VDI / Azure Virtual Desktop
Virtual Desktop Infrastructure (VDI) and Azure Virtual Desktop (AVD) hosts behave differently from physical devices — they are non-persistent, may share a public IP with other hosts, and should be excluded from certain device-targeted policies. This guide covers how to register the AVD egress IP as a trusted location and how to keep AVD hosts in the correct device group so the baseline applies the right policies.
Overview
When AVD or VDI hosts are enrolled in Intune alongside physical devices, two problems arise without proper configuration:
Some Conditional Access policies — such as requiring Intune-compliant devices or restricting access to trusted locations — evaluate the sign-in location as a condition. AVD sessions originate from the datacenter IP, not the user's physical location, so they can be incorrectly blocked or restricted by these rules. Registering the AVD egress IP as a trusted named location ensures those policies evaluate correctly.
Policies such as hardware-based Hello for Business, BitLocker TPM enforcement, or credential provider restrictions target physical hardware that AVD/VDI hosts do not have. Placing virtual hosts in the dedicated device group exempts them from those policies.
Register the AVD Public IP as a Trusted Location
AVD session hosts connect to Microsoft 365 services through the Azure datacenter's public IP (or NAT gateway IP). Conditional Access sees this IP as the sign-in location. Add it as a named location so it is treated as trusted — this prevents spurious MFA prompts and block policies from firing against AVD sessions.
Step 1 — Find your AVD egress IP
From any active session host, run:
(Invoke-RestMethod -Uri "https://api.ipify.org?format=json").ip
If your environment uses a NAT gateway or Azure Firewall, the egress IP is the public IP of that gateway — find it in the Azure Portal under the NAT gateway or firewall resource.
Step 2 — Update the AVD named location in Entra ID
The baseline deploys an AVD named location with placeholder IPs. After the baseline is deployed, update it with your actual egress IPs directly in the portal:
- 1. Go to Entra ID → Security → Conditional Access → Named locations
- 2. Open the AVD named location
- 3. Remove the placeholder IP ranges and add your environment's actual egress IPs
- 4. Save
If AVD egresses through an Azure NAT gateway or Azure Firewall, use the public IP of that resource. Use /32 for a single address or a wider CIDR block if your environment uses a range. Changes made in the portal are not overwritten by subsequent pipeline runs — the orchestrator only manages what is defined in the baseline files.
Add AVD Hosts to the VDI Device Group
The baseline ships with a dedicated device security group for virtual hosts. Policies that rely on physical hardware capabilities are excluded for members of this group, so AVD/VDI hosts receive a tailored policy set without breaking the physical device baseline.
Dynamic security group. All devices whose display name contains avd are automatically added. Assign policies that should be excluded from virtual hosts to this group as an exclusion target.
(device.displayName -contains "avd")
The dynamic rule matches any device whose name contains avd (case-insensitive). Use a consistent naming prefix or suffix when provisioning session hosts — for example AVD-PROD-001, AVD-PROD-002, etc. — and the devices will join the group automatically at enrollment.
If your hosts use a different naming convention (e.g. VDI-), update the membership rule in the group JSON before deploying the baseline.
Baseline file reference
The group is defined in:
{
"displayName": "Baseline - Devices Virtual Azure Virtual Desktop",
"description": "Query to be determined",
"groupTypes": "DynamicMembership",
"membershipRuleProcessingState": "On",
"membershipRule": "(device.displayName -contains \"avd\")",
"mailEnabled": false,
"securityEnabled": true,
"visibility": null
}
The description field is a placeholder — update it to describe your VDI environment before deploying. The orchestrator deploys this group in the Groups stage, before Intune and Conditional Access policies, so group references in assignments will resolve correctly.
Policies that already exclude this group
The baseline assignment files already exclude Baseline – Devices Virtual Azure Virtual Desktop from policies that target physical hardware capabilities:
| Policy area | Reason to exclude virtual hosts |
|---|---|
| Hello for Business (hardware TPM) | Session hosts have no TPM chip; HfB enrollment fails and blocks sign-in |
| BitLocker TPM enforcement | Virtual disks cannot use TPM-bound protectors |
| Credential Provider (passwordless) | AVD sign-in flow uses its own web-based credential stack |
| Device lock / screen timeout | Session idle is managed by the AVD host pool, not Intune |
| Driver / firmware update rings | Session host OS is managed by the Azure image, not end-user update rings |