A Windows Server 2008 rendszerben már nem települ alapértelmezés szerint a Network Load Balancing funkció, a Feature-ök közül kézzel kell feltenni. Ez jó, ha nincs rá szükségünk. Ha viszont szükségünk van rá, de nem a megfelelő ütemben telepítjük, furcsa hibát tud okozni.

Ha fel van telepítve - akár még úgy is, hogy nincs NLB bekonfigurálva - az Exchange CAS szerepkör telepítője a következő hiba miatt fog megállni:

Invalid URI: The hostname could not be parsed

A gondot egy PowerShell parancs okozza: New-OabVirtualDirectory -DomainController $RoleDomainController

Ez a parancs adja a fenti hibát. Hogy miért, arra egyelőre nincs magyarázat, de az NLB feature-t eltávolítva ugyanez a hiba már nem jön elő, az Exchange 2007 CAS feltelepül.

Ez után telepítve az NLB-t már mindkettő vidáman fog működni.

Ha a Windows Server 2008 R2-n futó virtuális szervert szeretnénk Network Load Balancing funkcionalitással felruházni, nem árt tudni, hogy az R2-ben lévő virtuális switch hogy is működik. Alapértelmezés szerint ugyanis a virtuális szerver indulásakor megtanulja annak MAC címeit és a későbbiek során a szerverhez tartozó port(okon) nem is enged más MAC című forrásból származó forgalmat. Ez Unicast módú NLB szempontból súlyos következményekkel jár, konkrétan a funkció nem fog működni.

Szerencsére van lehetőség a virtuális switch fent leírt biztonságos működésének kikapcsolására. A virtuális gép hálózati csatolóinak beállításai közt található az Enable spoofing of MAC addresses jelölő, amely bekapcsolt állapotban más MAC című forgalmat is enged a hozzá tartozó switch porton, mint amit a gép indulásakor megtanult, így az NLB működni fog.

Az írás lehetne anny is, hogy az IIS 7.0 telepítése csak a rendszer kötetre történhet és sajnos valóban ez a szomorú igazság.
Van erre azonban workaround. Kicsit furi, de működik. Thomas Deml az IIS csapat program mendzsere készített egy szkriptet, ami elvégzi a piszkos munkát: http://blogs.iis.net/thomad/archive/2008/02/10/moving-the-iis7-inetpub-directory-to-a-different-drive.aspx
Két kiegészítés a fentiekhez: a szkriptben két helyen is fixen be van kódolva az f: meghajtó, mint cél. Ezt használat előtt érdemes javítani. A szkript a futtatás során elvégzi az Inetpub mappa mozgatását is, így az xcopy paranccsal már nem is kell bajlódni.

Ez aztán az érdekes téma, teljesen általános, hogy az ember ilyesmit kénytelen csinálni. :o)
A menet a következő:
IIS telepítés
PHP telepítés
PHP beálllítás

Az IIS telepítése egyenesen előre típusú művelet: Add/remove role, IIS  hozzáadása alapbeállításokkkal, valamint a PHP miatt érdemes hozzáadni a CGI-t is. Befejezés.
Aztán jön a gondolat, hogy best practise, meg amúgy se babráljunk ki magunkkal, jobb lenne, ha az IIS mégsem a rendszer köteten foglalá a helyet, nosza tegyük át. Aha, csakhogy ilyet nem lehet! Illetve lehet, de a módszer nem elegáns. Nade erről majd egy külön írásban.
Jöhet a PHP telepítése. Mivel Windows a környezet, ajánlott a VC9 Non Thread Safe installer használata, amely letölthető innen: http://windows.php.net/download
Hogy miért ez az ajánlott, az kiderül ebből a leírásból, de lényeg, hogy ez nyújtja majd a legjobb teljesítményt. Szükség lesz még a Microsoft 2008 C++ Runtime telepítésére is. A PHP telepítésekor a telepítési mód kérdésre természetesen a FastCGI a jó válasz.
A telepítő elvégzi az IIS beállítását is, így Module Mapping (*.php a php-cgi.exe használatával) és a Default Document (index.php) beállításokat is.
A PHP konfigurálása már ízlés kérdése. Ez ugyebár a php.ini fájl szerkesztésével történik, ami elég jól dokumentált. Azonban ehhez már nem árt a fejlesztő segítsége, mert a sima rendszermérnök itt már könnyen elvérzik és még számonkérni sem lehet rajta. :o)

