Daim

Wegen dem SYSVOL musst du nicht gleich dein AD neu aufsetzen. Auch wenn du am ende des Latain wärst, würde ich als allerletzten Griff zum höerr greifen und den Microsoft Product Support Service anrufen. Dieser kostet dann zwar ca. 300 Euro, aber damit lösst sich dann das Problem mit hoher Wahrscheinlichkeit und du hast die ne Menge Arbeit gespart. Nein, nicht normal. Vorallem diese Meldung ist nicht ok. Gehe in der Kommandozeile mal auf C:\%windir%\sysvol\sysvol\ und gib dort ein DIR ein. Nun solltest du so etwas sehen: <DIR> . <DIR> .. <Verbindung> <Domäne> Auch das Access Denied ist nicht ok. Kontrolliere mal die ACL vom SYSVOL. Schritt für Schritt geht es vorwärts ;).

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".

Überprüfe auf diesem DC (Server1) 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). Wenn das alles soweit in Ordnung ist, stoppst du auf allen DCs in der Domäne den NTFRS Dienst. Gehe dazu auf auf den DCs in die Kommandozeile (CMD) und gib folgenden Befehl ein: "net stop ntfrs". Auf dem DC der komplett ist (das dürfte bei dir Server1 sein) setzt du unter folgendem Registry-Pfad "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets" den Schlüssel Burflags D4. Auf den anderen DCs entfernst du die beiden Ordner Policy sowie Script (unter SYSVOL) und setzt unter dem gleichen Registry-Pfad den Schlüssel Burflags D2. Danach startest du ZUERST auf dem DC01/Server1 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.

Servus, du fügst quasi den SBS in die bestehende AD-Domäne als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Vorher führst du auf dem 2000er Schema-Master das ADPREP von der SBS-CD aus und zwar zuerst mit dem Schalter /FORESTPREP und dann mit dem Schalter /DOMAINPREP. Danach verschiebst du die FSMO-Rollen auf den SBS. Für alles weitere, siehe unten stehende Artikel. Yusuf`s Directory - Blog - Die Besonderheiten eines Small Business Server`s (SBS) How to install Small Business Server 2003 in an existing Active Directory domain

So kann man es auch formulieren ;). ... nicht wirklich. Dann wende noch dieses Tool an (bitte vorher die Anwendungsweise lesen): Link Shell Extension Junction Points sind eine Art Link zum Original bzw. Spiegelbild. Jede Änderung am Junction Point wird direkt am Original vorgenommen. Ergo existiert das Original auch nur einmal. Hier ist beschrieben wie man z.B. NTFS Junction Points erstellt/löscht/manipuliert: How to create and manipulate NTFS junction points Für das SYSVOL-Verzeichnis, ist dieser Artikel relevant. Daran musst du dich halten: How to rebuild the SYSVOL tree and its content in a domain

Server1 muss nur dann rein, wenn dieser auch ein GC ist! Man kann diesen zwar händisch im DNS hinzufügen, doch wenn es sauber laufen soll - dann hätte dies automatisch (siehe meinen Artikel) geschehen sollen... Versuche die Junction Points mit diesem Tool zu setzen. Evtl. hat man damit mehr Glück. Junction Link Magic

