Konfus

Hi, keinen Bock mir den ganzen Thread durchzulesen. Also fluppt auch kein Domain Join. Schaue mal auf dem DC in der Default Domain Controllers und in der Default Domain Policy unter COMPUTERKONFIGURATION >>WINDOWS EINSTELLUNGEN>>SICHERHEITSEINSTELLUNGEN>>LOKALE RICHTLINIEN>>SICHERHEITSOPTIONEN folgende Policies an. Sollte wie folgt aussehen. Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) => deaktiviert Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)=> aktiviert Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) => deaktiviert Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) )=> aktiviert Auf dem Client sollte das im gpedit.msc genauso aussehen. mfg Konfus

Hallo, betrifft es nur die eine OU oder alle OU`s in der Umgebung? Greifen sowohl User als auch Mashine Policies nicht? In Eventvwr sollten signifikante Events getrackt sein, welche werden bei Dir geloggt. Aktiviere mal das userenv Logging gem. folgenden KB Artikel: http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833 mfg Konfus

Hi, schaut eher nach einen DCOM Rechteproblem aus. Führe mal "dcomcnfg" aus und registriere alles was an GUID`s angeboten wird beim Start. Schau im Event Log nach DCOM Fehlern o.ä und poste die hier. mfg KOnfus

Hi, schau mal hier: Wie Beheben des Empfängeraktualisierungsdiensts, indem das Anwendungsprotokoll in Exchange 2000 Server oder Exchange Server 2003 verwendet ( http://support.microsoft.com/?kbid=822794 NEIN, nimm lieber den englischen Artikel, der deutsche scheint mit Babelfish übersetzt worden zu sein :))) http://support.microsoft.com/kb/822794/en-us lg Konfus

Hi, ist es eine Event ID 1030 und 1058. Setze auf dem DC in der Default Domain Policy und in der Default Domain Controllers Policy die SMB Signing Policys wie folgt: Computeronfiguration => Windows Einstellungen ==>> Sicherheitseinstellungen ===>>> Lokale Richtlinien ====>>>> Sicherheitsoptionen Microsoft network client: Digitally sign communications (always) => disabled Microsoft network client: Digitally sign communications (if server agrees) => enabled Microsoft network server: Digitally sign communications (always) => disabled Microsoft network server: Digitally sign communications (if client agrees) =>enabled Ziehe dann die GPO mit "secedit /refreshpolicy mashine_policy /enforce" Führe dann auf einem XP Client ein "gpupdate /force" durch. Ist im Anwendungslog eine Event ID 1704? Wenn nicht, geh in die Registry und setze auf dem Client die folgenden Werte: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters enablesecuritysignature => 0x1 requiresecuritysignature => 0x0 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation\parameters enablesecuritysignature => 0x1 requiresecuritysignature => 0x0 Starte den Client neu, nun sollte das GPO Processing funzen. lg Wicked

Hi, welche Event ID mit der Quelle Netlogon bekommst Du denn? Ist es eine Event ID 5781, die deutet auf ein DNS Problem hin. Nutzt Du einen FQDN oder einen Single Label Domain Name. Installiere die Support Tools und leite einen Auszug von DCDIAG mit "dcdiag /v >dc.txt" in eine Textdatei um. Kann die GUID des Servers aufgelöst werden? Links: http://support.microsoft.com/?kbid=311354 lg Konfus

Hi, das neue Board hat sicherlich auch neue Chipsatztreiber. Insofern sollte selbst eine normale Reparaturinstallation helfen. Wenn der NIC weiter funzt sollte auch das AD und Exchange starten. Setze auf jeden Fall zur Sicherheit einen temporären zweiten DC in die Domäne. Verschiebe die FSMO Rollen mit ntdsutil und sichere auch die Exchange Datenbanken auf den Temp DC. Am sinnvollsten ist beim MB Wechsel aber wohl eine Neuinstallation. lg Konfus

Dann musst Du noch den Secure Channel reseten : Auf ENTERBRAIN musst Du den KDC (Kerberos Schlüssel Verteilungscenter) stoppen und auf manuell setzen. Setz dann das Computerkonto mit "netdom resetpwd /server:Dateiserver /userd:kmw.local\administrator /passwordd:*" zurück. Starte ENTERBRAIN neu und setz den KDC wieder auf Automatisch. Nun sollten die beiden quatschen wie gewohnt :) mfg KOnfus

