GPO - Fehler beim Editieren

[daabm 1.366]

Stimmt alles. Was aber auch stimmt: Wir tendieren dazu, die "Last" und damit das Sizing eines DC an der Größe der Physik festzumachen. Das ist aber nur die halbe Wahrheit. Die Menge an Objekten in AD hat mit der Physik zwar "regelmäßig" direkt zu tun, aber nicht zwingend.

 

Beispiel? Gerne Ich hab irgendwann spaßeshalber in einer Umgebung mit 2 DCs, 2 Membern und 5 Usern 15.000 Sites und 50.000 Subnetze angelegt. Ergebnis: Domäne nahezu unbedienbar. Die reale Umgebung hat sich dabei nicht verändert, nur der Inhalt von AD. Netlogon/LSASS 100% CPU, KCC/ISTG werden nicht mehr fertig. Wenn ich damit in ein Forum gehe, weil meine dsa.msc fast unbedienbar ist: "Die Umgebung ist klein, nur 2 DCs und ne Handvoll Computer und User".

 

Vielleicht lief mal ein Skript Amok und hat 2 Mio. User angelegt? Vielleicht gibt es endlose Gruppenverschachtelungen?

 

"Etwas aus dem Lot" @NilsK ist da die zutreffende Formulierung, aber bisher kam vom TO nichts dazu.

 

Und damit verweise ich wieder auf meinen Post oben: GPMC Debug Logging könnte helfen. Korrekte AV-Exceptions könnten helfen. Prüfen der DFS-Replikation (nicht dcdiag/repadmin!) könnte helfen.

Und wenn man wüßte, welche Prozesse die 30% CPU verursachen, könnte das auch helfen. "Virenschutz" ist mir da zu pauschal - ist es ein bestimmtes Modul?

[NilsK 2.954]

Moin, 

 

First things first - ich würde "etwas aus den Lot" erst mal bei den naheliegenden Dingen suchen. Updates, die nicht abgeschlossen sind. Virenscanner mit falscher Konfiguration. Kaputte Treiber. Software, die sich nicht benimmt. In der beschrieben Situation wird sich sicher im Event Log und im Process Monitor was finden.

 

Es geht mir ja nicht darum, deine Erfahrung in Zweifel zu ziehen oder dich bloßzustellen - aber in kleinen und mittleren Umgebungen sind es typischerweise nun mal sehr "irdische" Probleme, mit denen man zu tun hat. Der Verdacht, dass "das AD" zu viel Last verursache, lässt sich so gut wie nie erhärten.

 

Gruß, Nils

[daabm 1.366]

Womit Du natürlich Recht hast Warten wir mal entspannt auf den TO...

[RalphT 15]

vor 17 Stunden schrieb daabm:

"Etwas aus dem Lot" @NilsK ist da die zutreffende Formulierung, aber bisher kam vom TO nichts dazu

 

Stimmt. Denn der hat sich die 2 Tage bei gutem Wetter eine Auszeit gegönnt.

 

Ich war heute kurz vor Ort und habe die beiden DCs neu gestartet. Es war beiden tatsächlich ein Update vom Virenscanner (Panda) noch nicht fertig.

Nach dem Neustart merkte man sofort, dass die beiden Geräte wieder wesentlich flotter auf Eingaben reagieren. Mir war auch so, dass ein DC erst mal so nicht viel an Resourcen benötigt. Das war damals bei Novell auch so.

 

Das tückische hierbei war, dass der Virenschutz einen benötigten Neustart nicht angezeigt hatte.

 

Anschließend habe ich das gleiche Verfahren auf beiden DCs wieder ausprobiert. Läuft!

Beim Klick auf OK reagiert das Menü sofort. Das war vorher nicht der Fall. Man sah richtig, wie das manchmal klemmte.

 

Jetzt habe ich zum Schluss aber trotzdem noch eine Frage:

 

