EOL für Windows Server 2003: Migration des Active Directory

Die Version des Active Directory (AD) wird üblicherweise bei einer Migration von Windows Server 2003 auf Windows Server 2012 Release 2 hochgestuft. Denn mit der aktuellen AD-Variante stehen komfortable Funktionalitäten zur Verfügung. Dabei stehen zwei Wege offen: zum einen eine Migration des AD und zum anderen ein Upgrade. Welche Vorteile diese Optionen bieten und wie das Thema DNS (Domain Name System) bei einer Migration anzugehen ist, verdeutlicht dieser Beitrag.

Wer seine Windows-basierte IT-Umgebung auf der Basis von Windows Server 2003 betreibt, der hat üblicherweise auch das Active Directory (AD) in dieser „Funktionsstufe“ im Einsatz. Muss man nun die Umstellung angehen und seine mit Windows Server 2003 arbeitenden Domänencontroller in der Gesamtstruktur auf die aktuellste Produktivversion von Windows, den Windows Server 2012 Release 2, umsteigen, so gibt es zwei prinzipielle Ansätze:

• das Ausführen eines Upgrades der Gesamtstruktur (Forest) und
• das Ausführen einer Migration der Gesamtstruktur.

Dabei erweist sich die Migration als der schwierigere Ansatz. Denn bei einer Migration der Gesamtstruktur muss man einige oder sogar alle AD-Objekte, die in der Ausgangs-Gesamtstruktur vorliegen, auch wieder in der Ziel-Gesamtstruktur anlegen. Der Vorteil einer Migration allerdings zeigt sich recht deutlich: Bei dieser Arbeit kann man alle früher einmal angelegten Objekte, die man allerdings mittlerweile nicht mehr benötigt, weg lassen. Sprich es lässt sich eine Säuberungsaktion ausführen, so dass nicht mehr unnütze Objekte „mitgezogen“ werden müssen. Das wird zu einer besseren Performance führen – etwa bei der AD-Replikation. Der Nachteil allerdings ist nicht von der Hand zu weisen: Betreibt ein Unternehmen Applikationen, die in das AD integriert sind (wie zum Beispiel Exchange), dann wird die Migration und auch das Weglassen von – scheinbar – nicht mehr benötigtem Objekten recht schwierig.

Deswegen sind die Upgrade-Aktionen beim AD weitaus einfacher. Denn dabei wird auf den „Frühjahrsputz“ in Sachen AD verzichtet. Beim Upgrade wird das AD einfach erweitert und man kümmert sich nicht darum, ob alle aktualisierten AD-Objekte überhaupt noch benötigt werden. Die Umstellung geht somit schneller von der Hand, denn der Administrator muss bei den AD-Objekten nicht entscheiden, ob sie in der aktualisierten Umgebung gebraucht werden.

Der Vorgang des AD-Upgrades von Windows Server 2003 auf Windows Server 2012 Release 2 umfasst einige Schritte – die allerdings nicht sonderlich kompliziert sind:

• Es werden zunächst Member Server (Mitgliedsserver) mit Windows Server 2012 R2 hinzugefügt.
• Im nächsten Schritt werden diese Systeme zu Domänencontrollern heraufgestuft.
• Anschließend werden die FSMO-Rollen von den Domänencontrollern mit Windows Server 2003 auf die mit Windows Server 2012 R2 überführt.
• Danach werden die Domänencontroller auf Basis von Windows Server 2003 „zurückgestuft“ – sie sind dann keine Domänencontroller mehr. Denn in einem AD-Verbund dürfen keine Domänencontroller mit verschiedenen Funktionsebenen aktiv sein – ansonsten wären Probleme im Betrieb – etwa bei der Replikation des AD – zu erwarten.

Änderungen am AD durch die Umstellung

Die Wahrscheinlichkeit ist groß, dass in einer Umgebung mit vielen Systemen auf der Basis von Windows Server 2003 auch die Domänen und die Gesamtstruktur auf dieser Funktionsebene stehen (sprich die Domänencontroller arbeiten mit Windows Server 2003). Kommen nach der Migration Domänencontroller mit Windows Server 2012 Release 2 zum Einsatz, können diese Systeme auch so konfiguriert werden, dass die Domänen und die Gesamtstruktur auf der neueren Funktionsebene – Windows Server 2012 R2 – betrieben werden.

