WVD - Windows Virtual Desktop auf der grünen Wiese

Windows Virtual Desktop (WVD) ist ein Desktop- und Anwendungsvirtualisierungsservice, der auf Microsoft Azure läuft. Auf die Multi-Session-fähigen, virtuellen Desktopumgebungen und Anwendungen kann standortunabhängig von sämtlichen Client-Geräten mit gängigen Betriebssystemen wie Windows, MacOS, iOS, Android und Linux zugegriffen werden. Auch können die meisten modernen Browser (die HTML5 unterstützen) verwendet werden, um auf die gehosteten Remote-Desktop und (Remote-)Anwendungen zuzugreifen.

Windows Virtual Desktop reduziert für Unternehmen den finanziellen und arbeitstechnischen Aufwand der für den Betrieb eigener Hard- und Software zur Bereitstellung von VDI-Umgebungen notwendig ist.

In diesem kleinen How-To soll gezeigt werden, wie man eine Cloud-only WVD (Test-)Umgebung aufbaut und wie es möglich ist, die eigenen App-V Pakete in WVD bereitzustellen.

Notwendig ist hierfür nur ein Azure Konto. Das 30 Tage kostenlose Azure Konto ist hierfür ebenfalls ausreichend.

Anstatt nur die Azure AD Domain Services zu verwenden, wie in diesem How-To, ist es natürlich auch möglich, einen Domänencontroller in einer gehosteten Windows Server-VM in Azure oder einen on-prem Domänencontroller zu verwenden.

Für den Betrieb von Windows 10 Multisession, können folgende Lizenzvarianten genutzt werden:

• Microsoft 365 F1, E3, E5, A3, A5, Business
• Windows 10 Enterprise E3, E5
• Windows 10 Education A3, A5
• Windows 10 VDA pro Benutzer

Aufbau von VWD

• Web Access Web Frontend für HTML 5 Verbindungen
• Gateway Globaler Gateway Dienst für eingehende Verbindungen
• Broker Verwaltung der eingehenden Verbindungen und Reconnects
• SQL DB Zentrale Speicherung der Infrastrukturdaten rund um WVD
• Diagnose Überwachung des Backends (technisch)

Azure AD Domain Services

Eine mögliche Grundlage zur Benutzeradministration sind die Active Directory Domain Services. Azure Active Directory Domain Services  verfügt über verwaltete Domänendienste wie Domänenbeitritt, Gruppenrichtlinien, und Kerberos/NTLM-Authentifizierung. Wir können diese Domänendienste nutzen, ohne Domänencontroller in der Cloud bereitstellen (und patchen zu müssen). Natürlich funktioniert auch ein eigenes Active Directory "Ohne" oder in Kombination.

Zu allererst wird ein Benutzer erstellt, der Administratorrechte in der Azure AD Domäne bekommen soll. Vergibt man das Kennwort selbst, muss man sich einmal mit dem Benutzer anmelden, da dann eine Aufforderung zur Kennwort Änderung kommt.

Nun gibt man „azure domain services“ in das Suchfeld ein und wählt „Azure AD Domain Services“ aus.

Klick auf „Azure AD Domain Services erstellen“ um eine neue Domäne in Azure anzulegen.

Falls noch nicht vorhanden, muss eine Ressourcengruppe angelegt werden. In diesem Fall soll sie WVD für Windows Virtual Desktop heißen.

Der Domänenname soll NickIT.onmicrosoft.com lauten. Als SKU reicht „Standard“ für dieses Lab.

Es wird automatisch mit Erzeugung der Domäne ein neues VLAN angelegt. Hier können die Default Einstellung behalten werden.

Über Klick auf „Gruppenmitgliedschaft verwalten“ muss hier in die Gruppe „AAD DC Administratoren“ ein Anwender aufgenommen werden, der Administratorrechte in der Azure AD Domäne bekommen soll. Dafür wird der im ersten Schritt angelegte Benutzer verwendet.

Über „Mitglieder hinzufügen“ den Anwender auswählen.

Synchronisierungseinstellungen haben für das Lab keine Auswirkungen und können so beibehalten werden.

Sind alle Angaben korrekt, kann die Domäne erzeugt werden.

Der Prozess dauert ca. 1,5-2 Stunden.

Erscheint „Wird ausgeführt“ ist die Domäne erfolgreich erstellt.

