Daim

Huhuu, ... und die DCs zu den entsprechenden AD-Standorten verschieben. Jaja, iss ja schon gut. Bin schon wech. ;)

Dein Wunsch ist mir Befehl. Ist korrigiert. ;)

Hola, so so... DU nennst es also "sinnvoll". Ich, versteht sich von selbst, keineswegs! Und dann wären da noch die Datenschutzbestimmungen... Abgesehen davon, auch wenn du ein Landsmann bist, schließe ich mich Norbert an.

Ich habe nichts anderes erwartet. :p Danke für die Rückmeldung.

Salve, auch ich rate von einer Domänenumbenennung ab. Da scheinbar nur ein DC (und das ist genau ein DC zu wenig!) existiert, ist auch eine Migration zügig durchgführt (das entsprechende Know-How vorausgesetzt). Wenn die Frage mir erlaubt ist: Gibt es denn einen *trifftigen* Grund warum die Domäne umbenannt werden soll? Denn dieser Vorgang ist alles andere als "einfach" (wie so vieles in der IT). Es ist zwar möglich ab dem Gesamtstrukturfunktionsmodus "Windows Server 2003" eine Domäne umzubenennen, doch falls man diesen Weg gehen möchte, muss vorher die Umgebung genauestens analysiert und die notwendigen Schritte geplant werden. Die Hauptproblematik sind die eingesetzten (Netzwerk-) Applikationen. Abgesehen davon, der Name der AD-Domäne fällt doch dem Benutzer kaum auf. Der ist in den meisten Fällen *nur* für die IT interessant. Die Benutzer kommen doch mit dem Domänennamen kaum in Berührung (i.d.R. "sehen" sie ihn nur bei der Anmeldung) und sehen ihn praktisch sonst nirgends. Der Außenauftritt ist von dem Domänennamen auch nicht abhängig. Was die Mailadressen anbetrifft, haben die mit dem Domänennamen ebenfalls nichts zu tun, genauso wenn es um die Benutzeranmeldung geht. Die Benutzeranmeldung könnte auf den userPrincipalName (UPN) umgestellt werden und dazu könnte man die Mailadresse nutzen.

Hola, ... das können sogar weitaus mehr User pro Standort sein. Das kommt dann auf den "Anspruch" an. Handelt es sich tatsächlich um 10-15 User, ist es schon keine Option mehr, sondern, es ist die Empfehlung wenn es keinen trifftigen Grund gibt, keinen *DC vor Ort hinzustellen.

Servus, lies dir in dem folgenden Link, insbesondere den Abschnitt "Die Objektdelegierung" durch. Das sollte die Lösung sein. LDAP://Yusufs.Directory.Blog/ - Clients in die Domäne hinzufügen P.S. dmetzger hat mit seiner Annahme mit der knappen Beschreibung vollkommen recht!

Servus, jetzt muss ich auch noch etwas dazu schreiben. Die Zeitsynchronisation in einer Domäne funktioniert folgendermaßen: Der für die Zeit verantwortliche DC einer Gesamtstruktur ist der DC, der die FSMO-Rolle des PDC-Emulators in der Root-Domäne innehat! Man sollte den PDC-Emulator der Root-Domäne gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen. Auf der Firewall muss dazu der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer "externen Quelle" abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie muss(!) nur innerhalb einer Gesamtstruktur synchron sein! Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Memberserver synchronisieren sich ihre Zeit mit ihrem Anmeldeserver, also von dem DC, bei dem sich der Client anmeldet/authentisiert und dieser muss nicht zwingend der PDC-Emulator ihrer Domäne sein. Wenn an w32time nichts gedreht wurde, hast man eine komplette Zeitsynchronisation. Die PDC-Emulatoren der Subdomänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne. Wie bereits geschrieben, ist der PDC-Emulator der Root-Domäne die maßgebliche Zeitquelle für die Gesamtstruktur. Auf dem PDC-Emulator der Root-Domäne wäre folgender Befehl auszuführen: w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES Anschließend das Eventlog kontrollieren. Du musst nur darauf achten das an den Clients sich die Zeit nicht mehr als 5 mins abweicht, denn dann verweigert w32time seinen Dienst. Hier müsstest Du dann von Hand erstmal nachstellen. How to configure an authoritative time server in Windows Server Du kannst an einem XP-Client auch diesen Befehl händisch eingeben: "w32tm /config /update /syncfromflags:DOMHIER". Oder du konfigurierst die Zeitsynchronisation nach Norberts Anleitung (Link von Sunny). Denn das hat den Vorteil, das wenn der PDC-Emulator verschoben wird, du nichts mehr konfigurieren musst.

