7
Sehr lange Unlock zeit auf Windows 10 Workstations
Hallo Allerseits, nachdem wir lange nach einer Lösung suchten, komm ich nun zu euch 😀
Bei einigen unserer Workstations / Notebooks kommt es zu sehr langen unlock zeiten, das erste Anmelden ist schnell und ohne probleme, jedoch dann (aber auch nicht immer) wenn die user ihre Workstation sperren und aus der pause zurückkommen, dauert das entsperren bis zu 10 minuten in manchen Fällen.
Nach untersuchung der Eventlogs haben wir folgendes gefunden:
Der Anmeldebenachrichtigungsabonnent <TermSrv> hat 600 Sekunden benötigt, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Der Anmeldebenachrichtigungsabonnent <TermSrv> benötigt einige Zeit, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Es läuft unteranderem ein Logon Script welches wir von den Vorherigen Dienstleistern übernommen haben, jedoch sollte dieses keine Probleme verursachen. Habt ihr irgendwelche ideen?
Grüßt euch
Bei einigen unserer Workstations / Notebooks kommt es zu sehr langen unlock zeiten, das erste Anmelden ist schnell und ohne probleme, jedoch dann (aber auch nicht immer) wenn die user ihre Workstation sperren und aus der pause zurückkommen, dauert das entsperren bis zu 10 minuten in manchen Fällen.
Nach untersuchung der Eventlogs haben wir folgendes gefunden:
Der Anmeldebenachrichtigungsabonnent <TermSrv> hat 600 Sekunden benötigt, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Der Anmeldebenachrichtigungsabonnent <TermSrv> benötigt einige Zeit, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Es läuft unteranderem ein Logon Script welches wir von den Vorherigen Dienstleistern übernommen haben, jedoch sollte dieses keine Probleme verursachen. Habt ihr irgendwelche ideen?
Grüßt euch
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: 12227334754
Url: https://administrator.de/contentid/12227334754
Ausgedruckt am: 23.11.2024 um 09:11 Uhr
7 Kommentare
Neuester Kommentar
Moin,
ich habe ein ähnliches Problem. Bei mir war ein PS-Skript die Ursache, das jedoch beim Logoff nicht zuverlässig funktioniert hat. Das Skript sollte lokale Daten auf das persönliche Laufwerk kopieren. Das Skript an sich funktionierte (keine Fehlermeldung), aber im Skript gab es dann einen Laufzeitfehler, da das Ziel nicht mehr erreichbar war. Der Timeout hierbei liegt bei 900 Sekunden. manchmal ging es, manchmal ging es nicht und die Anwender brauchen 15 Minuten zum Abmelden. Eine Ursache wieso es manchmal und nicht immer auftrat, konnte ich auch nicht finden. Warum ich das schreibe?
Gruß
Doskias
ich habe ein ähnliches Problem. Bei mir war ein PS-Skript die Ursache, das jedoch beim Logoff nicht zuverlässig funktioniert hat. Das Skript sollte lokale Daten auf das persönliche Laufwerk kopieren. Das Skript an sich funktionierte (keine Fehlermeldung), aber im Skript gab es dann einen Laufzeitfehler, da das Ziel nicht mehr erreichbar war. Der Timeout hierbei liegt bei 900 Sekunden. manchmal ging es, manchmal ging es nicht und die Anwender brauchen 15 Minuten zum Abmelden. Eine Ursache wieso es manchmal und nicht immer auftrat, konnte ich auch nicht finden. Warum ich das schreibe?
Zitat von @zoellerg:
Es läuft unteranderem ein Logon Script welches wir von den Vorherigen Dienstleistern übernommen haben, jedoch sollte dieses keine Probleme verursachen.
Wieso? Mein Skript lief auch mehrere Monate problemlos und irgendwann fing das Problem an. Habe MS-Updates in Verdacht, aber keinen Anhaltspunkt gefunden. Nur weil am Skript nichts verändert wurde, kann das Skript dennoch Ursache sein. Ggf. wurde im Hintergrund eine Änderung vorgenommen, so dass ein Pfad im Skript nicht mehr stimmt? Oder entsprechende Berechtigungen auf einen Pfad?Es läuft unteranderem ein Logon Script welches wir von den Vorherigen Dienstleistern übernommen haben, jedoch sollte dieses keine Probleme verursachen.
Nach untersuchung der Eventlogs haben wir folgendes gefunden:
Der Anmeldebenachrichtigungsabonnent <TermSrv> hat 600 Sekunden benötigt, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Der Anmeldebenachrichtigungsabonnent <TermSrv> benötigt einige Zeit, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Was sagen andere Logs? Die Eventlogs sind ja nur ein Log. Was sagen die Systemlogs und Sicherheitslogs zum Beispiel in dem Moment? Ggf. nicht nach Fehler oder Warnung suchen. Die Lösung kann auch in einem Info-Eintrag in einem anderen Protokoll zu finden sein.Der Anmeldebenachrichtigungsabonnent <TermSrv> hat 600 Sekunden benötigt, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Der Anmeldebenachrichtigungsabonnent <TermSrv> benötigt einige Zeit, um dieses Benachrichtigungsereignis (Unlock) zu bearbeiten.
Gruß
Doskias
Moin,
ggfs. läuft ein Script mit dem "Beim Entsperren" Trigger im TaskScheduler? 5 Minuten (600 sec) oder 10 Minuten klingen verdammt nach den harten Timeouts für Scriptausführung (z.b. per GPO o.Ä,)
lg,
Slainte
ggfs. läuft ein Script mit dem "Beim Entsperren" Trigger im TaskScheduler? 5 Minuten (600 sec) oder 10 Minuten klingen verdammt nach den harten Timeouts für Scriptausführung (z.b. per GPO o.Ä,)
lg,
Slainte
Ein logon script lässt sich ja leicht testweise abschalten.
Steht <TermSrv> nur im Eventlog oder reden wir über eine Anmeldung am Terminal Server? Hat der lokale Client Internet Zugriff?
Steht <TermSrv> nur im Eventlog oder reden wir über eine Anmeldung am Terminal Server? Hat der lokale Client Internet Zugriff?
@Doskias
Da werden wir dann morgen nochmal weiter nach schauen
@SlainteMhath
Im Taskscheduler befindet sich auch nicht es handelt sich nur um ein logonscript.
@ukulele-7
TermSrv steht nur im eventlog, wir dachten es könnte damit zusammen hängen, terminal server ist es nicht nein, es ist ein normales windows domain joined notebook
Da werden wir dann morgen nochmal weiter nach schauen
@SlainteMhath
Im Taskscheduler befindet sich auch nicht es handelt sich nur um ein logonscript.
@ukulele-7
TermSrv steht nur im eventlog, wir dachten es könnte damit zusammen hängen, terminal server ist es nicht nein, es ist ein normales windows domain joined notebook
Hallo,
Und welches Problem und welche Lösung habt ihr gefunden?
Gruss,
Peter
Und welches Problem und welche Lösung habt ihr gefunden?
Gruss,
Peter
