Custom-Image für Azure Virtual Desktop (AVD) erstellen

Bisher haben wir Sitzungshosts für Azure Virtual Desktop (AVD) stets aus Standard-Marktplatz-Images von Microsoft erstellt. Derzeit bietet z. B. „Windows 11 Enterprise multi-session, Version 23H2 + Microsoft 365 Apps – Gen2“ eine ideale Basis für Client-OS-basierter Windows-Desktops. Möchtest du hingegen eigene Software oder Erweiterungen in deinem Image verankern, musst du ein eigenes erstellen. Wie das geht, zeigen wir dir im Folgenden:

Erstellst du deine Sessionhosts stets aus einem Marktplatz-Image von Microsoft, hast du zwar die Sicherheit, dass deine Sessionhosts stets auf einem aktuellen und überprüften Image bereitgestellt werden, du muss dich dann aber auf jeden Fall um die Bereitstellung der für dein Unternehmen wichtigen Anwendungen, Treiber und Erweiterungen kümmern. Daraus ergibt sich wiederrum automatisch die Frage, wo du solche Dinge „pflegen“ möchtest, im OS des Sitzungshosts oder im Image. Das gilt gleichermaßen für anstehenden Aktualisierungen. Erstellst du Sessionhosts immer nur aus dem Basis-Image und rüstest erst dann deine Sessionhosts mit einer möglicherweise großen Anzahl individueller Anpassungen aus, entsteht mit Sicherheit ein erheblicher Wartungsaufwand, spätestens dann, wenn du vorhandene Sessionhosts ersetzen musst oder Neue hinzufügen möchtest. Ich deute hier nur einige der dabei zu berücksichtigen Fragen und Themen an, weil dieser Artikel eigentlich nicht die „Warum“-Frage klären soll, also warum du benutzerdefinierte Images benötigt, sondern in erste Linie die „Wie-Frage“.

• Hast du eine geeignete Automatisierung, um Software und Erweiterungen auf einer ggf. großen Anzahl von Sessionhosts mit vertretbarem Aufwand zu verteilen? Bist du z. B. mit Configuation Manager, Intune und/oder Gruppenrichtlinien vertraut?
• Hast du dir Gedanken über die Bereitstellung von Windows-Updates für deine Sessionhosts gemacht (automatische Windows Updates, WSUS, Azure Update Manger) oder ist es nicht sinnvoller, dein zentrales Custom-Images zu aktualisieren?
• „Wo“ und „wie“ möchtest du Anwendungen für AVD bereitstellen? Du kannst nämlich die benötigten Anwendungen von vorneherein in deinem Custom-Image integrieren (die Variante, welche ich hier in den Vordergrund stelle), was allerdings Erstellung und Pflege des Custom-Images aufwendiger macht. Du kannst Anwendungen dann als Remote-Apps oder im Rahmen eines vollständigen Session-Desktops ausliefern.
• Du kannst Anwendungen natürlich auch erst „nach“ Bereitstellung der Sessionhosts auf Diesen installieren. Dies erfordert wieder erheblichen Aufwand bei der Automatisierung aus außerdem geht der „Zustand“ verloren, wenn du einen Sessionhost neu bereitstellen musst.
• Sind deine Anwendungen hingegen im Image enthalten, kannst du immer wieder identisch konfigurierte Sessionshosts schnell bereitstellen, übrigens auch Mehrere gleichzeitig aus dem gleichen Image.

Das sind nur ein paar Anregungen und Überlegungen. Im Detail hängen strategische Überlegungen dieser Art natürlich von vielen spezifischen Bedingungen in deiner Umgebung ab, weshalb es hierzu auch keine eindeutigen Best Practises gibt, weder von mir noch vom Microsoft. Nun aber zu den konkreten Schritten zum Erstellen eines benutzerdefinierten Images. Hierzu verwenden wir Microsoft Windows 11 Multisession als Basis. Sofern du auch MS-Office in dein Image integrieren möchtest, kannst du natürlich auch gleich wie eingangs erwähnt das Marktplatz-Image mit Office 365 Apps verwenden. Du musst dann ggf. noch Teams mit dem systemweiten Installer deinstallieren, um Team im Per-Device-Mode neu installieren zu können. Möchtest du hingegen nur ausgewählte M365-Apps in deinem Image haben, verwende das Windows-11-Basis-Image ohne M365-Apps. Ich werden mich unter anderem deshalb in diesem Beitrag auf letzteres beschränken, weil eine angepasste Office-Bereitstellung im Image sehr aufwendig ist. Quellen und Denkanregungen zu diesem User-Case werde ich dir aber trotzdem liefern. Beginnen wir aber nun mit den Basics.

