Single Label Domain

Bei der Einrichtung eines neuen Active Directory gibt es eine ganz wichtige Stelle, an der ein Administrator den "Namen" der ersten Domäne, der Forrest-Root-Domäne, eingibt. Gerade bei den Anfängen des Active Directory war es noch nicht jedem bewusst, was es denn mit dem neuen Namen auf sich hat. Zumal auch immer noch der "NetBIOS-Name" eingegeben wurde, wie dies bei NT4-Domänen schon immer der Fall war. Leider ist es wohl nicht selten passiert, dass hier der DNS-Name mit dem NT4-Domänenname gleich gesetzt wurde.

Windows 2000 (SP4) hat zwar davor gewarnt aber dies nicht unterbunden, denn natürlich können Sie auch eine DNS-Zone "FIRMA" machen und müssen nicht zwingend einen Punkt nutzen. Aber das ist aus heutiger Sicht sehr ungeschickt gewesen, denn aktuelle Produkte von Exchange und Lync und vermutlich auch andere Systeme unterstützen diese Single Label Domain" nicht mehr. für die Wahl eines Domänennamen für die Forest Root Domäne gibt es aus meiner Sicht vier Möglichkeiten:

Die Abkürzung "tld" verwende ich als Platzhalter für eine beliebige offizielle "Top Level Domain" wie z.. ".de" oder ".com" o.ä.

Beispiel Kurzbezeichnung Bewertung Status

firma.

Single Label Domain

Über diesen "Sonderfall", dass eine Domäne keinen "Punkt" hat, handelt diese Seite.


Nicht ratsam

firma.intern.
firma.local.

Privater DNS-Namensraum

Gerade in der Anfangszeit wurde oft ein "nicht öffentlicher" Namen genutzt. Da die Top-Level Domain "intern" oder "local" oder "AD" nicht im öffentlichen Internet verwendet wurden, haben einige Firmen diese TLD als Basis für das Active Directory genutzt. Allerdings ist dies nicht mehr sicher, seit dem es Bestrebungen für viele neue Domänen gibt.


möglich

firma.tld.

Offizielle Name, der aber (noch) nicht extern genutzt wird

Daher haben einige Firmen neben der offiziellen Webseite und Maildomäne sich einfach noch einen zweiten Namen "gekauft", der aber extern nicht genutzt wird. So kann dieser DNS-Name aber intern verwendet werden, ohne das es zu einem Konflikt mit einer anderen Firma käme, die extern den gleichen Namen verwendet.


möglich

firma.tld.

SplitDNS

Eine durchaus ratsame Konfiguration ist der Betrieb eines Split-DNS, bei dem intern der gleiche Namensraum genutzt wird, wie im Internet. Natürlich muss ein Administrator dann beachten, dass z. B. www.firma.tld vom internen DNS-Server aufgelöst wird und als "intern" angesehen wird. Entsprechende Ausnahmen oder Regeln sind entsprechend erforderlich. Speziell in kleinen Firmen sind dies aber meist nur wenige Hostnamen, die so behandelt werden müssen.


Gut

sub.firma.de.

Privater DNS-Namensraum

Wer schon einen offiziellen Namen hat, kann natürlich sein Active Directory als Subdomäne darunter nutzen. Damit bliebt intern die Hierarchie und DNS-Auflösung problemlos erhalten und man spart sich den externen Domänenmanen


Gut

Welcher Namensraum für sie nun "passend" oder sogar "optimal" ist, kann lässt sich nicht verallgemeinert sagen. Im Hinblick auf eine immer wichtigere "überall Verbunden"-Strategie sollten Sie ihren Mitarbeitern nicht mehr zumuten, sich für den internen und externen Zugriff unterschiedliche URLs zu merken. Das gilt insbesondere für Exchange OWA, ActiveSync, LyncWebservice.
Auf der anderen Seite müssen Sie natürlich ihre interne Namensauflösung korrekt gewährleisten und auch Anbindungen an Partner oder VPN und Direct Access berücksichtigen.

