Microsoft 365 auf Citrix VDAs mit FSLogix bereitstellen

Word über Citrix zu öffnen, sieht für den Benutzer einfach aus: Anwendung anklicken, anmelden und arbeiten. Bei der Bereitstellung müssen jedoch mehrere Dinge zusammenpassen. Die Office-Lizenz muss zum gemeinsamen Sitzungsrechner passen, das persönliche Profil muss geladen werden und der nächste VDA braucht eine eigene Maschinenidentität.

In unserer Laborumgebung haben wir Microsoft 365 Apps zunächst auf einem Windows-VDA bereitgestellt und das Verfahren anschliessend wiederverwendet. Dazu gehören Shared Computer Activation, FSLogix-Profilcontainer auf einer geeigneten SMB-Ablage und eine vorbereitete Hyper-V-Vorlage. Dieser Beitrag beschreibt einen konkreten Fehler bei der Profilkonfiguration und die Prüfungen für einen wiederholbaren Rollout.

Die Bausteine unserer Bereitstellung

Ein VDA, ausgeschrieben Virtual Delivery Agent, stellt in diesem Aufbau die Windows-Umgebung für die Citrix-Sitzung bereit. Office und OneDrive sind dort installiert. Der Benutzer startet seine veröffentlichte Anwendung über Citrix Workspace. Active Directory und Gruppenrichtlinien liefern einen Teil der Konfiguration; Microsoft 365 übernimmt die persönliche Office-Aktivierung.

FSLogix bindet das Benutzerprofil aus einem Container auf einer SMB-Freigabe ein. Microsoft unterscheidet dabei vollständige Profile Container und auf bestimmte Office-Daten begrenzte ODFC-Container. Wir verwenden den Profilcontainer. Ein zusätzlicher ODFC-Container ist bei diesem Aufbau nicht automatisch erforderlich; der Profilcontainer kann die entsprechenden Office-Daten bereits enthalten. Die Microsoft-Erklärung der Containertypen beschreibt den Unterschied.

Die VDA-Systeme wurden manuell über Hyper-V exportiert und importiert. Dieser Ablauf setzt ihre Systemplatten nicht nach jeder Anmeldung zurück. Ein ausgelagertes Benutzerprofil allein macht aus einer VM noch keinen nichtpersistenten Desktop.

Die Lizenz muss Shared Computer Activation erlauben

Wir haben Office 365 E3 mit Microsoft 365 Apps for enterprise gewählt. Für gemeinsam genutzte Sitzungsrechner verwenden wir Shared Computer Activation, kurz SCA. Jeder zugreifende Benutzer braucht eine passende Lizenz und seine eigene Identität. Die SCA-Nutzung zählt nicht gegen das normale Fünf-PC-Aktivierungslimit.

Eine wichtige Korrektur gegenüber einer frühen Notiz: Microsoft 365 Business Premium unterstützt SCA ebenfalls, Business Standard dagegen nicht. Massgeblich ist die Microsoft-Dokumentation zu Shared Computer Activation.

Windows-/RDS-Rechte, Citrix-Lizenzen und FSLogix-Berechtigungen gehören ebenfalls in die Planung. Die erfolgreiche Office-Aktivierung ersetzt diese Prüfung nicht. Microsoft nennt beispielsweise RDS CAL und RDS SAL als mögliche Berechtigungen für FSLogix. Ein Office-Produktname allein beantwortet deshalb noch nicht alle Lizenzfragen der gesamten Sitzung.

Office mit dem Deployment Tool installieren

Für die Installation haben wir das Office Deployment Tool verwendet. Eine XML-Datei beschreibt Produkt, Sprache, Architektur und Updatekanal. Damit bleibt die Installationsentscheidung nachvollziehbar und lässt sich beim nächsten VDA wiederverwenden. Microsoft erklärt die Betriebsarten in der Anleitung zum Office Deployment Tool.

Unsere Ausgangskonfiguration sah so aus:

<Configuration>
  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
    <Product ID="O365ProPlusRetail">
      <Language ID="de-de" />
    </Product>
  </Add>
  <Display Level="None" AcceptEULA="TRUE" />
  <Property Name="SharedComputerLicensing" Value="1" />
</Configuration>

Die Installation wurde mit der XML-Datei gestartet:

.\setup.exe /configure .\configuration.xml

Dieser Befehl verändert die Office-Installation. Er gehört auf ein vorbereitetes System beziehungsweise in ein geplantes Wartungsfenster. Die XML-Datei ist ein Beispiel aus unserer Einrichtung; Architektur, Sprache, Produkt und Updatekanal müssen zur eigenen Umgebung passen.

Nach der Installation prüfen wir den tatsächlichen Zustand. Eine abgelegte XML-Datei beweist nicht, dass deren Einstellungen auf dem VDA wirksam sind:

Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration' |
    Select-Object ProductReleaseIds, VersionToReport, Platform,
        SharedComputerLicensing, UpdateChannel

Im ersten Test war SharedComputerLicensing auf 1 gesetzt. Word liess sich über Citrix Workspace öffnen und war unter dem persönlichen Microsoft-365-Konto aktiviert. Genau diese Kombination aus wirksamer Einstellung und tatsächlichem Anwendungsstart war für uns der erste brauchbare Nachweis.

Der entscheidende FSLogix Fehler lag im Registry Pfad

Bei der Profilkonfiguration hatten wir zunächst Werte unter HKLM\SOFTWARE\Policies\FSLogix\Profiles abgelegt. Im FSLogix-Log stand trotzdem: „FSLogix Profiles feature is not enabled“.

Der entscheidende Punkt war der Pfad. FSLogix erwartet die Profileinstellungen unter HKLM\SOFTWARE\FSLogix\Profiles. Für ODFC-Einstellungen verwendet Microsoft dagegen den Policies-Zweig. Wir hatten diese beiden Konfigurationsbereiche vermischt. Nach der Korrektur von Enabled und VHDLocations im richtigen Profilpfad wurde das Profil erfolgreich geladen. Es handelte sich somit nicht um einen nachgewiesenen Defekt der Gruppenrichtlinien. Die FSLogix-Konfigurationsreferenz dokumentiert die unterschiedlichen Zweige.

Für die Bestandsprüfung reichen zunächst lesende Befehle:

Get-ItemProperty 'HKLM:\SOFTWARE\FSLogix\Profiles' |
    Select-Object Enabled, VHDLocations, SizeInMBs, VolumeType

Get-LocalGroupMember -Group 'FSLogix Profile Include List'
Get-LocalGroupMember -Group 'FSLogix Profile Exclude List'

Enabled muss für diesen Aufbau auf 1 stehen; VHDLocations verweist auf die vorgesehene Profilfreigabe. Der gewünschte Benutzer wurde im Pilot gezielt in den Geltungsbereich aufgenommen und das administrative Konto ausgeschlossen.

Ein lokaler Fix hilft bei der Fehlereingrenzung. Für weitere VDAs muss anschliessend dieselbe wirksame Konfiguration zentral oder im freigegebenen Image vorhanden sein. Es wäre unnötig, auf jedem Klon blind denselben Registry-Eingriff zu wiederholen, wenn die Werte bereits korrekt gesetzt sind.

Profilfreigabe und Anmeldeverhalten praktisch prüfen

Die Freigabe muss erreichbar sein und die vorgesehenen Zugriffsrechte haben. Gleichzeitig müssen Benutzerprofile voneinander getrennt bleiben. Eine beschreibbare gemeinsame Ablage mit pauschalen Vollzugriffsrechten wäre dafür keine ausreichende Abnahme.

Für eine Profilfreigabe müssen die beteiligten Benutzer- und Computeridentitäten sowie der gewählte FSLogix-Zugriffsmodus berücksichtigt werden. Eine AD-Gruppenzuordnung allein beantwortet noch nicht, unter welcher Identität der Container tatsächlich geöffnet wird. Die Rechte müssen zum gewählten Speicherkonzept passen.