Gerade frisch aus der Presse ;). Yusuf`s Directory - Blog - Globaler Katalog – Sein oder nicht sein

Servus, der Fehler 13508 ist lediglich ein Folgefehler. Das Ursprungsproblem ist, dass der DC seinen Replikationspartner per RPC nicht erreichen kann. Das deutet auf DNS sowie Replikationsprobleme hin. Hier wird der GC nicht erreicht. Falls nicht alle DCs auch GCs sind, solltest du das jetzt nach holen. DNS ist hierbei elementar. Denn wenn der DC zum gC deklariert wurde, trägt dieser sich mit seinen SRV-Records im DNS ein. Die Replikation ist natürlich genauso wichtig. Es fehlen auch noch die Junction Points. Du brauchst das Tool Linkd dazu und musst folgendes ausführen: Linkd %Systemroot%\SYSVOL\SYSVOL\<DNS-Domänenname> C:\windows\sysvol\domain Linkd %Systemroot%\SYSVOL\staging areas\<DNS-Domänenname> C:\WINDOWS\SYSVOL\staging\domain How to rebuild the SYSVOL tree and its content in a domain Du hast ein bisserl Arbeit vor dir. DCDIAG, NetDIAG sowie REPADMIN sind deine Freunde. Das Eventlog natürlich auch.

... die SRV-Einträge sind dort also vorhanden? Ansonsten installiere dir die Windows Support Tools und lass mal DCDIAG laufen.

Na ob z.B. die ganzen Unterordner _sites _tcp _udp usw. unterhalb deiner FLZ existieren. Im Ordner _tcp müssen vier Einträge existieren, nämlich die, die der Client bei der Anmeldung vom DC zwingend braucht. Diese wären: _gc _kerberos _kpasswd _ldap

Servus, das liegt mit Sicherheit am DNS. Kontrolliere im DNS ob die SRV-Records existieren. Wie sieht das Eventlog aus? DC2 muss (sofern dann auf DC1 alles i.O. ist) auf Port 53 den DC1 auf alle Fälle erreichen können.

Moin, ... nur der vollständigkeitshalber ;). Yusuf`s Directory - Blog - Active Directory Replikation durch eine Firewall

Moin, schau mal hier: Yusuf`s Directory - Blog - Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)

Aloha, genau so wie es grizzly treffend erwähnt hat. Das Stichwort lautet: Eingeschränkte Gruppen. Hier noch ein weiterer Link: Gruppenrichtlinien - Übersicht, FAQ und Tutorials Richtig. Meine Finger hatten zwar korrekt zitiert, doch meine Hirnwindungen nahmen an, dass Du einen BENUTZER aus der Root, zum Domänen-Admin in der Child deklarieren wolltest. Die Lösung liegt in grizzlys Antwort.

Servus, Domänen-Admins ist eine globale Sicherheitsgruppe und eine globale Gruppe kann lediglich nur Objekte aus der eigenen Domäne enthalten. Du solltest dich an das A - G/U - DL - P Prinzip halten. Yusuf`s Directory - Blog - Gruppen Das bedeutet: Du musst die Gruppe "Domänen-Admins" der Hauptdomäne in die Gruppe "BUILTIN\Administratoren" der Unter1-Domäne einfügen, um dein Ziel zu erreichen. Sicherheitstechnisch ist das aber nicht gerade ideal...

So so.... hat es sich das ? RAS Clients Receive 127.0.0.1 for DNS Server Address

Servus, wie soll man dir - hier - ohne die Umgebung zu kennen - was - wie - wo - implementiert wurde, helfen

