Konfus
-
Gesamte Inhalte
114 -
Registriert seit
-
Letzter Besuch
Beiträge erstellt von 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:
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
-
-
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
Client lässt sich nicht in Domäne einbinden
in Windows Server Forum
Geschrieben
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