Servus, IP-Informationen vergibt man mit DHCP und nicht mit Hilfe von GPOs. Schließlich muss zum Verteilen von GPOs das DNS bereits funktionieren (ja, ich weiß, es sind zwei DCs).

Servus, ja, klar kannst du den Server zum DC stufen und somit eine Domäne installieren. Somit werden auch alle Benutzerkonten die auf dem Server erstellt wurden mit übernommen. Die Clients musst du dann noch zur Domäne hinzufügen.

Off-Topic:Natürlich! Das Leben und erst garnicht die IT, ist kein Kindergeburtstag! :cool:

Nein, ich meine warum du eine neue Domäne installieren möchtest, anstatt die bestehende, durch einen zusätzlichen DC zu aktualisieren. Du führst quasi keine Migration, sondern eine Domänenaktualisierung durch. Das erspart dir jede Menge Arbeit und Risiko. Genau so ist es auch. Warum migrieren? Das ist nicht notwendig. Bestehende Fehler können korrigiert werden. Altlasten im AD, in Form von "nicht mehr notwendigen" Objekten kann man entfernen usw. Ich erwarte von jedem IT-Pro, dass er auch seine Häuptlinge in einem gewissen Grad, durch handfeste Argumente, vom Gegenteil überzeugen kann.

Ich hoffe doch sehr für euch, dass er das auch Begründen kann. Denn wie Nils es es bereits schrub, läuft demnächst Windows Server 2003/R2 aus dem Support aus. Warum also heute noch das "uralte" OS installieren. Warum das denn? Eine Migration ist eine Menge Arbeit (in Abhängigkeit der Umgebung) und birgt jede Menge Gefahren. Erst recht wenn man im Thema Migration nicht Fit ist. @ Nils Zwei Mal: Ich weiß. ;)

Servus, ürgs. Du willst nicht im ernst heute noch Windows Server 2003 installieren? Besser ist es nicht und im Übrigen heißt es "R2" und nicht "RS2". Quatsch! ADPREP wird nie automatisch durch einen Assistenten ausgeführt. Das ist immer ein manueller Vorgang. Und abgesehen davon funktioniert ein Inplace-Update auf "Windows Server 2003 R2 --> x64Bit <--" nur, wenn der Server bereits unter x64Bit läuft. Ein Cross-Upgrade von x32 auf x64Bit ist nicht möglich. Ja, habe ich. Installiere das aktuelle Serverbetriebssystem "Windows Server 2008 R2" und füge diesen als "zusätzlichen" DC zur Domäne hinzu und vermeide wenn möglich ein Inplace-Update (was von Windows 2000 direkt zu 2008 R2 ohnehin nicht möglich ist).

Servus, die Möglichkeiten um DHCP ausfallsicher zu gestalten sind: 1. Du kannst auf dem zweiten Server die gleichen Scopes als DHCP Server einrichten. Den DHCP Server im AD autorisieren, aber den Dienst deaktivieren. Im Fehlerfall (primärer DHCP fällt aus) kannst du den zweiten DHCP aktiv schalten. 2. Du kannst die IP-Bereiche teilen. Dann verteilen beide DHCP-Server die IP-Adressen und im Fehlerfall musst du im Idealfall nichts machen (ausreichend verfügbare IP-Adressen vorausgesetzt). 3. Zwei DHCP-Server haben den gesamten Adressbereich, aber jeder der Server schliesst den zu verteilenden Bereich des jeweils anderen Servers aus. Z.B. verteilen beide Server 10.0.0.1 - 10.0.0.254. Wenn beide Server in etwa die Hälfte der Adressen verteilen sollen, dann schliesst der erste DHCP von 10.0.0.1 - 10.0.0.128 aus und der zweite DHCP von 10.0.0.129 - 10.0.0.254. 4. Einen DHCP-Cluster installieren. Was das Thema DHCP und Sicherheit betrifft, siehe: LDAP://Yusufs.Directory.Blog/ - Ist DHCP ein Sicherheitsfeature?

Servus, wenn das WAN "Full-Mesh" ist, ist es sogar empfehlenswert die AD-Replikation zwecks Ausfallsicherheit (siehe Norberts Antwort) ebenfalls so aufzubauen! Eben. Aber auch bei einer Schemaaktualisierung genügt weitaus weniger Bandbreite. Die Übertragung dauert dann nur zu lange. Das AD ist robust und lässt sich nicht so einfach "klein kriegen". ;)

