MSXFAQ MeetNow aktiv: Komm doch einfach dazu.

Windows Benutzerprofile

Dieses Seite beleuchtet die Windows Benutzer-Profile auf einem Windows 11 Desktop etwas neuer, denn mit EntraID-Join u.a. gibt es neue Varianten, die im Betrieb aber auch bei Migrationen zu beachten sind.

Benutzerprofile

Früher war die Konfiguration noch relativ einfach, als es nur lokale Konten oder natürlich eine NT-Domäne gab. Im Grund hatte sich seit den ersten Tagen des Windows NT Domain Controllers bis zur aktuelle Windows Server-Version nichts geändert: Sobald eine Firma mehrere Clients hatte, war eine lokalen Pflege von Benutzerkonten eine sehr schlechte Idee und alle Desktops wurden "Domainmitglied" und haben damit auch der zentralen Datenbank für Benutzer, Gruppen und Computer vertraut. Lokale Konten gab es nur für Administratoren oder Dienstkonten für rein lokale Dienste. Wenn sich ein Benutzer am PC angemeldet hat, dann wurde dynamische ein Profilverzeichnis unter "C:\Users\<%username%" angelegt und entweder das "Default Profile des Computers kopiert oder, sofern konfiguriert, ein "Roaming Profile" von einem Dateiserver kopiert. So konnten Anwender sich an allen Geräten anmelden. Welche Profile auf einem Client vorhanden war, konnten Sie über die Systemsteuerung sehen:

Dies ist die Anzeige auf einem HYPER-V-Server "HYPERV2", der in der lokalen AD-Domain "CARIUS" und Mitglied in einem Entra ID ist. Neben der Größe und dem Datum der letzten Änderung gibt es einen Type und einen Status:

  • Typ/Type
    Kennzeichnet, ob das Profil nur lokal vorliegt oder als "Roaming"-Profile beim Anmelden von einem Dateiserver und beim Abmelden wieder zurückkopiert wird.
  • Status
    Auch hier gibt es einmal "Local" für ein lokale Profile und wieder "Roaming". Zusätzlich gibt es aber noch "Temporary". Wenn ein Benutzer auf dem lokalen System z.B. in der Gruppe "Gäste" ist, dann wird das Profil automatisch temporär und nach der Abmeldung gelöscht. zuletzt gibt es noch "Mandantory Profile", die verbleiben aber die Änderungen nach der Abmeldung wieder verworfen werden.

Sie sehen aber schon hier, dass ein "EntraID"-User ohne Bezug zu einem lokalen Active Directory auch ein Profil bekommt. Daraus kann ich folgende Tabelle ableiten:

Client-Mitgliedschaft Anmeldung als Profil

Standalone

Computername/User (Lokal)

Lokal

Domain Mitglied

Computername/User (Lokal) 

Lokal

Domain Mitglied 

Domain/User

Lokal oder Roaming

Domain Mitglied 

Entra ID CloudOnly User

nicht möglich

EntraAD Joined

Computername/User (Lokal)

Lokal 

EntraAD Joined

Domain/User

nicht möglich

EntraAD Joined

Entra ID CloudOnly User

Lokal

EntraAD Joined 

Entra ID DirSync User

Lokal

Hybrid Joined

Computername/User (Lokal) 

Lokal

Hybrid Joined

Domain/User (nur bei Kontakt zum Domain Controller)

Lokal oder Roaming 

Hybrid Joined

Domain/User (nur bei Kontakt zum Domain Controller)

Lokal 

Nur lokale Benutzer sind auch wirklich in der lokalen SAM vorhanden. DomainUser und EntraID User sind

Sie sehen hier schon die Besonderheit, dass ein Domain-Benutzer sich an einem AD-Joined und Hybrid-Joined Device anmelden kann aber die Anmeldung an einem Entra ID-Joined Device natürlich nur möglich ist, wenn das Konto auch ein Entra-ID-Konto hat. Umgekehrt ist es aber einem Entra-ID-Only-Konto nicht möglich, sich an einem Hybrid Joined Device anzumelden. Das ganze noch mal als Tabelle