Wenn ich auf dem DC 1 den GPO-Editor öffne und dort etwas verändere, dann werden die Änderung ja auf dem SYSVOL geschrieben.

Wird dann in diesem Fall auf dem SYSVOL vom DC 1 geschrieben? Also auf seine Festplatte? Oder kann man das gar nicht so genau sagen? Die Änderung ist doch auf allen DCs sofort verfügbar oder liege ich da falsch?

Denn mit der eigentlichen Replikation hat dieses hier doch nichts zu tun.

[cj_berlin 1.329]

vor 25 Minuten schrieb RalphT:

Denn mit der eigentlichen Replikation hat dieses hier doch nichts zu tun.

Kommt darauf an, was für Dich die "eigentliche" Replikation ist. Das hat mit der AD-Replikation vielleicht nichts zu tun, dafür aber mit der DFS-Replikation, denn die SYSVOL-Inhalte kommen nicht "mit der Macht" auf die anderen Domain Controller.

 

Mit welchem DC Dein GP Editor verbunden ist, kannst Du direkt im Editor sehen:

[NorbertFe 2.061]

vor einer Stunde schrieb cj_berlin:

nicht "mit der Macht" auf die anderen Domain Controller.

Und das am heutigen Tage? 😂 das glaubst du doch selbst nicht.

[NilsK 2.954]

Moin,

 

vor 12 Stunden schrieb RalphT:

Das war damals bei Novell auch so.

na, das liest man aber auch nur noch selten. 

 

Gruß, Nils

[daabm 1.366]

Am 4.5.2024 um 19:46 schrieb cj_berlin:

Mit welchem DC Dein GP Editor verbunden ist, kannst Du direkt im Editor sehen:

..das ist nur die AD-Verbindung von GPMC selbst und - in der Theorie - GPEdit. Sysvol geht über DFSR und hat leider andere Mechanismen. Wenn in der aktuellen Site mehr als ein DC steht, ist der Sysvol-Zugriff undefiniert. Frag mich per PN, woher ich das weiß Oder wenn allgemein von Interesse, dann auch hier.

 

Und auch bei der AD-Verbindung haben manche Snapins immer wieder Probleme - WLAN war eines davon, das hat den DC aus GPMC/GPEdit schlicht ignoriert, Folge Replikationskonflikte in AD. (WLAN speichert seine Settings nicht in Sysvol, sondern in AD.)

[NilsK 2.954]

Moin, 

 

Dann bitte hier.

 

Gruß, Nils 

 

[testperson 1.704]

vor 21 Minuten schrieb NilsK:

Dann bitte hier.

 

+1  

[daabm 1.366]

Ok Wir haben ein Drittprodukt (Quest GPOAdmin), das GPOs über Domänengrenzen synchronisieren kann. Ein in der Quelldomäne per GPMC-API erstelltes GPO-Backup im ZIP-Format wird dabei zum Zielserver übertragen. Dort wird von der Ziel-GPO eine tempoärer Kopie erzeugt und dann das entpackte Zip (wieder per GPMC-API) in diese Kopie importiert. Danach wird (wieder GPMC-API) davon ein Backup estellt, die temporäre Kopie gelöscht und das aktuelle Backup in die ursprüngliche "produktive" GPO importiert (noch mal GPMC-API). (Klingt aufwändig mit der temporären Kopie und dem vielen Import/Export, das hängt mit den verfügbaren Workflows zusammen - man kann nicht nur "immediate deployment" machen, sondern auch erst mal "stagen"- das sprengt den Rahmen hier aber.)

 

Das arbeitet also mit ein wenig Zip/Copy, der Rest ist GPMC-API nativ.

 