Eine VM als Basis für das Image

Du brauchst eine Basis für die Image-Erstellung. Dazu gibt es prinzipiell zwei Wege. Die erste Option besteht darin, dass du einen virtuellen Computer in Azure bereitstellst und aus diesem ein Image erzeugst.

Die zweite Möglichkeit ist, das Image lokal zu erstellen, indem du eine Hyper-V-VM bereitstellst, an deine Anforderungen anpasst, aus dieser eine VHD exportierst, sie dann nach Azure hochlädst (z. B. im einen Blob-Container) und aus der VHD ein Image in Azure generierst. Außerdem gibt es bei Microsoft ein Powershell-Werkzeug namens Image-Builder, welches ich aber an dieser Stelle nicht bespreche. Wir verwenden hingegen eine Azure-VM als Basis. Erstelle zunächst mit der Methode deiner Wahl (Azure Portal, Azure Powershell, Azure CLI, ARM-Template oder per Bicep-Vorlage) eine gewöhnliche Azure-VM mit Windows 11-Enterprise Multisession. Da du dich anschließend mit der VM verbinden können musst, schaffe dazu eine Möglichkeit, im einfachsten Fall RDP über eine öffentliche IP-Adresse, RDP über die private IP-Adresse, falls es in deinem Unternehmen ein VPN zu Azure gibt oder via Azure Bastion. Da wir die VM lediglich kurzfristig zur Image-Erstellungen benötigen, verwende ich in diesem Beispiel ebenfalls eine Public IP. Hat sie die Standard-SKU, was unbedingt zu empfehlen ist (Basic ist ohnehin zum 30.09.2025 abgekündigt), brauchst du außerdem eine Network Security Group und darin eine Eingangs-Zulassungs-Regel für RDP (3389). Die notwendigen Schritte sollten aus zahlreichen Beiträgen in diesem Blog bekannt sein.

Achtung: Erstellst du die VM wie in diesem Fall nicht explizit als Sessionhost-VM aus einem Hostpool heraus, sondern als reguläre Azure-VM im Azure-Portal, taucht „Windows 11 Pro Multisession“ nicht in der angebotenen Standard-Image-Auswahlliste auf, lediglich „Windows 11 Pro 22H2“. Du musst dann explizit auf „Alle Images anzeigen“ klicken, um zum Marktplace zu gelangen. Dort suchst du nach „Windows 11“ und klickst beim entsprechenden Angebot von Microsoft auf „Auswählen“. Hier findest du das gewünschte Image. Erlaubst du direkt im ersten Tab „Grundeinstellungen“ das Öffnen des Eingangsports RDP (3389), kannst du die VM direkt von hier aus erstellen lassen, weil die übrigen Default-Einstellungen dafür sorgen, dass ein passenden virtuelles Netzwerk, die zugehörige Netzwerksicherheitsgruppe und eine öffentliche IP-Adresse erhältst.

Anpassungen für den Image-Nutzung

Hast du die Windows-VM erstellt, verbindest du dich mit der Console der VM, um eine Reihe von Vorbereitungen treffen zu können, welche das System als optimale Image-Vorlage zu prädestinieren. Dazu gehört auch das Installieren deiner unternehmensspezifischen Anwendungen wie z. B. Office-365. Als Beispiel für eine unternehmensspezifische App wollen wir in diesem Beispiel Microsoft Teams bereitstellen, allerdings im Per-Machine-Mode und nicht im Per-User-Mode. Da viele Microsoft-Windows-Client-Images jedoch den systemweitern Teams-Installer bereits enthalten, solltest du diesen zunächst bereinigen und weitere Vorbereitungen treffen, um Teams im Per-Device-Mode zu installieren. Ist Teams in deinem Ausgangs-Image nicht enthalten, kannst du die nächsten Schritte ignorieren.

Setze zunächst in einer CMD im Administrator-Mode folgenden Registry-Code:

