GPO - Fehler beim Editieren

[RalphT 15]

Moin,

 

ich erstelle ein neues GPO. In den Computereinstellungen stelle ich z.B. im Pfad ..\Lokale Richtlien etwas ein.

Nachdem ich dann auf OK klicke, erscheint folgende Fehlermeldung.

 

 

 

Das ist aber nicht in allen Werten so. Stelle ich z.B. etwas bei der Firewall eine Regel ein, dann funktioniert das. Auch in den Administrativen Vorlagen habe ich stichpunktartig rumprobiert. Dort war auch kein Fehler feststellbar.

Die Datei GptTmpl.inf wurde tatsächlich nicht richtig verändert. Der Wert steht zwar in der Datei, jedoch nicht der angegebene User. Die GPO habe ich hier auf einem zentralen Store.

Die Ereignisanzeige ist sauber. DCDIAG und repladmin sind auch ohne Fehler.

 

Ich kann mir jetzt nicht so direkt vorstellen, dass bestimmte ADMX-Vorlagen defekt sind.

 

Hat einer eine Idee, wo der Fehler liegen könnte? Wer weiß, wie lange dieser Fehler schon präsent ist, da das ja nur bei bestimmten Werte in einer GPO auffällt.

 

bearbeitet 30. April von RalphT

[RalphT 15]

Beim Sichern der GPOs ist mir dann folgendes aufgefallen:

 

In der Standard-GPO "Default Domain Controllers Policy" ist mir aufgefallen, dass dort nicht auflösebare SIDs enthalten sind. Siehe Anhang.

Diese hatte ich allerdings nie verändert.

 

bearbeitet 30. April von RalphT

[NorbertFe 1.829]

Lösch doch mal raus. 

[RalphT 15]

Habe ich gemacht. Funktioniert leider teilweise. Entfernen der unbekannten SIDs hat funktioniert. Allerdings fehlten bei machen Einträgen bestimmte Gruppen. Das hatte ich mit einem funktionierenden DC verglichen. Viele Einträge ließen sich komplett so wiederherstellen, wie es sein soll.

Allerdings sind so ca. 5 Einträge vorhanden, wo ich die SIDs herauslöschen konnte. Jedoch die fehlenden Gruppen ließen sich nicht hinzufügen.

Es erscheint dann gleiche Fehlermeldung wie im ersten Post. Es kann die Datei GptTmpl.inf nicht beschrieben werden.

 

Irgendwie seltsam:

Ganz oben ist "Ändern der Systemzeit". Hier kann ich z.B. die Gruppe Druck-Operatoren hinzufügen und auch wieder entfernen.

Bei dem Eintrag "Laden und entfernen von Gerätetreibern" funktioniert das nicht.

 

Es wird irgendwie immer kurioser:

 

Jetzt war ich beim Eintrag "Lokal anmelden zulassen". Da fehlten auch 3 oder 4 Gruppen. Nach ca. 10 Minuten konnte ich dann doch eine weitere Gruppe hinzufügen. Anschließend hatte ich dann eine weitere Gruppe hinzugefügt. Auch das funktionierte.

Zum Schluss fehlte noch die Gruppe "Server Operatoren". Nach dem Klick auf OK sieht man auch, dass der Schreibvorgang irgendwie länger dauert. Anschließend erscheint die bekannte Fehlermeldung.

Dann hatte ich wieder ca. 10 Minuten verstreichen lassen. Auf einmal ließ sich dann auch noch die letzte fehlende Gruppe dort hinzufügen.

 

 

[RalphT 15]

Ich habe nochmal etwas rumprobiert.

 

Eine neues GPO erstellt.

 

Im Zweig Computerkonfiguration/Windows-Einstellungen/Sicherheitseinstellungen/Lokale Richtlinien/Zuweisen von Benutzerrechten

 

einiges an Werten verändert.

 

Mal gehts sofort, im gleichen Augenblick danach kann man die Gruppe nicht mehr entfernen. Dann wieder und wieder probieren zu entfernen. Auf einmal funktioniert es. Sieht mir so nach einem Zufallsprinzip aus.

 

Andere Zweige, wie z.B. Computerkonfiguration/Administrative Vorlagen, da gibt es anscheinend keine Probleme. Hier kann man nach Belieben Werte aktivieren und wieder deaktivieren.

