Einführung in Windows-Benutzerprofile - AppData und NTUSER.DAT

Dieser Artikel richtet sich als allgemeine Übersicht an IT-Verantwortliche, die Windows verwalten, an Personen, die für die Geräteverteilung zuständig sind, sowie an Windows-Anwendungsentwickler. Die Abbildungen sind konzeptioneller Natur. In Markdown-Umgebungen mit Mermaid-Unterstützung werden sie als Diagramme dargestellt.

Der Inhalt basiert auf offiziellen Microsoft-Informationen, die zum Stand April 2026 überprüfbar waren. [1][4][7][10][13][14]

Wegweiser für die Lektüre

Der Artikel ist lang, deshalb hier vorab ein Einstiegspunkt für jede Zielgruppe.

Bei Windows-Beratungen wird der Begriff „Profil“ sehr breit verwendet.

• Was genau steckt in C:\Users\Benutzername?
• Wie sollten %AppData% und %LocalAppData% unterschiedlich genutzt werden?
• Was ist ein Roamingprofil in einer Domänenumgebung?
• Worin unterscheiden sich ein Mandatory-Profil und ein Temporary-Profil?
• Was sollte man bei gemeinsam genutzten PCs, RDS, VDI oder Azure Virtual Desktop wählen?
• Wo fängt man an, wenn ein Profil kaputtgeht?

Hier mischen sich schnell Konto, Ordner, Registrierung, Synchronisierungsmethode und Betriebsrichtlinie, sodass das Gespräch schnell vom Thema abkommt.

In diesem Artikel etablieren wir zunächst die Sichtweise, das Windows-Benutzerprofil als einen einzigen Bauplan zu betrachten, und gehen anschließend der Reihe nach durch die Verwendung von AppData, Roaming, Mandatory, Temporary, FSLogix und die Fehlersuche bei Problemen.

1. Das Wichtigste zuerst

Bevor es ins Detail geht, hier vorab die praktischen Kernaussagen.

• Ein Windows-Benutzerprofil ist nicht einfach der Ordner C:\Users\Benutzername. Es ist die Kombination aus Dateien und einem Benutzer-Registrierungshive (NTUSER.DAT). [1]
• Auf einem gewöhnlichen lokalen PC wird standardmäßig ein lokales Profil angelegt. Bei der ersten Anmeldung wird ein neues Profil auf Basis von C:\Users\Default erstellt. [11][12]
• Den Speicherort für Anwendungsdaten sollte man nicht beliebig festlegen. Die Grundregel lautet: Einstellungen, die pro Benutzer mitgenommen werden sollen, gehören nach %APPDATA%; Caches oder vorübergehende Zustände, die nur für diesen PC gelten, gehören nach %LOCALAPPDATA%. [2][3]
• Ein Roamingprofil ist ein Mechanismus, der „das gesamte Profil auf eine Freigabe verschiebt“, während Folder Redirection nur „bekannte Ordner wie Documents an einen anderen Ort verlagert“. Beides ist nicht dasselbe. [4][5]
• Ein Mandatory-Profil ist ein schreibgeschütztes Profil, das Benutzern die Arbeit erlaubt, aber nichts speichert. Ein Temporary-Profil ist eine Notlösung bei Fehlern, die grundsätzlich bei jeder Sitzung wieder verschwindet. [7][8][9]
• Bei Roamingprofilen über OS-Generationen hinweg ist Vorsicht geboten. Windows 10 / Server 2016 und neuer sind mit älteren Versionen inkompatibel, weshalb man von vornherein mit getrennten Profilversionen planen sollte. [6]
• Für RDS / VDI / Azure Virtual Desktop gibt es viele Situationen, in denen FSLogix-Profilcontainer die erste Wahl sein sollten, statt sich allein auf klassische Roamingprofile zu verlassen. Auch Microsoft empfiehlt FSLogix für Azure Virtual Desktop. [13][14]
• Bei Problemen ist es sinnvoller, nicht sofort in C:\Users herumzuwühlen, sondern zunächst das Application-Protokoll, die Operational-/Diagnostic-Protokolle des User Profile Service, den Freigabepfad sowie Attribute und Berechtigungen von NTUSER.DAT / USRCLASS.DAT zu prüfen. [10][11][16]

Kurz gesagt läuft alles bei Windows-Profilen auf „was wird wo abgelegt, wie weit wird es mitgenommen, und wie wird im Fehlerfall zurückgesetzt“ hinaus.

1.1 In diesem Artikel verwendete Abkürzungen

Die gleich zu Beginn verwendeten Abkürzungen werden hier aufgelöst.

2. Was ist ein Windows-„Benutzerprofil“ überhaupt?

Zunächst wird es einfacher, wenn man Konto und Profil getrennt betrachtet.

flowchart LR
    A[Benutzerkonto<br/>Wer meldet sich an] --> B[Benutzerprofil<br/>Einstellungen und Daten dieser Person]
    C[Gerät / Betriebssystem] --> B
    B --> D[Desktop-Einstellungen]
    B --> E[AppData]
    B --> F[Documents / Desktop usw.]
    B --> G[Unter HKCU sichtbare Einstellungen]

• Das Konto identifiziert eine Person
• Das Profil ist die eigentliche Substanz der Arbeitsumgebung dieser Person
• Das Gerät ist der Ort, an dem dieses Profil geladen und verwendet wird

Auch Microsoft Learn erklärt, dass ein Benutzerprofil die Profilordner im Dateisystem sowie den Registrierungshive NTUSER.DAT umfasst, und dass dieser Hive bei der Anmeldung geladen und als HKEY_CURRENT_USER verwendet wird. [1]

2.1 Nicht nur „Ordner“ - die Registrierung gehört dazu

Das ist der entscheidende Punkt.

