6
Domain Controller kann auf Shares (eigene und fremde) nicht zugreifen
Von außen kommt man auf die Shares des Servers. Auf dem Server geht es nicht. Dadurch kann der Domain-Controller nicht auf die Richtlinien zugreifen und auch nicht abändern
Hallo,
ich bin mittlerweise mit dem oben genannten Problem absolut am verzweifeln.
Wir nutzen Windows Server 2008 als DC. Alle Clients können auf die Shares des Servers zugreifen (SYSVOL und diverse Daten Shares), aber der Server selbst kann auf keinem Share zugreifen. Auf den Laufwerken (also ohne \\ ) kann der Server zurgreifen. Es klingt für mich selbst wie SMB Signing Probleme (besonders weil der Server auch der einzige ist, der nicht auf einem Samba Share im Netz zugreifen kann - er kann aber auch nicht auf einen lokalen Share eines Rechners (x-beliebig) und auf einen Share eines alten Windows 2000 File-Servers zugreifen), aber dahingehend habe ich eigentlich alles getestet (dachte ich zumindest).
Die Registry habe ich wie folgt testweise geändert:
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature 1
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature 1
(wie auf http://www.gruppenrichtlinien.de/index.html?/HowTo/SMB_signing.htm vorgeschlagen). Ein Rechner-Neustart brachte keine Änderungen - der Neustart der Dienste Server und Arbeitsstation brachten auch keine Änderung
Schau ich auf dem Server mit rsop.msc nach, dann sind
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)
beide aktiviert (ist es normal, das bei dem Programm ein rotes X durch die Computzerkonfiguration ist?)
Auf dem Server erhalten wir immer wieder die Event-Id 1058, aber kein 1030.
Folgendes habe ich im Explorer getestet
\\server.firma.local -> sehe die Shares, bei einem Zugriff kommt die Fehlermeldung
\\firma.local -> sofort Fehler
\\192.168.0.1 -> sofort Fehler
Das ganze hatte mal funktioniert, leider kann man aber nicht mehr zurückverfolgen, was genau geändert wurde (oder gibt es eine Art Verlauf?)
Wie könnte ich feststellen, ob es wirklich am SMB Signing liegt und noch viel wichtiger: wie könnte ich das Beheben?! Kann man das Signing vorrübergehend komplett abschalten? Wie kann man die Richtlinien ändern, wenn man nicht auf sysvol zugreifen kann (und wie kann der Server die dann für sich selbst anwenden?). Ich befürchte, dass die "fehlerhafte" Einstellung sich in den "Default Domain Controllers Policy" befinden (anhand der letzten Dateiänderung), aber wie könnte ich die a) ändern und b) anwenden ohne sysvol Zugriff?
Ich hoffe mir kann jemand helfen und meinen schlaflosen Nächten ein Ende bereiten ...
ich bin mittlerweise mit dem oben genannten Problem absolut am verzweifeln.
Wir nutzen Windows Server 2008 als DC. Alle Clients können auf die Shares des Servers zugreifen (SYSVOL und diverse Daten Shares), aber der Server selbst kann auf keinem Share zugreifen. Auf den Laufwerken (also ohne \\ ) kann der Server zurgreifen. Es klingt für mich selbst wie SMB Signing Probleme (besonders weil der Server auch der einzige ist, der nicht auf einem Samba Share im Netz zugreifen kann - er kann aber auch nicht auf einen lokalen Share eines Rechners (x-beliebig) und auf einen Share eines alten Windows 2000 File-Servers zugreifen), aber dahingehend habe ich eigentlich alles getestet (dachte ich zumindest).
Die Registry habe ich wie folgt testweise geändert:
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature 1
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature 1
(wie auf http://www.gruppenrichtlinien.de/index.html?/HowTo/SMB_signing.htm vorgeschlagen). Ein Rechner-Neustart brachte keine Änderungen - der Neustart der Dienste Server und Arbeitsstation brachten auch keine Änderung
Schau ich auf dem Server mit rsop.msc nach, dann sind
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)
beide aktiviert (ist es normal, das bei dem Programm ein rotes X durch die Computzerkonfiguration ist?)
Auf dem Server erhalten wir immer wieder die Event-Id 1058, aber kein 1030.
Folgendes habe ich im Explorer getestet
\\server.firma.local -> sehe die Shares, bei einem Zugriff kommt die Fehlermeldung
\\firma.local -> sofort Fehler
\\192.168.0.1 -> sofort Fehler
Das ganze hatte mal funktioniert, leider kann man aber nicht mehr zurückverfolgen, was genau geändert wurde (oder gibt es eine Art Verlauf?)
Wie könnte ich feststellen, ob es wirklich am SMB Signing liegt und noch viel wichtiger: wie könnte ich das Beheben?! Kann man das Signing vorrübergehend komplett abschalten? Wie kann man die Richtlinien ändern, wenn man nicht auf sysvol zugreifen kann (und wie kann der Server die dann für sich selbst anwenden?). Ich befürchte, dass die "fehlerhafte" Einstellung sich in den "Default Domain Controllers Policy" befinden (anhand der letzten Dateiänderung), aber wie könnte ich die a) ändern und b) anwenden ohne sysvol Zugriff?
Ich hoffe mir kann jemand helfen und meinen schlaflosen Nächten ein Ende bereiten ...
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 129924
Url: https://administrator.de/contentid/129924
Printed on: April 19, 2024 at 23:04 o'clock
6 Comments
Latest comment
Hi,
Hast schonmal folgendes ausgprobiert? Auch wenn du keine 1030er Event-ID hast.
http://support.microsoft.com/kb/842804/de
Hast schonmal folgendes ausgprobiert? Auch wenn du keine 1030er Event-ID hast.
http://support.microsoft.com/kb/842804/de
das scheint es leider auch nicht zu sein (scheint ja auch dabei sich um das Verhalten nach dem Aufwachen des Rechners zu handeln).
zusätzlich habe ich nun mit dem Holzhamme ein dcgpofix angewandt. Dies wird als Tipp gegeben bei reinen 1058 Fehlern. Geholfen hat das nichts - nur dass auch nun die Clients keine Gruppenrichtlinien jetzt mehr haben bzw. lesen können (Clients kamen ja noch auf /Server/sysvol).
Wie kann es sein, dass der Server auf seine eigene Shares nicht zugreifen kann? Auf fremde Shares ist mir das ja egal, aber die eigenen braucht er für die Gruppenrichtlinien
Bis auf dem 1058 finde ich nichts in den Logs.
"Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\klaas.local\sysvol\klaas.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
- Provider
[ Name] Microsoft-Windows-GroupPolicy
[ Guid] {aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}
EventID 1058
Version 0
Level 2
Task 0
Opcode 1
Keywords 0x8000000000000000
- TimeCreated
[ SystemTime] 2009-11-22T16:28:50.386Z
EventRecordID 605886
- Correlation
[ ActivityID] {9F162B15-C181-4C52-A263-8C39B760CB3C}
- Execution
[ ProcessID] 508
[ ThreadID] 4900
Channel System
Computer server.klaas.local
- Security
[ UserID] S-1-5-18
- EventData
SupportInfo1 4
SupportInfo2 840
ProcessingMode 0
ProcessingTimeInMilliseconds 2043
ErrorCode 2
ErrorDescription Das System kann die angegebene Datei nicht finden.
DCName \\server.klaas.local
GPOCNName CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=klaas,DC=local
FilePath \\klaas.local\sysvol\klaas.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini
"
ein Net use in der Shell bringt ein
"Systemfehler 1231 aufgetreten.
Das Netzlaufwerk ist nicht erreichbar. Weitere Informationen über die Behebung von Netzwerkproblemen finden Sie in der Windows-Hilfe."
(egal ob sysvol oder irgendein anderer share auf dem Server)
Lege ich auf dem Server ein neuen Share an und versuche über \\server\sharename zuzugreifen, dann kann ich den auch nicht vom Server aus erreichen - aus dem Netzwerk ist die FReigabe sofort zu erreichen
zusätzlich habe ich nun mit dem Holzhamme ein dcgpofix angewandt. Dies wird als Tipp gegeben bei reinen 1058 Fehlern. Geholfen hat das nichts - nur dass auch nun die Clients keine Gruppenrichtlinien jetzt mehr haben bzw. lesen können (Clients kamen ja noch auf /Server/sysvol).
Wie kann es sein, dass der Server auf seine eigene Shares nicht zugreifen kann? Auf fremde Shares ist mir das ja egal, aber die eigenen braucht er für die Gruppenrichtlinien
Bis auf dem 1058 finde ich nichts in den Logs.
"Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\klaas.local\sysvol\klaas.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:
a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
System
- Provider
[ Name] Microsoft-Windows-GroupPolicy
[ Guid] {aea1b4fa-97d1-45f2-a64c-4d69fffd92c9}
EventID 1058
Version 0
Level 2
Task 0
Opcode 1
Keywords 0x8000000000000000
- TimeCreated
[ SystemTime] 2009-11-22T16:28:50.386Z
EventRecordID 605886
- Correlation
[ ActivityID] {9F162B15-C181-4C52-A263-8C39B760CB3C}
- Execution
[ ProcessID] 508
[ ThreadID] 4900
Channel System
Computer server.klaas.local
- Security
[ UserID] S-1-5-18
- EventData
SupportInfo1 4
SupportInfo2 840
ProcessingMode 0
ProcessingTimeInMilliseconds 2043
ErrorCode 2
ErrorDescription Das System kann die angegebene Datei nicht finden.
DCName \\server.klaas.local
GPOCNName CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=klaas,DC=local
FilePath \\klaas.local\sysvol\klaas.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini
"
ein Net use in der Shell bringt ein
"Systemfehler 1231 aufgetreten.
Das Netzlaufwerk ist nicht erreichbar. Weitere Informationen über die Behebung von Netzwerkproblemen finden Sie in der Windows-Hilfe."
(egal ob sysvol oder irgendein anderer share auf dem Server)
Lege ich auf dem Server ein neuen Share an und versuche über \\server\sharename zuzugreifen, dann kann ich den auch nicht vom Server aus erreichen - aus dem Netzwerk ist die FReigabe sofort zu erreichen
Falls auf dem Server eine Firewall oder AV-"Lösung" mit Netzwerkschutzfunktionen läuft - schmeiß die testhalber runter und starte neu.
Falls es das nicht ist, hast Du ein ernstes Problem. Evtl. ist ein Restore vom Backup oder eine Reparaturinstallation dann der beste Weg. Auch ein Wiedereinspielen des letzten Servicepacks könnte man als "Reparatur-light" versuchen.
Falls es das nicht ist, hast Du ein ernstes Problem. Evtl. ist ein Restore vom Backup oder eine Reparaturinstallation dann der beste Weg. Auch ein Wiedereinspielen des letzten Servicepacks könnte man als "Reparatur-light" versuchen.
Was mich noch wundert...
(dieser Teil war quatsch und hilft mir nicht bei der Lösungsfindung)
(dieser Teil war quatsch und hilft mir nicht bei der Lösungsfindung)
So ... noch immer stecke ich bei dem Problem fest. Was ich nun bemerkt habe: In den Logfiles %windir%\debug\usermode\UserEnv.log und %windir%\security\logs\winlogon.log steht seit Anfang November (seit dem es auch das Problem gibt) nichts neues drin. Ein ändern der Registry auf ExtensionDebugLevel = REG_DWORD 0x2 und UserEnvDebugLevel = REG_DWORD 30002 bringt kein Änderung.
Kann es sein, dass die lokalen Sicherheitseinstellungen einen Fehler haben? Sollte ich die neu setzen? Was könnte es bringen!?
Kann es sein, dass die lokalen Sicherheitseinstellungen einen Fehler haben? Sollte ich die neu setzen? Was könnte es bringen!?
So .. Problem nun gelöst. Es war nicht das SMB Signing.
Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage und Routing standen alte Netzwerkkarten. Ich habe die Einträge mit LanmanServer verglichen (von außen ging ja alles) und abgeändert.
Nach dem Booten ging wieder alles!
Trotzdem Danke für die Bemühungen!
Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage und Routing standen alte Netzwerkkarten. Ich habe die Einträge mit LanmanServer verglichen (von außen ging ja alles) und abgeändert.
Nach dem Booten ging wieder alles!
Trotzdem Danke für die Bemühungen!
