none
Gruppenrichtlinien werden nicht angewendet - EventID: 1058, 1030 RRS feed

  • 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

    Dienstag, 21. Juli 2009 07:03

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
    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/
    Dienstag, 21. Juli 2009 07:59
    Moderator
  • 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
    Dienstag, 21. Juli 2009 08:05
  • 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
    Mittwoch, 22. Juli 2009 15:08
    Beantworter
  • 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



    Donnerstag, 23. Juli 2009 11:05
  • 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
    Mittwoch, 29. Juli 2009 15:03
  • Hallo Daniel

    hat dir Walters Lösungsansatz weitergeholfen?

    Gruß
    Andrei
    Montag, 10. August 2009 07:39
    Moderator
  • 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
    Montag, 10. August 2009 08:27
  • 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

     

    Mittwoch, 9. Juni 2010 07:41
  • 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

    Mittwoch, 9. Juni 2010 08:25
  • 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...

    Mittwoch, 9. Juni 2010 08:49
  • 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/

    Mittwoch, 9. Juni 2010 10:20
  • 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
    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

    Mittwoch, 27. Juni 2012 07:44