Das Problem scheint nur in den oberen System-GPOs zu liegen.

 

Jetzt könnte ich natürlich bei der neuen GPO solange probieren, bis alle Einträge sitzen. Das würde dann wahrscheinlich auch später wohl funktionieren. Denn die Einträge in der GptTmpl.inf sind ja korrekt.

 

Die Sicherung aller GPOs hat natürlich auch ohne Fehlermeldungen funktioniert, da ich das GPO mit den unbekannten SIDs bereinigt hatte.

 

[Nobbyaushb 1.371]

Ich lese ja bislang nur mit

Meine Frage - wie viele DC´s hast du, wie ist die Verbindung untereinander?
Steht einer an einem anderen Standort, sind Firewall zwischen den DC´s?

 

Liest sich wie ein Sync-Problem im AD

 

[RalphT 15]

vor einer Stunde schrieb Nobbyaushb:

Liest sich wie ein Sync-Problem im AD

Habe ich auch schon gerade im Verdacht. Ich bin ja immer noch in der Findungsphase.

 

Ich habe hier 2 DCs und woanders auch 2 DCs stehen. Der DC mit den FSMO-Rollen steht hier. Verbunden über eine gute Leitung, über VPN und Firewalls.

 

Jetzt hatte ich gerade von der Zweigstelle das gleiche Verfahren auf einem der DCs probiert. Also die gleiche GPO editiert. Dort nach Belieben etwas verändert. Funktionierte super schnell und einwandfrei. Dann dachte ich schon daran, das das Phänomen nur auf einer Seite besteht.

Nein, denn ein Nachfolgeversuch auf der Gegenseite war anschließend nicht erfolgreich.

 

Wenn man den Editor öffnet und dort etwas einstellt und anschließend auf OK oder Übernehmen klickt, dann geht das mal superschnell und im Fehlerfall "klemmt" es richtig. Der blaue Mauskreis dreht sich ca. 2 Sekunden.

 

Was mich so stutzig macht:

Warum funktionert es bei einem großen Teil der Werte und bei bestimmten Zweigen nicht? es wird doch die gleiche Datei beschrieben. Oder denke ich falsch?

bearbeitet 30. April von RalphT

[Nobbyaushb 1.371]

Auf jedem DC ein CMD als Administrator aufmachen

repadmin /syncall /force

Und das bitte auf allen 4 DC´s

In der Ausgabe stehen eventuelle Probleme, meist mit einem Hinweis

Wie hoch ist die Latenz zwischen den Standorten?

Ein Forrest und ein AD?

[RalphT 15]

vor 1 Stunde schrieb Nobbyaushb:

Auf jedem DC ein CMD als Administrator aufmachen

repadmin /syncall /force

Und das bitte auf allen 4 DC´s

In der Ausgabe stehen eventuelle Probleme, meist mit einem Hinweis

Wie hoch ist die Latenz zwischen den Standorten?

Ein Forrest und ein AD?

Darüber hatte ich auch schon nachgedacht. Habe es aber aus einem anderen Grund erstmal verworfen.

 

Mir ist aufgefallen, dass die beiden DCs hier recht lahme Krücken sind. Ein STRG-ALT ENTF dauert bestimmt 5 bis 10 Sekunden, bis mal der Bildinhalt zu sehen ist. RAM haben die jeweils 16G, der ist nur zu 30% ausgelastet. Die Prozessorleistung ist ständig bei 30% ausgelastet. Das kam mir recht viel vor. Ich habe noch andere Server, ähnlicher Bauart. Das sind z.B. einfache Fileserver usw. Die regieren wesentlich flotter. Bei denen ist die Dauerlast vom Prozessor bei mal gerade 5%.

 

Die Prozessorlast kommt bei den DCs vom Virenschutz. Jetzt hatte ich heute noch gesehen, dass der Virenschutz überall einen Neustart erfordert.

Ich werde daher jetzt als aller erstes die Rechner alle neustarten. Danach sehe ich mir nochmal die Prozessorlast auf den beiden DCs an.

Ich hatte letzt den Exchange 5 oder 6 mal booten müssen, bis alle Windows-Updates und Virenschutzupdates zufrieden waren. Daher war vorhin noch meine Vermutung, dass das vielleicht die Fehlerursache sein könnte.

 

