DC1 zeigt Ereignisse 1030 und 1058

[fly87 10]

Hallo zusammen,

 

vor einiger Zeit musste ich nahezu alle System herunterfahren, da an der Stromversorgung des Serverraums gearbeitet werden musste, da gabs Arbeiten wegen der Klimaanlage etc.

 

Alle Systeme danach wieder hochgefahren.

Auf den ersten Blick lief dann auch alles und ich bemerkte keine Fehler.

 

Über die Tage habe ich dann etwas Urlaub gehabt und daher auch nicht die Logs verfolgt. Heute komme ich wieder und finde das Anwendungslog des ersten von zwei DCs voll mit Ereignissen 1030 und 1058.

 

Dazu gibts auch einen KB Artikel: Verarbeitung der Gruppenrichtlinie funktioniert nicht und die Ereignisse 1030 und 1058 werden im Anwendungsprotokoll des Domänencontrollers protokolliert

 

Der Fehler lautet:

Auf die Datei gpt.ini des Gruppenrichtlinienobjekts CN={Policy} kann nicht zugegriffen werden. Die Datei muss im Pfad {PFAD} vorhanden sein. (Zugriff verweigert ). Die Verarbeitung der Gruppenrichtlinie wird abgebrochen.

 

Aber diesen Fehler verstehe ich nicht, denn alle Berechtigungen stimmen, sowohl die Sysvol als auch die DC Richtline, die genannten Dienste laufen auch.

 

Vor dem Restart hatte ich diese Probleme nicht.

Ich habe zwar ein paar Software Policys gelöscht, da wir damals auf Verteilung über AD gesetzt haben, das aber schon einige Zeit nicht mehr so machen.

 

Es gab auch nie so eine Meldung, die tauchen erst alle 5 Minuten seit dem Restart des Servers auf.

 

Auf dem 2. DC sehe ich keine dieser Meldungen.

 

Anmeldungen etc. klappen über beide DCs, das konnte ich schon testen.

Policy Änderungen ziehen auch...

 

Ist mir ein bisschen Rätselhaft, hat jemand von euch evtl. eine Idee, was hier das Problem auslöst...? Bevor ich den wieder neustarte, wollte ich hier erst mal nachhören, möglicherweise kennt jemand das Problem.

 

Danke euch.

 

Viele Grüße,

Ben

[dmetzger 10]

Kannst Du von anderen Stationen auf die Sysvol- und Netlogon-Freigaben des betreffenden DCs zugreifen?

 

Kannst Du die GPMC mit Fokus auf den betreffenden DC öffnen?

[Babble 11]

Ich hatte vor kurzem ein ähnliches Problem auf einem unserer DC's.

Der Fehler lag im DFS, ein Löschen des DFS/MUP-Cache über dfsutil /purgemupcache hat geholfen.

 

Quelle: Fehler userenv 1030/1058 - Howtos und Anleitungen

 

Gruss,

Babble.

[fly87 10]

Kannst Du von anderen Stationen auf die Sysvol- und Netlogon-Freigaben des betreffenden DCs zugreifen?

 

Kannst Du die GPMC mit Fokus auf den betreffenden DC öffnen?

 

Öffnen ja, gucke ich mir dann aber die Gruppenrichtline an, dann erhalte ich ein Error Fenster, welches über die Richtline im Fehlerlog meckert.

 

Meldung ist folgende:

 

The following error occured in \\Pfad\{Policy}\Adm\inetres_angepasst_poledit.adm on line 1325:

Error 64

 

The file can not be loaded.

 

Also offenbar doch irgendwo in der DC Gruppenrichtline, seltsam das ich diesen Fehler auf dem genannten DC selber nicht erhalte... :suspect:

Obwohl er sich die Liste ja vom ersten DC geholt hat...

[dmetzger 10]

Hast Du eine ADM-Vorlage angepasst und über "Administrative Vorlagen" dem fraglichen Gruppenrichtlinienobjekt zugefügt?

 

Du müsstst in diesem Fall diese Vorlage entfernen und beobachten, ob sich das GPO nun ohne Fehlermeldung öffnen und bearbeiten lässt.

[fly87 10]

Hallo,

 

ich habe mir jetzt heute mal etwas genauer Zeit genommen für das Problem, also diese angemahnte Policy ist die Domain Controller Policy sprich Gruppenrichtline.

 

Wenn man diese bearbeiten will, gibts den genannten Fehler, als Fenster und auch einen direkten Log Eintrag.

 

Die angemeckerte "inetres_angepasst_poledit.adm" gibts in dem fraglichen Verzeichnis überhaupt nicht. Es gibt eine interes.adm und das wars.

 

Bisher habe ich nie auf selbstgestrickte Vorlagen gesetzt.

 

Möglicherweise hat sich auch irgendwas verschluckt, was jetzt nicht ersichtlich ist. Ich werden den Neustart noch einmal probieren und dann mal sehen, ob der Fehler weiterhin besteht.

 

Es gibt ja auch noch die Möglichkeit, die DC Policy wiederherzustellen.

Mit dem Thema müsste ich mich dann befassen...

Allerdings ist die nie angepackt worden, ähnlich wie die Default Domain Policy.

[dmetzger 10]

Die angemeckerte "inetres_angepasst_poledit.adm" gibts in dem fraglichen Verzeichnis überhaupt nicht.

 

Das ist ja das Problem. Würde es sie geben, liesse sie sich öffnen. :rolleyes:

 

Andererseits erfindet der überlebende DC mit Bestimmtheit nicht eine "inetres_angepasst_poledit.adm". Hier muss in der Vergangenheit eine selbst gebaute Vorlage mit diesem Dateinamen existiert haben, möglicherweise aber nur lokal auf dem nicht mehr funktionsfähigen DC.

 

