Daim

Aloha, da kann ich nur sagen, der Kandidat hat 100% Recht ;). Das ist ja genau das Problem der Autorisierung des DHCPs im AD. Im Prinzip ist der schuldige, der Windows Client. Denn dieser dürfte eben von keinem anderen DHCP-Server eine IP annehmen bzw. von keinem DHCP-Server, der nicht im AD autorisiert ist. Und was macht unsern Windows -Client? Richtig, er kümmert sich "nullinger" darum, WER ihm eine IP zuweißt. Genau da liegt das Problem. Die Autorisierung schützt lediglich (wenn man das so sagen kann) das AD, das keine wildgewordenen DHCP-Server eben in einer AD-Domäne DHCP-Server sein dürfen. Hängt man einen Router ins Netz, verteilt dieser wunderbar die IPs und die Suche nach dem Übeltäter kann losgehen.

Servus, kannst du mir einen vernünftigen Grund dafür nennen ?

@Morpheus Wie wäre es, wenn du für Serverhowto.de über den MIIS einen Artikel schreiben würdest ? Ich für meinen Teil fände es für hochspannend.

Servus, den internen Domänennamen kann man so wählen, wie der externe Internet-Auftritt. Bedeutet aber, dass die externen Ressourcen im internen DNS eingepflegt werden müssen. Das bedeutet, richte in der Forward Lookup Zone einen A-Record mit dem Eintrag "www" und nimm als IP-Adresse, die externe IP-Adresse der Webseite. Na klar, siehe oben. Was das Thema "Domäne umbenennen" betrifft kann ich ebenfalls davon nur abraten. Nicht wenn es nicht zwingend sein muss oder es um "Leben oder Tot" geht ;). Wenn man doch diesen Schritt gehen sollte, gibt es einiges zu beachten. Siehe: Yusuf`s Directory - Blog - Fehler beim ausführen von DCPROMO Das Tool heißt im übrigen "RenDom".

Hallo, Du musst das ADPREP von der _zweiten_R2 CD ausführen und nicht von der ersten: Wie aktualisiert man einen Domänencontroller unter Windows Server 2003 auf Windows Server 2003 R2? - faq-o-matic.net Führe auf dem Schemamaster das ADPREP mit dem Schalter /FORESTPREP aus. 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 Siehe: Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2

Genau so solltest du Vorgehen. Beide DCs ausschalten und ein paar Tage überprüfen ob das Netz noch ordnungsgemäß funktioniert. Na das ist aber zuckersüßer Honig für meine Ohren :cool: . Es ist auch für uns immer wieder schön, solche Worte zu lesen. Jeder hilft hier während seiner Freizeit, umso mehr finde ich es für notwendig den Experten Infos zukommen zu lassen. Sei es, dass der Tipp geholfen hat (denn das muss der Expert wissen um sich das zu merken und weiter empfehlen zu können) oder sei es ein einfaches "Danke schön, es hat funktioniert". Das ist dann quasi unsere "Bezahlung". Dann viel spass noch weiterhin und du weißt, wo du uns findest.

Ich sehe das erleichterte Grinsen bis hier her ;). Na wer sagt`s denn. So muss das sein!

Schade aber auch, oder zum Glück für dich ;). Jetzt werden wir den genauen Grund leider nicht erfahren, aber so ist es nun mal in der IT. Es gibt Dinge, die kann man einfach nicht erklären. Behalte das aber im Auge. Kontrolliere die kommenden Tage das Eventlog. Des Weiteren prüfe den DC auch mit DCDIAG/NETDIAG ob nun auch wirklich alles ok ist. Führe die Tools ein paar Tage bewußt aus, min. einmal täglich.

Dann bleibt nur noch zu erwähnen, dass im Fall der Fälle, du ohne Support von Seiten Microsoft stehst.