flowchart TD
    A[Anmeldung] --> B[Profilordner ermitteln]
    B --> C[NTUSER.DAT laden]
    C --> D[Als HKCU verwenden]
    B --> E[Desktop / Documents / AppData vorbereiten]
    D --> F[Benutzereinstellungen werden wirksam]
    E --> F

Wer also nur C:\Users\Benutzername betrachtet, sieht erst die halbe Wahrheit.

Ein Windows-Profil besteht im Wesentlichen aus zwei Schichten.

1. Die Dateischicht Desktop, Documents, Downloads, AppData und Ähnliches
2. Die Registrierungsschicht HKCU, gestützt auf das geladene NTUSER.DAT

Diskussionen über Profilbeschädigungen sind deshalb verwirrend, weil es Fälle gibt, in denen nur die Ordnerseite kaputtgeht, und Fälle, in denen das Problem im Registrierungshive liegt. [1][11]

2.2 Bei der ersten Anmeldung dient Default als Vorlage

Meldet sich ein neuer Benutzer zum ersten Mal an einem PC an, erstellt Windows ein lokales Profil auf Basis von C:\Users\Default. [11]

flowchart LR
    A[C:\Users\Default] --> B[Erste Anmeldung]
    B --> C[C:\Users\Benutzername wird erstellt]
    C --> D[NTUSER.DAT wird geladen]
    D --> E[Wird zur dedizierten Umgebung dieses Benutzers]

Wer das im Kontext von Image-Verteilung oder Geräte-Provisionierung nachlässig behandelt, bekommt später erhebliche Probleme.

Microsoft erklärt, dass die unterstützte Methode zur Anpassung des Standardprofils die Verwendung von CopyProfile ist. Manuelles Kopieren oder altmodische, grobe Vervielfältigung kann unerwünschte Informationen einschleppen und Probleme bei Anwendungen und der Systemstabilität verursachen. [12]

3. Wie man C:\Users\Benutzername liest

Von der Ordnerseite aus betrachtet, hat ein Benutzerprofil grob diese Struktur.

flowchart TD
    A["C:\Users\Benutzername"] --> B[Desktop]
    A --> C[Documents]
    A --> D[Downloads]
    A --> E[Pictures]
    A --> F[AppData]
    A --> G[NTUSER.DAT]
    F --> H[Roaming]
    F --> I[Local]
    F --> J[LocalLow]

In der Praxis sind das meist die ersten Orte, die man sich ansieht.

3.1 AppData in drei Bereiche unterteilt betrachten

Bei der Windows-App-Entwicklung und bei der Fehlersuche wird an dieser Stelle am häufigsten durcheinandergebracht.

Microsofts Leitfaden empfiehlt, für anwendungsspezifische Daten FOLDERID_RoamingAppData (Roaming AppData) zu verwenden und für temporäre Dateien und Daten, die auf keinem anderen Computer benötigt werden, FOLDERID_LocalAppData. [2]

Außerdem sind in der Definition der Known Folders die Standardpfade wie folgt festgelegt. [3]

• %APPDATA% = %USERPROFILE%\AppData\Roaming
• %LOCALAPPDATA% = %USERPROFILE%\AppData\Local
• LocalLow = %USERPROFILE%\AppData\LocalLow

flowchart LR
    A[AppData] --> B[Roaming]
    A --> C[Local]
    A --> D[LocalLow]

    B --> B1[Einstellungen, die mitgenommen werden sollen]
    B --> B2[Kleinerer Benutzerzustand]

    C --> C1[Caches]
    C --> C2[Regenerierbare Daten]
    C --> C3[PC-spezifischer Zustand]

    D --> D1[Bereich, in den Prozesse mit niedriger Integritätsstufe schreiben können]

LocalLow ist kein „ungenutzter Ort“, sondern der Ablageort für Apps mit geringen Rechten

Von den drei Bereichen wird LocalLow meist am kürzesten erklärt, aber das liegt nur an seinem speziellen Einsatzzweck - der Grund für seine Existenz ist klar.

Windows-Prozesse besitzen eine Berechtigungsstufe namens Integritätsstufe (integrity level), und Prozesse, die mit niedriger Integrität laufen, können nicht in AppData\Roaming, AppData\Local oder den größten Teil von HKCU schreiben. Damit trotzdem etwas gespeichert werden kann, gibt es einen Ort, in den auch bei niedriger Integrität geschrieben werden kann: %USERPROFILE%\AppData\LocalLow sowie auf Registrierungsseite HKEY_CURRENT_USER\Software\AppDataLow. [19]

Zusammengefasst ergibt sich also:

Ein typisches Beispiel sind Apps, die Teile, die direkt mit Internetinhalten umgehen, bewusst mit reduzierten Rechten ausführen - etwa Browser. Der Gedanke dahinter: „Selbst wenn dieser Prozess gekapert wird, bleibt der Schaden auf LocalLow beschränkt.“

Aus Sicht der Anwendungsentwicklung ist das Fazit einfach.

• Wenn Ihre eigene App nicht mit niedriger Integrität läuft, gibt es keinen Grund, LocalLow zu verwenden. Nutzen Sie Local.
• Umgekehrt gilt: Taucht in LocalLow ein unbekannter Ordner auf, schreibt dort etwas, das mit niedriger Integrität läuft. Das ist ein hilfreicher Hinweis bei der Suche nach Speicherplatzfressern.

So sollte man in der Praxis entscheiden

Auch in Microsofts Definition der bekannten Ordner wird ProgramData als Anwendungsdaten für alle Benutzer bezeichnet, gedacht für gemeinsam genutzte Daten, die nicht roamen. [3]

Am meisten vermeiden sollte man hier, benutzerbezogene Laufzeitdaten in Program Files abzulegen. Das bringt sowohl die Profilorganisation als auch das Berechtigungsdesign schnell durcheinander.

