Nach Fall Creators Update 1709 kein Login mehr möglich

[EH]Keeper

Lieutenant
Registriert
Aug. 2001
Beiträge
620
Hi,

großes Problem mit Windows 10 - mal wieder.
Habe mehrere Intel NUC Rechner, auf Windows 10 Basis im Einsatz - an verschiedenen Standorten.
Konfiguriert sind diese so, dass sich ein Standardbenutzer immer beim booten automatisch anmeldet - ohne PWD-Eingabe.
Einige dieser PCs haben am Dienstag Abend das Fall Creators Update 1709 "erhalten" (ohne Abfrage).
Nach einem Neustart am nächsten Morgen können sich diese NUCs nun nicht mehr automatisch anmelden.
Eine manuelle Anmeldung ist auch nicht mehr möglich. Man wird immer wieder sofort in die Windows Login Maske zurückgeleitet.

Nur noch der Admin kann sich anmelden und Einstellungen vornehmen, als wäre Win10 frisch installiert worden. Diese Einstellungen lösen aber aber das Problem nicht.

Auch läuft seit dem FCU1709 der Lüfter des Intel NUCs nur noch auf Vollgas.

hat jemand eine Idee?
 
thx für die schnelle Antwort.
Leider funktioniert dieser Trick nicht.
Es sieht so aus, als würde die Sitzung des Benutzers noch im Hintergrund "hängen".
Als Admin angemeldet sehe ich, dass der Benutzer bereits angemeldet ist. Ich habe aber keine Möglichkeit (gefunden), den Benutzer zu trennen, um eine Neuanmeldung zu versuchen.
 
Hast du den PC schonmal "Neugestartet" ? Nicht "Herunterfahren" und wieder einschalten, da ist ein großer Unterschied bei W10. Hatte oft Probleme nach Upgrades mit dem Benutzerprofildienst. Nach Neustart oder spätestens nach einem "chkdsk /r /f" von einem Windows Boot Stick waren die Fehler weg!
 
Neustart und Herunterfahren probiert. Bringt leider auch keine Besserung. Hab sogar mal den Stecker im laufenden Betrieb gezogen - ohne Erfolg (außer ca. 10sek. Stromersparnis *G*)

Sobald ich den Benutzer anklicke, fliege ich wieder raus in die Login Maske. Habe allerdings jetzt beobachten können, dass für ca. 0.00005 sek ;) das Wörtchen "Sperren" erscheint, bevor ich wieder rausfliege.
Scheint also, als würde Win10 den Benutzer sofort nach Anmeldung sperren.
Habe dem Benutzer jetzt auch mal Adminrechte verpasst. Brachte aber auch nix.
 
Ich nehme mal an, das Ganze wurde über die Registry eingestellt?
Ich würde mal die Einstellungen unter
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
zurücksetzen. Also die Einträge AutoAdminLogon, DefaultDomainName und DefaultUserName und DefaultPassword löschen.

Desweiteren mal die Windows Logs prüfen.
Um es einfach zu machen, hier eine PowerShell-Funktion von mir:
https://www.computerbase.de/forum/t...r-die-eventlog-ausgabe.1734277/#post-20749259

Einfach PowerShell ISE öffnen, den Code reinkopieren und ganz unten dann Folgendes anfügen (und kurz warten; kann ein bisschen dauern):
Get-EventLog2 -Levels (L1_Critical , L2_Error) | Ogv

Wenn das nichts hilfreiches ausspuckt, dann noch die Warnings miteinbinden:
Get-EventLog2 -Levels (L1_Critical , L2_Error , L3_Warning) | Ogv
 
Hi,

jop, die Kekse von Microsoft haben da wohl beim FCU1709 still und heimlich das Autologin in der Registry deaktiviert.
unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" muss der Schlüssel "DisableLockWorkstation" auf "1" gesetzt werden. Dann gehts wieder.
 
[EH]Keeper schrieb:
Hi,

jop, die Kekse von Microsoft haben da wohl beim FCU1709 still und heimlich das Autologin in der Registry deaktiviert.
unter "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" muss der Schlüssel "DisableLockWorkstation" auf "1" gesetzt werden. Dann gehts wieder.

Das hört sich für mich aber nicht nach "der Lösung" an.
Dieser Key setzt ja die Möglichkeit der Computer/Benutzer-Sperre (via Start-Menü oder [Win]+[L]) außer Kraft.
Zwar gut, dass du den Ursprung des Problems gefunden hast und aktuell einen "Workaround" hast, aber das kann nicht die Lösung sein.
Nun hast du aber einen Ansatzpunkt. Prüfe doch bitte mal sämtliche Lock-Einstellungen!
  1. Welche Domain-Policies sind aktiv (Computer & Benutzer) ? (GPRESULT)
  2. Welche lokalen Policies sind aktiv? (Computer & Benutzer)? (GPRESULT)
  3. Welche lokalen Registry-Modifikationen wurden vorgenomen?
  4. Welche Einstellungen in den Energieeinstellungen?
  5. ...
 
Zuletzt bearbeitet:
Zurück
Oben