Nun müssen die DNS-Servereinstellungen aktualisiert werden. Ein Klick auf „Konfigurieren“ ist ausreichend.

Windows Virtual Desktop

Nun beginnt die eigentliche Konfiguration von Windows Virtual Desktop.

Im folgenden ein Schaubild zur Architektur

Zunächst muss die Ressource „Microsoft Desktop Virtualization“ registriert werden.

Dazu im Abonnement unter „Ressourcenanbieter“ „desktop“ im Suchfeld angeben, „Microsoft.Desktop.Virtualization“ anwählen und auf „Registrieren“ klicken.

Unter „Windows Virtual Desktop“ kann jetzt ein Hostpool erstellt werden.

Wichtig ist hier der Name des Hostpools, hier „Hostpool_01“ der Hostpooltyp und die maximale Anzahl von Sitzungen pro Host. Zum Testen reichen 5 aus.

Im nächsten Schritt müssen Angaben zu den zu erstellenden VMs im Hostpool gemacht werden.

Neben der Ausstattung und Imagetyp ist die Anzahl relevant. Für dieses Lab reicht eine VM. Zusätzlich müssen noch ein Name bzw. ein Namenspräfix angegeben werden.

Unter „Netzwerk und Sicherheit“ muss die Domäne angegeben werden, in die die VM aufgenommen werden soll, sowie einen Benutzer mit entsprechenden „domain join“ Berechtigungen. Dazu wird wieder der Benutzer vom ersten Schritt verwendet.

Für das Lab wird noch ausgewählt, dass die VM eine öffentliche IP sowie RDP Port bekommen soll. Um sich auf die VM auf einfachem Wege über RDP verbinden zu können (Sicherheitsrisiko!).

Hier muss ein Arbeitsbereich angegeben bzw. neu erstellt werden und es kann angegeben werden, ob gleich eine Anwendungsgruppe (Name: Hostpool_01-DAG) mit dem veröffentlichten Desktop des Hostpools erzeugt werden soll.

Sind alle Angaben korrekt, kann der Hostpool erstellt werden.

Bereitstellung ist abgeschlossen.

Nun wird eine neue Gruppe (WVD User) erzeugt, die auf die Anwendungsgruppen (Anwendung oder Desktop) berechtigt wird.

Es werden noch zwei weitere Benutzer erzeugt,

die dann Mitglied der eben erzeugten Grupp WVD User werden.

In der im vorigen Schritt automatisch erzeugten (Desktop-)Anwendungsgruppe Hostpool_01-DAG wird die Gruppe WVD Users berechtigt. Somit erhalten alle Mitglieder dieser Gruppe Zugriff auf den veröffentlichten Desktop.

Zum Testen wird der Link des Portals aufgerufen.

https://rdweb.wvd.microsoft.com/arm/webclient/index.html

Nach dem Login mit einer der beiden Testuser wird der veröffentliche Desktop angezeigt.

Nach einem Klick auf das Icon wird der Desktop in einem Tab im Browser geöffnet.

Nun wird eine weitere Anwendungsgruppe, diesmal für Anwendungen (RemoteApp), erstellt.

Ein Klick auf „Anwendungen hinzufügen“ …

… öffnet einen Dialog in dem Anwendungen direkt aus dem Startmenü oder über den Dateipfad ausgewählt werden können.

Excel, Word und Paint sind nun in der Anwendungsgruppe aufgenommen.

Die zuvor erzeugte Gruppe „WVD User“ wird auf die Anwendungsgruppe berechtigt.

Die Anwendungsgruppe wird im vorhandenen Arbeitsbereich registriert.

Klick auf „Erstellen“ erzeugt die Gruppe.

WVD Anwendung im Portal starten

Generell ist ein Start mit folgenden Betriebssystemen möglich

• Windwos 32 und 64 Bit, Windows Arm
• MacOS
• iOS
• Android

Die folgenden Browser werden unterstzützt

• Edge (Edge Chrominum)
• Chrome+
• Safari (mac , iOS)
• Mozilla

Im Portal stehen nun die neuen Anwendungen zur Verfügung.

Ein Klick auf das Paint Icon startet Paint.

Paint ist ianschließend n einem neuen Tab gestartet.

Schöner geht dies mit der Remotedesktop App. Nach dem Anmelden mit E-Mail und Passwort …

… stehen die Anwendungen zur Verfügung.

Ein Klick auf das Paint Icon startet Paint…

