Azure Virtual Desktop Teil 6  – Custom Image mit Office 365

Golden Master Image für Azure Virtual Desktop

Du hast in den vergangenen Teilen dieser Serie eine funktionsfähige Azure Virtual Desktop Umgebung aufgesetzt. Dabei haben wir uns in Bezug auf das Image für die Sessionshosts stets auf das Marktplatzangebot von Microsoft Azure verlassen. Wir waren zu dem Schluss gekommen, dass Windows 11 Multisession die idealen Voraussetzungen als Betriebssystem für die Sessionhosts einer VDI-Umgebung bietet, insbesondere in ge-poolten Umgebungen. Trotzdem möchtest du dein Master-Image möglicherweise für dein Unternehmen individualisieren. Wie das geht, zeigen wir dir in diesem Beitrag:

Passende Schulungen

AZ-104 Microsoft Azure Administrator (AZ-104T00)

AZ-104 Microsoft Azure Administrator (AZ-104T00): Azure Administration für Profis

AZ-140 Configuring and Operating Windows Virtual Desktop on Microsoft Azure (AZ-140T00)

Das Erstellen eines Custom-Images umfasst sowohl strategische als auch technologische Aspekte. Die strategischen Fragen, die du dir stellen musst, befassen sich unter anderem mit dem Aufwand zur Aktualisierung und Verwaltung des Images. Welches Verfahren du dabei wählst, hängt von verschiedenen Faktoren ab, einschließlich ihrer spezifischen Anforderungen, Ressourcen und der Größe ihrer Umgebung.

In jedem Fall solltest du die automatischen Windows-Updates deaktivieren, damit du die Kontrolle über den Aktualisierungsprozess behältst und zudem sicherstellst, dass Updates nicht zu unerwarteten Ausfallzeiten führen. Besser ist es, eine regelmäßige manuelle Aktualisierung deines Images vorzunehmen. Wie oft du dein Image aktualisierst, hängt von deinen spezifischen Anforderungen ab. Du kannst das beispielsweise monatlich oder nur alle paar Monate tun, allerdings sind deine Sessionhosts dann stets über einen längeren Zeitraum ohne Updates. Bedenke, dass Microsoft Client-Betriebssysteme alle 14 Tage mit Updates versorgt, was insbesondere im Hinblick auf die Virenscanner-Signaturen wichtig ist.

Strategische Fragen

Auf der anderen Seite bedeutet das regelmäßige manuelle Einspielen und Testen von Updates erheblichen Aufwand. Dabei geht es nicht nur um den Aufwand, für das Einspielen und Testen selbst. Du möchtest ja die Updates nicht auf den laufenden Sessionhosts anwenden, sondern auf dem zentralen Custom-Image, das sämtliche Sessionhosts unternehmensweit betankt. Du musst also …

• zunächst alle Benutzer-Sitzungen vom betroffenen Session-Host nehmen oder auf einen Anderen verschieben  – worin dich wiederrum das Profil-Roaming mittels FSlogix unterstützt,
• den Sessionhost beenden,
• aus dem bisherigen Masterimage eine neue VM erstellen,
• auf der neuen VM die gewünschten Updates einspielen,
• die VM generalisieren und daraus das neue Image erstellen,
• aus dem neuen Image wieder einen neuen, aktualisierten Sessionhost erstellen,
• den neuen Sessionhost wieder in den Hostpool aufnehmen
• und ggf. die zuvor verlagerten Benutzersitzungen wieder auf den neuen Sessionhost verlagern

Bei Windows 10/11-basierten Session-Host kann auch die Verwendung von Intune für das Bereitstellen von Aktualisierungen in Frage kommen. Dies sind nur ein paar Denkanregungen zu einer möglichen Aktualisierungsstrategie. Im Detail musst du die Strategie an deine Unternehmensbedürfnisse anpassen.

Technische Fragen

Die grobe technische Vorgehensweise zum Erstellen eines Custom Images ist Folgende:

Passende Schulungen

AZ-900 (2-tägig) – Microsoft Azure Fundamentals (AZ-900T00)