Gebe Netlogon so lange manuell frei damit die Scripte verarbeitet werden. Wurde der Client neu gestartet? Was macht das FRS Log vom zweiten DC, nach den Burflags sollte der eigentlich funzen. Poste aber bitte mal die Logs, dann sollten wir schnell eine Lösung finden. mfg Konfus

/edit: Und was macht der zweite. Baut der Sysvol auf? Was bringt er denn beim Starten des Dienstes: 13501 ist klar davor 13502 und 13503 Der Fehler ist die Event ID 13508. Hast Du auch eine Event ID 13516? Wenn nicht, Dienst stoppen, DWORD SysvolReady unter HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters auf "1" setzen, Dienst starten. Mit "net share" die sysvol Freigabe prüfen. Wenn Du eine 13516 hast ist der erste Server ok. Die 13508 kommt halt, weil er den zweiten DC nicht ansprechen kann. Setz dann auf DC 2 wie oben den DWORD auf 1 und starte den Dienst neu. Den solltest Du dann mit den Burflags auf Hexadezimal "D2" unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup lösen können. Dann sollte er die Initialreplikation anstossen. => EBEN EINKAUFEN UND WEGEN BL ZUM KOLLEGEN FAHR. ICH SCHAU VON DORT GLEICH NOCHMAL RUM UND POSTE WENNS NOCH IRGENDWO HAPERT . mfg Konfus

okidoki... stoppe auf dem ersten DC NTFRS und kopiere Policies und Scripts aus dem Preexsiting Ordner eine Ebene nach oben, sprich in kmw.local. Starte FRS. Sicher Dir Policies und Scripts vorher auch noch weg. Prüfen den SysvolReady Key aus meinem Post oben, der muss auf "1" gesetzt sein. mfg Konfus

Dann schau unter %systemroot%\sysvol\sysvol\kmw.local ob unter Policies die Default Policies (31b... und 6ac...) vorhanden sind. Eventuell sind die in den Ordner NTFRS_Preexisting geschoben worden.

Bei FRS Problemen am besten zuerst in die FRS Event Logs schauen. Im Endeffekt hast Du eine Hardrecovery der FRS Datenbank gemacht. Auf dem ersten Server, also den FSMO Holder ist aber sysvol und netlogon freigegeben oder? Stoppe auf dem FRS und sicher Dir erst einmal Policies und Scripts. Setze dann direkt die Burflags auf D4. Vergewisser Dich auf dem neuen DC das der DWORD SysvolReady unter HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters auf "1" steht. Wie vermutet sollte das die Lösung sein: ================LÖSUNG================== Den sollte man eigentlich so hinbekommen. Auf allen DC`s FRS stoppen, auf einem gesunden DC die Burflags gem. den Artikel auf D4 setzen und FRS starten. Abwarten bis einen Event ID 13516 kommt. Alle anderen nach und nach mit den Burflags auf D2 starten. Immer prüfen das Sysvol freigegeben wird. http://www.jsiinc.com/SUBM/tip6100/rh6153.htm ================LÖSUNG================== Anbei noch ein sehr guter FRS Troubleshooter: http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/techref/en-us/Default.asp?url=/resources/documentation/windowsServ/2003/all/techref/en-us/sonar_remarks.asp mfg Konfus

Hi, zum einem brauchen wir noch ein paar INfos über die Struktur. Wieviele DC`s sind im Netz und funktionieren die anderen. Wurde der gerade hochgestuft oder ist der im Betrieb "ausgefallen"? Der shared auf jeden Fall kein Sysvol, haben denn die anderen Sysvol und Netlogon geshared. Poste am besten nach einem Neustart von FRS (net stop ntfrs und net start ntfrs) und einer Wartezeit von 5 Minuten die FRS Event Logs. Sind die anderen DC`s mit nslookup auflösbar. Poste auch mal das Ergebnis von dcdiag /v, eventuell ist auch der Secure Channel gebrochen. ============================================ Den sollte man eigentlich so hinbekommen. Auf allen DC`s FRS stoppen, auf einem gesunden DC die Burflags gem. den Artikel auf D4 setzen und FRS starten. Abwarten bis einen Event ID 13516 kommt. Alle anderen nach und nach mit den Burflags auf D2 starten. Immer prüfen das Sysvol freigegeben wird. http://www.jsiinc.com/SUBM/tip6100/rh6153.htm ============================================ Poste aber vorher die Logs. mfg Konfus

