Daim

Servus, die Verbindungsobjekte werden automatisch vom KCC erstellt. Du musst also nichts händisch erstellen. Denn das AD schaut nicht nach dem Namen, da diese nur "Schall und Rauch" sind. Das AD verwendet die objectGUID und die Datenbak-GUID (das Attribut invocationId). Und da diese einmalig und eindeutig in der Gesamtstruktur sind, kommt es auch nicht zu Problemen. LDAP://Yusufs.Directory.Blog/ - Zwei wichtige IDs eines DCs: DC GUID und InvocationId

Servus, ohne vorher das Schema zu aktualisieren, wirst du auch keinen Windows Server 2008 R2 als DC zur Domäne hinzufügen können. Das Umbenennen der Domäne ist bereits ab dem Gesamtstrukturfunktionsmodus "Windows Server 2003" technisch möglich. Die Clients und Mitgliedsserver werden zwar übernommen, aber ob es dann keine Probleme gibt, kann dir keiner garantieren! Auch wenn es technisch möglich ist eine Domäne umzubenennen, würde ich es vermeiden, wann immer möglich. Meistens sind es die Programme, die eingesetzt werden. Ob die mit einer Domänenumbenennung klar kommen, kann dir noch nicht einmal jeder Hersteller garantieren. Sind Exchange oder eine CA im Einsatz, wird das Umbennen der Domäne nicht gerade vereinfacht und es ist mit Komplikationen zu rechnen. Je nach Größe der Umgebung, würde ich eher zu einer Migration raten. Vor allem: Gibt es denn überhaupt einen trifftigen Grund, warum die Domäne umbenannt werden soll?

Gut, dann kann ich ja heute Abend mit ruhigem Gewissen einschlafen. ;) Naja, du kannst dir doch mal anschauen (z.B. in meinem PDC-Emulator Link), welche Gruppen erstellt werden. Denn es kann doch auch sehr gut sein, dass diese in absehbarer Zeit gar nicht benötigt und somit auch nicht zu einem Problem werden können. Exakto mundo. :cool:

Einer von uns beiden... sollte sich eine Auszeit nehmen (und nein, dass bin nicht ich). ;) Was hast du denn an meinen Ausführungen, die ich doch so einfach wie möglich geschrieben habe, nicht verstanden? Nochmal: Der DC in der Zentrale muss nicht aktualisiert werden. Der kann weiter unter Windows 2003 betrieben werden. Dann verschiebst du die Rollen einfach nicht und belässt sie weiterhin auf dem 2003er DC in der Zentrale. Es ist kein muss, dass die Rollen verschoben werden müssen. Wenn du allerdings in der Zukunft auf ein Problem stößt und die Lösung in den "neuen" Gruppen steckt, müssen die FSMO-Rollen dann auf einen 2008 R2 DC verschoben werden. Es ist deine Entscheidung, aber du scheinst mich nicht zu verstehen...

Ich hingegen, "glaube" es nicht nur. ;) Und abgesehen davon: Glauben tut der Pfarrer. Wenn du meinen Worten lauschst, wird es gut gehen.

... warum du ihm das "so" andrehen möchtest! Wenn der erste Windows Server 2008 R2 zur Domäne, als zusätzlicher DC hinzugefügt werden soll, muss doch keineswegs der bestehende Rolleninhaber auf Windows Server 2008 R2 aktualisiert werden! Wie kommst du denn darauf?! Der bestehende Rolleninhaber kann natürlich weiterhin unter Windows Server 2003 betrieben werden. Nur die FSMO-Rollen sollten eben auf den 2008 R2 verschoben werden. Nicht mehr und nicht weniger!

Ja, der Rollenionhaber kann weiterhin der Windows Server 2003 DC bleiben. Aber dann werden die neuen Gruppen nicht erstellt, die erst erstellt werden, wenn der PDC-Emulator verschoben wird. Denn dieser ist dafür zuständig (beachte dazu den dritten Link aus meiner vorherigen Antwort!) Muss nicht, aber es ist auch kein Nacheil wenn du die Rollen verschieben würdest, was zu empfehlen wäre. Die Rollen können ja jederzeit verschoben werden.

Servus, du musst(!) sogar zwingend das ADPREP, zuerst mit dem Parameter /FORESTPREP auf dem Schemamaster und dann mit dem Parameter /DOMAINPREP /GPPREP auf dem Infrastrukturmaster ausführen. LDAP://Yusufs.Directory.Blog/ - Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen Anschließend verschiebe noch die FSMO-Rollen auf den neuen DC. LDAP://Yusufs.Directory.Blog/ - Die FSMO-Rollen verschieben Warum? Darum --> LDAP://Yusufs.Directory.Blog/ - Der PDC-Emulator

Bonjour, und dann?

Servus, bei der Authentisierung eines Clients, ist das DNS und das Desgin im Snap-In "Active Directory-Standorte und -Dienste" entscheidend. Falls AD-Standorte eingerichtet werden sollen, darf das erstellen der jeweiligen Subnetze und das verknüpfen an den entsprechenden AD-Standorten nicht vergessen werden. Natürlich müssen dann noch die DC-Icons an ihre AD-Standorte, in der MMC "Active Directory-Standorte und -Dienste" verschoben werden. Alles weitere erfährst du hier: LDAP://Yusufs.Directory.Blog/ - Domänencontroller am Standort

