16
Nach Kennwortänderung - Warten auf Benutzerprofildienst
Guten Tag,
wir haben seit einigen Wochen ein Problem bei uns und ich finde den Fehler einfach nicht.
Wir setzen eine AD auf einem Server 2008 R2 und Clients von Win7 bis Win10 ein.
Wenn bei uns ein User sein Kennwort an seinem Rechner ändert, kann er sich an diesem Rechner ganz normal danach mit dem neuen Kennwort anmelden.
Versucht sich der Benutzer an einem anderen Rechner, an dem er mit seinem alten Kennwort schon mal angemeldet war, mit seinem Kennwort an, bleibt der Rechner beim Laden des Benutzerprofils mit der Meldung "Warten auf Benutzerprofildienst" stehen. Haben Rechner auch schon über Nacht laufen lassen, aber selbst dann fängt sich die Anmeldung nicht mehr. Auch mehrmaliges Anmelden bringt dann nichts mehr, es passiert immer das selbe.
Wenn ich im AD den Haken "Kennwort muss geändert werden" setze, bekommt der Benutzer bei der Anmeldung die Aufforderung zur Änderung und es funktioniert danach alles wie gewünscht.
In der Ereignisanzeige und im AD finde ich hierzu keine Fehler.
Der Fehler tritt übrigens auch auf, wenn das Kennwort in der AD direkt wurde.
Wisst ihr Rat hierbei?
Danke im Voraus.
Andy
wir haben seit einigen Wochen ein Problem bei uns und ich finde den Fehler einfach nicht.
Wir setzen eine AD auf einem Server 2008 R2 und Clients von Win7 bis Win10 ein.
Wenn bei uns ein User sein Kennwort an seinem Rechner ändert, kann er sich an diesem Rechner ganz normal danach mit dem neuen Kennwort anmelden.
Versucht sich der Benutzer an einem anderen Rechner, an dem er mit seinem alten Kennwort schon mal angemeldet war, mit seinem Kennwort an, bleibt der Rechner beim Laden des Benutzerprofils mit der Meldung "Warten auf Benutzerprofildienst" stehen. Haben Rechner auch schon über Nacht laufen lassen, aber selbst dann fängt sich die Anmeldung nicht mehr. Auch mehrmaliges Anmelden bringt dann nichts mehr, es passiert immer das selbe.
Wenn ich im AD den Haken "Kennwort muss geändert werden" setze, bekommt der Benutzer bei der Anmeldung die Aufforderung zur Änderung und es funktioniert danach alles wie gewünscht.
In der Ereignisanzeige und im AD finde ich hierzu keine Fehler.
Der Fehler tritt übrigens auch auf, wenn das Kennwort in der AD direkt wurde.
Wisst ihr Rat hierbei?
Danke im Voraus.
Andy
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: 303018
Url: https://administrator.de/forum/nach-kennwortaenderung-warten-auf-benutzerprofildienst-303018.html
Ausgedruckt am: 25.12.2024 um 02:12 Uhr
16 Kommentare
Neuester Kommentar
Hallo,
wieviele DC sind im Einsatz? (replication)
Wie schauts mit gespeicherten Anmeldungen aus?
An einem PC wo noch nie angemeldet wurde geht es sofort?
Wenn es keine GPO gibt, die dafür sorgt, das die Clients vor der Anmeldung auf das Netzwekr warten, eine einrichten und das Verhalten beobachten.
Was sagt das Log auf Cleint und DC?
Gruß
Chonta
wieviele DC sind im Einsatz? (replication)
Wie schauts mit gespeicherten Anmeldungen aus?
An einem PC wo noch nie angemeldet wurde geht es sofort?
Wenn es keine GPO gibt, die dafür sorgt, das die Clients vor der Anmeldung auf das Netzwekr warten, eine einrichten und das Verhalten beobachten.
Was sagt das Log auf Cleint und DC?
Gruß
Chonta
Wir haben zwei DCs im Einsatz auf denen die Replikation auch funktioniert.
Was meinst du mit gespeicherten Anmeldungen?
An meinem PC an dem der User noch nie angemeldet war funktioniert es auf Anhieb.
Die GPO mit dem Warten auf das Netzwerk ist aktiv und greift auch sauber.
Die Ereignisanzeige sagt gar nichts in dem Moment. Keinerlei Einträge.
Gruß Andy
Was meinst du mit gespeicherten Anmeldungen?
An meinem PC an dem der User noch nie angemeldet war funktioniert es auf Anhieb.
Die GPO mit dem Warten auf das Netzwerk ist aktiv und greift auch sauber.
Die Ereignisanzeige sagt gar nichts in dem Moment. Keinerlei Einträge.
Gruß Andy
Hallo,
normalerweise werden die Anmeldungen auf den Clients zwischengespeichert, so könnte man sich auch anmelden wenn das Netzwerk icht da ist.
Sprich wenn ein Benutzer sich schonmal an einem PC angemeldet hat (kein Servergespeichertes Profil) dann wird er sich auch ohne Netzwerk wieder anmelden können. (mit dem dahmals gültigen Passwort)
Gruß
Chonta
normalerweise werden die Anmeldungen auf den Clients zwischengespeichert, so könnte man sich auch anmelden wenn das Netzwerk icht da ist.
Sprich wenn ein Benutzer sich schonmal an einem PC angemeldet hat (kein Servergespeichertes Profil) dann wird er sich auch ohne Netzwerk wieder anmelden können. (mit dem dahmals gültigen Passwort)
Gruß
Chonta
Hey,
ach das meinst du... Ja die Anmeldung sind auf den Clients zwischengespeichert.
Das neue Kennwort wird jedoch auch nicht abgelehnt, sondern er bleibt einfach stehen.
Das Ganze passiert jedoch auch auf mehreren Rechnern mit mehreren Usern.
Gruß Andy
ach das meinst du... Ja die Anmeldung sind auf den Clients zwischengespeichert.
Das neue Kennwort wird jedoch auch nicht abgelehnt, sondern er bleibt einfach stehen.
Das Ganze passiert jedoch auch auf mehreren Rechnern mit mehreren Usern.
Gruß Andy
Passiert das auch, wenn der Rechner schon in Betrieb war und der neue Benutzer sich anmelden will?
Bzw. es war ein anderer angemeldet, der meldet sich ab und der neue an.
Ist im Log des Clients etwas zu finden (Anwendung und System) währende der hängt?
Was passiert, wenn Du bei der Anmeldung das Netzwerkkabel ziehst?
Ist das DNS sauber?
Gab es DC die jetzt nicht mehr da sind?
Gruß
Chonta
Bzw. es war ein anderer angemeldet, der meldet sich ab und der neue an.
Ist im Log des Clients etwas zu finden (Anwendung und System) währende der hängt?
Was passiert, wenn Du bei der Anmeldung das Netzwerkkabel ziehst?
Ist das DNS sauber?
Gab es DC die jetzt nicht mehr da sind?
Gruß
Chonta
Hi, es passiert sowohl nach Neustart oder auch nach einer Anmeldung an einem Rechner der schon lange lief.
Im Log ist kein einziger Eintrag wären der "Wartezeit".
DNS läuft soweit Problemlos... Auch da geben die LOGs keinerlei Fehler aus. AD-Sync läuft auch sauber.
Die DCs laufen seit 1,5 Jahren schon. Hier gab es auch keine größere Änderung.
Andy
Edit:
Konnte jetzt den Test mit dem Netzwerkkabel machen:
- Benutzer hat einem Rechner sein Kennwort geändert
- Ist zum zweiten Rechner (an dem der Benutzer schon mal angemeldet war) gegangen, und der Rechner hing nach Eingabe des neuen Kennwortes wieder bei "Warte auf Benutzerprofildienst". Das Ganze drei vier mal probiert und immer das gleiche.
- Anschließend das Netzwerkkabel gezogen und wieder hochgefahren; Die Anmeldung läuft mit dem neuen Kennwort ohne Probleme.
- Neustart mit Netzwerkkabel und die Anmeldung lieft wieder ohne Probleme.
Im Log ist kein einziger Eintrag wären der "Wartezeit".
DNS läuft soweit Problemlos... Auch da geben die LOGs keinerlei Fehler aus. AD-Sync läuft auch sauber.
Die DCs laufen seit 1,5 Jahren schon. Hier gab es auch keine größere Änderung.
Andy
Edit:
Konnte jetzt den Test mit dem Netzwerkkabel machen:
- Benutzer hat einem Rechner sein Kennwort geändert
- Ist zum zweiten Rechner (an dem der Benutzer schon mal angemeldet war) gegangen, und der Rechner hing nach Eingabe des neuen Kennwortes wieder bei "Warte auf Benutzerprofildienst". Das Ganze drei vier mal probiert und immer das gleiche.
- Anschließend das Netzwerkkabel gezogen und wieder hochgefahren; Die Anmeldung läuft mit dem neuen Kennwort ohne Probleme.
- Neustart mit Netzwerkkabel und die Anmeldung lieft wieder ohne Probleme.
Hallo,
ok ich meinte eigendlich wenn der hängt das Netzwerkkabel mal ziehen und schuaen ob die Anmeldung dann durch geht.
Sind auch WIndows7 Clients betroffen?
Passiert das Problem beim Wechsle von Windows7 zu Windows 8 zu Windows 10?
Bzw in anderer Reihenfolge?
Geht es von innerhalb der gleichen Generation gut?
Servergespeicherte Profile? (wenn ja bestimmt keine Ordnerumleitung oder?)
Seid wann ist das Problem - Server oder Client Updates an einem Patchtag.
Gruß
Chonta
ok ich meinte eigendlich wenn der hängt das Netzwerkkabel mal ziehen und schuaen ob die Anmeldung dann durch geht.
Sind auch WIndows7 Clients betroffen?
Passiert das Problem beim Wechsle von Windows7 zu Windows 8 zu Windows 10?
Bzw in anderer Reihenfolge?
Geht es von innerhalb der gleichen Generation gut?
Servergespeicherte Profile? (wenn ja bestimmt keine Ordnerumleitung oder?)
Seid wann ist das Problem - Server oder Client Updates an einem Patchtag.
Gruß
Chonta
Guten Tag,
habe in den letzten Wochen noch einiges umgestellt und probiert und es verhält sich immer noch gleich.
Es ist vollkommen egal wie man Wechselt...Ob von Win7 zu Win10 oder andersrum... Der Fehler ist immer Identisch.
Der Fehler ist an keiner Systemänderung festzumachen.
Zu dem gezogenen Netzwerkkabel: Wenn der Rechner auf den ProfSvc wartet, wartet er egal was man mit... Mit Netzwerkkabel oder auch wenn man es zieht.
Erst wenn man danach ohne Netzwerkkabel den Rechner startet funktioniert die Anmeldung im Anschluss immer ohne Probleme.
Ich verstehe dieses Verhalten einfach nicht mehr.
habe in den letzten Wochen noch einiges umgestellt und probiert und es verhält sich immer noch gleich.
Es ist vollkommen egal wie man Wechselt...Ob von Win7 zu Win10 oder andersrum... Der Fehler ist immer Identisch.
Der Fehler ist an keiner Systemänderung festzumachen.
Zu dem gezogenen Netzwerkkabel: Wenn der Rechner auf den ProfSvc wartet, wartet er egal was man mit... Mit Netzwerkkabel oder auch wenn man es zieht.
Erst wenn man danach ohne Netzwerkkabel den Rechner startet funktioniert die Anmeldung im Anschluss immer ohne Probleme.
Ich verstehe dieses Verhalten einfach nicht mehr.
Hallo,
das Netzwerkkabel muss gezogen weden BEVOR sich der Benutzer anmeldet.
Danach inst das Kind schon in den Brunnen gefallen.
Wenn der Benutzer sich anmelden kann wenn der Rechner ohne Netzwerk startet...
Verschiebe den Rechner mal in eine OU in der bis auf dei Domainpolecy keine GPO wirken und der Rechner auch KEINE Start/Anmeldescripte ausführt.
Wenn die Benutzer anmeldescripte haben auch diese mal deaktivieren.
Gruß
Chonta
das Netzwerkkabel muss gezogen weden BEVOR sich der Benutzer anmeldet.
Danach inst das Kind schon in den Brunnen gefallen.
Wenn der Benutzer sich anmelden kann wenn der Rechner ohne Netzwerk startet...
Verschiebe den Rechner mal in eine OU in der bis auf dei Domainpolecy keine GPO wirken und der Rechner auch KEINE Start/Anmeldescripte ausführt.
Wenn die Benutzer anmeldescripte haben auch diese mal deaktivieren.
Gruß
Chonta
Hallo,
aber wenn der User sich ein neues Kennwort an Rechner 1 vergibt und ich an Rechner 2 das Kabel vorm hochfahren ziehe, woher soll der Rechner das neue Kennwort kennen? Oder stehe ich hierbei auf dem Schlauch?
aber wenn der User sich ein neues Kennwort an Rechner 1 vergibt und ich an Rechner 2 das Kabel vorm hochfahren ziehe, woher soll der Rechner das neue Kennwort kennen? Oder stehe ich hierbei auf dem Schlauch?
Wenn der Rechner ohne Netzwerk startet und dann eine Anmeldung erfolgt, wird die zwischengespeicherte Anmeldung verwendet.
Und die erfolgt dann mit dem alten Passwort.
Du kannst auch vor einer Anmeldung versuchen den Benutzeranmeldedienst neu zustarten.
Irgendwas muss aber auch in den Logs drin stehen.
Was ist wenn Du mit lokalen Profilen arbeitest, geht das dann immer ohne Probleme?
Gruß
Chonta
Und die erfolgt dann mit dem alten Passwort.
Du kannst auch vor einer Anmeldung versuchen den Benutzeranmeldedienst neu zustarten.
Irgendwas muss aber auch in den Logs drin stehen.
Was ist wenn Du mit lokalen Profilen arbeitest, geht das dann immer ohne Probleme?
Gruß
Chonta
Der User kann sich ohne Probleme an dem selben Rechner nach einer Passwortänderung anmelden.
Nur an einem weiteren Rechner nicht mehr, an dem sein altes Passwort bekannt ist.
Heute ist mir aufgefallen, dass in den Logs auf dem DC ein Eintrag ist. Von genau dem Rechner an dem ich heute getestet habe, allerdings mit knapp 30 Minuten Verzögerung.
DCOM konnte mit dem Computer "PC" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen.
System - Dcom - 10009
Der Test war um ca. 12:30, der Eintrag um 13:07.
Nur an einem weiteren Rechner nicht mehr, an dem sein altes Passwort bekannt ist.
Heute ist mir aufgefallen, dass in den Logs auf dem DC ein Eintrag ist. Von genau dem Rechner an dem ich heute getestet habe, allerdings mit knapp 30 Minuten Verzögerung.
DCOM konnte mit dem Computer "PC" unter Verwendung eines beliebigen, konfigurierten Protokolls keine Daten austauschen.
System - Dcom - 10009
Der Test war um ca. 12:30, der Eintrag um 13:07.
Hallo,
hat mit deinem Problem nix zu tun.
Dann deaktiviere mal die zwischengespeicherten Anmeldungen, dann MUSS imme ralles vom DC geholt werden.
Und ganz wichtig, dafür sorgen das die Kisten auf das Netzwerk WARTEN.
Warum? Die Rechner starten so schnell, das eine Anmeldung möglich ist, bevor das Netzwerk bereit ist.
Wenn jetzt an einem anderen rechner mit veralteten zwischengespeicherten Daten macht, kann er das aber wenn Das Netzwerk steht und er versucht auf Netzwerkresourcen zuzugreifen ZONK falsches Passwort.
Ist die Protokollierung für Anmeldungen aktiviert, was steht drin?
Wichtig auch Hibernate und son müll abstellen, weil damit die Rechner nicht richtig neu gestartet werden sondern sich verhaltne wie beim energiesparmodus und die sitzung vom runterfahren versuchen wiederherzustellen.....
Das zerschießt Dummerweise nur die GPO/Skript Mechanismen die MS selber mal aufgebaut hat....
Gruß
Chonta
hat mit deinem Problem nix zu tun.
Dann deaktiviere mal die zwischengespeicherten Anmeldungen, dann MUSS imme ralles vom DC geholt werden.
Und ganz wichtig, dafür sorgen das die Kisten auf das Netzwerk WARTEN.
Warum? Die Rechner starten so schnell, das eine Anmeldung möglich ist, bevor das Netzwerk bereit ist.
Wenn jetzt an einem anderen rechner mit veralteten zwischengespeicherten Daten macht, kann er das aber wenn Das Netzwerk steht und er versucht auf Netzwerkresourcen zuzugreifen ZONK falsches Passwort.
Ist die Protokollierung für Anmeldungen aktiviert, was steht drin?
Wichtig auch Hibernate und son müll abstellen, weil damit die Rechner nicht richtig neu gestartet werden sondern sich verhaltne wie beim energiesparmodus und die sitzung vom runterfahren versuchen wiederherzustellen.....
Das zerschießt Dummerweise nur die GPO/Skript Mechanismen die MS selber mal aufgebaut hat....
Gruß
Chonta
So habe es getestet mit dem Cachen der letzten Anmeldungen und bei dem User und einem weiteren Rechner lief es ohne Probleme.
Könnte die Einstellung auch per GPO an alle Verteilen, jedoch habe ich ein Problem mit unseren Notebooks dabei.
Ohne gecachte Anmeldung keine Anmeldung mehr möglich an dem Notebooks.
Außer unterschiedliche GPOs, noch eine Idee dazu wie ich das elegant lösen kann?
Gruß Andy
Könnte die Einstellung auch per GPO an alle Verteilen, jedoch habe ich ein Problem mit unseren Notebooks dabei.
Ohne gecachte Anmeldung keine Anmeldung mehr möglich an dem Notebooks.
Außer unterschiedliche GPOs, noch eine Idee dazu wie ich das elegant lösen kann?
Gruß Andy
Hallo,
laptops gehöhren in separate OU.
Ansonsten alle Stationären Rechner in eine Gruppe und das no chache gpo für dise gruppe filtern (nur die gruppe nix anderes)
Oder mit WMI Filter die GPO nur auf nicht Mobile anwenden.
Das mit dem WMI ist aber nicht immer möglich, weil ggf das ein oder andere Laptop nicht mit spielt, siche rist es alle Workstations in eine Gruppe und dan filtern oder Laptops und Workstations in separaten OUs.
Oder Du findest die Ursache, meine Vermutung die Rechner erlauben eine Anmeldung bevor der Netzwerkstack richtig geladen ist und dann zonk alte Anmeldedaten und nix geht.
Gruß
Chonta
laptops gehöhren in separate OU.
Ansonsten alle Stationären Rechner in eine Gruppe und das no chache gpo für dise gruppe filtern (nur die gruppe nix anderes)
Oder mit WMI Filter die GPO nur auf nicht Mobile anwenden.
Das mit dem WMI ist aber nicht immer möglich, weil ggf das ein oder andere Laptop nicht mit spielt, siche rist es alle Workstations in eine Gruppe und dan filtern oder Laptops und Workstations in separaten OUs.
Oder Du findest die Ursache, meine Vermutung die Rechner erlauben eine Anmeldung bevor der Netzwerkstack richtig geladen ist und dann zonk alte Anmeldedaten und nix geht.
Gruß
Chonta
Die Policy "Warten aufs Netzwerk" ist jedoch aktiv.
Werde wohl die Notebooks in eine neue OU Auslagern und dann das mit einer neuen Policy in der nur der Cache deaktiviert einsetzen.
Werde wohl die Notebooks in eine neue OU Auslagern und dann das mit einer neuen Policy in der nur der Cache deaktiviert einsetzen.