Az ISA Server szerintem egy nagyon jó tűzfal, sőt annál sokkal több, microsoftos rendszerekhez a legjobb választás. Persze egy tűzfal nem tűzfal, nem árt ha van előtte pl egy Cisco ASA.
Szóval a termék jó, minden verzióval és javító csomaggal egyre jobb lesz, de természetesen van pár "limitation", meg "not supported" scenario. Ezekkel nem is sűrűn találkozik az ember, de ha mégis, sok kellemetlenséget tudnak okozni. Ezért kell minden bevezetést jól megtervezni és jól letesztelni. Blabla. :o)
Egy ilyen dokumentált tulajdonság a transparent network address translation (NAT). Ha két hálózati interfész közé  route viszonyt definiáltunk, a webes forgalmat az ISA akkor is átvezeti a Web Proxy filteren, ha a fene fenét eszik is. Az pedig már NAT. És ez történik az úgynevezett Web Proxy kliensekkel (böngészőben beállított proxy az ISA), a SeureNAT kliensekkel (kb a default gateway az ISA) és a Firewall kliensekkel is (kliens oldalon telepített kis tűzfal alkalmazás).
Ez akár még jó is lehetne, hiszen ilyenkor működik a proxy cache és teszi a dolgát a filter is, de ha nem csak tréfából állítottunk route viszonyt a két interfész közé, hanem valóban fontos lenne a forrás valódi IP címe, akkor bizony cselhez kell folyamodni:
http://support.microsoft.com/kb/838708

Najó, ez csak egy vicc, de tényleg nagyon örvendetes az újítás. A szerveren a Start menüre kattintva végre nem a Shutdown gomb jelenik meg, hanem a Logoff. Innováció a köbön! :)

Ezt a remek tulajdonságot többször is sikerült megtapasztalnom. Exchange 2003 és Outlook 2003, valamint Exchange 2007 és Outlook 2007 párosokkal is. A történet röviden annyi, hogy Exchange restore után a cache mode-ot használó Outlook kliensekben az új levelek nem szinkronizálódnak megfelelően. A cache mode kikapcsolt állapotában minden működik  rendesen, de visszakapcsoláskor újra előjön a hiba, az új levelek eltűnnek. Küldeni lehet, a kapott levelek OWA felületen látszódnak is, de az Outlookban nem.

A megoldás az .ost fájl törlése és új Outlook profil létrehozása. Egyszerű, annak aki ért hozzá. Azért egy 80 felhasználós környezetben megcsinálni ezt, komoly kitolás. Szerencsére egy okosan beállított Group Policy Startup script sokat tud segíteni.

Egy korábban más által telepített System Centerk Operations Manager (SCOM) 2007 rendszert frissítése során találkoztam ezzel a furcsa hibával. Egy XP kliensen szerettem volna frissíteni a konzolt, de a telepítő elindítása után mindössze egyetlen üzenet jelent meg:
We need to install a Software Update before we can install Service Pack1, it modifies setup configuration and does not modify files or registry, do you want to proceed with the Service Pack1 update?

A Yes gomb lenyomása után pedig nem történt semmi.

A google erre az üzenetre 3 találatot adott, persze egyik sem a jó megoldásról szólt. Végül a OpsMgr, SCE And MOM Blog oldalon akadtam rá a hiba okára: http://blogs.technet.com/cliveeastwood/archive/2008/02/25/upgrading-opsmgr-evaluation-copies-to-sp1-rtm.aspx

Itt egyébként szerepel is a hibaüzenet, de csak egy kép formájában. :os

Az előzőleg telepített konzol még egy RTM előtti változat volt, amit az SP1 telepítő nem volt hajlandó frissíteni, csak erről elfelejtett tájékoztatni is.

Meglévő konzol leszed, majd RTM konzol telepít. Ezt már simán frissítette az SP1-es telepítő készlet.