FSLogix: Profilcontainer für RDS und VDI richtig planen und betreiben

Warum FSLogix die alten Bordmittel abgelöst hat

Wer schon mal einen Windows-Terminalserver mit klassischen Roaming Profiles oder User Profile Disks (UPD) betrieben hat, kennt die Symptome: Anmeldezeiten von mehreren Minuten, korrupte NTUSER.DAT nach einem Absturz, Outlook-Suchindizes die bei jedem Login neu aufgebaut werden, und Profile die bei parallelen Sessions auf zwei Servern munter gegeneinander schreiben. FSLogix wurde 2012 von der gleichnamigen Firma entwickelt und 2018 von Microsoft aufgekauft. Seither ist es fixer Bestandteil der RDS-Lizenzierung und liegt praktisch jedem Windows Server- und Azure-Virtual-Desktop-Deployment zugrunde, das heute produktiv läuft.

Der Kerntrick: FSLogix virtualisiert das komplette Benutzerprofil in eine einzelne VHD- oder VHDX-Datei, die auf einer zentralen SMB-Freigabe liegt. Beim Login mountet ein Filter-Treiber (frxdrv.sys) diese Datei transparent als virtuelle Festplatte und blendet sie über Reparse Points so ein, dass Windows glaubt, das Profil liege lokal unter C:\Users. Das Betriebssystem merkt nichts davon, aber physisch liegen alle Daten zentral - und weil nur eine einzige Datei kopiert, gesperrt und synchronisiert werden muss statt tausender Einzeldateien, sind Anmeldezeiten und I/O-Muster fundamental anders als bei klassischem Profil-Roaming.

Architektur: Was beim Login wirklich passiert

Der Ablauf in Kurzform:

1. Der FSLogix-Dienst (frxsvc) startet beim Boot des Session-Hosts und meldet den Filtertreiber am Windows-Filtersystem an.
2. Beim interaktiven Login prüft der Treiber die Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles, ob für den Benutzer ein Profile Container aktiv ist.
3. FSLogix sucht auf der konfigurierten Freigabe (VHDLocations) nach einem Ordner im Muster Profil_SID_Benutzername beziehungsweise Benutzername_SID (abhängig von FlipFlopProfileDirectoryName).
4. Existiert die VHDX-Datei bereits, wird sie über SMB gemountet und exklusiv gesperrt (Locked-Exclusive-Modus als Standard).
5. Existiert sie nicht, wird sie aus einer VHDX-Vorlage neu angelegt, formatiert und mit NTUSER.DAT sowie den Standardordnern befüllt.
6. Windows startet den Login-Prozess mit dem Profilpfad, der jetzt auf die gemountete virtuelle Disk zeigt - für Anwendungen unsichtbar.
7. Beim Logout wird das Dateisystem sauber ausgehängt (Unmount), sofern keine Prozesse mehr Handles auf Dateien im Container halten.

Genau der letzte Punkt ist die häufigste Ursache für “hängende” Container: Prozesse, die auch nach dem Logoff noch Handles offen halten (Virenscanner, Backup-Agenten, Outlook-Suchindex, manchmal auch fehlerhafte Drittsoftware), verhindern den sauberen Unmount und damit die Freigabe der exklusiven Sperre für die nächste Session.

Profile Container vs. Roaming Profiles vs. UPD

Installation und Grundkonfiguration

Das FSLogix-Setup wird direkt von Microsoft bezogen (aktuell als eigenständiges Paket sowie automatisch in aktuellen AVD-Session-Host-Images enthalten). Auf einem klassischen RDS-Session-Host installierst du es so:

# FSLogix Agent auf einem RDS Session Host installieren (x64)
Start-Process msiexec.exe -ArgumentList "/i FSLogixAppsSetup.exe /quiet /norestart" -Wait

# Dienst und Treiber prüfen
Get-Service frxsvc, frxccds
fltmc filters | Select-String "frxdrv"

Die Konfiguration erfolgt primär über die Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Profiles - am saubersten per GPO mit den offiziellen FSLogix-ADMX-Vorlagen (fslogix.admx/adml, liegen dem Setup-Paket bei):

# Kernparameter für Profile Container setzen (lokal testen, produktiv via GPO)
$key = "HKLM:\SOFTWARE\FSLogix\Profiles"
New-Item -Path $key -Force | Out-Null
New-ItemProperty -Path $key -Name "Enabled" -PropertyType DWord -Value 1
New-ItemProperty -Path $key -Name "VHDLocations" -PropertyType MultiString -Value "\\fs01\FSLogixProfiles$"
New-ItemProperty -Path $key -Name "VolumeType" -PropertyType String -Value "VHDX"
New-ItemProperty -Path $key -Name "SizeInMBs" -PropertyType DWord -Value 20000
New-ItemProperty -Path $key -Name "IsDynamic" -PropertyType DWord -Value 1
New-ItemProperty -Path $key -Name "FlipFlopProfileDirectoryName" -PropertyType DWord -Value 1
New-ItemProperty -Path $key -Name "DeleteLocalProfileWhenVHDShouldApply" -PropertyType DWord -Value 1
New-ItemProperty -Path $key -Name "ReAttachIntervalSeconds" -PropertyType DWord -Value 15
New-ItemProperty -Path $key -Name "ReAttachRetryCount" -PropertyType DWord -Value 3