reg add "HKLM\Software\Microsoft\Teams" /v IsWVDEnvironment /t REG_DWORD /d 1 /f

Mit diesem gibst du praktisch an, dass die Teams-Umgebung in einer Windows Virtual Desktop (WVD)-Umgebung installiert wird.

Danach musst du Microsofts Visual C++ Redistributable https://aka.ms/vs/16/release/vc_redist.x64.exe herunterladen und installieren. Das kannst du ggf. auch gleich in der CMD erledigen

~<Download-Pfad>vc_redist.x64.exe /install /passive /norestart /log ~<Download-Pfad>\vc_redist.log.

Dann kannst du Teams in der https://learn.microsoft.com/en-us/microsoftteams/teams-for-vdi#deploy-the-teams-desktop-app-to-the-vm 64Bit-Version herunterladen und im obrigen Download-Pfad speichern.

Das Installieren von Teams im Per-Device-Mode funktioniert dann mit:

msiexec /i C:\Allfiles\Labs\Teams_windows_x64.msi /l*v C:\Allfiles\Labs\Teams.log ALLUSER=1

Das bewirkt der Parameter ALLUSER=1

Nun wendest du der Reihe nach in deiner CMD-Sitzung (im Admin-Mode) oder im Regedit eine Reihe von Registrierungsschlüsseln an, die letztendlich alle dazu dienen, dein Image für den Einsatz als AVD-Sitzungshost zu optimieren. Das sind z. B. Folgende:

Deaktivieren der automatischen Windows-Updates:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU" /v NoAutoUpdate /t REG_DWORD /d 1 /f

Deaktivieren von Storage Sense

reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\StorageSense\Parameters\StoragePolicy" /v 01 /t REG_DWORD /d 0 /f

Konfigurieren der Zeitzonen-Umleitung:

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v fEnableTimeZoneRedirection /t REG_DWORD /d 1 /f

Deaktivieren des Einsammeln von Telemetriedaten (Feedback Hub).

reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DataCollection" /v AllowTelemetry /t REG_DWORD /d 0 /f

Außerdem solltest du den Download-Ordner löschen, den du oben z. B. für das Teams-Setup verwendet hast, sofern dies nicht der Standard-Download-Ordner des jeweiligen Anmeldeprofils war.

Zum Schluss empfiehlt es sich, das Disk-Cleanup-Werkzeug laufen zu lassen:

cleanmgr /d C: /verylowdisk

Das sind lediglich einige Vorschläge zum Vorbereiten eines Images. Geradezu aufdrängen für den Einsatz als AVD-Image würde sich das Installieren von FSLogix. Wie du die Roaming-Profil-Lösung auf einem Sitzungshost installierst, haben wir bereits in einem anderen beitrag beschrieben. Du kannst dir die Mühe sparen, wenn du das Markplatz-Image „Windows 11 Enterprise Multisession“ als Ausgangsbasis für die weiteren Schritte verwendest, denn in diesem ist seit einiger Zeit FSlogix bereits vorinstalliert, wie du der Abbildung unten entnehmen kannst.

Weitere Empfehlungen findest du in der AVD-Dokumentation. Das Installieren von Teams ist als Vorschlag für eine Unternehmensanwendung zu verstehen. Möchtest du beispielsweise MS-Office in deinem AVD-Image einsetzen, findest du tiefergehende Informationen dazu in der https://learn.microsoft.com/azure/virtual-desktop/install-office-on-wvd-master-image AVD-Dokumentation. Das betrifft z. B. auch Lizenz-Themen wie etwa die für den Mehrbenutzerbetrieb auf einem Client-basierten Sitzungshost erforderliche „Shared Computer Activation“ (SCA).

Azure Virtual Desktop Optimization Tool (VDOT)

Die bisherigen Anpassungen zielten primär darauf ab, die in deinem Unternehmen benötigten Anwendungen und Erweiterungen in der geeigneten, bzw. optimalen Weise zur Verfügung zu stellen. Geht es speziell um das Erstellen eines Images für Azure Virtual Desktop (was ja nur einen Anwendungsfall unter vielen für den Einsatz virtueller Client- und Server-Maschinen in Azure darstellt), ist zusätzlich noch das Azure Virtual Desktop Optimization Tool (VDOT) erwähnenswert. Hierbei handelt es sich um ein Powershell-Skript, das von Microsofts Azure Virtual Desktop Team kostenlos auf https://github.com/The-Virtual-Desktop-Team/Virtual-Desktop-Optimization-Tool GitHub zur Verfügung gestellt wird.