3.2 Public und Default haben unterschiedliche Rollen

Auch hier kommt es leicht zu Verwechslungen.

flowchart LR
    A["C:\Users"] --> B[Default]
    A --> C[Public]
    A --> D[Jeder Benutzer]

    B --> B1[Ausgangspunkt für neue Profile]
    C --> C1[Für alle Benutzer sichtbare Freigabe]
    D --> D1[Substanz des jeweiligen Benutzers]

• Default ist die Vorlage zur Erstellung neuer Profile
• Public ist der gemeinsame Bereich, der für alle Benutzer sichtbar ist
• Der jeweilige Benutzerordner ist die eigentliche Substanz dieser Person

Diese drei sehen einander ähnlich, haben aber völlig unterschiedliche Rollen.

4. Die Profiltypen im Überblick

Auch wenn man pauschal von „Profil“ spricht, gibt es in der Praxis mindestens die folgenden Arten.

flowchart TD
    A[Windows-Profile] --> B[Lokales Profil]
    A --> C[Roamingprofil]
    A --> D[Mandatory-Profil]
    A --> E[Temporary-Profil]
    A --> F[FSLogix-Profilcontainer]

4.1 Lokales Profil

Auf einem gewöhnlichen PC ist dies der Standard.

• Wird auf der lokalen Festplatte dieses PCs erstellt
• Wird nicht automatisch auf andere PCs mitgenommen
• Auf einem einzelnen PC die einfachste Lösung

Microsoft erklärt ebenfalls, dass Windows standardmäßig ein lokales Benutzerprofil erstellt. [14]

4.2 Roamingprofil

Microsoft Learn beschreibt Roaming User Profiles als Mechanismus, der auf einer Serverfreigabe gespeichert wird, sodass Benutzer auf mehreren Computern dieselben Betriebssystem- und Anwendungseinstellungen erhalten. [4][5]

flowchart LR
    A[Profil auf freigegebenem Server] <--> B[PC-A]
    A <--> C[PC-B]
    A <--> D[PC-C]

In der Praxis gibt es jedoch folgende Vorbehalte.

• Kopiervorgänge und Synchronisierung bei An-/Abmeldung werden leicht schwerfällig
• Große Datenmengen in AppData\Local sind problematisch
• Anfällig für Unterschiede zwischen OS-Versionen
• Stark abhängig von Freigabepfad und Netzwerkqualität

4.3 Mandatory-Profil

Ein Mandatory-Profil ist ein „nicht speicherndes Roamingprofil“, das von einem Administrator erstellt wird. [7][8]

Laut Microsoft werden bei einem Mandatory-Profil Änderungen, die Benutzer während einer Sitzung vornehmen, nicht wie bei einem normalen Roamingprofil gespeichert. [7]

Die Win32-Dokumentation erklärt außerdem:

• Wird NTUSER.DAT in NTUSER.MAN umbenannt, wird das Profil zu einem Mandatory-Profil
• Endet der Ordnername des Profilpfads auf .man, entsteht ein Super-Mandatory-Profil

[8]

flowchart LR
    A[Vom Administrator vorbereitetes Profil] --> B[Benutzer meldet sich an]
    B --> C[Während der Nutzung sind Änderungen möglich]
    C --> D[Abmeldung]
    D --> E[Änderungen werden nicht gespeichert]

Das eignet sich zum Beispiel für folgende Einsatzzwecke:

• Bildungseinrichtungen
• Empfangsterminals
• Kioske
• Gemeinsam genutzte Geräte, die jedes Mal in einen sauberen Zustand zurückversetzt werden sollen

4.4 Temporary-Profil

Ein Temporary-Profil ist keine Design-Entscheidung, sondern die Ausweichlösung, die bei einem Fehler zum Einsatz kommt, wenn das eigentliche Profil nicht geladen werden kann. [9]

Microsoft Learn erklärt, dass bei einer Fehlerbedingung, die das Laden des eigentlichen Profils verhindert, ein Temporary Profile ausgegeben wird, das am Ende der Sitzung gelöscht wird, wobei Änderungen verloren gehen. [9]

flowchart TD
    A[Laden des normalen Profils beginnt] --> B{Kann es geladen werden}
    B -->|Ja| C[Normale Anmeldung]
    B -->|Nein| D[Anmeldung mit Temporary-Profil]
    D --> E[Arbeiten ist möglich]
    E --> F[Änderungen gehen bei der Abmeldung verloren]

Läuft ein System also mit einem Temporary-Profil, ist das bereits selbst ein Anzeichen für ein Problem.

4.5 FSLogix-Profilcontainer

FSLogix wird auf Microsoft Learn als Mechanismus beschrieben, der das Windows-Benutzerprofilerlebnis in virtuellen Desktopumgebungen konsistent macht. [13]

Ein FSLogix-Profilcontainer ist ein Ansatz, bei dem das gesamte Benutzerprofil als VHD / VHDX vorgehalten, bei der Anmeldung angehängt und als natives Profil dargestellt wird. [13][14]

flowchart LR
    A[Profil auf VHD / VHDX] --> B[Wird bei der Anmeldung angehängt]
    B --> C[Erscheint auf dem Sitzungshost als C:\Users\Benutzer]
    C --> D[Wird bei der Abmeldung ausgehängt]

Für Azure Virtual Desktop empfiehlt Microsoft die Verwendung von FSLogix-Profilcontainern. [14]

5. Worin sich Roamingprofile, Folder Redirection und FSLogix unterscheiden

Diese drei werden oft in einem Atemzug genannt, haben aber unterschiedliche Rollen.

