Daim

Das ist ja auch nicht verkehrt und eher empfehlenswert, alle Rollen auf einem DC zu haben. Ich wollte aber etwas anderes verdeutlichen. ADPREP mit dem Schalter /FORESTPREP ist idealerweise auf dem Schema-Master (also in der Root-Domäne) auszuführen. Wenn aber der erste Windows Server 2003/R2 in einer Sub-Domäne hinzugefügt werden soll, dann ist das ADPREP auf dem Infratstruktur-Master der entsprechenden Sub-Domäne auszuführen, um die Domäne zu aktualisieren ;).

Servus, richtig. Das stimmt nicht ganz. Das ADPREP ist mit dem Schalter /DOMAINPREP idealerweise auf dem Infrastruktur-Master in DER Domäne auszuführen, in der der neue (R2) Domänencontroller hinzugefügt werden soll.

Dann hast du es einfach übersehen ;). Das ADPREP bei einem Windows Server 2003 R2 befindet sich auf BEIDEN - R2 - CDs. Falls der Server mit beiden CDs installiert und dieser zu einem DC gestuft werden soll oder die R2-Features auf einem Memberserver zum Einsatz kommen sollen, dann ist das ADPREP von der zweiten CD in dem von mir angegebenen Verzeichnis auszuführen.

Wurde dieser verwaiste DC mit NTDSUTIL oder ADSIEdit aus dem AD entfernt ? Falls nicht, siehe: How to remove data in Active Directory after an unsuccessful domain controller demotion Handelt es sich denn auch um einen Windows Server 2003 R2 ? Falls ja, dann schau in dieses Verzeichnis: „CD-Laufwerk\CMPNENTS\R2\ADREP“ Siehe: Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Wie aktualisiert man einen Domänencontroller unter Windows Server 2003 auf Windows Server 2003 R2? - faq-o-matic.net

Kannst ud as etwas erläutern, was war denn der Fehler ? Du hast das ADPREP von der Windows Server 2003 CD ausgeführt und wenn es ein R2 ist, hast du ADPREP von der zweiten CD ausgeführt ? Umzustellen auf was ? Du meinst bis sich die Änderung vom ADPREP repliziert hat ? Das hängt natürlich von der Größe der Gesamtstruktur ab, wieviele DCs existieren und wie die REplikation eingestellt ist. Aber wenn man einen Tag nach ausführen von ADPREP geduldet, ist man (meistens) auf der sicheren Seite. Kontrolliere evtl. noch das ADPREP-Log. Dieses findest du unter %windir%\System32\Debug\Adprep\Logs. Evtl. findet man dort noch diverse Hinweise.

Einen Exchange Server auf einem Domänencontroller zu installieren, ist bereits nicht (von seiten Microsoft) empfohlen. Aber den "Status" eines bereits installierten Exchange Servers zu ändern, ist nicht supportet. Das bedeutet konkret, installierst du einen Exchange Server auf einem Memberserver, sollte dieser nicht mit DCPROMO zum Domänencontroller gestuft werden. Installierst du einen Exchange Server auf einem Domänencontroller, sollte dieser im nachhinein nicht heruntergestuft werden. Overview of operating system and Active Directory requirements for Exchange Server 2003 Wenn du genau nach meiner Anleitung beim reseten des Kennworts vorgegangen bist und es nicht geholfen hat, empfehle ich dir einen Call beim Microsoft Produkt Support Service zu öffnen. Das kostet weniger als 300 Euro.

Servus, AFAIK ist eine Deinstallation lediglich des R2 nicht möglich. Das ist auch nicht weiter tragisch, denn ein R2 ist nicht weiter als ein Windows Server 2003 mit integriertem SP1. Auf der zweiten R2 CDs sind lediglich die wenigen R2 Features. R2 ist keinerlei Update der Betriebssystemkomponenten. R2 müßte man eher "Feature-Pack" nennen. Die erste CD von R2 ist ein Windows Server 2003 mit Service Pack 1. Die zweite CD macht daraus ein "R2" indem Zusatzkomponenten unter Systemsteuerung - Software eingetragen werden, die man dann für bestimmte Szenarien nachinstallieren kann. Wenn Du ein R2 hast, schau mal auf die zweite CD im Ordner DOCS. Die dortige Datei R2SETUP.CHM enthält alle Informationen über R2. Microsoft Corporation Wenn das Schema mit ADPREP von der zweiten CD auch nicht angewendet wurde, ist doch alles in Ordnung. Aber auch wenn es angewendet wurde, ist es genauso wenig schlimm... Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Nur interessehalber, wie hast du es letztendlich gelöst? Das interessiert mich jetzt aber. Erkläre mal genauer, dann schauen wir mal ob es dein Kollege erledigt oder wir ;).

