FSLogix-Profilcontainer und der OneDrive-Cache
Was in den Profilcontainer gehört – und was nichtFSLogix und OneDrive: wenn die Profilcontainer explodieren

|
WISSEN Alles zu CosyTrack.Drive: SharePoint, Teams und OneDrive als Laufwerksbuchstaben, am Arbeitsplatz und auf dem Terminalserver. |
BERATUNG Deine Profilcontainer platzen aus allen Nähten? Wir schauen uns Hosts, Freigaben und Bibliotheken gemeinsam an. |
SCHULUNG Onboarding für Admins von RDS und Azure Virtual Desktop, damit Cache, Richtlinien und Leistungszähler sitzen. |
|---|
Es gibt diesen Moment im Leben eines Terminalserver-Admins, in dem die Dateifreigabe mit den FSLogix-Profilen meldet, dass sie gleich voll ist. Du schaust nach und stellst fest: Die Profile sind nicht dicker geworden, weil die Belegschaft plötzlich mehr Hintergrundbilder sammelt. Sie sind dicker geworden, weil OneDrive mitfährt. Und zwar mit allem, was dazugehört: dem OneDrive-Ordner, jeder synchronisierten Teams-Bibliothek, den lokal vorgehaltenen Dateien und den Verwaltungsdaten der Sync-App. Pro Benutzer. Auf jeder Anmeldung. Herzlichen Glückwunsch, dein Profilcontainer ist jetzt ein Fileserver mit Nebenberuf.
Dieser Beitrag ist eine Tiefenbohrung für Admins von RDS und Azure Virtual Desktop. Die Grundlagen, also wie die Sync-App pro Computer installiert wird, warum es FSLogix braucht und welche Windows-Server-Versionen Microsoft unterstützt, findest du im Artikel OneDrive auf dem Terminalserver. Hier geht es um die Frage danach: Wie hängen OneDrive-Cache und Profilcontainer zusammen, warum wachsen die Container, welche Stellschrauben dokumentiert Microsoft, und wie sieht ein Gegenentwurf aus, bei dem der Container wieder das ist, was er sein soll, nämlich ein Profil.
Gleich vorweg, damit niemand mit falschen Erwartungen weiterliest: FSLogix wird durch nichts in diesem Artikel überflüssig. Benutzerprofile brauchst du auf einem nicht persistenten Sitzungshost weiterhin, und FSLogix ist dafür das Werkzeug der Wahl. Es geht nur darum, was in den Container gehört und was nicht.
|
FAKTEN · FSLogix und OneDrive in Zahlen laut Microsoft Learn SizeInMBs, die Höchstgröße eines Profil- oder ODFC-Containers, steht standardmäßig auf 30.000 MB. Der Wert lässt sich jederzeit erhöhen, aber nicht verringern; bestehende Container schrumpfen dadurch nicht. IsDynamic steht standardmäßig auf 1: Der Container belegt auf der Freigabe nur so viel Platz wie nötig und wächst bis zur Obergrenze. Die VHD-Datenträgerkomprimierung ist standardmäßig aktiv, läuft beim Abmelden und greift nur, wenn der Container größer als 1 GB ist und sich mindestens 20 % der belegten Größe zurückholen lassen. Im Office-Container (ODFC) leitet die Einstellung IncludeOneDrive den OneDrive-Cache standardmäßig in den Container um (Wert 1). OneDrive unterstützt keine gleichzeitigen Verbindungen mit demselben Profil, unter keinen Umständen. |
|---|
Wie OneDrive-Cache und Profilcontainer zusammenhängen
Auf einem nicht persistenten Sitzungshost lebt nichts, was der Benutzer anfasst, länger als seine Sitzung, es sei denn, es liegt im Profil. FSLogix löst das elegant: Das gesamte Benutzerprofil wandert in eine VHD- oder VHDX-Datei auf einer Dateifreigabe, die bei der Anmeldung eingehängt wird. Für Windows sieht das wie ein lokales Profil aus. Für OneDrive auch. Und genau das ist der Punkt: Die Sync-App merkt nicht, dass ihr lokaler Speicher in Wahrheit eine Datei auf einem Netzwerkpfad ist. Sie verhält sich, wie sie sich am Notebook verhält.