Servus, da hätte man darauf achten müssen. Da gab es anscheinend Replikationsprobleme und ist nicht aufgefallen. Stichwort: Lingering Objects Yusuf`s Directory - Blog - Lingering Objects (veraltete Objekte) Korrekt. Das hätte dir auch nichts gebracht in diesem Fall. Denn das SP2 MUSS auf dem allerersten DC in der Gesamtstruktur installiert worden sein, der dann zu DC gestuft wird. Denn es ist wirklich so, dass mit dem SP2 der Fehler im R2 mit der zweiten CD gefixt wurde. Aber wie gesagt, dass bedeutet, der ERSTE DC einer mit dem man die (neue) Gesamtstruktur erstellt muss das SP2 installiert haben, um nach dem heraufstufen zum DC die 180 Tage für die Tombstone Lifetime zu haben. Siehe: The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2 Schau dir den o.g. Link an. Wie gesagt, es kommt darauf an, wie die Gesamtstruktur erstellt wurde und auch dann, wird in dem Attribut die 180 Tage nicht angezeigt. Das ist Standard.

Servus, wenn du keine NT-BDCs mehr in deiner Domäne hast, stufe zuerst den Domänenfunktionsmodus auf "Windows Sercver 2003", dann die Gesamtstruktur auf "Windows Server 2003" damit du die Vorteile die dir dieser Modus bietet, nutzen kannst (verbesserte AD-Replikation, LVR, bessere Nutzung von Gruppen usw.). Das hochstufen des Modus betrifft die DCs, weder die Clients noch die Memberserver merken etwas davon. Das Heraufstufen kannst du während dem laufenden BEtrieb erledigen. Es sind quasi "zwei Klicks". Ansonsten lies dir hier meine Antwort durch: http://www.mcseboard.de/windows-forum-ms-backoffice-31/2000-gemischt-2003-a-114546.html#post706764

Noch ein Nachtrag zu oben stehender Aussage: Für das dynamische DNS Update ist nicht etwa wie es zu erwarten wäre der DNS-Client zuständig, sondern ein DDNS fähiger DHCP-Client (so wie er in den Windows Betriebssystemen existiert). Trotzdem solltest du sicherheitshalber deine DCs mit DCDIAG /v sowie NetDIAG /v überprüfen. Beide Tools befinden sich in den Windows Support Tools, die sich wiederum auf der Windows Server 2003 CD befinden.

Servus, kurz zur Erklärung zu dem Vorgang: Das Herauf stufen des Domänen- bzw. Gesamtstrukturfunktionsmodus betrifft in erster Linie die DCs. Memberserver sowie Clients sind davon ausgenommen und spielen bei diesem Vorgang keine Rolle. Der Domänenfunktionsmodus sowie Gesamtstrukturfunktionsmodus "Windows Server 2003" sollte auf alle Fälle eingesetzt werden, um von den Vorteilen die dieser Modus bietet zu profitieren (AD-Replikation, LVR ...usw.). Ein Zurückstufen der Ebenen, sei es der Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus ist im Nachhinein aber nicht mehr möglich! Daher sollte zukunftsorientiert dieser Vorgang vollzogen werden. Das Herauf stufen des Domänenfunktionsmodus kann entweder über das Snap-In „Active Directory-Benutzer und –Computer“ oder „Active Directory-Domänen und -Vertrauensstellungen“ erledigt werden (mit einem Rechtsklick auf den FQDN), wobei die Gesamtstruktur ausschließlich im Snap-In „Active Directory-Domänen und -Vertrauensstellung“ herauf gestuft werden kann. Beides lässt sich ebenfalls durch bearbeiten (mit LDP.exe oder ADSIEdit.msc) des Attributs msDS-Behavior-Version herauf stufen. Siehe auch: How to raise domain and forest functional levels in Windows Server 2003 Welche Funktionen in den einzelnen Ebenen de- bzw. aktiviert sind, kann man hier nachlesen: Microsoft Corporation Des Weiteren kann jederzeit, bei einer bereits existierenden Vertrauensstellung z.B. zwischen einer Windows 2000/2003- und einer NT-Domäne, der Domänenfunktionsmodus der Windows 2000/2003 Domäne herauf gestuft werden. Dieser Vorgang hat auf die Vertrauensstellung keinen Einfluss.

In den TCP/IP-Einstellungen der DCs kannst du als "Bevorzugter DNS-Server" bei Windows Server 2003 jeden selbst mit der echten IP-Adresse eintragen. Idealerweise trägst du aber einen zentralen (z.B. DC1) als bevorzugten DNS-Server ein und als zweiten DNS, den DC selbst. Den Clients verteilst du beide DNS-Server (statisch oder per DHCP).

Gewöhne dir das "PDC" sowie "BDC" ab. Ab Windows 2000 Server sind es alle DCs ;). Dann führe das aus, was in diesem Artikel steht: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Falls der zweite Server der ERSTE - R2 - DC werden soll, dann musst du das ADPREP mit dem Schalter /FORESTPREP auf dem Schema-Master zuerst ausführen.

OK. Schön das es funktioniert. Mit den Fehlermeldungen sowie Event IDs lässt sich das ganze auch recht einfach nachvollziehen.

Dieser zweite Eintrag soll entfernt werden ? Kannst du diesen händisch (Rechtsklick auf diesen Eintrag - Löschen) nicht löschen ? Ist das DNS sauber? Führe mal eine Semantic Database Analysis durch und falls Fehler gemeldet werden, führe ein FIXUP durch. Yusuf`s Directory - Blog - Die Active Directory-Datenbank reparieren Falls das nicht geholfen hat, gehe diese Artikel mal durch: Namenskonflikt in Active Directory verursacht Replikationsfehler