Benutzer  DomainJoined Hybrid-Joined EntraID Joined
Domain Only 

Ja

Ja

Nein
DirSynced

Ja

Ja

Ja
EntraID Only

Nein 

Nein

Ja

Die grünen und die beide gelben Szenarien lassen sich ja noch erklären, aber dass ein Entra ID-Only Konto sich nicht am Hybrid-Joined Client anmelden kann, mag den ein oder anderen Admin überraschen. Maßgeblich ist nach meiner Einschätzung hier die Priorisierung auf das lokale AD und dass Entra ID hier nur eine sekundäre Anmeldung ist. Generell ist eine erstmalige Anmeldung an einem "Hybrid-Joined" Computer nur mit Verbindung zum Domain Controller möglich.

Benutzerprofile, Regedit und SID

Zu der Anzeige in der GUI gehört natürlich ein Eintrag in der Registrierung. Alle Profile auf einem Windows Client sind hier mit der SID des Benutzers verknüpft. Der Pfad ist:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Hier ein Auszug eines Computers mit verschiedenen lokalen und Domain-Profilen.

Ich habe aus der ProfileListe verschiedener Computer aus unterschiedlichen Domains die SIDs und deren Zuordnung zusammengesucht:

Bedeutung Bedeutung SID  Profilpfad

Lokal

Systemprofil 

 
S-1-5-18 

%systemroot%\system32\config\systemprofile

Lokal 

LocalService 

 
S-1-5-19 

%systemroot%\ServiceProfiles\LocalService

Lokal 

NetworkService 

 
S-1-5-20

%systemroot%\ServiceProfiles\NetworkService 

Lokal 

.NET Systemkonto

 
S-1-5-82-271721585-897601226-2024613209-625570482-296978595

C:\Users\.NET v4.5 

Lokal 

.IIS Systemkonto 

 
S-1-5-82-3006700770-424185619-1745488364-794895919-4004696415

C:\Users\DefaultAppPool 

Lokal 

.NET Systemkonto 

 
S-1-5-82-3876422241-1344743610-1729199087-774402673-2621913236

C:\Users\.NET v4.5 Classic 

Lokal 

Administrator

 
S-1-5-21-126836536-4064733748-308209707-500

C:\Users\administrator (BUildIn)

Lokal 

Admin

 
S-1-5-21-126836536-4064733748-308209707-1001

C:\Users\admin

Lokal 

User1

 
S-1-5-21-126836536-4064733748-308209707-1002

C:\Users\user1

AD-Domain 

AD Domain User

 
S-1-5-21-11949449-30417519-71842111-1009 

C:\Users\fcarius

AD-Domain 

AD Domain User

 
S-1-5-21-11949449-30417519-71842111-12658 

C:\Users\fcarius1

Entra ID (CloudOnly)

Admin2@MSXFAQDEV...

 
S-1-12-1-3255886919-1129945890-3455466132-4088124041 

C:\User\Admin2 (CloudOnly)

Entra ID (Syned)

ADUser1@MSXFAQDEV...

 
S-1-12-1-3003550381-1249573276-4207654077-3163717621

C:\Users\ADUser1 (DirSynced)

Entra ID (CloudOnly)

Admfc@MSXFAQDEV...

 
S-1-12-1-1919109211-1188410033-2200104094-3806127387

C:\User\FrankCariusDEV (CloudOnly)

Entra ID (CloudOnly)

Clouduser1@MSXFAQDEV...

 
S-1-12-1-1468215284-1285803115-2559570101-2481903227

C:\User\CloudUser1 (CloudOnly)

Wer genau vergleicht sieht erst einmal die drei "Default User" einer Windows Installation "System", "LocalService" und "NetworkService". Dann folgen auf diesem System drei weitere lokale Konten, deren SID anscheinend überall gleich ist.