Prinzipiell handelt es sich dabei um eine Reihe von meist textbasierten Tools, die Einstellungen auf ein Windows-Betriebssystem anwenden, um die Leistung zu verbessern. Die Leistungssteigerungen betreffen die Gesamtstartzeit, die Zeit für die erste Anmeldung, die Zeit für nachfolgende Anmeldungen und die Benutzerfreundlichkeit während einer Benutzersitzung. Das VDOT-Tool entstand laut Microsoft aus jahrelanger Leistungsoptimierung der lokalen Virtual Desktop Infrastructure (VDI). Solche VDI-Implementierungen waren oft nicht oder nur eingeschränkt mit dem Internet verbunden, wodurch einige Features und/oder Funktionen von Windows nicht funktionsfähig waren. Anstatt nicht funktionsfähige Komponenten auszuführen, wurden diejenigen Elemente deaktiviert oder entfernt, die auf unterstützte Weise deaktiviert oder entfernt werden konnten. Das Ergebnis waren ein schnellerer Start, eine schnellere Anmeldung und ein reibungsloserer Benutzerbetrieb während der gesamten Benutzersitzung. Später, als Azure Virtual Desktop (AVD) auf den Markt kam, wurde das VDOT-Tool so gestaltet, dass es AVD unterstützt, ohne die Benutzeroberfläche zu verschlechtern, die Funktionalität zu verringern oder die AVD-Sitzungshosts in irgendeiner Weise zu beeinträchtigen. Das VDOT-Tool ist in seiner jetzigen Form mit einer Vielzahl von Systemen kompatibel. Es funktioniert auf VDI, AVD, eigenständigen Windows-Systemen, Windows Server (mit einigen Einschränkungen) und einige Optimierungen werden sogar auf das Windows 365-Angebot angewendet. Bei den Optimierungseinstellungen handelt es sich primär und solche Einstellungen, welche die Rechenaktivität reduzieren und so die Benutzerdichte pro Host erhöhen. Microsoft weist darauf hin, dass es wichtig ist, die einzelnen Optimierungseinstellungen in der jeweiligen Umgebung zu testen und die Einstellungen nach Bedarf anzupassen.

Welche Einstellungen dabei im Detail zum Einsatz kommen, legst du mit Hilfe von VDOT-Konfigurationsdateien fest. Hierbei handelt es sich um eine gruppierte Sammlung von JSO-Dateien, in denen du bestimmst, was deaktiviert, entfernt oder als Richtlinie festgelegt werden soll. Die  .JSON-Dateien findest du nach dem Klonen oder Herunterladen des kompletten Repositories im jeweiligen Ordner der Betriebssystemversion (z. B. „2009“).

Es würde den Rahmen des Beitrags deutlich sprengen, die einzelnen Einstellungen an dieser Stelle durchzugehen.

Da ich aber davon ausgehe, dass du erste Exprimente mit deinem Image ohnehin erstmal ausprobierst, spricht nichts dagegen, wenn du probeweise alle Einstellungen anwendest. Lass die mitgelieferten JSON-Dateien unverändert (d. h. du übernimmst dann bei vielen Einstellungen die Default-Werte) und rufts das PS-Skript mit folgendem Parameter auf:

 .\Windows_VDOT.ps1 -Optimizations All -AdvancedOptimizations All

Achtung: wie üblich, lässt sich unter Windows ein aus dem Internet heruntergeladenes PS-Skript nicht ohne weiteres ausführen. Rufe also unter Windows die Einstellungen der Skript-Datei „Windows_VDOT“ auf und setzen um Tab „Allgemein“ im Abschnitt „Sicherheit“ die Option „Zulassen“.

Möchtest du effektiv testen, ob die Maßnahmen des VDOT-Skriptes etwas bringen, kannst du vor Ausführen des Skriptes z. B. mit Perfmon oder im Performance-Monitor des Taskmanagers die CPU-Metriken anschauen.

