Daim

Salve, war das geplant oder sind die drei DCs gecrasht (was ich nicht hoffe, denn dann stimmt bei euch etwas nicht)? Welche FSMO-Rolle war das noch einmal? Der RID-Master ist die Einzigste FSMO-Rolle, die zwingend in der Kommandozeile mit NTDSUTIL von einem anderen DC übernommen werden muss. Siehe im folgenden Artikel ganz unten den Abschnitt "Die FSMO-Rollen offline übernehmen": LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

Nöö, heut' war mir nicht danach. ;)

Servus, Start - Ausführen - MMC - Datei - Snap-In hinzufügemn/entfernen... - Hinzufügen - Active Directory-Benutzer und Computer - Hinzufügen - Schließen - OK. Danach navigierst du zu der OU "Gruppen" und rufst mit einem Rechtsklick die Option "Neues Fenster" auf. Diese MMC speicherst du dann als "Gruppen.msc" ab und gibst sie dem Benutzer der die Gruppen verwalten soll. Das gleiche führst du dann mit der OU "User" durch.

Na das passt aber auch nicht ganz. Vermutlich meinst du den Infrastrukturmaster und nicht den Schemamaster. Denn der Schemamaster hat überhaupt kein Problem mit dem GC. Der Infra.-Master unter gewissen Umständen schon. Daher: Wenn auf jedem DC der GC aktiviert ist, gibt es auch hierbei kein Problem mehr. ;) Yes, Sir. Tue dir keinen Zwang an. ;)

Du solltest "aufmerksam" lesen. ;) Nein, die Anleitung ist Versionsunabhängig geschrieben und gilt für alle Serverversionen. Ja, klar geht das. Scrolle in der Anleitung ganz runter zum Abschnitt "Die FSMO-Rollen offline übernehmen". Deshalb aufmerksam lesen. :p Genau so ist das. Die Rollen werden "mit Gewalt" von einem anderen DC übernommen. Dann darf aber wie bereits erwähnt, der Ursprungs-Rolleninhaber nie mehr online gehen und muss aus den Metadaten des AD entfernt werden.

Salve, nur wenn die FLZ AD-integriert gespeichert wurde. Nein, müssen sie keineswegs! Im Gegenteil, in vielen Umgebungen ist es eher sinnvoll, alle Rollen auf einem DC zu belassen! Die Rollen sollten: 1. In den meisten Umgebungen (insbesondere in KMUs) alle auf einem DC belassen werden. 2. Falls eine Verteilung der Rollen notwendig ist, dann wie folgt: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Dabei ist es ebenfalls empfehlenswert, auf jedem DC den GC zu aktivieren. Dann muss auch nicht weiter beachtet werden, auf welchem DC sich der Infrastrukturmaster befindet. Es funktioniert sogar, wenn sich alle Rollen auf einem DC befinden. :p Und auch wenn zwei DCs in der Domäne existieren (was standardmäßig in jeder Domäne wegen der Ausfallsicherheit sein sollte), funktioniert natürlich alles weiterhin. Es kommt wie so oft, immer auf die Umgebung an.

Servus, na das wird aber auch mal Zeit. ;) Fällt ein DC aus, kann der zweite DC die Domänenfunktionen "erstmal" aufrecht halten. Die Benutzer merken vorerst nichts davon. Dabei muss natürlich sichergestellt sein, dass auf jedem DC das DNS installiert ist und beide Server als DNS-Server an die Clients verteilt werden. Der zweite DC hat alle AD- und DNS-Informationen, sofern sich die Forward Lockup Zone (FLZ) im AD befindet, was ohnehin Standard sein sollte. Was das AD und DNS (bei AD-integrierter FLZ) betrifft, ja. Aber nichts weiter. In den meisten Umgebungen ist es ebenfalls empfohlen, auf JEDEM DC den GC zu aktivieren. Die FSMO-Rollen werden nicht repliziert. Diese müsste bei einem Crash des Rolleninhabers mit Gewalt übernehmen [1]. Dann darf aber der ursprüngliche Rolleninhaber nie mehr online gehen. Diesen musst du dann noch aus den Metadaten des AD entfernen [2]. [1] LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben [2] LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen So ist es. Erstmal keiner. Aber das ist im ersten Moment auch nicht weiter tragisch. Denn die FSMO-Rollen werden für die Benutzeranmeldung nicht benötigt. Crasht der Rolleninhaber, musst du die Rollen auf einen anderen DC mit Gewalt "seizen". Nein, dass geht nicht und ist auch nicht notwendig. Die AD-Informationen werden automatisch wenn alles ordnungsgemäß funktioniert auf andere DCs repliziert. Ist die FLZ im DNS AD-integriert gespeichert (was es sein sollte), werden auch die DNS-Infos automatisch dank der AD-Replikation auf die anderen DCs repliziert. Wenn der gecrashte DC noch weitere Dienste oder Daten bereitgestellt hatte, müssen diese dann natürlich noch auf einem anderen DC bereitgestellt werden (ggf. mit Hilfe eines Backups). P.S. Uiuiuii... jetzt war ich aber langsam beim tippen. :)

