langsame / teilweise / mehrfache Verarbeitung von Gruppenrichtlinien

[Florian-0625 0]

Hallo ins Forum,

wir haben seit einiger Zeit (lässt sich nicht definitiv sagen, da die Probleme sich nicht immer gleich zeigen) folgende Probleme in unserem AD:

- Richtlinien werden sehr langsam verarbeitet
- Richtlinien werden teilweise verarbeitet
- Richtlinien kommen auf dem Client nicht an
- Richtlinien werden teilweise mehrfach verabeitet (z.B. Scripte doppelt ausgeführt)
- DNS Registrierung / Aktualisierung (Forward- und Reverse-Lookup) passiert manchmal nicht
- DNS Registrierung / Aktualisierung funktioniert zum Teil nicht (Bsp. Forward-Lookup existiert und Reverse-Lookup fehlt, oder ist nicht aktualisiert)
- Anmeldung "hängt" in "Wilkommen" Dialog
- in den Ereignislogs werden fehlerhafte Anmeldungen (mehrfach) dokumentiert, auch wenn der User sich sofort korrekt anmeldet

Nun treten die Problem sporadisch und an unterschiedlichen Clients auf:

- direkt im LAN
- an Standorten per IPSec angebunden
- an Heimarbeitsplätzen per IPSec angebunden
- an Heimarbeitsplätzen per SSL Client angebunden

In den Ereignislogs finde ich leider gar keine Hinweise die weiterhelfen.

Wir haben zwei DCs in der Zentrale + an jedem Standort einen.

Wo kann ich am besten mit der Fehlersuche beginnen, wer hat hier eine Idee?

[cj_berlin 1.329]

Moin,

der letzte Punkt in der Fehlerbeschreibung lässt an Replikationsprobleme in Deinem AD denken...

Ich würde damit beginnen, die Sites & Subnets zu überprüfen, sicherstellen, dass alles der Physik entspricht und die Replikation - AD *und* DFS-R - fehlerfrei funktioniert.

Parallel würde ich, auch wenn's mit Deinem Problem nicht ursächlich zu tun hat, hinterfragen, ob ich für Geräte mit dynamischen IP-Adressen *wirklich* die rückwärtige DNS-Auflösung brauche.

[Florian-0625 0]

Hallo @cj_berlin,

 

danke für die Rückmeldung.

 

Was mir als erstes auffällt, ist unter Active Directory-Standorte und Sites:

 

Bei allen Standorten sind unter dem Standort DC unter NTDS-Settings jeweils die beiden DCs in der Zentrale - OK, aber auch ein Eintrag "<automatisch generiert>" von einem Standort DC, der gehört da nicht hin denke ich.

 

Beim Standort dessen DC bei allen anderen Standorten unter NTDS-Settings "<automatisch generiert>" hinzugefügt ist hingegen habe ich wiederum alle Standort DCs einmal mit "<automatisch generiert>" unter den NTDS-Settings.

 

Dies würde ich gern als erstes auflösen, wie gehe ich dazu vor?

 

[cj_berlin 1.329]

Wenn die Standorte nur Verbindungen zur Zentrale haben, aber nicht untereinander, musst Du wie folgt vorgehen:

• Unter "Inter-Site-Transports - IP" für jeden Standort einen Site Link hinzufügen, der nur den jeweiligen Standort und die Zentrale beinhaltet. Tu Dir selbst einen Gefallen und setze das "options" Attribut jedes dieser Links auf 1 (USE_NOTIFY)
• Wenn das fertig ist, den DEFAULTIPSITELINK löschen
• Wenn die Zentrale zwischen den Standorten routet, bist Du fertig
• Wenn die Zentrale nicht routet, klicke mit der rechten Maustaste auf den Container "IP" (wo die Site Links drin sind) und nimm den Haken raus bei "All links are bridged"

Das hast Du hoffentlich in der Zentrale gemacht. Öffne die Administrator-CMD auf dem DC, gegen den Du verbunden warst, und sage

repadmin /syncall /AdeP

(Groß- und Kleinschreibung ist wichtig)

[Florian-0625 0]

Hallo @cj_berlin,

 

erst einmal vielen Dank für die Ausführung.

 

Aktuell ist ein Objekt "ZENTRALE" als Standortverknüpfung angelegt, welches alle Standorte und die Zentrale beinhaltet.

 

D.h. ich würde dieses eine Objekt löschen, nachdem ich für jeden Standort ein neues Objekt angelegt habe, welches die Zentrale und den jeweiligen Standort berücksichtigt, richtig?

 

DEFAULTIPSITELINK ist wohl bereits entfernt.

 

Zur Info, alle Standorte können untereinander die DCs erreichen, jedoch sind einige mit nicht besonders leistungsfähigen Internetanschlüssen angebunden. Besser wäre es also, wenn die Standorte nur zu den DCs in der Zentrale sprechen.

[cj_berlin 1.329]

Genauso machst Du das.

[Florian-0625 0]

Hallo @cj_berlin,

 

ich habe dies so gemacht. Unter den beiden DCs aus der Zentrale (NTDS Settings) haben sich die Standort DCs verteilt "automatisch generiert".

 

Unter den Standort DCs (NTDS Settings) sind ja noch jeweils die beiden DCs aus der Zentrale fest eingetragen, soll ich diese entfernen und die automatisch generierten Einträge übernehmen lassen?

[cj_berlin 1.329]

Moin,

 

das würde ich machen. Eine Topologie, die automatisch die korrekten Verbindungen erzeugt, ist immer schöner, als manuell nachhelfen zu müssen. Zumal bei Dir ja keine extremen Sonderlocken vorhanden sind. Du wirst allerdings nur eine Verbindung automatisch angelegt bekommen, und das ist auch gut so.

