Skip to content

Design and deploy#

Open deploy.andykemp.com/avd and sign in. If you already have host pools, they're listed first; those built with AVD Deploy offer Finish setup. Below them is the design, one page at a time. Your place is kept if you reload.

1. Azure#

  • Subscription and region. Only regions that can hold Azure Virtual Desktop are listed, each with the vCPUs your subscription has free. Regions with too little quota are greyed out.
  • Prefix and resource group. The prefix names the host pool (<prefix>-HostPool) and session hosts (<prefix>SH-0 and on).

2. Desktops#

  • Pooled or personal desktops.
  • Worker profile: frontline (6 users per vCPU), standard office (4) or heavy office (2), after Microsoft's sizing guidelines.
  • Users, and how many are signed in at peak. The tiles show the hosts, sessions per host and vCPUs this needs.
  • VM size. The recommended size, or any D, E, F or B-series size that suits the template (Generation 2, Trusted Launch, premium disks). Sizes your subscription can't use in that region are shown greyed out.
  • Apps (pooled): Windows 11 multi-session with Microsoft 365 Apps, or plain Windows 11 with apps from Intune. Personal desktops use Windows 11 Enterprise.

3. Identities (pooled only)#

  • Cloud-only (Entra Kerberos, preview) or hybrid (synchronised from Active Directory) for FSLogix profiles on Azure Files.
  • What happens when a profile can't load: sign in with a temporary profile, or stop the sign-in.

4. Network#

  • New: a virtual network with a NAT gateway for outbound access. The first free 10.200–250.0.0/24 is suggested.
  • Existing: pick a network and subnet in the same region.

5. Access#

  • Users and admins groups, new or existing. You can add yourself to the users group to test.
  • Intune device group (optional): a dynamic group with the rule (device.displayName -startsWith "<PREFIX>SH-"), for assigning apps and policies to the session hosts. It needs Entra ID P1; if it can't be created, that's a warning, not a failure.
  • Local administrator. The user name is checked against Azure's reserved names. The password is generated (24 characters, the default) or one you type. It's never stored by the page; see Security model.

6. Power and names#

  • Business hours scaling (hosts start before the working day and stop after it) or always on, and the time zone.
  • Workspace and desktop names, with a preview of how they'll look in Windows App.

Review#

Review checks your design without changing anything:

  • the release files, by fingerprint;
  • resource providers;
  • the resource group's region, and any host pool already in it;
  • Key Vault and storage names (free, and not soft-deleted);
  • an existing network's subnets and DNS;
  • VM size availability and vCPU quota, with same-size alternatives when blocked;
  • your Azure permissions and Entra roles;
  • Entra devices named like the new hosts but with no VM behind them.

It then lists exactly what Deploy creates. Blockers must be fixed; warnings are yours to judge.

Deploy#

Five steps, each with its own progress:

  1. Entra groups: found by name or created, with you as owner.
  2. Foundation: the resource group, network, Key Vault and the admin password secret, and the scaling grant. Only what's missing is created.
  3. Host pool: storage with its private endpoint, the host pool, application group, workspace, role assignments and scaling plan.
  4. Session hosts: validated first, then deployed with a short-lived registration token, which is revoked afterwards.
  5. Registration: waits for every host to register, then restarts the new hosts once so the Entra Kerberos setting applies.

Session hosts can take half an hour or more. Keep the tab open: the deployment runs in Azure, but the page drives the steps. If the tab closes, open AVD Deploy again and deploy the same design: what exists is kept.

Then go to Finish setup.