Salut, ja, dass ist so korrekt. Das ist "by Design" so und ist auch weiter nicht tragisch.

Servus, sind diese Clients zufällig geimaget und falls ja, wurde SYSPREP angewendet? Dieses Verhalten kenne ich nur bei geimageten Clients.

Hola, Das trifft aber auf jede Microsoft Prüfung zu. Wer die Betaphase intensiv genutzt hat, der hat mehr als ein Jahr praktische Erfahrung. ;)

Servus, kann es sein, dass der KB-Arikel eigentlich schon hilft, aber du ihn nicht genau interpretieren kannst? ;) In der FehlerID 1988 stehen doch die Lingering Objects (LOs), zu Deutsch herumlungernde Objekte. Diese Leichen lassen sich auch mit ADSIEdit aus dem AD entfernen. Wenn mehrere herumlungernde Objekte existieren, solltest du den folgenden Befehl in der Kommandozeile ausführen: REPADMIN /removelingeringobjects /advisory_mode. Arbeite sorgfälltig den folgenden Artikel durch: LDAP://Yusufs.Directory.Blog/ - Lingering Objects (veraltete Objekte) Die entscheidende Frage, warum sich die DCs "plötzlich" nicht mehr replizieren, sollte man sich aber in jedem Fall stellen. Denn was hilft es die LOs zu entfernen, wenn sie im nächsten Moment wieder entstehen. Ursachen-Forensik solltest du betreiben.

Servus jpanse, du bist aber immer noch nicht auf den Zaunpfahl, mit dem Norbert, mit dem folgenden Zitat dir zugewinkt hat eingegangen: Unser einer würde dir besser helfen können, wenn du eine genauere Fehlerbeschreibung liefern würdest. Das wollte dir Norbert sagen, ich kenne meinen Bruda. ;)

Na das er am Ende keinen Forwarder mehr eintragen kann und muss. :cool:

Prima, ich habe auch nichts anderes erwartet. :p Null problemo (würde Alf sagen) und danke für die Rückmeldung. Gruß, Yusuf ... der sich wünscht, dass jeder immer eine Rückmeldung geben würde, die für uns Helfer wichtig ist!

Natürlich funktioniert das! Sonst würde ich es doch nicht schreiben. ;) Das hat man dir auch angemerkt. :) So isses. Windows, weißt du. :cool: You are welcome und weiterhin viel Erfolg. Happy weekend!

Servus, hast du dein Problem nicht bereits "dort" gelöst? Domain Controller sehr trge - Windows Server - administrator

Salve, garnicht! Eine Schemaänderung kann nicht einfach wieder rückgängig gemacht werden, außer du führst ein Forest-Recovery durch, was keiner möchte. Eigene hinzugefügte Attribute kann man nicht löschen, höchstens deaktivieren. Aber zumindest "Schaden" sie auch nicht. Du kannst weitere, diesmal mit korrekten Namen erstellen und beim nächsten Mal besser aufpassen.

Servus, nach einer Sicherung kannst du auch die AD-Datenbank auf Schäden überprüfen und evtl. mit einem FIXUP beheben. LDAP://Yusufs.Directory.Blog/ - Die Active Directory-Datenbank reparieren

In welcher Domäne möchtest du denn bitte schön eine Domänenaktualisierung durchführen? Das ist nicht notwendig! Es existiert die Windows Server 2003 Quell-Domäne in Polen und eine Windows Server 2008 Zieldomäne in Deutschland. Nun erstellst du in Polen auf einer weiteren Maschine, die Subdomäne innerhalb der deutschen Gesamtstruktur. Aber eine Subdomäne ist "bisher" keineswegs notwendig. Du kannst auch lediglich in Polen zwei weitere Server installieren und diese zur bestehenden deutschen Windows Server 2008 Domäne als zusätzliche DCs (oder RODCs) hinzufügen. Erst erstellst du mit einem DC die Subdomäne und erstellst anschließend die Vertrauensstellung mit dieser Subdomäne. Wie gesagt, wennn es keine zwingende Gründe für eine Subdomäne gibt, lass es sein. Oder such dir besser einen Dienstleister der dir die Arbeit abnimmt.

Servus, warum installierst du nicht gleich in Polen die Subdomäne, erstellst eine Vertrauensstellung mit der polnischen Domäne und migrierst die AD-Objekte mit ADMT? Warum die Subdomäne zuerst in Deutschland installieren und nicht gleich vor Ort in Polen? Das bringt dir ohnehin nichts, da du ja die bestehende polnische Domäne als Subdomäne (das solltest du dir nochmals überlegen) in dem deutschen Forest installieren möchtest. Es gilt aber tatsächlich zu klären, ob du wirklich eine Subdomäne benötigst. Es gibt weitaus größere weltweite Umgebungen, mit nur einer Domäne!

Servus, der folgende Link sollte nicht unerwähnt bleiben. ;) Dort kannst du nachsehen, welche Einstellungen in welcher GPO konfiguriert werden können. Group Policy Search

... oder entfernt die Gruppe „Authentifizierte Benutzer“ aus der GPO. ;)