Aber dann wird es interessant, denn ich habe zwei "lokale Benutzer" angemeldet ,die sich nur bei der RID unterscheiden. Der vordere Teil ist die Workstation. Dann haben sich an dem Computer zwei Domain User angemeldet. Auch hier ist der vordere Teil unverändert und nur die RID ändert sich. Wenn ich mir die Werte so anschaue und vergleiche, dann fällt mir folgendes auf:

  • EntraID SIDs beginnen mit S-1-12-1-*
    Zumindest in meinen Testumgebungen war das bisher so, dass alle Benutzer, die sich rein mit einer Entra-ID Kennung auf einem "Entra ID Joined"-Devices angemeldet haben, diese SID bekommen haben. Allerdings gibt es selbst im gleichen Tenant keine weitere Ähnlichkeit vor der RID. Es gibt keinen "Domainteil". Ich vermute, dass die Entra ID SecurityIdentifiers weltweit "unique" sind. Der "Entra ID SecurityIdentifiers" wird auch zur User-SID auf dem Entra ID Joined Client.
  • "DomainSID" + SID beginnt mit S-1-5-*
    Alle Benutzer in einem lokalen Active Directory haben den identischen vorderen Teil der SID und nur der letzte Block, der "relative Identifier (RID)" ändert sich. Die RID sind sogar von 1000 an aufsteigend.
  • Entra ID SecurityIdentifiers bleibt gleich
    Wenn ich das Profil eines Benutzers lösche und wieder neu anlegen lasse, dann wird es mit der gleichen SID angelegt. Die SID wird daher nicht lokal generiert sondern aus der Cloud bezogen. Die SID lässt sich auch einfach ermitteln:

    Das ist wichtig, wenn wir später Profile zwischen Computern umziehen.
  • Profil-Pfad ermittelt sich aus den ersten 20 Zeichen des Displaynamen
    In Entra ID gibt es keinen SamAccountName und auf einen Mailnickname kann sich Windows ebenso wenig verlassen wie auf das Feld "onPremisesSamAccountName", welches bei reinen Cloud-Usern leer ist.
  • OnPremises-SID und Cloud-SID unterscheiden sind.
    Wenn ein Konto per ADSync repliziert wird, dann hat das Konto in Entra ID sogar zwei "SecurityIdentifiers".

    Wenn sich so ein Konto an einem "Domain Joined" oder "Hybrid Joined" Gerät anmeldet, liest der Client die SID vom Domain Controller. Bei einer Anmeldung an einem Entra ID Joined Device wird aber der Entra ID "SecurityIdentifier" als SID genutzt.

Das Verhalten mit den beiden SID je nach Client ist natürlich mehr als ärgerlich, da unterschiedliche SIDs eine Übernahme von Profilen aufgrund der Berechtigungen erschweren.

Hinweis:
Es gibt keine "Cleanup-Funktion", die Profile auf  Endgeräten nach Ausscheiden des Benutzers oder nach einer Zeit ohne Anmeldung entfernt. Siehe dazu auch Clean-UserProfiles und Cached Profile als Risiko.

Inhalte

Ich habe mir mittlerweile angewöhnt, dass ich eigentlich gar keine Profile mehr bei der Neuinstallation von einem Client oder bei der Anmeldung eines Benutzers irgendwie "mitführe".  Bei der ersten Anmeldung legt Windows einfach ein neues Profil an, wenn es nicht schon ein Profil gibt und alles, was der Anwender braucht, muss dann eben durch eine Synchronisation "irgendwie" bereitstelle. Das gleiche gilt natürlich für eine Sicherung von Endgeräten und deren Daten. Hier mal eine vereinfachte Aufschlüsselung von Datenpools:

Bereich  Beschreibung

C:\ 

 Wer eine komplette Sicherung eines System anstrebt, sollte am besten ein Image-Backup anfertigen. Sei es mit dem bei Windows 11 immer noch vorhandenen "Windows 7 Backup" oder eben 3rd Party Tools. So ein komplettes Backup kann die Wiederherstellung eines wichtige Notebooks sehr vereinfachen. Ich spreche aus eigener Erfahrung (Siehe SSD-Fail)

C:\Users

In diesem Verzeichnis ladet pro angemeldetem Benutzer ein Verzeichnis mit dem Profil.

C:\Users\Frank

