Active Directory TLD-Änderung

[Maraun 12]

Hallo zusammen,

 

unsere Umgebung besteht aus 2003er Domain- und Forestlevel, wobei nur noch ein 2003er DC abgelöst werden muss und wir dann zumindest auf 2008 hochstufen können. Knapp 200 Server, größtenteils virtuell, 1500 Clients, Exchange 2010.
Wir haben eine .ads AD-Domain, die eventuell in den freien Erwerb kommen kann. Das ist natürlich zu verhindern.

Dennoch interessiert mich die technische Lösung, falls wir tatsächlich zu einer AD-Domainumbenennung gezwungen wären.

Was ich bisher gelesen habe ist, dass Exchange 2010 damit inkompatibel ist. Was genau bedeutet das? Ich müsste Exchange komplett in einer neuen Gesamtstruktur installieren?? Oder als Alternative eine Mailweiterleitung von alter zu neuer Domäne realisieren?
Sollte doch tatsächlich (hoffentlich nicht) Fall eintreten, wäre es dann nicht besser/ratsamer, eine neue Domäne parallel aufzusetzen und alles sukzessive umzuziehen?

Kann mir jemand vielleicht bitte mal ein paar Angaben oder Erfahrungswerte dazu schreiben.

Danke vorab.
 

Gruß

Alex

[NorbertFe 2.027]

Und was hat eure interne Domain mit einer möglicherweise auch öffentlichen Domain zu tun? Im Allgemeinen nichts. Du kannst Exchange nicht deinstallieren und dann umbenennen, weil das Schema die Umbenennung verhindert (zumindest soweit ich mich daran erinnere). Also ich würde schauen, ob ihr die .ads Domain nicht einfach selber kauft. ;)

Alternativ ignorieren oder bei konkretem Bedarf in eine neue AD Struktur migrieren.

 

Bye

Norbert

[Maraun 12]

"Und was hat eure interne Domain mit einer möglicherweise auch öffentlichen Domain zu tun? Im Allgemeinen nichts."
Routing, bzw. Mailing?
Aber die Frage an für sich finde ich schon spannend bzw. berechtigt.

"Also ich würde schauen, ob ihr die .ads Domain nicht einfach selber kauft."
Das ist natürlich der ausgewiesene Plan.

"Alternativ ignorieren".

Wenn das so einfach geht, dann ist das meine bevorzugte Lösung.
 

Viele Grüße

Alex

[magheinz 110]

Ich würde auch schauen das ich die Domäne kaufe. Das ist zumindest technisch, deutlich weniger Streß.

[NorbertFe 2.027]

"Und was hat eure interne Domain mit einer möglicherweise auch öffentlichen Domain zu tun? Im Allgemeinen nichts."

Routing, bzw. Mailing?

Ist halt die Frage, ob ihr mit der Domain dann kommunizieren müßt. ;) Falls ja = kaufen oder migrieren.

 

Aber die Frage an für sich finde ich schon spannend bzw. berechtigt.

Naja so richtig spannend ist das auch nicht. ;)

 

 

 

"Alternativ ignorieren".

Wenn das so einfach geht, dann ist das meine bevorzugte Lösung.

Geht nur, wenn ihr euch bewußt seid, was das ggf. bedeutet. Da ich aber davon ausgehe, dass das für 90% der weltweiten Domains gilt die irgendwas .local heißen, sehe ich das erstmal nicht so kritisch. Hängt natürlich vom Namen davor ab. ;)

 

 

Bye

Norbert

[NilsK 2.930]

Moin,

 

ignorieren. Es ist sehr unwahrscheinlich, dass ihr jemals ein Problem damit bekommt.

 

Und sollte es tatsächlich mal nötig sein, über das Internet mit Hosts der dann nicht euch gehörenden DNS-Domain <Name>.ads zu kommunizieren, dann könnt ihr die Namen dieser Hosts manuell in euer DNS eintragen mit der IP, über die diese erreichbar sind. In dem Fall müsstet ihr maximal ein paar eigene Computer umbenennen, falls die ausgerechnet auch noch dieselben Hostnamen hätten. Halte ich aber für ein ausgesprochen bizarres Szenario.

 

Der Aufwand, einen neuen AD-Forest mit einem von euch kontrollierten Namensraum aufzubauen und alles dorthin zu migrieren, dürfte schwerlich in einem sinnvollen Verhältnis zu dem höchst geringen Risiko stehen.

 

"Den Namen kaufen" ist anscheinend momentan noch nicht möglich, weil die "ads"-TLD noch nicht zugelassen ist. Kann man der Vollständigkeit halber machen, sobald Preise feststehen. Eine Vorregistrierung scheint momentan durchaus ein Kostenrisiko zu beinhalten, da die "Anbieter" allesamt nicht seriös aussehen. Mit Ausnahme vielleicht von Google, die sich auch um die TLD-Registry bemühen, aber sie anscheinend eben noch nicht haben. Müsst ihr selbst wissen.

 