flowchart TD
    A[Benutzerzustand mitnehmen] --> B[Roamingprofil]
    A --> C[Folder Redirection]
    A --> D[FSLogix]

    B --> B1[Gesamtes Profil auf eine Freigabe]
    C --> C1[Nur bekannte Ordner an einen anderen Ort]
    D --> D1[VHD/VHDX anhängen]

Orientiert man sich an der Einordnung von Microsoft Learn, lassen sich die Unterschiede so am einfachsten erkennen. [4][5][14]

5.1 Folder Redirection verschiebt nur „bekannte Ordner“

Auf Microsoft Learn ist Folder Redirection ein Mechanismus, der den Pfad eines bekannten Ordners an einen anderen Ort umleitet. [4]

Leitet man beispielsweise Documents auf eine Dateifreigabe um, sieht es für den Benutzer aus wie lokal, während die eigentlichen Daten an anderer Stelle liegen. [4]

flowchart LR
    A[Documents] --> B[Eigentliche Daten auf einer Dateifreigabe]
    C[Desktop] --> D[Bei Bedarf separate Einstellung]
    E[AppData] --> F[Unverändert oder anderer Ansatz]

Folder Redirection ist also kein Ersatz für das gesamte Profil, sondern eine Umverlagerung auf Ordnerebene.

5.2 Roamingprofile nicht unbedacht über OS-Generationen hinweg mischen

Microsoft erklärt, dass Roamingprofile von Windows 10 / Server 2016 und neuer mit früheren Windows-Versionen inkompatibel sind. [6]

flowchart LR
    A[Windows 7 / 8.1-Reihe] -.Vorsicht beim Mischen.-> B[Dieselbe Freigabe]
    C[Windows 10 / Server 2016 und neuer] -.Vorsicht beim Mischen.-> B
    B --> D[Ursache für Inkonsistenzen / defektes Startmenü / defekte Taskleiste]

Wichtig ist hier:

• Profilversionen nach OS-Generation trennen
• Nicht davon ausgehen, dass „derselbe Benutzer, also derselbe Ordner“ in Ordnung ist
• Bei Geräteverteilung oder -erneuerung die Profilkompatibilität in den Migrationsplan aufnehmen

[6]

6. Speicherorte, die Entwickler und Betrieb vorab festlegen sollten

Die Profildiskussion läuft letztlich immer auf dasselbe hinaus: Was gehört wohin.

flowchart TD
    A[Zu speichernde Daten] --> B{Ist es ein Arbeitsergebnis des Benutzers}
    B -->|Ja| C[Documents usw.]
    B -->|Nein| D{Ist es PC-spezifisch}
    D -->|Ja| E[%LOCALAPPDATA%]
    D -->|Nein| F{Ist es eine benutzerspezifische Einstellung}
    F -->|Ja| G[%APPDATA%]
    F -->|Nein| H{Sind es veränderliche Daten, die für alle Benutzer gelten}
    H -->|Ja| I[ProgramData + ACL]
    H -->|Nein| J[Speicherort erneut überdenken]

6.1 Vom Benutzer erstellte Dateien vom internen App-Zustand trennen

Vermischt man das, brechen Backup und Migration leicht.

• Arbeitsergebnisse, mit denen der Benutzer bewusst umgeht Documents, Pictures, geschäftliche Ablageordner
• Interner Zustand der Anwendung Einstellungen, Caches, Miniaturansichten, Sitzungsinformationen, Arbeitsdateien

Ersteres sind Geschäftsdaten, Letzteres dient den Belangen der Anwendung. Auch wenn beides „Dateien“ sind, sollten sie unterschiedlich behandelt werden.

6.2 Was in %APPDATA% gehört

Hierher gehört grob gesagt:

• Kleinere Einstellungen
• Benutzerspezifische Präferenzen
• Zustand, der auf mehreren Geräten gleich aussehen soll
• Dinge, die problemlos mit dem Profil mitwandern dürfen

Auch die Dokumentation zu Fast User Switching nennt FOLDERID_RoamingAppData als Ablageort für anwendungsspezifische Daten. [2]

6.3 Was in %LOCALAPPDATA% gehört

Hierhin gehört, was aus Sicht von Regenerierbarkeit und Mitnehmbarkeit lokal bleiben sollte.

• Regenerierbare Caches
• Zustand, der nur lokal Bedeutung hat
• Große Arbeitsdateien
• Dinge, die aus Performance-Gründen nicht mitgenommen werden sollen

Auch in der Definition der Known Folders ist LocalAppData gleich %USERPROFILE%\AppData\Local. [3]

6.4 Was in ProgramData gehört

Daten, die für alle Benutzer gemeinsam gelten, sich aber zur Laufzeit ändern, sind ein Kandidat für ProgramData. [3]

Zum Beispiel:

• Gemeinsam genutzte Wörterbücher
• Definitionsdateien, die für alle Benutzer gelten
• Veränderliche Daten, die zwischen einem Dienst und mehreren Benutzern geteilt werden

Allerdings muss dieser Bereich einschließlich des ACL-Designs durchdacht werden. Nicht „gemeinsam genutzt, also erst mal nach ProgramData“, sondern die Entscheidung, wer liest und wer schreibt, ist entscheidend.

6.5 Wenn Sie das Standardprofil vorkonfigurieren möchten

Bei der Image-Verteilung kommt es häufig vor, dass „alle neuen Benutzer dieselben Ausgangseinstellungen erhalten sollen“. In diesem Fall ist es sicherer, nicht Default grob von Hand anzufassen, sondern es mit der von Microsoft unterstützten, auf CopyProfile basierenden Methode aufzubauen. [12]

flowchart LR
    A[Ersteinrichtung mit einem Administratorkonto] --> B[Sysprep + CopyProfile]
    B --> C[Wird in das Default-Profil übernommen]
    C --> D[Gilt für nachfolgende neue Benutzer]

