Profile: der Zustand, der den Host überleben muss

Wenn die Anbindung des Profils scheitert, meldet sich der Nutzer trotzdem an — mit einem temporären Profil. Er arbeitet einen Tag lang, und beim Abmelden ist alles weg. Keine Fehlermeldung, kein Hinweis. Das ist kein Defekt, sondern die dokumentierte Voreinstellung: PreventLoginWithTempProfile steht auf 0. Dieses Modul behandelt den Profilcontainer als das, was er ist — eine VHD-Datei auf einer Freigabe, mit dokumentierten Standardwerten, die man kennen muss: warum die Installation von FSLogix allein gar nichts bewirkt, warum SizeInMBs eine Einbahnstraße ist, warum das Umstellen der Ordnernamenskonvention wie ein vollständiger Datenverlust aussieht, wie lange eine Sperre ausgesessen wird — und warum Cloud Cache beim gleichzeitigen Ausfall aller Anbieter schlimmer ist als gar kein Cloud Cache.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-12

Das temporäre Profil ist kein Fehler, sondern die Voreinstellung

Ein gepoolter Host Pool tauscht Maschinen aus. Damit ein Mensch trotzdem jeden Morgen seine Umgebung vorfindet, muss der Nutzerzustand woanders liegen als auf der Maschine. Das ist die Aufgabe von FSLogix.

Der unangenehme Teil dieses Moduls kommt gleich zu Beginn: Wenn die Anbindung des Profils scheitert, meldet sich der Nutzer trotzdem an — mit einem temporären Profil. Er arbeitet einen Tag lang, und beim Abmelden ist alles weg. Niemand hat eine Fehlermeldung gesehen. Das ist kein Defekt, sondern das dokumentierte Standardverhalten, und es lässt sich abschalten.

LernzielDu kannst einen Profilcontainer nach Ablageort, Größe und Benennung auslegen, das Verhalten bei Sperre und Ausfall bewusst konfigurieren und benennen, welche Daten ein Container aus gutem Grund nicht enthält.

Profilcontainer — Eine virtuelle Festplattendatei — VHD oder VHDX — die den Inhalt des Benutzerprofils trägt. Was üblicherweise unter C:\Users\%username% liegt, steckt fast vollständig in dieser einen Datei; sie wird bei der Anmeldung von einer SMB-Freigabe eingebunden.

Installieren allein bewirkt nichts

Der erste Stolperstein liegt vor jeder Konfiguration. Die Dokumentation ist hier ungewöhnlich deutlich: Die Installation legt eine Grundstruktur von Registry-Schlüsseln an, aber keinen einzigen Konfigurationswert. Jede Einstellung mit dokumentiertem Standardwert gilt, ohne dass sie existiert.

HKLM\SOFTWARE\FSLogix\Profiles: Ort der Profileinstellungen. Wird bei der Installation angelegt — leer.
Enabled: Pflichteinstellung, DWORD, Standardwert 0. Profilcontainer sind damit aus.
VHDLocations: Pflichteinstellung. Liste von SMB-Orten, an denen der Container gesucht wird.

Die Folge im BetriebEin Session Host mit installiertem FSLogix und ohne gesetzte Werte verhält sich exakt wie ein Host ohne FSLogix: Jeder Nutzer bekommt ein lokales Profil auf der Betriebssystemplatte, das beim nächsten Hostwechsel zurückbleibt. Die Installation ist im Monitoring sichtbar, die fehlende Konfiguration nicht.

Wo der Container liegt und wie er heißt

Nutzer meldet sich an→FSLogix sucht in den VHDLocations→Treffer über das Namensmuster→Container wird eingebunden→Profil steht

Suchen, nicht wissen

VHDLocations ist eine Liste von SMB-Orten. Wird kein Container gefunden, legt FSLogix einen im ersten Eintrag der Liste an — existiert der Pfad nicht, wird er zuvor erzeugt. Als REG_SZ werden mehrere Orte mit Semikolon getrennt, alternativ dient ein MULTI_SZ.