Wenn ein Forest aus mehreren Domänen besteht, dann gibt es natürlich noch weitere DNS-Namensräume, die daneben oder darunter. Das primäre Problem ist aber, dass sie relativ problemlos weitere Domänen mit richtigem DNS-Namen installieren und deinstallieren können aber die Forrest-Root-Domäne nur in einem Fall umbenennen können.

Probleme mit Single Label Domain

Die ersten Jahre von Windows 2000 haben viele Programme noch die "NT4-Denkweise" an den Tag gelegt und sich nicht wirklich um DNS gekümmert. Insofern ist es auch nicht wirklich "aufgefallen", wenn eine Domäne eine "Single Label Domain" war. Aber Microsoft hat in einem KB-Artikel und dem DNS Planning Center schon lange auf Inkompatibilitäten hingewiesen.

Exchange 2000 war wohl das erste Produkt, welches das Problem mit der Single Label Domain aufgezeigt hat. Aber vermutlich haben viele Firmen damals zwar schon Windows 2000 eingesetzt aber noch einige Zeit mit Exchange 5.5. gearbeitet. Schließlich war die Migration von Exchange 5.5 nach Exchange 2000/2003 alles andere als trivial. Erinnern sie sich nur an die Zeiten des Active Directory Connector. Aber mit der Zeit kamen weitere Produkte hinzu, so dass in der Vergangenheit schon mehrere Firmen ihr Active Directory umgebaut haben.

Interessanterweise war es aber mit Windows 2003 und Exchange 2003 wieder problemlos möglich, eine Single Label Domain mit Exchange zu betreiben, was aber kein Freibrief für eben diese Installation sein soll. Denn folgende Programme werden sich bei einer Single Label Domain auf jeden Fall nicht installieren lassen

  • Microsoft Exchange 2000 Server
  • Microsoft Exchange Server 2007
  • Microsoft Internet Security and Acceleration (ISA) Server 2004
  • Microsoft Live Communications Server 2005
  • Microsoft Operations Manager 2005
  • Microsoft SharePoint Portal Server 2003
  • Microsoft Systems Management Server (SMS) 2003
  • Microsoft Office Communications Server 2007
  • Microsoft Office Communications Server 2007 R2
  • Microsoft System Center Operations Manager 2007 SP1
  • Microsoft System Center Operations Manager 2007 R2

Und die Liste wird sicher eher länger denn kürzer werden.

Wenn eine Firma also jemand in jüngerer Zeit noch eine Single Label Domain installiert hat, dann sollten Sie vielleicht den alten Dienstleister oder Berater wechseln oder überhaupt ihre Optionen einer Unterstützung hinterfragen.

Wege aus der Sackgasse

Wenn Sie also mit dem aktuellen Domänenamen nicht mehr weiter arbeiten können, weil er z.B. nur eine "Single Label Domain" ist oder weil der Name einen anderen Konflikt verursacht, wie das bei Firmenzukäufen oder Auftrennungen manchmal der Fall ist, dann gibt es drei Optionen:

Option Beschreibung Bewertung
Rename der (Root)-Domäne

Mit NT4 war es relativ einfach den Namen einer Domäne zu ändern. Mit Windows 2000 war dies gar nicht möglich. Erst seit Windows 2003 oder höher ist es überhaupt möglich, eine Domäne umzubenennen.

Wichtig: ein Rename einer Domäne ist nur mit Exchange 2003 SP1 unterstützt. Sobald im Forest ein Exchange 2000/2007/2010 Server enthalten ist, kann kein Domain Rename durchgeführt werden.

Abgesehen von der Beschränkung auf Exchange 2003 ist auch dann ein Rename nicht gerade "Plug and Play". Datenverluste sind zwar nicht zu erwarten aber eine Downtime muss eingeplant werden. Und ziemlich viel "Arbeit". So müssen z.B. alle Workstations in der Domäne zweimal rebootet werden. Gut wer mit hier mit einem Softwaremanagement und WOL arbeiten kann.

