Ausführung Startskript an entferntem Standort (Site) dauert sehr lange

[geologist 10]

Moin moin,

 

ich habe folgendes Problem:

 

die Abarbeitung eines Startskriptes dauert an einem entfernten Standort sehr viel länger (ca. sieben Minuten) als an der Hauptniederlassung (ca. 30 Sekunden). Beim Anmeldeskript ist dies nicht der Fall.

 

Domänendesign:

Gesamtstruktur mit übergeordneter Stammdomäne und mehreren, parallel angeordneten Subdomänen (stamm.xy, sub1.stamm.xy, sub2.stamm.xy, ...). Alle DCs sind GCs, keiner ist RODC, alle W2K8.

 

DNS-Konfiguration der entfernten Clients:

Bevorzugter DNS-Server=DC des entfernten Standortes, alternativer DNS=DC der Hauptniederlassung.

 

Skripte:

Startskript per Gruppenrichtlinie, liegt in "...\Sysvol\...\scripts\startup"

Anmeldeskript per Userattribut in AD (Profil > Anmeldeskript), liegt in "Netlogon" (historisch gewachsen ...).

 

Standorte:

Sites wurden für Hauptniederlassung und mehrere entfernte Standorte eingerichtet, die dortigen Domänencontroller wurden in die entsprechenden Sites verschoben, Site "Default-First-Site-Name" wurde weder umbenannt noch gelöscht.

 

DNS-Bereinigung:

In Zonen <sub1.stamm.xy\_msdcs\_sites\Default-First-Site-Name\_tcp>, <sub1.stamm.xy\_sites\Default-First-Site-Name\_tcp> und <sub1.stamm.xy\DomainDNSZones\_sites\Default-First-Site-Name\_tcp> wurden die SRV-Einträge der jeweiligen DCs gelöscht, da sie korrekt jeweils unter <...\_sites\"standort"\_tcp> vorhanden waren. Die SRV-Einträge der ersten beiden DCs der Hauptniederlassung erscheinen bei <...\Default-First-Site-Name\_tcp> jedoch nach mehreren Minuten immer wieder (übrigens auch bei den jeweiligen _sites-Zonen der Stammdomäne)! Warum?

 

Registry:

Bei den Clients steht unter HKLM\System\CurrentControlSet\services\Netlogon\Parameters beim Wert "DynamicSiteName" immer der korrekte Standort-Eintrag.

 

Wenn ich bei den entfernten Standort-Clients in den NIC-Einstellungen das Gateway entferne, läuft das Startskript immer so schnell ab, wie in der Hauptniederlassung, mit Gateway (also korrektem Routing) dauert das erheblich länger (s. o.). Der enfernte Client zieht das Startskript also offenbar von einem DC der Hauptniederlassung. Nach der Anmeldung läuft das Anmeldeskript immer zügig durch, der Logonserver (Abfrage mit set) ist auch immer der entfernte DC, das funktioniert also.

 

Muss ich etwa in der NIC-Konfiguration der entfernten Clients den alternativen DNS-Server entfernen? Stimmt irgendwas mit der Site "Default-First-Site-Name" nicht, muss dieser Eintrag gar gelöscht werden? Oder: DCs der Hauptniederlassung wieder dorthin verschieben, Site der Hauptniederlassung löschen und anschließend Site "Default-First-Site-Name" in Site der Hauptniederlassung umbenennen? Was könnte sonst das Problem sein?

 

Da denkt man, man hat alles richtig gemacht, ...

 

Viele Grüße

[zahni 587]

Gehe mal an einem PC in der "entfernten" Niederlassung und mach mal wiederholt:

 

ping fqdn Deiner DNS-Domäne (keinen Servernamen verwenden). Dabei sollte ein DC aus dem entfernten Standort antworten. Dann ipconfig /flushdns, usw.

 

Wenn dabei ein DC aus Deinem lokalen Standort antwortet ist was verkehrt.

(Sorry, ich werde aus Deine Beschreibung nicht gang schlau...)

 

-Zahni

[geologist 10]

DNS habe ich schon überprüft, auch nslookup gibt forward und reverse immer den DC des entfernten Standortes zurück.

[Sunny61 834]

DNS habe ich schon überprüft, auch nslookup gibt forward und reverse immer den DC des entfernten Standortes zurück.

 

Was sagt die Variable %LOGONGSERVER% am betroffenen Client aus? Kann der betroffene Client denn überhaupt auf das Script zugreifen? Fehlermeldungen im Ereignisprotokoll auf dem Client? Gpupdate /force hast Du schon ausgeführt? Was sagt RSOP.MSC auf dem Client?

[geologist 10]

Moin,

 

%LogonServer%: siehe oben, gibt den richtigen Standortserver aus.

rsop.msc: da steht auch nur das Startskript, aber nicht, von wo das ausgeführt wird

EventLog: keine Fehler

[Sunny61 834]

Kann der betroffene Client denn überhaupt auf das Script zugreifen?

[geologist 10]

Moin,

 

das ist ja gerade das Problem:

 

die Abarbeitung eines Startskriptes dauert an einem entfernten Standort sehr viel länger (ca. sieben Minuten) als an der Hauptniederlassung (ca. 30 Sekunden). Beim Anmeldeskript ist dies nicht der Fall.

 

Wenn die Clients an den entfernten Standorten GAR NICHT auf das Startskript zugreifen könnten, hätte ich ja die üblichen Möglichkeiten der Fehlersuche ...

[blub 115]

Hallo

 

Hast du in deinem Skript Loggingbefehle eingebaut? Dann solltest du erkennen können, an welchem Befehl (Netzlaufwerk / Druckverbinden etc.) das Skript hängen bleibt

Wenn du den Verdacht hast, dass es mit dem Netz zu tun hat, könntest du auch parallel einen Netzwerktrace ziehen und analysieren

 

cu

blub

[lefg 276]

Hallo,

 

ich frage mal so, was dauert denn wirklich lange, das Ablaufen des Skriptes oder das Ausfüheren der Befehle im Skript, z.B. das Mappen von Netzlaufwerken, wurde das schon mal beobachtet?

[geologist 10]

Moin,

 

das wurde beobachtet.

 

Nochmal: Nicht das Anmeldeskript (NACH der Anmeldung), wo z. B. Laufwerke gemappt werden, sondern das Startskript (VOR der Anmeldung) ist am entfernten Standort langsam. Nehme ich das Gateway am Client weg, läuft das Startskript schnell, also holt sich der Client vermutlich das Skript irgendwo her, aber nicht vom Standort-DC.

 

Es geht nicht um das Ausführen von Befehlen im Skript, sondern das Ablaufen des Skriptes dauert lange (selbst Kommentare im Skript laufen langsam). Das Skript bleibt auch nicht hängen, es ist nur sehr langsam.

 

Grüße