Die wichtigsten Parameter im Überblick:

Office-Container (ODFC): Sinn und Grenzen

ODFC (Office 365 Container, historisch “Office Dynamic File Container”) legt Outlook-OST-Dateien, den Suchindex, Teams-Cache und OneDrive-Zustand in einen zweiten, separaten VHDX-Container - unabhängig vom eigentlichen Profil Container. Ursprünglich war das wichtig, weil ältere FSLogix-Versionen mit sehr grossen kombinierten Containern Probleme hatten und weil manche Szenarien (z. B. ein Benutzer mit Zugriff auf mehrere Session-Host-Pools gleichzeitig) getrennte Sperr-Granularität brauchten.

Microsofts aktuelle Empfehlung: Für die meisten Umgebungen reicht der Profile Container allein, ODFC ist nicht mehr zwingend nötig. Aktiviere ODFC gezielt, wenn:

• Postfächer sehr gross sind (mehrere GB OST) und du den Profile Container klein halten willst
• Benutzer regelmässig auf mehreren Host-Pools gleichzeitig aktiv sind und getrennte Sperrlogik für Office-Daten sinnvoll ist
• Ihr Outlook im Cached-Exchange-Modus mit grossen Postfächern betreibt und Neuindizierung nach jedem Login unbedingt vermeiden wollt, aber den Hauptcontainer schlank halten möchtet

# ODFC aktivieren (separater Registry-Pfad)
$odfc = "HKLM:\SOFTWARE\FSLogix\ODFC"
New-Item -Path $odfc -Force | Out-Null
New-ItemProperty -Path $odfc -Name "Enabled" -PropertyType DWord -Value 1
New-ItemProperty -Path $odfc -Name "VHDLocations" -PropertyType MultiString -Value "\\fs01\FSLogixODFC$"
New-ItemProperty -Path $odfc -Name "IncludeTeams" -PropertyType DWord -Value 1
New-ItemProperty -Path $odfc -Name "IncludeOneDrive" -PropertyType DWord -Value 1

Für ein typisches Schweizer KMU mit 20-150 RDS-Benutzern und einem einzigen Session-Host-Pool ist ein kombinierter Profile Container ohne separaten ODFC meist die pragmatischere Wahl: weniger bewegliche Teile, weniger Freigaben zu pflegen, weniger potenzielle Fehlerquellen. ODFC lohnt sich erst bei komplexeren Multi-Pool-Szenarien.

Storage-Anforderungen und IOPS-Planung

FSLogix-Container erzeugen ein untypisches I/O-Muster: viele kleine, zufällige Schreib-/Lesevorgänge (Random I/O), konzentriert auf die Login- und Logout-Phasen. Realistische Richtwerte für die Planung:

Für die Storage-Wahl gilt in der Praxis:

• Windows-Server-Freigabe (SMB) auf SSD/NVMe: günstigste Lösung für KMU, funktioniert gut bis mittlere dreistellige Nutzerzahlen, solange RAID und Netzwerkanbindung (mindestens 1 GbE, besser 10 GbE) stimmen.
• Azure Files (Standard): bis ca. 20’000 IOPS pro Freigabe, ausreichend für rund 400 gleichzeitige Nutzer als grobe Faustregel.
• Azure Files (Premium) / Azure NetApp Files: für grössere oder latenzsensitive Deployments, deutlich höhere IOPS-Obergrenzen.
• NAS-Systeme mit SMB 3.0+: möglich, aber prüfe explizit SMB-Multichannel- und Signierungs-Unterstützung sowie Latenz - viele günstige NAS-Geräte sind für Random-I/O-Lasten mit vielen kleinen Operationen nicht ausgelegt.

Für Sizing-Tests eignet sich DiskSpd direkt gegen die geplante Freigabe:

# Realistisches Random-I/O-Profil gegen die FSLogix-Freigabe testen
.\diskspd.exe -c2G -b4K -r -w30 -t4 -o8 -d60 -Sh `
  \\fs01\FSLogixProfiles$\testfile.dat

Berechtigungen auf der Freigabe korrekt setzen

Ein häufiger Fehler: zu grosszügige oder zu restriktive NTFS-Rechte auf dem Freigabe-Root. Microsofts empfohlenes Modell:

# Freigabe anlegen
New-Item -Path "D:\FSLogixProfiles" -ItemType Directory
New-SmbShare -Name "FSLogixProfiles$" -Path "D:\FSLogixProfiles" `
  -FullAccess "DOMAIN\RDS-SessionHosts$", "DOMAIN\Domain Admins"

