[English]Ein Blog-Leser hat mich vor einigen Tagen per Mail auf ein Problem bei der Domänenanmeldung unter Windows 10 V1809 aufmerksam gemacht. Er bekam nach der Migration von Windows 7-Clients auf Windows 10 V1809 bei der Domänenanmeldung die Meldung, dass der Benutzerprofildienst nicht geladen werden konnte.
Anzeige
Das Fehlerbild
Blog-Leser Holger K. schrieb mir dazu, dass er bei einem Kunden Probleme nach der Umstellung von Windows 7 auf Windows 10 1809 Probleme bei der Anmeldung (Domain-Login, DC mit Windows 2016) hatte. Auf den Clients wurde die Meldung: "Fehler bei der Anmeldung mit dem Benutzerprofildienst. Das Benutzerprofil kann nicht geladen werden" angezeigt. Dieser Fehler kam bei diesem Benutzer nach Überprüfung auf allen Rechnern mit Windows 10 1809.
Die Lösung
Bei der Suche nach der Ursache stieß Blog-Leser Holger dann auf diesen Technet-Forenbeitrag. Dort beschreibt ein Benutzer das Szenario, was auch bei Holger zutrat:
Some domain users get "user profile service failed" when trying to login after October Windows update
Some of my domain users can't logon on any upgraded Win10 pro machine, whilst other users can logon to the upgraded machine fine. they see the error – windows couldn't connect to the user profile service service.
There accounts can also not logon to other upgraded machines – they see the same error on other machines too.
The 'fix' seem to be rebuild their machine then stop the update happening – but what is the rel cause and proper fix?
i also on one occasion on one machine saw windows couldn't connect to the System Event notification Service service
Ein Nutzer bestätigte das Problem in Windows 10 V1809 und hat seine Clients auf die Version 1803 zurück gerollt. Dieser Nutzer Gov PC Guy schlug auch eine Lösung als Workaround vor:
found something, clearing the home drive path on the active directory user object. It allowed me to login. I then home drive mapping back on the object (it complains that the directory already exists, but I said ok) logged user off and back on again and it seems fine.
Blog-Leser Holger schreibt dazu: Der USer "Gov PC Guy" hat im AD den Profileintrag vom Serverlaufwerk auf Lokal und sofort wieder zurück gesetzt. Dabei wird man darauf hingewiesen, daß das Verzeichnis schon existiert, danach wird abgefragt, ob dem User Vollzugriff auf den Profilpfad gewährt werden soll. Wenn man das auch bestätigt, wird der Profilpfad wieder eingetragen.
Danach kann sich der Benutzer, laut Blog-Leser Holger, auch wieder an jedem Win10 1809 Client anmelden. Beim Vergleich was jetzt an diesem und einem andern Benutzerprofil unterschiedlich ist, ist Holger aufgefallen, dass die anderen Benutzerprofile keinen "Vollzugriff" für den User eingetragen haben. Der wieder neu zugewiesene Benutzer besitzt diesen Vollzugriff dagegen schon.
Holger vermutet, dass Windows 10 neue Einträge schreiben will, die es bisher nicht gab. Warum der DC dies inzwischen anders macht ist dem Blog-Leser unbekannt, da er die Historie bei diesem Kunden nicht kennt. Möglicherweise wurde der Domain Controller (DC) in der Vergangenheit migriert. Möglicherweise liegt ein Erklärungsansatz im Blog-Beitrag Windows 10 V1803: Roaming-Profil nicht voll synchronisiert – kann ich aber nicht beurteilen. Holger meint: Es ist davon auszugehen, dass dieses Problem in der nächsten Zeit gehäuft auftreten wird. An dieser Stelle danke für die Information, vielleicht hilft die Info ja anderen.
Ähnliche Artikel:
Windows 10 V1809: Ständige Warnungen (Event ID 1534)
Anmeldung scheitert wegen defektem Benutzerprofil
Windows Server 2016: Terminalserver-Anmeldung scheitert
Windows: Bugs/Ungereimtheiten im Dateisystem
Windows 10 V1607: Update KB4467684 killt Outlook-Suche in Terminal Server
Windows 10 V1803: Roaming-Profil nicht voll synchronisiert
2015
Zuerst dachte ich: wer geht von Windows 7 per Upgrate auf Windows 10, aber das Problem passt ja auch von Windows 10 1803 auf 1809.
Na super, mal wieder ein Show stopper.
Fraglich ist wie man aus diesem Dilemma wieder rauskommt: das Updgrate auf Windows 10 1809 verfolgt ja immer auf eine bestimmte Build, erst dann werden Updates installiert (die dann irgendwann hoffentlich einen Fix bringen). Heißt nach dem Upgrate müssen vor Verwendung erst alle Updates installiert werden, dass die Maschinen wieder nutzbar sind.
Das scheint aber tatsächlich nur Roaming-Profiles zu betreffen, wo der Client auf v1809 upgraded worden ist. Wir haben hier weder Roaming Profiles noch ein Upgrade gemacht und mit LTSC 2019 keinerlei Probleme diesbezüglich. Bei einem Kunden, die Roaming Profiles nutzen, sind die v1809-Installationen neu aufgesetzt worden und auch hier keine Probleme. Aber gut zu wissen, einige Rechner sind noch auf v1803 und Windows 7. Zumindest bei den v1803 Versionen wollte ich eigt. ein Upgrade durchführen. Die Win7-Installationen werden wohl eh neu aufgesetzt.
Ich hatte das Problem bei der zurückgezogenen 1809 Version auch. Allerdings war es mein Testrechner, den ich anschließend einfach mit dem freigegebenem 1809 neu installiert habe. Auf mittlerweile 20 1809 Maschinen ist das Problem nicht mehr aufgetreten. Mit dem User war auch alles OK. Keine Roaming Profiles btw.
wir hatten das Problem sogar vermehrt mit Windows 10 1803
lange Ursachenrecherche ohne Lösung
-> am Ende hat ein deaktivieren des Schnellstarts in Windows 10 (in den Energieeinstellungen) das Problem auf allen Clients behoben
Versuche mich seit drei Wochen an dem Problem, habe alle in die Richtung gehenden Ratschläge abgearbeitet. Rollback auf 1803 und Update/Upgrade verhindern ist nur kurzfristige Lösung. Haben Domänen mit roaming profiles und Server 2012R2. Das Problem tritt auf bei Upgrade von 1803 auf 1809, auch bei neuinstallierten 1809 und auch bei komplett neu aufgesetzter Domäne mit Server 2019 und 1809 (nichts anderes als Windows drauf). Sowohl bei alten Accounts/Profilen als auch bei neu angelegten.
Manchmal funtioniert die Anmeldung bei einzelnen Accounts noch, aber sobald es bei dem ersten schiefgeht mit "Windows konnte keine Verbindung mit dem Dienst Benutzerprofildienst" herstellen…" können sich auch die, bei denen es gerade noch funtioniert hatte, nicht mehr einloggen, Meldung: "Fehler bei der Anmeldung des Diensts "Gruppenrichtlinienclient". Zugriff verweigert."
Aus dem Ereignisprotokoll "Anwendung" bei fehlgeschlagenem login:
Fehler:
Name der fehlerhaften Anwendung: svchost.exe_ProfSvc, Version: 10.0.17763.1,
Name des fehlerhaften Moduls: profsvc.dll, Version: 10.0.17763.107
Pfad der fehlerhaften Anwendung: C:\Windows\system32\svchost.exe
Pfad des fehlerhaften Moduls: c:\windows\system32\profsvc.dll
Warnung:
* Der Winlogon-Benachrichtigungsabonnent war nicht verfügbar, um das kritische Benachrichtigungsereignis zu verarbeiten.
* Der Winlogon-Benachrichtigungsabonnent ist bei einem kritischen * Benachrichtigungsereignis fehlgeschlagen.
* Der Dienst "Benutzerprofildienst" wurde unerwartet beendet
* Der Winlogon-Benachrichtigungsabonnent ist bei einem kritischen Benachrichtigungsereignis fehlgeschlagen.
Machmal auch zusätzlich :
Name der fehlerhaften Anwendung: explorer.exe, Version: 10.0.17763.107,
Name des fehlerhaften Moduls: ucrtbase.dll
und
Name der fehlerhaften Anwendung: ctfmon.exe, Version: 10.0.17763.1,
Name des fehlerhaften Moduls: InputLocaleManager.dll
oder
Name der fehlerhaften Anwendung: sihost.exe, Version: 10.0.17763.1
Name des fehlerhaften Moduls: Windows.Shell.ServiceHostBuilder.dll
Die Meldungen kommen auf allen 1809-Rechnern, das Hauptproblem scheint die svchost.exe_ProfSvc – Geschichte zu sein.
Hm, merkwürdig. Eben nochmal bei dem Kunden geguckt. Der nutzt ebenfalls Win2k12R2 und Roaming Profiles und die 2 Clients mit v1809 funktionieren problemlos. Wir hatten damals das Problem mit v1803 und dem fehlenden ExcludeProfileDirs-Eintrag in der Registry. Aber das ist mittlerweile ja behoben.
Ich muss aber noch hinzufügen, dass die beiden v1809-Clients bisher immer von denselben Außenmitarbeitern genutzt werden, sprich die beiden Nutzer melden sich z.Z. nur an diesen Rechnern an. Eventuell tritt das Problem erst zutage, wenn die Nutzer dann tasächlich mit ihren Profilen "roamen". Jedenfalls sind die Berechtigungen des Nutzer.V6-Profilordners vollkommen korrekt und die Nutzerkonten haben auch Vollzugriff auf ihren eigenen Profilordner.
Ersteller-Besitzer ist im Profil-Oberordner richtig hinterlegt (Vollzugriff: Nur Unterordner und Dateien)?
Ich hab außerdem noch diese GPO an:
Computerrichtlinien\Richtlinien\Administrative Vorlagen\System\Benutzerprofile\"Sicherheitsgruppe Administratoren zu servergespeicherten Profilen hinzufügen". Weiß aber nicht, inwieweit diese relevant ist. Ansonsten fällt mir jetzt auch erstmal nichts ein.
An den Profilen liegt es nicht.
Ein heute ausprobierter "dreckiger" workaround für PC, auf denen sich das Upgrade nicht verhindern ließ, ist: den PC über USB-Stick mit einem Notfallwindows starten und die svchost.exe und die profsvc.dll auf dem 1809er mit den Dateien von einem funtionierenden 1803er zu ersetzen. Die oben erwähnten Fehlermeldungen tauchen nicht mehr auf.
(Lediglich: Name der fehlerhaften Anwendung: ShellExperienceHost.exe,
Name des fehlerhaften Moduls: StartUI.dll, das stört aber bislang nicht)
Alle ausprobierten DomänenAccounts mit Roaming Profiles laden wieder und werden auch wieder zurückgespeichert.
Das möchte ich nicht auf den anderen 150 PC machen. Vielleicht wird ja mit dem Frühjahrsupgrade alles wieder gut? Hallo MS!