Vorgehensweisen wie „C:\Users\A eines PCs manuell in das Default eines anderen PCs kopieren“ sehen zwar schnell aus, führen aber später leicht zu Problemen. [12]

7. Vorgehen bei defektem, temporärem oder nicht synchronisierendem Profil

Das ist der Punkt, an dem es in der Praxis am meisten Ärger gibt. Und weil sich die Symptome ähneln, verliert man sich bei nachlässiger Eingrenzung leicht in der Tiefe.

7.1 Symptome zunächst in drei Gruppen einteilen

flowchart TD
    A[Sieht nach Profilproblem aus] --> B{Kann sich der Benutzer anmelden}
    B -->|Ja| C{Sieht alles zurückgesetzt aus}
    B -->|Nein| D[Ladefehler-Kategorie]
    C -->|Ja| E[Temporary / beschädigt / anderes Profil]
    C -->|Nein| F{Setzen sich nur einzelne Einstellungen zurück}
    F -->|Ja| G[Roaming / Redirection / Synchronisierungs-Kategorie]
    F -->|Nein| H[Möglicherweise ein anwendungsspezifisches Problem]

Grob unterteilt gibt es drei Kategorien:

1. Fehler bei der Anmeldung
2. Anmeldung gelingt, aber alles sieht zurückgesetzt aus
3. Nur ein Teil synchronisiert nicht

7.2 Die Protokolle, die Sie zuerst prüfen sollten

Microsoft Learn empfiehlt bei der Untersuchung von Profilproblemen, in dieser Reihenfolge vorzugehen. [10]

1. Das Application-Protokoll
2. Das Operational-Protokoll des User Profile Service
3. Bei Bedarf das Diagnostic-Protokoll
4. Bei weiterem Bedarf ETL-Traces

Die konkreten Pfade sind wie folgt. [10]

• Ereignisanzeige Anwendungs- und Dienstprotokolle > Microsoft > Windows > User Profile Service > Operational
• Für mehr Details ... > User Profile Service > Diagnostic

In der Ereignisanzeige eines deutschsprachigen Windows lautet der linke Baum entsprechend Anwendungs- und Dienstprotokolle > Microsoft > Windows > User Profile Service > Operational. Ab der Ebene des Anbieternamens bleiben die Bezeichnungen englisch.

flowchart LR
    A[Application-Protokoll] --> B[Operational-Protokoll]
    B --> C[Diagnostic-Protokoll]
    C --> D[ETL-Trace]

In der Praxis ist es sicherer, nicht direkt mit Registrierungsreparaturen oder dem Löschen von Ordnern zu beginnen, sondern anhand der Protokolle zunächst die Richtung zu erfassen: „Ladefehler“, „Kopierfehler“, „Zugriff verweigert“, „Pfad zu lang“, „kann nicht auf die Freigabe schreiben“ und Ähnliches.

Die drei Protokolle liegen an „unterschiedlichen Orten“

Das ist der Punkt, an dem man sich zunächst am ehesten verirrt, daher hier vorab die Übersicht. [10]

Das Diagnostic-Protokoll erscheint in dieser Form nicht im Baum. Aktivieren Sie in der Ereignisanzeige unter Aktionen > Ansicht > Analyse- und Debugprotokolle anzeigen die Anzeige, wählen Sie dann Diagnostic aus und führen Sie Protokoll aktivieren aus. Deaktivieren Sie es nach Abschluss der Untersuchung unbedingt wieder. Es handelt sich um ein sehr detailliertes Protokoll, das nicht dauerhaft aktiv bleiben sollte. [10]

Dasselbe sehen, ohne die GUI zu öffnen

Wenn Sie Reproduzierbarkeit brauchen oder ein Remote-Gerät untersuchen, ist es zuverlässiger, die Werte per Befehl abzurufen. Statt die Ereignisanzeige jemandem am Telefon zu erklären, ist es schneller, sagen zu können: „Führen Sie diesen Befehl aus und schicken Sie mir das Ergebnis.“

# 1) Nur die User-Profile-Service-Ereignisse aus dem Application-Protokoll, neueste zuerst
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
} -MaxEvents 50 | Select-Object TimeCreated, Id, LevelDisplayName, Message

# 2) Das Operational-Protokoll direkt einsehen
Get-WinEvent -LogName 'Microsoft-Windows-User Profile Service/Operational' -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message

# 3) Nur die Event-ID 1509 (verursacht durch zu lange Pfade) herausfiltern
Get-WinEvent -FilterHashtable @{
    LogName      = 'Application'
    ProviderName = 'Microsoft-Windows-User Profiles Service'
    Id           = 1509
} | Format-List TimeCreated, Id, Message

Hier lauert eine Falle: Der Quellname auf der Seite des Application-Protokolls lautet Microsoft-Windows-User Profiles Service (Profiles im Plural), der Kanalname des Operational-Protokolls dagegen Microsoft-Windows-User Profile Service/Operational (Profile im Singular). Wenn Copy & Paste nicht funktioniert, liegt es meist genau daran.

Event-ID 1509 erscheint nicht im Operational-Protokoll, sondern im Application-Protokoll. Die Stufe ist Warnung, und der Text besteht aus einer Meldung der Form „Windows kann die Datei \\Server\Freigabe\... nicht nach C:\Users\... kopieren“, gefolgt von DETAIL - The filename or extension is too long.. Diese letzte Zeile ist der entscheidende Hinweis darauf, dass die Pfadlänge die Ursache ist. [16]

Ein weiterer Punkt, der in der Praxis Zeit spart: Microsoft weist ausdrücklich darauf hin, dass die User-Profile-Service-Ereignis 1530 „Die Registrierungsdatei wird noch von einer anderen Anwendung oder einem anderen Dienst verwendet“ ignoriert werden kann. [10] Verfolgt man das weiter, läuft man ins Leere.