# NTFS-Rechte: Benutzer nur "Ändern", kein "Vollzugriff" auf das Root
icacls "D:\FSLogixProfiles" /inheritance:r
icacls "D:\FSLogixProfiles" /grant "DOMAIN\Domain Admins:(OI)(CI)F"
icacls "D:\FSLogixProfiles" /grant "DOMAIN\FSLogix-Users:(OI)(CI)M"
icacls "D:\FSLogixProfiles" /grant "CREATOR OWNER:(OI)(CI)(IO)F"
icacls "D:\FSLogixProfiles" /grant "SYSTEM:(OI)(CI)F"
icacls "D:\FSLogixProfiles" /remove "Authenticated Users" "Users"

Die Logik dahinter: Benutzer brauchen “Ändern” auf dem Root, um ihren eigenen Unterordner anzulegen, aber via CREATOR OWNER erhält jeder Benutzer anschliessend Vollzugriff nur auf seinen eigenen Profilordner - nicht auf die Container der Kollegen.

Troubleshooting: Gesperrte und hängende Container

Der Klassiker im Support-Alltag: “Mein Profil lädt nicht, ich sehe ein temporäres Profil.” Systematisches Vorgehen:

1. Logs prüfen. FSLogix schreibt detaillierte Logs unter C:\ProgramData\FSLogix\Logs\Profile. Suche nach “[ERROR” für die erste Fehlermeldung mit Fehlercode.

Get-ChildItem "C:\ProgramData\FSLogix\Logs\Profile" | Sort-Object LastWriteTime -Descending | Select-Object -First 1 |
  Get-Content | Select-String "\[ERROR"

2. Prüfen, ob der Container anderswo noch gemountet ist. Der häufigste Fall: Der Benutzer hat noch eine getrennte (disconnected) Session auf einem anderen Host im selben Pool, die die exklusive Sperre hält.

# Auf dem Verdachts-Host offene Sessions des Benutzers prüfen
query user /server:rdsh02

# Auf dem Dateiserver offene Handles auf die VHDX finden
Get-SmbOpenFile | Where-Object Path -like "*max.muster*" | Format-Table ClientComputerName, Path

3. Verwaiste Session sauber beenden, statt den Handle brachial zu killen:

# Getrennte Session auf dem anderen Host beenden
logoff <SessionID> /server:rdsh02

4. Wenn kein aktiver Prozess mehr zugreift, aber die Sperre bleibt (z. B. nach einem Host-Absturz), das Handle auf dem Dateiserver gezielt schliessen:

Get-SmbOpenFile | Where-Object Path -like "*max.muster*" | Close-SmbOpenFile -Force

5. VHDX-Integrität prüfen, falls der Container nach dem Freigeben der Sperre immer noch nicht mountet (Verdacht auf Beschädigung nach unsauberem Trennen):

# VHDX temporär manuell mounten und mit CHKDSK prüfen
$vhd = Mount-VHD -Path "\\fs01\FSLogixProfiles$\max.muster_S-1-5-21-...\Profile_max.muster.vhdx" -Passthru
$disk = Get-Disk -Number $vhd.DiskNumber
$partition = Get-Partition -DiskNumber $disk.Number | Where-Object Type -eq "Basic"
chkdsk "$($partition.DriveLetter):" /f
Dismount-VHD -Path $vhd.Path

6. Fehlercodes nachschlagen. FSLogix liefert klare numerische Fehlercodes (z. B. 0x00000032 für “nicht unterstützt”, diverse STATUS_-Codes für Locking-Konflikte) in der offiziellen Codetabelle - hilfreich, um zwischen Sperr-, Berechtigungs- und Netzwerkproblemen zu unterscheiden.

Antivirus-Ausnahmen und weitere Fallstricke

Virenscanner, die VHDX-Dateien während des Mount-Vorgangs scannen, sind eine der häufigsten Ursachen für langsame Logins und sporadische Sperr-Timeouts. Microsoft empfiehlt feste Ausschlüsse für:

; Pfad-Ausschlüsse (Beispiel Windows Defender)
%ProgramFiles%\FSLogix\Apps\frxdrv.sys
%ProgramFiles%\FSLogix\Apps\frxdrvvt.sys
%ProgramFiles%\FSLogix\Apps\frxccd.sys
%TEMP%\*.VHD
%TEMP%\*.VHDX
\\fs01\FSLogixProfiles$\*\*.VHD
\\fs01\FSLogixProfiles$\*\*.VHDX

; Prozess-Ausschlüsse
%ProgramFiles%\FSLogix\Apps\frxsvc.exe
%ProgramFiles%\FSLogix\Apps\frxccds.exe
%ProgramFiles%\FSLogix\Apps\frxrobocopy.exe

Weitere Praxisfallen, die immer wieder auftauchen:

• Zu kleine SizeInMBs bei Umstellung von grossen Bestandsprofilen: Der erste Login nach der Migration schlägt fehl, weil das Bestandsprofil grösser ist als der neue Container. Vor Rollout Profilgrössen der Bestandsbenutzer erheben.
• RDS-Benutzerprofilpfad in Active Directory noch gesetzt: Wenn im AD-Benutzerkonto unter dem Reiter “Umgebung”/“Terminaldiensteprofil” noch ein Roaming-Profilpfad hinterlegt ist, kollidiert das mit FSLogix. Diesen Pfad vor der Umstellung leeren.
• Mehrere gleichzeitige Sitzungen auf verschiedenen Collections/Pools: Ohne Cloud Cache oder sauberes Session-Handling führt das garantiert zu Sperrkonflikten. Nutzer-zu-Pool-Zuordnung sauber planen.
• Falsche Zeitzone/Uhrzeit-Drift zwischen Session-Hosts und Dateiserver: Kerberos-Ticket-Fehler äussern sich bei FSLogix oft fälschlich wie ein Speicherproblem.

Cloud Cache für Hochverfügbarkeit

Für Szenarien mit mehreren Standorten oder hohen Verfügbarkeitsanforderungen bietet FSLogix Cloud Cache: Statt eines einzelnen VHDX-Speicherorts schreibt FSLogix synchron auf mehrere, redundante Storage-Ziele (z. B. zwei unabhängige Dateiserver an unterschiedlichen Standorten). Für die meisten Schweizer KMU mit einem Standort und einem gut gespiegelten/geclusterten Dateiserver (siehe Failover-Cluster-Konzepte) ist der Zusatzaufwand von Cloud Cache selten gerechtfertigt - es lohnt sich primär bei Multi-Site-Betrieb oder wenn Storage-Ausfallsicherheit nicht anders lösbar ist.

Praxis-Szenario: Rollout in einem 60-Personen-KMU

Typischer Ablauf für die Einführung bei einem Schweizer KMU mit einer RDS-Farm aus zwei Session-Hosts:

1. Bestandsprofile analysieren (Grösse, Sonderfälle wie sehr grosse PST/OST-Dateien lokal statt im Postfach).
2. Dedizierte Freigabe auf dem vorhandenen Dateiserver mit SSD-Storage anlegen, Berechtigungen wie oben gezeigt setzen.
3. FSLogix-Agent per Softwareverteilung (z. B. über Intune oder klassisches GPO-Softwareinstallations-Paket) auf beide Session-Hosts ausrollen.
4. GPO mit den Kernparametern (Profile Container aktiv, VHDLocations, SizeInMBs, DeleteLocalProfileWhenVHDShouldApply) auf die Session-Host-OU anwenden.
5. AV-Ausnahmen zentral über die Endpoint-Security-Konsole verteilen.
6. Pilotgruppe von 5 Benutzern für eine Woche testen, insbesondere Login-Zeiten und Outlook-Verhalten beobachten.
7. Rollout auf alle Benutzer ausserhalb der Kernarbeitszeit, mit Rollback-Plan (GPO deaktivieren, alte Profile bleiben als Fallback erhalten, solange DeleteLocalProfileWhenVHDShouldApply erst nach erfolgreichem Test aktiviert wird).
8. Monitoring der Freigabe (Speicherplatz, IOPS, offene Handles) in die bestehende Serverüberwachung aufnehmen.

Beobachte in der Pilotphase die tatsächliche Containergrösse mit Get-ChildItem *.vhdx | Select Name, Length. Viele KMU-Deployments starten mit 30 GB Maximalgrösse, obwohl 90 % der Benutzer nie über 5 GB hinauskommen - das beeinflusst zwar nicht den Storage-Verbrauch (dynamische VHDX), wohl aber, wie viel “Luft” bei Wachstum bleibt.

Weiterlernen

• Configure profile containers – Microsoft Learn
• Configuration Settings Reference – Microsoft Learn
• Configure ODFC containers – Microsoft Learn
• Container storage options – Microsoft Learn
• FSLogix Codes and what they mean – Microsoft Learn
• High Availability mit Cloud Cache – Microsoft Learn

Verwandte Themen im Wiki: Terminalserver und RDS im Support-Alltag, Windows-Server-Freigaben einrichten, GPOs planen und verwalten, Benutzer und Gruppen in Active Directory, Monitoring-Grundlagen für Server und Dienste.

Videos

YouTube