Daim

Servus, du kannst auf den Clients im folgenden Registry-Pfad den Eintrag <NoDomainUI> als Reg_DWORD mit dem Wert 1 setzen: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon Daraus kannst du dir auch eine ADM basteln und diese per GPO an die Clients verteilen. Dann muss aber für die Zukunft die Anmeldung über den UPN und nicht mehr über den sAMAccountName erfolgen.

Servus, versuche es mal hiermit: "c0070005" error message if you try to access a tab in Exchange System Manager

Die Domäne, die du unterordnen möchtest hat nur einen DC? Nicht gut. Es gibt Dienstleister die dir sehr gerne dabei helfen würden. :p Aber ok, ich verstehe schon. Dann wäre als erster Schritt eine Vertrauensstellung schon hilfreich. – Aloha, genau, aber nur ein klitzekleines bisschen länger. :D

Ahh.. ok, wenn es mehrere Standorte sind macht es eher Sinn. Aberphysikalisch sicher sollten die DCs vor Ort schon stehen. Für solche Szenarien wurde ja unter Windows Server 2008 der RODC kreiert. You are welcome. Aber warum willst du direkt die Migration beider bestehender Domänen, in eine neue Domäne anstreben? Ich hoffe dir ist klar, dass was wir hier besprechen ein ganz kleiner grober Teil ist. Ein Überprüfung der Umgebung vor Ort kann anders aussehen. Du solltest einen erfahrenen Dienstleister zur Seite holen. Der kostet dann "ein paar Euronen", kann aber am Ende jede Menge Gewinnbringend sein (z.B. das eine Fehleinschätzung abgewendet wurde). Wenn du beide bestehende Domänen in eine neue Domäne migrieren möchtest, warum sollen die Clients dann nicht mit migriert werden? Das ist doch an ADMT gerade der Vorteil. Du kannst eben auf Knopfdruck die Benutzer -sowie Computerkonten (Clients und Memberserver) in die neue Domäne migrieren, ohne das du an jeden einzelnen Client ran musst (soviel zur Theorie).

Klar, mit einer Vertrauensstellung erstellst du eine Verbindung zwischen beiden Domänen. Eine Migration möchtest du nicht durchführen, weil....?

Servus, nein, keine Chance. Wenn eine bestehende Domäne einer anderen Domäne untergeordnet werden soll, muss migriert werden (z.B. mit ADMT).

Sechs DCs für 600 Benutzer? Das ist zuviel des Guten. Auch wenn die DCs andere Aufgaben wahrnehmen, benötigst du nicht soviele DCs. Wenn der Domänenname einer der beiden Domänen für beide Organisationen akzeptabel wäre, könntest du die andere Domäne lediglich mit ADMT in die Domäne mit dem gewünschten Domänennamen migrieren. Fertig. Wenn die beiden bestehenden Domänennamen inakzeptabel wären, könntest du weiterhin die eine Domäne in die andere migrieren (mit ADMT) und könntest dann eine Domänenumbennenung durchführen. Ob dieses aber sinnvoll ist steht auf einem anderen Blatt. Der Aufwand einer Domänenumbennenung hängt davon ab, welche Applikationen eingesetzt werde. Evtl. könnte es auch sinnvoller und effektiver sein, beide bestehende Domänen in eine neue mit dem gewünschten Domänennamen zu migrieren. Das müsste eben nach einer genaueren Überprüfung der Umgebung entschieden werden.

Nein, dass "meine ich" nicht. Ich erwähne nur die Möglichkeiten die du hast. Du könntest eben die eine Domäne auflösen, in dem du die Benutzer- sowie Computerkonten in die andere Domäne migrierst. Was ist denn genau dein Ziel? 1. Lediglich aus zwei Domänen, eine Domäne zu haben und/oder 2. nach der Zusammenführung beider Domänen in eine, für beide Firmenteile einen akzeptablen Domänennamen zu wählen? Nein, DCs können nicht migriert werden. Die sind viel zu komplex. Die DCs müssen aus der alten Domäne herunter- und in der neuen Domäne heraufgestuft werden. Welche Größen haben denn beide Domänen (Benutzer, Clients, DCs)?

Servus, zum einen könnte man entweder eine externe oder ab Windows Server 2003 eine Gesamtstrukturvertrauensstellung erstellen. Das mit dem umbenennen der einen Domäne ist völliger Unfug. Durch das ändern des Domänennamen, was ohnehin kein Kinderspiel ist, entsteht keineswegs nur eine einzige Domäne. Zum anderen könntest du neben der Vertrauensstellung die eine Domäne, mit ADMT in die andere migrieren. Oder du migrierst beide Domänen in eine ganz neue Domäne. Yusufs Directory Blog - Benutzermigration mit ADMT v3: How-To

Servus, es ist zumindest eine technisch mögliche Variante. Im Übrigen bleibt noch zu klären, was genau mit "viele Probleme" gemeint ist.