Beobachte die Werte für Prozesse, Threads und Handles und vergleiche die Situation nach dem Neuenstart, wenn du das Optimierungsskript ausgeführt hast. Theoretisch sollte sich hier eine kleine Verbesserung zeigen, weil ja. u. a. nicht benötigte Hintergrundprozesse deaktiviert wurden.

Sysprep

Nun bist du bereit für die Generalisierung. Das hierfür vorgesehene Microsoft-Werkzeug heißt bekanntlich „Sysprep“, zu finden unter C:\Windows\System32\ und seit Windows NT.4.0 per Default unter den Bordwerkzeugen. Der Name Sysprep deutet auf den Verwendungszweck: Systemvorbereitung. Das Tool bereitet eine Windows-Server oder Client-Installation für das Imaging vor. Dazu entfernt es Computer-spezifische Informationen aus einer Windows-Installation und „verallgemeinert“ damit das System derart, dass daraus ein neues System auf verschiedenen Rechnern installiert werden kann. Du kannst beim Ausführen von Sysprep konfigurieren, ob der neu zu installierende PC im „Überprüfungsmodus“ oder auf der Windows-Willkommensseite („Out-of-Box Experience“, OOBE) starten soll. Du stellst die beiden beschriebenen Parameter stellst in der minimalistischen grafischen Oberfläche von Syspep ein. Für den Einsatz als Image für AVD wählst du bei „System Cleanup Action“ den Eintrag „Enter System Out-of-the-Box Experience (OOBE)“ und bei „Shutdown Options“ den Eintrag „Shutdown“. Außerdem musst den Haken „Generalize“ aktivieren.

Allerdings empfehle ich dir speziell beim Einsatzweck Imaging für Azure Virtual Desktop (AVD) nicht, die grafische Oberfläche von Sysprep zu verwenden. Öffne stattdessen eine CMD im Administrator-Modus und mache es so:
C:\Windows\System32\Sysprep\sysprep.exe /oobe /generalize /shutdown /mode:vm

Nur dann kannst du nämlich den für AVD, bzw. generell für den Einsatzweck der Generalisierung für virtuelle Maschinen erforderlichen Parameter „/mode:vm“ setzen, den die GUI nicht vorsieht. Warum ist der wichtig? Wird die Generalisierung ohne den Parameter angestoßen, führt Windows beim Erstellen einer neuen physischen oder virtuellen Maschine aus dem generalisierten Image in jedem Fall eine Hardwareerkennung durch, was eine Zeit von bis zu 45 min in Anspruch nehmen kann. Ist dein Ziel aber ohnehin eine VM (im Falle von Azure quasi eine Hyper-V-VM) ist die virtuelle Hardware immer die Gleiche und muss nicht erst mühselig erkannt werden. Bei VMware/ESXi gilt das Gleiche, ebenso bei Xen oder KVM. Das Erstellen neuer VMs aus deinem Custom-Image geht also wesentlich schneller, wenn du das Sysprepping mit dem genannten Parameter über die CMD durchführst:

Lege also los.

Der Sysprep-Prozess selbst dauert nur wenige Minuten. Dabei wird die Ausgangs-VM heruntergefahren, sodass deine RDP-Verbindung automatisch geschlossen wird.  Der Status im Azure-Portal ist dann „Beendet“ aber nicht „Beendet (Zuordnung aufgehoben), d. h. diese VM verursacht die weiterhin Kosten.

Achtung: Du hast eine generalisierte VM. Diese Methode wird oft verwendet, um eine VM für die Bereitstellung auf mehreren Computern vorzubereiten. Nach dem Generalisieren kann die VM auf verschiedenen Hardwarekonfigurationen verwendet werden.

Ein Image ist eine vollständige Kopie eines Betriebssystems, das auf einem Computer oder einer VM installiert ist. Es enthält alle installierten Anwendungen, Treiber und Konfigurationen. Images werden allgemein verwendet, um eine standardisierte Umgebung schnell auf mehreren Computern bereitzustellen. Sie können mit Tools wie DISM oder PowerShell (Image Builder) erstellt werden. Für Azure VMs gibt es dazu ein grafisches Werkzeug im Azure-Portal, welches wie uns im nächsten Schritt ansehen werden. Speziell für Azure/AVD gilt: Ein Image kann auch (muss aber nicht) generalisiert werden, um es auf verschiedenen Hardwarekonfigurationen zu verwenden, aber es ist in erster Linie eine Methode zur schnellen Bereitstellung einer vorkonfigurierten Umgebung. Wie kommst du also jetzt zu einem Image?

