10
Langsamer Start und Anmeldung Domänenangebundener Rechner über VPN - was tun?
Hallo allerseits,
ich habe das Problem, dass einige unserer PCs in Außenstandorten mit relativ langsamer Internetverbindung endlos lange beim Rechnerstart und anschließender Anmeldung hängen.
Die Außenstandorte sind per VPN an die Zentrale angebunden, die PCs authentifizieren sich am zentralen DC (ein separater DC am Außenstandort mach keinen Sinn bei 1-2 Rechnern). Leider sind auch die Internet-Bandbreiten unterirdisch (1Mbit - 3Mbit ADSL) und keine bessere Leitung in Aussicht (zu bezahlbaren Preisen!).
Beim Start werden lediglich einige Computer-GPOs gezogen, bei der Anmeldung noch einige Benutzer-GPOs, außerdem wird das Anmeldescript (Kix) abgearbeitet (in Zeitlupe). Es gibt keine servergespeicherten Profile, die hier reinfunken könnten.
In einigen anderen Außenstellen mit besserer Internetanbindung (ab 3Mbit Down-/512kbit Upstream) laufen Rechnerstart und Anmeldung erträglich schnell.
Könnte die Erhöhung des Upstreams auf 512kbit hier etwas bringen? Bei 1Mbit Downstream ist im Upstream tatsächlich bei 128kbit Schluss.
Wie macht Ihr das wenn Ihr Systeme über Verbindungen mit geringer Bandbreite anbindet? Die Systeme von der Domänenanbindung zu "befreien" halte ich für inakzeptabel.
Bin mal gespannt...
Gruß mhard666
ich habe das Problem, dass einige unserer PCs in Außenstandorten mit relativ langsamer Internetverbindung endlos lange beim Rechnerstart und anschließender Anmeldung hängen.
Die Außenstandorte sind per VPN an die Zentrale angebunden, die PCs authentifizieren sich am zentralen DC (ein separater DC am Außenstandort mach keinen Sinn bei 1-2 Rechnern). Leider sind auch die Internet-Bandbreiten unterirdisch (1Mbit - 3Mbit ADSL) und keine bessere Leitung in Aussicht (zu bezahlbaren Preisen!).
Beim Start werden lediglich einige Computer-GPOs gezogen, bei der Anmeldung noch einige Benutzer-GPOs, außerdem wird das Anmeldescript (Kix) abgearbeitet (in Zeitlupe). Es gibt keine servergespeicherten Profile, die hier reinfunken könnten.
In einigen anderen Außenstellen mit besserer Internetanbindung (ab 3Mbit Down-/512kbit Upstream) laufen Rechnerstart und Anmeldung erträglich schnell.
Könnte die Erhöhung des Upstreams auf 512kbit hier etwas bringen? Bei 1Mbit Downstream ist im Upstream tatsächlich bei 128kbit Schluss.
Wie macht Ihr das wenn Ihr Systeme über Verbindungen mit geringer Bandbreite anbindet? Die Systeme von der Domänenanbindung zu "befreien" halte ich für inakzeptabel.
Bin mal gespannt...
Gruß mhard666
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 272328
Url: https://administrator.de/contentid/272328
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
10 Kommentare
Neuester Kommentar
Hi,
man müsste jetzt wissen, was für "lediglich einige Computer-GPOs" und "einige Benutzer-GPOs" sind. Ebenso in etwa, was das Kix-Script macht.
Und wie wird das Script ausgeführt? Als Benutzer-Loginscript (standardmäßig synchrone Ausführung) oder als GPO-Anmeldescript (standardmäßig asynchrone Ausführung).
Sollten da Software-Installationen bei sein, wie etwa AntiVirus-Update u.ä., dann muss man das ändern.
Werden Drucker verbunden? Falls ja, wie schnell geht es, wenn Du das mal raus nimmst?
Gleiches für Netzlaufwerke?
Ordnerumleitungen? (Über WAN nicht zu empfehlen)
U.U. kann es helfen, die Scripte lokal abzulegen und von dort zustarten. Überhaupt: Die Kix-EXE liegt aber nicht im Netlogon? Falls doch, dann lokal ablegen und von dort starten.
Muss es Kix sein? Schon mal mit Bordmitteln versucht? VBscript oder Powershell? Vielleicht reicht ja auch ein einfaches CMD? Wie gesagt, man müsste wissen, was das Script macht.
Schon mal über Terminalserver nachgedacht?
E.
man müsste jetzt wissen, was für "lediglich einige Computer-GPOs" und "einige Benutzer-GPOs" sind. Ebenso in etwa, was das Kix-Script macht.
Und wie wird das Script ausgeführt? Als Benutzer-Loginscript (standardmäßig synchrone Ausführung) oder als GPO-Anmeldescript (standardmäßig asynchrone Ausführung).
Sollten da Software-Installationen bei sein, wie etwa AntiVirus-Update u.ä., dann muss man das ändern.
Werden Drucker verbunden? Falls ja, wie schnell geht es, wenn Du das mal raus nimmst?
Gleiches für Netzlaufwerke?
Ordnerumleitungen? (Über WAN nicht zu empfehlen)
U.U. kann es helfen, die Scripte lokal abzulegen und von dort zustarten. Überhaupt: Die Kix-EXE liegt aber nicht im Netlogon? Falls doch, dann lokal ablegen und von dort starten.
Muss es Kix sein? Schon mal mit Bordmitteln versucht? VBscript oder Powershell? Vielleicht reicht ja auch ein einfaches CMD? Wie gesagt, man müsste wissen, was das Script macht.
Schon mal über Terminalserver nachgedacht?
E.
Hallo;
die Hinweise von @emeriks kann ich nur unterstützen.
Zu seiner letzten Bemerkung bezüglich Terminal-Server noch eine praktische Erfahrung:
Vor ca. 10 Jahren hatte ich eine ähnliche Konstellation. Die Standort-Vernetzung wurde aber noch mit einer ISDN-Standleitung der Telekom realisiert. Bei 64k Bandbreite konnten 2-3 WinXP-Clients pro Standort problemlos auf einen 2003er Terminal-Server zugreifen. (Eine Terminal-Session braucht etwa 20-25k Bandbreite)
Durch den Terminal-Betrieb konnte ich mir nicht nur die Server-Replikation in der Nacht sparen, auch der Zugriff auf den File-Server war schnell, da die Dateien ja nicht durch das WAN mußten.
Vom Vorteil der zentralen Administration mal ganz abgesehen.
Jürgen
die Hinweise von @emeriks kann ich nur unterstützen.
Zu seiner letzten Bemerkung bezüglich Terminal-Server noch eine praktische Erfahrung:
Vor ca. 10 Jahren hatte ich eine ähnliche Konstellation. Die Standort-Vernetzung wurde aber noch mit einer ISDN-Standleitung der Telekom realisiert. Bei 64k Bandbreite konnten 2-3 WinXP-Clients pro Standort problemlos auf einen 2003er Terminal-Server zugreifen. (Eine Terminal-Session braucht etwa 20-25k Bandbreite)
Durch den Terminal-Betrieb konnte ich mir nicht nur die Server-Replikation in der Nacht sparen, auch der Zugriff auf den File-Server war schnell, da die Dateien ja nicht durch das WAN mußten.
Vom Vorteil der zentralen Administration mal ganz abgesehen.
Jürgen
man müsste jetzt wissen, was für "lediglich einige Computer-GPOs" und "einige Benutzer-GPOs" sind.
Die Computer GPOs regeln nur so Sachen wie PasswortSicherheitseinstellungen, Energieverwaltungsoptionen, Windowsupdates, Firewalleinstellungen, Installation des Exchange-Zertifikats.
Die Benutzer-GPOs schalten das ActionCenter ab und regeln ein paar IE-Sicherheitseinstellungen fürs Intranet.
Dazu kommt noch die Default Domain Policy, die im Wesentlichen original, sprich unangetastet ist.
Ebenso in etwa, was das Kix-Script macht.
Im Wesentlichen werden hier nur das Desktop-Verzeichnis des Benutzers ermittelt und Verknüpfungen für Office, Intranet, TeamViewer erstellt. Das Script ist aber für alle User und legt gruppenbezogen Links auf den Desktop und mapt Netzwerkfreigaben... Insgesamt sind es gut 1600 Zeilen.
Und wie wird das Script ausgeführt? Als Benutzer-Loginscript (standardmäßig synchrone Ausführung) oder als
GPO-Anmeldescript (standardmäßig asynchrone Ausführung).
GPO-Anmeldescript (standardmäßig asynchrone Ausführung).
Als Userlogonscript.
Sollten da Software-Installationen bei sein, wie etwa AntiVirus-Update u.ä., dann muss man das ändern.
Werden Drucker verbunden? Falls ja, wie schnell geht es, wenn Du das mal raus nimmst?
Gleiches für Netzlaufwerke?
Ordnerumleitungen? (Über WAN nicht zu empfehlen)
Werden Drucker verbunden? Falls ja, wie schnell geht es, wenn Du das mal raus nimmst?
Gleiches für Netzlaufwerke?
Ordnerumleitungen? (Über WAN nicht zu empfehlen)
Nö, alles nicht (zumindest nicht in den betroffenen Standorten).
U.U. kann es helfen, die Scripte lokal abzulegen und von dort zustarten. Überhaupt: Die Kix-EXE liegt aber nicht im Netlogon?
Falls doch, dann lokal ablegen und von dort starten.
Falls doch, dann lokal ablegen und von dort starten.
Die Kix.exe wird in der vorgelagerten Batch-Datei auf dem lokalen Rechner gesucht und wenn vorhanden von dort gestartet. Wenn nicht vorhanden wird versucht sie zu kopieren und dann zu starten und nur wenn das fehlschlägt wird sie vom Netlogon ausgeführt.
Muss es Kix sein? Schon mal mit Bordmitteln versucht? VBscript oder Powershell? Vielleicht reicht ja auch ein einfaches CMD? Wie
gesagt, man müsste wissen, was das Script macht.
gesagt, man müsste wissen, was das Script macht.
Schon drüber nachgedacht, ja. Powershell ist absolutes Neuland für mich, sicher interessant, aber bis ich das Script umgeschrieben hätte...
VBScript wäre eine Option, ein Teil des Scriptes ist eh schon gekapseltes vbs. Allerdings hat Kix für einen Großteil der Funktionalitäten schon fertige Befehle... Hinsichtlich der Komplexität des Ganzen trage ich mich aber schon ne Weile mit diesem Gedanken.
Schon mal über Terminalserver nachgedacht?
Ja, aber wenn man keinen Thin-Client hinstellen kann/will/darf hat man nun mal einen Windows-PC dort stehen, mittlerweile mindestens mit Win 7.
Gearbeitet wird übrigens schon auf WTS. Im konkreten Fall handelt es sich um eine Kita. Die Fotografieren den ganzen Tag
(für die Entwicklungsdokumentation der Kinder) und wollen dann die Bilder bearbeiten, drucken und/oder entwickeln lassen... Das geht nicht wirklich über WTS, auf keinem Fall bei der Internet-Anbindung.VG mhard666
Moin,
?
LG von Bornholm, Thomas
Ja, aber wenn man keinen Thin-Client hinstellen kann/will/darf hat man nun mal einen Windows-PC dort stehen
was hat das mit der Nutzung eines RDS-Servers zu tun ?LG von Bornholm, Thomas
Als Userlogonscript.
Also direkt am Benutzerobjekt eingetragen?Falls ja: Das könnte die Ursache sein. Diese Scripte werden im Vordergrund synchron angeführt. Hängt das Script (oder benötigt sehr lange), dann hängt der Anmeldeprozess. Alternative: GPO-Anmeldescript. Diese laufen parallel zum Aufbau des Desktops.
E.
N'Abend,
Nix. Aber ich habe halt wieder einen Windows-PC mit allem schipp und schnapp. Und die besagten Dinge (stehen genau unter der von Dir zitierten Zeile) lassen eine ausschließliche Nutzung via RDS nicht zu. Und wir nutzen ja RDS (steht auch genau unter der von Dir zitierten Zeile)
Mit nem ThinClient könnte man einen Haufen Traffic sparen, der halt nur für die Verwaltung der Windows-Kiste in der Domäne drauf geht. Wenn ein ThinClient aber keine Option ist, dann muss ich sehen, dass ich diesen Traffic minimieren kann. RDS (oder Citrix) ändert daran (leider) erst einmal nichts.
Gruß mhard666.
Zitat von @keine-ahnung:
Moin,
> Ja, aber wenn man keinen Thin-Client hinstellen kann/will/darf hat man nun mal einen Windows-PC dort stehen
was hat das mit der Nutzung eines RDS-Servers zu tun?
Moin,
> Ja, aber wenn man keinen Thin-Client hinstellen kann/will/darf hat man nun mal einen Windows-PC dort stehen
was hat das mit der Nutzung eines RDS-Servers zu tun
?Nix. Aber ich habe halt wieder einen Windows-PC mit allem schipp und schnapp. Und die besagten Dinge (stehen genau unter der von Dir zitierten Zeile) lassen eine ausschließliche Nutzung via RDS nicht zu. Und wir nutzen ja RDS (steht auch genau unter der von Dir zitierten Zeile)
Mit nem ThinClient könnte man einen Haufen Traffic sparen, der halt nur für die Verwaltung der Windows-Kiste in der Domäne drauf geht. Wenn ein ThinClient aber keine Option ist, dann muss ich sehen, dass ich diesen Traffic minimieren kann. RDS (oder Citrix) ändert daran (leider) erst einmal nichts.
Gruß mhard666.
Guten Abend zusammen,
Was sagt die Ereignisnazeige auf dem Client in der Außenstelle (Warnungen, Fehler o.ä.)? DNS-Probleme kann solche Verzögerungen auch hervorrufen. Wenn z.B. auf dem Router/Firewall in der Außenstelle falsch konfiguriert ist.
Gruß,
Dani
Könnte die Erhöhung des Upstreams auf 512kbit hier etwas bringen?
Wie ist den die Leitungsauslastung (Down/Upload) an der betroffenen Außenstelle als auch am Hauptstandort zum entsprechenden Zeitpunkt.Das Script ist aber für alle User und legt gruppenbezogen Links auf den Desktop und mapt Netzwerkfreigaben... Insgesamt sind es gut 1600 Zeilen.
Wie lange die Verarbeitung wenn du das Skript manuell auf dem Client startest? Vllt. kannst du beim Start die Uhrzeit ausgeben und am Ende nochmals.Was sagt die Ereignisnazeige auf dem Client in der Außenstelle (Warnungen, Fehler o.ä.)? DNS-Probleme kann solche Verzögerungen auch hervorrufen. Wenn z.B. auf dem Router/Firewall in der Außenstelle falsch konfiguriert ist.
Gruß,
Dani
> Als Userlogonscript.
Also direkt am Benutzerobjekt eingetragen?
Falls ja: Das könnte die Ursache sein. Diese Scripte werden im Vordergrund synchron angeführt. Hängt das Script
(oder benötigt sehr lange), dann hängt der Anmeldeprozess. Alternative: GPO-Anmeldescript. Diese laufen parallel zum
Aufbau des Desktops.
Also direkt am Benutzerobjekt eingetragen?
Falls ja: Das könnte die Ursache sein. Diese Scripte werden im Vordergrund synchron angeführt. Hängt das Script
(oder benötigt sehr lange), dann hängt der Anmeldeprozess. Alternative: GPO-Anmeldescript. Diese laufen parallel zum
Aufbau des Desktops.
Jupp. Anmeldescript im Benutzerobjekt.
Das Anmeldescript ist leider nur die halbe Miete. Bis sich der User überhaupt anmelden kann, dauert es schon gefühlte Ewigkeiten.
Gruß mhard666
> Könnte die Erhöhung des Upstreams auf 512kbit hier etwas bringen?
Wie ist den die Leitungsauslastung (Down/Upload) an der betroffenen Außenstelle als auch am Hauptstandort zum entsprechenden
Zeitpunkt.
Wie ist den die Leitungsauslastung (Down/Upload) an der betroffenen Außenstelle als auch am Hauptstandort zum entsprechenden
Zeitpunkt.
Am Hauptstandort ist die Auslastung unwesentlich, sprich gering. In der Außenstelle... nee, kann ich nicht sagen, weil nicht verfolgt beim Test. Da müsste ich noch mal drüberschauen.
> Das Script ist aber für alle User und legt gruppenbezogen Links auf den Desktop und mapt Netzwerkfreigaben... Insgesamt
sind es gut 1600 Zeilen.
Wie lange die Verarbeitung wenn du das Skript manuell auf dem Client startest? Vllt. kannst du beim Start die Uhrzeit ausgeben und
am Ende nochmals.
sind es gut 1600 Zeilen.
Wie lange die Verarbeitung wenn du das Skript manuell auf dem Client startest? Vllt. kannst du beim Start die Uhrzeit ausgeben und
am Ende nochmals.
Mach ich mal. Also Zeit loggen und manuell starten.
Was sagt die Ereignisnazeige auf dem Client in der Außenstelle (Warnungen, Fehler o.ä.)? DNS-Probleme kann solche
Verzögerungen auch hervorrufen. Wenn z.B. auf dem Router/Firewall in der Außenstelle falsch konfiguriert ist.
Verzögerungen auch hervorrufen. Wenn z.B. auf dem Router/Firewall in der Außenstelle falsch konfiguriert ist.
Muss ich auch schauen, mit der Inbetriebnahme des Routers in einer Außenstelle gab es in der Tat anfänglich Probleme.
Gruß mhard666
Hallo,
fragen wir doch mal anders herum: Was wird denn in bzw. über die Domäne abgewickelt?
Datentransfer auf einen zentralen File-Server kann es ja nicht sein, das wäre dann ja auch ars...langsam.
Werden die Entwicklungsdokumentationen lokal oder auf einem Server (über das WAN) gespeichert?
Wie sind denn die lokalen Drucker angebunden (lokaler Drucker am PC, Netzwerkdrucker im lokalen LAN oder Domänen-Drucker)?
Wenn die Dokumentationen ausschließlich lokal bearbeitet werden, kann man für die "Netzwerkdienste" (Mail, Datenbank, usw.) doch auf dem "normalen" Windows-PC eine Terminal-Session aufmachen. Der Zugriff auf lokale Ressourcen (lokaler Drucker, lokale Festplatte, lokale SD-Karte oder USB-Stick) aus der Session ist heute ja kein Problem mehr.
Jürgen
fragen wir doch mal anders herum: Was wird denn in bzw. über die Domäne abgewickelt?
Datentransfer auf einen zentralen File-Server kann es ja nicht sein, das wäre dann ja auch ars...langsam.
Werden die Entwicklungsdokumentationen lokal oder auf einem Server (über das WAN) gespeichert?
Wie sind denn die lokalen Drucker angebunden (lokaler Drucker am PC, Netzwerkdrucker im lokalen LAN oder Domänen-Drucker)?
Wenn die Dokumentationen ausschließlich lokal bearbeitet werden, kann man für die "Netzwerkdienste" (Mail, Datenbank, usw.) doch auf dem "normalen" Windows-PC eine Terminal-Session aufmachen. Der Zugriff auf lokale Ressourcen (lokaler Drucker, lokale Festplatte, lokale SD-Karte oder USB-Stick) aus der Session ist heute ja kein Problem mehr.
Jürgen