• Zunächst brauchst du eine VM. Am einfachsten im Kontext von AVD ist es, wenn du mit einer Azure-VM arbeitest, du könntest dein Image aber auch lokal unter Hyper-V erstellen.
• Installiere dann die in deinem Unternehmen benötigte Software. Dazu gehören Anwendungen wie Microsoft Office oder Teams, die deine Benutzer benötigen.
• Extrem wichtig ist, dass der Azure Virtual Desktop-Agent nicht bereits auf der VM installiert ist. Wenn er installiert ist, muss du ihm deinstallieren, bevor du das Image erstellst.
• Beim Erstellen eines Multisession-Images für Azure Virtual Desktop sollten Sie Windows 10 oder 11 Enterprise verwenden, u. a. wegen der enthaltenen VDA.
• Installiere keine OS-spezifischen Sprachpakete, bzw. deinstalliere alle Sprachpakete, falls diese schon installiert sind, weil sonst der spätere Sysprep-Prozess scheitert.
• Installiere ggf. die Office 365-Apps, wenn du diese in deinem Unternehmen benötigst. Dazu sind allerdings einige weitere Punkte zu beachten, die ich weiter unten erläutere.
• Dazu gehört auch, dass du ggf. Teams oder OnDrive nicht zusammen mit den o. g. Office-365-Apps im Pro-Benutzer-Modus, sondern nachträglich im Pro-Computer-Modus installierst, sofern du einen Hostpool im Pooling-Modus verwendest.
• Setze eine Reihe von für AVD nützlichen Registrierungseinstellungen.
• Vor der Generalisierung ist es eventuell nützlich, dein Image im Hinblick auf die Verwendung von AVD zu optimieren, wozu das Azure-Virtual-Desktop-Team von Microsoft ein nützliches Powershell-Skript zum Download bereitstellt. Siehe nächster Abschnitt:
• Auch wenn der Sysprep-Prozess viele Bereinigungsmaßnahmen von selbst berücksichtigt, solltest du vor dem Generalisieren deines Images dafür sorgen, dass auf diesem keine temporären oder benutzerspezifischen Daten mehr liegen. Da betrifft z. B. Verlaufsdaten, Mülleimer, Downloads usw.
• Schließe die Generalisierung nun durch den Einsatz von Sysprep ab. Dazu musst du sicherstellen, dass alle Benutzer abgemeldet sind und keine Anwendungen im Hintergrund laufen. Sysprep entfernt computerspezifische Informationen wie installierte Treiber und die Computersicherheits-ID (SID), damit du das Image problemlos auf verschiedenen PCs verwenden kannst.

Performance-Optimierung

Lade zur Performance-Optimierung das AVD Optimization Tool von https://github.com/The-Virtual-Desktop-Team/Virtual-Desktop-Optimization-Tool GitHub herunter und entpacke den Inhalt des Archivs in einem Ordner deiner Wahl:

Das Virtual Desktop Optimization Tool (VDOT) besteht aus einer Reihe textbasierter Tools, die Einstellungen auf ein Windows-Betriebssystem anwenden, um die Leistung zu verbessern. Die Leistungssteigerungen betreffen die Gesamtstartzeit, die Zeit der ersten Anmeldung, die Zeit der nachfolgenden Anmeldung und die Benutzerfreundlichkeit während einer Benutzersitzung.

Das VDOT-Tool ist mit einer Vielzahl von Systemen kompatibel. Es funktioniert auf VDI, AVD, eigenständigem Windows und Windows Server (mit einigen Einschränkungen) und einige Optimierungen werden sogar auf Windows 365 angewendet. Bei den Optimierungseinstellungen in diesem Tool handelt es sich um potenzielle Einstellungen, die die Rechenaktivität reduzieren und somit die Benutzerdichte pro Host erhöhen. Es ist wichtig, die Optimierungseinstellungen in der jeweiligen Umgebung zu testen und die Einstellungen bei Bedarf anzupassen.

In den mitgelieferten JSON-Konfigurations-Dateien legst du fest, was deaktiviert, entfernt oder als Richtlinie festgelegt werden soll. Die JSON-Dateien befinden sich im jeweiligen Betriebssystemversionsordner (z. B. „2009“). Der JSON-Parameter, den dieses Tool verwendet, um zu bestimmen, ob eine Einstellung angewendet werden soll oder nicht, ist „VDIState“. Wenn der Parameter „VDIState“ in der jeweiligen .JSON-Datei auf „Disabled“ gesetzt ist, wird die Optimierungseinstellung angewendet. Wenn „VDIState“ auf etwas anderes eingestellt ist, wird die Einstellung nicht angewendet.