Die vier Mitfahrer im Container
Wenn OneDrive auf dem Sitzungshost läuft, landen im Profilcontainer im Wesentlichen vier Dinge, die ein klassisches Windows-Profil nicht kennt:
Der OneDrive-Ordner des Benutzers. Mit Files On-Demand stehen dort zunächst nur Platzhalter. Sobald jemand eine Datei öffnet, liegt der Inhalt lokal, also im Container.
Synchronisierte SharePoint- und Teams-Bibliotheken. Jede Bibliothek, die jemand über „Synchronisieren“ oder „Verknüpfung zu OneDrive hinzufügen“ einbindet, bringt eigene Platzhalter, eigene Datenbankeinträge und eigene lokale Kopien mit.
Die Verwaltungsdaten der Sync-App. Unter %LocalAppData%\Microsoft\OneDrive liegen Einstellungen, Datenbanken und Protokolle. Bei vielen synchronisierten Elementen wird das kein Zwerg.
Bekannte Ordner, wenn die Ordnersicherung aktiv ist. Desktop, Dokumente und Bilder landen dann ebenfalls im OneDrive-Ordner und damit im Container.
Was die Ordnersicherung auf Sitzungshosts sonst noch mit sich bringt, steht in OneDrive-Ordnersicherung (Known Folder Move) auf dem Terminalserver. Für dieses Thema reicht die Erkenntnis, dass sie die Menge der Dateien im OneDrive-Ordner und damit im Container erhöht.
Profilcontainer oder Office-Container?
FSLogix kennt zwei Containerarten. Der Profilcontainer nimmt das komplette Profil auf, OneDrive inklusive. Der Office-Container (ODFC) nimmt nur Office-bezogene Daten auf und ist für Umgebungen gedacht, in denen eine andere Profillösung das eigentliche Profil verwaltet. Im ODFC entscheidet die Einstellung IncludeOneDrive, ob der OneDrive-Cache mit hineinwandert; der Standardwert ist 1, also ja. Wer beides parallel betreibt, landet schnell bei der Frage, in welchem Container die Sync-Daten eigentlich liegen. Für die meisten RDS- und AVD-Umgebungen genügt der Profilcontainer allein; dann ist die Antwort eindeutig: dort.
|
Aspekt |
Profilcontainer |
Office-Container (ODFC) |
|---|---|---|
|
Inhalt |
Gesamtes Benutzerprofil |
Office-bezogene Daten, optional OneDrive, OneNote, Teams u. a. |
|
OneDrive-Cache |
Liegt im Profil und damit im Container |
Über IncludeOneDrive steuerbar, Standard 1 |
|
Höchstgröße |
SizeInMBs, Standard 30.000 MB |
SizeInMBs, Standard 30.000 MB |
|
Dynamisch |
IsDynamic, Standard 1 |
IsDynamic, Standard 1 |
|
Typischer Einsatz |
Standard für RDS und Azure Virtual Desktop |
Ergänzung zu einer anderen Profillösung |
|
WARNUNG · Eine Sitzung pro Profil, sonst knallt es Microsoft schreibt es in die FSLogix-Referenz und in die OneDrive-Dokumentation: OneDrive unterstützt keine gleichzeitigen Verbindungen mit demselben Profil, unter keinen Umständen. Wer Benutzern parallel eine Desktop-Sitzung und eine RemoteApp auf verschiedenen Hosts erlaubt und dabei mit Lese-Schreib-Containern experimentiert, baut sich eine sehr kreative Fehlerquelle. |
|---|
Was Microsoft offiziell unterstützt
Für nicht persistente Desktops mit FSLogix nennt Microsoft als unterstützte Betriebssysteme Windows 11 und Windows Server 2025 oder neuer. Voraussetzung sind die Installation der Sync-App pro Computer, auf Windows Server zusätzlich SMB für die Freigabe, und eine aktuelle FSLogix-Version. Wenn du noch auf älteren Serverversionen sitzt, lohnt ein Blick in Windows Server 2025 als Terminalserver mit SharePoint-Dateien und in Microsoft 365 Apps auf Windows Server 2022: was nach Oktober 2026 gilt. Die verbindliche Liste pflegt Microsoft auf der Seite Synchronisierungs-App auf virtuellen Desktops (Microsoft Learn).
Warum die Container wachsen
Ein Profilcontainer wächst nicht aus Bosheit. Er wächst, weil drei Mechanismen ineinandergreifen, die jeder für sich harmlos wirken. Zusammen ergeben sie die Kurve, die du aus deinem Monitoring kennst: Es geht immer nur bergauf, und die Freigabe ruft irgendwann um Hilfe.

