12
Anmeldung an Windows Server 2016 nur mit temp. Profilen
Hallo zusammen,
hoffe hier kann mir vielleicht jmd. helfen. Ich habe seit ein paar Tagen Probleme mit unserem Windows Server 2016 Standard, welcher als Domain-Controller verwendet wird.
Egal mit welchem Profil ich mich versuche per RDP anzumelden, ich bekomme immer angezeigt, dass eine Anmeldung mit einem lokalen Profil nicht möglich ist und deswegen eine temp. Profil erstellt wird.
Wir verwenden keine servergespeicherten Profile.
Ich habe schon folgendens versucht:
- abgemeldet und neugestartet
- per regedit (Admin) die Profile gelöscht / unbenannt
- Berechtigungen auf C:/Users/default kontrolliert
- Laufwerk C: überprüft
- Kaspersky deinstalliert
Alles ohne Erfolg.
Sobald ich mich anmelde, wird ein Userordner mit dem Namen z.B. TEMP.Domain.001 angelegt.
In der Ereignisanzeige bekomme ich folgende Fehler:
Die User können sich jedoch an den Clients ganz normal anmelden. Auch mit Usern, die an den Rechnern noch nicht angemeldet waren.
Was mir noch aufgefallen ist, dass der Server während der RDP-Anmeldung bei "Bitte warten Sie auf Konfiguration Remotedesktopdienst" und "Bitte warten Sie auf Benutzerprofildienst" länger benötigt als üblich.
Hat vielleicht jmd. eine Idee?
Gruß
g0drealm
hoffe hier kann mir vielleicht jmd. helfen. Ich habe seit ein paar Tagen Probleme mit unserem Windows Server 2016 Standard, welcher als Domain-Controller verwendet wird.
Egal mit welchem Profil ich mich versuche per RDP anzumelden, ich bekomme immer angezeigt, dass eine Anmeldung mit einem lokalen Profil nicht möglich ist und deswegen eine temp. Profil erstellt wird.
Wir verwenden keine servergespeicherten Profile.
Ich habe schon folgendens versucht:
- abgemeldet und neugestartet
- per regedit (Admin) die Profile gelöscht / unbenannt
- Berechtigungen auf C:/Users/default kontrolliert
- Laufwerk C: überprüft
- Kaspersky deinstalliert
Alles ohne Erfolg.
Sobald ich mich anmelde, wird ein Userordner mit dem Namen z.B. TEMP.Domain.001 angelegt.
In der Ereignisanzeige bekomme ich folgende Fehler:
1511: Das lokale Benutzerprofil wurde nicht gefunden. Sie werden mit einem temporären Benutzerprofil angemeldet. Änderungen, die Sie am Benutzerprofil vornehmen, gehen bei der Abmeldung verloren.
1515: Dieses Benutzerprofil wurde gesichert. Bei der nächsten Anmeldung dieses Benutzers wird automatisch versucht, dieses gesicherte Profil zu verwenden.Die User können sich jedoch an den Clients ganz normal anmelden. Auch mit Usern, die an den Rechnern noch nicht angemeldet waren.
Was mir noch aufgefallen ist, dass der Server während der RDP-Anmeldung bei "Bitte warten Sie auf Konfiguration Remotedesktopdienst" und "Bitte warten Sie auf Benutzerprofildienst" länger benötigt als üblich.
Hat vielleicht jmd. eine Idee?
Gruß
g0drealm
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: 629776
Url: https://administrator.de/contentid/629776
Ausgedruckt am: 22.11.2024 um 08:11 Uhr
12 Kommentare
Neuester Kommentar
Moin,
schau mal unter:
sollte ungefähr so aussehen.
schau mal unter:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileListsollte ungefähr so aussehen.
Hallo,
soweit war ich schon.
bei *.bak wird unter Pfad der richtige Pfad zum Benutzerordner angezeigt.
ohne .bak steht unter Pfad immer C:/Users/TEMP.domäne.00x
löschen von allen Einträgen oder nur das löschen des TEMP Eintrages und Entfernen von .bak hilft jedoch nichts. Beim erneuten Anmelden das selbe Spiel.
soweit war ich schon.
bei *.bak wird unter Pfad der richtige Pfad zum Benutzerordner angezeigt.
ohne .bak steht unter Pfad immer C:/Users/TEMP.domäne.00x
löschen von allen Einträgen oder nur das löschen des TEMP Eintrages und Entfernen von .bak hilft jedoch nichts. Beim erneuten Anmelden das selbe Spiel.
Aus dem .bak Eintrag den richtigen Pfad in den Schlüssel ohne .Bak übernehmen.
Bak Schlüssel löschen und natürlich nachsehen ob unter C:\Users\ auch die Ordner da sind.
Reboot.
Bak Schlüssel löschen und natürlich nachsehen ob unter C:\Users\ auch die Ordner da sind.
Reboot.
Moin,
schon übeprüft, ob das filesystem überhaupt in Ordnund ist und auch die Berechtigungen im Users-Ordner passen?
Hatte schon öfter mal den Fall, daß kaputte Platten oder Filesysteme auch solche Probleme verirsachen und der Kunde sich nicht um die Fehlermeldungen des Systems geschert hatte, bis es "zu spät" war.
lks
schon übeprüft, ob das filesystem überhaupt in Ordnund ist und auch die Berechtigungen im Users-Ordner passen?
Hatte schon öfter mal den Fall, daß kaputte Platten oder Filesysteme auch solche Probleme verirsachen und der Kunde sich nicht um die Fehlermeldungen des Systems geschert hatte, bis es "zu spät" war.
lks
welcher als Domain-Controller verwendet wird.
Öhm, du lässt deine Users per RDP auf einem DC arbeiten?? What the fuck .... Terminal-Services Rolle und DC kombiniert ist eine ziemlich schlechte Idee nur mal so zur Info.Egal mit welchem Profil ich mich versuche per RDP anzumelden
Wurden bei den Usern "Remote-Desktopdienste-Benutzerprofil-Pfade" in den AD Eigenschaften eingetragen? Wenn ja ist der dort hinterlegte Pfad noch vorhanden?
Werden auf dem TS evt. auch unbewusst User-Profile-Disks (UPD) genutzt?
@Tektronix
Also ich habe jetzt mal so ziemlich alles ausprobiert. Einmal hab ich es kurzeitig hinbekommen, dass ich mich ohne temporäres Profil anmelden konnte. Ich habe hierfür über ein anderes temporäres Konto mit Adminrechten den reg-Schlüssel des gewünschten Kontos importiert und den User-Pfad angepasst sowie die anderen reg-Einträge auf 0 gesetzt. Danach hat der RDP-Anmeldevorgang mit diesem Konto 3 Minuten gedauert, jedoch kam diesmal keine Meldung und meine Daten waren auf dem Desktop. Anschließend hab ich mich abgemeldet und beim erneuten Versuch hat er sich wieder mit einem temporären Konto angemeldet und den User-Ordner TEMP.domäne.000 angelegt
Kann es mir nicht erklären
@Lochkartenstanzer
Habe ich auch schon in Betracht gezogen. Würde heute Nachmittag mal noch chkdsk laufen lassen.
Ich habe auch noch ein Vollbackup von der VM von vor 2 Wochen, als der Server noch ordnungsgemäß funktionierte.
Habe jedoch noch nie einen Domaincontroller auf einen früheren Zustand zurückgesetzt. Gibt es da nicht Vertrauensprobleme mit den Clients?
Die Shares würde ich dann einfach über Acronis oder Robocopy überspielen.
Also ich habe jetzt mal so ziemlich alles ausprobiert. Einmal hab ich es kurzeitig hinbekommen, dass ich mich ohne temporäres Profil anmelden konnte. Ich habe hierfür über ein anderes temporäres Konto mit Adminrechten den reg-Schlüssel des gewünschten Kontos importiert und den User-Pfad angepasst sowie die anderen reg-Einträge auf 0 gesetzt. Danach hat der RDP-Anmeldevorgang mit diesem Konto 3 Minuten gedauert, jedoch kam diesmal keine Meldung und meine Daten waren auf dem Desktop. Anschließend hab ich mich abgemeldet und beim erneuten Versuch hat er sich wieder mit einem temporären Konto angemeldet und den User-Ordner TEMP.domäne.000 angelegt
Kann es mir nicht erklären
@Lochkartenstanzer
Habe ich auch schon in Betracht gezogen. Würde heute Nachmittag mal noch chkdsk laufen lassen.
Ich habe auch noch ein Vollbackup von der VM von vor 2 Wochen, als der Server noch ordnungsgemäß funktionierte.
Habe jedoch noch nie einen Domaincontroller auf einen früheren Zustand zurückgesetzt. Gibt es da nicht Vertrauensprobleme mit den Clients?
Die Shares würde ich dann einfach über Acronis oder Robocopy überspielen.
Zitat von @g0drealm:
@Lochkartenstanzer
Habe ich auch schon in Betracht gezogen. Würde heute Nachmittag mal noch chkdsk laufen lassen.
Ich habe auch noch ein Vollbackup von der VM von vor 2 Wochen, als der Server noch ordnungsgemäß funktionierte.
@Lochkartenstanzer
Habe ich auch schon in Betracht gezogen. Würde heute Nachmittag mal noch chkdsk laufen lassen.
Ich habe auch noch ein Vollbackup von der VM von vor 2 Wochen, als der Server noch ordnungsgemäß funktionierte.
Den kannst Du zum Testen in einer Isolierten Umgebung nehmen. um zu prüfen, wie weit sich diese VM von der aktuellen unterscheidet.
Habe jedoch noch nie einen Domaincontroller auf einen früheren Zustand zurückgesetzt.
Macht man i.d.R auch nicht, sondern setzt einfach einen weiteren frisch auf.
Gibt es da nicht Vertrauensprobleme mit den Clients?
Und auch weitere Probleme.
Die Shares würde ich dann einfach über Acronis oder Robocopy überspielen.
Kannst Du auch beim neuen DC.
Aber i.d.R. sollte der DC nur DC sein, zwar notfalls auch DHCP und DNS, aber reiner DC ist das sinnvollste.
lks
@146707
Nope natürlich nicht. Geht nur um meinen Admin-Account. Keine Terminal-Service-Rolle. Dafür hab ich einen extra Server.
nein
s.o.
Öhm, du lässt deine Users per RDP auf einem DC arbeiten?? What the fuck .... Terminal-Services Rolle und DC kombiniert ist eine ziemlich schlechte Idee nur mal so zur Info.
Nope natürlich nicht. Geht nur um meinen Admin-Account. Keine Terminal-Service-Rolle. Dafür hab ich einen extra Server.
Wurden bei den Usern "Remote-Desktopdienste-Benutzerprofil-Pfade" in den AD Eigenschaften eingetragen? Wenn ja ist der dort hinterlegte Pfad noch vorhanden?
nein
Werden auf dem TS evt. auch unbewusst User-Profile-Disks (UPD) genutzt?
s.o.
@Lochkartenstanzer
AD ist ja komplett funktionsfähig. Kann ich dann einfach einen zweiten Domänencontroller verbinden und den dann später zum primary promoten? Geht das?
Ist nur DC, DNS und Fileserver.
Macht man i.d.R auch nicht, sondern setzt einfach einen weiteren frisch auf.
AD ist ja komplett funktionsfähig. Kann ich dann einfach einen zweiten Domänencontroller verbinden und den dann später zum primary promoten? Geht das?
Aber i.d.R. sollte der DC nur DC sein, zwar notfalls auch DHCP und DNS, aber reiner DC ist das sinnvollste.
Ist nur DC, DNS und Fileserver.
Zitat von @g0drealm:
@Lochkartenstanzer
AD ist ja komplett funktionsfähig. Kann ich dann einfach einen zweiten Domänencontroller verbinden und den dann später zum primary promoten? Geht das?
@Lochkartenstanzer
Macht man i.d.R auch nicht, sondern setzt einfach einen weiteren frisch auf.
AD ist ja komplett funktionsfähig. Kann ich dann einfach einen zweiten Domänencontroller verbinden und den dann später zum primary promoten? Geht das?
Ja. Einfach die FSMO-Rollen übertragen.
Aber i.d.R. sollte der DC nur DC sein, zwar notfalls auch DHCP und DNS, aber reiner DC ist das sinnvollste.
Ist nur DC, DNS und Fileserver.
ok.
lks
Zumindest über die Migration des Fileservers solltest du mal nachdenken. Das macht den restore im Ausfallfall des DC's um einiges einfacher.
Ich habe auch noch ein Vollbackup von der VM von vor 2 Wochen, als der Server noch ordnungsgemäß funktionierte.
Wenn es ein reiner DC wäre und nicht der einzige, dann könntest du den einfach platt machen und einen neuen DC drauf installieren, ohne FS Probleme zu bekommen. Wenn du ihne jetzt wiederherstellst, dann musst du den DC im Recoverymodus erstmal bearbeiten, damit es keinen Konflikt mit anderen DCs gibtZu deinem Ursprungsproblem. zurück: Ich weiß, die Frage ist ziemlich blöd, aber hast du den Server einfach mal neu gestartet? Wir hatten vor einigen Wochen ein ähnliches Problem. User haben (gefühlt) zufällig Probleme mit ihren Benutzerprofilen gehabt und konnten nur lokal angemeldet werden. Selbst die Admins, die keine Roamingprofile oder Ordnerumleitungen hatten, bekamen diese Meldung wenn sie sich an einem Server angemeldet haben. Wir haben den betroffenen Server einfach (nachdem wir 3 Wochen alles andere Versucht und analysiert haben) neu gestartet und die Probleme waren dann behoben. Im Nachgang haben wir dann herausgefunden, dass ein Update in den Update-Einstellung als '"Bereit zur Installation" angezeigt wurde. Das Update war aber bereits Installiert und hat auf einen Neustart gewartet. Ich habe grade mal geschaut, ich finde die KB Nummer nicht mehr.
Warum erwähne ich das? Das Problem trat bei uns ausschließlich an dem Fileserver auf. Vielleicht ärgert dich das gleiche Update? Noch eine Information zu dem Update. Bei uns hat sich dann der Fileserver gefühlt 10 mal während des Updateprozesses neu gestartet und das Update hat fast 2 Stunden gedauert. Also lieber spät abends machen
@Doskias
Ich habe den DC abends schon einige Male neugestartet. Ich werde heute Abend mal noch ein Fullbackup machen und dann chkdsk laufen lassen. Updates sind keine ausstehend.
Ein paar Tage bevor ich bemerkte, dass die Anmeldung am DC nicht mehr richtig funktioniert, wurde nur ein ISCSI-Laufwerk mit Freigaben (keine die irgendwas mit Benutzern zu tun haben) getrennt und wir hatten 2 Mal kurz hintereinander Stromausfall. Beim 2. Mal hat die USV irgendwas abbekommen, wodurch die Ausgangsgruppe 2 nicht mehr funktionierte. Mit einer Ersatz-USV funktionert jetzt alles wieder, jedoch wollte der DC beim 2. Stromausfall vermutlich gerade starten und vermutlich Updates konfigurieren und ist währendessen abgeschmirt.
Ich habe den DC abends schon einige Male neugestartet. Ich werde heute Abend mal noch ein Fullbackup machen und dann chkdsk laufen lassen. Updates sind keine ausstehend.
Ein paar Tage bevor ich bemerkte, dass die Anmeldung am DC nicht mehr richtig funktioniert, wurde nur ein ISCSI-Laufwerk mit Freigaben (keine die irgendwas mit Benutzern zu tun haben) getrennt und wir hatten 2 Mal kurz hintereinander Stromausfall. Beim 2. Mal hat die USV irgendwas abbekommen, wodurch die Ausgangsgruppe 2 nicht mehr funktionierte. Mit einer Ersatz-USV funktionert jetzt alles wieder, jedoch wollte der DC beim 2. Stromausfall vermutlich gerade starten und vermutlich Updates konfigurieren und ist währendessen abgeschmirt.