Dass es schon beim Erscheinen von Active Directory vor 16 Jahren und zwei Monaten ein schlechtes Design war, eine "ausgedachte" TLD zu verwenden, deren Domänennamen man nicht selbst kontrollieren kann, erwähne ich hier nur am Rande, weil es irgendwie jetzt nicht weiterhilft.

 

Gruß, Nils

bearbeitet 26. April 2016 von NilsK

[daabm 1.348]

...und ich werfe noch 2 Cent in den Raum: Wenn Du wählen kannst, dann nimm einen Namen, der nichts mit dem Unternehmen zu tun hat _und_ dessen Internet-Domain Dir gehört. Spart bei Fusionen/Mergern/Splits viel Ärger... :)

[Maraun 12]

Hi,

 

zunächst danke für alle Antworten.

Jetzt wurde mir die bisherige Thematik etwas genauer erläutert und dabei tauchen dann doch schon erste kleinere Probleme auf.

Google hat sich zumindest unsere .ads TLD gesichert und hält diese (unsere) öffentliche Domain auch seit mehrere Jahren.
Wir haben diverse Anwendungen, die sich mit dem Rechner starten (Identity Agent z. B.), der dann auch sofort versucht, per Internetverbindung
einen connect herzustellen. Google hat per DNS für alle .ads DNS-Abfragen localhost (127.0.0.1) mit kurzem Cache (3 Minuten) eingetragen.
Ist der User also irgendwann per VPN oder direkt am Netzwerk, dauert der Start des Identity Managers unüblich lange.
In der Regel sollte das aber nicht allzu oft, bzw allzu lange der Fall sein. Zudem kann man im Identity Manager ja auch die direkte IP des Systems angeben.

Der TLD Name ist Quark, keine Frage. Passierte vor meiner Zeit, hätte mir aber auch eventuell passieren können.

Für mich erschliesst sich daraus aber auch, dass ignorieren/nichts tun nicht unbedingt eine Alternative ist, da irgendwie auch nicht klar ist, was Google plant.
Das beste wäre in diesem Fall also, dass Google die Domain verkauft.
Parallel muss ich an einer Alternative arbeiten.

[ChrisRa 42]

Stichwort Hosts-Datei. Da trägst du einfach eure IP zum passenden DNS-Namen ein.

Sollte funktionieren. Dann werden die DNS-Server für diesen Namen übergangen und dein Client weiß, wo er hin soll.

Würde ich bei allen Notebooks so machen, die nach "aussen" gehen.

bearbeitet 28. April 2016 von ChrisRa

[NilsK 2.930]

Moin,

 

mir ist gerade nicht klar, wie ihr das beschriebene Problem verhindern würdet, wenn ihr die Domain besitzen würdet. Wollt ihr dann ins Public DNS eure internen Servernamen eintragen?

 

Oder wie es bei zahlreichen anderen Kunden aussähe, deren interne Hosts ja schließlich auch nicht über das Public DNS auflösbar sind, selbst wenn sie keinen Fehler beim Benennen ihrer Domäne gemacht haben.

 

Und irgendwie kommt mir dabei nur in den Sinn: Euer Problem liegt gar nicht im Namen der Domäne, sondern in dem Verbindungskonstrukt, das ihr da nutzt. An das solltet ihr ran. Nicht an den Domänennamen.

 

Gruß, Nils

[Doso 77]

Bei unserem VPN nutzt der Nutzer nach dem Verbindungsaufbau unsere internen DNS Server.

[ChrisRa 42]

Bei unserem VPN nutzt der Nutzer nach dem Verbindungsaufbau unsere internen DNS Server.

 

So sollte sein. Ich habs irgendwie so raus gelesen, dass der Client zum initialen Verbindungsaufbau einen bestimmten Host auflösen muss. Dann solltet ihr tatsächlich euer Design überdenken.

[Doso 77]

Den muss er im externen DNS auflösen, das kann man ggf. ja dann in dieser DNS Zone manuell konfigurieren.

[Maraun 12]

Hi zusammen,

 

danke nochmals für alle Antworten.

Nach der VPN-Verbindung nutzt der User auch unsere internen DNS-Einträge.
Aber bevor er mit VPN verbunden ist, versuchen bereits einige Anwendungen per Internet die Verbindung aufzubauen.

Dann cachen sie sich die DNS-Einträge von Google. Das verzögert ein oder zwei spezielle Anwendungen. Mehr ist es momentan nicht.
Das sind ja in dem Sinn keine öffentlichen DNS-Einträge, sondern Googles DNS-Einträge für unsere genutzte ads Domain.

Zum Glück kennt Google dieses Problem und vergibt eine kurze Lease/Cache-Zeit für die Einträge.

[magheinz 110]

Das ist noch viel spannender bei den ganzen T-DSL-Anschlüssen. Andere Provider machen das auch.

Standardmässig lösen die ALLE Anfragen auf. Im Browser leiten die dann auf eine Hilfeseite, oder Suchmaschine oder so um.

Hat man im RDP-Client eingestellt das er in fremden Domains über ein RDS-Gateway gehen soll klappt das dann nicht da er immer denkt er ist im Firmennetz.