Lange Anmeldezeiten bei wechselden Anmeldungen in unseren Standorten
Hallo,
ich habe folgendes Phänomen/Problem:
Ich betreue als Admin eine Domäne mit fünf Standorte. Zwei DC im Hauptstandort und jeweils einen DC in den Standorten. Die DC in den Standorten halten alle den GC. Fünf DC sind Server 2008 R2 einer noch ein Server 2003. Alle Standorte sind über eine WAN Leitung verbunden. Clients sind Win7 32/64 Bit.
Zum LW und Drucker verteilen nehmen wir Start KIX Skript.
Wenn ein User mit seinem Notebook den Standort wechselt dauert das Anmelden genausolange wie sonst also sehr schnell. Aber das Start KIX Skript was in der folge abläuft braucht Factor 5 bis 10 mal länger zum durchlaufen.
Der Grund habe ich gefunden, der Client meldet sich bei der ersten Anmeldung in einem Standort immer am DC des Ursprünglichen Standortes an. Da dann die Gruppenmitgliedschaften über die WAN Strecke geprüft werden läuft das Skript natürlich länger. Nach einem Neustart des Clients stimmt wieder alles, die Anmeldung findet am lokalen DC statt. Das Start KIX Skript läuft schnell durch da die Gruppenmitgliedschaften am lokalen DC im LAN geprüft werden. Nehme ich das Notbook wieder in einen anderen Standort mit habe ich wieder das gleiche verhalten. Nach der ersten Anmeldung dauert das durchlaufen des Start KIX Skriptes lange.
Beim zweiten mal geht alles wieder normal.
Frage: Wie kann ich die Clients zwingen schon beim ersten Anmelden in einem Standort den lokalen DC zu nehmen? Hat da jemand eine Idee?
Folgendes habe ich mir schon angeschaut:
Die Site Konfiguration unter Active Directory-Standorte und Dienste, die Subnets sind richtig zugeordnet. Im DNS habe ich nach falschen oder alten SRV Einträge gesucht und bisher keine relevanten gefunden.
Danke!
Gruß
Locutus
ich habe folgendes Phänomen/Problem:
Ich betreue als Admin eine Domäne mit fünf Standorte. Zwei DC im Hauptstandort und jeweils einen DC in den Standorten. Die DC in den Standorten halten alle den GC. Fünf DC sind Server 2008 R2 einer noch ein Server 2003. Alle Standorte sind über eine WAN Leitung verbunden. Clients sind Win7 32/64 Bit.
Zum LW und Drucker verteilen nehmen wir Start KIX Skript.
Wenn ein User mit seinem Notebook den Standort wechselt dauert das Anmelden genausolange wie sonst also sehr schnell. Aber das Start KIX Skript was in der folge abläuft braucht Factor 5 bis 10 mal länger zum durchlaufen.
Der Grund habe ich gefunden, der Client meldet sich bei der ersten Anmeldung in einem Standort immer am DC des Ursprünglichen Standortes an. Da dann die Gruppenmitgliedschaften über die WAN Strecke geprüft werden läuft das Skript natürlich länger. Nach einem Neustart des Clients stimmt wieder alles, die Anmeldung findet am lokalen DC statt. Das Start KIX Skript läuft schnell durch da die Gruppenmitgliedschaften am lokalen DC im LAN geprüft werden. Nehme ich das Notbook wieder in einen anderen Standort mit habe ich wieder das gleiche verhalten. Nach der ersten Anmeldung dauert das durchlaufen des Start KIX Skriptes lange.
Beim zweiten mal geht alles wieder normal.
Frage: Wie kann ich die Clients zwingen schon beim ersten Anmelden in einem Standort den lokalen DC zu nehmen? Hat da jemand eine Idee?
Folgendes habe ich mir schon angeschaut:
Die Site Konfiguration unter Active Directory-Standorte und Dienste, die Subnets sind richtig zugeordnet. Im DNS habe ich nach falschen oder alten SRV Einträge gesucht und bisher keine relevanten gefunden.
Danke!
Gruß
Locutus
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 189452
Url: https://administrator.de/forum/lange-anmeldezeiten-bei-wechselden-anmeldungen-in-unseren-standorten-189452.html
Ausgedruckt am: 07.05.2025 um 22:05 Uhr
11 Kommentare
Neuester Kommentar
moin,
das kann ich so nicht wirklich nachvollziehen, denn da fehlt u.a das Kixscript.
Und dann die banalste Frage - werden die kisten mit eingesteckten Lan gebootet, oder stecken die das nach dem hochfahren an?
Gruß
das kann ich so nicht wirklich nachvollziehen, denn da fehlt u.a das Kixscript.
- woher weißt du das mit dem ersten mal anmelden und "alten" DC?
Die Site Konfiguration unter Active Directory-Standorte und Dienste, die Subnets sind richtig zugeordnet.
Dass die netze die richtigen dcs zugewiesen haben?Und dann die banalste Frage - werden die kisten mit eingesteckten Lan gebootet, oder stecken die das nach dem hochfahren an?
Gruß
Moin,
danke für deine Antwort. Mir fällt echt nix mehr zu meinem Problem ein.
also in der CMD sehe ich mit dem SET Befehl den aktuellen Anmeldeserver.
Ja genau das.
Ja, die Notbooks sind beim Hochfahren angestöpselt. Habe ich selbst getestet.
Das Kixscript ist doch erstmal egal, der Anmeldeserver ist das erste mal immer der vom vorgehenden Standort. Das bedeutet
das das Kixscript im Netlogon vom Remote DC ausgeführt wird. Deshalb brauch das Kixscript länger.
Gruß
Locutus
danke für deine Antwort. Mir fällt echt nix mehr zu meinem Problem ein.
Zitat von @60730:
- woher weißt du das mit dem ersten mal anmelden und "alten" DC?
also in der CMD sehe ich mit dem SET Befehl den aktuellen Anmeldeserver.
Dass die netze die richtigen dcs zugewiesen haben?
Ja genau das.
Und dann die banalste Frage - werden die kisten mit eingesteckten Lan gebootet, oder stecken die das nach dem hochfahren an?
Ja, die Notbooks sind beim Hochfahren angestöpselt. Habe ich selbst getestet.
das kann ich so nicht wirklich nachvollziehen, denn da fehlt u.a das Kixscript.
Das Kixscript ist doch erstmal egal, der Anmeldeserver ist das erste mal immer der vom vorgehenden Standort. Das bedeutet
das das Kixscript im Netlogon vom Remote DC ausgeführt wird. Deshalb brauch das Kixscript länger.
Gruß
Locutus
- du hast aber schon dhcp aktiv und keinen festen DNS vergeben?
- und die GPO "warte aufs Netzwerk" ist auch aktiv?
- du hast kosten auf die einzelnen WAN Strecken gelegt?
- wenn so eine Kiste frisch aus dem anderen Standort hochgefahren ist, dann muß u.a in
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters ein RegSz "DynamicSiteName" mit dem aktuellen Standort vorhanden sein.
- Mag sein, dass das Kixscript egal ist, aber wenn da Netzwerkdrucker gemappt werden....
- Anyway - meine kixscripte laufen nur unmerklich langsamer, wenn ich die gezielt von nem anderen Standort DC aus starten lasse und ich hab auch mit 2 mbit verbundene Standorte. Von daher würde ich das mit "egal" erstmal nicht so weit weglegen.
Gruß
Moin,
"warte aufs Netzwerk".............
Ohne es zu wissen aber das könnte es sein. Ich schau heute nach.
Über das kixscript können wir uns gerne unterhalten, da ich nicht glaube das das bei uns optimal ist. Das Grundgerüst ist von 2003 und vor meiner Zeit, ich habe es immer nur ergänzt. Hat ja gut funktioniert...
Das habe ich im Vorfeld schon geprüft, war OK.
Wir haben 8 mbit in jedem Standort, und trozdem leichte Performance Probleme über die WAN Strecke.
Im normal Fall läuft das Skript max 30 Sekunden, über die WAN Strecke 5-6 Minuten. Über VPN bis zu 50 Minuten
Diese Probleme versuche ich gerade zu lösen. Das das Skript über VPN solange braucht ist relativ neu....., es könnte sein das das Problem seit der Umstellung auf die 2008 R2 DC´s exsistiert. Aber sicher bin ich mir nicht.
Vielen Dank! Echt gute Einfälle und geballtes Wissen hier!
Gruß
Locutus
"warte aufs Netzwerk".............
Ohne es zu wissen aber das könnte es sein. Ich schau heute nach.
Über das kixscript können wir uns gerne unterhalten, da ich nicht glaube das das bei uns optimal ist. Das Grundgerüst ist von 2003 und vor meiner Zeit, ich habe es immer nur ergänzt. Hat ja gut funktioniert...
HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters ein RegSz "DynamicSiteName" mit dem aktuellen Standort vorhanden sein.
Das habe ich im Vorfeld schon geprüft, war OK.
Wir haben 8 mbit in jedem Standort, und trozdem leichte Performance Probleme über die WAN Strecke.
Im normal Fall läuft das Skript max 30 Sekunden, über die WAN Strecke 5-6 Minuten. Über VPN bis zu 50 Minuten
Diese Probleme versuche ich gerade zu lösen. Das das Skript über VPN solange braucht ist relativ neu....., es könnte sein das das Problem seit der Umstellung auf die 2008 R2 DC´s exsistiert. Aber sicher bin ich mir nicht.
Vielen Dank! Echt gute Einfälle und geballtes Wissen hier!
Gruß
Locutus
Hallo,
die GPO "warte aufs Netzwerk" war nicht aktiv.
Ich werde die GPO "warte aufs Netzwerk" aktvieren und das Verhalten anhand ein paar Clients testen.
Zitat von TimoBeil:
Einen DHCP dibt es in jedem Standort und ist auch aktiv.
Nein Kosten sind keine mehr festgelegt. Also auf Standard eingestellt.
Das Skript läuft, wenn es langsam läuft, gleichmäßig langsam ab.
Sobald ich fertig getestet habe, melde ich mich mit den Ergebnissen wieder.
Gruß
Locutus
die GPO "warte aufs Netzwerk" war nicht aktiv.
Ich werde die GPO "warte aufs Netzwerk" aktvieren und das Verhalten anhand ein paar Clients testen.
Zitat von TimoBeil:
du hast aber schon dhcp aktiv und keinen festen DNS vergeben?
Einen DHCP dibt es in jedem Standort und ist auch aktiv.
du hast kosten auf die einzelnen WAN Strecken gelegt?
Nein Kosten sind keine mehr festgelegt. Also auf Standard eingestellt.
Mag sein, dass das Kixscript egal ist, aber wenn da Netzwerkdrucker gemappt werden....
Das Skript läuft, wenn es langsam läuft, gleichmäßig langsam ab.
Sobald ich fertig getestet habe, melde ich mich mit den Ergebnissen wieder.
Gruß
Locutus
moin,
ich fass mal zusammen, was ich von der Nummer mitbekommen habe...
Der Netlogonserver iss oll, aber der Regkey den die Kiste braucht um den neuen Standort und damit Logonserver zu finden ist aktuell.
Das Kixscript verbindet Drucker, und beim ersten Mal läufts langsam ab.
Also bei mir hat da von Anfang an was geklingelt - wenn die Karre neu im Standort ist - werden die Drucker samt Treibern installiert.
Läuft die Kiste das zweite mal hoch - gehts schneller - weil die Treiber alle schon aufm Client sind.
So sehe ich das aus meiner Warte mit meinem Wissenstand, den du mir/uns vermittelt hast.
Schau dir das mal an.
Gruß
ich fass mal zusammen, was ich von der Nummer mitbekommen habe...
Der Netlogonserver iss oll, aber der Regkey den die Kiste braucht um den neuen Standort und damit Logonserver zu finden ist aktuell.
Das Kixscript verbindet Drucker, und beim ersten Mal läufts langsam ab.
Also bei mir hat da von Anfang an was geklingelt - wenn die Karre neu im Standort ist - werden die Drucker samt Treibern installiert.
Läuft die Kiste das zweite mal hoch - gehts schneller - weil die Treiber alle schon aufm Client sind.
So sehe ich das aus meiner Warte mit meinem Wissenstand, den du mir/uns vermittelt hast.
Schau dir das mal an.
Gruß
Moin,
die Idee mit den Druckern ist gut. Zum Testen nehme ich die Drucker mal aus dem Skript raus. Daran glauben tue aber nicht... weil:
Wenn ein Client von Standort A nach B und von B wieder nach A wechselt, ist die Laufzeit des Skriptes bei jeden Wechsel von Standort zu Standort länger, ca. 5 Minuten. Nur wenn der Client sich das zweite Mal hintereinander, in einen X beliebigen Standort anmeldet, läuft das Startskript das zweite Mal schnell durch ca. 30 Sekunden. Es ist also, egal ob der Client schon mal in den Standort war, das Startskript braucht bei jeden Wechsel zwischen den Standorten das erste Mal ca. 5 Minuten. Auch wenn der Client schon früher mal am Standort angemeldet war.
Und Drucker sind bei uns auf Hauptgruppen bezogen. Die Hauptgruppen beziehen sich auf einem Standort. Drucker fremder Standorte werden nicht automatisch installiert.
Laut Set Befehl ist nach einem Standortwechsel z. B. von Standort A nach B immer bei der ersten Anmeldung in Standort B der vorige Anmeldeserver von Standort A. Und da das Startskript über den Anmelde-Server geht, läuft das Skript beim ersten Mal über die WAN-Strecke. Deshalb läuft das Skript dann auch länger.
Die reine Geschwindigkeit bei der Anmeldung ist in jeden Standort OK, es betrifft nur die Laufzeit des KIX Skriptes bei Wechsel zwischen den Standorten und über VPN.
Sobald ich fertig getestet habe, melde ich mich mit den Ergebnissen wieder.
Gruß
Locutus
die Idee mit den Druckern ist gut. Zum Testen nehme ich die Drucker mal aus dem Skript raus. Daran glauben tue aber nicht... weil:
Wenn ein Client von Standort A nach B und von B wieder nach A wechselt, ist die Laufzeit des Skriptes bei jeden Wechsel von Standort zu Standort länger, ca. 5 Minuten. Nur wenn der Client sich das zweite Mal hintereinander, in einen X beliebigen Standort anmeldet, läuft das Startskript das zweite Mal schnell durch ca. 30 Sekunden. Es ist also, egal ob der Client schon mal in den Standort war, das Startskript braucht bei jeden Wechsel zwischen den Standorten das erste Mal ca. 5 Minuten. Auch wenn der Client schon früher mal am Standort angemeldet war.
Und Drucker sind bei uns auf Hauptgruppen bezogen. Die Hauptgruppen beziehen sich auf einem Standort. Drucker fremder Standorte werden nicht automatisch installiert.
Laut Set Befehl ist nach einem Standortwechsel z. B. von Standort A nach B immer bei der ersten Anmeldung in Standort B der vorige Anmeldeserver von Standort A. Und da das Startskript über den Anmelde-Server geht, läuft das Skript beim ersten Mal über die WAN-Strecke. Deshalb läuft das Skript dann auch länger.
Die reine Geschwindigkeit bei der Anmeldung ist in jeden Standort OK, es betrifft nur die Laufzeit des KIX Skriptes bei Wechsel zwischen den Standorten und über VPN.
Sobald ich fertig getestet habe, melde ich mich mit den Ergebnissen wieder.
Gruß
Locutus
Salü,
naja -ein Blick in das Kix Script und diese Vermutung könnte bestätigt werden, oder nicht...
Also meine Kixscripte werfen die Drucker - die der User nicht mehr braucht auch in die Tonne......
Und wenn das bei dem auch so ist, dann...?
Egal - teste und berichte
N8
Daran glauben tue aber nicht... weil:
naja -ein Blick in das Kix Script und diese Vermutung könnte bestätigt werden, oder nicht...
Also meine Kixscripte werfen die Drucker - die der User nicht mehr braucht auch in die Tonne......
Und wenn das bei dem auch so ist, dann...?
Egal - teste und berichte
N8
Hallo,
der Test war erfolgreich, auch bei Standortwechsel wird immer der lokale DC benutzt, und dadurch ist die Laufzeit des Startkix Skriptes im normalen Rahmen.
Auf der Notebook_Test OU habe ich folgende GPO´s aktiviert:
Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten
Anmeldeskripts gleichzeitig ausführen.
Leider haben die Änderungen nur wenig Einfluss auf die Geschwindigkeit des Skriptes bei Verbindung über VPN.
Beim letzten Test über VPN hatte ich eine Laufzeit von ca. 30 Minuten. Die Drucker hatte ich aus dem Skript entfernt.
Gruß
Locutus
der Test war erfolgreich, auch bei Standortwechsel wird immer der lokale DC benutzt, und dadurch ist die Laufzeit des Startkix Skriptes im normalen Rahmen.
Auf der Notebook_Test OU habe ich folgende GPO´s aktiviert:
Beim Neustart des Computers und bei der Anmeldung immer auf das Netzwerk warten
Anmeldeskripts gleichzeitig ausführen.
Leider haben die Änderungen nur wenig Einfluss auf die Geschwindigkeit des Skriptes bei Verbindung über VPN.
Beim letzten Test über VPN hatte ich eine Laufzeit von ca. 30 Minuten. Die Drucker hatte ich aus dem Skript entfernt.
Gruß
Locutus
Salie,
Wenn du magst, darfat du gerne das kix script in anton nymisierter, aber nachvollziehbarer form hier zwischen code tags packen.
Ist ein (einmaliges angebot, keine drohung)
Gruss
Wenn du magst, darfat du gerne das kix script in anton nymisierter, aber nachvollziehbarer form hier zwischen code tags packen.
Ist ein (einmaliges angebot, keine drohung)
Gruss
Hallo,
vielen Dank für das Angebot. Das alte Skript reinzustellen macht wenig Sinn. Die Erklärung folgt....
Ich habe mir über das alte Skript Gedanken gemacht und festgestellt das man einiges anders machen könnte.
Z. B. haben wir ca. 20 exclusiver Gruppen in jedem Standort, bedeutet ein User kann nur Mitglied in eine Gruppe sein und dazu auch noch nur in seinem Standort. Bis jetzt ist es so, dass unser Skript in allen Gruppen in jedem Standort sucht, um sein Laufwerksmapping zu machen. Das bedeutet das das Skript bei fünf Standorte ca. 100 Gruppen durchsucht um das Gruppenlaufwerk zu Mappen.
Das ist natürlich Unsinn.
Ich kann ja im Skript abfragen: Gehört der User nach Standort X? Dann suche auch nur in den Hauptgruppen in Standort X, das sind dann nur noch 20 Gruppen, die das Skript durchsuchen muss. Es gibt noch ein paar andere Stellen im Skript die nicht optimal sind. Des Weiteren ist das alte Skript sehr komplex, das brauchen wir gar nicht in dieser Form.
Ich habe angefangen, ein Test Skript zu machen. Das Mapping der Hauptgruppen geht schon deutlich, schneller. Mit den Hauptgruppen und ein paar Fremdzugriffsgruppen ohne Drucker läuft das Test-Skript über VPN knapp eine Minute.
Vielen Dank für eure Hilfe!
Gruß
Locutus
vielen Dank für das Angebot. Das alte Skript reinzustellen macht wenig Sinn. Die Erklärung folgt....
Ich habe mir über das alte Skript Gedanken gemacht und festgestellt das man einiges anders machen könnte.
Z. B. haben wir ca. 20 exclusiver Gruppen in jedem Standort, bedeutet ein User kann nur Mitglied in eine Gruppe sein und dazu auch noch nur in seinem Standort. Bis jetzt ist es so, dass unser Skript in allen Gruppen in jedem Standort sucht, um sein Laufwerksmapping zu machen. Das bedeutet das das Skript bei fünf Standorte ca. 100 Gruppen durchsucht um das Gruppenlaufwerk zu Mappen.
Das ist natürlich Unsinn.
Ich kann ja im Skript abfragen: Gehört der User nach Standort X? Dann suche auch nur in den Hauptgruppen in Standort X, das sind dann nur noch 20 Gruppen, die das Skript durchsuchen muss. Es gibt noch ein paar andere Stellen im Skript die nicht optimal sind. Des Weiteren ist das alte Skript sehr komplex, das brauchen wir gar nicht in dieser Form.
Ich habe angefangen, ein Test Skript zu machen. Das Mapping der Hauptgruppen geht schon deutlich, schneller. Mit den Hauptgruppen und ein paar Fremdzugriffsgruppen ohne Drucker läuft das Test-Skript über VPN knapp eine Minute.
Vielen Dank für eure Hilfe!
Gruß
Locutus