Wenn sich der Anwender "Frank" anmeldet, dann finden sich in diesem Verzeichnis weitere Unterverzeichnisse aber auch die wichtige Profildateien "NTUSER*.*", welche den Registrierungsschlüssel "HKeyCurrentUser" enthalten. Hier hinterlegen nicht nur Programme teilweise ihre Einstellungen sondern auch Windows selbst, z.B. der Tresor mit Zugangsdaten, Windows Hello-Daten, Zertifikate etc.

Hier landen aber auch Dateien, Musik, Videos, Downloads etc., die ein Anwender z.B. auf seinem Desktop oder den entsprechenden Ordnern ablegt. Ohne "Backup" oder Roaming Profiles sind diese Daten beim Verlust des Clients verloren.

Eine Lösung könnt hier die "Dateiverlauf"-Funktion von Windows sein, die lokale Änderungen, ähnlich der Apple TimeMachine automatisch auf einen USB-Datenträger oder SMB-Freigabe sichert. 

C:\Users\Frank\OneDrive

 Wer in der Microsoft 365-Welt unterwegs ist, nutzt vermutlich sowieso auch OneDrive und kann dort schon mal bis zu 1 TB ablegen, die automatisch in die Cloud repliziert werden. Diese Daten müssen dann auch nicht mehr Bestandteil eines "Roaming Profiles" sein.
Neben OneDrive gibt es auch andere Diensten (GDrive, Dropbox, NextCloud etc.), die eine Synchronisation der Dateien zu einem Cloud-Service ermöglichen. Damit sind diese Daten nicht nur gegen Verlust gesichert, sondern sehr oft auch versioniert und können auch mit anderen Geräten und Personen geteilt werden.

C:\Users\Frank\Git u.a.

Es gibt aber noch viel mehr Dateien, die einen eigenen Replikationsmechanismus. Entwickler arbeiten gerne mit GIT zur Versionsverwaltung und wenn Sie nicht nur Dateien per "Staging" vorbereiten sondern auch einchecken, dann ist das wie ein Backup. Notfalls kann auch ein XCopy/RoboCopy oder Programme wie Syncback (Synchronisation von Dateien) beim Anfertigen von Kopien helfen. Wer ein NAS einsetzt, kann auch hier eventuell fündig werden, z.B. SynologySync

Einige Applikationen nutzen eigene Clouddienste als Backup für Konfigurationen. Microsoft ist hier mit Windows 11 aber auch Edge dabei aber auch Google und Firefox erlauben die Einrichtung eines Kontos im jeweiligen Cloud Dienst und sichern dort Einstellungen, um sie über mehrere Systeme synchron zu halten.

 

C:\Users\Public

 Das Verzeichnis "öffentlich" wird bei der Betrachtung einer Datensicherung gerne vergessen. Ich habe immer wieder erlebt, dass zentral installierte Programme, z.B. LexWare Büro Easy u.a. dort Daten abgelegt haben. Das kann ja sinnvoll sein wenn eine Software in C:\Programme installiert ist und der PC von mehreren Personen mit eigenem Konto genutzt wird.
Diese Verzeichnis wird aber weder von der "Dateiverlauf"-Funktion noch von OneDrive o.ä. berücksichtigt. Oft haben aber solche Branchenprogramme eigene "Backup-Routinen", die natürlich auch genutzt werden sollten.

C:\ProgramData

Genauso gerne legen solche Branchenprogramme und andere Produkte ihre Daten in diesem Verzeichnis ab, welches auch nicht in der "Dateiverlauf"-Funktion oder einem OneDrive-Sync enthalten ist. Bei Servern sind diese Daten meist im Backup enthalten aber wenn Clients nur ihre Profil sichern, dann wird dies gerne vergessen.

Roaming Profiles