VHDNameMatch bestimmt, wonach gesucht wird; der Standardwert ist Profile*.
FlipFlopProfileDirectoryName bestimmt die Form des Ordnernamens: 0 erzeugt %sid%_%username%, 1 erzeugt %username%_%sid%.
VolumeType legt den Typ neuer Dateien fest — der Standardwert ist vhd, nicht vhdx.

Die Änderung, die Profile scheinbar löschtFlipFlopProfileDirectoryName nachträglich umzustellen, ist einer der teuersten Einzelklicks in diesem Umfeld. Die Dokumentation warnt ausdrücklich: FSLogix sucht danach nach einer anderen Namenskonvention, findet nichts — und legt ein neues Profilverzeichnis samt Container an. Die Daten sind nicht verloren, sie liegen im alten Ordner. Für die Nutzer sieht es aus wie ein vollständiger Datenverlust, und die Rückkehr verlangt entweder das Zurückstellen der Einstellung oder das manuelle Verschieben jedes einzelnen Containers.

Größe: wächst automatisch, schrumpft nie

SizeInMBs legt die Maximalgröße des Containers fest. Der Standardwert ist 30000, also rund 30 GB. Neue Container entstehen in dieser Größe, und bestehende werden bei der Anmeldung automatisch auf diesen Wert erweitert.

EinbahnstraßeDer Wert lässt sich jederzeit erhöhen, aber nicht verringern. Eine Absenkung führt nicht dazu, dass bestehende Container schrumpfen — sie bleiben, wie sie sind. Wer die Größe zu großzügig ansetzt und später umschwenkt, hat die Entscheidung für den vorhandenen Bestand bereits getroffen.

Zu bedenken ist der Unterschied zwischen vorgesehener und belegter Größe: Die Datei wächst dynamisch mit ihrem Inhalt. Für die Kapazitätsplanung der Freigabe zählt trotzdem beides — die tatsächliche Belegung heute und die Obergrenze, die jeder Container erreichen darf.

Kurzcheck

Eine Umgebung wurde mit SizeInMBs auf 100000 ausgerollt. Nach drei Monaten stellt sich heraus, dass 20 GB je Nutzer genügt hätten. Was bewirkt eine Absenkung auf 20000?

Für bestehende Container nichts — sie behalten ihre Obergrenze.
Bestehende Container werden bei der nächsten Anmeldung verkleinert.
Nutzer mit mehr als 20 GB Belegung können sich nicht mehr anmelden.
Die Container werden beim nächsten Start auf 20 GB abgeschnitten.

Treffer. Richtig. Eine Absenkung lässt bestehende Container unverändert. Nur neu erzeugte entstehen mit dem kleineren Wert.

Was passiert, wenn es schiefgeht

Hier liegt der Befund, der ganze Umgebungen still beschädigt. Zwei Einstellungen steuern, ob ein Fehler sichtbar wird — und beide stehen standardmäßig auf 0, also auf unsichtbar.

PreventLoginWithFailure: Bei 1 lädt FSLogix die FRXShell, wenn das Einbinden eines vorhandenen Containers scheitert. Der Nutzer erhält die Aufforderung, den Support zu rufen; seine einzige Option ist das Abmelden.
PreventLoginWithTempProfile: Bei 1 lädt FSLogix die FRXShell, sobald ein temporäres Profil entstanden ist. Gleiches Bild: Support rufen, abmelden.
Standardwert 0: Die Anmeldung läuft durch. Der Nutzer arbeitet in einem temporären Profil — und verliert beim Abmelden alles, was er darin getan hat.

Warum die Voreinstellung trotzdem einen Sinn hatWer beide Werte auf 1 setzt, tauscht stillen Datenverlust gegen laute Arbeitsunfähigkeit. Bei einer Störung des Profilspeichers kann sich dann niemand mehr sinnvoll anmelden — statt dass ein Teil der Belegschaft wenigstens eingeschränkt weiterarbeitet. Das ist eine bewusste Abwägung und keine reine Verbesserung. Die meisten Organisationen entscheiden sich trotzdem dafür, weil ein Tag verlorener Arbeit teurer ist als ein Tag ohne Arbeit — aber die Entscheidung gehört getroffen und nicht geerbt.