Servus, nein, der DC würde nicht den zweiten DNS-Server anfragen. Er würde den ersten DNS-Server anfragen (also sich selbst) und würde egal welche Antwort er erhält damit Leben. Du musst auf dem DC im DNS eine Weiterleitung entweder auf deinen Router oder auf den DNS deines ISPs konfigurieren.

Salve, das wäre aber noch die "freundlichste" Variante. Mit zwei-drei Sätzen Anleitung kommen dann sogar man staune, sogar die Benutzer damit klar. ;)

Servus, mit welchem Werkzeug wurden die Mail-DBs denn migriert? Du bekommst das nur sauber getrennt, wenn du die Mail-DBs von beiden Benutzern diesmal "richtig" migrierst. Bei allen anderen Varianten kannst du dir nicht sicher sein, ob nicht doch noch Mails vergessen wurden.

... und du kannst dich trotzdem an die Anleitung halten. :cool:

Ich darf zitieren: Service Accounts Step-by-Step Guide

Huhuu, cool, in dem Verein bin ich auch Mitglied. ;) Dazu muss man noch nicht einmal einen Windows Server 2008 R2 DC in der Domäne betreiben. Man kann auch in einer Windows Server 2003 bzw. Windows Server 2008 Domäne "Managed Service Accounts" nutzen. Es reicht schon lediglich das AD-Schema auf Windows Server 2008 R2 zu aktualisieren. Dann müssen aber SPNs manuell von Admin konfiguriert werden.

Servus, mit Bordmitteln wirkt bis Windows Server 2003 eine Kennwortwortrichtlinie nur auf Domänenebene. Verlinkt man eine Kennwortrichtlinie auf eine OU, wirkt sich das nur auf die lokalen Konten die auf dem Client existieren aus. Man kann aber auch unter Windows Server 2003 mehrere Kennwortrichtlinien erstellen, aber nur mit Dritt-Anbieter! Ab Windows Server 2008 gibt es zusätzlich die PSOs, so wie Necron das schon erwähnt hat. Du kannst die Kontooption "Kennwort läuft nie ab" setzen. Danach läuft das Kennwort nicht ab.

Servus, auch heute noch, zu Zeiten Windows Server 2008 R2 ist es sinnvoll einen WINS zu installieren. WINS ist DNS für NetBIOS-Namen. Wenn du keinen WINS-Server hast, macht dein Rechner Broadcasts um NetBIOS-Namen aufzulösen. Es ist empfehlenswert einen WINS-Server zu installieren und kostet im tagtäglichen Job kaum Brot. Meistens installierst du den WINS-Server und verteilst ihn an die Clients. Das war es. Es produziert im tagtäglichen Leben keine Mehrarbeit für den Admin. Was die FSMO-Rollen anbetrifft macht es in den meisten Umgebungen und gerade in KMUs Sinn, alle Rollen auf einem DC zu belassen. Was den Infrastrukturmaster und den GC anbetrifft, dass kommt auf die Umgebung an. Der Infra.-Master überprüft die Objekte aus seiner eigenen Domäne, mit Objekten aus den anderen Domänen (z.B. domänenübergreifende Gruppenmitgliedschaften) innerhalb der Gesamtstruktur. Existiert nun lediglich ein Single-Domain Forest, also nur eine Domäne, dann existieren ja schlichtweg keine domänenübergreifende Objekte die es zu vergleichen gibt. In solch einer Umgebung kann der GC auf dem Infra-Master aktiviert werden, da es für beide keine Arbeit gibt. Aber das sind Grundlagen die du schnell mit einer Suchmaschine auch selbst findest. LDAP://Yusufs.Directory.Blog/ - DNS vs. WINS LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben LDAP://Yusufs.Directory.Blog/ - Phantome im Active Directory