Servus, ein zweiter DC wäre die empfohlene Vorgehensweise. Allerdings könntest du aber auch das System State sichern, den Server neu installieren und anschließend das System State erneut rücksichern. Dann sicherst du den Server (samt Registry) zum Zeitpunkt der Systemstatussicherung zurück. Yusufs Directory Blog - Einen Server mit rücksichern des System State zum DC stufen

Servus, das ist jetzt nicht dein ernst, oder? Keine zwei Minuten Suchen im Internet und du findest z.B. diesen Link: Microsoft Corporation Den anderen Link wirst du doch sicher alleine finden, oder?

Servus, es handelt sich um ein DNS- und/oder Verbindungsproblem. Hat denn bereits die AD-Replikation stattgefunden, so dass sich die DNS-Informationen auch auf dem neuen DC befinden? Die Forward Lookup Zone sollte idealerweise AD-integriert gespeichert sein. Eine Firewall unterbindet nicht zufällig die Verbindung? Neben dem DCDIAG das Nils erwähnte, solltest du vorallem auch das NetDIAG ausführen. Das meinte übrigens Nils mit dem "usw." (ich kann Hellsehen, daher weiß ich das ;) ).

Buenos dias, es handelt sich dabei aber um eine Domäne. Sprich, alle DCs befinden sich in der gleichen Domäne? Wenn ich das richtig verstanden habe, repliziert der sich die beiden DCs (der alte und der neue DC) in der Aussenstelle nicht miteinander. Existiert denn bei beiden DCs ein Verbindungsobjekt jeweils zum anderen DC? Prüfe beide DCs mit DCDIAG, NetDIAG und vorallem mit REPADMIN eingehender die AD-Replikation. Schließlich muss es irgendeinen Grund geben, warum sich beide DCs nicht miteinander replizieren wollen. Einen Blick in die Eventlogs der DCs solltest du dabei ebenfalls riskieren. Na, alles was nicht festgeschraubt ist. :p So könntest du es auch versuchen. Aber trotzdem überprüfe beide DCs genauer. Du könntest auch auf eine andere Weise die beiden DCs sich miteinander zum replizieren bringen (Stichwort: Lingering Objects [1]). Jedoch sehe ich bis jetzt noch keinen Bedarf dazu. Erst sollten die bisher besprochenen Punkte durchgeführt werden. [1] Yusufs Directory Blog - Lingering Objects (veraltete Objekte) Im übrigen: Die Tombstone Lifetime (TSL) wird mit dem installieren des allerersten DCs in einer Gesamtstruktur und zwar für alle Domänen festgelegt. Diese kann nicht pro Domäne konfiguriert werden. Natürlich kann aber der Wert der TSL jederzeit manuell verändert werden. Die TSL legt fest, wie lange noch ein gelöschtes Objekt im Active Directory weiterhin gespeichert wird. Denn ein Objekt wird erst nach Ablauf der TSL endgültig aus dem AD entfernt. Die TSL beträgt unter: - Windows 2000 (mit allen SPs) = 60 Tage - Windows Server 2003 ohne SP = 60 Tage - Windows Server 2003 mit Service Pack 1 = 180 Tage - Windows Server 2003 R2 mit Service Pack 1 = 60 Tage - Windows Server 2003 mit Service Pack 2 = 180 Tage - Windows Server 2003 R2 mit Service Pack 2 = 180 Tage - Windows Server 2008 = 180 Tage Kontrollieren kann man die TSL mit ADSIEdit unterhalb der Root-Domäne im folgenden Container: CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration Dort findet man in den Eigenschaften des Containers das Attribut "tombstoneLifetime". Ist dort ein Wert gesetzt, beträgt die TSL den eingetragenen Wert in Tagen. Steht im Attribut als Wert hingegen <Not Set>, so beträgt die TSL den Standardwert von 60 Tagen. Wenn mehrere DCs existieren, müssen sich die DCs mindestens einmal in der TSL mit ihren Replikationspartnern repliziert haben.

Servus, diese Handbücher sollten für den Anfang reichen. ;) Windows Server 2003 Active Directory-Betriebshandbuch: Inhaltsverzeichnis Windows Server 2003 – Schritt-für-Schritt-Anleitungen für das Active Directory Windows Server 2003 - Handbuch für die Bereitstellung: Bereitstellen von DNS Als Bücher sind diese hier für den Anfang ganz ok: Active Directory - Das Praxisbuch für Windows Server 2003 R2 von Thomas Joos erschienen bei Microsoft-Press Active Directory - Das Praxisbuch für Windows Server 2008 von Thomas Joos erschienen bei Microsoft-Press

Das schöne an ADMT ist ja, dass es die Benutzer- UND Computerkonten von einer Domäne in die andere migrieren kann, ohne das der Admin jeden einzelnen Client anfassen muss. ;)

Servus, hast du das SMB-Signing konfiguriert? Falls nicht, stelle es wie in den folgenden Artikeln ein. You cannot open file shares or Group Policy snap-ins when you disable SMB signing for the Workstation or Server service on a domain controller Yusufs Directory Blog - Zugriff auf die GPOs verweigert