7.3 Häufige Ursachen

Attribute oder Berechtigungen von NTUSER.DAT / USRCLASS.DAT

Microsoft erklärt, dass das Laden eines Profils fehlschlagen kann, wenn NTUSER.DAT oder USRCLASS.DAT als schreibgeschützt markiert ist oder die nötigen Zugriffsrechte fehlen. [11]

Unscheinbar, aber übersieht man das, zieht sich die Untersuchung in die Länge.

flowchart LR
    A[Profil laden] --> B{Kann auf die DAT-Dateien zugegriffen werden}
    B -->|Nein| C[Anmeldefehler / Standard-Desktop / Temporary]
    B -->|Ja| D[Normales Laden]

Zu lange Pfade beim Roaming-Kopiervorgang

Eine Microsoft-KB beschreibt einen Fall, in dem Server- oder Freigabename auf der Freigabepfad-Seite so lang sind, dass der gesamte Zielpfad zu lang wird und der Benutzer zusammen mit Event-ID 1509 in ein temporäres Profil fällt. [16]

Was wie eine simple Einschränkung der Pfadlänge aussieht, kann also tatsächlich durch das Design des Roaming-Ziels selbst verursacht sein.

Durch unvollständige Löschung zurückgebliebene Registrierungs-/Ordnerinformationen

Microsoft hat einen Artikel mit Beispielskripten zum Bereinigen verwaister Informationen in der Registrierung und in C:\Users, um TEMP-Profile zu verhindern. [15]

Daraus wird deutlich: Das bloße Löschen des Ordners ist noch nicht das Ende.

flowchart LR
    A[Altes Profil grob löschen] --> B[Registrierungsinformationen bleiben zurück]
    B --> C[Inkonsistenz bei der nächsten Anmeldung]
    C --> D[Ursache für TEMP-Profile oder zusätzliche Ordner]

7.4 Was Sie zuerst prüfen sollten

8. Welchen Ansatz sollten Sie wählen?

Hier gibt es nicht „eine richtige Antwort“. Es hängt vom Einsatzszenario ab.

flowchart TD
    A[Einsatzszenario] --> B[Persönlich genutzter PC]
    A --> C[Domänengebundener Arbeits-PC]
    A --> D[Gemeinsam genutzter PC / Bildungsgerät]
    A --> E[RDS / VDI / AVD]

    B --> B1[Vorwiegend lokal]
    C --> C1[Folder Redirection / Roaming je nach Bedarf]
    D --> D1[Mandatory / Shared PC / Cleanup]
    E --> E1[FSLogix als erste Wahl]

8.1 Persönlich genutzte PCs

Ein lokales Profil reicht grundsätzlich aus.

• Benutzereinstellungen in AppData
• Arbeitsergebnisse in Documents
• Bei Bedarf Dokumentensynchronisierung über eine separate Ebene wie OneDrive

Diese Konfiguration ist die einfachste.

8.2 Domänengebundene Arbeits-PCs

Je nach Anforderung kombinieren Sie Folgendes.

• Dokumentdaten sollen zentral verwaltet werden → Folder Redirection
• Dieselben Einstellungen sollen auf mehreren PCs vorliegen → Roamingprofile
• Gemischte OS-Versionen oder sehr große Profile → sorgfältiges Design oder Überdenken des Ansatzes

Auch Microsoft Learn nennt zentrale Verwaltung, Offline-Verfügbarkeit und leichtere Backups als Vorteile von Folder Redirection und Roaming User Profiles. [4]

8.3 Gemeinsam genutzte PCs / Bildungsgeräte / Kioske

Für diese Einsatzzwecke zählt eher jedes Mal wieder ein sauberer Zustand als „persönliche Anpassungen erhalten“.

Es gibt drei Kandidaten.

• Mandatory-Profile
• Shared-PC-Modus
• Richtlinien zum automatischen Löschen alter Profile

Microsoft bietet die Richtlinie „Delete user profiles older than a specified number of days on system restart“, mit der Profile, die eine festgelegte Anzahl von Tagen nicht genutzt wurden, beim Neustart gelöscht werden können. [17]

Auch der Shared-PC-Leitfaden stellt einen Ansatz vor, der automatische Konto-/Profilverwaltung und -löschung auf gemeinsam genutzten Geräten kombiniert. [18]

8.4 RDS / VDI / Azure Virtual Desktop

Hier reichen klassische Roamingprofile allein häufig nicht aus.

Microsoft empfiehlt FSLogix-Profilcontainer für Azure Virtual Desktop und erklärt, dass eine VHDX / VHD bei der Anmeldung angehängt und wie ein natives Benutzerprofil behandelt wird. [14]

flowchart LR
    A[Mehrere Sitzungshosts] --> B[Gemeinsamer Speicher]
    B --> C[Benutzerprofil auf VHDX]
    C --> D[Wird an den verbundenen Host angehängt]

Besonders unter folgenden Bedingungen lohnt es sich, FSLogix vorrangig zu prüfen:

• Der Sitzungshost wechselt jedes Mal
• Outlook / OneDrive / Microsoft-365-Dienste werden genutzt
• Nicht-persistente VDI, bei der Profilportabilität zwingend ist
• Anmeldeverzögerungen durch Roamingprofile sind ein Problem

9. Häufige Missverständnisse

9.1 „Erstellt man ein Konto, wird überall dasselbe Profil verwendet“

Das stimmt nicht. Das Konto ist ein Bezeichner, das Profil ist die geräteseitige Substanz. Wie weit es mitgenommen wird, hängt vom gewählten Ansatz ab: lokal, Roaming, Folder Redirection, FSLogix und so weiter. [4][14]