… als seamless application nahtlos ins lokale Windows integriert und nicht in einem Tab im Browser.

Erstellen eines (Management-)Servers

Um Gruppenrichtlinien in der Azure Domäne erstellen zu können, wird nun ein virtueller Server erstellt.

Dazu kann die Konfiguration je nach Belieben vorgenommen werden.

Als Administratorkonto ist ein Benutzer erforderlich, der später als lokaler Administrator auf dem Server angelegt wird.

Auch hier wird für das Lab ausgewählt, dass der Server einen öffentlichem RDP Port bekommen soll. Um sich auf die VM auf einfachem Wege über RDP verbinden zu können (Sicherheitsrisiko!).

HDD Standard reicht für diese Testumgebung aus.

Server soll öffentliche IP bekommen.

Standardwerte können beibehalten werden.

Klick auf „Erstellen“ erzeugt den Server.

Da

mit es möglich ist, über RDP auf die Server zuzugreifen, muss noch eine Eingangsregel in der Firewall für RDP Port 3389 angelegt werden.

Nun ist eine Verbindung über RDP möglich und der Server kann in die Domäne gehoben werden.

Dafür wird wieder der User mit den Domänenrechten verwendet.

Jetzt können die Gruppenrichtlinienkonsole sowie die AD Benutzer und Computer Konsole installiert werden.

In der erstellten Azure Domäne sind dann in der OU „AADDC Computers“ die beiden zuvor erstellten Computer zu finden. Der WVD Session Host „NickITVM-0“ sowie der Server01.

Speicherkonto für App-V

Nun wird ein Speicherkonto erstellt, in dem später die App-V Pakete abgelegt werden sollen.

Notwendig ist hier wieder die Auswahl der Ressourcengruppe und ein Speicherkontoname, hier „storageappv“, der Rest kann je nach Bedarf konfiguriert werden.

Hier können die Standardeinstellungen beibehalten werden.

Klick auf „Erstellen“ erzeugt das Speicherkonto.

Im eben erzeugten Speicherkonto „storageappv“ kann nun eine neue Dateifreigabe erstellt werden.

Hier ist wieder ein Name erforderlich sowie die Angabe des Kontingentes. 1GB sollten für dieses Lab ausreichend sein.

In der Konfiguration des Speicherkontos muss „Identitätsbasierter Zugriff auf Dateifreigaben“ aktiviert werden, damit verschiedene Benutzerberechtigungen auf das Share gesetzt werden können.

Nun können auf das eben erstellte Share entsprechende Rollen für den lesenden und schreibenden Zugriff hinzugefügt werden. Dazu in der Share Konfiguration auf „Zugriffssteuerung“ klicken und „Rollenzuweisung hinzufügen“ auswählen.

Als erstes die Rolle „Mitwirkender mit erhöhten Rechten für Speicherdaten-SMB-Freigabe“ auswählen und die Gruppe auswählen, welche schreibenden Zugriff auf das Share erhalten soll. In diesem Fall wird die Gruppe „AAD DC Administrators“ ausgewählt.

Als zweites die Rolle „Leser für Speicherdaten-SMB-Freigabe“ auswählen und die Gruppe auswählen, welche lesenden Zugriff auf das Share erhalten soll. In diesem Fall wird die Gruppe „WVD User“ ausgewählt, damit die beiden Testuser in der Gruppe lesenden Zugriff auf das Share erhalten.

Zu Testzwecken kann man das PowerShell Skript welches unter „Verbinden“ in den „appvshare“ Eigenschaften zu finden ist, auf dem Session Host ausführen.

$connectTestResult = Test-NetConnection -ComputerName storageappv.file.core.windows.net -Port 445

if ($connectTestResult.TcpTestSucceeded) {

# Laufwerk einbinden

New-PSDrive -Name Z -PSProvider FileSystem -Root "\\storageappv.file.core.windows.net\appvshare" -Persist

} else {

Write-Error -Message "Unable to reach the Azure storage account via port 445. Check to make sure your organization or ISP is not blocking port 445, or use Azure P2S VPN, Azure S2S VPN, or Express Route to tunnel SMB traffic over a different port."

}

Nach Ausführen des PowerShell Skriptes ist das Share als Netzlaufwerk Z: verbunden.

App-V Konfiguration

Zum Kopieren der App-V Pakete kann z.B. der „Microsoft Azure Storage Explorer“ verwendet werden.