Mechanismus 1: Öffnen heißt Herunterladen
Files On-Demand ist der wichtigste Verbündete, aber kein Zauberstab. Ein Platzhalter kostet fast nichts. Öffnet jemand die Datei, lädt die Sync-App den Inhalt herunter, und die Datei ist ab dann „lokal verfügbar“. Sie bleibt das, bis jemand oder etwas sie wieder in eine reine Online-Datei verwandelt. Am Notebook fällt das kaum auf. Im Container summiert es sich: Das Ingenieurbüro mit 40 Leuten, in dem jeder ein paar große Planstände öffnet, trägt diese Planstände eben 40-mal in 40 Containern mit sich herum.
Mechanismus 2: Jede Bibliothek zählt pro Benutzer
Synchronisiert ein Team seine Teams-Bibliothek, entsteht diese Bibliothek als Platzhalterbaum in jedem einzelnen Profil. Bei kleinen Bibliotheken ist das egal. Bei großen Bibliotheken mit Zehntausenden Elementen wachsen Datenbanken und Platzhalter mit, und die Sync-App hat bei sehr vielen Dateien ohnehin ihre Grenzen. Was dann passiert, beschreibt der Beitrag OneDrive synchronisiert nicht mehr: die Grenze bei vielen Dateien.
Mechanismus 3: Gelöscht heißt nicht geschrumpft
Ein dynamischer Container wächst auf der Freigabe, wenn innen Daten dazukommen. Werden innen Daten gelöscht, wird der Platz in der VHDX frei, die Datei auf der Freigabe bleibt aber zunächst so groß, wie sie war. Genau dafür gibt es die VHD-Datenträgerkomprimierung. Sie läuft bei jedem Abmelden und prüft, ob sich der Aufwand lohnt. Das Kriterium ist präzise dokumentiert: Der Container muss größer als 1 GB sein, und die Differenz zwischen belegter Größe und der kleinstmöglichen Größe muss mindestens 20 % der belegten Größe betragen. Sonst passiert nichts.
|
Belegt |
Kleinstmögliche Größe |
Rückholbar |
20 % der Belegung |
Komprimierung? |
|---|---|---|---|---|
|
6 GB |
2,5 GB |
3,5 GB |
1,2 GB |
Ja |
|
12 GB |
10 GB |
2 GB |
2,4 GB |
Nein |
|
30 GB, feste Größe |
nicht ermittelt |
entfällt |
entfällt |
Nein, nur dynamische Disks |
Die Beispiele stammen aus Microsofts eigener Beschreibung. Wichtig für die Praxis: Die Komprimierung braucht den Windows-Dienst „Laufwerke optimieren“ (defragsvc). Steht dessen Starttyp auf „Deaktiviert“, scheitert die Größenermittlung und die Komprimierung läuft nicht. Gehärtete Images, in denen jemand „unnötige Dienste“ abgeschaltet hat, sind hier ein Klassiker. Außerdem läuft die Komprimierung höchstens fünf Minuten pro Abmeldung und macht beim nächsten Mal weiter; Benutzer sehen solange die Meldung, dass auf die FSLogix-Dienste gewartet wird. Die Details stehen bei Microsoft unter VHD-Datenträgerkomprimierung in FSLogix (Microsoft Learn).
|
AUS DER PRAXIS · Filialisierter Lebensmittelbetrieb, Zentrale mit RDS-Farm Die Profile lagen lange stabil im einstelligen Gigabyte-Bereich. Dann wurden die Abteilungslaufwerke nach Teams verlagert, und jedes Team hat seine Bibliothek per Verknüpfung synchronisiert. Ein halbes Jahr später waren die Container im Einkauf ein Vielfaches so groß, und die Anmeldezeiten stiegen mit. Ursache war kein einzelner Fehler, sondern die Summe: viele Bibliotheken, viele geöffnete Dateien, pro Benutzer. Die Komprimierung lief, kam aber gegen den Zuwachs nicht an. |
|---|
Was die Größe kostet, außer Speicherplatz
Speicher auf der Freigabe ist der sichtbare Teil der Rechnung. Der unsichtbare Teil: Jeder Zugriff auf eine Datei im Container ist ein Zugriff über SMB auf eine VHDX. Große Container bedeuten mehr Ein- und Ausgabelast auf dem Speicher, längere Komprimierungsläufe beim Abmelden und mehr Risiko, wenn die Obergrenze erreicht ist. Laut FSLogix-Referenz erlebt der Benutzer Fehler, sobald sein Container über SizeInMBs hinauswachsen müsste. Das ist dann kein OneDrive-Problem mehr, sondern ein Profilproblem, und das betrifft Outlook, Teams und alles andere gleich mit.
Die Stellschrauben mit Microsoft-Bordmitteln
Die gute Nachricht: Mit Bordmitteln lässt sich einiges retten. Die schlechte: Keine der Stellschrauben ändert das Grundprinzip, dass die Sync-Kopien im Profil liegen. Du kannst sie verkleinern, regelmäßig ausdünnen und die Folgen begrenzen. Hier ist, was Microsoft dokumentiert.

