Anmeldung an Windows Server 2016 nur mit temp. Profilen

g0drealm
Goto Top
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

Content-Key: 629776

Url: https://administrator.de/contentid/629776

Ausgedruckt am: 18.05.2022 um 01:05 Uhr

Mitglied: Tektronix
Tektronix 09.12.2020 um 09:19:32 Uhr
Goto Top
Moin,
schau mal unter:


screenshot 2020-12-09 091409 - kopie

sollte ungefähr so aussehen.
Mitglied: g0drealm
g0drealm 09.12.2020 aktualisiert um 09:35:13 Uhr
Goto Top
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.
profile
Mitglied: Tektronix
Tektronix 09.12.2020 um 09:50:45 Uhr
Goto Top
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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 09.12.2020 um 10:12:59 Uhr
Goto Top
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
Mitglied: 146707
146707 09.12.2020 aktualisiert um 11:14:30 Uhr
Goto Top
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?

screenshot

Werden auf dem TS evt. auch unbewusst User-Profile-Disks (UPD) genutzt?
Mitglied: g0drealm
g0drealm 09.12.2020 um 11:20:18 Uhr
Goto Top
@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 :-| face-plain

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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 09.12.2020 um 11:27:19 Uhr
Goto Top
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.

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
Mitglied: g0drealm
g0drealm 09.12.2020 aktualisiert um 11:32:25 Uhr
Goto Top
@primal

Ö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.
Mitglied: g0drealm
g0drealm 09.12.2020 aktualisiert um 11:33:36 Uhr
Goto Top
@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?

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.
Mitglied: Lochkartenstanzer
Lochkartenstanzer 09.12.2020 aktualisiert um 11:40:29 Uhr
Goto Top
Zitat von @g0drealm:

@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
Mitglied: Doskias
Doskias 09.12.2020 um 14:55:35 Uhr
Goto Top
Zitat von @g0drealm:
Ist nur DC, DNS und Fileserver.

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 gibt

Zu 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 :) face-smile
Mitglied: g0drealm
g0drealm 11.12.2020 um 10:27:18 Uhr
Goto Top
@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.