Es ist an dieser Stelle müßig, jede einzelne Option zu erörtern. Hierzu muss ich auf die https://github.com/The-Virtual-Desktop-Team/Virtual-Desktop-Optimization-Tool/tree/main/2009/ConfigurationFiles Referenz verweisen. Du kannst aber testweise wie folgt sämtliche Optimierungen aktivieren und dann schauen, wie sie sich auswirken:

.\Windows_VDOT.ps1 -Optimizations All -AdvancedOptimizations All

Die Fertigstellung dieses Skripts dauert einige Minuten. Die Gesamtlaufzeit wird am Ende in den Statusausgabemeldungen angezeigt. Wurde das Skript vollständig ausgeführt, wird eine Aufforderung zum Neustart angezeigt. Warte auf diese Eingabeaufforderung, um zu bestätigen, dass das Skript erfolgreich abgeschlossen wurde. Dann ist ein Neustart erforderlich, da mehrere Elemente in der aktuellen Sitzung nicht gestoppt werden können. Der Parameter „-verbose“ in PowerShell weist das Skript an, während der Ausführung des Skripts eine beschreibende Ausgabe bereitzustellen.

Office-Installation

Zur Office-365-Installation musst du zwingend das  https://www.microsoft.com/en-us/download/details.aspx?id=49117 Office-Bereitstellungstool nutzen. Windows 10 Enterprise (mehrere Sitzungen) und Windows 11 Enterprise (mehrere Sitzungen) unterstützen nur die folgenden Versionen von Office:

• Microsoft 365 Apps for Enterprise
• Microsoft 365 Apps for Business mit einem Microsoft 365 Business Premium-Abonnement

Für das Office-Bereitstellungstool wird eine XML-Konfigurationsdatei benötigt.  Darin stehen die Installationsoptionen.  Details zum Office Deployment Tool (ODT) findest du z. B. hier: https://learn.microsoft.com/deployoffice/overview-office-deployment-tool

Mit dem Office Deployment Tool (ODT) kannst du die Microsoft 365 Apps herunterladen und auf deinen Client-Computern bereitstellen. Das gilt auch für deinen Session-Host. Das Office-Bereitstellungstool bietet dir eine optimale Kontrolle über eine Office-Installation. So kannst du z. B. definieren, welche Produkte und Sprachen installiert werden, wie diese Produkte aktualisiert werden sollen und ob den Benutzern der Installationsvorgang angezeigt werden soll.

Konkret besteht das ODT aus zwei Dateien: „setup.exe“ und „configuration.xml“. Um mit dem Tool zu arbeiten, bearbeite die Konfigurationsdatei, um die gewünschten Optionen zu definieren und führe dann „setup.exe“ über die Befehlszeile aus. Du kannst z. B. die Konfigurationsdatei bearbeiten, um die englische 64-Bit-Version von Office zu installieren, wobei die Lizenzbedingungen automatisch akzeptiert werden. Den vollständigen Satz von Optionen findest du https://learn.microsoft.com/deployoffice/office-deployment-tool-configuration-options hier.

Microsoft empfiehlt beim Erstellen der Konfigurationsdatei, dass du mit einer Beispieldatei startest und diese um die entsprechenden Optionen für deine Umgebung ergänzt. Ich habe im Folgenden das Standard-Beispiel von Microsoft verwendet und darin lediglich die Spache auf „de-DE“ geändert. Wie du siehst, werden außerdem Groove, Lync, OneDrive und Teams zunächst aus der Installation ausgeschlossen, um später im Per-Device-Modus installiert werden zu können. Zudem wird automatisch die EULA akzeptiert, um O365ProPlusRetail im Standardpfad zu installiert und die Shared-Computer-Activation (SCA) aktiviert.