Files On-Demand konsequent nutzen
Files On-Demand ist die Grundvoraussetzung für OneDrive im Container. Ohne Platzhalter würde jede synchronisierte Bibliothek komplett in jedem Profil landen. Zusätzlich kennt Windows die Dateiattribute, mit denen sich der Zustand einer Datei setzen lässt. Laut Microsoft Learn macht attrib +u eine Datei oder einen Ordner zur reinen Online-Datei, der Inhalt wird lokal freigegeben. Das lässt sich skripten, etwa beim Abmelden für ausgewählte Ordner. Rechne aber damit, dass genau die Dateien, die gestern freigegeben wurden, morgen wieder geöffnet und damit erneut heruntergeladen werden.
Für synchronisierte Teamwebsites bietet OneDrive eine eigene Richtlinie, die deren Dateien in reine Online-Dateien umwandelt. Sie zielt auf genau das Szenario, in dem viele Benutzer dieselben Bibliotheken synchronisieren, und ist auf Sitzungshosts einen Blick wert.
Weniger synchronisieren
Die wirksamste Bordmittel-Maßnahme ist organisatorisch: Nicht jede Bibliothek muss in jedes Profil. Wer nur gelegentlich in eine Bibliothek schaut, braucht keine Synchronisation, sondern den Browser oder Teams. Das klingt einfach, scheitert in der Praxis aber oft an Fachanwendungen und Gewohnheiten, die einen echten Pfad im Dateisystem erwarten. Die Abwägung zwischen Sync, Explorer-Ansicht und Laufwerk beschreibt OneDrive-Sync, Explorer-Ansicht oder CosyTrack.Drive.
Containergrößen bewusst festlegen
SizeInMBs ist eine Obergrenze, kein Ziel. Mit dynamischen Containern (IsDynamic = 1, Standard) belegt ein Container nur, was er braucht. Die Grenze schützt die Freigabe vor einem einzelnen Ausreißer, zwingt dich aber zu einer Entscheidung: Zu niedrig, und Benutzer bekommen Fehler. Zu hoch, und die Freigabe läuft voll, bevor ein einzelner Container an seine Grenze stößt. Beachte: Erhöhen geht jederzeit, verkleinern nicht. Bestehende Container werden beim Anmelden auf eine höhere Grenze erweitert, schrumpfen bei einer niedrigeren aber nicht.
Aufräumen und überwachen
1. Komprimierung prüfen. VHDCompactDisk steht standardmäßig auf 1. Kontrolliere in deinem Image, dass der Dienst „Laufwerke optimieren“ nicht deaktiviert ist und dass du dynamische Container verwendest.
2. Größen auf der Freigabe überwachen. Eine regelmäßige Auswertung der VHDX-Dateigrößen pro Benutzer zeigt Ausreißer, bevor die Freigabe voll ist.
3. Synchronisierte Bibliotheken inventarisieren. Frag nicht, wie groß die Container sind, sondern was darin synchronisiert wird. Oft sind es wenige große Bibliotheken.
4. Online-only gezielt einsetzen. Richtlinie für Teamwebsite-Dateien und, wo sinnvoll, ein Skript mit attrib +u für bekannte Datengräber.
5. Anmelde- und Abmeldezeiten beobachten. Lange Abmeldungen mit Winlogon-Warnungen sind laut Microsoft bei Komprimierungen normal. Werden sie zum Dauerzustand, ist der Zuwachs größer als das, was die Komprimierung zurückholt.
|
Stellschraube |
Wirkt auf |
Was sie leistet |
Was sie nicht leistet |
|---|---|---|---|
|
Files On-Demand |
OneDrive |
Platzhalter statt Vollkopie |
Geöffnete Dateien bleiben lokal |
|
attrib +u |
Einzelne Dateien und Ordner |
Inhalt lokal freigeben |
Verhindert kein erneutes Herunterladen |
|
Teamwebsite-Dateien online-only |
Synchronisierte Teamwebsites |
Dünnt Teamwebsite-Kopien aus |
Ändert nichts an der Zahl der Bibliotheken |
|
SizeInMBs |
Container |
Schützt die Freigabe vor Ausreißern |
Lässt sich nicht verkleinern |
|
IsDynamic = 1 |
Container |
Belegt nur Benötigtes |
Schrumpft nicht von selbst |
|
VHDCompactDisk |
Container |
Holt Platz beim Abmelden zurück |
Greift erst ab 20 % Rückholbarem |
|
TIPP · Erst messen, dann schrauben Bevor du Grenzen änderst, sortiere die Container auf der Freigabe nach Größe und schau dir die größten zehn an. In aller Regel findest du dort nicht zehn verschiedene Probleme, sondern zwei oder drei Bibliotheken, die in vielen Profilen synchronisiert sind. |
|---|
Der Gegenentwurf: schlanker Container plus CosyTrack.Drive
Die Bordmittel behandeln die Symptome eines Grundprinzips: Die Sync-App legt ihre Daten ins Profil, weil das Profil ihr lokaler Speicher ist. Der Gegenentwurf setzt beim Prinzip an. Statt Bibliotheken pro Benutzer ins Profil zu synchronisieren, bindet CosyTrack.Drive SharePoint- und Teams-Bibliotheken sowie OneDrive als Windows-Laufwerksbuchstaben ein und arbeitet dabei mit einem eigenen Cache, dessen Ressourcenverbrauch du einstellst. Der Profilcontainer bleibt, was er sein soll: ein Profil mit Registry, AppData und Einstellungen.