Dann lies dir mal diesen Artikel durch: Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Dort ist das 64Bit zwar mit 2003 erläutert, trifft aber auch für 2000 zu - zumindest mit der Trial Version. Was den Hotfix anbetrifft (was ich bevorzugen würde), frage den MS-PSS ob dieser auch für 2000 gilt.

Schon mal auf die Uhr geschaut , wann er den Post geschrieben hat, wann er zur Prüfung geht und welche Uhrzeit wir gerade haben ?

@StephenK Ich hatte dir doch schon "woanders" geantwortet. So wie blub es auch erwähnte, führe NETDOM auf dem gecrashten DC aus, damit er sich ein neues Computerkennwort verpasst. Das Zurücksetzen des Passwortes mittels NetDOM funktioniert folgendermaßen: - Den Kerberos-Dienst beenden und auf manuellen Start setzen (wegen dem folgenden notwendigen Reboot ohne diesen Dienst). - NETDOM RESETPWD /server:{PDC-Emulator} /userd:{Domänenadmin} /passwortd:{Admin-Passwort} Der DC gibt sich hiermit selbst ein neues Computer-Passwort und synchronisiert dieses sofort mit dem PDC-Emulator. - Neu booten. Der reparierte DC sollte jetzt auch ohne KDC-Dienst hochfahren und sich ein Kerberos-Ticket von einem anderen DC holen. - Nach erfolgreichem Reboot KDC-Dienst wieder starten und auf automatisch setzen

Ja. Falls aber eine große Umgebung existieren würde (viele Domänen) dann sollte man ADPREP in einer ruhigen Minute ausführen. Da zu dem Zeitpunkt wenn ADPREP ausgeführt wird, der Schema-Master "wenig" Last haben sollte (in Form von Replikation der anderen DCs).

Du hast dir den Artikel den ich gepostet hatte, durchgelesen? Der Vorgang selbst ist Stressfrei. Es kann nichts "kaputt" gehen. Du führst das ADPREP mit dem Schalter /FORESTPREP auf dem 2000er Schema-Master aus. Dann führst du das ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master aus. Wenn der 2003er ein R2 sein sollte, dann musst du das ADPREP von der ZWEITEN CD ausführen.

