Daim

Das ist auch gut so. Wo genau hast du nochmal geschrieben, dass du die 16 DCs in der Testumgebung entfernt hast? ;) Wenn es sich um "echte" DCs handelt die keine weiteren Dienste zur Verfügung stellen, ist das doch in kurzer Zeit durch. Ich denke an gar kein Imagen. Aber wenn du doch dein Inplace Update testen möchtest, dann erstelle dir doch ein Image von nur einem DC und teste das Inplace Update dann in einer abgeschotteten VM. OK, du willst also wenig Arbeit damit haben. ;) Sehr gute Wahl. :cool:

Servus, doch, dass funktioniert. Der Client bringt zwar eine Fehlermeldung aber das wechseln in eine Arbeitsgruppe ist trotzdem möglich.

Hola, dann erscheint diese Fehlermeldung auch in der produktiven Umgebung? Genau. Auf einem DC existieren noch herumlungernde Objekte (Lingering Objects). Das bedeutet, auf einem (oder mehreren) DC existieren noch Objekte, die auf den anderen DCs bereits gelöscht wurden. Die Ursachen können Konnektivitäts-, Namensauflösungs- oder AD-Replikationsprobleme sein. Mit dem folgenden Befehl kannst du dir die Objekte anzeigen lassen: REPADMIN /removelingeringobjects <FQDN des “veralteten” DCs> <GUID eines “aktuellen” DCs> <Verzeichnispartition worin sich die veralteten Objekte befinden> /Advisory_Mode Anschließend wird für jedes veraltete Objekt im Eventlog die EventID 1946 protokolliert. Diese kannst du dann entweder mit dem gleichen Befehl allerdings ohne den Parameter /Advisory_Mode oder mit ADSIEdit entfernen. Lies dir diesen Artikel durch, dann sollte es klarer werden: LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte) Die Vorgehensweise war ungeschickt. Du hättest z.B. mit dem kostenlosen VMWare Converter dir eine VM eines DCs erstellen können und dort dein Inplace Update (was im Übrigen nicht empfohlen ist) durchführen. Siehe vorherigen Absatz.

Hola, vor allem bestimmt der Domänenfunktionsmodus das Serverbetriebssystem, unter dem ein DC betrieben werden kann. Des Weiteren kommen mit jedem höheren Modus neue Funktionen hinzu. :)

Servus, es liegen keine konkreten Probleme vor und die Macintosh-Benutzer können sich weiterhin an der Domäne authentisieren. Aber wenn du weitestgehend jegliches Risiko ausschließen möchtest, solltest du das in einer Testumgebung verifizieren. LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus

Servus, wenn du die MMC "Active Directory-Domänen und -Vertrauensstellungen" öffnest, siehst du gleich alle Domänen, die sich innerhalb der Gesamtstruktur befinden. Die Vertrauensstellungen tauchen in der Übersicht so nicht auf. Wenn du die Vertrauensstellung sehen möchtest, musst du dazu auf der entsprechenden Domäne einen Rechtsklick durchführen -> Eigenschaften -> auf den Reiter Vertrauensstellungen wechseln. Nur an dieser Stelle in der GUI bekommst du die Vertrauensstellungen die nicht zur Gesamtstruktur gehören angezeigt und nicht in der Übersicht.

Salve, moment, dass möchte ich jetzt aber genauer wissen. Also erstmal habe ich natürlich ein großes Interesse, dass ich auf meiner Seite keine Fehler stehen habe. Das kann ich jetzt ausschließen? Dann schreibst du "...wer Klammer zählen kann". Das alleine wird doch nicht der Grund gewesen sein, denn dein LDAP-Pfad stimmte doch bestimmt nicht. Demnach waren es also nicht "nur" die Klammern, oder?

Hast du dir etwa den Link in meiner vorherigen Antwort nicht durchgelesen? Dann jetzt aber. Siehe oben. Das musst du wissen. Mit DCPROMO stufst du den DC zum Mitgliedsserver herunter. Existieren auf dem DC noch weitere Dienste die für den Betrieb notwendig sind, dann musst du diese auf dem noch zur Verfügung stehenden DC bereitstellen. Auf was du noch alles achten solltest, erfähst du hier (lesen musst du schon selbst): LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