Jetzt mal gaaaaannzz langsam und tief Luft holen. Was ist denn der ganze Zweck dieser Übung? Ich vermute mal, der einzig bestehende DC (was an dieser Stelle gesagt sein; Das ist genau ein DC zu wenig) hat Probleme und er soll ein weiterer DC hinzugefügt werden. Wenn nun der 2000er DC und somit die Domäne in einer VM läuft, dann brauchst du doch nur lediglich die neue Maschine mit in die Domäne aufzunehmen. Falls es sich dabei um eine Windows Server 2003/R2 Maschine handelt, musst du vorher auf dem 2000er DC das ADPREP mit dem Schalter /FORESTPREP, gefolgt vom Schalter /DOMAINPREP von der Windows Server 2003 CD (bei R2 von der zweiten CD) ausführen.

Dann nimm die V. 2.0 Download details: Active Directory Migration Tool v.2.0

Servus, wenn sich die Clients an diesem DC anmelden können, somit also die "alte" Domäne wieder vorhanden ist, dann könntest du mit ADMT die Benutzer- sowie Computerkonten von der "alten" Domäne, in die neue Domäne migrieren. Siehe: Yusuf`s Directory - Blog - Benutzermigration mit ADMT v3: How-To

Nein, kein "muss". Ich würde es zumindest nicht ausschließen.

Aloha, aber auch der FRS ist nicht zu verwechseln, mit der AD-Replikation. Für die AD-Replikation verwendet man z.B. die Tools Replmon sowie RepAdmin. Für die NTFRS-Replikation (das für die SYSVOL-Replikation zuständig ist), wären dann die Tools Sonar, Ultrasound, FRSDiag oder NTFRSUTL zu verwenden.

Servus, nein, ist sie nicht!

Doch ;). Mit Sicherheit :cool: .

Du meinst, wenn das Kennwort auf dem PDC-Emulator nicht mehr aktuell wäre? Wenn der PDC-Emulator sich selber nicht mehr kennt bzw. sein eigenes Computerpasswort zwischen AD und Registry nicht mehr synchron ist (sehr selten) muss man auf ihm NetDOM gegen ihn selber laufen lassen. Bis Windows 2000 SP1 hatte man empfohlen, dass wenn das Kennwort auf dem PDC-Emulator zurückgesetzt werden muss, dass man vorher die Rolle des PDC-Emus auf einen anderen DC verschiebt, dass Kennwort zurücksetzt und danach erneut die Rolle zurück verschiebt.

Korrrrrekt, dass ist mein Nick ;). Genau so sieht es aus. Der Auslöser ist der Fehler mit der ID 13568. Der Fehler 13508 ist ein "Folgeproblem". Genau. Du kannst die Burflag- (lies dazu den KB-Artikel) oder den "Enable Journal Wrap Automatic Restore" Schlüssel (dieser wurde bis Windows 2000 SP3 empfohlen, wobei er heute mit 2003, immer noch funktioniert) setzen. Kein Problem, ist ja auch ein komplexer Vorgang und dafür braucht es kein Sorry! Nicht dafür ;). Dazu sind wir hier.

Ahaa... na dann ist ja meine Welt wieder in Ordnung ;). Ich hatte es bisher noch nicht erlebt, dass der Fehler 13508 ohne den Fehler 13568 erscheint. Aber gut das wir darüber gesprochen haben ;) .

Ist der DC nun ein GC bzw. gibt er sich auch als GC im AD/DNS bekannt ? Mach mal ein TELNET DC-NAME 3268 in der Kommandozeile. Falls danach ein blinkender Cursor erscheint, horcht der DC auf Port 3268. Kontrolliere zusätzlich das DNS, ob sich der DC mit seinen SRV-Records als GC eingetragen hat. Der Fehler 13508, 13509, 13568 u.v.m. deuten auf Probleme des System Volume - SYSVOLs hin. Nein, nicht den Fehler 13508. Der Fehler 13508 gibt an, dass sich der DC, genauer der NTFRS, sich nicht mit dem DC gegenüber replizieren konnte. Das ist hier genau das PRoblem. Warum konnte er sich nicht mit dem gegenüber replizieren. DAs kann viele Ursachen haben, was es aufzuspüren gilt. Gehe einfach diesen Artikel durch (13508 ohne 13509). Betriebshandbuch für Active Directory: Problembehandlung für den Dateireplikationsdienst Genau, dass liegt am DNS. Der Client ist auf folgende DNS-Records angewiesen: - _kerberos - _ldap - _kpasswd - _gc Kontrolliere das DNS, ob dort der neue DC drin steht. Hatte ich schon erwähnt, dass das DNS elementar ist ? ;-) Wenn lediglich 13508 erscheint, brauchst du Burflags nicht zu setzen. Das hat/muss andere Ursachen haben.

Null Probleme - würde Alf sagen ;). Yepp, mach das. Aber richte dich schon mal darauf ein, dass du einiges vor Dir hast.

Sorry wenn ich das so sage, aber du hast mehrere Probleme. Das DNS ist dabei elementar. Das scheint wohl am wenigsten OK zu sein. Dort solltest du zuerst anfangen. Das DNS sollte auf allen DCs installiert werden und die Forward Lookup Zone sollte AD-integriert gespeichert sein. In den TCP/IP-Einstellungen der DCs steht als "Bevorzugter DNS-Server" eine echte IP-Adresse und nichr die Localhost-Adresse. Führe ein DCDIAG /FIX sowie NETDIAG /FIX aus.

Auf den anderen DCs der Domäne entfernst du den Inhalt der beiden Ordner Policy sowie Script und setzt unter dem gleichen Registry-Pfad den Schlüssel Burflags D2. Danach startest du ZUERST auf dem vollständigen DC den NTFRS-Dienst (net start ntfrs) und wartest ein paar Minuten. Es muss zwingend der Event-Eintrag 13516 protokolliert werden. Wenn dieser erschienen ist, startest du auf den anderen DCs den NTFRS Dienst. Danach gedulde dich ein wenig und überprüfe ob die Replikation stattfindet. Wenn das alles funktioniert, überprüfe ob das SYSVOL freigegeben wurde, den Inhalt stimmt und die Junction Points existieren. Vor allen dingen behalte das Eventlog im Auge. Der relevante Artikel an den du dich zu halten hast, ist dieser: How to rebuild the SYSVOL tree and its content in a domain Ergänzung: Unter dem Registry-Pfad befindet sich unter der Ebene "Cumulative Replica Sets" eine GUID. Siehe: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\<GUID> Unter "Cumulative Replica Sets" existiert i.d.R. EINE GUID, diese ist diejenige für das SYSVOL und dort erstellst du dann den Burflags Schlüssel (ist auch im erwähnten Artikel beschrieben). Wäre DFS noch im Einsatz, gäbe es noch einen weiteren Eintrag mit einer anderen GUID. Nach dem Start von NTFRS bleibt den Burflags Schlüssel vorhanden, nur der Wert wird "genullt". ... to be continued.

NSLOOKUP bringt dann ebenfalls keine Fehler...? Wenn im Dateireplikationsdienst-Protokoll die Event-ID 13568 (Journalumbruch-Fehler) auf einem DC protokolliert wird, liegt ein Problem mit dem System Volume-Verzeichnis (SYSVOL) vor. Das SYSVOL stellt eine Sammlung von Dateien, Ordnern und Bereitstellungspunkten (Junction Points) im Dateisystem dar. Es ist ein freigegebenes Systemvolume auf Domänencontrollern worin sich Gruppenrichtlinienobjekte, Gruppenrichtlinienvorlagen, Anmeldeskripte und weitere Dateien befinden. Dieses Verzeichnis wird auf alle anderen Domänencontroller der Domäne repliziert. Das SYSVOL-Verzeichnis wird vom File Replication Service (NTFRS.exe) und nicht durch die Active Directory-Replikation repliziert. Sobald eine Änderung in diesem Verzeichnis auftritt, repliziert der FRS automatisch diese Änderung auf die anderen Domänencontroller. Wenn es um das Troubleshooting des FRS geht, sind die Tools: Sonar Download details: Sonar.exe: File Replication Service (FRS) Status Viewer Ultrasound Download details: Ultrasound - Monitoring and Troubleshooting Tool for File Replication Service (FRS) FRSDiag Download details: File Replication Service Diagnostics Tool (FRSDiag.exe) NTFRSUTL Download details: Windows Server 2003 Service Pack 1 32-bit Support Tools hilfreich. In der Beschreibung des Fehlers 13568, wird auch gleich die Lösung mitgeliefert. Diese lautet: Führen Sie regedit aus, um diesen Registrierungsparameter zu ändern. Klicken Sie auf "Start", dann auf "Ausführen", und geben Sie dann "regedit" ein. Erweitern HKEY_LOCAL_MACHINE. Folgen Sie folgendem Pfad: "System\CurrentControlSet\Services\NtFrs\Parameters" Doppelklicken Sie auf den Namen des Wertes "Enable Journal Wrap Automatic Restore" und aktualisieren Sie den Wert. Ist der Name des Wertes nicht vorhanden, können Sie ihn mit dem Befehl "Neu" und dann "DWORD-Wert " im Menü "Bearbeiten" hinzufügen. Geben Sie den Wert genauso ein wie oben gezeigt. Mit diesem Registry-Eintrag wir eine nicht autorisierte Wiederherstellung des SYSVOLs durchgeführt. Dieses macht natürlich nur dann Sinn, wenn es mehr als einen DC gibt. Der Reg.-Schlüssel "Enable Journal Wrap Automatic Restore" wird aber seit Windows 2000 SP3 von Microsoft nicht mehr empfohlen. Wobei er aber auch HEUTE noch unter Windows Server 2003 funktioniert. Überprüfe also zuerst: - Überprüfe auf den DCs, ob das SYSVOL Verzeichnis komplett (Skripte und Policys vorhanden?) sind und auch freigegeben ist (net share). - Prüfe des weiteren ob die Junction Points existieren (CMD - C:\%windir%\sysvol\sysvol\ dort ein dir ausführen). Im Idealfall sollte das alles auf einem der DCs der Fall sein. Wenn das alles soweit in Ordnung ist, stoppst du auf allen Maschinen den NTFRS Dienst. Gehe dazu auf den DCs in der Kommandozeile (CMD) und gib folgenden Befehl ein: "net stop ntfrs". Auf dem DC, der alle Vorraussetzungen erfüllt (also alles vorhanden ist) setzt du unter folgendem Registry-Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\<GUID>" den Schlüssel Burflags D4. ...to be continued.

Aloha, Dann hätte man (je nachdem) erstmal die bestehenden DCs richtig konfigurieren sollen, um eine saubere Ausgangsbasis zu schaffen. Scheinbar ja doch nicht... Kontrolliere auf DC3 ob der Registry-Eintrag "Global Catalog Promotion Complete" im Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters mit dem Wert 1 existiert. Falls nicht, ist der DC noch kein GC. Yusuf`s Directory - Blog - Globaler Katalog – Sein oder nicht sein Falls der Schlüssel dort nicht existiert, setze mal diesen Schlüssel und starte den DC neu: HKLM\System\ CurrentControlSet\Services\NTDS\Parameters\Global Catalog Partition Occupancy mit DWORD 1. Nach einem Neustart "sollte an gleicher Stelle in der Registry, dieser Schlüssel auftauchen "Global Catalog Promotion Complete". Das sind aber völlig verschiebene Probleme. Das der DC nicht als GC erkannt wird ist das eine Problem, dass sich das SYSVOL nicht repliziert, dass andere... Im übrigen ist der Fehler 13508 ein Folgeproblem. Das Ursprungsproblem dürfte auf dem DC liegen, der die Fehler-ID 13568 protokolliert. Das ist das Resultat der oben erwähnten Meldung (13508). ... to becontinued!