Hi, schau mal hier: http://www.microsoft.com/resources/documentation/WindowsServ/2003/datacenter/proddocs/en-us/Default.asp?url=/resources/documentation/windowsserv/2003/datacenter/proddocs/en-us/ntbackup_system_state.asp mfg Konfus

Hallo, schau mal hier; http://support.microsoft.com/default.aspx?scid=KB;EN-US;825826'>http://support.microsoft.com/default.aspx?scid=KB;EN-US;825826 und http://support.microsoft.com/default.aspx?scid=KB;[LN];269155 hier. Dann sollte es funktionieren. mfg Konfus

Hi, liegen die Profile in einem DFS Share? Das kann schon einmal zu Profilproblemen führen. Könnte eventuell ein Replikationsproblem sein. Versuche mal mit einem Client das Profil in einen anderen Share zu schreiben. Setze mal das Userenv Logging hoch: http://support.microsoft.com/default.aspx?scid=kb;EN-US;221833 mfg Konfus

Hi, der DHCP Dienst muss aber demnoch gestartet sein. Ich kenne den Fehler nur bei deaktivierten DHCP Dienst. mfg KOnfus

hm, trusten kannst Du die Rechner nicht, weil a. Die Domäne den gleichen Namen hat b. Ein Trust auf einem SBS nicht möglich ist c. Die Rechner gleich heissen Also wird auch ADMTv2 nicht funktionieren. Ich glaube, dass Du in der Konfiguration keine Chance hast. Es gab mal einen KB Artikel wie Du einen DC auf neue Hardware schiebst. Aber den finde ich nicht mehr. mfg KOnfus

Hört sich nach offenen Handles o.ä an. Schiess mal im Taskmanager alle Third Party Services ab. Oder nimm von einer XP Maschine "msconfig" und kopier die Datei in %systemroot%\system32. Starte die msconfig.exe und deaktivier alles im Systemstart. mfg Konfus

Hi, schau mal unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters und vergewisser Dich das Domain und Nvdomain auf den FQDN zeigen und nicht auf den Server. mfg Konfus

Hi, betrifft es XP Clients oder einen 2003 Server? Läuft DFS? Führe "dfsutil /purgemupcache" aus. Setze die folgenden DWORDS auf 0x0 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters enablesecuritysignature => 0x0 requiresecuritysignature => 0x0 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanworkstation enablesecuritysignature => 0x0 requiresecuritysignature => 0x0 mfg Konfus

Hi, dcomcnfg ist unter XP ein wenig anders. Die LÖsung könnte aber noch greifen. Starte dcomcnfg und navigiere dann zu Komponentendienste => Computer => Arbeitsplatz => DCOM Konfiguration und wähle die Eigenschaften von Verwaltungsdienst für die Verwaltung logischer Datenträger. Prüfe bei Identität das auch das Systemkonto genutzt wird und nicht ein User o.ä. Prüfe dann bei Sicherheit die Rechte von Start, Zugriff und Konfiguration. Poste die ACL mal hier. lg KOnfus

Hallo, sind die durch eine Firewall getrennt? Das RPC Problem sollte im Bereich DNS zu finden sein. Erstelle "dcdiag /v" und "netdiag /v" und suche dort nach Fehlern. Die 1586er ID ist eigentlich nur relevant wenn sich Downlevel Rechner im Netz befinden. Prüfe auch die Synchronisation der Zeit. mfg konfus

Hi, ich weiss nicht ob Dir das rendom Tool von Microsoft weiterhilft. Lese Dir die Doku ganz genau durch falls Du es einsetzen willst. Sicherer ist wahrscheinlich die ADMTv2 Variante. http://www.microsoft.com/windowsserver2003/downloads/domainrename.mspx rendom it nicht geeignet wenn auch Exchange eingesetzt wird. http://support.microsoft.com/default.aspx?kbid=822590 KOnfus