FRXShell — Die Ersatz-Oberfläche, die FSLogix anstelle des Desktops lädt, wenn eine der beiden Sperren greift. Sie zeigt einen Hinweistext und lässt nur das Abmelden zu — der Nutzer kann gar nicht erst anfangen, in einem Profil zu arbeiten, das nicht gesichert wird.

Sperre und Wiederanbindung

Ein Container ist eine Datei, und eine Datei kann von einem anderen Prozess oder einem anderen Rechner geöffnet sein. FSLogix wartet in diesem Fall nicht unbegrenzt, sondern nach dokumentierten Zahlen.

LockedRetryCount: Standardwert 12 — so oft wird ein erneuter Versuch unternommen, wenn die VHD(x) gesperrt ist.
LockedRetryInterval: Standardwert 5 — Sekunden zwischen den Versuchen.
ReAttachRetryCount: Standardwert 60 — so oft wird ein unerwartet getrennter Container erneut angebunden.
ReAttachIntervalSeconds: Standardwert 10 — Sekunden zwischen diesen Versuchen.

Daraus ergeben sich zwei Zeitfenster, die man kennen sollte: Eine Sperre wird rund eine Minute lang ausgesessen, ein unerwarteter Abriss rund zehn Minuten. Eine kurze Storage-Störung von zwei Minuten überlebt eine laufende Sitzung also — eine Anmeldung im selben Moment dagegen nicht.

Die häufigste SperreSie entsteht nicht durch Storage-Fehler, sondern durch eine zweite Sitzung desselben Nutzers: eine getrennte Sitzung auf einem anderen Host, die den Container noch hält. Genau deshalb sind Grenzwerte für getrennte Sitzungen keine Kosmetik, sondern Teil der Profilstrategie.

Gleichzeitiger Zugriff — und seine Grenze

Manchmal soll ein Nutzer bewusst mehrere Sitzungen zugleich haben, etwa einen Desktop und eine veröffentlichte Anwendung aus verschiedenen Pools. ProfileType steuert, wie sich die beteiligten Maschinen dabei verhalten.

0 — normales Verhalten. Der vorgesehene Wert, wenn kein gleichzeitiger Zugriff stattfindet.
1 — die Maschine soll ausschließlich die schreibende Instanz sein.
2 — die Maschine soll ausschließlich die lesende Instanz sein.
3 — die Maschine versucht die schreibende Rolle und fällt auf die lesende zurück, wenn das nicht gelingt.

Zwei Sätze, die man nicht überlesen darfDie Dokumentation verlangt, dass alle Sitzungen, die einen Container gleichzeitig nutzen, einen zusammenpassenden ProfileType tragen — und warnt ausdrücklich davor, 0 mit einem anderen Wert zu mischen. Unabhängig davon gilt: OneDrive unterstützt unter keinen Umständen mehrere gleichzeitige Verbindungen auf dasselbe Profil. Wer gleichzeitigen Zugriff einführt, führt ihn also für eine Umgebung ein, in der OneDrive nicht mehr zugesichert ist.

Was bewusst nicht im Container liegt

Ein Profilcontainer ist kein vollständiges Abbild des Benutzerprofils. Zwei Klassen von Inhalten bleiben draußen, und beide aus nachvollziehbarem Grund.

Umleitung statt Aufnahme: Inhalte, die nicht im Container liegen können, werden in einen lokalen Ordner umgeleitet — C:\Users\local_%username%. Er wird beim Abmelden gelöscht. Betroffen sind unter anderem %userprofile%\AppData\Roaming\Microsoft\Protect und die Anmeldeinformationen unter Microsoft\Credentials. Der Grund ist ausdrücklich genannt: Anwendungen brauchen Zugriff auf diese Daten auch dann, wenn der entfernte Speicher gerade nicht verfügbar ist.

Löschung statt Übernahme: Inhalte, die zwischen Maschinen nicht wandern sollen, werden beim Abmelden aus dem Container entfernt. Dazu zählen nicht wanderungsfähige Anwendungsdaten und — betrieblich am wichtigsten — Identitätsdaten wie AppData\Local\Microsoft\TokenBroker, OneAuth und IdentityCache samt zugehöriger Registry-Zweige.