Damit das klar ist: FSLogix bleibt. Auch mit Drive braucht ein nicht persistenter Sitzungshost ein Benutzerprofil, und FSLogix ist dafür weiterhin das richtige Werkzeug. Was sich ändert, ist die Rolle des Containers: Er trägt keine Sync-Kopien von Bibliotheken mehr. Wenn du gerade überlegst, ob FSLogix oder Benutzerprofil-Datenträger besser zu SharePoint-Dateien passen, hilft Benutzerprofil-Datenträger oder FSLogix: was passt zu SharePoint-Dateien?.
Laufwerke statt Sync-Kopien
Drive kennt mehrere Laufwerksquellen, die du kombinierst: eine feste Bibliothek als Laufwerk, die Teams-Automatik, die alle Teams eines Benutzers einbindet und regelmäßig sowie auf Wunsch manuell aktualisiert, das eigene OneDrive als eigener Buchstabe, zum Beispiel O:, die Website-Suche, die zugängliche Websites der ersten Ebene einsammelt (standardmäßig nur Teamwebsites), und eine SharePoint-Liste per Filter, etwa mit einem Personenfeld, das dem angemeldeten Benutzer entspricht. Pro Laufwerk legst du fest, ob es nur lesend oder lesend und schreibend eingebunden wird; Schreiben umfasst Speichern, Umbenennen, Löschen und Ordner anlegen. Wie die Teams-Automatik im Alltag aussieht, zeigt Teams-Dateien als Laufwerk im Explorer, das eigene OneDrive als Laufwerk beschreibt OneDrive als Laufwerk O: einbinden.
Auf dem Terminalserver bekommt jeder Benutzer seine eigenen Laufwerke. Am Arbeitsplatz gilt dasselbe Modell, nur ohne Nachbarn auf dem Host. Drive ist damit keine reine Terminalserver-Lösung: Arbeitsplatz und Sitzungshost sind gleichwertige Einsatzorte, und die Konfiguration ist an beiden Stellen dieselbe.
Cache, den du steuerst
Der Unterschied, der für dieses Thema zählt, ist der Cache. Den Ressourcenverbrauch des Drive-Caches stellst du zentral ein. Im Statusfenster siehst du, wie viel Platz der Lesecache gerade belegt, wie er sich auf die Laufwerke verteilt und welche Dateien noch auf ihren Upload warten. Wie du Cache und Plattenplatz auf Sitzungshosts planst, beschreibt Cache und Plattenplatz auf dem Terminalserver.