Dabei fällt der Import in die temporäre Kopie regelmäßig auf die Nase, wenn der jeweilige Server mehr als einen DC sieht. In AD wird das GPC-Objekt immer auf dem PDC angelegt (das kriegt das GPMC-API noch hin). Der GPT-Sysvol-Ordner entsteht dabei ebenfalls "initial" - aber nicht auf dem PDC, sondern "irgendwo". Der folgende Import per GPMC-API greift AD-seitig auch nur auf den PDC zu und findet den GPC-Container. Der Dateiimport in den GPT-Sysvol-Ordner läuft über DFSR aber wieder gegen "irgendeinen" DC. Und DFSR hat auch innerhalb einer Site Latenzen -> Sysvol-Ordner nicht vorhanden -> "Path not found".

 

Macht man das von Hand, ist es i.d.R. kein Problem, weil man von Hand nicht so schnell klicken kann (DFSR-Latenzen intra-site sind im Sekundenbereich). Das ganze läuft hier aber programmatisch: Neue temporäre Kopie erstellen und "sofort" importieren.

 

Ich hoffe, das ist soweit verständlich ausgedrückt

 

Workasround: In jeder Domäne eine Site, in der nur der PDC und der jeweilge Server stehen. Dann ist nicht nur AD zufrieden, sondern auch DFSR - das findet dann auch nur noch "the one"

 

Das WLAN-Snapin war diesbezüglich auch speziell. Das hatte den Bug, daß es die DC-Auswahl in GPMC, die von GPMC an GPEdit (korrekt eigentlich: GPME.MSC) beim Aufruf weitergegeben wird, ignoriert hat und auch "irgendeinen" DC auswählte. Ergebnis: Klickte man in GPEdit auf "neue WLAN-Policy", wurde von GPEdit auf dem PDC im GPO-Container ein "Machine"-Container erstellt. Das Snapin selbst erstellt darin dann ein WLAN-Objekt, bei Bedarf aber auch den zugehörigen Container. Ging das nicht gegen den PDC -> Replikationskonflikt (CNF:) für den "Machine"-Container, wenn es den nicht vorher "aus Gründen" schon gab -> GPO kaputt.

[NilsK 2.954]

Moin, 

 

Klingt plausibel. Also, eigentlich klingt das total beh*mmert, aber wenn man schon seit fast 25 Jahren Automatisierung von AD-Prozessen beobachtet, dann ist es eben plausibel. 

 

Nebenbei willst du uns aber sagen, dass das Quest-Tool diese Probleme nicht selbst behandelt, ja? Auch das würde ich in Verbindung mit dem Hersteller nicht zum ersten Mal hören. Was hatten wir vor 15 Jahren für einen Aufwand, hinter den Lücken im Migrator herzuscripten. (Aber das nur am Rande.)

 

Danke für den Einblick. 

 

Gruß, Nils

[daabm 1.366]

Quest behandelt das nicht selbst, warum auch - sie nutzen das GPMC-API, das für das Anlegen von GPH und GPT verantwortlich ist. Da müßte das gefixt werden...

[NilsK 2.954]

Moin,

 

Ja, schon, aber der Witz bei den Quest-Tools ist ja gerade, dass sie das leisten, was man von den Bordmitteln erwartet, aber nicht bekommt. Da wundert es mich dann immer wieder, dass sie selbst solche Lücken lassen. Zumal es für Quest, wenn ich es richtig verstanden habe, recht einfach sein müsste, das Problem zu umschiffen. Das Timing verändern oder mit ein paar Zeilen Code den richtigen DC ausfindig machen, dürfte ja so schwer nicht sein.

 

Gruß, Nils

[daabm 1.366]

Den richtigen DC finden sie ja schon. Kannst sogar einen "preferred" einstellen, falls der PDC hinter einem WAN-Link hängen sollte. Das Problem steckt in GPMC/DFSR. Und um das zu lösen, müssten sie das Anlegen und Importieren komplett nachbauen. Ich kann schon verstehen, daß man das nicht unbedingt will, wenn es doch "offizielle" APIs gibt. "Timing verändern" ist so ein zweischneidiges Schwert - wie lange willst denn warten, bis DFSR auf dem von Dir grad genutzten Referral das Verzeichnis erstellt hat?