Warum Identitätsdaten nicht wandern dürfenZwischengespeicherte Token und Geräteregistrierungen gehören zu einer Maschine. Wandern sie mit, treffen sie auf einem anderen Host auf einen anderen Gerätekontext — mit Anmeldefehlern, die wie Profilfehler aussehen. FSLogix kennt dafür die Einstellung RoamIdentity; die Dokumentation empfiehlt ausdrücklich, sie nicht zu verwenden.

Der Speicher darunter

Der Container liegt auf einer SMB-Freigabe, und damit erbt das Profil alle Eigenschaften dieses Speichers: seine Latenz, seine Verfügbarkeit und sein Berechtigungsmodell.

Die Anmeldedauer hängt unmittelbar an der Latenz zum Speicher — sie ist der Grund, warum ein Anmeldevorgang je nach Profil zwischen 30 Sekunden und fünf Minuten dauern kann.
Der Speicher ist eine gemeinsame Abhängigkeit: Fällt er aus, ist nicht ein Host betroffen, sondern jede Anmeldung im Pool.
Berechtigungen wirken zweifach — auf der Freigabe und im Dateisystem. Ein Nutzer, der die Freigabe erreicht, aber keinen Zugriff auf sein Verzeichnis hat, landet im temporären Profil.
Die Verschlüsselungsart, auf die sich Host und Dateidienst bei Kerberos einigen, ist eine harte Abhängigkeit der Einbindung: Passt sie nicht zusammen, scheitert der Zugriff auf die Freigabe — und damit jedes Profil darauf.

Der Nachteil der sauberen LösungProfile vom Host zu trennen macht Maschinen austauschbar — und schafft dafür eine zentrale Abhängigkeit, die es vorher nicht gab. Ein lokales Profil fällt mit einem Rechner aus; ein zentraler Profilspeicher fällt mit allen zugleich aus. Das ist der Preis, und er gehört in jede Verfügbarkeitsrechnung des Pools, nicht in die des Dateidienstes.

Das lokale Profil, das im Weg steht

Ein Sonderfall verdient eine eigene Erwähnung, weil seine Einstellung endgültig wirkt. Hat ein Nutzer auf einem Host bereits ein lokales Profil und soll künftig einen Container bekommen, steht dieses Profil im Weg.

`DeleteLocalProfileWhenVHDShouldApply`Standardwert 0: keine Aktion. Bei 1 gilt laut Dokumentation: Stellt FSLogix fest, dass ein Nutzer einen Container haben sollte, und es existiert ein lokales Profil, wird dieses lokale Profil dauerhaft gelöscht. Das ist gewollt und beseitigt eine häufige Fehlerquelle — es ist aber auch eine Löschung ohne Rückfrage, und sie trifft Daten, die möglicherweise noch nie gesichert wurden.

Für eine Migration heißt das: Der Zeitpunkt, zu dem diese Einstellung scharf geschaltet wird, ist der Zeitpunkt, ab dem lokale Profilinhalte verschwinden. Wer Inhalte aus lokalen Profilen übernehmen will, tut das vorher — danach gibt es nichts mehr zu übernehmen.

Cloud Cache: Redundanz mit eigenem Preisschild

Ein einzelner Profilspeicher ist ein einzelner Ausfallpunkt. Cloud Cache ist die dokumentierte Antwort darauf — kein eigener Containertyp, sondern eine optionale Betriebsart für Profil- und ODFC-Container.

Der Container wird dabei lokal auf der Maschine geführt, unter C:\ProgramData\FSLogix\Cache, und periodisch zu einem oder mehreren entfernten Speicheranbietern abgeglichen. Die Anbieter stehen in CCDLocations statt in VHDLocations, sortiert nach Nähe und dann nach Vorrang.

Lesen: Fehlende Daten werden von genau einem der Anbieter in den lokalen Cache geholt.
Schreiben: Änderungen gehen an alle Anbieter — unabhängig davon, von welchem gelesen wurde.
Abmelden: Wird verzögert, bis alle Anbieter denselben Stand haben.
Anbieter ausgefallen: Der lokale Cache arbeitet weiter und wächst, bis ein Anbieter zurückkehrt — höchstens bis SizeInMBs.

