Jump to content

Win2k-Gruppenrichtlinien funktionieren nicht mehr


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Hallo zusammen,

 

ich habe hier seit gestern ein Problem dem ich nicht beikomme.

Hier stehen insgesamt 4 Win2k-Domänencontroller (alle mit aktuellem SP und aktuellen Patches). Einer von denen ist gestern mit BSOD abgeschmiert, Nach dem Neustart funktionierte der darauf installierte DHCP-Server nicht mehr und musste neu eingerichtet werden. Dieser verteilt jetzt auch brav wieder die IP-Adressen.

Ob das jetzt was mit dem Gruppenrichtlinien zu tun haben kann weiss ich nicht.

Aber seit dem Absturz werden die Gruppenrichtlinien nicht mehr verteilt.

Jeder Client hat im Ereignisanzeige nach dem Login unter Anwendungen folgendes stehen:

 

Ereignis-ID 1054 Userenv

Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.

 

Der Zugriff auf die gesamte Domäne funktioniert jedoch absolut fehlerfrei. Alle Freigaben und Anwendungen funktionieren auf den Clients.

 

Auf ALLEN Domänencontrollern erscheinen im 5-Minuten-Takt in der Ereignisanzeige folgende Fehlermeldungen:

 

Ereignis-ID 1000 Userenv

Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Bisher wurde eine Fehlermeldung dieser Art im Richtlinienmodul protokolliert.

 

Ereingis-ID 1000 Userenv

Auf die Datei gpt.ini des Gruppenrichtlinienobjekts kann nicht zugegriffen werden. Die Datei muss im Pfad <> vorhanden sein. (). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen.

 

Aufgrund dessen habe ich mit dem Tool recreatedefpool.exe die Standardgruppenrichtlinien wiederhergestellt. Da die PDC FSMO aber auf einem anderen Domänencontroller läuft musste das Tool dort ausgeführt werden.

Das wurde auf allen Domänencontrollern übernommen ... bis auf den einen der den Absturz hatte. Dort steht unter Sysvol\domänenname\Policies immer noch die ID der alten Policy aber das Script ist dort auch weg. Das bedeutet, dass eigentlich nirgendwo eine Richtlinie hinterlegt ist aber die Fehlermeldungen erscheinen trotzdem alle 5 Minuten.

Egal welche Änderungen ich an den Gruppenrichtlinien mache, auf diesen einen DC werden diese nicht übertragen. Und das ist dummerweise genau der, der diese verteilen sollte.

 

Wenn man an den Clients gpresult laufen lässt heisst es unter Benutzereinstellungen:

.

.

.

Neues Gruppenrichtlinienobjekt

Filterung: Nicht angewendet (unbekannte Ursache)

.

.

 

Weiss jemand Rat? Was ist mit diesem DC faul? Wie bringe ich diesen einen DC dazu die Gruppenrichtlinien wieder mit den anderen DCs abzugleichen?

Was sich völlig meiner Kenntnis entzieht: Wie bringt man einen anderen DC dazu die Gruppenrichtlinien an die Clients zu übergeben?

:confused:

Link zu diesem Kommentar
Weiss jemand Rat? Was ist mit diesem DC faul? Wie bringe ich diesen einen DC dazu die Gruppenrichtlinien wieder mit den anderen DCs abzugleichen?

Was sich völlig meiner Kenntnis entzieht: Wie bringt man einen anderen DC dazu die Gruppenrichtlinien an die Clients zu übergeben?

Wie ist es denn mit dem Funktionieren der Namensauflösung? Was sagt das Ereignisprotokoll?
Link zu diesem Kommentar

So, ich konnte das jetzt endlich mal halbwegs in Ruhe ansehen und Eure Tips ausprobieren.

 

Der Befehl dfsutil /PurgeMupCache funktioniert nicht. Falscher Parameter.

 

Laut replmon treten bei der Replizierung keine Fehler auf. Zumindest werden bei keinem der Domänencontrollern Fehler bei "Search Domain Controllers for Replication Errors" angezeigt.

 

Bei dcdiag sieht es da schon wieder anders aus. Auf dem Domänencontroller der mit BSOD (das ist der Schema Master) abgestürzt ist heisst es:

Doing initial required tests:

.

.

.

GUID DNS name could not be resolved to an IP adress. Check the DNS server, DHCP, server name, etc.

