11
AD-Umbenennung und AD-Level-Erhöhung vor AD-Migration
Hallochen Gemeinde!
Ausgangssituation:
1. SBS2011-AD-Domäne, die ihren Ursprung bei SBS2003R2 und ausschließlich das Level "Windows 2008R2" hat. Nach den damaligen Vorgaben von Microsoft lautet der interne Domain Name auf mydomain.local, während der externe Domain Name auf mydomain.de hört. Die externe Domäne wird praktisch nur für den Mail-Verkehr und die Webseite genutzt (beides über einen Hoster).
2. Beabsichtigt ist die vollständige Migration der Domain nach Linux/Samba. Die Domäne als solche soll beibehalten werden. Nach den Vorgaben von samba.org hat das dortige Tool für den Wechsel des Domain Name keinen dauerhaften Produktivstatus. Aber in der Windowswelt ist das ein "alter Hut", auch wenn das bei einem SBS deaktiviert ist.
3. Überdies können nach derzeitigem Stand nur dann Windows Server ab 2012 als Domaincontroller zu einer Samba-Domäne hinzugefügt werden, wenn wegen des Erfordernisses des WMI-Protokolls bereits ein Windows Server (>= 2008R2) DC ist, vgl. https://wiki.samba.org/index.php/Joining_a_Windows_Server_2012_/_2012_R2 ....
4. Ein Samba DC ist bereits in die Domäne aufgenommen und steht als zweiter integrierter DNS-Server zur Verfügung.
Ziele:
1. Wechsel des internen Domain Name, um die Kollision der TLD .local mit zeroconf zu beseitigen.
2. Migration nach Samba AD ohne einen Verbleib von Windows Servern als Domaincontroller.
Konzeptionell beabsichtigte Vorgehensweise:
1. Es wird (kurzzeitig) ein zweiter Windows Server in der Domäne als DC aufgenommen, so dass sämtliche FSMO-Rollen vom SBS auf diesen Windows DC übertragen werden können. Hierfür kann ein Windows Server 2008R2, 2012R2 oder 2016 verwendet werden. Der SBS wird danach aus der Domäne entfernt. Insgesamt gemäß dem üblichen Vorgehen für die Migration einer SBS2011-Domäne auf einen "normalen" Windows Server.
2. Umbenennung des Domain Name. Eventuelle Anpassung der manuellen/statischen Einstellungen auf den Member-Servern/-Clients. Gegebenenfalls noch Heraufstufen der Domäne auf das Level 69 (2012R2).
3. Übergabe der FSMO-Rollen vom Windows Server auf einen Samba DC. Sodann das Herabstufen des Windows Servers und dessen Entfernen aus der Domäne.
Ein zweiter Samba DC wird wohl noch vor Schritt 1. hinzugefügt werden.
Das beabsichtigte Vorgehen will ich unter anderem im Hinblick auf die Änderung des Domain Name vorab diskutieren. Denn auch wenn bisher die interne Verwendung von .local keine feststellbaren Probleme offenbarte, ist das auf Seiten von Samba als DNS-Server involvierte bind9 bekanntlich sehr streng, was die Einhaltung von Förmlichkeiten angeht. So spricht nach umfangreicher Recherche und Untersuchung etwas dafür, dass das unter Samba DC (Bind9 DLZ) mit RSAT-DNS-Manager administrieren beschriebene Problem von der Kollision mit zeroconf herrühren könnte.
Als best practice für den internen Domain Name wird wegen des Mangels einer reservierten TLD für den internen LAN-Bereich wohl angesehen, auf einen regulären externen Domain Name zu setzen und diesen um einen Third-Level wie "intern", "lan" etc. zu erweitern. Hingegen hatte die frühere Vorgabe von Microsoft durchaus ihren Charme für die Abgrenzung von extern und intern, zumal beispielsweise der interne Domain Name kurz gehalten werden konnte. Aber selbst solche naheliegenden Alternativen wie .lan birgen ein hohes Risiko, über Kurz oder Lang das Schicksal von .local zu teilen. Was sollte demnach bei der Abwägung der Bestimmung des künftigen Domain Name vor allem in perspektivischer Hinsicht bedacht werden?
Wird für die externe und interne Verwendung derselbe Domain Name gewählt, ohne dass der extern zuständige DNS-Server (beim Hoster) kontrolliert wird, stellt sich die weitere Frage, wie die IP der extern gehosteten gleichnamigen Webseite auch von intern sicher aufgelöst werden kann. Das würde ja mit der internen Auflösung des Domain Name mit Verweis auf die internen DC's konkurrieren. Von den drei Zonen-Typen (Primär/Sekundär/Stub) verbleibt wegen der fehlenden Kontrolle des extern zuständigen DNS-Servers wohl nur der Typ "Primäre Zone". Was wäre in diesem Zusammenhang zu bedenken, wenn in ferner Zukunft die Möglichkeit der Übernahme der externen Zuständigkeit erwogen werden würde?
Dessen ungeachtet: Das höchste AD-Level bei Samba ist derzeit Windows 2012R2 (69). Wann höhere AD-Level unterstützt werden, ist derzeit nicht abzusehen, obschon daran wohl für Windows 2016 gearbeitet wird und eine teilweise Implementation schon erfolgt sein soll. Sollte zu einem späteren Zeitpunkt das Bedürfnis entstehen, wieder einen Windows Server ( > 2008R2) als DC in die Domäne aufzunehmen, bestünde Stand heute zunächst die oben genannte WMI-Problematik. Kann eigentlich ein Windows 2008R2 als DC in eine Domäne mit einem Level > 2008R2 aufgenommen werden, wie der Workaround von samba.org als Zwischenschritt vorschlägt, um sodann einen Windows (>=) 2012R2 als DC aufnehmen zu können?
Neben dieser WMI-Problematik besteht seit Windows Server 2012R2 das Erfordernis, dass das Schema- und das Preparation-Level auf das Niveau des zu verwendenden Windows Servers erhöht werden muss beziehungsweise diese Erhöhung bei der AD-Einbindung automatisch erfolgt. Wie verhält sich ein SBS2011 bei dieser Level-Erhöhung? Welche Probleme sind zu erwarten beziehungsweise wie können diese im Voraus vermieden werden? Stellt sich dann nicht wegen des höheren AD-Levels für den Verbleib der Samba DC dieselbe Frage wie beim Windows Server 2008R2? Oder ist das wegen der generellen Abwärtskompatibilität der AD-Level in beiden Fällen unproblematisch?
Vielen Dank für Tipps, Erfahrungen und Anregungen im Voraus.
HansDampf06
Ausgangssituation:
1. SBS2011-AD-Domäne, die ihren Ursprung bei SBS2003R2 und ausschließlich das Level "Windows 2008R2" hat. Nach den damaligen Vorgaben von Microsoft lautet der interne Domain Name auf mydomain.local, während der externe Domain Name auf mydomain.de hört. Die externe Domäne wird praktisch nur für den Mail-Verkehr und die Webseite genutzt (beides über einen Hoster).
2. Beabsichtigt ist die vollständige Migration der Domain nach Linux/Samba. Die Domäne als solche soll beibehalten werden. Nach den Vorgaben von samba.org hat das dortige Tool für den Wechsel des Domain Name keinen dauerhaften Produktivstatus. Aber in der Windowswelt ist das ein "alter Hut", auch wenn das bei einem SBS deaktiviert ist.
3. Überdies können nach derzeitigem Stand nur dann Windows Server ab 2012 als Domaincontroller zu einer Samba-Domäne hinzugefügt werden, wenn wegen des Erfordernisses des WMI-Protokolls bereits ein Windows Server (>= 2008R2) DC ist, vgl. https://wiki.samba.org/index.php/Joining_a_Windows_Server_2012_/_2012_R2 ....
4. Ein Samba DC ist bereits in die Domäne aufgenommen und steht als zweiter integrierter DNS-Server zur Verfügung.
Ziele:
1. Wechsel des internen Domain Name, um die Kollision der TLD .local mit zeroconf zu beseitigen.
2. Migration nach Samba AD ohne einen Verbleib von Windows Servern als Domaincontroller.
Konzeptionell beabsichtigte Vorgehensweise:
1. Es wird (kurzzeitig) ein zweiter Windows Server in der Domäne als DC aufgenommen, so dass sämtliche FSMO-Rollen vom SBS auf diesen Windows DC übertragen werden können. Hierfür kann ein Windows Server 2008R2, 2012R2 oder 2016 verwendet werden. Der SBS wird danach aus der Domäne entfernt. Insgesamt gemäß dem üblichen Vorgehen für die Migration einer SBS2011-Domäne auf einen "normalen" Windows Server.
2. Umbenennung des Domain Name. Eventuelle Anpassung der manuellen/statischen Einstellungen auf den Member-Servern/-Clients. Gegebenenfalls noch Heraufstufen der Domäne auf das Level 69 (2012R2).
3. Übergabe der FSMO-Rollen vom Windows Server auf einen Samba DC. Sodann das Herabstufen des Windows Servers und dessen Entfernen aus der Domäne.
Ein zweiter Samba DC wird wohl noch vor Schritt 1. hinzugefügt werden.
Das beabsichtigte Vorgehen will ich unter anderem im Hinblick auf die Änderung des Domain Name vorab diskutieren. Denn auch wenn bisher die interne Verwendung von .local keine feststellbaren Probleme offenbarte, ist das auf Seiten von Samba als DNS-Server involvierte bind9 bekanntlich sehr streng, was die Einhaltung von Förmlichkeiten angeht. So spricht nach umfangreicher Recherche und Untersuchung etwas dafür, dass das unter Samba DC (Bind9 DLZ) mit RSAT-DNS-Manager administrieren beschriebene Problem von der Kollision mit zeroconf herrühren könnte.
Als best practice für den internen Domain Name wird wegen des Mangels einer reservierten TLD für den internen LAN-Bereich wohl angesehen, auf einen regulären externen Domain Name zu setzen und diesen um einen Third-Level wie "intern", "lan" etc. zu erweitern. Hingegen hatte die frühere Vorgabe von Microsoft durchaus ihren Charme für die Abgrenzung von extern und intern, zumal beispielsweise der interne Domain Name kurz gehalten werden konnte. Aber selbst solche naheliegenden Alternativen wie .lan birgen ein hohes Risiko, über Kurz oder Lang das Schicksal von .local zu teilen. Was sollte demnach bei der Abwägung der Bestimmung des künftigen Domain Name vor allem in perspektivischer Hinsicht bedacht werden?
Wird für die externe und interne Verwendung derselbe Domain Name gewählt, ohne dass der extern zuständige DNS-Server (beim Hoster) kontrolliert wird, stellt sich die weitere Frage, wie die IP der extern gehosteten gleichnamigen Webseite auch von intern sicher aufgelöst werden kann. Das würde ja mit der internen Auflösung des Domain Name mit Verweis auf die internen DC's konkurrieren. Von den drei Zonen-Typen (Primär/Sekundär/Stub) verbleibt wegen der fehlenden Kontrolle des extern zuständigen DNS-Servers wohl nur der Typ "Primäre Zone". Was wäre in diesem Zusammenhang zu bedenken, wenn in ferner Zukunft die Möglichkeit der Übernahme der externen Zuständigkeit erwogen werden würde?
Dessen ungeachtet: Das höchste AD-Level bei Samba ist derzeit Windows 2012R2 (69). Wann höhere AD-Level unterstützt werden, ist derzeit nicht abzusehen, obschon daran wohl für Windows 2016 gearbeitet wird und eine teilweise Implementation schon erfolgt sein soll. Sollte zu einem späteren Zeitpunkt das Bedürfnis entstehen, wieder einen Windows Server ( > 2008R2) als DC in die Domäne aufzunehmen, bestünde Stand heute zunächst die oben genannte WMI-Problematik. Kann eigentlich ein Windows 2008R2 als DC in eine Domäne mit einem Level > 2008R2 aufgenommen werden, wie der Workaround von samba.org als Zwischenschritt vorschlägt, um sodann einen Windows (>=) 2012R2 als DC aufnehmen zu können?
Neben dieser WMI-Problematik besteht seit Windows Server 2012R2 das Erfordernis, dass das Schema- und das Preparation-Level auf das Niveau des zu verwendenden Windows Servers erhöht werden muss beziehungsweise diese Erhöhung bei der AD-Einbindung automatisch erfolgt. Wie verhält sich ein SBS2011 bei dieser Level-Erhöhung? Welche Probleme sind zu erwarten beziehungsweise wie können diese im Voraus vermieden werden? Stellt sich dann nicht wegen des höheren AD-Levels für den Verbleib der Samba DC dieselbe Frage wie beim Windows Server 2008R2? Oder ist das wegen der generellen Abwärtskompatibilität der AD-Level in beiden Fällen unproblematisch?
Vielen Dank für Tipps, Erfahrungen und Anregungen im Voraus.
HansDampf06
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 622979
Url: https://administrator.de/contentid/622979
Printed on: April 16, 2024 at 12:04 o'clock
11 Comments
Latest comment
Sers,
schau dir lieber mal genau an was eigentlich alles im AD konfiguriert ist (Benutzer, Gruppen, Datei/Freigabestruktur, DFS, GPOs, Exchange, etc) und überleg dir wie viel Zeit es dich kosten würde das ganze sauber von 0 an aufzuziehen. Das ist der bessere Weg.
rendom.exe ist der Pfad in die Altlasten, unerklärlichen Fehler und sonstigen Sonderfällen.
Benutzer, Gruppen und Rechtestrukturen, Freigaben lassen sich skripten, diverse andere Themen ebenso. Das kannst du selbst am Besten beurteilen.
Ansonsten:
[https://www.faq-o-matic.net/2020/07/02/ad-domne-umbenennen-was-man-dazu-wissen-sollte/ FAQ-O-MATIC:
AD-Domäne umbenennen: Was man dazu wissen sollte]
msxfaq.de: Domain Rename
Der SBS2011 basiert auf einem Windows Server 2008R2, kann also maximal mit AD Funktionsniveau 2008R2 arbeiten. Solange der SBS2011 eine DC Rolle in der Domäne ausführt kannst du das Funktionsniveau der Domäne nicht über 2008R2 anheben.
Für Domänenfunktionsniveau 2012R2 müssen alle Windows Server Domänencontroller auf Windows Server Version 2012R2 oder höher laufen.
Ein nachträgliches Absenken ist nicht möglich.
Grüße,
Philip
schau dir lieber mal genau an was eigentlich alles im AD konfiguriert ist (Benutzer, Gruppen, Datei/Freigabestruktur, DFS, GPOs, Exchange, etc) und überleg dir wie viel Zeit es dich kosten würde das ganze sauber von 0 an aufzuziehen. Das ist der bessere Weg.
rendom.exe ist der Pfad in die Altlasten, unerklärlichen Fehler und sonstigen Sonderfällen.
Benutzer, Gruppen und Rechtestrukturen, Freigaben lassen sich skripten, diverse andere Themen ebenso. Das kannst du selbst am Besten beurteilen.
Ansonsten:
[https://www.faq-o-matic.net/2020/07/02/ad-domne-umbenennen-was-man-dazu-wissen-sollte/ FAQ-O-MATIC:
AD-Domäne umbenennen: Was man dazu wissen sollte]
msxfaq.de: Domain Rename
Der SBS2011 basiert auf einem Windows Server 2008R2, kann also maximal mit AD Funktionsniveau 2008R2 arbeiten. Solange der SBS2011 eine DC Rolle in der Domäne ausführt kannst du das Funktionsniveau der Domäne nicht über 2008R2 anheben.
Für Domänenfunktionsniveau 2012R2 müssen alle Windows Server Domänencontroller auf Windows Server Version 2012R2 oder höher laufen.
Ein nachträgliches Absenken ist nicht möglich.
Grüße,
Philip
Moin
Kurz und Knapp. Das Zauberwort heißt Split-DNS. Im Prinzip gibst du hier deinem DNS in der Domäne die IPs mit, die er extern abfragen soll. Wenn du also alles bis auf www.deinedomäne.de intern hast, dann musst du nur www im DNS auf die externe Adresse umleiten und schon kann auch die Externe Website von intern geöffnet werden, während alles andere wie mailserver.deinedomäne.de richtig auf den internen Mail Server umgeleitet wird (da den dein DC ja kennt). Schon mehrfach gemacht.
Gruß
Doskias
Zitat von @HansDampf06:
Wird für die externe und interne Verwendung derselbe Domain Name gewählt, ohne dass der extern zuständige DNS-Server (beim Hoster) kontrolliert wird, stellt sich die weitere Frage, wie die IP der extern gehosteten gleichnamigen Webseite auch von intern sicher aufgelöst werden kann. Das würde ja mit der internen Auflösung des Domain Name mit Verweis auf die internen DC's konkurrieren. Von den drei Zonen-Typen (Primär/Sekundär/Stub) verbleibt wegen der fehlenden Kontrolle des extern zuständigen DNS-Servers wohl nur der Typ "Primäre Zone". Was wäre in diesem Zusammenhang zu bedenken, wenn in ferner Zukunft die Möglichkeit der Übernahme der externen Zuständigkeit erwogen werden würde?
Wird für die externe und interne Verwendung derselbe Domain Name gewählt, ohne dass der extern zuständige DNS-Server (beim Hoster) kontrolliert wird, stellt sich die weitere Frage, wie die IP der extern gehosteten gleichnamigen Webseite auch von intern sicher aufgelöst werden kann. Das würde ja mit der internen Auflösung des Domain Name mit Verweis auf die internen DC's konkurrieren. Von den drei Zonen-Typen (Primär/Sekundär/Stub) verbleibt wegen der fehlenden Kontrolle des extern zuständigen DNS-Servers wohl nur der Typ "Primäre Zone". Was wäre in diesem Zusammenhang zu bedenken, wenn in ferner Zukunft die Möglichkeit der Übernahme der externen Zuständigkeit erwogen werden würde?
Kurz und Knapp. Das Zauberwort heißt Split-DNS. Im Prinzip gibst du hier deinem DNS in der Domäne die IPs mit, die er extern abfragen soll. Wenn du also alles bis auf www.deinedomäne.de intern hast, dann musst du nur www im DNS auf die externe Adresse umleiten und schon kann auch die Externe Website von intern geöffnet werden, während alles andere wie mailserver.deinedomäne.de richtig auf den internen Mail Server umgeleitet wird (da den dein DC ja kennt). Schon mehrfach gemacht.
Gruß
Doskias
Ausgangssituation:
1. SBS2011-AD-Domäne, die ihren Ursprung bei SBS2003R2 und ausschließlich das Level "Windows 2008R2" hat. Nach den damaligen Vorgaben von Microsoft lautet der interne Domain Name auf mydomain.local, während der externe Domain Name auf mydomain.de hört. Die externe Domäne wird praktisch nur für den Mail-Verkehr und die Webseite genutzt (beides über einen Hoster).
2. Beabsichtigt ist die vollständige Migration der Domain nach Linux/Samba. Die Domäne als solche soll beibehalten werden. Nach den Vorgaben von samba.org hat das dortige Tool für den Wechsel des Domain Name keinen dauerhaften Produktivstatus. Aber in der Windowswelt ist das ein "alter Hut", auch wenn das bei einem SBS deaktiviert ist.
1. SBS2011-AD-Domäne, die ihren Ursprung bei SBS2003R2 und ausschließlich das Level "Windows 2008R2" hat. Nach den damaligen Vorgaben von Microsoft lautet der interne Domain Name auf mydomain.local, während der externe Domain Name auf mydomain.de hört. Die externe Domäne wird praktisch nur für den Mail-Verkehr und die Webseite genutzt (beides über einen Hoster).
2. Beabsichtigt ist die vollständige Migration der Domain nach Linux/Samba. Die Domäne als solche soll beibehalten werden. Nach den Vorgaben von samba.org hat das dortige Tool für den Wechsel des Domain Name keinen dauerhaften Produktivstatus. Aber in der Windowswelt ist das ein "alter Hut", auch wenn das bei einem SBS deaktiviert ist.
Ziele:
1. Wechsel des internen Domain Name, um die Kollision der TLD .local mit zeroconf zu beseitigen.
2. Migration nach Samba AD ohne einen Verbleib von Windows Servern als Domaincontroller.
1. Wechsel des internen Domain Name, um die Kollision der TLD .local mit zeroconf zu beseitigen.
2. Migration nach Samba AD ohne einen Verbleib von Windows Servern als Domaincontroller.
Diese Zielerreichung sehe ich bei der jetzigen Umgebung nicht. Sowohl die Umbenennung der Windows Domäne als auch die vollständige Migration auf Samba dürfte durch den vorhandenen Exchange Server ausgeschlossen sein.
Der Exchange-Server ist seit über einem halben Jahr vollständig deaktiviert und spielt keine Rolle mehr. Es fehlt nur noch seine Deinstallation, die in den nächsten Tagen erfolgen wird. Horde Groupware / postfix / dovecot läuft seither mit sehr großer Zufriedenheit und absolut stabil. Das war übrigens der erste wichtig(st)e Meilenstein, um überhaupt Samba ernsthaft ins Auge fassen zu können. Ein Gang in die Cloud war, ist und bleibt keine Option ...
Bei der Verwendung des externen Domain Name mit vorangestelltem "www." ist das unproblematisch. Aber die Website ist auch "nackt" ohne "www." erreichbar. Das würde dann einerseits unweigerlich zugleich auf die intern eingetragenen DC führen und andererseits würden Anfragen betreffend das interne AD zugleich auf die externen IP-Adressen zeigen. Und wenn ich die aktuelle interne Domain im DNS-Server betrachte, tragen sich beide DC's automatisch als A/AAAA-Host auf den Domain Name ein. Genau hier liegt das Problem, das mich umtreibt und wofür ich derzeit keine Lösung sehe, es sei denn, ich würde entweder eine ThirdLD für intern verwenden oder doch wieder eine abweichende "irre/kryptische" TLD.
Freilich das alles mit der Maßgabe, dass beispielsweise die extern (fremd)gehostete Webseite auch von intern erreichbar sein soll. Ist das nicht erforderlich, lösst sich die Problematik in Luft auf.
PS: Ich habe das Split-DNS natürlich testweise probiert und die externe Domäne intern als interne primäre Zone erstellt. Ich lande dann erwartungsgemäß auf dem internen IIS des SBS2011, und zwar auch dann, wenn ich die externen IP-Adressen ordnungsgemäß erfasst habe. Kein anderes Ergebnis habe ich erwartet.
Freilich das alles mit der Maßgabe, dass beispielsweise die extern (fremd)gehostete Webseite auch von intern erreichbar sein soll. Ist das nicht erforderlich, lösst sich die Problematik in Luft auf.
PS: Ich habe das Split-DNS natürlich testweise probiert und die externe Domäne intern als interne primäre Zone erstellt. Ich lande dann erwartungsgemäß auf dem internen IIS des SBS2011, und zwar auch dann, wenn ich die externen IP-Adressen ordnungsgemäß erfasst habe. Kein anderes Ergebnis habe ich erwartet.
Wenn ich wesentliche Parameter für weiterhin benötigte Objekte wie insbesondere die Benutzer-ID und Gruppen-ID's vom alten AD ins neue AD übernehmen könnte ... Gäbe es denn - ins Unreine gesprochen - ein "Tool" mit dem solche Parameter aus einem alten AD extrahiert werden können, um auf deren Basis die Struktur im neuen AD aufbauen zu können? Bisher habe ich keinen Hinweis darauf gefunden.
Für die Entscheidung, ob Umbenennung oder neue Domäne, geht es letztlich um die Frage: Welche Anpassungen müssen ohnehin in beiden Fällen vorgenommen werden? Wie sieht das beispielsweise mit SPN-Einträgen aus? Welchen identischen manuellen Nachbearbeitungsbedarf hätten demnach beide Varianten ohnehin (Freigaben; ACL; Benutzer; Gruppen; auf Member-Servern/-Clients ...)? Was ist hier die Erfahrung an erforderlichen Nacharbeiten?
Die beiden Links bei faq-o-matic und msxfaq sind mir bestens bekannt. Mir geht es - gerade durch die beiden Links inspiriert - beim künftigen Domain Name mehr um den konzeptionellen Blick in die Zukunft, um nicht in wenigen Jahren wieder einen Wechsel des Domain Name erwägen zu müssen. Wichtig ist mir hierbei die sinnvolle Abgrenzung zwischen extern und intern bei der Namensauflösung, wenn TLD und SLD identisch sind, aber der externe Bereich nicht beherrscht wird. Geht es dann intern überhaupt ohne ThirdLD, wenn keine Kollisionen provoziert werden sollen?
AD-Level: Der vorhin gefundene letzte Beitrag bei https://social.technet.microsoft.com/Forums/ie/de-DE/a96d425f-5db5-43eb- ... bringt es auf den Punkt für das Hinzufügen eines Windows 2012R2-DC in eine SBS2011-Domäne:
"das ist problemlos möglich. Man kann nur keinen weiteren SBS dazuhängen.
Das Schema-Update wird daher auch keine Probleme verursachen. Du darfst nur die Funktionsebene der Domäne nicht auf 2012 updaten, weil Du sonst den SBS als DC rausschmeißt."
Und selbstredend gilt das für jeden anderen Windows 2008R2.
Damit habe ich jetzt restlose Klarheit, unter welchen Voraussetzungen zu einem späteren Zeitpunkt nochmals einen Windows 2008R2 hinzugefügt werden kann oder nicht. Keines der drei Level darf höher als 2008R2 sein; ein auch nur teilweise höheres Level verhindert bereits den Join eines Windows 2008R2. In der Konsequenz schließt die vorherige Level-Erhöhung (> 2008R2) die spätere Einbindung eines Windows DC (>= 2012R2) in ein Samba AD solange aus, solange entweder kein anderer aktiver Windows DC im Samba AD vorhanden ist oder Samba das WMI-Protokoll nicht beherrscht. Bis dahin ist die Migration des Active Directory auf (nur) Samba endgültig und ohne Rückkehrmöglichkeit zu Windows als DC. [Als Member-Server ist Windows freilich jederzeit möglich.]
Hieraus stellt sich folgende Ergänzungsfrage: Welche bedeutsamen Gründe kann es geben, dass später eine Schema-Erhöhung und / oder die Hinzufügung eines Windows DC erforderlich werden könnte? Doch eigentlich (1.) nur bei spezieller Software wie zum Beispiel Exchange. Exchange ist hier aber bereits seit Monaten aus dem Rennen. Und (2.), wenn das Upgrade eines Windows DC auf eine neuere Version nach dem Willen von Microsoft eine Schema-Erhöhung unumgänglich macht, bei der Samba nicht mithalten könnte. Mit dem Wechsel auf (nur) Samba ist (2.) irrelevant. Welches sonstige Szenario könnte es geben für die Notwendigkeit einer Schema-Erhöhung?
Für die Entscheidung, ob Umbenennung oder neue Domäne, geht es letztlich um die Frage: Welche Anpassungen müssen ohnehin in beiden Fällen vorgenommen werden? Wie sieht das beispielsweise mit SPN-Einträgen aus? Welchen identischen manuellen Nachbearbeitungsbedarf hätten demnach beide Varianten ohnehin (Freigaben; ACL; Benutzer; Gruppen; auf Member-Servern/-Clients ...)? Was ist hier die Erfahrung an erforderlichen Nacharbeiten?
Die beiden Links bei faq-o-matic und msxfaq sind mir bestens bekannt. Mir geht es - gerade durch die beiden Links inspiriert - beim künftigen Domain Name mehr um den konzeptionellen Blick in die Zukunft, um nicht in wenigen Jahren wieder einen Wechsel des Domain Name erwägen zu müssen. Wichtig ist mir hierbei die sinnvolle Abgrenzung zwischen extern und intern bei der Namensauflösung, wenn TLD und SLD identisch sind, aber der externe Bereich nicht beherrscht wird. Geht es dann intern überhaupt ohne ThirdLD, wenn keine Kollisionen provoziert werden sollen?
AD-Level: Der vorhin gefundene letzte Beitrag bei https://social.technet.microsoft.com/Forums/ie/de-DE/a96d425f-5db5-43eb- ... bringt es auf den Punkt für das Hinzufügen eines Windows 2012R2-DC in eine SBS2011-Domäne:
"das ist problemlos möglich. Man kann nur keinen weiteren SBS dazuhängen.
Das Schema-Update wird daher auch keine Probleme verursachen. Du darfst nur die Funktionsebene der Domäne nicht auf 2012 updaten, weil Du sonst den SBS als DC rausschmeißt."
Und selbstredend gilt das für jeden anderen Windows 2008R2.
Damit habe ich jetzt restlose Klarheit, unter welchen Voraussetzungen zu einem späteren Zeitpunkt nochmals einen Windows 2008R2 hinzugefügt werden kann oder nicht. Keines der drei Level darf höher als 2008R2 sein; ein auch nur teilweise höheres Level verhindert bereits den Join eines Windows 2008R2. In der Konsequenz schließt die vorherige Level-Erhöhung (> 2008R2) die spätere Einbindung eines Windows DC (>= 2012R2) in ein Samba AD solange aus, solange entweder kein anderer aktiver Windows DC im Samba AD vorhanden ist oder Samba das WMI-Protokoll nicht beherrscht. Bis dahin ist die Migration des Active Directory auf (nur) Samba endgültig und ohne Rückkehrmöglichkeit zu Windows als DC. [Als Member-Server ist Windows freilich jederzeit möglich.]
Hieraus stellt sich folgende Ergänzungsfrage: Welche bedeutsamen Gründe kann es geben, dass später eine Schema-Erhöhung und / oder die Hinzufügung eines Windows DC erforderlich werden könnte? Doch eigentlich (1.) nur bei spezieller Software wie zum Beispiel Exchange. Exchange ist hier aber bereits seit Monaten aus dem Rennen. Und (2.), wenn das Upgrade eines Windows DC auf eine neuere Version nach dem Willen von Microsoft eine Schema-Erhöhung unumgänglich macht, bei der Samba nicht mithalten könnte. Mit dem Wechsel auf (nur) Samba ist (2.) irrelevant. Welches sonstige Szenario könnte es geben für die Notwendigkeit einer Schema-Erhöhung?
Zunächst einmal Danke für die bisherigen Anregungen.
Diese haben mich bei der weiteren Auseinandersetzung mit der Thematik auf folgende Diskussion geführt: https://www.mcseboard.de/topic/218240-ad-dom%C3%A4ne-umbenennen/. Anhand dessen ergeben sich für mich folgende Schlussfolgerungen.
In dem dortigen Fall sind der externe und der interne Domain Name identisch. Das wird als kritisch gesehen, weil der interne Bereich mit dem externen Bereich grundsätzlich nichts zu schaffen hat. Für den internen Bereich bieten sich vielmehr abstrakte Domain Names ohne Außenbezug an. In diesem Sinne war die alte Vorgabe von Microsoft betreffend eine unterschiedliche externe und interne Namensgebung berechtigt und ist es bis heute.
Ferner kommt eine Umbenennung / Wechsel des internen Domain Name nur bei harten technischen Gründen in Betracht. Die Kollision der aktuellen internen TLD „.local“ mit zeroconf (/mDNS) ist aus meiner Sicht aber ein harter technischer Grund, und zwar insbesondere mit Blick in die ferne Zukunft.
Es erscheint mir als vorzugswürdig und „ausreichend“, die TLD „auszutauschen“; das DNS-Problem kann dann gar nicht erst entstehen. Dafür ist aber von der direkten Umbenennung der existierenden Domäne mittels rendom.exe abzusehen, weil das letztlich zu riskant und wohl auch zu aufwendig ist. Ein solches Vorgehen ist zudem nicht erforderlich, weil die Migration aller benötigten Objekte aus dem bisherigen Forest in einen anderen Forest mittels dem ActiveDirectoryMigrationToolkit wesentlich einfacher ist. Selbst die Migration eines Exchange-Servers auf diese Weise ließe sich (viel) problemfrei(er) realisieren, käme es vorliegend darauf noch an.
Demnach muss ich mich mit dem ADMT näher beschäftigen und werde eine neue interne TLD wählen, die in der Zukunft mit hoher Wahrscheinlichkeit keine harten technischen Kollisionen erwarten lässt (mehrstellige Buchstaben-Zahlen-Kombination). Wegen des ADMT und wegen der Beschränkungen des SBS2011 führt das zunächst zu mindestens einem zusätzlichen Windows DC, der vom SBS2011 die FSMO-Rollen übernimmt. Dem folgen die Beseitigung des SBS2011 und im nächsten Schritt die Forest-Migration. Nach der Forest-Migration kann der Wechsel auf (nur) Samba vollzogen werden.
Übrigens kommt gemäß https://www.msxfaq.de/exchange/migration/admt.htm scheinbar auch eine sukzessive Forest-Migration in Betracht, was einem späteren Vollzug beim produktiven System sehr gelegen kommt.
Diese haben mich bei der weiteren Auseinandersetzung mit der Thematik auf folgende Diskussion geführt: https://www.mcseboard.de/topic/218240-ad-dom%C3%A4ne-umbenennen/. Anhand dessen ergeben sich für mich folgende Schlussfolgerungen.
In dem dortigen Fall sind der externe und der interne Domain Name identisch. Das wird als kritisch gesehen, weil der interne Bereich mit dem externen Bereich grundsätzlich nichts zu schaffen hat. Für den internen Bereich bieten sich vielmehr abstrakte Domain Names ohne Außenbezug an. In diesem Sinne war die alte Vorgabe von Microsoft betreffend eine unterschiedliche externe und interne Namensgebung berechtigt und ist es bis heute.
Ferner kommt eine Umbenennung / Wechsel des internen Domain Name nur bei harten technischen Gründen in Betracht. Die Kollision der aktuellen internen TLD „.local“ mit zeroconf (/mDNS) ist aus meiner Sicht aber ein harter technischer Grund, und zwar insbesondere mit Blick in die ferne Zukunft.
Es erscheint mir als vorzugswürdig und „ausreichend“, die TLD „auszutauschen“; das DNS-Problem kann dann gar nicht erst entstehen. Dafür ist aber von der direkten Umbenennung der existierenden Domäne mittels rendom.exe abzusehen, weil das letztlich zu riskant und wohl auch zu aufwendig ist. Ein solches Vorgehen ist zudem nicht erforderlich, weil die Migration aller benötigten Objekte aus dem bisherigen Forest in einen anderen Forest mittels dem ActiveDirectoryMigrationToolkit wesentlich einfacher ist. Selbst die Migration eines Exchange-Servers auf diese Weise ließe sich (viel) problemfrei(er) realisieren, käme es vorliegend darauf noch an.
Demnach muss ich mich mit dem ADMT näher beschäftigen und werde eine neue interne TLD wählen, die in der Zukunft mit hoher Wahrscheinlichkeit keine harten technischen Kollisionen erwarten lässt (mehrstellige Buchstaben-Zahlen-Kombination). Wegen des ADMT und wegen der Beschränkungen des SBS2011 führt das zunächst zu mindestens einem zusätzlichen Windows DC, der vom SBS2011 die FSMO-Rollen übernimmt. Dem folgen die Beseitigung des SBS2011 und im nächsten Schritt die Forest-Migration. Nach der Forest-Migration kann der Wechsel auf (nur) Samba vollzogen werden.
Übrigens kommt gemäß https://www.msxfaq.de/exchange/migration/admt.htm scheinbar auch eine sukzessive Forest-Migration in Betracht, was einem späteren Vollzug beim produktiven System sehr gelegen kommt.
Moin Hans Damp06,
zunächst einmal ein lob an dich, dass du dir die Mühe machst ausführlich zu antworten und, wie du schreibst es sogar ausprobierst. ich würde mir mehr solcher Kollegen, grade hier im Forum wünschen. nun zu deinem Post.
Grundlegende Arbeitsweise des DNS wenn du Split DNS machst: Dein DNS glaubt dann, er sei für die Domäne alleine zuständig. Die Einträge von Servern und Rechnern aktualisiert der DC bzw. dein DHCP. Und damit hat es sich dann erstmal mit dem Automatismus. Dadurch verweist dann deinedomäne.de auch auf deine Domäne und ein ping davon wird von einem der DC beantwortet.
Kann ich dir so jetzt nicht sagen was an der Stelle "falsch" gelaufen ist. ich kenne weder die Seite die du aufrufen wolltest, noch sehe ich deinen Eintrag im DNS. Ich muss allerdings gestehen, das ich persönlich noch nie Daten im DNS gepflegt habe, die NICHT gleichzeitig den Domännamen entsprochen haben. In deinem Fall müsste deine Domäne ja noch deinedomän.local sein und du hast deinedomäne.de als zusätzliche Forward-Zone eingetragen. Rein von der Logik sollte es egal sein, aber wie gesagt: so hab ich es noch nie gemacht. Nächstes "Problem" bei mir. ich hab nur mit nativen selbst installierten Servern diese Konstellation gefahren und nie mit einem SBS. Kann dir an der Stelle also nicht sagen ob der SBS sich dort ggf. anders verhält als ein nicht-SBS DC.
Viel Erfolg weiterhin bei deiner nicht all zu leichten Aufgabe.
Gruß
Doskias
zunächst einmal ein lob an dich, dass du dir die Mühe machst ausführlich zu antworten und, wie du schreibst es sogar ausprobierst. ich würde mir mehr solcher Kollegen, grade hier im Forum wünschen. nun zu deinem Post.
Zitat von @HansDampf06:
Bei der Verwendung des externen Domain Name mit vorangestelltem "www." ist das unproblematisch. Aber die Website ist auch "nackt" ohne "www." erreichbar. Das würde dann einerseits unweigerlich zugleich auf die intern eingetragenen DC führen und andererseits würden Anfragen betreffend das interne AD zugleich auf die externen IP-Adressen zeigen.
Stimmt. deinedomän.de geht auf den DC, aber: Ist es so schwer für die Mitarbeiter www.deinedomäne.de anstatt deinedomäne.de zu schreiben, wenn sie von intern die Website erreichen wollen?Bei der Verwendung des externen Domain Name mit vorangestelltem "www." ist das unproblematisch. Aber die Website ist auch "nackt" ohne "www." erreichbar. Das würde dann einerseits unweigerlich zugleich auf die intern eingetragenen DC führen und andererseits würden Anfragen betreffend das interne AD zugleich auf die externen IP-Adressen zeigen.
Und wenn ich die aktuelle interne Domain im DNS-Server betrachte, tragen sich beide DC's automatisch als A/AAAA-Host auf den Domain Name ein.
Richtig. geht ja auch nicht anders. Du solltest jedes Gerät deiner Domäne wiederfinden mit einem Host Eintrag. Anders kann die IP-Auflösung nicht funktionieren.Genau hier liegt das Problem, das mich umtreibt und wofür ich derzeit keine Lösung sehe, es sei denn, ich würde entweder eine ThirdLD für intern verwenden oder doch wieder eine abweichende "irre/kryptische" TLD.
Nein. Genau hier liegt die Lösung. Grundlegende Arbeitsweise des DNS wenn du Split DNS machst: Dein DNS glaubt dann, er sei für die Domäne alleine zuständig. Die Einträge von Servern und Rechnern aktualisiert der DC bzw. dein DHCP. Und damit hat es sich dann erstmal mit dem Automatismus. Dadurch verweist dann deinedomäne.de auch auf deine Domäne und ein ping davon wird von einem der DC beantwortet.PS: Ich habe das Split-DNS natürlich testweise probiert und die externe Domäne intern als interne primäre Zone erstellt. Ich lande dann erwartungsgemäß auf dem internen IIS des SBS2011, und zwar auch dann, wenn ich die externen IP-Adressen ordnungsgemäß erfasst habe. Kein anderes Ergebnis habe ich erwartet.
Kann ich dir so jetzt nicht sagen was an der Stelle "falsch" gelaufen ist. ich kenne weder die Seite die du aufrufen wolltest, noch sehe ich deinen Eintrag im DNS. Ich muss allerdings gestehen, das ich persönlich noch nie Daten im DNS gepflegt habe, die NICHT gleichzeitig den Domännamen entsprochen haben. In deinem Fall müsste deine Domäne ja noch deinedomän.local sein und du hast deinedomäne.de als zusätzliche Forward-Zone eingetragen. Rein von der Logik sollte es egal sein, aber wie gesagt: so hab ich es noch nie gemacht. Nächstes "Problem" bei mir. ich hab nur mit nativen selbst installierten Servern diese Konstellation gefahren und nie mit einem SBS. Kann dir an der Stelle also nicht sagen ob der SBS sich dort ggf. anders verhält als ein nicht-SBS DC.
Viel Erfolg weiterhin bei deiner nicht all zu leichten Aufgabe.
Gruß
Doskias
Danke für die Blumen!
Es gibt dabei sogar noch eine "Seitenwirkung" des Spit-DNS: Der Mail-Abruf der extern gehosteten Postfächer, die ja den externen Domain Name als Basis haben, hat Erreichbarkeitsprobleme. Dann müssen wohl auch die zugehörigen A/AAAA-Einträge für imap etc. im internen DNS-Server manuell gepflegt werden. Und wer weiß schon, was sich noch so für komische Wirkungen zeigen würden ... Leider habe ich diese Seitenwirkung erst zu einem späteren Moment gesehen, so dass ich das nicht weiter untersuchen konnte.
Sei es wie es sei! Nochmals folgt klares Credo für mich daraus: ein identischer Domain Name für beide Bereiche wird besser gelassen. Das gilt insbesondere dann, wenn der Außenbereich bei der Namensauflösung nicht beherrscht wird.
Das Nichtbeherrschen des Außenbereichs zeigt in meinem Fall beim Split-DNS zudem auf, dass diese allgemeine Praxis des Split-DNS letztlich dem Wesensgrundsatz, dass es für eine Zone nur eine federführende Zonendatei geben kann, widerspricht, vgl. https://www.comconsult.com/dns-views-und-dns-split-brain. Die Inkonsistenzen treten deutlich zutage. Und genau deshalb war für mich der identische externe und interne Domain Name bei Nichtbeherrschung des Außenbereichs intuitiv eine eher schlechte(re) Wahl. Ansonsten hätte ich das "Problem" hier nicht eingehangen.
Es gibt dabei sogar noch eine "Seitenwirkung" des Spit-DNS: Der Mail-Abruf der extern gehosteten Postfächer, die ja den externen Domain Name als Basis haben, hat Erreichbarkeitsprobleme. Dann müssen wohl auch die zugehörigen A/AAAA-Einträge für imap etc. im internen DNS-Server manuell gepflegt werden. Und wer weiß schon, was sich noch so für komische Wirkungen zeigen würden ... Leider habe ich diese Seitenwirkung erst zu einem späteren Moment gesehen, so dass ich das nicht weiter untersuchen konnte.
Sei es wie es sei! Nochmals folgt klares Credo für mich daraus: ein identischer Domain Name für beide Bereiche wird besser gelassen. Das gilt insbesondere dann, wenn der Außenbereich bei der Namensauflösung nicht beherrscht wird.
Das Nichtbeherrschen des Außenbereichs zeigt in meinem Fall beim Split-DNS zudem auf, dass diese allgemeine Praxis des Split-DNS letztlich dem Wesensgrundsatz, dass es für eine Zone nur eine federführende Zonendatei geben kann, widerspricht, vgl. https://www.comconsult.com/dns-views-und-dns-split-brain. Die Inkonsistenzen treten deutlich zutage. Und genau deshalb war für mich der identische externe und interne Domain Name bei Nichtbeherrschung des Außenbereichs intuitiv eine eher schlechte(re) Wahl. Ansonsten hätte ich das "Problem" hier nicht eingehangen.
Zitat von @HansDampf06:
Es gibt dabei sogar noch eine "Seitenwirkung" des Spit-DNS: Der Mail-Abruf der extern gehosteten Postfächer, die ja den externen Domain Name als Basis haben, hat Erreichbarkeitsprobleme. Dann müssen wohl auch die zugehörigen A/AAAA-Einträge für imap etc. im internen DNS-Server manuell gepflegt werden. Und wer weiß schon, was sich noch so für komische Wirkungen zeigen würden ... Leider habe ich diese Seitenwirkung erst zu einem späteren Moment gesehen, so dass ich das nicht weiter untersuchen konnte.
Stimmt das hatte ich bei deinem Eingangs-Posting nicht mehr im Kopf, aber prinzipiell ja geschrieben Wenn der Mailserver extern ist, dann müssen die entsprechenden Adresse (autodiscover, etc.) natürlich auch nach extern geleitet werden.Es gibt dabei sogar noch eine "Seitenwirkung" des Spit-DNS: Der Mail-Abruf der extern gehosteten Postfächer, die ja den externen Domain Name als Basis haben, hat Erreichbarkeitsprobleme. Dann müssen wohl auch die zugehörigen A/AAAA-Einträge für imap etc. im internen DNS-Server manuell gepflegt werden. Und wer weiß schon, was sich noch so für komische Wirkungen zeigen würden ... Leider habe ich diese Seitenwirkung erst zu einem späteren Moment gesehen, so dass ich das nicht weiter untersuchen konnte.
Sei es wie es sei! Nochmals folgt klares Credo für mich daraus: ein identischer Domain Name für beide Bereiche wird besser gelassen. Das gilt insbesondere dann, wenn der Außenbereich bei der Namensauflösung nicht beherrscht wird.
Du bist dann halt immer von der Gegenseite abhängig. Wenn sich bei denen dann IP-Adressen ändern, dann musst du bei dir nachziehen. Aber so häufig ändert sich das ja eigentlich nicht. In meinen Augen machbar, aber nicht zwingend erforderlich für deine Umsetzung.Wenn du allerdings einen "fiktiven" Domainnamen nutzen willst, der auf .de Ende, also zum Beispiel istnichtmeinedomain.de und deinedomain.de dann beibehalten willst, dann wärst du gut beraten den Namen entweder so kryptisch zu wählen, dass er auf keinen Fall im Internet vorkommen wird (nichts ist unmöglich) oder sich zumindest die Domain für ein paar Euro im Monat zu registrieren. Wir hatten mal einen Kunden, wo ein Systemhaus die Domäne aufgesetzt hat. Der Kunde hatte vorher keine Domäne und als bei denen SAP eingeführt wurde, hat das Systemhaus das SAP eingeführt hat gleich mal ne Domäne aufgebaut. Und weil Sie ja nur SAP machen, so hieß die Domäne dann auch SAP.de. Das dann im Nachgang grade zu ziehen, war ein heidenspaß
Meine Tendenz für den neuen internen Domain Name ist derzeit, den SLD so zu belassen, wie er ist (aktuell ist er auch extern einmalig) und nur den TLD von ".local" auf eine "irre/kryptische" Zeichenfolge zu wechseln. Denn wegen zeroconf besteht nur insoweit eine technische Notwendigkeit. Beispiele könnten ".ak4xm" oder ".a2b2c" oder ... sein. Mithin geht es um eine interne TLD, bei der die Wahrscheinlichkeit, dass sie wegen künftiger technischer Standardisierungen plötzlich wie ".local" plötzlich verbrannt sein könnte, als äußerst gering einzuschätzen ist. Landestypische oder schon jetzt registrierte TLD's scheiden natürlich von vornherein für den Innenbereich aus, weil ich andernfalls möglicherweise "vom Regen in die Traufe" komme ...