Beim Test achten wir auf das eigene geladene Profil und die zugehörigen FSLogix-Meldungen. Das aktuelle Profil-Log lässt sich beispielsweise so lesen:

$profileLog = Get-ChildItem 'C:\ProgramData\FSLogix\Logs\Profile\*.log' |
    Sort-Object LastWriteTime -Descending |
    Select-Object -First 1

if ($profileLog) {
    Get-Content -LiteralPath $profileLog.FullName -Tail 80
}

Im Einrichtungstest meldete FSLogix ein erfolgreich geladenes Profil. Für die weitere Abnahme gehört eine vollständige Abmeldung dazu: Eine kleine Profiländerung vornehmen, abmelden und nach erneuter Anmeldung deren Fortbestand prüfen. Erst danach folgt der Wechsel auf einen zweiten VDA. Eine bloss getrennte Citrix-Verbindung ist dafür nicht dasselbe wie eine beendete Sitzung.

Office-Anmeldung und Lizenz-Tokens betrachten wir dabei gesondert. SCA verwendet benutzerbezogene Tokens; ein abweichender Speicherort kann über die unterstützte Token-Roaming-Konfiguration eingerichtet werden. Ein angewendeter GPO-Name beweist jedoch noch kein funktionierendes Roaming. Unser erfolgreicher Word-Test bestätigt die Aktivierung des getesteten Benutzers, keinen vollständig geprüften Tokenwechsel über sämtliche VDAs.

OneDrive gemeinsam installieren und persönlich prüfen

OneDrive haben wir pro Computer installiert:

.\OneDriveSetup.exe /allusers

Die Programmdateien werden damit gemeinsam bereitgestellt. Konten und Synchronisationsdaten bleiben benutzerspezifisch. Microsoft beschreibt diesen Aufbau in der Anleitung zur Per-Machine-Installation.

In den Gruppenrichtlinien waren Files On-Demand und Silent Account Configuration vorgesehen. Ein laufender OneDrive-Prozess unter dem richtigen Benutzer war im ersten Test sichtbar. Ob die Anmeldung automatisch klappt und eine Datei wirklich synchronisiert wird, sind jedoch eigene Prüfungen.

Besonders SilentAccountConfig=1 ist kein allgemeiner Ersatz für die Identitätskonfiguration. Die Voraussetzungen für Geräte- und Benutzeridentität müssen erfüllt sein. Dazu gehört der Blick auf den tatsächlichen Entra-/Hybrid-Zustand und die geltenden Anmeldeanforderungen. Die Microsoft-Anleitung zur stillen Kontokonfiguration erläutert diese Abhängigkeiten.

Für die Abnahme verwenden wir deshalb eine Testdatei und kontrollieren ihren Synchronisationsstatus. Ein Prozess im Task-Manager beantwortet diese Frage nicht.

Aus dem ersten VDA weitere Maschinen bereitstellen

Nach der ersten Einrichtung haben wir das Verfahren auf weitere VDAs übertragen. Die wiederverwendbare Vorlage spart Installationsarbeit; Maschinenidentität und Zielkonfiguration brauchen bei jedem neuen System trotzdem Aufmerksamkeit.

Unser Ablauf verwendet eine exportierte Hyper-V-Arbeitskopie. Die funktionierende Quelle wird gesichert und ausgeschaltet exportiert. Auf dem Zielhost wird die Kopie unabhängig importiert, vom Netzwerk getrennt und erst dort generalisiert. Sysprep gehört in diese isolierte Arbeitskopie. Die laufende Quelle darf dadurch nicht ihre Identität verlieren.

Persönliche Office- und OneDrive-Anmeldedaten gehören nicht in die freigegebene Vorlage. Ein Test mit einem persönlichen Konto und die Vorbereitung eines verteilbaren Images sind deshalb getrennte Arbeitsschritte; Sysprep allein ersetzt diese Kontrolle nicht.