Risiko, enge Randbedingungen
Cross Forest Migration

Eine andere Option ist natürlich der Aufbau einer komplett neuen Umgebung nach aktuellen Vorgaben. Viele Firmen präferieren diesen Weg, weil sie glauben er wäre einfacher und alte Fehler würden verschwinden.

Wenn ihre aktuelle Umgebung schon "verkonfiguriert" ist, dann ist das sicher nicht die Schuld von Windows, sondern eher der handelnden Personen. Eine neue Umgebung ist nur dann "sauber" wenn die Personen das Know-how dazu haben und sie lange überfällige Konzeptarbeit erledigt haben!. Ansonsten bessert sich nur kurzfristig was.

Auch eine Migration "Cross Forest" ist eine mittlere Herausforderung. Sicher gibt es Werkzeuge wie ADMT, um Benutzer, Computer und Dienste zu verschieben aber auch hier ist umsicht und Arbeit erforderlich. Nur ganz kleine Firmen werden an einem Wochenende alles "umstellen" können. Ansonsten gibt es eine Koexistenzphase, in der Teile schon in der neuen Umgebung arbeiten und andere Komponenten noch in der alten Welt. Bei einem "Rename" der DNS-Domäne kann es dabei nicht bleiben, da der NetBIOS-Name nicht gleich sein darf. Die SidHISTORY erlaubt zwar eine Transponierung der NT-ACLs, aber Drittprogramme haben vielleicht andere Konfigurationsspeicher.

Und letztlich muss natürlich auch Exchange und eventuell Lync "umgestellt" werden. können hier nicht alle Nutzer zeitgleich migriert werden, muss über Federation und Verzeichnisabgleich eine Koexistenz unterstützt werden. Oft ist hier der Einsatz von Drittprodukten ratsam oder sogar erforderlich, um Geschäftsanforderungen zu erreichen.

Viel Arbeit aber kann sich über längere Zeit hinziehen.
Intra Forest Migration

Ein Sonderfall kann die Migration innerhalb eines Forests sein. Im Gegensatz zu einer Cross Org Migration kann man System innerhalb des gleichen Forest einfacher verlagern. So kann man eine neue Domäne mit dem gewünschten Namen aufbauen und die Single Label Domain "leeren". Das geht allerdings nicht mit der Forest Root Domäne.

Sonderfall

Je größer eine Firma ist, je größer die Datenmenge, die Anzahl der Clients, Server und Dienste ist und je mehr Verzahnungen und Integrationen vorliegen, desto aufwändiger wird die umbau einer solchen Umgebung.

Gegenüberstellung

Ich habe versucht ein paar Aspekte der beiden Lösungswege gegenüber zu stellen. Dies ist nur ein Auszug mit wenigen Aspekten um die Komplexität aufzuzeigen.

Thema Domain Rename Cross Org
Migrationsweg

"AdHoc" Umstellung in kurzer Zeit. Kein "Weg zurück" möglich.

Migration einzelner Komponenten erlaubt
Zeitrahmen

Die Umstellung glieder sich in drei Phasen:

  • Analyse
    Aufnahme derUmgebung
    Prüfen der Rename-Unterstützung
  • Domain Rename
    Oft am Wochenende "durchgezogen"
  • Nacharbeiten

Der Aufwand bewegt sich meist in Tagen oder wenige Wochen.

Die Umstellung gliedert sich in vier Phasen:

  • Analyse
    Aufnahme der Umgebung
    Prüfen der Migrationswege
  • Aufbaue der ZielUmgebung und Verbindung mit Quelle
  • Migration der Dienste, Computer, Accounts
    Diese Phase kann sich über Wochen oder Monate hinziehen
  • Abbau der Quelle

Der Aufwand ist deutlich höher.
Verfügbarkeit

Downtime des Forest muss eingeplant werden

Downtime für Einzeldienste oder einzelne Postfächer.
DC

Bestehende DCs werden weiter genutzt

