Umstieg auf Windows Server 2003
Der Umstieg auf Windows Server 2003 lässt sich auf zwei Arten durchführen: durch ein Upgrade eines vorhandenen Servers oder durch eine komplette Neuinstallation. Welche Methode für ihre Anforderungen die passende ist, hängt von der individuellen Situation ab. Diese Punkte sollten Sie vor einer Entscheidung beachten:
Ein Upgrade ist einfacher durchzuführen, denn die vorhandene Netzwerkstruktur lässt sich übernehmen.
Bei einem Upgrade brauchen Daten und Anwendungen nicht neu installiert zu werden. Vor dem Upgrade empfiehlt sich aber auf jeden Fall ein komplettes Backup der vorhandenen Festplatten.
Wenn Sie ihre Festplatten vor einer Installation neu formatieren, dann könnte sich deren Effizienz erhöhen. Außerdem können Sie dabei die Partitionsstruktur ändern und sie somit besser an geänderte Einsatzanforderungen anpassen.
Vor allem bei Servern, für die hohe Verfügbarkeit entscheidend ist, bietet sich eine Neuinstallation mit anschließender Neukonfiguration der Systemumgebung an. Das gilt besonders, wenn beim vorhandenen Betriebssystem bereits in der Vergangenheit mehrfache Upgrades vorgenommen wurden.
Auch bei einer Neuinstallation von Windows Server 2003 Standard Edition lassen sich unter Umständen andere Betriebssysteme auf dem Server einsetzen. Jedoch ist dabei zu berücksichtigen, dass dabei Schwierigkeiten aufgrund verschiedener Dateisysteme auftreten können.
Bei einem Upgrade auf Windows Server 2003 lassen sich dessen Vorteile nutzen, ohne dass die vorhandene Netzwerkkonfiguration geändert werden muss. Grundsätzlich lässt sich eine Migration auf zwei Arten durchführen:
Durch den Upgrade eines vorhandenen Windows 2000 Domänen-Controllers auf Windows Server 2003.
Durch die Installation von Active Directory mit dem Active Directory Installations-Assistenten auf einem Windows .NET–basierenden Member Server.
Tipps zur Durchführung eines Upgrades
Folgende Punkte sollten Sie bei einem Upgrade auf Windows Server 2003 berücksichtigen:
Überprüfen Sie, welche Windows 2000-Versionen im Einsatz sind und stellen Sie fest, ob Sie darauf ein Upgrade durchführen können oder ob eine komplette Neuinstallation nötig ist.
Weisen Sie den Mitarbeitern, die das Upgrade durchführen, die notwendigen Zugriffsrechte zu.
Stellen Sie in ihrer Netzwerk-Umgebung einen Windows .NET Member Server bereit. Wenn Sie darauf Active Directory installieren, dann lassen sich während des Upgrades die bereits vorhandenen Services ohne Unterbrechung weiter ausführen.
Die folgende Tabelle welche Upgrades von Windows 2000 Server auf Windows Server 2003 durchführbar sind:
Plattform
|
Upgrade auf Windows Server 2003 Standard Edition
|
Upgrade auf Windows Server 2003 Enterprise Edition
|
Upgrade auf Windows .NET Datacenter Server
|
Windows 2000 Server
|
|
|
|
Windows 2000 Advanced Server
|
|
|
|
Windows 2000 Datacenter Server
|
|
|
|
Beachten Sie dabei: Windows 2000 Server unterstützt maximal vier Prozessoren, Windows Server 2003 Standard Edition jedoch maximal zwei Prozessoren. Beim Upgrade eines Windows 2000 Servers mit vier Prozessoren auf Windows Server 2003 Standard Edition, erhalten Sie eine Warnung, dass zwei der vier Prozessoren nicht mehr verfügbar sein werden. Um weiterhin alle vier Prozessoren nutzen zu können, müssen sie auf Windows Server 2003 Enterprise Edition umsteigen.
Erstellen Sie einen Katalog der vorhandenen Hardware und überprüfen Sie, ob diese die empfohlenen Mindestvoraussetzungen erfüllt. Zur Installation von Windows Server 2003 Standard Edition sind mindestens eine 550 MHz CPU, 256 MB RAM und 1.5GB freier Festplattenspeicher erforderlich. Zur Installation eines Domain-Controllers ist noch zusätzlicher Speicherplatz erforderlich. Das Laufwerk, das die Active Directory Datenbank-Templates (NTDS.dit) speichert, benötigt einen freien Speicher, der 10 Prozent der aktuellen Datenbankgröße entspricht, im Mindestfall aber 250 MB. Das Laufwerk mit den Active Directory ESENT Transaktions-Logdateien benötigt mindestens 50MB freien Speicherplatz.
Erstellen Sie einen Notfallplan mit klaren Anweisungen, wie das Upgrade-Team den Anwendern weiterhin einen normalen Betrieb bereitstellen kann, falls ein Teil des Upgradeprozesses fehlschlägt.
Dokumentieren Sie die Konfiguration der Domänen-Controller und legen Sie fest, in welcher Reihenfolge das Upgrade erfolgt. Rüsten sie als erstes den Windows .NET-basierenden Member Server in einen Domänen-Controller um. Danach können Sie die anderen Domänen-Controller in beliebiger Reihenfolge umrüsten.
Führen Sie vor dem Upgrade unbedingt eine Datensicherung durch.
Bevor Sie den Upgradeprozess starten, sollten Sie auf jeden Fall die Funktion der vorhandenen Domänen-Controller überprüfen. Stellen Sie sicher, dass diese korrekt arbeiten und die Replizierung des Active Directories konsistent und fehlerfrei abläuft. Nach dem Upgrade können Sie mit den in Windows Server 2003 mitgelieferten Werkzeugen den korrekten Ablauf des Upgrades nachprüfen.
Vor dem Upgrade des ersten Windows 2000 Domänen-Controllers oder vor der Installation von Active Directory auf einem .NET Member Server, müssen Sie das Active Directory Preparation Tool (ADprep.exe) ausführen. Ohne diesen Schritt ist ein Upgrade der Domänen-Controller nicht möglich. ADPrep.exe muss ebenfalls ausgeführt werden, bevor sich Active Directory mit dem Active Directory Installations-Assistenten auf einem Windows .NET Member Server installieren lässt.
Weitere Informationen zu diesem Thema finden Sie hier: http://www.microsoft.com/reskit
Migration von Anwendungen
Im den meisten Fällen sollen nach einem Upgrade des Betriebssystems die im Unternehmen vorhandenen Anwendungen weiter verwendet werden. Windows Server 2003 erlaubt im Normalfall die problemlose Weiterverwendung von Applikationen, die bisher unter Windows 2000 Server laufen. Der folgende Teil beschreibt, worauf bei der Migration von existierenden Anwendungen zu achten ist.
Als erstes sollten Sie überprüfen, welche Applikationen von Microsoft oder anderen Anbietern sich auf dem Server befinden, die nicht zum Lieferumfang des Windows Server 2003 gehören. Vergewissern Sie sich, welche dieser Anwendungen während des Upgrades auf dem Server bleiben können und welche neu installiert werden müssen. Genauere Hinweise dazu finden Sie in der entsprechenden Dokumentation. Prüfen Sie bei Applikationen von anderen Anbietern auch, ob der Hersteller eventuell Migrations-Utilities anbietet, die den Umstieg vereinfachen.
Selbst erstellte Anwendungen
Anwendungen, die in Visual Basic (VB 6.0) oder C++ geschrieben sind, laufen grundsätzlich unverändert auf Windows Server 2003. Voraussetzung dafür ist, dass die erforderlichen Laufzeit- und Klassenbibliotheken installiert sind. Dies geschieht im Falle der VB 6.0 Laufzeit-Bibliothek bereits per Default während der Server-Installation. Für C++-Anwendungen müssen die im Lieferumfang befindlichen Microsoft Foundation Class (MFC) Programm-Bibliotheken (Version 4.2) installiert sein.
Für jede Applikation, die Sie weiterhin auf Windows Server 2003 einsetzen, empfiehlt es sich, ein sogenanntes Applikations-Manifest zu schreiben, in dem die von der Applikation verwendeten DLLs (Dynamic Link Libraries) mit der genauen Versionsnummer festgelegt werden. Dadurch lassen sich Probleme durch Versionskonflikte verhindern.
Weitere Informationen zu diesem Thema finden Sie hier:
Deployment Changes in Visual Basic .NET
Migrating Win32 Applications to Windows Server 2003
VBRun60.exe Installs Visual Basic 6.0 Run-Time Files
DLL Help Database
Wenn Ihr Ziel optimale Performance und die Nutzung der erweiterten Features von Windows Server 2003 ist, dann empfiehlt es sich, vorhandene Applikationen mit Hilfe des neuen .NET Framework neu erstellen. Weitere Informationen zu diesem Thema finden Sie hier: Migrating Win32 Applications to Windows Server 2003.
Verwendung von IIS 6.0
IIS 6.0 besitzt zwei unterschiedliche Isolationsmodi, wobei jeder Modus andere Erfordernisse an die Konfiguration stellt. Während der Isolationsmodus für Arbeitsprozesse die neuen Features von IIS 6.0 voll ausnutzt, garantiert der IIS 5.0 Isolationsmodus Abwärtskompatibilität zur Vorgängerversion. Im Isolationsmodus für Arbeitsprozesse lassen sich Anwendungen durch Verwendung von Applikationspools voneinander isolieren.
Jedoch laufen möglicherweise nicht alle vorhandenen Anwendungen in dem neuen Modus. In diesen Fällen muss dann der abwärtskompatible IIS 5.0 Isolationsmodus verwendet werden. Bei seinem Einsatz sollte jedoch jede vorhandene Applikation vorab gründlich getestet werden, um auszuschließen, dass sie übermäßig viele Server-Ressourcen verbraucht und dadurch die Gefahr besteht, dass sie Prozesse zum Absturz bringt.
Daher empfiehlt es sich, immer wenn möglich den Isolationsmodus für Arbeitsprozesse einzusetzen. In folgenden Situationen lässt sich der Einsatz des IIS 5.0 Isolationsmodus jedoch nicht vermeiden:
Bei ISAPI-Filtern, die Rohdatenfilter lesen.
Bei Prozessen, in denen der Session Status beibehalten wird. Eine Ausnahme hierfür bilden nur ASP Sessions, die auch im Isolationsmodus für Arbeitsprozesse problemlos funktionieren.
Bei COM-Objekten, oder jeder anderen Applikation, die nicht multi-instance aware ist.
Bei Verwendung von Microsoft Exchange.
Beim ersten Start von IIS 6.0 ist der Isolationsmodus bereits voreingestellt. Diese Einstellung hängt von der Vorgängerinstallation ab. Die folgende Tabelle zeigt die dabei mögliche Konfiguration:
Art der Installation
|
Voreingestellter Isolationsmodus
|
Neuinstallation von IIS 6.0
|
Isolationsmodus für Arbeitsprozesse
|
Upgrade von einer früheren Version von IIS 6.0
|
Der Modus der vorhergehenden Installation wird übernommen
|
Upgrade von IIS 5.0
|
IIS 5.0 Isolationsmodus
|
Unabhängig von der Voreinstellung lässt sich der Betriebsmodus jederzeit im Internet Service Manager ändern. Jedoch ist danach ein Neustart des Internet Information Servers notwendig.
ISAPI-Filter
Bei Applikationen, die ISAPI-Filter nutzen, empfiehlt es sich, diese als ISAPI-Extensions neu zu schreiben. Dadurch steigern Sie deren Leistungsfähigkeit, denn:
ISAPI-Extensions sind multi-instance aware und können daher im Isolationsmodus für Arbeitsprozesse laufen
ISAPI-Extensions laufen asynchron, während ISAPI-Filter nur synchron laufen.
Weitere Informationen zu diesem Thema finden Sie hier:
ASP und COM+
ASP-Applikationen (Active Server Page), die keine ISAPI-Filter verwenden, lassen sich normalerweise ohne Probleme auf Windows Server 2003 übertragen, wenn sie über die folgenden Eigenschaften verfügen:
Ausgabe von HTML und Used Session Variablen
HTML-Ausgaben, die vom SQL Server durch ADO aufgerufen werden
Used System ODBC-Datenquellen.
Dies gilt sowohl für die 32-Bit als auch für die 64-Bit Edition von Windows Server 2003. ASP-Applikationen laufen ohne Änderung auf der Windows Server 2003 64-bit Edition für Itanium, wenn sie in Skript-Code (wie VBScript oder ECMAScript) geschrieben sind und keine 32-Bit COM-Komponenten (Component Object Model) benötigen, die nicht Bestandteil von Windows Server 2003 sind.
Vorhandene COM+ Applikationen laufen normalerweise ohne Änderung unter IIS 6.0. In 5.0 ASP-Anwendungen in IIS 5.0 verwenden COM+ Services, in dem sie das WAM-Objekt der Applikation im COM+ Configuration Store zur Nutzung eines Satzes von Services konfigurieren. Diese Vorgehensweise ist erforderlich, weil COM+-Services für die Nutzung in Zusammenarbeit mit COM-Komponenten konzipiert sind. Dagegen sind in IIS 6.0 COM+-Services von den Komponenten getrennt und erlauben dadurch jeder ASP-Anwendung, COM+-Services zu nutzen.
Die folgende Tabelle zeigt, welche zusätzlichen Services ASP nun gegenüber COM+ bereitstellt:
Eigenschaft
|
Beschreibung
|
Fusion Unterstützung
|
Erlaubt einem Entwickler, für jede ASP-Applikation die genaue Version von Runtime-Bibliotheken und COM-Komponenten festzulegen, mit denen die Anwendung arbeitet. So werden Probleme durch neuere Versionen mit geänderter Funktionalität verhindert.
|
Partitions Unterstützung
|
COM+ Partitionen erlauben es dem Administrator, für verschiedene Anwender unterschiedliche Konfigurationen einer einzigen Com+ Applikation zu definieren. Dabei enthält jede Konfiguration Sicherheits- und Versions-Informationen.
|
Tracker Unterstützung
|
Sobald er aktiviert ist, zeigt der COM+ Tracker dem Administrator an, welcher Code wann in einer ASP-Session abgearbeitet wird. Dadurch wird das Debugging von ASP-Applikationen außerordentlich erleichtert.
|
Auswahl des Apartment Modus
|
ASP über COM+ erlaubt Entwicklern festzulegen, ob sie den Single-Threaded Apartment Modus (Standard) oder den Multi-Threaded Apartment Modus einsetzen (Dieser ist für Applikationen mit poolbaren Objekten verwendbar).
|
Weitere Informationen zu diesem Thema finden Sie hier:
IIS 6.0 Overview
COM+ Documentation
Technical Overview of Internet Information Services 6.0
|