Servus, korrekt, denn der Infrastrukturmaster ist in einem Single-Domänen Forest quasi Arbeitslos. Du kannst auch auf allen DCs den GC aktivieren, dass ist auch ok. Yusufs Directory Blog - Die FSMO-Rollen verschieben

Langsam ernährt sich das Eichhörnchen... Du setzt also servergespeicherte Profile ein. Natürlich werden diese nicht automatisch auf den anderen DC repliziert. Du musst diese manuell verschieben. Schau dir im folgenden Artikel den Absatz "Wie kann man servergespeicherte Profile von einem Server auf den anderen umziehen" an. Yusufs Directory Blog - Profile (lokal/servergespeichert)

Also dann wurde doch das DCPROMO bereits ausgeführt, denn der Server ist bereits ein DC. Nein. Der Server ist also doch ein DC.

Sehr gute Entscheidung. ;) Dann ist der Windows Server 2008 aber kein DC! Denn nur das installieren der Rolle "Active Directorey-Domänendienste" macht den Server noch nicht zum DC. Falls der Server ein DC werden soll, musst du das DCPROOMO ausführen. Das ist alles kein Wunder. Du hast auf dem Windows Server 2008 noch KEIN DCPROMO ausgeführt, daher ist der 2008er auch noch kein DC.

Salut, ein Cross-Update von einem 32Bit auf 64Bit Server ist ohnehin nicht supportet. Du hast also bereits auf dem Windows Server 2008 das DCPROMO erfolgreich durchgeführt? Von welchem Medium hast du denn das ADPREP ausgeführt? WO verweist WAS auf den Windows Server 2003 DC? Da gibt es nichts zu kopieren. Das muss durch die AD-Replikation durchgeführt werdn, andernfalls ist etwas nicht in Ordnung. Automatisch passiert das nicht.

OK, aber trotzdem könnte man doch versuchen die Situation zu verbessern und das Ein-Domänenmodell anstreben. Wer ist denn "an diesem DC"? Sprich, aus welcher Domäne? Ein DC der Domäne "test.bla.de" authentifiziert auch nur die Benutzer aus der Domäne "test.blu.de". Er authentifiziert keine Benutzer aus der Domäne "blu.de" oder "blubb.blu.de". Wenn ich nur ansatzweise verstehen würde, was du hiermit meinst... Erläutere das ganze doch nochmals, anhand deiner Beispiel-Domänen. Welche Sub-Domäne denn? Nichts destotrotz, immer weiter festigt sich meine Meinung das ein Single-Domänen Forest für euch das ideale wäre.

Nein, gibt es nicht. Yusufs Directory Blog - Die FSMO-Rollen verschieben Im Übrigen ist es ohnehin jederzeit sinnvoll, die FSMO-Rollen auf das neuere Server-Betriebssystem zu verschieben. Siehe dazu: Yusufs Directory Blog - Der PDC-Emulator

OK, deine leere Root-Domäne lautet also "bla.de" und die Sub-Domäne lautet "test.bla.de". Hat das einen besonderen Grund, warum ihr dieses Domänenmodell gewählt habt oder ist eure Umgebung und die Sicherheitsanforderungen so groß? Denn pauschal kann man das Ein-Domänenmodell empfehlen. Es ist leichter zu administrieren und man hat eine bessere Übersicht. OK, es soll also neben der Sub-Domäne "test.bla.de" eine weitere Sub-Domäne "blubb.bla.de" erstellt werden. Auch hier die Frage, ist das Notwendig? Rechtfertigt aber immer noch nicht das Erstellen einer weiteren Sub-Domäne. Ein DC aus der Domäne "test.bla.de" ist einzig und allein ein DC aus dieser Domäne. Möchtest du mit einem DC von "test.bla.de" die neue Sub-Domäne "blubb.bla.de" Erstellen, so musst du wie in meiner vorherigen Atwort bereits erwähnt, den DC aus der "alten" Domäne zuerst Herunterstufen. Anschließend erstellst du auf mit diesem Server die neue Sub-Domäne "blubb.bla.de". Wieviele Benutzer existieren denn in der Domäne "test.bla.de" und wieviele Benutzer sollen denn in der Domäne "blubb.bla.de" hinzugefügt werden? Umso weniger Domäne existieren, desto leichter gestaltet sich die Administration. ??? Auch die Benutzer der neuen Sub-Domäne "blubb.bla.de" können z.B. den globalen Katalog, der schließlich alle Objekte der Gesamtstruktur enthält, nach Informationen durchsuchen. Ich habe bisher Zweifel, ob ihr mit diesem Domänenmodell das richtige Design habt. Wenn die Sub-Domäne "blubb.bla.de" erstellt werden soll, muss eben vorher auf einer Maschine zuerst die Domäne kreiiert werden. Erst dann können die Benutzer- sowie Computerkonten mit ADMT in die neue Domäne migriert werden.