Benutzer mit den meisten Antworten
Gruppenrichtlinien werden nicht angewendet - EventID: 1058, 1030

Frage
-
Hallo zusammen
Wir haben auf einem DomänenController (Win2003 RC2 SP2) ein "grösseres" Problem.
Gruppenrichtlinien werden nicht mehr angewendet und diese können auch nicht mehr bearbeitet werden.
Im Eventlog erhalte ich folgende Fehler:
Ereignistyp: Fehler
Ereignisquelle: Userenv
Ereigniskategorie: Keine
Ereigniskennung: 1030
Datum: 21.07.2009
Zeit: 08:51:17
Benutzer: NT-AUTORITÄT\SYSTEM
Computer: SATURN
Beschreibung:
Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Überprüfen Sie das Ereignisprotokoll auf frühere Fehlermeldungen des Richtlinienmoduls, die die Ursache für dieses Problem beschreiben.
---
Ereignistyp: Fehler
Ereignisquelle: Userenv
Ereigniskategorie: Keine
Ereigniskennung: 1058
Datum: 21.07.2009
Zeit: 08:53:14
Benutzer: domain\administrator
Computer: DC
Beschreibung:
Auf die Datei gpt.ini des Gruppenrichtlinienobjekts CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=local kann nicht zugegriffen werden. Die Datei muss im Pfad <\\domain.local\sysvol\domain.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini> vorhanden sein. (Die Konfigurationsinformationen konnten vom Domänencontroller nicht gelesen werden. Mit dem Computer kann keine Verbindung hergestellt werden, oder der Zugriff wurde verweigert. ). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen.
---
Wenn ich anschliessend die Freigabe: \\domain.local\sysvol\ öffnen möchte, erhalte ich folgenden Fehler
---------------------------
domain.local
---------------------------
Auf \\domain.local\SYSVOL kann nicht zugegriffen werden. Sie haben eventuell keine Berechtigung, diese Netzwerkressource zu verwenden. Wenden Sie sich an den Administrator des Servers, um herauszufinden, ob Sie über Berechtigungen verfügen.
Die Konfigurationsinformationen konnten vom Domänencontroller nicht gelesen
werden. Mit dem Computer kann keine Verbindung hergestellt
werden, oder der Zugriff wurde verweigert.
Wenn ich die Eigenschaften von SYSVOL anschaue, ist das DFS nicht erreichbar.
Öffne ich aber den Sysvol Ordner über \\DC\SYSVOL klappt dies.
Ich hab schon vieles Probiert und gelesen, aber bis jetzt hat noch nichts wirklich geholfen.
Nun hoffe ich, dass einer von euch eine zündende Idee hat. :)
Besten Dank schon mal für eure Hilfe.
Gruss Dani
Antworten
-
Hallo zusammen
Bald ein Jahr später....
Ich konnte mitlerweile das Problem lösen.
Aus Gründen der Ausfallsicherheit und Best Practices habe ich bei diesem Kunden nachträglich einen weiteren DC installiert.
Im Zuge dieser Installation hat sich die SYSVOL Geschichte von selbst gelöst.
Ich denke, dass mit dem neuen DC die Kommunikation wieder richtiggestellt werden konnte.Für mich ist es schön, dass dieses Phänomen weg ist, trotzdem hätte ich gerne gewusst, was denn der Ausschlaggebende Part der DC installation gewesen ist, welcher das Problem gelöst hat.
Danke und Liebe Grüsse
Daniel
http://www.iteh.ch- Als Antwort markiert Daniel Hartmann Mittwoch, 14. Juli 2010 12:49
Alle Antworten
-
Bonjour,
als erstes solltest du das SMB-Signing nach "Best Practice" konfigurieren.
Siehe dazu:
[LDAP://Yusufs.Directory.Blog/ - Zugriff auf die GPOs verweigert]
http://blog.dikmenoglu.de/PermaLink,guid,2b1beca6-bde0-49ed-a5bc-0dd61ef242a0.aspx
Ansonsten stimmt die Uhrzeit auf den DCs?
Gibt es AD-Replikationsprobleme bzw. anderweitige Probleme die im Eventlog auftauchen?
Hast Du mehrere NICs im DC (multihomed)? Wenn ja, solltest du mehrere NICs im DC meiden bzw. auf die Bindungen achten.
Viele Grüße aus Mainz
Yusuf Dikmenoglu - MVP Directory Services
Blog: LDAP://Yusufs.Directory.Blog/ -
Hallo
Ich werde das SMB - Signing prüfen.
Edit: Folgender Eintrag von "Best Practice" ist bei mir anders:
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature 0
Dieser Wert steht bei mir auf 1
Die Uhrzeit stimmt.
Nein, im EventLog gibt es keine ungewöhnliche Meldungen.
Ja, ich habe 2 NICs. 1 x LAN und 1 x iSCSI
Gruss Daniel -
Hi,
wenn die Änderung der Binding-Order der NICs nicht hilft und auch die Veränderung des SMB-Signings keine Änderung bringt:
Du schreibst, daß das SYVOL über den DFS Pfad vom DC aus nicht erreichbar ist - wie genau ist das gemeint?
Ist das SYSVOL auf dem konkreten DC freigegeben ("net share")? Wie sieht es auf den anderen DCs aus (BTW: Um wie viele DCs handelt es sich in der Domäne)?
Was sagt ein "dfsutil /pktinfo", ausgeführt auf dem betroffenen DC?
Die NICs sind also nicht im Teaming verbunden? Wie alt sind die NIC Treiber?
DFS Client Dienst läut und der NETLOGON Dienst ebenso?
Viele Grüße
Fabian
http://blogs.technet.com/deds -
Hallo zusammen
Es hat kurz etwas gebracht. Danach wollte ich die Einstellungen in den GPO's vornehmen.
Wo genau finde ich diese Einstellungen?
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
Als ich erneut die Registry Einträge überschrieben habe, konnte ich nicht mehr auf den Sysvol zugreifen. Es hat nur einmal funktioniert mit dem "manuellen" Umstellen der Parameter in der Registry.
--- Du schreibst, daß das SYVOL über den DFS Pfad vom DC aus nicht erreichbar ist - wie genau ist das gemeint?
Wenn ich den Sysvol mit dem Servernamen anspreche, also über die net share Freigabe passt alles.
Wenn aber der DC oder wer auch immer über \\Domänenname\Sysvol zugreiffen möchte, erhalte ich eine Fehlermeldung.
--- BTW: Um wie viele DCs handelt es sich in der Domäne
Leider nur um einen. Bei der Installation war ich noch nicht vor Ort......
--- Was sagt ein "dfsutil /pktinfo", ausgeführt auf dem betroffenen DC?
Hmm... Auf diesem DC kennt er den Befehl gar nicht.
--- Die NICs sind also nicht im Teaming verbunden? Wie alt sind die NIC Treiber?
Nein, die NICs haben kein Teaming. Die NIC Treiber sollten nicht all zu alt sein. Es handelt sich hierbei um Virtuelle Treiber.
--- DFS Client Dienst läut und der NETLOGON Dienst ebenso?
Ja, die Dienste laufen.
Besten Dank für eure Hilfe
Gruss Daniel
http://www.iteh.ch -
Hi,
schau mal hier: http://support.microsoft.com/kb/290647/en-us
Dann solltest du noch das multihomed-Problem in den Griff bekommen:
http://support.microsoft.com/kb/272294/en-us
http://support.microsoft.com/kb/191611/en-us
tbc....
Du solltest das ISCSI-Interface an einem anderen SErver aufhängen, am DC macht das nur Stress. Und die DNS-Eintragungen der ISCSI-Nic müssen unbedingt in der Registry deaktiviert werden. Ich kenne mehr als einen Fall das es mit dem Haken in der Gui nicht getan war. Im DNS dann noch den IP-ISCSI-Eintrag löschen nicht vergessen.
hth
Viele Grüße Walter Steinsdorfer MVP Exchange Server http://msmvps.org/blogs/wstein -
Hallo Andrei
Bis jetzt noch nicht. Muss aber dazu sagen, dass ich zuerst den Server so "umbauen" muss, damit er seine Disks lokal und nicht mehr per iSCSI mountet.
Ich melde mich, wenn ich es testen konnte.
Unterdessen vielen Dank für eure Unterstützung.
Gruss Daniel
http://www.iteh.ch -
Hallo.
Ich habe an sich das gleiche Problem und habe gestern diverse Lösungsansätze durchprobiert und Einstellungen kontrolliert.
NAchdem ich die Registrykeys geändert hatte, habe ich nur über gpedit.msc dies auch in den Gruppenrichtlinien geändert. nach einem Neustart, waren dann aber wiederrum die registry und die Gruppenrichtlinieneinstellungen unterschiedlich, lag das daran das ich es nicht in der "Default Doamain Policy" sowie der "Default Domain Controllers Policy" geändert hatte?
Noch eine Frage:
Der Server läuft soweit wunderbar, nur wenn ich mich auf dem DC einlogge, brechen kurz darauf die Dateifreigaben für die Clients zusammen und der DNS funktioniert nicht mehr, es tauchen die Fehlermeldungen 1058 und 1030 auf. Hängt das mit dem Gruppenrichtlinien zusammen? bzw. das er sie nicht mehr finden kann, laut der Fehlermeldungen?
Ach so, ich habe außerdem mal in der "...\etc\hosts"-Datei folgende Einträge gemacht:
192.x.x.100 DC
192.x.x.100 DC.domain.local
192.x.x.100 domain.local
Ist dies als zusätzliche Namensauflösungshilfe, u.a. auch für das Active Directory ok? Schaden tutu das doch nicht oder?
Vielen Dank schonmal und viele Grüße
Thorsten
-
Malleus2010 schrieb:
Ich habe an sich das gleiche Problem und habe gestern diverse Lösungsansätze durchprobiert und Einstellungen kontrolliert.
Trotzdem ist es nicht gut, einen so alten Thread zu kapern. Erstell in
Zukunft vernünftigerweise einen neuen und beschreib dein Problem.NAchdem ich die Registrykeys geändert hatte, habe ich nur über gpedit.msc dies auch in den Gruppenrichtlinien geändert. nach einem Neustart, waren dann aber wiederrum die registry und die Gruppenrichtlinieneinstellungen unterschiedlich, lag das daran das ich es nicht in der "Default Doamain Policy" sowie der "Default Domain Controllers Policy" geändert hatte?
GPEDIT.MSC ändert nur LOKAL ab. Ist das ein DC?
Ach so, ich habe außerdem mal in der "...\etc\hosts"-Datei folgende Einträge gemacht:
192.x.x.100 DC
192.x.x.100 DC.domain.local
192.x.x.100 domain.local
>
Ist dies als zusätzliche Namensauflösungshilfe, u.a. auch für das Active Directory ok? Schaden tutu das doch nicht oder?Das ist flüssiger als Wasser. Mach die Änderungen wieder rückgängig.
Servus
Winfried
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
GPO's: www.gruppenrichtlinien.de
Community Forums NNTP Bridge: http://communitybridge.codeplex.com -
Danke schon mal für die Antwort.
Ja, es ist ein einziger DC im Netzwerk. Er läuft mit Win 2003 und die Dienste DNS, DHCP, Fileserver, Exchange 2003.Naja, ich hatte gelesen, das der DC Probleme hat sich selbst zu finden und da das DNS ja auch irgendwie nicht richtig läuft, dachte ich der Eintrag in die hosts wäre ein Ansatz.
Meinst Du mit "flüssiger als Wasser" unnötig?
Wie sind denn die Standardeinstellungen von den genannten Gruppenrichtlinien/Registryeinträgen? Da findet man auch unterschiedliche Angaben.
Achso, ich habe keinen neuen Thread erstellt, weil man woanders geschimpft wird, wenn man nicht die vorhandenen nutzt...
-
Malleus2010 schrieb:
Danke schon mal für die Antwort.Ja, es ist ein einziger DC im Netzwerk. Er läuft mit Win 2003 und die Dienste DNS, DHCP, Fileserver, Exchange 2003.
Ist das ein SBS?
Naja, ich hatte gelesen, das der DC Probleme hat sich selbst zu finden und da das DNS ja auch irgendwie nicht richtig läuft, dachte ich der Eintrag in die hosts wäre ein Ansatz.
Ursachen finden und beseitgen ist besser als mit Workarounds vom
hörensagen bekämpfen zu wollen.Meinst Du mit "flüssiger als Wasser" unnötig?
Überflüssig.
Wie sind denn die Standardeinstellungen von den genannten Gruppenrichtlinien/Registryeinträgen? Da findet man auch unterschiedliche Angaben.
Welche Einträge suchst Du denn? Ich lese die Foren mit einem
Newsreader lokal und offline. Die alten Beiträge hab ich nicht zur
Auswah.Achso, ich habe keinen neuen Thread erstellt, weil man woanders geschimpft wird, wenn man nicht die vorhandenen nutzt...
Woanders ist nicht hier. ;) Spaß beiseite, erstell einen neuen Thread
und beschreib das Problem. Daten zum System so exakt wie möglich
angeben. Dann kann dir geholfen werden.Servus
Winfried
Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
GPO's: www.gruppenrichtlinien.de
Community Forums NNTP Bridge: http://communitybridge.codeplex.com/ -
Hallo zusammen
Bald ein Jahr später....
Ich konnte mitlerweile das Problem lösen.
Aus Gründen der Ausfallsicherheit und Best Practices habe ich bei diesem Kunden nachträglich einen weiteren DC installiert.
Im Zuge dieser Installation hat sich die SYSVOL Geschichte von selbst gelöst.
Ich denke, dass mit dem neuen DC die Kommunikation wieder richtiggestellt werden konnte.Für mich ist es schön, dass dieses Phänomen weg ist, trotzdem hätte ich gerne gewusst, was denn der Ausschlaggebende Part der DC installation gewesen ist, welcher das Problem gelöst hat.
Danke und Liebe Grüsse
Daniel
http://www.iteh.ch- Als Antwort markiert Daniel Hartmann Mittwoch, 14. Juli 2010 12:49
-
Hallo,
ich hatte gerade den gleichen Effekt. die gleichen Events wegen der GPOs und kein Zugriff auf Sysvol, Netlogon und weitere Shares. Zugriff auf \\Server\Share war möglich, Zugriff auf \\Domäne\Share war nicht möglich. Es gab hier nur einen DC (SBS2008).
Bei mir war ein Abhängigkeits-Dienst vom DFS-N nicht gestartet und zwar die Remoteregistrierung, keine Ahnung warum.
Da DFS-N jetzt wieder läuft, gelingt auch der Zugriff auf \\Domäne\Share
Vielleicht hilft es ja jemanden :)
Beste Grüße