flooo 10 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Domain example.com --> Standort 1 --> Standort 2 --> Standort 3 --> Standort 4 -> Child Domain country1.example.com -> Child Domain country2.example.com -> Child Domain country3.example.com -> Child Domain country4.example.com example.com selbst ist über 4 Standorte in DE verteilt. Die Child Domains werden in anderen Ländern betrieben. Jeder Standort hat seinen eigenen IP-Adressbereich im selben Subnetz. An jedem Standort existieren mindestens zwei Domain Controller. An Standort 1, dem HQ, steht der Windows 2k3 Enterprise Server und ein 2k3 Standard Server. Server 1 (2K3 Enterprise) hält bis auf den Infrastruktur-Master alle anderen 4 AD Rollen und ist gleichzeitig GC für den HQ Standort, ausserdem ist er Sub-CA und stellt die TRUSTs zu anderen Domains (Mutterfirma) her und hält im DNS eine Kopie der Zoneneinträge dieser anderen Domains. Server 2 (2K3 Standard) ist Infrastruktur-Master. Beide Server sind zusätzlich DNS und IAS Server. An den anderen Standorten sind jeweils 2 2k3 Domain Controller, die auch gleichzeitig DNS für den Standort bereitstellen. Einer von diesen ist immer der GC für den jeweiligen Standort. Die Frage ist jetzt, ob man im HQ nicht noch einen dritten Domain Controller zur Verfügung stellen sollte, der nur GC (und vielleicht dritter DNS) Server ist und praktisch nur für die lokale Clientanmeldung verantwortlich ist? Ausserdem beobachten wir immer wieder, dass wenn der GC Domain Controller in einem Standort ausfällt, alle Clients in diesem Standort manchmal bis zu 10 Minuten warten müssen bis sie sich anmelden können und auch alle anderen Vorgänge, die den GC erfordern unglaublich träge, wenn nicht sogar unmöglich sind. Hat irgendjemand eine Idee, woran das liegen könnte bzw. wie man die Struktur optimieren könnte ? Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Hast Du unter AD Sites and Services denn auch die Sites und IP-Subnetze definiert und die DCs den jeweiligen Subnetzen zugeordnet? Im übrigen würde ich alle DCs auch zu GCs machen, wenn nicht arg dünne WAN-Verbindungen dagegensprechen. Christoph Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Moin, braucht ihr die Subdomains für die Länder zwingend? Falls nein, würde ich über eine Konsolidierung nachdenken. faq-o-matic.net Welches Domänenmodell ist das Beste für Active Directory? Außerdem solltet ihr alle DCs zu GCs machen. faq-o-matic.net Globaler Katalog vs. Infrastruktur-Master Mit "Kopie der Zoneneinträge" meinst du AD-integrierte Zonen? Falls nein, solltet ihr auch darüber nachdenken. Die Standorte sind korrekt konfiguriert? Gruß, Nils Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Servus, es kommt darauf an, wie AD-lastig in eurem Unternehmen gearbeitet wird. Wird das AD lediglich wie in vielen Umgebungen zur Anmeldung genutzt, können sich alle FSMO-Rollen auf einem DC befinden. Existieren aber in eurer Umgebung Applikationen die AD-lastig arbeiten und so evtl. die ein oder andere FSMO-Rolle mehr beansprucht wird, muss man das natürlich genauer verifizieren. Was du in jedemfall tun kannst ist, auf ALLEN DCs den GC zu aktivieren und das DNS auf jedem DC zu installieren. Nein, dabei spielt es auch keine Rolle, welcher DC die Rolle des Infrastrukturmasters inne hat. Siehe dazu: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Zitieren Link zu diesem Kommentar
flooo 10 Geschrieben 11. August 2009 Autor Melden Teilen Geschrieben 11. August 2009 Hallo, erstmal Danke für die schnellen Reaktionen und die Links. Das der Standort des IMs unwichtig ist, wenn alle DCs auch GC sind, war mir bewusst, die Frage ist nur, ob das nicht zuviel Traffic erzeugt. Im Moment sind alle Standorte mit dem HQ über 2mbit Standleitung verbunden. Das HQ selbst ist mit 6mbit an den Backbone angeschlossen, da die anderen Standorte auf das HQ zugreifen. Welche Überlegungen sollte ich in dieser Richtung noch anstellen? Wir streben mittlerweile auch eine Konsolidierung zumindestens auf Kontinentebene an, d.h. in Europa sollten alle Standorte in eine Domain. Das ist allerdings ein Prozess der sich nicht mal eben umsetzen lässt und daher werden wir wahrschein noch mindestens 1-2 Jahre mit der momentanten Struktur leben müssen. Die Standorte und IP-Adressbereich sind übrigens unter "Sites and Services" vollständig konfiguriert. Anhand der Reaktionen und der Artikel kann ich sehen, dass es zwar nicht Default, aber durchaus verbreitet ist, alle DCs auch zu GCs zu machen. Das heisst wiederum, dass es von Haus aus normal ist, dass wenn der GC in einem Standort ausfällt, die Clients und auch andere Applikationen ewig lange für einen Anmeldevorgang benötigen. Ich frage, da ich es von meinem vorherigen Unternehmen eigentlich nicht so kenne und mir fast sicher bin, dass wir nur einen GC hatten. Zum DNS: Die Zonen unserer Domain und der Child Domains sind AD integriert. Die Kopie der Zone für den asiatischen und amerikanischen Raum, zu deren Domains wir Trusts haben, werden im Moment aber nur von einem DNS Server repliziert. Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Moin, Existieren aber in eurer Umgebung Applikationen die AD-lastig arbeiten und so evtl. die ein oder andere FSMO-Rolle mehr beansprucht wird, muss man das natürlich genauer verifizieren. was für Applikationen könnten eine der FSMO-Rollen stärker beanspruchen? Da fiele mir nix ein. Gruß, Nils Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Moin, Das der Standort des IMs unwichtig ist, wenn alle DCs auch GC sind, war mir bewusst, die Frage ist nur, ob das nicht zuviel Traffic erzeugt. du meinst damit den GC? Nein, in aller Regel ist das kein Problem. Wie groß ist denn die Umgebung, von der wir sprechen? Bedenke, dass nach der Erstreplikation ja nur noch Änderungen repliziert werden. Dafür entfallen im laufenden Betrieb die clientseitigen Anfragen an entfernte GC-Server, wenn der lokale mal nicht antworten sollte. Im Moment sind alle Standorte mit dem HQ über 2mbit Standleitung verbunden. Das HQ selbst ist mit 6mbit an den Backbone angeschlossen, da die anderen Standorte auf das HQ zugreifen. Das ist doch ziemlich dick. Da würde ich keinen Flaschenhals vermuten. Zur Not könnt ihr das Repl-Intervall ja auch anpassen, aber vermutlich ist nicht mal das nötig. Gruß, Nils Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 die Frage ist nur, ob das nicht zuviel Traffic erzeugt. Wenn die Erstreplikation abgeschlossen ist, also auf den GC alle Domänenpartition repliziert wurden, hält sich die tagtägliche standortübergreifende AD-Replikation in Grenzen. Zumindest wenn nicht permanent an AD-Objekten etwas geändert wird. Aber auch wenn, über eine 2 MBit Leitung und Dank der LVR-Replikation fällt das kaum ins Gewicht. LDAP://Yusufs.Directory.Blog/ - Die Linked Value Replikation (LVR) Welche Überlegungen sollte ich in dieser Richtung noch anstellen? Das Design ist soweit korrekt. Wann und warum man AD-Standorte erstellen sollte, habe ich hier erläutert: http://www.mcseboard.de/windows-forum-ms-backoffice-31/ad-standorte-dienste-festverbindung-154964.html#post952878 Wir streben mittlerweile auch eine Konsolidierung zumindestens auf Kontinentebene an, d.h. in Europa sollten alle Standorte in eine Domain. Und im zweiten Schritt folgt dann eine Domäne "weltweit", oder nicht? Das ist allerdings ein Prozess der sich nicht mal eben umsetzen lässt und daher werden wir wahrschein noch mindestens 1-2 Jahre mit der momentanten Struktur leben müssen. Das ist verständlich. Die Standorte und IP-Adressbereich sind übrigens unter "Sites and Services" vollständig konfiguriert. OK. Anhand der Reaktionen und der Artikel kann ich sehen, dass es zwar nicht Default, aber durchaus verbreitet ist, alle DCs auch zu GCs zu machen. Genau. Das heisst wiederum, dass es von Haus aus normal ist, dass wenn der GC in einem Standort ausfällt, die Clients und auch andere Applikationen ewig lange für einen Anmeldevorgang benötigen. Von Haus aus normal ist das nicht. Es kommt auf die Umgebung an und wie sie konfiguriert ist. Was zu empfehlen wäre ist, dass auf jedem DC das DNS installiert ist, sich die Forward Lookup Zone im AD befindet und zusätzlich auf jedem DC der GC aktiviert ist. An die Clients verteilt man dann statisch oder per DHCP mehrere DNS-Server. Ich frage, da ich es von meinem vorherigen Unternehmen eigentlich nicht so kenne und mir fast sicher bin, dass wir nur einen GC hatten. Ja, früher hatte auch Microsoft (mit weniger Erfahrung) andere Ansichten und gab dementsprechende Empfehlungen aus. Heute aber, mit den zur Verfügung stehenden Bandbreiten und mit mehr Erfahrung kann man die Empfehlung ausgeben, auf jedem DC den GC zu aktivieren. Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 (bearbeitet) was für Applikationen könnten eine der FSMO-Rollen stärker beanspruchen? Da fiele mir nix ein. Ich dachte da in Richtung RID-Master, zugegeben auch nicht unbedingt Applikationsbezogen. bearbeitet 11. August 2009 von Daim Zitieren Link zu diesem Kommentar
flooo 10 Geschrieben 11. August 2009 Autor Melden Teilen Geschrieben 11. August 2009 Wie groß ist denn die Umgebung, von der wir sprechen? An den Standorten innerhalb der Hauptdomäne ca 300 Workstations und Server, wobei wahrscheinlich in absehbarer Zeit zwei Standorte integriert werden, d.h. wir sind bei ca. 450-500. Die dann zwei übrig bleibenden Child Domains haben nochmal jeweils 150. Und im zweiten Schritt folgt dann eine Domäne "weltweit", oder nicht? Das wäre sicher ein denkbarer Schritt, ich bezweifle aber, dass das aus organisatorischer Sicht überhaupt möglich ist (technisch sicherlich). Wir haben in Europa nur ca. 800 Maschinen, die im AD vorhanden sind, im asiatischen Raum sind es dann aber schon über 20.000. In Amerika dürfte es ähnlich wie in Europa sein. In Europa ist eine Konsolidierung wahrscheinlich sinnvoll und auch in den nächsten Jahren machbar, weltweit würde es technisch auch gehen, aber es würde eine immensen organisatorischen Aufwand bedeuten, der wahrscheinlich den Benefit übersteigt. Von Haus aus normal ist das nicht. Es kommt auf die Umgebung an und wie sie konfiguriert ist. Was zu empfehlen wäre ist, dass auf jedem DC das DNS installiert ist, sich die Forward Lookup Zone im AD befindet und zusätzlich auf jedem DC der GC aktiviert ist. An die Clients verteilt man dann statisch oder per DHCP mehrere DNS-Server. DNS ist auf jedem Domain Controller installiert, nur einen GC gibt es nur einmal pro Standort. Das werde ich dann ändern, eigentlich sollte das ja auch dann das Logon Problem lösen, da der Client ja nicht einen DC in einem anderen Standort dafür kontaktieren muss, wenn ich das richtig verstanden habe? Zitieren Link zu diesem Kommentar
Christoph35 10 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Naja, in dem Fall wird es eher, wenn der Schritt zu einem globalen AD gegangen wird, so sein, dass eure (und evtl die amerikanischen) Domains aufgelöst werden, und alles in die asiatische(n) Domain(s) integriert wird. Christoph Zitieren Link zu diesem Kommentar
NilsK 2.971 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Moin, An den Standorten innerhalb der Hauptdomäne ca 300 Workstations und Server, wobei wahrscheinlich in absehbarer Zeit zwei Standorte integriert werden, d.h. wir sind bei ca. 450-500. Die dann zwei übrig bleibenden Child Domains haben nochmal jeweils 150. ach so. Das ist überhaupt kein Problem. Ich habe mal einen Forest mit je 6000 Usern/PCs migriert, dessen WAN-Verbindungen teils schmalbandiger waren. Stündliche weltweite Replikation lief klaglos. aber es würde eine immensen organisatorischen Aufwand bedeuten, der wahrscheinlich den Benefit übersteigt. Das kann durchaus sein. wenn ich das richtig verstanden habe? Hast du. Gruß, Nils Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Das werde ich dann ändern, eigentlich sollte das ja auch dann das Logon Problem lösen, da der Client ja nicht einen DC in einem anderen Standort dafür kontaktieren muss, wenn ich das richtig verstanden habe? Du musst nicht unbedingt auf jedem DC den GC aktivieren. Du kannst auch in "Standorte und Dienste" im jeweiligen AD-Standort auf dem "NTDS Site Settings-Objekt" die Option "Zwischenspeichern der universellen Gruppenmitgliedschaften" aktivieren. Doch bei deiner Bandbreite kannst du ruhig auf jedem DC den GC aktivieren. Zitieren Link zu diesem Kommentar
flooo 10 Geschrieben 11. August 2009 Autor Melden Teilen Geschrieben 11. August 2009 Vielleicht noch eine Frage zu der Verteilung der Rollen. Sollten die Rollen wirklich alle auf einem Server lagern oder besser auf 2-3 verteilt werden, um z.B. einem Totalausfall zu entgehen, wenn dieser eine Server ausfällt? (Es läuft hier ja neben den 4 AD Rollen auch noch IAS und Sub-CA). Naja, in dem Fall wird es eher, wenn der Schritt zu einem globalen AD gegangen wird, so sein, dass eure (und evtl die amerikanischen) Domains aufgelöst werden, und alles in die asiatische(n) Domain(s) integriert wird. Zum Glück lässt man uns in Europa da recht viel eigenen Freiraum und will auch gar nicht mit den Problemen einer Migration konfrontiert werden, von daher müsste die Initiative dann wohl von uns ausgehen und logischerweise würde unser Domäne dann auch in die der Muttergesellschaft integriert werden, da es einfacher ist 800 Maschinen und User zu migrieren als >20000 :-) Wir wollen jedoch erstmal in die Richtung einer einzigen europäischen Domäne, da wir auch die einzigen sind, die überhaupt Child Domains nutzen und das in der Vergangenheit schon immer Nachteile mit sich gebracht hat. Danke erstmal an alle für die sehr aufschlussreiche Diskussion! Zitieren Link zu diesem Kommentar
Daim 12 Geschrieben 11. August 2009 Melden Teilen Geschrieben 11. August 2009 Vielleicht noch eine Frage zu der Verteilung der Rollen. Sollten die Rollen wirklich alle auf einem Server lagern oder besser auf 2-3 verteilt werden, um z.B. einem Totalausfall zu entgehen, wenn dieser eine Server ausfällt? (Es läuft hier ja neben den 4 AD Rollen auch noch IAS und Sub-CA). Ja, du kannst die FSMO-Rollen alle auf einem DC lassen. Auch wenn dieser DC ausfallen sollte, kann man immer noch "mit Gewalt" die FSMO-Rollen auf einem anderen DC zügig zur Verfügung stellen. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben da es einfacher ist 800 Maschinen und User zu migrieren als >20000 :-) Da könnte durchaus etwas dran sein. ;) Danke erstmal an alle für die sehr aufschlussreiche Diskussion! Null problemo, dafür sind wir doch hier. :) Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.