Das ist unser manuelles Verfahren. Es lässt sich nicht unverändert auf Citrix Machine Creation Services oder Provisioning übertragen. Für MCS beschreibt Citrix einen eigenen Master-Image-Prozess und weist darauf hin, das Master-Image nicht mit Sysprep zu bearbeiten. Dafür gilt die zum eigenen Citrix-Release passende Katalog-Dokumentation.

Eine praktische Hürde war der direkte Export auf die NAS-Freigabe: Der Hyper-V-Dienst und der angemeldete Administrator verwenden unterschiedliche Zugriffskontexte. Unser verlässlicher Weg war ein lokaler Export, anschliessender Dateitransport über das NAS und lokaler Import. Eine im Explorer erreichbare Freigabe ist nicht automatisch für den exportierenden Dienst zugänglich.

Vor dem ersten regulären Start bekommt der neue VDA eine eindeutige Netzwerk- und Windows-Identität. Danach folgen Domänenbeitritt, passende OU, wirksame GPOs, Profilberechtigungen und Citrix-Katalog beziehungsweise Delivery Group. Im Rollout wurden RDS-Lizenzierungseinstellungen erst nach einem zusätzlichen Neustart wirksam. Darum haben wir nach der Richtlinienanwendung auch den tatsächlichen Zustand geprüft.

Geklonte Verwaltungsidentitäten verdienen ebenfalls Aufmerksamkeit. Bei uns erschien ein neuer VDA zeitverzögert in WSUS. Eine kurze Wartezeit rechtfertigt noch keinen Reset der Update-Client-ID. Erst eine tatsächlich doppelte Identität ist ein Anlass für eine gezielte Korrektur auf dem neuen Klon.

Abnahme über den tatsächlichen Citrix Zugang

Zum Abschluss starten wir die veröffentlichte Anwendung über Citrix Workspace. Ein administrativer Login auf dem Server prüft einen anderen Weg. Auch die erfolgreiche Brokerregistrierung allein sagt noch nicht, ob Word mit dem richtigen Profil und Konto startet.

Für einen neuen VDA gehen wir die Aufgaben deshalb in dieser Reihenfolge durch: Erreichbarkeit und Richtlinien prüfen, Citrix-Registrierung kontrollieren, Word starten und den persönlichen Aktivierungsstatus ansehen. Danach prüfen wir Profilpersistenz und OneDrive mit einem konkreten Dateitest. Bei einem zweiten VDA wiederholen wir den Benutzertest nach vollständiger Abmeldung.

Der Word-Start mit persönlicher Aktivierung und das geladene FSLogix-Profil haben in unserem ersten Aufbau funktioniert. Der Betrieb der bereitgestellten Office-VDAs ist bestätigt. Automatische OneDrive-Anmeldung, parallele Profilnutzung und vollständiger serverübergreifender Token-Roaming-Test bleiben eigene Abnahmepunkte. Das verhindert, aus einem gelungenen ersten Start mehr abzuleiten, als tatsächlich geprüft wurde.

Betrieb und Wiederherstellung mitdenken

Eine Golden-Vorlage erleichtert neue Bereitstellungen. Persönliche Profilcontainer, Berechtigungen, GPOs und Citrix-Zuordnungen gehören zusätzlich in die Sicherungs- und Wiederherstellungsplanung. Auch ein FSLogix-Container ist keine Datensicherung seiner selbst.

Für Updates bietet sich ein Pilot-VDA an. Dort werden die tatsächlich eingesetzten Windows-, Citrix-, Office-, OneDrive- und FSLogix-Versionen zusammen geprüft, bevor weitere Maschinen folgen. Ein Installationsordner oder eine einzelne Buildnummer reicht nicht, um die gesamte Produktunterstützung zu beurteilen.

Für mich liegt der Nutzen dieser Einrichtung darin, den Zusammenhang der Komponenten besser zu verstehen. Der Registry-Pfad war eine kleine Einstellung mit grosser Wirkung. Die wiederverwendbare Vorlage macht aus dieser Erfahrung einen nachvollziehbaren Ablauf. Beim nächsten VDA beginnen wir dadurch mit einer dokumentierten Konfiguration und konkreten Prüfungen für die persönliche Sitzung.