In vielen Fällen arbeitet ein Benutzer permanent an seinem eigenen "persönlichen Computer". Wenn der Anwender dann aber den Arbeitsplatz wechselt, dann findet er im Ziel ein neues leeres Profil vor. Einstellungen aber vor allem die im Profil abgelegten Dateien wandern per Default nicht mit. Heute können Anwender die Dateien natürlich mit OneDrive u.a. Diensten synchronisieren oder der Administrator kann per Ordnerumleitung den Benutzer dazu bringen, die Dateien gar nicht mehr lokal zu speichern. Dennoch sind "Roaming Profile" immer noch ein Aspekt in jeder Umgebung mit Windows Clients. Schon die erste NT-Domain kannte beim Benutzer eine Einstellung für Profile:

Dieses Feld ist meist leer, aber wenn Sie es mit einem UNC-Pfad konfigurieren, auf dem der Benutzer berechtigt ist, dann kopiert Windows beim Anmelden das Profil aus diesem Verzeichnis auf den Client und beim Abmelden wieder zurück. Das klingt gut aber ist nicht problemlos.

  • Anmeldezeit
    Je nach Größe und vor allem Anzahl der Dateien im Profil kann die Anmeldung am Desktop entsprechend lange dauert. Nach dem Anmelden mit Kennwort o.ä. startet erst das Kopieren des Profils, um dann die NTUSER.DAT als "HKEY_Current_User" einzubinden und dann die Gruppenrichtlinien anzuwenden, ehe dann erst der Desktop erscheint.
  • Datenmenge
    Sie sollten genau prüfen, welche Dateien im Profil liegen und ob diese auch im "Roaming" eingeschlossen sein sollen. Über eine Gruppenrichtlinie können die Pfade im Profil ausschließen.

    Sie sollten zumindest die Verzeichnisse ausschließen, deren Inhalte nicht zwischen verschiedenen Systemen abgeglichen werden sollen, z.B.: Temp- oder Cache-Dateien von Applikationen
  • Parallelarbeiten - Last Write Wins
    Wenn Anwender auf mehreren Computern parallel arbeiten, dann bekommt jeder das Profil. Windows "sperrt" hier nicht die parallele Anmeldung. Beim Abmelden ist dann die letzte Abmeldung maßgeblich, d.h. es besteht das Risiko, dass eine auf einem System gelöschte oder geänderte Datei durch einen spätere Abmeldung an einem anderen System überschrieben wird.
  • "Disconnected"-Szenario
    Denken Sie auch an Notebooks, Suspend/Resume-Szenarien, bei denen sich Benutzer gar nicht regelmäßig abmelden. Ohne Abmeldung wird nichts zurückgeschrieben. Wer Dokumente z.B. auf dem Desktop ablegt und darauf hofft, dass diese dann auch auf allen anderen Clients sichtbar werden, sollte sich besser OneDrive und andere "Synchronisierer" anschauen.
  • Windows Client Versionen
    Das normale "Profil" unterscheidet erst einmal nicht nach dem Betriebssystem des Clients zu sehen. Früher war es schon ein Problem, wenn Anwender zwischen Windows 7 und Windows 10 gewechselt sind. Microsoft hat daher eine Client-Versionierung eingebaut.

    Diese Funktion muss aber erst über den Schalter "UseProfilePathExtensionVersion" aktiviert werden. Siehe https://support.microsoft.com/de-de/topic/inkompatibilit%C3%A4t-zwischen-windows-8-1-servergespeicherte-benutzerprofile-und-fr%C3%BCheren-versionen-von-windows-e62cb813-a175-60d9-f99a-f926073ab8ad
  • Terminal Server
    Ein Sonderfall sind TerminalServer. Hier ist es "normal", dass ein Anwender immer mal wieder auf einem anderen Server angemeldet wird aber man nicht das reguläre Profil mit Megabytes an Daten kopieren will. Daher kann ich beim Benutzer im Active Directory einen separaten Profilpfad für Terminalserver angeben.
  • User Installed Apps
    Früher haben Administratoren oder eine Softwareverteilung die notwendigen Programme auf den jeweiligen Client installiert. Durch die modernen WebApps, insbesondere "New Outlook/Win" oder auch der Microsoft Teams Client oder leistungsfähige Apps von Webseite, z.B. https://draw.io, die dann im BrowserCache landen, blähen sich Profile sehr stark auf. Hier muss man als Administrator abwägen, ob der User die Apps beim Wechsel des Clients erst neu einrichten muss oder diese im Profil mitgeschleppt werden.