Falls Du wirklich zu dcgpofix.exe greifen möchtest, dann lies vorab noch dies:

The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state

[fly87 10]

Also es kann sein, unter Umständen, das es eine solche Datei mal unter Windows 2000 Server AD gab...

 

Aber dann hätte dieses Problem ja schon mal da sein müssen.

 

Ich habe mit meinem Kollegen gesprochen.

Weder er noch ich haben jemals mit selbst gebauten Templates gespielt.

 

Mal in einer VM Umgebung, die keinen Zugang zu den Produktivsystemen hatte... Wie gesagt, bis zu dem Neustart gab es das Problem ja nicht.

 

Gut, der DC ist die letzt 1,5 Jahre nicht durchgestartet worden, aber nee kann ich mir nicht vorstellen...

 

Da werde ich noch mal weiter prüfen müssen.

[Sunny61 812]

Da werde ich noch mal weiter prüfen müssen.

 

Wie lange dauert es eigentlich so ein umbenanntes ADM-Template in das Verzeichnis zu bringen?

[GuentherH 61]

Hi.

 

Läuft der betroffene DC in einer virtuellen Umgebung (Hyper-V)?

 

LG Günther

[fly87 10]

Wie lange dauert es eigentlich so ein umbenanntes ADM-Template in das Verzeichnis zu bringen?

 

Insgesamt nicht lange, aber das wäre ja eine Murkslösung, die nicht wirklich die Ursache behabet sondern nur die Auswirkung, den Log Eintrag aufhebt...

 

Hi.

 

Läuft der betroffene DC in einer virtuellen Umgebung (Hyper-V)?

 

LG Günther

 

....nein, das nicht. Der erste DC ist bei uns, aus der Tradition immer nativ und alleine auf einer eigenen Hardware installiert.

 

------

 

Eines ist aber sehr komisch, davon ab.

Es hat sich jetzt offenbar erledigt.

Gestern Abend gegen 23:00 Uhr fand noch mal ein Restart des Servers statt.

 

Dann gabs eine Log Meldung, die Sicherheitsrichtlinen wurden erfolgreich angewendet. Die gabs beim letzeten Restart nicht.

Seit dem ist die Meldung nicht wieder aufgetaucht...

 

Aber diese vorher benannte Datei gibt es immer noch nicht.

Ist mir ein echtes Rätsel...

[Sunny61 812]

Insgesamt nicht lange, aber das wäre ja eine Murkslösung, die nicht wirklich die Ursache behabet sondern nur die Auswirkung, den Log Eintrag aufhebt...

 

Wenn es die defekte GPO aber gibt?

[fly87 10]

....ja aber offenbar gibt es die ja nicht, da der nächtliche Restart offenbar das Problem gelöst hat...

 

Nicht böse, abfällig oder so gemeint, aber Verstehst du, ich denke mir das ja nicht aus, das dass Log nach diesem Restart wieder normal ausschaut und keine Errors mehr drin sind, die vorher im 5 Minuten Takt kamen...

 

Selbst wenn ich jetzt den Ordner anschaue, der angemotzt wurde, hat sich da rein gar nichts verändert.

Also will mir nicht ganz in den Kopf...

 

Ich versuche gerade nach zu vollziehen, was da passiert ist.

Du hast sicher nicht ganz unrecht, Aber:

 

Wie kann er ein File verarbeiten wollen, das es nicht gibt, nach unserer Auffassung und es gibt blos zwei Admins, die dazu überhaupt Berechtigung hätten, nie gegeben hat und nach dem Restart ist das alles wieder vergessen und alles läuft wieder so, wie es sein soll...

Kann ja nicht von ungefähr kommen, die vorherige Meldung.

[dmetzger 10]

....ja aber offenbar gibt es die ja nicht, da der nächtliche Restart offenbar das Problem gelöst hat...

 

Der DC denkt sich aber bestimmt auch keine Vorlage aus, die es nie gegeben hat, und benennt sie darüber hinaus mit dem Zusatz "angepasst".

 

Nicht böse, abfällig oder so gemeint, aber Verstehst du, ich denke mir das ja nicht aus, das dass Log nach diesem Restart wieder normal ausschaut und keine Errors mehr drin sind, die vorher im 5 Minuten Takt kamen...

 

Das klingt glaubhaft.

 

Selbst wenn ich jetzt den Ordner anschaue, der angemotzt wurde, hat sich da rein gar nichts verändert.

Also will mir nicht ganz in den Kopf...

 

Wäre interessant zu wissen, was nach einem nächsten Neustart passiert.

 

Ich versuche gerade nach zu vollziehen, was da passiert ist.

 

Das wüssten wir ebenfalls gerne. Im Gegensatz zu Dir haben wir aber keinen direkten Zugriff auf den Server. Das macht es schwer zu bestimmen, weshalb die Fehlereinträge zuerst geschrieben wurden und jetzt nicht mehr.

 

Wie kann er ein File verarbeiten wollen, das es nicht gibt,

 

Siehe oben.

 

und es gibt blos zwei Admins, die dazu überhaupt Berechtigung hätten,

 

Da könnte ich ein paar Geschichten erzählen von Admins, die "überhaupt nichts gemacht" haben - wenn man lokal auf Server zugreifen kann, finden sich oft unglaubliche Spuren...

 

Kann ja nicht von ungefähr kommen, die vorherige Meldung.

 

Ja, da wäre ich auch sehr misstrauisch und würde unbedingt wissen wollen, was vorgegangen ist.