Wenn es sich um einen reinen DC handelt, brachst du den DC garnicht wiederherstellen. Du bist sicher mindestens genauso schnell, wenn du die Metadaten des AD bereinigst [1], also die DC-Informationen aus dem AD und DNS entfernst, und anschließend den (anderen) Server nach einer Neuinstallation zum zusätzlichen DC stufst [2]. Wird allerdings der DC gestohlen, stimmt etwas gewaltig an euren Sicherheitsvorkehrungen nicht! Denn genau dieser Fall darf genau aus dem Grund, den blub genannt hat, nicht eintreten! In solch einem Fall, müssen schleunigst sämtliche Kennwörter von administrativen Konten geändert und der DC muss aus dem AD entfernt werden. Genau aus diesem Grund, wurde der RODC erkoren [3]! Dieser ist geradezu prätestiert für Aussenstellen, die nicht die gleiche physikalische Sicherheit bieten können wie die Zentrale. Aber nur dann, wenn alle DCs einer Domäne ausgeschaltet sind, könnte das funktionieren. Trotzdem ist das nicht supportet und ist alles andere, als eine gute Idee [4]. Sichere die Server stets mit der Variante, die der Hersteller supportet. Klar, das Thema Backup ist aufwändig, gehört jedoch zur täglichen Administration. Die Server und Technologien müssen "supportet" gesichert werden! Wozu soll man das denn tuen? [1] LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen [2] LDAP://Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen [3] LDAP://Yusufs.Directory.Blog/ - Read-Only Domain Controller (RODC) [4] LDAP://Yusufs.Directory.Blog/ - Images als Sicherung?

Hola, das stimmt... ... aber das nicht. Denn nach dem Ausführen von DCPROMO /Forceremoval ist der gewaltsam heruntergestufte DC kein Mitgliedsserver, sondern ein Standaloneserver! Dann kann man auf einem Standaloneserver direkt das DCPROMO ausführen und den Server wieder zum DC stufen. Der Server muss also nicht zuerst ein Mitgliedsserver werden, um das DCPROMO auszuführen. Somit erspart man sich dann auch einen Schritt und damit einen Neustart.

Und mich freut es jedes Mal wenn ich sehe, dass wir mit unserer Community Leistung "hier und da" etwas bewirken können. Danke für die für uns helfende, immens wichtige Rückmeldung. Dann kann ja das Wochenende kommen. ;)

Bei mehreren Domänen wären die Vorteile, wenn man z.B. unterschiedliche DNS-Namensräume haben möchte. Oder unterschiedliche Administratoren sollen "nur" ihre eigene Domäne verwalten und nur dort der Admin sein. Wobei das letztendlich nur mit getrennten Gesamtstrukturen und nicht wirklich mit mehreren Domänen innerhalb einer Gesamtstruktur zu regeln ist. Mit mehreren Domänen kann man unterschiedliche Kennwortrichtlinien (bis einschließlich Windows Server 2003) anwenden. Ab Windows Server 2008 gibt es die "Password Settings Objects, kurz PSOs". Das lässt sich durch ein entsprechendes Berechtigungskonzept regeln. Verschiedene Kunden befinden sich in derselben Domäne? :rolleyes: Verwaltungsberechtigungen delegiert man besser über Organisationseinheiten. Zum einen ist das einfacher und flexibler zu handhaben und zum anderen wird weniger Hardware für die DCs benötigt. Des Weiteren spart man wie bereits erwähnt, Serverlizenzen.

