Daniel's Tech Blog

Cloud Computing, Cloud Native & Kubernetes

Windows Client OS – WAP VM Role Gallery Item

English version: Windows_Client_OS_WAP_VM_Role_Gallery_Item.pdf

Wie man Windows Server oder Linux als VM Role Gallery Item für das Windows Azure Pack Portal bereitstellen kann, dafür gibt es zahlreiche gute Anleitungen und ist vermutlich jedem, der sich mit dem WAP beschäftigt, auch bekannt.

Aber wie sieht es mit dem Windows Client OS aus? Dazu findet sich leider sehr selten etwas. Mein MVP Kollege Marc van Eijk hat folgenden Hinweis bezüglich des Windows Client OS in seinem dritten Teil zu den VM Role Gallery Items für WAP gegeben.

For a Windows based gallery item the Operating System must be set to a Windows Server setting. When the Operating System entry is set to a Windows client or a non-Microsoft Operating System, the disk will not be displayed in the gallery item deployment wizard.
-> http://blogs.technet.com/b/privatecloud/archive/2014/09/15/the-windows-azure-pack-vm-role-part-3-resource-definition.aspx

Diese Erfahrung habe ich in meinen ersten Versuchen ebenfalls gemacht. Sobald man für die VHDX, zum Beispiel ein Windows 8.1 Enterprise, die entsprechenden Tags setzt, so erscheint die OS Disk nicht im Deployment Wizard des Gallery Items. Nur wie schafft man es jetzt Windows 7 Enterprise oder Windows 8.1 Enterprise im Self-Service als VM Role anzubieten?

Man muss eigentlich nur drei Punkte beachten, dann funktioniert auch das Bereitstellen eines Windows Client OS über ein VM Role Gallery Item im Windows Azure Pack Portal.

VMRoleClient1

Fangen wir mit Punkt 1 an. Beim automatischen Deployment eines Windows Client OS darf man als Admin Account nicht den Benutzer Administrator im Gegensatz zum Windows Server OS verwenden, sondern muss einen benutzerdefinierten Namen angeben.

VMRoleClient2

Aber wie erreicht man dies im VM Role Gallery Item, dass der User diesen selber definieren oder man diesen Vorgeben kann? Wenn man mit den Tags für die OS Disk arbeitet, sei es jetzt für Windows Server oder Linux, dann wird der Benutzer Administrator oder root direkt grau hinterlegt eingeblendet und kann nicht geändert werden. Da wir aber bereits wissen, dass man bei einem Windows Client OS nicht mit den Tags für die OS Disk arbeiten kann, muss man einen anderen Weg gehen.

Damit wären wir bei Punkt 2. Man gibt in der Resource Definition direkt die OS Disk an. Somit bekommt man die Möglichkeit auf der einen Seite den benutzerdefinierten Namen für den Admin Account setzen zu können (siehe Screenshot 2) und auf der anderen Seite ist die OS Disk hart verdrahtet, so dass das Deployment des Windows Client OS funktioniert.

VMRoleClient4

Die Angabe der OS Disk erfolgt in der Resource Definition nach den Vorgaben der Family und der Release Version, die man in der VMM Library für die VHDX definiert hat.

VMRoleClient3

In unserem Beispiel mit Windows 8.1 Enterprise würden wir “64-bit edition of Windows 8.1:1.0.0.0” angeben (siehe Screenshot 3). Wichtig dabei ist natürlich auch, dass das Operating system der VHDX korrekt in der VMM Library angegeben wurde. Ansonsten kann der VMM den Deployment Prozess nicht korrekt steuern.

Zum Schluss und damit wären wir bei Punkt 3 wird ein Produktschlüssel für das Windows Client OS benötigt. Damit steht man wieder vor dem nächsten Problem. Die VM Role Gallery Items lassen keine Eingabe eines Produktschlüssels zu, soweit ich weiß. Daher muss man den Weg über die VHDX gehen. Für Windows 7 Enterprise oder Windows 8.1 Enterprise bieten sich die KMS Schlüssel an.

-> http://technet.microsoft.com/en-us/library/jj612867.aspx

Diesen einfach für die VHDX mit folgendem VMM PowerShell Cmdlet setzen.

Set-SCVirtualHardDisk -VMMServer VMMServer -VirtualHardDisk VHDX -ProductKey ‘Produktschlüssel’

Danach funktioniert das Deployment eines Windows Client OS über ein VM Role Gallery Item im Windows Azure Pack Portal genauso problemlos, wie das eines Windows Server OS.

WordPress Cookie Notice by Real Cookie Banner