Servus, dann arbeite den Artikel erneut durch oder verwende den folgenden. LDAP://Yusufs.Directory.Blog/ - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Die Metadaten des DCs stehen noch im AD. Die richtige Stelle können wir dir von hier aus schlecht beantworten.

Servus, schlägt dieser Test nicht mehr fehl?

Na dann ist es nicht der Rede wert. ;) Ohnehin kann man gerade im KMUs empfehlen, auf jedem DC den GC zu aktivieren. Da wird Erfahrungsmäßig nicht soo sehr AD bzw. GC lastig gearbeitet.

Servus, lies im folgenden Artikel in der zweiten Aufzählung Punkt 3. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben

Servus, warum um Himmels Willen?

Servus, überprüfe doch mal ob dieser Artikel passt: Troubleshooting Active Directory replication failures that occur because of DNS lookup failures, event ID 2087, or event ID 2088

Servus, siehe: LDAP://Yusufs.Directory.Blog/ - Einen zusätzlichen DC in die Domäne hinzufügen LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen

Dann: - Das Eventlog. Das Eventlog sollte man stets im Auge haben, denn falls der Server Probleme hat, wird es meistens protokolliert. - DCDIAG. Installiere dir die Windows Support Tools (von der CD im Verzeichnis Support\Tools oder auf den Microsoft-Seiten) und führe auf dem DC in der Kommandozeile das DCDIAG aus. Damit kontrollierst du den "Gesundheitsstatus" des DCs. Beim ausführen von DCDIAG werden einige Tests durchgeführt. Falls es Probleme gibt, erscheint bei den fehlgeschlagenen Tests FAILED. Weiterhin kannst du z.B. mit DCDIAG /Test:_DNS (ohne dem Unterstrich) DNS-Tests durchführen. Du kannst auch DNSLint verwenden, um das DNS zu überprüfen. Aber auch hier, sollte es Probleme geben, wird es im Eventlog protokolliert. - NetDIAG. Dieses Kommandozeilentool befindet sich ebenfalls in den Windows Support Tools und führt in erster Linie die Netzwerkdiagnose des DCs durch. LDAP://Yusufs.Directory.Blog/ - Domänencontroller Diagnose mit NETDIAG - Für Exchange, führe den Best Practice Analyzer (BPA) durch (zu finden ist der BPA in der EMC unter "Tools"). Dort kannst du einen "Health Check" durchführen und der BPA meldet dann, wenn ihm etwas nicht passt. Der BPA bietet dir gleichzeitig dann bei Problemen die er gefunden hat weiterführende Informationen sowie eine Lösung an.

Servus, um welche Serverversion handelt es sich?

Servus, @ dalmatino Nimm es mir bitte nicht böse, aber welchen Mehrwert stellt nun deine Antwort dar? Da du dir nicht zu 100% nicht sicher bist, bringt das dem OP rein garnichts. Klar, auch wenn man sich zu 100% sicher ist bedeutet das noch lange nicht das es am Ende so ist. Aber wenn man schon selbst keine absolute Antwort zu der Frage hat, sollte man besser keine abgeben. Des Weiteren gibt es primäre- sowie sekundäre Zonen auch bei AD-integierter Speicherung der DNS-Informationen und das seit Windows 2000! Wie gesagt, bitte nicht falsch verstehen und ist auch nicht böse gemeint, aber deine Antwort hilft dem OP eher wenig. @ dirk12345 Du hast es bereits richtig erkannt. Da die Anwendungsverzeichnspartitionen wie z.B. die DomainDNSZones und ForestDNSZones erst mit Windows Server 2003 eingeführt wurden, kann Windows 2000 damit nichts anfangen. In Windows 2000 befinden sich die Active Directory-integrierten DNS-Informationen in der Domänenpartiton (wo sich z.B. auch die Benutzer, Gruppen, Computer etc. befinden) und können daher nur innerhalb der Domäne repliziert werden. Du kannst die Frage im Assistenten ruhig bestätigen. Da Windows 2000 ohnehin mit den Verzeichnispartitionen nichts anfangen kann, geht auch nichts kaputt. ;) Denn wie bereits erwähnt stecken die DNS-Informationen unter Windows 2000 in der Domänenpartition.