In diesem Fall, wo nur zwei DCs existieren kann man das Verschieben wirklich dem DCPROMO-Vorgang überlassen. Ansonsten bin ich aber ein Freund davon, diesen Schritt manuel durchzuführen. Um sich einfach diesen Vorgangs bewußt zu sein (man muss überprüfen ob alle Rollen auch tatsächlich verschoben wurden) und zum anderen, in einer Umgebung mit mehreren DCs, den "passenden" neuen Rolleninhaber selbst auszuwählen. Aber wenn ohnehin nur zwei DCs existieren wie beim OP, kann man das dem DCPROMO überlassen. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen mit DCPROMO verschieben @ Froschkoenig Welcher Fehler kam denn mit NTDSUTIL?

Das funktioniert aber nur, wenn unter Windows Server 2003 die Windows Support Tools installiert sind. ;)

Servus, dann konfiguriere diese beiden Richtlinien: LDAP://Yusufs.Directory.Blog/ - Asynchrones Startverhalten beim Windows XP

Du hast du Quellangabe vergessen! Hier die Quelle: http://www.rlmueller.net/Programs/LastLogonTimeStamp.txt

Servus, wann sich der Benutzer das letzte Mal an der Domäne authentisiert hat, wird im Attribut Last-Logon gespeichert. Der Nachteil von diesem Attribut ist, dass es nicht zwischen den DCs repliziert wird. Somit müsste man jeden einzelnen DC in der Domäne abfragen, um das aktuellste Datum zu erhalten. Daher ist es empfehlenswert, dass Attribut Last-Logon-TimeStamp zu nutzen da dieses Attribut zwischen den DCs repliziert wird. Das Attribut wird allerdings verzögert (ca. 10-11 Tage) aktualisiert, reicht aber für eine Aufräumaktion allemal. Dieses Attribut kann aber erst ab dem Domänenfunktionsmodus "Windows Server 2003" genutzt werden. Siehe: LDAP://Yusufs.Directory.Blog/ - Die letzte Benutzeranmeldung herausfinden

Salut, du kannst nach der Betriebssysteminstallation direkt DCPROMO ausführen und musst nicht zuerst den Server zur Domäne hinzufügen. Damit sparst du dir einen Schritt und somit einen Neustart. Das Einzige was automatisch verschoben wird, sind lediglich die FSMO-Rollen. Alles andere, je nachdem welche Dienste noch auf dem DC laufen, musst du manuell verschieben. Siehe: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen Bevor du den DC mit DCPROMO herunterstufst, deaktiviere vorher noch den GC auf dem DC. Sonst meckert der DCPROMO-Assistent und das kann man sich leicht sparen.

Achso. Dann hättest du einfach "Computername" schreiben können, dann wäre es glasklar gewesen. Um die Group Policy Preferences (GPP) auch auf Windows XP (x32/x64), Windows Server 2003 (x32/x64) und Vista (x32/x64) nutzen zu können, musst du lediglich die CSEs an diese Systeme verteilen. Siehe: Information about new Group Policy preferences in Windows Server 2008 Das ist falsch! Wenn du von den "neuen" Richtlinienfunktionen (GPPs) profitieren möchtest, müssen lediglich die CSEs verteilt werden. Für die Konfiguration von Richtlinien gilt ohnehin, dass das vom aktuellsten Betriebssystem durchgeführt werden sollte. Eben.

Bonjour, das ADPREP /Domainprep /GPPREP genügt. Das führt die Änderungen von /Domainprep und /GPPREP in einem Schritt durch. Was du damit meinst ist mir nicht klar. Oder du lässt ie rollen auf dem anderen 2008 R2 DC. Ja, kann man. Ansonsten schau noch hier rein: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

Ja, dass funktioniert und viel passieren kann nicht. Denn entweder es funktioniert oder nicht. Und wenn es nicht funktioniert, gibt es wahrscheinlich noch eine Leiche im AD die nicht aus den Metadaten des AD entfernt wurde.