Custom Image und Azure Compute Gallery

Navigiere im Azure-Portal zu deiner generalisierten und ausgeschalteten VM und klicke auf der Übersichtsseite auf die Schaltfläche „Aufnahme“. Die deutsche Übersetzung ist etwas unglücklich geraten. Im englischen Azure-Portal steht hier „Capture“, was die Sache besser trifft. Wähle dann im Klapp-Menü den Untereintrag „Bild“ (deutsch), bzw. „Image“ (englisch). Du landest dann im Portal „Image erstellen“.

Hier hast du die Wahl zwischen zwei verschiedenen Image-Verfahren, nämlich „verwaltetes Image“ und „Image Gallery“; Letzteres ist seit einiger Zeit Default und sollte auch bevorzugt werden. Ein gewöhnliches „verwaltetes Image“ kann im Gegensatz zu einem Image in einer Image Galerie z. B. nicht repliziert, geteilt, kopiert oder veröffentlicht werden, während du ein Image aus eine Image Gallery mit anderen Benutzern in deinem Mandanten teilen kannst. Das geht mit entsprechenden Freigabeberechtigungen sogar Abonnement- und sogar Mandanten-Übergreifend.  

Außerdem kannst du bei einer Image Galerie mehrere Versionen eines Images verwalten und auch mehrere VMs gleichzeitig aus dem gleichen Image erstellen. Übrigens wird das gewöhnliche verwaltete Image nicht unterstützt, wenn du einen VM-Typ mit vertrauenswürdigen Start verwendest. In diesem Fall bräuchtest du den Standard-Typ.

Bevor wir mit der Image-Erstellung via Azure Image Gallery (welche Microsoft übrigens vor einiger Zeit im „Azure Compute Gallery“) umbenannt hat fortfahren, werfen wir einen Blick auf die Nutzung eines Custom-Images beim Erstellen einer neuen VM. Klickst du hier im Tab „Grundeinstellungen“ auf den Link „Alle Images anzeigen“ landest du bekanntlich im Markplatz vom Microsoft. Von hier aus kannst du links oben bei „Andere Elemente“ auf „Meine Bilder“ klicken, um zu deinen verwalteten Images zu gelangen oder auf „Freigebener Bilder“ für die Azure Compute Gallery“. Außerdem gibt es noch „Communitybilder“. Ich habe hier die unglückliche deutsche Übersetzung übernommen.

Doch zurück zur Image-Erstellung selbst. Wie oben beschrieben kannst du diese konkret von der betreffenden VM aus initiieren, indem du auf „Aufnahme“ klickst. Nun wählst du nur noch deine Ressourcengruppe; „Region“ und „Abonnement“ ergeben sich automatisch durch die VM. Darunter wählst du den Typ des Images, also „Verwaltetes Image“ oder „Azure Compute Gallery“. Wie oben schon erwähnt, scheidet im meinem Beispiel erste Option ohnehin aus, weil die bei einer VM mit vertrauenswürdigem Start nicht unterstützt wird. Die Azure Compute Gallery ist ohnehin die bessere Option, weil sie nur Vorteile und keine Nachteile hat. Du solltest die Option „Diesen virtuellen Computer nach dem Erstellen des Images automatisch löschen“ setzen, weil die VM als solche nach der Image-Erstellung ohnehin nicht mehr benutzbar ist.

Im Abschnitt „Details zum Katalog“ erstellt du deine „Azure Compute Gallery“. Dieses hättest du auch vorher erstellen können, wenn du im Azure Portal nach dem Dienst „Azure Compute Gallery“ suchst. Klicke also auf „Neu erstellen“ und gebe deiner Galerie einen Namen. Dann wählst du den „Betriebssystemstatus“. Hiermit teilst du dem System mit, ob die VM, aus der das Image erstellt werden soll generalisiert ist oder nicht. Bei „Generalisiert“ müssen für VMs, die du aus diesem Image erstellst, Hostname, Administratorbenutzer und andere VM-bezogene Einstellungen beim ersten Start neu festgelegt werden. Bei „Spezialisiert“ bekommst du immer eine vollständig konfigurierte VM. Unsere VM ist generalisiert, weil wir das Image später nutzen möchten, um daraus viele neue VM erstellen zu können.