Neue zusätzliche DCs sind erforderlich. Trusts und zusätzliche Namensauflösung.
DNS
DHCP
WINS

Bleiben erhalten

Müssen neu aufgebaut und die Daten übernommen werden.
Gruppen-
richtlinien

Bleiben zum Teil erhalten

Müssen neu aufgebaut werden. Change für Neuanfang aber auch Risiko, dass was vergessen wird, wenn es nicht dokumentiert war
SID
ACL
Password

Bleiben erhalten

SID und Kennwort können per ADMT übernommen werden (SIDHistory). Später eventuell Anpassung der ACLs auf den Servern ratsam um von der SIDHistory unabhängig zu sein
Exchange

Nur mit Exchange 2003 möglich. Daten bleiben erhalten. Keine Datenbewegung

Umfangreiche Koexistenz mit Prepare-Moverequest und ADMT. Verschieben der Postfachinhalte. Daten werden physikalisch bewegt.
Zusätzliche Server und Storage erforderlich
Dateiserver

Bleiben erhalten

Server werden mit ADMT verschoben.
Druckdienste

Server bleibt erhalten.

Server kann samt Rechte mit ADMT übernommen werden. Verknüpfungen auf Clients bleiben bei gleichem Servernamen erhalten. SIDHistory erlaubt CrossForest Nutzung.
Lizenzen

Keine Veränderung. 3rd Party Produkte mit Bindung an Domänenamen müssen angepasst werden.

Keine Veränderung. 3rd Party Produkte mit Bindung an Domänenamen müssen angepasst werden.
Clients

Alle PCs müssen während der Migration zweimal gebootet werden. Gut, wer mit WOL und SCCM hier diese Aktionen zentral steuern kann.

PCs werden geplant mit ADMT umgezogen. Dies muss nicht auf einmal erfolgen. Oft wird es mit einem Rollout einer neuen Clientgeneration und Software verbunden.

Und das ist nur eine Teilmenge. Es gibt noch eine ganze Menge weiterer Komponente wie z.B. Zertifizierungsstellen, RMS-Server, Radius-Server für 802.1x, Webserver mit Kerberos Delegation und Dienstkonten mit SPN, Bitlocker, Smartcard-Anmeldungen und vieles mehr. Ich denke niemand kann 100% die Auswirkungen der beiden Migrationswege vorab abschätzen. Insofern bleibt immer ein Risiko, dass ein Dienst nach der Umstellung nicht gleich wieder funktioniert oder nur mit Hilfe des Herstellers wieder funktionsfähig gesetzt werden kann. Bei dieser Betrachtung hat eine Cross-Org Migration zwar den Malus, dass Sie länger dauert und sicher viel mehr Zeit und Aufwand bedeutet, aber dass die Migration schrittweise erfolgen kann und das Risiko damit geringer erscheint.

Für Exchange gibt es ja so Tricks, dass eine Exchange 2007/2010 Datenbank auch in einer komplett neuen Umgebung wieder "online" gesetzt werden kann, solange der Name der "Organisation" gleich ist. Der kann beim Setup aber angegeben werden. Exchange 2007/2010 nutzt nicht mehr das Dienstkonto. So könnte man auch überlegen, die Exchange 2007/2010 Datenbanken und Benutzereinstellungen zu "sichern", dann Exchange komplett zu "deinstallieren" und den Rename durchzuführen und danach Exchange wieder als "Desaster Recovery" bereit zu stellen.

Sie sehen, die Entscheidung für den passenden Weg ist sicher nicht mal eben gefällt. Sicher wird eine kleine Firma mit einer Domäne und überschaubaren Diensten vielleicht den Weg des Domain Rename vorziehen, zumindest wenn Exchange 2003 und Windows 2003 zum Einsatz kommt. Ob andere Firmen ihre Umgebung auf diesen Stand zurecht rücken oder gleich den "Cross-Org"-Weg gehen, lässt sich erst nach einer Analyse abschätzen.

Weitere Links