Die Warnung, die den Ausschlag gibtDie Dokumentation ist hier ungewöhnlich drastisch: Wird ein Lesezugriff angefordert und Cloud Cache kann die Daten von keinem der entfernten Anbieter holen, führt das zu einem Hängen der Sitzung — „or worse a system crash (BSOD)“. Redundanz schützt hier also gegen den Ausfall einzelner Anbieter; der gleichzeitige Ausfall aller ist schlimmer als ohne Cloud Cache, nicht besser.

Cloud Cache stellt laut Dokumentation eine zusätzliche Leistungs- und Speicheranforderung an die virtuelle Maschine — der lokale Cache kostet Platte und I/O auf jedem Session Host.
Das Schreiben an alle Anbieter läuft je Anbieter in einem eigenen Thread und wird nicht gedrosselt: FSLogix nutzt so viel Durchsatz, wie das System hergibt.
Steht ein Anbieter beim Anmelden nicht auf demselben Stand, wird ein vollständiger Klon des Containers erzeugt, bevor der normale Abgleich weiterläuft.
Ein Anbieter, der dauerhaft hinterherhinkt, ist ein Hinweis auf zu schwachen Speicher — und Ping oder Test-NetConnection sind laut Dokumentation schlechte Indikatoren dafür, weil sie kein transaktionales I/O messen.

Für eine Mehrregionen-Strategie ist Cloud Cache damit das vorgesehene Mittel — aber eines, das die Anmeldung, das Abmelden und die lokale Plattenauslastung jedes Hosts verändert. Wer es einführt, tauscht ein Verfügbarkeitsrisiko gegen eine Reihe neuer Leistungsfragen ein.

Diagnose: vier Fragen in fester Reihenfolge

Ist FSLogix überhaupt konfiguriert — Enabled und VHDLocations?→Existiert der Container am erwarteten Pfad und Namen?→Lässt er sich einbinden — oder ist er gesperrt?→Ist ein temporäres Profil entstanden?

Konfiguration, Ort, Sperre, Ergebnis

Alle Nutzer eines neuen Hosts im temporären Profil

Szenario

Ein neu aufgenommener Session Host liefert jedem Nutzer ein temporäres Profil. Auf den übrigen Hosts desselben Pools funktioniert alles. Die Freigabe ist vom neuen Host aus erreichbar.

Anforderungen

Die Ursache soll benannt werden, bevor weitere Nutzer auf den Host geleitet werden.
Bestehende Container dürfen nicht verändert werden.

Schritte

Host sofort in den Drain-Modus — jede weitere Anmeldung erzeugt sonst neue temporäre Profile.
Auf dem Host prüfen, ob Enabled und VHDLocations gesetzt sind; ein frisch bereitgestellter Host trägt die Werte möglicherweise noch nicht.
Sind sie gesetzt: mit einem Testkonto anmelden und prüfen, ob am erwarteten Pfad ein Verzeichnis entsteht — entsteht ein neues, stimmt die Namenskonvention nicht.
Erreichbarkeit ist nicht Zugriff: Rechte auf Freigabe und Dateisystem für Computerkonto und Nutzer prüfen.
Erst wenn eine Testanmeldung einen echten Container einbindet, den Drain-Modus aufheben.

Merksatz: Alle auf diesem Host, niemand auf den anderen — das zeigt auf die Konfiguration des Hosts, nicht auf den Speicher. Der Betroffenenkreis grenzt hier schneller ein als jedes Protokoll.

Die Einstellung, die diese Suche erspartMit PreventLoginWithTempProfile auf 1 wäre dieser Fall nie zu einem stillen Datenverlust geworden: Der erste Nutzer hätte den Support gerufen, statt einen Tag lang in einem Profil zu arbeiten, das abends verschwindet. Der Preis ist, dass er gar nicht hätte arbeiten können — und genau diese Abwägung gehört einmal bewusst getroffen und dokumentiert.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität5 Primärquellen · zuletzt geprüft: 2026-09-12