Nun musst du eine „Imagedefinition“ erstellen, indem du auf den gleichnamigen Link klickst:  Diese hat einen „Namen“ und die zugehörigen beschreibenden Metadaten, wie den Betriebssystemtyp, die VM-Generation, den Sicherheitstyp, die VM-Architektur (x64 / Arm64) usw., denn Azure muss ja beim Bereitstellen der „VM-Hülle“ wissen, wie Diese auszusehen hat, damit darin das OS, welches im Image steckt, problemlos ausgeführt werden kann. Ferner brauchst du folgende drei Micosoft-typischen SKU-Informationen, nämlich „Herausgeber“, „Angebot“ und „SKU“, in unserem Fall also „microsoftwindowsdesktop“, „windows-11“ und „win11-23h2-avd“. Die weiteren „Veröffentlichungsoptionen“ sind optional.

Klicke auf „OK“ und dann auf „Überprüfen und erstellen“ und wende dich im Hauptteil des Dialoges „Image erstellen“ den „Versionsdetails“ zu, denn in einer Azure Compute Gallery kannst du mehrere Versionen des gleichen Images pflegen. Starte z. B. mit 0.0.1. Außerdem kannst du die Lebensdauer deines Images beschränken, um sicherzustellen, dass in deinem Unternehmen immer nur VMs erstellt werden können, die eine gewisse Aktualität aufweisen.

Ferner kannst du ein Image einer Azure Compute Gallery bei Bedarf automatisch in eine andere Region replizieren lassen, um aus dem gleichen Image auch VMs in anderen Regionen erstellen zu können. So könntest du z. B. stets das neueste Image in mehreren Regionen replizieren, während alle älteren Versionen nur in einer einzigen Region verfügbar sind, um Speicherkosten für VM-Imageversionen zu sparen. Ich gehe allerdings in diesem Beitrag nicht weiter auf die zahlreichen Konfigurationsmöglichkeiten für die Replikation ein, ebensowenig auf die Freigabemöglichkeiten, weil beides den Umfang sprengt. Beide Funktionalitäten stehen übrigens bei einem gewöhnlichen verwalteten Image nicht zur Verfügung.

Übernimm ggf. an dieser Stelle einfach die vorgeschlagenen Default-Einstellungen. Wenn du beim Speicher etwas Geld sparen willst, kannst du bei der Standard-SKU für Speicher z. B. HDD-Standard, LRS“ statt zonenredundant auswählen. Das hat natürlich keinen Einfluss auf die Performance der VMs, die du später daraus erstellst, denn Diese bekommen ja ihre eigenen Datenträger. Es geht nur um die Haltbarkeit des Images (LRS bietet immer noch 99,999999999 %) sowie die Performance der Erstellung, insbesondere wenn du mehrere VMs gleichzeitig aus dem Image erstellst.

Klicke nun auf „Überprüfen und Erstellen“. Nach wenigen Minuten findest du eine Azure-Compute-Gallery-Ressource in deinem Azure-Account.

Neue VM erstellen

Möchtest du nun testweise eine neue VM aus diesem Image erstellen hast du dazu zwei Möglichkeiten. Eine habe ich oben bereits angedeutet. Erstelle also einfach eine neue VM im Azure-Portal, wie du es gewohnt bist und klicke bei der Image-Auswahl auf „Alles Images anzeigen“, um zum Marktplatz zu gelangen. Dort klickst du auf „Freigegebene Bilder“, um dort dein neues Image auswählen zu können.

Auf diese Weise kommst du also mit der Azure Compute Gallery eigentlich gar nicht in Berührung.

Du kannst auch im Azure-Portal nach „Azure Compute Gallery“ suchen und dann zunächst „in“ dein Azure Compute Gallery navigieren. Du landest wie üblich auf deren Übersichtsseite.

Hier könntest du dann z. B. unter „Einstellungen / Konfiguration“ Anpassungen vornehmen oder unter „Automation“ entsprechende Automatisierungsaufgaben einrichten.

Möchtest du nun aus deinem Image eine neue VM erstellen, klicke oben auf die Schaltfläche „Virtuellen Computer erstellen“. Alternativ kannst du mit der Schaltfläche rechts davon auch gleich ein VM-Scaleset erstellen.