Although the GUID DNS name ... couldn`t be resolved, the server name ... resolved to the IP adress (192.168.1.3) and was pingable. Check that the IP adress is registered correctly with the DNS server.

.

.

.

Doing primary tests:

.

.

Skipping all tests because server ... is not responding to directory service requests

 

Enterprise tests und FSMO check sind in Ordnung.

 

Allerdings sind ein paar andere Sachen "seltsam". Auf den anderen Domänencontrollern bekomme ich über dcdiag ebenfalls eine Fehlermeldung in Bezug auf das Active Directory.

 

Auf dem Server der die FSMO Funktionen PDC, RID, Infrastructure und Domain Tree hat erscheint folgendes:

Starting test frssysvol

There are errors after the SYSVOL has been shared.

The SYSVOL can prevent the AD from starting.

 

Alle anderen Tests auf diesem Server sind in Ordnung.

 

Auf den anderen beiden Servern die keinerlei FSMO Funktionen tragen ist folgende Fehlermeldung zu sehen:

Starting test frssysvol

Error: No record of File Replication System, SYSVOL started.

The Active Directory may be prevented from starting.

There are errors after the SYSVOL has been shared.

The SYSVOL can prevent the AD from starting.

 

Ich glaube hier liegt insgesamt nicht nur ein Problem vor. Allerdings wäre es jetzt erst einmal am wichtigsten das Problem mit der DNS auf dem Schema Master irgendwie in den Griff zu kriegen.

 

Wie kann/soll/muss ich vorgehen?

 

Danke und viele Grüße

Link zu diesem Kommentar

Hi!

 

Die Meldung:

Auf dem Server der die FSMO Funktionen PDC, RID, Infrastructure und Domain Tree hat erscheint folgendes:

Starting test frssysvol

There are errors after the SYSVOL has been shared.

The SYSVOL can prevent the AD from starting.

 

...muss nicht unbedingt auf ein Problem hindeuten. Grundsätzlich heißt das nur, dass im Eventlog Meldungen/Fehler protokolliert wurden, die das Syslog Share betreffen und das AD am starten hindern "könnten".

 

Wenn du auf diesem Server "net /share" eingibst siehst due dann die Freigabe Sysvol?

 

So wie es aussieht (und wie lefg bereits vermutet hat) hast du ein DNS Problem.

 

- Wie sieht es mit den DNS Einstellungen des Server aus, der den BSOD gehabt hat?

- Ist als primärer DNS Server beim SERVER (mit dem BSOD) bei den TCP IP Einstellungen "er selbst" mit seiner IP eingetragen?

- Verwendest du AD-integrierten DNS?

- Ist das dynamische aktualisieren des DNS aktiviert?

- Hast du schonmal versucht den Dienst NETLOGON (Anmeldedienst) neu zu starten?

- Welche Meldungen erscheinen im EVENT Log des Servers der abgestürzt ist?

- Vielleicht kannst du zusätzlich noch die Ausgabe des Befehles ipconfig /all posten?

 

lg

Link zu diesem Kommentar

Hallo mcdaniels,

 

Wenn du auf diesem Server "net /share" eingibst siehst due dann die Freigabe Sysvol?

 

Ja, die Freigabe ist da.

 

- Wie sieht es mit den DNS Einstellungen des Server aus, der den BSOD gehabt hat?

- Ist als primärer DNS Server beim SERVER (mit dem BSOD) bei den TCP IP Einstellungen "er selbst" mit seiner IP eingetragen?

 

Ja, ist er. An erster Stelle er selbst und als zweites ein weiterer Domänencontroller.

 

- Verwendest du AD-integrierten DNS?

- Ist das dynamische aktualisieren des DNS aktiviert?

 

Nein.

 

- Hast du schonmal versucht den Dienst NETLOGON (Anmeldedienst) neu zu starten?

 

Das zwar nicht aber ich habe z.B. gestern Abend den Server mehrfach neu gestartet.

 

- Welche Meldungen erscheinen im EVENT Log des Servers der abgestürzt ist?

 

Im Anwendungsprotokoll (welches jeden zweiten Tag überläuft) steht nach wie vor alle 5 Minuten die Event-ID 1000 Userenv. "Die Abfrage der Gruppenrichtlinien ist fehlgeschlagen. Bisher wurde eine Fehlermeldung dieser Art im Richtlinienmodul protokolliert."

 

und

 

Event-ID 1000 Userenv "Auf die Datei gpt.ini des Gruppenrichtlinienobjekts kann nicht zugegriffen werden. Die Datei muss im Pfad <> vorhanden sein (). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen."

 

Im Sicherheits-, System-, Directory-Service- und DNS Server-Protokoll sind keinerlei Fehlermeldungen.

Aber im Protokoll des Dateireplikationsdienstes steht ca. alle 24 Stunden etwas das mich beunruhigt:

 

Event-ID 13559 NtFrs

"Der Dateireplikationsdienst hat ermittelt, dass ein Replikatstammpfad von "d:\sysvol\domain" in "d:\sysvol\domain" geändert wurde. Falls diese Änderungen absichtlich vorgenommen wurde, muss die Datei NTFRS_CMD_FILE_MOVE_ROOT im neuen Stammpfad neu erstellt werden.

Folgendes wurde für diesen Replikatssatz ermittelt:

"DOMAIN SYSTEM VOLUME (SYSVOL SHARE)"

 

Die Replikatstammpfadänderung erfolgt in zwei Schritten, die durch das Erstellen der Datei NTFRS_CMD_FILE_MOVE_ROOT ausgelöst wird.

 

[1] Bei der ersten Abfrage, die in 5 Minuten durchgeführt wird, wird dieser Computer vom Replikatssatz entfernt.

[2] Bei der darauffolgenden Abfrage wird der Computer dem Replikatssatz erneut hinzugefügt. Durch das Hinzufügen wird eine vollständige Struktursynchronisierung ausgelöst. Nach der Synchronisierung befinden sich alle erforderlichen Dateien am neuen Ort."

 

Was ist das denn bitte?¿?

 

 

- Vielleicht kannst du zusätzlich noch die Ausgabe des Befehles ipconfig /all posten?

 

Gerne mache ich das:

 

Windows 2000-IP-Konfiguration

Hostname. . . . . . . . . . . . . : server-2

Primäres DNS-Suffix . . . . . : zentrale.firma.de

Knotentyp . . . . . . . . . . . . : Hybridadapter

IP-Routing aktiviert. . . . . . . : Nein

WINS-Proxy aktiviert. . . . . . : Nein

DNS-Suffixsuchliste . . . . . . .: zentrale.firma.de

firma.de

 

Ethernetadapter "LAN-Verbindung":

Verbindungsspezifisches DNS-Suffix:

Beschreibung. . . . . . . . . . . : 3Com Gigabit LOM (3C940)

Physikalische Adresse . . . . . . : 00-0C-6E-93-7F-44

DHCP-aktiviert. . . . . . . . . . : Nein

IP-Adresse. . . . . . . . . . . . : 192.168.1.3

Subnetzmaske. . . . . . . . . . : 255.255.255.0

Standardgateway . . . . . . . .: 192.168.1.190

DNS-Server. . . . . . . . . . . . : 192.168.1.3

192.168.1.2

Primärer WINS-Server. . . . : 192.168.1.3

Sekundärer WINS-Server. . .: 192.168.1.2

 

 

Ich kriege hier echt keinen Kopf mehr zusammen ...

:confused:

Link zu diesem Kommentar

Hi!

Sind - wenn du in der DNS MMC nachguckst - alle Einträge vorhanden?

 

d.h.

-- Forward - Lookup - Zone -> deine.domäne.de -> _msdcs (alle Einträge/Server vorhanden)

-- weiters -> _sites, _tcp, _udp vorhanden?

 

Du schreibst dynamische Aktualisierung ist NICHT AKTIV oder meinst du du hast keine AD integrierten DNS.

 

Wenn AD integriert -> warum keine (gesicherte) dyn. Aktualisierung?

Link zu diesem Kommentar
Hi!

Sind - wenn du in der DNS MMC nachguckst - alle Einträge vorhanden?

 

d.h.

-- Forward - Lookup - Zone -> deine.domäne.de -> _msdcs (alle Einträge/Server vorhanden)

-- weiters -> _sites, _tcp, _udp vorhanden?

 

Du schreibst dynamische Aktualisierung ist NICHT AKTIV oder meinst du du hast keine AD integrierten DNS.

 

Wenn AD integriert -> warum keine (gesicherte) dyn. Aktualisierung?

 

 

Hallo macdaniels,

 

sorry mein Fehler. Da habe ich in der Eile nicht aufgepasst bei der Antwort.

Ja, in der DNS MMC unter _msdcs sind alle vier Domänencontroller drin. Auch in den anderen Einträgen sind alle Domänencontroller eingetragen.

 

DNS ist AD integriert und die Einstellung für die dynamische Aktualisierung ist in den Forward Lookupzonen auf "Ja". In den Reverse Lookupzonen steht die Einstellung auf "Nur gesicherte Aktualisierungen"

 

 

 

Was die Event-ID 13559 NtFrs angeht ...

Sollte ich da besser einen neuen Thread erstellen? Das Ding macht mir bald mehr Sorgen wie die Gruppenrichtlinien.

Link zu diesem Kommentar

@mcdaniels:

Danke für Deine Hilfe und für den Link.

 

@nobex:

Wenn ich auf den Domänencontrollern unter Start -> Ausführen -> \\domainname eingebe dann bekomme ich eine Fehlermeldung:

"Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch".

 

Wenn ich das auf den Clients eingebe dann werden mir die Freigaben der DCs sowie die DFS-Struktur angezeigt.

 

nslookup ergibt auf dem Domänencontroller der abgestürzt war folgendes:

Server: server-2.zentrale.firma.de

Adress: 192.168.1.3

 

Name: zentrale.firma.de

Adresses: 192.168.1.3 192.168.1.2 192.168.1.4 192.168.1.5

Link zu diesem Kommentar
Wenn ich das auf den Clients eingebe dann werden mir die Freigaben der DCs sowie die DFS-Struktur angezeigt.

 

nslookup ergibt auf dem Domänencontroller der abgestürzt war folgendes:

Server: server-2.zentrale.firma.de

Adress: 192.168.1.3

 

Name: zentrale.firma.de

Adresses: 192.168.1.3 192.168.1.2 192.168.1.4 192.168.1.5

Sieht für mich erst mal (leider) ok aus. Da stehe ich nun auch auf dem Schlauch :(

Link zu diesem Kommentar
Hier stehen insgesamt 4 Win2k-Domänencontroller (alle mit aktuellem SP und aktuellen Patches).

 

Einer von denen ist gestern mit BSOD abgeschmiert, Nach dem Neustart funktionierte der darauf installierte DHCP-Server nicht mehr und musste neu eingerichtet werden. Dieser verteilt jetzt auch brav wieder die IP-Adressen.

Ob das jetzt was mit dem Gruppenrichtlinien zu tun haben kann weiss ich nicht.

Aber seit dem Absturz werden die Gruppenrichtlinien nicht mehr verteilt.

Jeder Client hat im Ereignisanzeige nach dem Login unter Anwendungen folgendes stehen:

 

Ereignis-ID 1054 Userenv

Der Domänencontrollername für das Computernetzwerk konnte nicht ermittelt werden. (Die angegebene Domäne ist nicht vorhanden oder es konnte keine Verbindung hergestellt werden. ). Die Verarbeitung der Gruppenrichtlinie wurde abgebrochen.:

Sind denn die FSMO und der GC da?

 

 

Der Zugriff auf die gesamte Domäne funktioniert jedoch absolut fehlerfrei. Alle Freigaben und Anwendungen funktionieren auf den Clients.
Das Ereignis-ID 1054 Userenv zeigt, es ist nicht fehlerfrei, der Zugriff auf Freigaben ist nicht das Entscheidende.

 

Auf ALLEN Domänencontrollern erscheinen im 5-Minuten-Takt in der Ereignisanzeige folgende Fehlermeldungen:

 

Ereignis-ID 1000 Userenv

Die Abfrage der Liste der Gruppenrichtlinienobjekte ist fehlgeschlagen. Bisher wurde eine Fehlermeldung dieser Art im Richtlinienmodul protokolliert.

Das ist eine Sekundärerscheinung.

 

Welcher DC ist denn abgeschmiert, war er der 1.DC, hält, hielt er FMSO-Rules oder ist, war er GC??

Link zu diesem Kommentar

@nobex:

Willkommen auf dem Schlauch ... :)

Vielen Dank für Deine Hilfe.

 

@lefg:

Es sind in der Domäne alle FSMO-Funktionen sowie der globale Katalog da. Wobei der GC auf allen vier Domänencontrollern läuft.

 

Nein, der DC der abgeschmiert ist war nicht der erste in der Domäne. Er hält die FSMO-Funktion Schema Master und ebenfalls wie die anderen den GC.

Ich checks echt nicht mehr ...

:confused:

 

 

P.S.: Das Problem mit Event-ID 13559 NtFrs ist Dank dem Link von macdaniels erledigt.

Vielen Dank nochmal.

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...