Userenv 1085 und 1030 Fehlermeldung bei Win XP und WS 2003
Wir haben bei uns in der Domain das Problem, dass sich die Gruppenrichtlinen nicht verteilen lassen. Der DC udn die Clients werfen die Fehlermeldung 1085 und 1030
Hallo zusammen,
EDIT: Das Problem mit der Fehlermeldung 1202 ist gelöst. Allerdings hält sich die Fehlermeldung 1085 hartnäckig. Ich habe jetzt das log angeschaut und mir ist aufgefallen das dort folgende Meldung oft vorkommt
Winlogon.log
ich weiß das hier im Forum schon öfter genau diese Problematik angesprochen wurde. Ich habe auch schon einiges davon ausprobiert aber es hat noch nichts so richtig geholfen. Vor allem habe ich noch eine Verständnisfragen
Durch den Befehl dfsutil /purgemupcache ist auf dem DC nun erstmal Ruhe, keine neuen Einträge mehr im Ereignisprotokoll. Allerdings habe ich schon gelesen das dies wohl nur eine temporäre Lösung ist. Ebenso erhalte ich auf den Clients beim Versuch mit gpupdate /force die Gruppenrichtlinen zu aktualisieren immer noch eine Fehlermeldung - auch die 1085 userenv und die SceCli mit der Fehlermeldung 1202:
Der erste Lösungsansatz war folgender:
Zu guter letzt hat noch jemand hier im Forum geschrieben
ich wäre für Hilfe sehr dankbar. Auch hoffe ich das es OK ist das ich einen neuen Beitrag eröffnet habe.
Gruß
Hallo zusammen,
EDIT: Das Problem mit der Fehlermeldung 1202 ist gelöst. Allerdings hält sich die Fehlermeldung 1085 hartnäckig. Ich habe jetzt das log angeschaut und mir ist aufgefallen das dort folgende Meldung oft vorkommt
Winlogon.log
Es besteht bereits ein Wiederherstellungswert für die Gruppenrichtlinieneinstellung <MaximumPasswordAge>
Diagnosis.logRichtlinienergebnissatz-Diagnoseinformationen. Fehlercode 1168
und viele weitere mit anderen Einträgen am Ende. Kann das hier ein Problem sein?ich weiß das hier im Forum schon öfter genau diese Problematik angesprochen wurde. Ich habe auch schon einiges davon ausprobiert aber es hat noch nichts so richtig geholfen. Vor allem habe ich noch eine Verständnisfragen
Durch den Befehl dfsutil /purgemupcache ist auf dem DC nun erstmal Ruhe, keine neuen Einträge mehr im Ereignisprotokoll. Allerdings habe ich schon gelesen das dies wohl nur eine temporäre Lösung ist. Ebenso erhalte ich auf den Clients beim Versuch mit gpupdate /force die Gruppenrichtlinen zu aktualisieren immer noch eine Fehlermeldung - auch die 1085 userenv und die SceCli mit der Fehlermeldung 1202:
Die Sicherheitsrichtlinien wurden mit Warnungen verbreitet. 0x534 : Zuordnungen von Kontennamen und Sicherheitskennungen wurden nicht durchgeführt.
Der erste Lösungsansatz war folgender:
1. Deaktivierung des SMB-Signing für Server und Clients via GPO
Unter Start/Programme/Verwaltung/Sicherheitsrichtlinien für Domänen und Start/Programme/Verwaltung/Sicherheitsrichtlinien für Domänencontroller jeweils zu Sicherheitseinstellungen\Lokale
Richtlinien\Sicherheitsoptionen navigieren und die Einträge
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt)
alle auf "Deaktiviert" setzen.
Wenn der Zugriff auf die Sicherheitsrichtlinien trotz vorhandener Berechtigung verweigert wird, hilft die Änderung von
HKLM\System\CurrentControlSet\Services\lanmanserver\parameters\requiresecuritysignature von "1" auf "0".
Direkt danach sollten bereits die Fehlermeldungen im Eventlog aufhören und der Zugriff auf die Sicherheitsrichtlinien ohne Reboot wieder möglich sein.
Ein Reboot des Servers ist übrigens grundsätzlich nicht zwingend notwendig, aber durchaus sinnvoll, um die Korrekte Übernahme der Änderungen zu prüfen.
Meine Frage ist nun, reicht es wenn ich das auf dem DC einstelle? Welche Gefahr entseht durch die Einstellung, kann man das bedenklos einstellen?Unter Start/Programme/Verwaltung/Sicherheitsrichtlinien für Domänen und Start/Programme/Verwaltung/Sicherheitsrichtlinien für Domänencontroller jeweils zu Sicherheitseinstellungen\Lokale
Richtlinien\Sicherheitsoptionen navigieren und die Einträge
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt)
alle auf "Deaktiviert" setzen.
Wenn der Zugriff auf die Sicherheitsrichtlinien trotz vorhandener Berechtigung verweigert wird, hilft die Änderung von
HKLM\System\CurrentControlSet\Services\lanmanserver\parameters\requiresecuritysignature von "1" auf "0".
Direkt danach sollten bereits die Fehlermeldungen im Eventlog aufhören und der Zugriff auf die Sicherheitsrichtlinien ohne Reboot wieder möglich sein.
Ein Reboot des Servers ist übrigens grundsätzlich nicht zwingend notwendig, aber durchaus sinnvoll, um die Korrekte Übernahme der Änderungen zu prüfen.
2. Eintragung der DCs in "hosts"
Auf allen DCs die Datei system32\drivers\etc\hosts öffnen und als erstes den lokalen DC mitsamt IP eintragen, danach alle anderen DCs in der Reihenfolge der Erreichbarkeit.
Ist so eingestellt udn hat auch keine Änderung gebrachtAuf allen DCs die Datei system32\drivers\etc\hosts öffnen und als erstes den lokalen DC mitsamt IP eintragen, danach alle anderen DCs in der Reihenfolge der Erreichbarkeit.
Zu guter letzt hat noch jemand hier im Forum geschrieben
Systemsteuerung->DNS->"Server"->forwardLookupZonen->
Erst waren folgende Einträge zu sehen:
DomainDNSZones:
identisch mit übergeordnetem Ordner_Host A_IP-Nummer des Servers
identisch mit übergeordnetem Ordner_Host A_Zweite Ip-Nummer des Server
ForestDNSZones:
identisch mit übergeordnetem Ordner_Host A_IP-Nummer des Servers
identisch mit übergeordnetem Ordner_Host A_Zeite IP-Nummer des Servers
Zu den obigen Einträgen habe ich folgende "hinzugefügt":
forward-lookupzonen->HC-Portal.local->domaindnszones folgenden Host(A)-Eintrag
hinzugefügt
Servername_Host A_IP-Adresse des Servers
Servername_Host A_Zweite IP-Adresse des Server
Dabei "Verknüpfungen PRT-Eintrag erstellen" aktiviert
forward-lookupzonen->HC-Portal.local->forestdnszones folgenden Host(A)-Eintrag
hinzugefügt
Servername_Host A_IP-Adresse des Servers
Servername_Host A_Zweite IP-Adresse des Servers
Dabei Verknüpfungen PRT-Eintrag erstellen aktiviert
Wichtig: Bei Servername ist zu beachten dass man nur den Servernamen einträgt. Also nicht etwa Servername.Domäne.local, sondern wirklich nur den Servernamen.
Zweite IP-Adresse nur wenn vorhanden. In meinem Fall fungiert der Server auch als Router, daher die zweite IP.
Was genau wird hier gemacht? so genau verstehe ich das nicht. :/Erst waren folgende Einträge zu sehen:
DomainDNSZones:
identisch mit übergeordnetem Ordner_Host A_IP-Nummer des Servers
identisch mit übergeordnetem Ordner_Host A_Zweite Ip-Nummer des Server
ForestDNSZones:
identisch mit übergeordnetem Ordner_Host A_IP-Nummer des Servers
identisch mit übergeordnetem Ordner_Host A_Zeite IP-Nummer des Servers
Zu den obigen Einträgen habe ich folgende "hinzugefügt":
forward-lookupzonen->HC-Portal.local->domaindnszones folgenden Host(A)-Eintrag
hinzugefügt
Servername_Host A_IP-Adresse des Servers
Servername_Host A_Zweite IP-Adresse des Server
Dabei "Verknüpfungen PRT-Eintrag erstellen" aktiviert
forward-lookupzonen->HC-Portal.local->forestdnszones folgenden Host(A)-Eintrag
hinzugefügt
Servername_Host A_IP-Adresse des Servers
Servername_Host A_Zweite IP-Adresse des Servers
Dabei Verknüpfungen PRT-Eintrag erstellen aktiviert
Wichtig: Bei Servername ist zu beachten dass man nur den Servernamen einträgt. Also nicht etwa Servername.Domäne.local, sondern wirklich nur den Servernamen.
Zweite IP-Adresse nur wenn vorhanden. In meinem Fall fungiert der Server auch als Router, daher die zweite IP.
ich wäre für Hilfe sehr dankbar. Auch hoffe ich das es OK ist das ich einen neuen Beitrag eröffnet habe.
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 172090
Url: https://administrator.de/contentid/172090
Ausgedruckt am: 05.11.2024 um 20:11 Uhr