9.2 „Kopiert man C:\Users\Benutzername, ist die Migration erledigt“

Eine grobe Kopie ist gefährlich, und zwar wegen:

• OS-Versionskompatibilität
• NTUSER.DAT
• Berechtigungen
• anwendungsspezifischem Zustand
• Vermischung mit dem Standardprofil

Besonders bei Roaming über OS-Generationen hinweg geht auch Microsoft von einer Trennung der Profilversionen aus. [6]

9.3 „Mandatory und Temporary sind ungefähr dasselbe“

Diese beiden sind völlig verschiedene Dinge. Mandatory ist ein schreibgeschütztes Profil, das ein Administrator bewusst erstellt; Temporary ist die Ausweichlösung, wenn das eigentliche Profil wegen eines Fehlers nicht gelesen werden kann. [8][9]

9.4 „Für die Synchronisierung reicht es, einfach alles nach Roaming zu legen“

Das ist riskant. Legt man Einstellungen und riesige Caches in dieselbe Kiste, werden An-/Abmeldung sowie die Behandlung von Störungen schwerfällig. Es ist betrieblich einfacher, was roamen soll von was lokal bleiben sollte zu trennen. [2][3]

9.5 „Landet man auf einem temporären Profil, kann man es einfach so weiter benutzen“

Besser vermeiden. Ein Temporary Profile ist darauf ausgelegt, bei der Abmeldung zu verschwinden. Arbeitet man in diesem Zustand weiter, riskiert man, wichtige Daten an einem Ort abzulegen, der später verschwindet. [9]

10. Zusammenfassung

Ein Windows-Benutzerprofil ist nicht einfach eine Bezeichnung für die Ordner unter C:\Users.

• Die Dateien
• Die Benutzerregistrierung, deren Kern NTUSER.DAT bildet
• Der Betriebsansatz: wo das Profil liegt, wie es synchronisiert wird und wie es gelöscht wird

Betrachtet man all das als einen einzigen Entwurf, wird der Überblick deutlich klarer.

In der Praxis lohnt es sich, diese sechs Punkte vorab festzuhalten:

• Bei einem einzelnen PC zunächst das lokale Profil als Grundlage nehmen
• Den Speicherort von Anwendungen zwischen Roaming / Local / ProgramData aufteilen
• In Domänenumgebungen Roamingprofil und Folder Redirection nicht verwechseln
• Bei gemeinsam genutzten Geräten Mandatory / Cleanup / Shared PC in Betracht ziehen
• Bei RDS / VDI / AVD FSLogix an die erste Stelle der Kandidaten setzen
• Im Fehlerfall zuerst die Protokolle des User Profile Service ansehen

Am Ende ist Profildesign keine Frage von „wo speichern“, sondern des Entwurfs, „wem was gehört und wie weit es mitgenommen wird“. Ist das geklärt, werden Geräteverteilung, Windows-App-Design und Fehlersuche erheblich einfacher.

11. Verwandte Artikel

• Wann braucht Windows wirklich Administratorrechte? - UAC, geschützte Bereiche und wie man es am Design erkennt
• Wie Windows Sandbox die Verifikation bei der Windows-App-Entwicklung beschleunigt

12. Zu diesem Thema passende Leistungen

Windows-Anwendungsentwicklung

Wie Sie Speicherorte für Benutzereinstellungen, Protokolle, Caches und gemeinsam genutzte Daten aufteilen, beeinflusst Betriebsfähigkeit und Wartbarkeit einer Windows-Anwendung erheblich. Wer von der Anforderungsanalyse über Design und Implementierung bis zum langfristigen Betrieb alles im Blick haben möchte, findet in der Windows-Anwendungsentwicklung den passenden Rahmen für dieses Thema.

Zur Leistung / Kontakt

Technische Beratung und Design-Review

Ob man sich für lokal / Roaming / FSLogix entscheidet, wie man den Betrieb bestehender Geräte ändert und wie man Speicherorte abgrenzt, macht einen großen Unterschied, wenn es vor der Implementierung geklärt wird. Wer die Auswahl des Ansatzes und das Grenzdesign von Grund auf klären möchte, kann dieses Thema gut als technische Beratung bzw. Design-Review herauslösen.

Zur Leistung / Kontakt

Fehleruntersuchung und Ursachenanalyse

Das Eingrenzen von Ausweichen auf ein Temporary-Profil, Anmeldefehlern, Speicherfehlern bei der Abmeldung und Problemen rund um Freigabepfade passt sehr gut zur Fehleruntersuchung. Das ist ein guter Einstiegspunkt für eine Beratung, wenn Sie schwer reproduzierbare Profilprobleme anhand von Protokollen, Ereignissen, Berechtigungen und Freigabekonfiguration aufklären möchten.

Zur Leistung / Kontakt

13. Quellen

Da es viele Quellen gibt, hier vorab ein nach Fragestellung durchsuchbarer Index.

1. Microsoft Learn, About User Profiles (Windows) Bestandteile eines Benutzerprofils, NTUSER.DAT, Grundlagen des Temporary Profile.

2. Microsoft Learn, Fast User Switching Empfehlung, für anwendungsspezifische Daten FOLDERID_RoamingAppData und für Daten, die auf keinem anderen Computer verwendet werden, FOLDERID_LocalAppData zu nutzen.

3. Microsoft Learn, KNOWNFOLDERID, CSIDL Definition der bekannten Ordner wie %APPDATA%, %LOCALAPPDATA%, LocalLow und ProgramData.

4. Microsoft Learn, Folder Redirection and Roaming User Profiles in Windows and Windows Server Unterschied zwischen Folder Redirection und Roaming User Profiles, Prinzip der zentralen Verwaltung.

5. Microsoft Learn, Deploy roaming user profiles Praktische Schritte zur Bereitstellung von Roamingprofilen: Freigabeberechtigungen, GPO, Versionierung.