Servus, genau, um den höchsten Modus einzustellen, musst du den Domänen- sowie Gesamtstrukturfunktionsmodus auf "Windows Server 2008 R2" hochstufen. Das bedeutet aber, dass sich in der Gesamtstruktur ausschließlich Windows Server 2008 R2 DCs (in allen Domänen) befinden dürfen. Denn die Voraussetzung zum aktivieren des AD-Papierkorbs ist der Gesamtstrukturfunktionsmodus "Windows Server 2008 R2". Siehe: LDAP://Yusufs.Directory.Blog/ - Der Active Directory-Papierkorb im Windows Server 2008 R2

Huhuu, Off-Topic:also DAS geht noch nicht einmal als Tippfehler durch! :D

Ja, dass ist "unter Umständen" korrekt. Denn es 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. Lies dir im folgenden Link in der zweiten Aufzählung "Punkt 3" durch: LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Dieser Link ist für das Verständnis auch hilfreich: LDAP://Yusufs.Directory.Blog/ - Phantome im Active Directory Was FTP betrifft: Du bist Domänen-Admin mit deinem Benutzerkonto, mit dem du den ganzen Tag angemeldet bist? Falls ja, wird es höchste Zeit das zu ändern! Welche Fehlermeldung *genau* erhalten denn die Benutzer?

Nein, ist es nicht. Wie bereits geschrieben, das OU-Design (Struktur und Namen) ist allein für die Admins. Naja, du möchtest nicht das "AD von Grund auf" umstrukturieren, sondern das OU-Design. Auch wenn bereits GPOs existieren würden, wäre das kein Problem. Akzeptiert. ;) Wenn du eine CMD explizit als Admin gestartet und von dort aus die DLL registriert hättest, hätte das auch funktioniert. Naaa... ok... Ausrede akzeptiert. :cool:

Aloha, ich weiß zwar nicht ob DU das "einfach" kannst, aber technisch möglich ist das. Abschalten? Es hätte gereicht wenn du das AD-Schema SnapIn explizit als Admin ausgeführt hättest. OUs werden in erster Linie für die gezieltere Delegation von administrativen Aufgaben im AD, zur administrativen Übersicht und für das Anwenden von GPOs erstellt. Das OU-Design ist keineswegs in Stein gemeißelt und kann jederzeit im laufenden Betrieb geändert werden. Du solltest aber nicht versuchen, dass Organigramm der Firma in OUs abzubilden. Sondern das OU-Design wählen, welches eure (also die Admins) tag tägliche Arbeit erleichtert. Ihr müsst damit arbeiten und klar kommen. Die Benutzer bekommen nichts von alledem mit. Nein, es geht nichts "kaputt". Du solltest das aber in einer "ruhigen Minute" durchführen. Nein und nein. P.S. Von einem MCITP SA hätte ich erwartet, dass er diese Fragen selbst beantworten kann und falls nicht, dass er weiß wie man die Antworten auf diese Fragen leicht selbst herausfindet.

Salut, du "musst" *nicht* vorher die FSMO-Rollen auf einen DC verlagern. Das ist für den Vorgang nicht zwingend notwendig. Die Frage wäre eher, warum die Rollen überhaupt verteilt waren. Warum ist die Forward Lookup Zone nicht AD-integriert gespeichert? Denn das ist "Best Practice". Das ist logisch, denn das AD-Schema unterscheidet sich zwischen "Windows Server 2008" und "Windows Server 2008 R2". Doch, dass AD-Schema hast du erfolgreich auf die Version 44 (also auf Windows Server 2008, aber nicht auf 2008 R2!) aktualisiert. In dem du die richtige ADPREP-Version verwendest. ;) Siehe auch: LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen Die DNS-Informationen übernimmt man aqutomatisch, in dem sich die Forward Lookup Zone AD-integriert speichert. Wenn das bei dir nicht der Fall sein sollte, ist das jetzt ein guter Zeitpunkt das zu tun. Was DHCP betrifft, siehe: LDAP://Yusufs.Directory.Blog/ - Den einzigen Domänencontroller austauschen

Servus: LDAP://Yusufs.Directory.Blog/ - Die letzte Benutzeranmeldung herausfinden oder mit: net user <Benutzername> /Domain

Servus, der Domänen- sowie Gesamtstrukturfunktionsmodus betrifft die DCs, nicht die Clients oder Mitgliedsserver! Siehe: LDAP://Yusufs.Directory.Blog/ - Domänen- und Gesamtstrukturfunktionsmodus