DaaS & Virtual Desktop · Glossar

Session Host

Eine einzelne VM innerhalb eines Host Pools, auf der User-Sessions tatsächlich laufen. Session Hosts sind die „Arbeitstiere“ der AVD-Infrastruktur — dort wird gerechnet, dort laufen die Apps, dort werden Ressourcen optimiert.

Auf einen Blick
VM
Virtuelle Maschine
D-Series
Typische SKU
Win 11
Multi-Session OS
DSR
Drain-Modus für Wartung

Was ist ein Session Host?

Ein Session Host ist eine einzelne virtuelle Maschine in einem Azure Virtual Desktop Host Pool, auf der User ihre Remote-Sessions öffnen. Je nach Host-Pool-Typ:

  • Personal Host Pool: 1 Session Host = 1 User
  • Pooled Host Pool: 1 Session Host = mehrere User gleichzeitig (Multi-Session)

Session Hosts sind normale Azure-VMs mit speziellem AVD-Agent-Software. Sie registrieren sich beim AVD-Broker-Service, der dann User-Logins an die Session Hosts vermittelt.

Was läuft auf einem Session Host?

KomponenteZweckPflicht/Optional
Windows 10/11 Enterprise (Multi-Session)Das Basis-OSPflicht
AVD AgentRegistriert VM beim BrokerPflicht
Boot LoaderVerbindet Session Host ins AVD-BackendPflicht
FSLogixProfile-ManagementStark empfohlen
Microsoft Teams Media OptimizationAudio/Video-RedirectEmpfohlen
Intune Agent / MDEEndpoint-Management & SecurityEmpfohlen
Monitoring-AgentAzure Monitor, Log AnalyticsEmpfohlen
Line-of-Business AppsBusiness-ApplikationenJe nach Bedarf

Welche Azure-VM-Größen für Session Hosts?

Die richtige VM-Größe hängt vom Workload, dem Host-Pool-Typ und der Ziel-Dichte ab:

SKUvCPU / RAMZiel-WorkloadTypische User/VM
D2s_v52 / 8 GBPersonal Desktop (Light)1
D4s_v54 / 16 GBPersonal Desktop (Standard)1
D8s_v58 / 32 GBMulti-Session Office6-10
D16s_v516 / 64 GBMulti-Session Power10-15
E8s_v58 / 64 GB (Memory-optimized)SAP GUI, RAM-heavy Apps6-10
NVv4 (NV12ads A10)12 / 110 GB + GPUCAD, 3D, Video1 (Personal)
NCasT4_v34 / 28 GB + T4 GPUAI/ML, DeepLearning1-2

Premium-SSD vs. Standard-SSD

Für Session Hosts immer Premium-SSD verwenden (P10 oder P15). Die OS-Disk-IO ist ein Engpass bei Multi-Session — Standard-SSD macht das Login für alle User spürbar langsamer.

Session Host Lifecycle

Typischer Lifecycle

  1. Provisioning — VM aus Gold Image erstellen (Azure Template, Nerdio, oder manuell)
  2. Domain-Join — an Microsoft Entra ID oder on-prem AD joinen
  3. Agent-Installation — AVD-Agent mit Registrierungs-Token
  4. Pool-Zuweisung — VM tritt Host Pool bei, wird für User verfügbar
  5. Aktive Phase — User arbeiten, Monitoring läuft, Autoscaling optimiert
  6. Patching — Updates via Intune oder Nerdio, idealerweise automatisiert
  7. Drain-Modus — vor Wartung: keine neuen User, laufende Sessions beenden
  8. Rebuild/Retire — mit neuem Image austauschen (Multi-Session-VMs haben typisch kurze Lebenszyklen)

Best Practice: Cattle, not Pets: Session Hosts sollten wie „Vieh“ behandelt werden — ersetzbar, austauschbar, unpersönlich. Wenn eine VM Probleme macht: wegwerfen und neu aus Image bauen. Nie mühsam reparieren. Das geht nur, wenn Profile/Daten zentral (FSLogix) und App-Config automatisiert sind.

Session-Host-Sizing in DaaS Maps

Die DaaS Maps zeigen Session-Host-Sizing-Empfehlungen für verschiedene Workloads mit realen Kosten-Szenarien. Zum Austausch über VM-Sizing und Session-Host-Patterns findet ihr mich auf LinkedIn.