6. Microsoft Learn, Roaming user profiles of earlier versions of Windows are incompatible with Windows 10, Windows Server 2016, and later versions Inkompatibilität zwischen OS-Generationen und Profilversionierung.

7. Microsoft Learn, Create mandatory user profiles Zweck und Erstellung von Mandatory User Profiles.

8. Microsoft Learn, Mandatory User Profiles Definition von NTUSER.MAN und Super-Mandatory Profile.

9. Microsoft Learn, Temporary User Profiles Definition und Eigenschaften von Temporary Profiles.

10. Microsoft Learn, Troubleshoot user profiles with events Eingrenzung anhand des Application-, Operational- und Diagnostic-Protokolls.

11. Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable when you log on to Windows for the first time Neuerstellung eines Profils ausgehend von C:\Users\Default, Attribut-/Berechtigungsprobleme bei NTUSER.DAT / USRCLASS.DAT.

12. Microsoft Learn, Customize the default local user profile when you prepare an image of Windows Die unterstützte Methode zur Anpassung des Standardprofils mit CopyProfile.

13. Microsoft Learn, What is FSLogix, Types of Containers Grundlagen von FSLogix, Konzept des Profile Container.

14. Microsoft Learn, User profile management for Azure Virtual Desktop with FSLogix profile containers, Configure profile containers using FSLogix Empfehlung für Azure Virtual Desktop, Profilcontainer-Ansatz auf Basis von VHD / VHDX.

15. Microsoft Learn, Scripts: Clean up profile folder information and prevent TEMP user profiles from being created Zusammenhang zwischen verwaisten Profilinformationen und TEMP-Profilen.

16. Microsoft Learn, User profile cannot be loaded with Event ID 1509: DETAIL - The filename or extension is too long Das Problem zu langer Pfade beim Speichern von Roamingprofilen.

17. Microsoft Learn, ADMX_UserProfiles Policy CSP Richtliniendefinitionen einschließlich „Delete user profiles older than a specified number of days on system restart“.

18. Microsoft Learn, Configure a shared or guest Windows device Shared-PC-Modus und Konto-/Profilverwaltung für gemeinsam genutzte Geräte.

19. Microsoft Learn, Designing Applications to Run at a Low Integrity Level Dazu, dass %USERPROFILE%\AppData\LocalLow und HKEY_CURRENT_USER\Software\AppDataLow als Orte bereitstehen, in die Prozesse mit niedriger Integritätsstufe schreiben können.

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist NTUSER.DAT?

NTUSER.DAT ist die Datei, die den Benutzer-Registrierungshive im Windows-Benutzerprofil bildet. Sie liegt direkt unter C:\Users\Benutzername, wird bei der Anmeldung geladen und als HKEY_CURRENT_USER (HKCU) verwendet. Ein Benutzerprofil besteht also aus zwei Schichten: den Dateien wie Desktop und AppData sowie der Registrierungsebene, deren Kern NTUSER.DAT bildet. Ist NTUSER.DAT als schreibgeschützt markiert oder fehlen die nötigen Zugriffsrechte, schlägt das Laden des Profils fehl - das kann zu einer fehlgeschlagenen Anmeldung oder einem temporären Profil führen.

Was ist ein Windows-Benutzerprofil? Ist das nicht dasselbe wie ein Konto?

Das Konto identifiziert, wer sich anmeldet; das Benutzerprofil ist die eigentliche Arbeitsumgebung dieser Person. Ein Profil ist nicht einfach der Ordner C:\Users\Benutzername, sondern die Kombination aus Dateien wie Desktop, Documents und AppData sowie dem Benutzer-Registrierungshive NTUSER.DAT. Meldet sich ein neuer Benutzer zum ersten Mal an, wird ein neues Profil auf Basis von C:\Users\Default erstellt. Wie weit die Einstellungen mitgenommen werden, entscheidet die gewählte Methode: lokal, Roaming, Folder Redirection oder FSLogix.

Wie unterscheide ich %APPDATA% und %LOCALAPPDATA% richtig?

Einstellungen, die pro Benutzer mitgenommen werden sollen, gehören grundsätzlich nach %APPDATA% (AppData\Roaming); Caches oder vorübergehende Zustände, die nur für diesen PC gelten, gehören nach %LOCALAPPDATA% (AppData\Local). Regenerierbare Caches oder große Arbeitsdateien im Roaming-Bereich machen An- und Abmeldung tendenziell langsam, daher gehören sie nach Local. Für veränderliche Daten, die für alle Benutzer gelten, kommt ProgramData infrage - allerdings muss dabei das ACL-Design mitgedacht werden, also wer lesen und schreiben darf. Benutzerbezogene Laufzeitdaten sollten keinesfalls in Program Files abgelegt werden.

Was tue ich, wenn sich jemand mit einem temporären Profil (Temporary Profile) anmeldet?

Ein Temporary Profile ist eine Notlösung, die ausgegeben wird, wenn das eigentliche Profil wegen eines Fehlers nicht geladen werden kann; es wird bei der Abmeldung gelöscht, und alle Änderungen gehen verloren. Arbeitet man einfach damit weiter, riskiert man den Verlust wichtiger Daten - dieser Zustand sollte vermieden werden. Bei der Untersuchung sollte man nicht sofort in C:\Users herumstochern, sondern zuerst das Application-Protokoll und das Operational-Protokoll des User Profile Service prüfen, bei Bedarf auch das Diagnostic-Protokoll. Häufige Ursachen sind Attribut- oder Berechtigungsprobleme bei NTUSER.DAT / USRCLASS.DAT, ein zu langer Roaming-Zielpfad sowie Registrierungsreste einer unvollständigen Löschung.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.