Je größer das Profil wird, desto umfangreicher ist auch das Kopieren. Anscheinend liest Windows den Status jeder einzelnen Datei und vergleich diese mit dem Server. Wer hier also 10.000 kleine Dateien im Profil hat und jede Abfrage dauert 1ms, dann sind das schon 10Sek Verzögerung. Kommt dann ein schnelles WAN dazwischen und addiert niedrige 5ms, dann sind es schon 60 Sekunden und die Anwender beschweren sich über die Performance.

Ziel muss es also sein, dass nicht nur möglichst wenig Dateien kopiert sondern auch überprüft werden müssen. Vielleicht kommen Sie ohne Roaming Profile aus oder können viele Verzeichnisse ausschließen. Auch die "Folder Redirection" ist eine nützliche Funktion, um stationäre Anwender z.B. eine Ablage der Dokument auf dem eh vorhandenen Dateiserver zu forcieren. Auch eine Replikation mit OneDrive, welche dann im Profil ausgeschlossen ist, kann Teil einer Lösung sein.

Zuletzt möchte ich aber auch auf den Zukauf der Firma "FSLogix" durch Microsoft hinweisen. Hierbei liefen die Profile auf einem Dateiserver und werden bei der Anmeldung des Anwenders über das Netzwerk eingebunden. Normalerweise erlaubt Windows nicht, dass das Profil auf einem UNC-Pfad liegt. Aber in dem Fall sieht C:\Users\%benutzername% einfach wie ein Verzeichnis aus, welches darunter aber als Mountpoint von einem Container auf dem Dateiserver verbunden ist. Damit erspart man sich das komplette Kopieren von Profilen. Das funktioniert natürlich nur mit entsprechend guten Verbindungen zwischen dem Client und dem Dateiserver und ist daher für den Einsatz mit Terminal Servern prädestiniert

Profile übernehmen

Die Windows Profile sind mit NTFS-Berechtigungen versehen und weil dies noch nicht genug ist, sind auch in der NTUSER.DAT.*-Dateien, die von Windows als Registrierung unter HKey_Current_User eingebunden werden, ebenfalls mit der SID und ACLs verstehen. Einfach mal so ein "C:\users\<user1>" nach C:\users\<user1> zu kopieren, kann nicht funktionieren. Es gibt natürlich Skripte und Programme, die ein "Suchen und Ersetzen" von ACLs versprechen aber seit Microsoft mit Windows 10 auch noch einen AppStore mit Verbindungen zum Profil eingeführt hat, habe ich eher durchwachsene Erfahrungen mit solchen Tools gemacht. Natürlich kenne ich schon viele Jahrzehnte auch Programme wie ADMT -Active Directory Migration Toolkit, die mit der ein AD-Konto in eine neue Domain samt SID als SIDHistory kopiert werden konnte. Auch Programme wie SUBINACL.EXE u.a. versprechend ACLs zu ersetzen und "TransWiz"/"UserProfileWizard" von https://www.forensit.com oder von den üblichen Herstellern von AD-Migrationswerkzeugen wie Quest etc. gibt es weitere Tools, die Lösungen versprechen.

Prüfen und testen Sie solche Tools, ehe Sie Kunden oder Mitarbeitern eine "problemlose Umstellung" versprechen. Meine Erfahrungen sind mitterlweile so, dass ich eine "Datenübernahme" über einen Server oder Replikation zusichere aber Einstellungen, Desktopfarbe, Startmenü etc. meist neu gemacht werden müssen.
Eine Mitnahme funktioniert eigentlich nur, wenn die SID gleich bleibt und das ist beim Wechsel von einem Domainkonto zu einem Entra ID-Only Loging leider nicht der Fall.

Mit der Auflistung aus dem vorherigen Abschnitt können sie nun besser abschätzen, welche Daten sie wie vermutlich von alleine mitbekommen und auf welche Daten sie noch mal genauer schauen müssen

Weitere Links