Drei App-V Testpakete wurden erfolgreich hochgeladen und sind in Azure sichtbar.

In der Gruppenrichtlinienkonsole kann nun eine neue Richtlinie für die App-V Client Konfiguration erstellt werden.

Folgende Einstellungen sollten vorgenommen werden:

Der App-V Client muss aktiviert werden.

Der Shared Content Store mode kann optional aktiviert werden, damit die virtuellen Pakete nicht auf der lokalen Disk des Session Hosts gespeichert werden, sondern direkt in den Speicher (RAM) geladen werden.

Eine weitere optionale Einstellung wäre das Aktivieren des „Automatic cleanup of unused appv packages“, damit nicht verwendete Pakete automatisch gelöscht werden.

Die Erstellung von 8.3-Dateinamen auf NTFS-Partitionen muss deaktiviert werden, damit der App-V Client funktioniert. NtfsDisable8dot3NameCreation = 0.

Die Script Execution für PowerShell muss auf "Allow local scripts and remote signed scripts" gesetzt werden, damit später das PowerShell Skript ausgeführt werden kann, welches die App-V Pakete auf dem Session Host importiert.

Übersicht aller für App-V gesetzten Gruppenrichtlinieneinstellungen. Der Session Host „NickITVM-0“ wird in die erstellte OU „WVD“ verschoben, in der auch die Gruppenrichtlinie verlinkt ist.

Jetzt wird ein Geplanter Task auf dem Session Host erstellt, der das App-V Skript bei jedem Start des Session Host Servers ausführt. Das Skript lädt die App-V Pakete vom erstellten Share und stellt sie am Session Host bereit.

Dazu wird am besten ein entsprechender Service Account verwendet.

Alternativ kann der Geplante Task ebenfalls in den Gruppenrichtlinien untergebracht werden.

Task soll bei jedem Serverstart ausgeführt werden.

Das Skript kann z.B. direkt auf dem Session Host abgelegt werden.

Im ersten Schritt werden alle eventuell bereits auf dem Session Host vorhandenen App-V Pakete entfernt, danach werden alle auf dem Share vorhandenen Pakete global veröffentlicht.

Nach dem Reboot des Session Hosts sollten die App-V Pakete zur Verfügung stehen.

Nachdem die App-V Pakete zur Verfügung stehen, wird eine neue Anwendungsgruppe erstellt, und die App-V Anwendungen hinzugefügt.

Als Anwendungsquelle wird „Dateipfad“ ausgewählt. Der Anwendungspfad wird aus der Verknüpfung der App-V Anwendung vom Session Host kopiert, genauso wie der Symbolpfad.

Alle drei App-V Anwendungen wurden hinzugefügt.

Auf die Anwendungsgruppe wird wieder die Benutzergruppe „WVD User“ berechtigt.

Die Anwendungsgruppe wird im vorhandenen Arbeitsbereich registriert.

Klick auf „Erstellen“ erzeugt die Gruppe.

In der Remotedesktop App oder im Browser stehen nun die neuen Anwendungen zur Verfügung.

Der virtuelle Firefox und Foxit Reader lassen sich erfolgreich starten.

Weitere Informationen

Eine der kommenden Neuerungen in Azure ist die einfache Bereitstellung von MSIX Paketen in WVD, sodass der altbekannte aber deutlich umständlichere weg über Skripte wegfällt.

Es passt zwar nicht direkt zu dem Thema App-V jedoch zur Bereitstellung von virtuellen Anwendungen in Azure. Daher soll diese Neuerung hier nicht unerwähnt bleiben.

Sollte einem das manuelle Erstellen einer Windows Virtual Desktop Umgebung in Azure zu lange dauern oder zu mühsam sein, kann man unter dem folgenden Link auch einfach eine WVD Umgebung automatisiert erstellen lassen. Dazu wird nur ein Azure Account benötigt.

https://www.wvdquickstart.com/

 ThinClients

Als einziger Hersteller unterstützt aktuell die Firma IGEL WVD. Weitere werden folgen. In Kombination mit Citrix ist die Unterstützung natürlich besser.

Kosten

Als kosten fallen generell die Kosten für die Azure VM, Azure Storage und die Lizenzen an (WIndwos 365, Windows Enterprise, Office 365 und andere Modelle) 

wichtige Internetadressen

https://docs.microsoft.com/de-de/learn/modules/m365-wvd-intro/