Jump to content

Active Directory TLD-Änderung


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

Link zu diesem Kommentar

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

Link zu diesem Kommentar

"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

Link zu diesem Kommentar

"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

Link zu diesem Kommentar

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 von NilsK
Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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

Link zu diesem Kommentar

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.

Link zu diesem Kommentar

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.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...