[toao 4]

Hi,
 

folgende Prüfungen könntest Du nun mal durchführen (DC Locator Prozess):
 

Am Client\Server selbst den nachfolgenden Registry Eintrag 
HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName einsehen und schauen was unter "Data" steht. Steht dort die "Site", welche Du unter "Sites&Services" inklusive des Subnetztes konfiguriert hast und diese stimmig zum Standort des Clients\Servers ist, ist das ein guter Start.

*Sidenote und bitte nur für den Troubleshooting Fall nutzen: 
Den DynamicSiteName Eintrag kann man über folgenden Registry Eintrag aushebeln:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters REG_SZ "SiteName" und unter Data dann die Site, die Du manuell eintragen möchtest. Wie erwähnt, sollte nur im Notfall/Troubleshooting Fall eingesetzt werden.

Wozu das ganze? Jeder Windows domain joined Client schaut beim DynamicSiteName Eintrag nach um für seine Site die verfügbaren DCs zur Anmeldung herauszufinden, dass macht er dann über einen DNS request, welcher dann die "Site" enthält.
Nachdem Du nun die "Sites&Services" Konfiguration geändert hast, könntest Du im "DNS" (ich gehe jetzt davon aus, Du hast die DNS Windows Rolle auf Euren DCs installiert) nachschauen, ob die DNS RR SRV Einträge korrekt aktualisiert wurden. Je nach Umgebung habe ich da von fantastisch aufgeräumten Einträgen bis hin zu Dschungel artigen Gegebenheiten gesehen.

DNS Pfad Rootdomain: ForwardLookupZone _msdcs.[domain].dc._sites.[Sitename]._tcp
DNS Pfad Childdomain: ForwardLookupZone [domain]._msdcs_dc.sites.[Sitename]._tcp

*Sidenote, es gibt noch einige anderes DNS Pfade, die für andere Szenarien\Gegebenheiten als Quelle von 3rd Party Solution anbietern, etc. genommen werden, beim DC Locator Prozess sind es die oben genannten.

Solltest Du nun DNS RR SRV Einträge sehen, die nicht stimmig sind, kannst Du diese  entfernen (Obacht: Sofern nach Bereinigung gar keine SRV Einträge übrig bleiben würden, bitte nicht löschen und zunächst Troubleshooten ;)

*Sidenote, sollten im DNS gar komplette DNS "Site" Einträge fehlen, kann ich dir wärmstens den folgenden Artikel empfehlen:
https://techcommunity.microsoft.com/t5/ask-the-directory-services-team/sites-sites-everywhere-8230/ba-p/399239#:~:text=Domain Controllers cannot calculate site,first%3B that's up to you.

Zu guter letzt sei die GPO Einstellung "Enabling Clients to Locate the Next Closest Domain Controller" zu erwähnen, dass verbessert quasi den DC Locator Prozess in der Hinsicht, dass bevor der letzte Prozess Schritt "find any Domain Controller" durchgeührt wird, der Schritt "find next closest site" zunächst in Erwägung gezogen wird. Eventuell habt Ihr diese Einstellung ja schon, daher nur sicherheitshalber erwähnt.

Viele Grüße,
toao

 

[Florian-0625 0]

Hallo @cj_berlin, hallo @toao,

 

ich habe die Einstellungen von @cj_berlin soweit umgesetzt.

 

Ich habe auch weitere Netze ergänzt, von Clients, die ich under Debug\netlogon auf den DCs gefunden haben.

 

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName zeigt am Client den gewünschten Standort

 

DNS Pfad Rootdomain: ForwardLookupZone _msdcs.[domain].dc._sites.[Sitename]._tcp, DNS Pfad Childdomain: ForwardLookupZone [domain]._msdcs_dc.sites.[Sitename]._tcp - in beiden Pfaden sind die Standorte sauber mit den entsprechenden DCs zu sehen

 

Wo finde ich diese Einstellung "Enabling Clients to Locate the Next Closest Domain Controller", wie heißt hier die Überordnung?

 

 

[cj_berlin 1.329]

Gerade eben schrieb Florian-0625:

Wo finde ich diese Einstellung "Enabling Clients to Locate the Next Closest Domain Controller", wie heißt hier die Überordnung?

Wenn Du in allen Sites DCs hast und die Topologie nun stimmt, ist sie nicht erforderlich. Ansonsten, Enabling Clients to Locate the Next Closest Domain Controller | Microsoft Learn

[Florian-0625 0]

Hallo zusammen,

 

ich denke diese Baustelle passt nun. Von den Eingangs genannten Probleme greife ich mir eines heraus, was definitiv noch existiert.

 

Mindestens drei Skripte werden bei jedem Anmeldevorgang am Client statt einmal, zweimal ausgeführt. Wie kann ich den Grund dafür herausfinden?

[cj_berlin 1.329]

Wo sind die Skripte hinterlegt? Group Policy? Dann sind sie vielleicht in zwei, drei GPOs hinterlegt, die da gelten - GPRESULT ist Dein Freund.

[daabm 1.366]

Logon Skripts, GPO mehrfach verlinkt bei User und Computer, Loopback Merge? So als Ergänzung zu @cj_berlin 

[cj_berlin 1.329]

Was auch gerne genommen wird, sind GPOs, welche das Skript nicht ausführen, sondern als geplanten Task hinterlegen. Das kannst Du auch nochmal checken.

bearbeitet 26. September von cj_berlin