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. |
|
firma.intern. |
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. |
|
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. |
|
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. |
|
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 |
|
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.
- 300684 Information about configuring Active Directory domains by using single-label DNS names
- Product
Compatibility page on the DNS Namespace Planning Solution Center
http://support.microsoft.com/gp/gp_namespace_master#tab4
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:
Der Aufwand bewegt sich meist in Tagen oder wenige Wochen. |
Die Umstellung gliedert sich in vier Phasen:
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. |
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
- Namenswahl
- DNS
- Lync Deployment
- LyncWebservice
- Single-Labeled Domain Names
and Exchange 2007 SP1
http://technet.microsoft.com/en-us/library/cc788134(v=exchg.80).aspx - How Domain Rename Works
http://technet.microsoft.com/en-us/library/cc738208(v=ws.10).aspx - 2379369 Microsoft Lync and Microsoft Office Communications Server compatibility with Single Label Domains, Disjointed Namespaces, and Discontiguous Namespaces
- 241980 Description of Valid Labels für Domain Name System
- 300684 Information about configuring Windows für domains with
single-label DNS names
Not Supported with Exchange 2007. Kein SP1 möglich - 254680 DNS namespace planning
- 294785 New group policies für DNS in Windows Server 2003
- 2002584 unable to select DNS Server role when adding a domain controller into an existing Active Directory domain
- 2992634 Warnings when promoting Windows Server 2008 and Windows Server 2008 R2 DCPROMO in domains with single-label DNS names
- ADMT
Guide: Migrating and Restructuring Active Directory Domains
http://technet.microsoft.com/en-us/library/cc974332(WS.10).aspx - Active Directory Migration Tool (ADMT) Guide: Migrating and Restructuring Active
Directory Domains
http://www.microsoft.com/downloads/details.aspx?familyid=6D710919-1BA5-41CA-B2F3-C11BCB4857AF&displaylang=en - Active Directory Migration Tool version 3.1
http://www.microsoft.com/downloads/details.aspx?familyid=AE279D01-7DCA-413C-A9D2-B42DFB746059&displaylang=en - Active Directory Migration Tool version 3.2
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=20c0db45-db16-4d10-99f2-539b7277ccdb - Product
Compatibility page on the DNS Namespace Planning Solution Center
http://support.microsoft.com/gp/gp_namespace_master#tab4 - Active Directory: Wie soll
das neue Active Directory
heißen?
https://www.frankysweb.de/active-directory-name-fr-ein-neues-active-directory/ - Ace Directory, Exchange and Windows
Infrastructure Services Blog:
Domain Rename With or Without
Exchange
http://msmvps.com/blogs/acefekay/archive/2009/08/19/domain-rename-with-or-without-exchange.aspx