Azure AZ-140 common mistakes
Azure AZ-140 · Understand the traps and how to avoid them.
Creates a personal host pool and then selects Breadth-first load balancing with a max session limit of 10, expecting hosts to be shared until full.
The create-host-pool blade asks the same load-balancing and session-limit questions for both host pool types, so candidates memorize 'breadth-first is the default' without tying the setting to pooled versus personal.
What to do instead
Personal host pools: load balancing does not apply, one user per session host, session limit effectively 1. Pooled host pools: breadth-first (even spread) or depth-first (pack to reduce cost), with the max session limit controlling concurrent sessions per host.
Generates the host pool registration key during the planning phase, then reuses that saved key days later in an ARM/Bicep deployment; the VMs and agent install succeed but the hosts never appear in the host pool.
The registration key is a time-limited token created with an expiry, and deployment pipelines are written once and re-run later, so the failure is silent and looks like an agent problem.
What to do instead
Regenerate the key immediately before each deployment (or pass it as a fresh parameter/output at deploy time), then confirm each host shows Available. If hosts are already built with a stale key, re-register the agent with a new key.
Restricts the session host subnet with an NSG or forced-tunnel firewall that permits only generic outbound 443 to Microsoft Entra ID and Windows Update, then treats the Unavailable agent status as a product bug.
Session hosts need outbound reachability to the specific Azure Virtual Desktop broker/agent endpoints and FQDNs, not just generic 443 to Entra, and network design is usually driven by generic PaaS hardening checklists.
What to do instead
Allow the documented AVD required FQDNs (and where supported the AVD service tag) from the session host subnet, validate with the AVD connectivity/agent checks, and only then tighten the remaining rules.
Gives end users the Desktop Virtualization Contributor role on the host pool (or Reader on the workspace) and then debugs why connecting users get a 'no resources' or empty-feed experience.
Every AVD RBAC role begins with 'Desktop Virtualization', and the host pool is the object in view when the deployment finishes, so the application group - the object that actually gates user connections - gets skipped.
What to do instead
Assign Desktop Virtualization User on the application group (to users or a group), keep Contributor-level roles for administrators, and verify the application group is associated with a workspace assigned to those users.
Joins session hosts to Microsoft Entra ID and then points FSLogix at an Azure Files share assuming AD DS Kerberos will just work, or does an AD DS join without verifying that the AVD VNet can resolve and reach a domain controller.
Entra ID join is marketed as the simpler modern option, but Entra-joined hosts cannot use AD DS Kerberos and need Entra Kerberos (with the right hybrid identity setup); AD DS join conversely requires domain DNS and line of sight to a DC from the host subnet.
What to do instead
Choose deliberately: Entra join plus an Entra Kerberos-enabled storage account for FSLogix profiles, or AD DS join with the VNet DNS servers pointing at domain DNS and a reachable DC. Prove it by mounting the profile share from a session host before rollout.
Configures FSLogix by placing VHDLocations under HKCU, or delivers the path but leaves the Profiles Enabled value absent/0, then concludes FSLogix is broken because no VHDX is ever created.
FSLogix documentation groups many registry values together and GPO/Intune delivery can land a partial configuration; without Profiles Enabled=1 no container is created no matter how correct the share path is.
What to do instead
Set HKLM\SOFTWARE\FSLogix\Profiles: Enabled=1 (DWORD), VHDLocations=\server\share (REG_MULTI_SZ), plus VolumeType and size values; apply through one mechanism (GPO or Intune settings catalog, not both) and verify by signing in a test user and checking FSLogix logs and the created VHDX.
Publishes MSIX App Attach applications by attaching the VHDX and registering the package by hand on one host, then finds the app missing after reimage or scale-out, or launching fails with a missing dependency.
App Attach is per-session-host state - the disk must be attached and packages registered on every host at startup - and applications ship with separate dependency packages that also must be staged.
What to do instead
Automate attach-and-register on every host (startup script or VM extension applied to the image), attach the dependency packages (for example VCLibs) in the same step, and confirm both main and dependency packages report as registered for the signed-in user.
Assumes clipboard, drive, and printer redirection are on by default and discovers in user acceptance testing that they are unavailable, or hand-edits the custom RDP properties box with a syntax error that breaks every connection.
Redirection is controlled by terse host pool RDP property strings (for example redirectclipboard:i:1, drivestoredirect:s:*) and the custom-properties field accepts free text with no validation or rollback safety.
What to do instead
Set the needed redirections in the host pool RDP properties (or via Intune/GPO - pick one source of truth, not both), test the exact string on a pilot host pool, and prefer the built-in toggles over free-text custom properties.
Enables the Azure Virtual Desktop Insights workbook and Azure Monitor, then finds empty dashboards and blames the workbook or the monitoring agent.
AVD telemetry is not collected by default; diagnostic settings must be created per AVD resource type with the right categories, and candidates assume enabling the workbook is the whole configuration.
What to do instead
Create diagnostic settings on the host pool, workspace, application group and session hosts with the required categories (for example Checkpoint, Error, Connection, HostRegistration) all sending to one Log Analytics workspace, allow for ingestion latency, then scope the workbook to that workspace.
Runs image updates or patching on pooled session hosts while they are still accepting new connections, or disables Start VM on Connect without checking the role the service principal needs.
Maintenance is treated as a normal VM operation, but drain mode and the power-on role assignment are AVD-specific controls that do not appear in standard VM patch workflows.
What to do instead
Set Allow new connections to No (drain mode) per host, wait for sessions to log off or force sign-out, patch or reimage, then re-enable the host; for Start VM on Connect confirm the host pool setting is on and the service principal holds Desktop Virtualization Power On Contributor at the correct scope.