Anschließend werde ich mal wie du geschrieben hattest die Replikation anschubsen.

 

Zwischenzeitlich hatte ich vorhin mit einer Test-GPO rumgespielt. Mir einen Wert ausgesucht, z. B. "Anmelden am Dienst verweigern" und dann immer einen Nutzer nach dem anderen im Sekundentakt reingebracht und wieder entfernt. Mal gehts zwei mal, und dann wieder 2 oder 3 mal nicht.

 

Die Latenz? Hm, ich glaube ein Ping hat so eine Antwortzeit von 10 - 15 ms. Bin mir da aber nicht so genau sicher.

[daabm 1.197]

GPOs sind zweiköpfige Monster. Der eine Kopf steckt in Active Directory, der andere in Sysvol. Und die zwei haben unterschiedliche Replikationsmechanismen... AD-Replikation vs. DFSR. "Replikation anschubsen" ist fast immer nur AD und nicht DFSR - und beim Bearbeiten der Inhalte ist immer DFSR relevant, fast nie AD. repadmin kannst Du Dir in dem Fall also sparen, der ist flüssiger als Wasser

 

BTW: In GPMC kann man ein Debug Log aktivieren, das bei so was erstaunlich hilfreich ist - https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc737379(v=ws.10)?redirectedfrom=MSDN

(gilt immer noch, auch wenn da 2003 im Link steht )

 

PS: Für AV-Exceptions auf DCs gibt es fertige Listen bei Microsoft - https://support.microsoft.com/en-au/topic/virus-scanning-recommendations-for-enterprise-computers-that-are-running-windows-or-windows-server-kb822158-c067a732-f24a-9079-d240-3733e39b40bc - die würde ich dringend empfehlen umzusetzen.

 

PPS: Die SIDs S-1-5-80-... sind Service-SIDs. Die werden nicht aufgelöst, weil es den entsprechend benamsten Service auf dem jeweiligen Computer nicht gibt. Ich würde empfehlen, die drin zu lassen, wenn es keine untergeordneten GPOs gibt, die das "offiziell" setzen. Und S-1-5-32-549 sind die Server-Operatoren, die es nur auf Servern gibt, nicht auf Clients.

 

[NilsK 2.795]

Moin, 

 

Ein DC braucht weder viel RAM noch viel CPU. Wenn das also was lahm ist, dann ist das ein deutliches Zeichen, dass irgendwas aus dem Lot ist. 

 

Gruß, Nils

 

[Nobbyaushb 1.371]

Sind das physische Maschinen oder VM‘s?

Wie viele Kerne sind zugewiesen (wenn VM) - einer ist d..f

Bin bei Nils, 16G braucht ein DC nicht, und wenn der ständig bei 30% Last ist stimmt was anderes nicht 

Was für ein AV ist installiert, die Ausnahmen korrekt gesetzt?

und danke an Martin, mache Dinge vergisst man im Laufe der Zeit 

bearbeitet 30. April von Nobbyaushb

[daabm 1.197]

vor 21 Stunden schrieb NilsK:

Ein DC braucht weder viel RAM noch viel CPU.

 

Ehm... https://learn.microsoft.com/en-us/windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services

Unsere größte Domäne hat knapp 200.000 User -> direkt mal 16 GB RAM als unteres Limit.

[cj_berlin 1.164]

Ich habe auf diesen Kommentar gewartet @daabm  

[NilsK 2.795]

Moin,

 

Ja, ich wusste auch, dass Martin sich nicht zurückhalten kann. Und dass wir ihn (bzw. alle anderen Lesenden dieses Threads) dann darauf hinweisen müssen, dass seine AD-Umgebung mit weitem Abstand ein Ausreißer ist. 

 

Martin weiß so gut wie wir, dass jemand, dessen Umgebung so groß ist, die hier diskutierten Fragen gar nicht stellen würde, weil er über Personal und Prozesse verfügt, die das unnötig machen. Anderen hier ist das möglicherweise nicht bewusst, daher weisen wir gern erneut darauf hin. 

 

Und natürlich weiß Martin auch, dass ein DC mit 16 GB auch in so einer großen Umgebung nicht derart langsam sein würde wie beschrieben, sodass der Kern meiner Aussage eben doch zutrifft. Auch hier sei das aber für alle anderen noch mal erwähnt.

 

Gruß, Nils