Huhuu, das kannst DU gerne so tun, aber zum einen ist das keineswegs notwendig und zum anderen würde --> ich <-- es *nur* dann tun, wenn es eine berechtigte Situation erfordert. Denn stell dir vor es existieren 100 Benutzer verteilt in fünf Standorte (an jedem Standort sitzen 20 Mann). Das würde ja bedeuten, du installierst *fünf* DCs. Und das halte ich aber gewaltig mit "Kanonen auf Spatzen" geschossen. Weiterhin darf die physikalische Sicherheit der DCs keineswegs vernachlässigt werden(!) und überlicherweise ist das in Aussenstandorten leider meistens genau der Fall (DC steht unter dem Tisch der Sekretärin). Apropos bin ich zur Zeit bei einem Kunden, der 700 Benutzer verteilt an 23 Standorte hat und sich alle Benutzer an den DCs in der Zentrale anmelden! Zur Verfügung steht ein vom rosaroten Pather gehostetes MPLS-VPN. Des Weiteren kommt es wie immer auf die Umgebung an! Handelt es sich mindestens um eine Windows Server 2008 Umgebung, kommen RODCs in Frage. Dann zumindest müssen keine beschreibbaren DCs mehr in den Aussenstandorten existieren. Ansonsten neige ich ich gerade bei 20 Mann (und mehr) Standorten stets dazu, die Benutzer an den DCs der Zentrale authentisieren zu lassen. Natürlich gibt es keine Garantie dafür, das zum Zeitpunkt der Authentisierung (und nur dann!) die Leitung zur Verfügung steht. Aber beispielsweise bist du bei einem MPLS-Netz mit entsprechenden SLAs schon gut ausgestattet. ;) Aber wenn möglich kann man ja dann RODCs einsetzen. In der Praxis ist das meist kein Problem. Die "rosarote" Welt sieht jedoch anders aus, ja, auch die Realität sieht anders aus. ;) Denn jeder Dienst und jede Applikation "gefährdet" den DC. Siehe dazu: LDAP://Yusufs.Directory.Blog/ - Warum es ein dedizierter DC sein sollte! Aber dann auch *nur* in der Zentrale. ;) Denn warum die Daten bzw. Applikationen zu den Benutzern bringen und nicht die Benutzer zu den Daten/Applikationen, RDS/RemoteApp sei Dank! Das bin und kann ich, versteht sich von selbst, nicht sein. ;)

Servus, vermeide für 15-20 Mitarbeiter eine Subdomäne zu erstellen und arbeite stattdessen mit OUs und AD-Standorten, wenn keine *trifftigen* Gründe für eine Subdomäne existieren. Schließlich sollte sich in jeder Domäne mindestens zwei DCs befinden, wozu min. zwei Serverlizenzen benötigt werden würden, jeder DC sollte/muss vor Ort physikalisch geschützt sein, jede Domäne muss gesichert werden (Backup). etc. Die Aussenstelllen können sich problemlos an den DCs der Zentrale authentisieren. Sofern ein "vernünftiges" VPN existiert. Mit deinen bisher genannten Informationen bist du mit OUs und AD-Standorten bestens bedient.

Servus, das DNS in einer Domäne, muss lediglich bei dem installieren des ersten DCs in der Domäne konfiguriert werden. Dieses lässt man in der Praxis vom DCPROMO-Assistenten durchführen. Installiert man einen weiteren DC in der Domäne, muss lediglich das DNS installiert, aber nicht konfiguriert werden. Denn das DNS ist doch bereits auf dem ersten DC durch den DCPROMO-Assistenten konfiguriert worden. Dabei gilt es lediglich darauf zu achten, dass die Forward Lookup Zone nach "Best Practice" AD-integriert gespeichert wurde. Denn somit erhalten alle weiteren DCs die DNS-Informationen automatisch durch die AD-Replikation. Wie gesagt, in der Praxis lässt man das DNS beim installlieren des ersten DCs durch den DCPROMO-Assistenten erledigen. Ab dem zweiten DC muss nur noch das DNS installliert werden. Alles andere erledigt die AD-Replikation. Beachte in dem folgenden Link Punkt 3: LDAP://Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen No problem!

Servus, die Forward Lookup Zone ist aber AD-integriert gespeichert? Weiterhin sollte in den TCP/IP-Einstellungen der DCs, die DNS-IP-Adresse "Überkreuz" eingetragen werden. LDAP://Yusufs.Directory.Blog/ - Welcher DNS-Server sollte eingetragen werden ? Wenn dieser Fall eintritt, kann der Client den DC/SBS anpingen (den Namen und die IP)? Wie wurden diese Clients installiert? Sind das zufällig geimagete bzw. geclonete Systeme und falls ja, wurde SYSPREP angewendet? Dann sollte in jedem Fall das Eventlog die erste Anlaufstelle sein. Des Weiteren solltest du auf dem DC das DCDIAG ausführen. Wie hast du das denn verifiziert? Die Clients haben beide DCs als DNS-Server in ihren TCP/IP-Einstellungen eingetragen?

Servus, für die Zukunft kannst du das Kennwort für den DSRM "einfacher" verwalten. Ab Windows Server/SBS 2008 kann die Synchronisierung des Kennworts für den DSRM mit dem Kennwort eines Domänen-Benutzers erfolgen. Dadurch musst du lediglich das Kennwort des Domänen-Benutzers verwalten und nicht noch zusätzlich, das Kennwort für den DSRM. LDAP://Yusufs.Directory.Blog/ - Das Kennwort vom DSRM ab Windows Server 2008 synchronisieren