Gesteuert wird Drive per GPO oder Intune; zum Testen gibt es zusätzlich eine Konfigurations-App. Im Statusfenster erkennst du für jede Einstellung, ob sie per Richtlinie kommt oder als Standardwert gilt. Das ist auf einer Farm mit mehreren Hosts die schnellste Antwort auf die Frage, warum sich ein Host anders verhält als sein Nachbar. Mehr zur zentralen Steuerung steht in CosyTrack.Drive per GPO und Intune steuern.

Vor dem Rollout: Bereitschaftscheck mit Bericht
Zu Generation 60, der komplett neu gebauten aktuellen Generation von Drive, gehört das Admin-Kit. Für dieses Thema ist vor allem der Bereitschaftscheck interessant: Er prüft den Host vor dem Rollout und erstellt einen Bericht, in dem unter anderem das Cache-Volume und der FSLogix-Profilcontainer auftauchen. So hast du vor der Installation schwarz auf weiß, wie es um Speicherplatz und Profil auf dem Sitzungshost steht. Mit dem Stresstest erzeugst du anschließend Last auf einem Laufwerk und bekommst einen Bericht, den du als Abnahmeprotokoll ablegen kannst.

Im Betrieb: messen statt raten
Drive protokolliert nachvollziehbar und liefert Leistungszähler, von der Zahl übertragener Dateien bis zur Übertragungsgeschwindigkeit, auch als Windows-Leistungsindikatoren. Das Statusfenster zeigt die Werte direkt an, einschließlich der Cache-Trefferquote. Uploads laufen über eine parallele Upload-Engine, deren Parallelität du einstellst. Wie du die Microsoft-365-Anbindung systematisch misst, beschreibt Microsoft-365-Anbindung messen mit Leistungszählern.