Servus, was die einzelnen Schritte wären, kannst du hier nachlesen: Yusuf`s Directory - Blog - Den ersten/einzigsten Domänencontroller austauschen

Nein, dass ADPREP von der zweiten CD wird dir dabei nicht helfen. Wenn APREP das Problem wäre, würde die Meldung anders lauten. Fordere Dir kostenlos den Hotfix vom Microsoft Produkt Support Service an (MS-PSS) an.

Servus, du führst das ADPREP von der Windows Server 2003 CD auf dem Schema-Master direkt aus? Der Schema-Master ist online und hat keine Netzwerk-Probleme? Wenn die 2003er Server - R2 - Server sind, dann brauchst du das ADPREP von der zweiten R2 CD. Dieser Hotfix könnte helfen: Enhancements to Adprep.exe in Windows Server 2003 Service Pack 1 and in hotfix 324392

Moin, den hier habe ich gerade gefunden: Microsoft Corporation P.S. Was es nicht alles für Microsoft-Artikel gibt ;).

Man kann natürlich vor der Reise die Tombstone Lifetime händisch auf einen höheren Wert setzen. Zu diesem Zeitpunkt sollten aber alle DCs online sein, damit sich die Information repliziert. Die generelle Empfehlung ist eben, nicht an der Tombstone Lifetime rumzuschraueban, da es i.d.R. nicht nötig ist. Kann man aber natürlich so machen. Aber wie bereits erwähnt, der ganze Vorgang ist ja nicht in Ordnung. Entweder stuft man die Server erst am Zielort zu DCs oder warum sind die Maschinen so lange unterwegs... usw.

Dazu brauchst du das Tool NETDOM das sich in den Windows Support Tools befindet. Über das Snap-In "Active Directory-Benutzer und -Computer" lässt sich nur das Computerkennwort con Clients sowie Memberservern zurücksetzen, nicht aber von Domänencontrollern. Bei DCs kann man das Computerkennwort lediglich über das Tool NETDOM zurücksetzen. netdom resetpwd /s:server /ud:domain\User /pd:* How to use Netdom.exe to reset machine account passwords of a Windows Server 2003 domain controller Danke!

Was sich beides - zwar mit sehr viel Arbeit - lösen lässt. Besser wäre es gewesen, die Server nicht VOR der Reise zu DCs zu stufen, sondern erst, wenn sie an ihrem Ziel-Ort sind.

Servus, in den TCP/IP-Einstellungen steht ein interner DNS-Server mit der echten IP-Adresse (nicht Localhost) drin? Stell auch mal das SMB-Signing nach diesem Best Practise ein: Gruppenrichtlinien - Übersicht, FAQ und Tutorials NSLOOKUP bringt keine Fehler? Die Zeit auf den Systemen stimmen weitestgehend überein? Kann ich am Wochenende grillen oder regnet es?

Nur nochmals zur Erklärung: Das entscheidende ist die Tombstone Lifetime. Wenn man Objekte aus dem AD entfernt, wird das gelöschte Objekt mit einem Tombstone (Grabstein) versehen und fast alle Attribute (bis auf einige wenige) werden sofort vom Objekt entfernt (welche Attribute eines Objekts entfernt werden sollen und welche nicht, lässt sich im Schema definieren). Das Objekt wird dann im AD in den Container (den es in allen Verzeichnispartitionen gibt) "Deleted Objects" verschoben. Wenn nun (alle 12 Stunden) der Garbage Collection Prozess anläuft, werden die Objekte endgültig aus der Datenbank entfernt, die die Tombstone Lifetime überschritten haben. Ist nun ein DC länger als die Tombstone Lifetime offline, bekommt dieser die Löschungen während dieser Zeit natürlich nicht mit. Auf den anderen DCs sind Objekte bereits endgültig gelöscht worden, die aber auf dem DC der offline war, noch vorhanden sind. Wenn nun auch noch ein Objekt (z.B. ein Benutzer) auf dem DC der offline war bearbeitet wird (du trägst eine Tel.-Nr. im Benutzerobjekt ein), versucht dieser die Änderung auf seine Replikationspartner zu replizieren. Die anderen DCs sagen aber dann, was willst du eigentlich von mir, dass Objekt das du mir geben möchtest kenn ich überhaupt nicht und habe es auch nicht und verweigert somit die Replikation. Diese Objekte (Leichen) nennen sich dann Lingering Objects (herumlungernde Objekte). Die Vorgehensweise was man in so einem Moment macht, steht im meinem vorher geposteten Link.

Es sind aber keine 90 Tage, sondern 30 ;). In Windows 2000, XP und 2003 erneuert das System sein Computerkennwort alle 30 Tage. Effects of machine account replication on a domain So ist er eben ;).

Servus, es sind keine 90 Tage per default sondern 60 oder 180 Tage. Je nachdem mit welcher Version der erste DC einer Gesamtstruktur erstellt worden ist. Es wird auch nichts "gesperrt". Das zurücksetzen des Computerkontos hat damit überhaupt nichts zu tun. Höchstens das neu aufsetzen. Das musst du aber auch nicht zwangsläufig tun. Das Stichwort nennt sich: Lingering Objects Siehe: Yusuf`s Directory - Blog - Lingering Objects (veraltete Objekte) Klar, die haben das Problem ja nicht. Wie jetzt? Sind die DCs 90 Tage unterwegs?

Servus, dein Ziel solltest du auf folgende Variante lösen können: Noch eine andere Art, Benutzerprofile zu migrieren. - faq-o-matic.net