Mit dieser aktuelleren Version der Funktionsebenen handelt man sich einige Vorteile ein, verglichen mit dem AD auf der Basis von Windows Server 2003. Dazu gehören unter anderem die folgenden Punkte:

• DFS-Replikation für SYSVOL,
• feingranulare Kennwortrichtlinien,
• Personal Virtual Desktops,
• automatisches SPN-Management für Dienste, die im Kontext des „Managed Service Accounts“ laufen,
• geschützte Benutzerkonten
• Authentifizierungs-Richtlinien und
• Active Directory Recycle Bin (AD-Papierkorb).

Der Nachteil der Aktualisierung der Funktionsebene einer Domäne: Die Domänencontroller müssen mindestens mit der Betriebssystemversion der zugehörigen Funktionsebene konfiguriert sein. Also wenn man auf der Funktionsebene Windows Server 2012 in der Domänen arbeiten will, müssen die Domänencontroller entweder mit Windows Server 2012 oder mit Windows Server 2012 R2 ausgestattet sein.

Der Umstieg auf eine aktuellere Funktionsebene in einer Domäne oder Gesamtstruktur bedeutet allerdings nicht, dass man auch bei den Member Servern die neueren Betriebssystemversionen einsetzen muss. Es darf weiterhin ein Member Server mit Windows Server 2003 konfiguriert sein, wenn er in einer Domäne zum Einsatz kommt, die auf der Funktionseben Windows Server 2012 R2 läuft.

Mehr Informationen über die Funktionalitäten in den verschiedenen Funktionsebenen das AD verdeutlicht Microsoft in einem Technet-Beitrag.

Die passende DNS-Infrastruktur

Ehe man in seiner AD-basierten IT-Umgebung den Umstieg von Windows Server 2003 auf Windows Server 2012 R2 macht, muss man sich noch dem Thema DNS (Domain Name System) widmen. Es gilt herauszufinden, welche Server in einer Organisation als DNS-Server fungieren. Des Weiteren ist zu bestimmen, welche DNS-Zonen auf den eigenen DNS-Servern gehostet sind und welcher Art diese Zonen sind.

Bei einer „Active Directory Integrated Zone“ handelt es sich um eine DNS-Zone, die im AD gespeichert ist. Eine „normale“ Primary Zone oder Secondary Zone werden dagegen in normalen Dateien abgelegt. Die „Stub Zonen“ enthalten lediglich Einträge von Namenservern können ebenfalls im AD abgelegt sein oder in einer normalen Datei.

DNS-Umgebungen auf der Basis von Windows Server 2003 haben üblicherweise zwei verschiedene Ansätze: Entweder ein Domänencontroller agiert als DNS- Server oder aber eigenständige DNS-Server kommen zum Einsatz. Bei den eigenständigen DNS-Servern lautet die Konfiguration so, dass sie entweder die Standard Primary Version oder die Standard Secondary Version einer Zone beheimaten. Dagegen können Domänencontroller sowohl die Standard Primary Version als auch die Standard Secondary Version einer Zone enthalten.

Der Administrator kann mit dem folgenden Befehl bestimmen, ob eine Zone im Active Directory oder in einer Datei gespeichert ist:

Dnscmd /enumzones

Diese Information lässt sich auch über die GUI ermitteln: Mit Hilfe der DNS Manager Konsole kann der Administrator diese Information ebenfalls herausfinden. Der Vorteil der Befehlszeile: Damit ist der Administrator auch in der Lage, entfernte DNS Server abzufragen.

Weiter Informationen sollte der Systembetreuer ebenfalls herausfinden: Es geht darum, ob DNS Forwarder konfiguriert sind und ob auch erweiterte Optionen zum Einsatz kommen (wie etwa ein Round Robin-Verfahren) die irgendwelche Abweichungen von einem Standardverhalten zur Folge haben.

In den meisten Fällen haben die Unternehmen zwar keine Abweichungen vom Standard vorgenommen, doch das sollte idealerweise immer im Vorfeld – beim Assessment der bestehenden Umgebung – überprüft werden. Wenn man nach der Migration Probleme beim DNS feststellt, wird das eine sehr aufwändige Fehlersuche nach sich ziehen.

Rainer Huttenloher