|
Frage |
OneDrive-Sync im Profilcontainer |
Schlanker Container plus Drive |
|---|---|---|
|
Wo liegen die Dateikopien? |
Im Profil, also in der VHDX pro Benutzer |
Im Drive-Cache, nicht als Sync-Kopie im Profil |
|
Wovon hängt die Containergröße ab? |
Von Profil, geöffneten Dateien und Zahl der Bibliotheken |
Vom eigentlichen Profil |
|
Wie steuerst du den Speicherverbrauch? |
Files On-Demand, attrib +u, Richtlinien, Komprimierung |
Einstellbarer Cache-Ressourcenverbrauch |
|
Wie bekommen Benutzer ihre Bibliotheken? |
Synchronisieren oder Verknüpfung pro Benutzer |
Laufwerksbuchstaben per GPO oder Intune, inklusive Teams-Automatik |
|
Rechte pro Ablage |
Wie in SharePoint |
Zusätzlich pro Laufwerk nur lesend oder lesend und schreibend |
|
Wird FSLogix noch gebraucht? |
Ja |
Ja, für das Profil |
|
Einsatzorte |
Arbeitsplatz und Sitzungshost |
Arbeitsplatz und Sitzungshost |
|
WICHTIG · Drive ist kein Umzugswagen Drive ist zum Arbeiten da, nicht zum Umziehen. Erkennt Drive eine Massenkopie, weist es darauf hin. Große Datenbestände bringst du mit CosyTrack.Migrate nach SharePoint. Die Abgrenzung erklärt Drive oder Migrate: Arbeiten ist nicht Umziehen. |
|---|
So gehst du den Umstieg an
1. Bestand aufnehmen. Welche Bibliotheken sind in wie vielen Profilen synchronisiert, und wie groß sind die Container heute?
2. Bereitschaftscheck laufen lassen. Bericht pro Host ablegen, Cache-Volume und Profilcontainer im Blick.
3. Laufwerke planen. Feste Bibliotheken, Teams-Automatik, O: für OneDrive, Rechte pro Laufwerk.
4. Im Pilot mit der eigenen Umgebung testen. Eine Benutzergruppe, ein Host, Konfiguration per GPO oder Intune, Stresstest als Abnahmeprotokoll.
5. Sync-Verknüpfungen zurückbauen. Erst wenn die Laufwerke laufen, Synchronisierungen auf den Hosts beenden und die Container beim Abmelden komprimieren lassen.
Den vollständigen Ablauf vom Pilot bis zum Regelbetrieb beschreibt der Einführungsfahrplan für CosyTrack.Drive. Nach der Installation läuft ein Testzeitraum; für Pilot und Angebot ist die Beratung zu CosyTrack.Drive der richtige Ansprechpartner. Lizenziert wird pro Named User.
FAQ: FSLogix und OneDrive
Gehört der OneDrive-Cache in den FSLogix-Profilcontainer?
Wenn du die OneDrive-Sync-App auf nicht persistenten Hosts nutzt: ja, sonst ist er nach jeder Abmeldung weg. Mit dem Profilcontainer liegt er automatisch im Profil; im Office-Container steuert IncludeOneDrive das Verhalten, Standard ist 1. Der Preis ist ein Container, der mit den Sync-Daten wächst.
Wie groß darf ein FSLogix-Profilcontainer werden?
Standardmäßig 30.000 MB, festgelegt über SizeInMBs. Du kannst den Wert erhöhen, aber nicht verringern; bestehende Container schrumpfen durch einen kleineren Wert nicht.
Warum wird mein Container nach dem Löschen von Dateien nicht kleiner?
Weil gelöschter Platz zunächst nur innerhalb der VHDX frei wird. Die Komprimierung beim Abmelden holt ihn zurück, aber nur bei dynamischen Containern über 1 GB und wenn mindestens 20 % der belegten Größe rückholbar sind. Außerdem darf der Dienst „Laufwerke optimieren“ nicht deaktiviert sein.
Hilft Files On-Demand gegen große Container?
Ja, ohne Files On-Demand wäre OneDrive im Container kaum betreibbar. Es verhindert aber nicht, dass geöffnete Dateien lokal bleiben. Dafür gibt es attrib +u und die Richtlinie für Teamwebsite-Dateien.
Macht CosyTrack.Drive FSLogix überflüssig?
Nein. Benutzerprofile brauchst du auf Sitzungshosts weiterhin, und dafür bleibt FSLogix zuständig. Drive sorgt dafür, dass Bibliotheken als Laufwerke mit eigenem, einstellbarem Cache eingebunden werden statt als Sync-Kopien im Profil.
Funktioniert das auch auf Azure Virtual Desktop?
Das Prinzip ist dasselbe: Profilcontainer per FSLogix, Dateien per Laufwerk. Die Besonderheiten von Azure Virtual Desktop und Windows 365 behandelt SharePoint-Laufwerke auf Azure Virtual Desktop und Windows 365; für Citrix gibt es SharePoint als Laufwerk unter Citrix Virtual Apps.
Läuft Drive nur auf Terminalservern?
Nein. Drive läuft auf Arbeitsplätzen und auf Terminalservern gleichermaßen, an beiden Orten mit derselben Konfiguration per GPO oder Intune.
Fazit: Der Container ist ein Profil, kein Fileserver
FSLogix-Profilcontainer explodieren nicht, weil FSLogix etwas falsch macht. Sie explodieren, weil die OneDrive-Sync-App das Profil als lokalen Speicher behandelt und jede geöffnete Datei, jede synchronisierte Bibliothek und jede Sync-Datenbank pro Benutzer mitbringt. Mit Bordmitteln kommst du ein gutes Stück weit: Files On-Demand, Online-only-Richtlinien, bewusst gewählte Containergrößen, funktionierende Komprimierung und ein waches Auge auf die Freigabe.
Wer das Grundprinzip ändern will, trennt Profil und Dateien: FSLogix für das Profil, CosyTrack.Drive für SharePoint, Teams und OneDrive als Laufwerke mit eigenem, steuerbarem Cache. Für den Einstieg der IT gibt es Schulung und Onboarding für CosyTrack.Drive. Geht es um die Struktur der Websites und Bibliotheken dahinter, hilft die SharePoint-Beratung; Grundlagen findest du im Kompetenzbereich SharePoint.
Dieses Consulting-Dokument steht als PDF zum Download bereit: https://www.boddenberg.de/ArtikelPdf/dein-fslogix.pdf — © Ulrich B. Boddenberg · boddenberg.de