<Configuration>

  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">

    <Product ID="O365ProPlusRetail">

      <Language ID="en-US" />

      <Language ID="MatchOS" />

      <ExcludeApp ID="Groove" />

      <ExcludeApp ID="Lync" />

      <ExcludeApp ID="OneDrive" />

      <ExcludeApp ID="Teams" />

    </Product>

  </Add>

  <RemoveMSI/>

  <Updates Enabled="FALSE"/>

  <Display Level="None" AcceptEULA="TRUE" />

  <Logging Level="Standard" Path="%temp%\WVDOfficeInstall" />

  <Property Name="FORCEAPPSHUTDOWN" Value="TRUE"/>

  <Property Name="SharedComputerLicensing" Value="1"/>

</Configuration>

Die wichtigsten Einstellungen, die du hier setzen kannst, sind Folgende:

Dank der vorbereiteten xml-Datei wird alles so installiert, dass keine Benutzerinteraktion erforderlich ist. Dann rufst du die setup-Datei auf mit …

setup.exe /configure configuration.xml

und wartest ab. Das Skript läuft ohne jegliche Rückmeldung in der CMD und braucht seine Zeit. Sobald sich der Cursor auf der CMD zurückmeldet, ist die Office-Installation erledigt.

Danach musst du eine Reihe von Registrierungsschlüsseln setzen, zumindest wenn du wie hier ein Image für AVD erstellst. Diese findet sich ebenfalls in der Dokumentation. Daher packst du die Einstellungen am besten in eine Batch-Datei, wie z. B. „office_reg_keys.cmd“.

rem Mount the default user registry hive
reg load HKU\TempDefault C:\Users\Default\NTUSER.DAT
rem Disable the option for Office Insider under File > Account
rem Must be executed with default registry hive mounted
reg add HKU\TempDefault\SOFTWARE\Policies\Microsoft\office.0\common /v InsiderSlabBehavior /t REG_DWORD /d 2 /f
rem Set Outlook's Cached Exchange Mode behavior
rem Must be executed with default registry hive mounted
reg add "HKU\TempDefault\software\policies\microsoft\office.0\outlook\cached mode" /v enable /t REG_DWORD /d 1 /f
reg add "HKU\TempDefault\software\policies\microsoft\office.0\outlook\cached mode" /v syncwindowsetting /t REG_DWORD /d 1 /f
reg add "HKU\TempDefault\software\policies\microsoft\office.0\outlook\cached mode" /v CalendarSyncWindowSetting /t REG_DWORD /d 1 /f
reg add "HKU\TempDefault\software\policies\microsoft\office.0\outlook\cached mode" /v CalendarSyncWindowSettingMonths  /t REG_DWORD /d 1 /f
rem Unmount the default user registry hive
reg unload HKU\TempDefault
rem Set the Office Update UI behavior for updates
reg add HKLM\SOFTWARE\Policies\Microsoft\office.0\common\officeupdate /v hideupdatenotifications /t REG_DWORD /d 1 /f
reg add HKLM\SOFTWARE\Policies\Microsoft\office.0\common\officeupdate /v hideenabledisableupdates /t REG_DWORD /d 1 /f

Sysprep

Nun bist du bereit, die Generalisierung der VM mittels Sysprep durchzuführen. Du könntest Sysprep dazu zwar in der GUI aufrufen (unter C:\Windows\System32\Sysprep) und die beiden Optionen  …

• System-Cleanup Action: OOBC (Out-Of-the-box-Experience)
• Shutdown-Option: Shutdown

setzen, in der Praxis ist es aber für AVD oder RDS (also generell bei virtuellen Maschinen) besser, das nicht zu tun, da du in der GUI die Option „mode:vm“ nicht setzen kannst.

Diese deaktiviert nämlich die Windows-Hardwareerkennung, welche beim späteren Hochfahren einer VM aus diesem Image bis zu 45 min in Anspruch nehmen kann. Da die virtuelle Hardware aber bei unseren Hyper-V-/Azure-VMs immer gleich ist, verwendest du Sysprep auf der Kommandozeile mit

           ..sysprep /generalize /shutdown /oobe /mode:vm

Nun musst du nur noch im Azure-Portal aus der generalisierten VM ein Image erstellt.

Wie das geht und was der Unterschied ist zwischen einem verwalteten Image, eine Azure Image Gallery und einer Azure Compute Gallery verrate ich dir im nächsten Teil.