Endlich ausgereift: Windows Server 2008 R2 im Praxistest

Windows Server 2008 R2 bietet eine Inplace-Upgrade-Funktion von Windows Server 2003 und 2008 an. Die Versuchung eines Upgrades ist groß. Meist ist sie jedoch nicht von Erfolg gekrönt. ZDNet versucht, insgesamt zwei Server umzurüsten. In beiden Fällen handelt es sich um echte Produktivserver, die seit Jahren in Betrieb sind.

Immerhin waren beide Upgrades am Ende erfolgreich. Bei einem Server handelte es sich um einen Windows Server 2003, der als Mailserver mit Exchange Server 2003 SP2 dient. Das Update scheitert zunächst an den installierten Daemon-Tools 4.08, die dazu verwendet werden, ISO-Images mounten zu können – eine Funktionalität, die eigentlich zur Basisausstattung eines jeden Betriebssystems gehören sollte.

Die Daemon-Tools laufen bekanntermaßen nicht unter Windows 7 und 2008 R2. Das hat der Compatibility-Checker sogar erkannt. Als Warnung erscheint eine Meldung, dass ein „SCSI Host/Bus Adapter“ Probleme bereiten könnte. Nach der Deinstallation der Daemon-Tools verschwindet die Warnung. Das Update läuft in etwa drei Stunden zu 90 Prozent durch. Dann erscheint beim letzten Boot ein Bluescreen: Der Daemon-Uninstaller hatte „vergessen“ seinen Kernelmode-Treiber zu deinstallieren.

Nach einem Neustart fährt der Server einen Rollback. Vor dem Upgrade wird immer eine Schattenkopie der Partition mit dem alten Betriebssystem angelegt. Beim kleinsten Fehler erfolgt der Rollback. Nach dem Löschen der Datei sptd.sys im Verzeichnis C:WindowsSystem32Drivers läuft das Update in weiteren drei Stunden durch. Microsoft Exchange fährt allerdings nicht mehr hoch.

Der zweite Server mit Windows Server 2008 beschwert sich über die Windows Internal Database, die vom Server Resource Manager benötigt wird. Sie müsse mindestens auf den Releasestand SQL Server 2005 SP3 gebracht werden. Installiert ist SP2. Windows Update hat das Upgrade schon mehrfach versucht, scheiterte jedoch. Der Grund ist, dass auf diesem Server zusätzlich die Vollversion des SQL Server 2005 installiert wurde. Das hat das Installationsprogramm „verwirrt“.

Abhilfe schafften die Deinstallation des Resource Manager, manuelles Löschen der GUID {BDD79957-5801-4A2D-B09E-852E7FA64D01} aus der Registry und ein anschließender Reboot. Danach war das Updateprogramm überzeugt, dass die Windows Internal Database nicht mehr installiert sei. Vor einer solchen Vorgehensweise ist bei einem Produktivserver allerdings zu warnen.

Erfolgreich ist das Update dennoch nicht. Irgendwas stimme mit der Active-Directory-Datenbank nicht. Da die Domain noch zwei weitere Domain-Controller hat, kann man den Upgradekandidaten kurzfristig zum einfachen Memberserver demoten. Das hat jedoch zur Folge, dass die Certificate Authority deinstalliert werden muss. Alle Clientzertifikate sind anschließend ungültig. Ein weiterer Grund, bei einem Produktivupgrade spätestens hier abzubrechen.