Scenario: AVD — Dedicated Sovereign Tenant

Azure Virtual Desktop deploys session hosts as Entra Joined virtual machines, managed by Intune, authenticating through Entra ID—the same identity stack as physical devices.

Prerequisite

Complete Entra Join (The Cloud-Only Path) (DNS records + MDM User Scope) before starting this section. The AVD host pool join and Intune enrollment depend on that foundation being in place.

---

AVD Architecture

AVD and Microsoft 365 GCC High as the Security Boundary

In this model, organizations tightly control the identity, device, and data policies in their GCC High tenant. User identities accessing AVDs in this environment should be authenticated with phishing resistant authentication, but organizations may want to leave the machines and the systems that manage them out of the scope of their assessment. Depending on broadly you have enforced device-compliance, you may want to avoid bringing connecting devices and the systems that manage them into assessment scope by excluding from your equivalent of P006 Require compliant devices for O365, Azure, and Management:

• Azure Virtual Desktop
• Azure Virtual Desktop Client
• Windows Sign In

Cross-tenant access settings allow your tenant to trust device claims from another tenant. From a security perspective, I always thought it better to restrict access to compliant devices, even if compliance for that device is managed by someone else. However, I've been told by not activating that control, the system governing that control does not come into assessment scope. Security is different than compliance.

Host Pool Model: Personal (Assigned)

This deployment uses a personal (assigned) host pool — each user is assigned a dedicated VM that persists between sessions. This is a deliberate design choice driven by both operational and compliance considerations.

Operational reasons:

• No FSLogix profile containers to configure, monitor, or troubleshoot. FSLogix adds Azure Files storage dependency, SMB firewall rules, and a class of failure modes (profile corruption, mount failures, storage quota issues) that are absent in the personal model.
• Predictable user experience. A user's session host retains their installed applications, browser profile, desktop layout, and local app state. There are no "fresh profile on every login" anomalies.
• Simplified troubleshooting. When a user reports an issue, the session host is theirs alone — IT is not debugging a shared environment where one user's actions affect others.

Compliance considerations:

Multi-session AVD (Windows 10/11 Enterprise Multi-Session, used in pooled host pools) runs multiple users in separate interactive sessions on a single VM under a shared OS kernel. For regulated environments handling sensitive data, this shared boundary introduces risk that requires affirmative mitigation:

Concern	Multi-Session Risk	Personal Pool
NIST 3.1.1 / 3.1.2 (least privilege, account management)	A compromised session on a multi-session host can potentially reach another user's process memory or profile data before kernel-enforced cleanup completes. Session isolation in Windows is strong but not absolute — privilege escalation vulnerabilities have historically enabled cross-session access.	Each VM is a single-user environment. There is no second user's process space to reach.
AU domain (audit and accountability)	Per-user audit event attribution depends on session IDs, which are recycled as users connect and disconnect. In a high-churn environment, audit trail integrity for sensitive data events is harder to establish and defend during a compliance assessment.	All events on a VM map unambiguously to one assigned user. No session ID ambiguity.
NIST 3.13.1 (system and communications protection)	All users on a multi-session host share the same network stack. A data boundary argument on a multi-session host requires demonstrating that one user's session traffic cannot be observed by another.	The VM is the boundary. Network isolation between users is not a concern.

Multi-session host pools are not automatically non-compliant, but they require additional mitigations

Microsoft's own AVD security guidance explicitly recommends personal pools for users who require elevated privileges or handle sensitive data. The audit burden of justifying multi-session data isolation is significant — and the operational benefits of multi-session (cost, density) are not a priority for the client profiles this guide targets. Multi-session pooled deployments are a valid and supportable AVD architecture, but they are a more complex compliance conversation and outside the scope of this guide.

Authentication (Azure RBAC, No Domain Controllers)

In the AVD model, authentication is handled by Azure RBAC policies rather than Domain Controller ACLs. Users authenticate using their Entra ID credentials directly. There are no group policy logins, no Kerberos ticket requests to a DC, and no VPN requirement for the authentication path.

Two RBAC roles govern access:

Role	Assigned To	Effect
Virtual Machine User Login	Standard users / AVD user group	Allows interactive sign-in to session hosts
Virtual Machine Administrator Login	IT admins	Allows sign-in with local admin rights

Without one of these roles, a user will receive an "Access Denied" error when connecting—even if the VM is running and healthy.

SSO via RDP Properties

To prevent double authentication prompts (once at the gateway, once at the VM), SSO must be enabled at the Host Pool level using RDP properties:

Property	Value	Purpose
enablerdsaadauth:i:1	1	Enables Entra ID authentication for the RDP session
targetisaadjoined:i:1	1	Tells the RDP client the target VM is Entra Joined

PIV Cards and CBA with AVD

For environments where users authenticate with NFC PIV cards (Path 2 in Phishing-Resistant Authentication), the AVD connection flow differs from both the traditional smart card experience and the Windows login screen behavior described in that article.

The key point: the PIV card authenticates the user once, at the Entra gate. It is not used again at the session host.

How the connection flow works

User taps PIV card at their local workstation
    → Entra CBA validates the certificate
    → Conditional Access: PIV cert satisfies phishing-resistant auth strength
    → AVD Gateway brokers the connection
    → SSO (enablerdsaadauth:i:1) carries the authenticated Entra token to the session host
    → User sees the session host desktop — no second PIN prompt

The session host's Windows login screen is bypassed entirely by SSO. The enablerdsaadauth:i:1 RDP property tells the AVD client and gateway to pass the user's existing Entra token — obtained from the PIV card authentication — directly into the session host's credential provider. The user does not tap the card at the session host because the session host is not the authentication boundary. Entra is.

Operational implications

• Users tap their card once to unlock their workstation. That authentication session carries into AVD. The experience is seamless.
• The PIV card and NFC reader are at the user's physical workstation — they never need to be present in or near the Azure datacenter.
• If the AVD session times out and triggers re-authentication, the user will be prompted through Entra again, which may require a new card tap depending on your Conditional Access Sign-in frequency setting.

Match CA sign-in frequency to shift length

Set the Sign-in frequency on your PIV CA policy (CA policy → Session → Sign-in frequency) to 8–12 hours to avoid mid-session re-authentication prompts for a standard work shift.

If SSO RDP properties are missing, PIV card logon to the session host will fail

Without enablerdsaadauth:i:1 and targetisaadjoined:i:1, the AVD client issues a second Windows credential prompt at the session host. A PIV card cannot satisfy that prompt over RDP — the card is physically at the user's desk, not at the session host. The session will either fail or fall back to password authentication, breaking the PIV-only enforcement posture.

---

Network Architecture

Azure Firewall Topology

GCC High AVD session hosts must not have public IP addresses. All outbound internet traffic routes through an Azure Firewall deployed in a hub VNet, enforced via a User Defined Route (UDR) applied to the session host subnet.

Session Host Subnet (10.x.x.0/24)
  └─ UDR: 0.0.0.0/0 → Azure Firewall private IP
       └─ Azure Firewall (Hub VNet)
            ├─ Application Rule Collections (FQDN-based)
            └─ Network Rule Collections (port/protocol-based)
                 └─ Internet

The key architectural principle: session hosts have no direct internet path. The firewall is the only egress point, and every allowed destination is explicitly enumerated. A deny-all rule at the lowest priority (4096) catches and logs any traffic not matched by an explicit allow.

Accelerate Your AVD Secure Enclave Build

Architecting an Azure Virtual Desktop enclave for GCC High is a heavy lift. Configuring an Azure Firewall with a deny-all default posture, routing all outbound traffic explicitly, and managing the unique constraints of the sovereign cloud can easily stall an internal IT team for months. If you need hands-on engineering to deploy a high-performance, compliant AVD environment, this is our core competency. Mindline can accelerate your build and ensure your network boundary is defensible for your next compliance assessment. Connect with our architects at mindline.com.

Required Traffic Categories

Azure Firewall rules for AVD GCC High fall into distinct categories, each with different ownership:

Category	Owner	Examples
AVD Control Plane	Microsoft (sovereign)	*.wvd.microsoft.us, *.servicebus.usgovcloudapi.net
Identity & Auth	Microsoft (sovereign)	login.microsoftonline.us, *.msftauth.net
M365 GCC High	Microsoft (sovereign)	*.mail.protection.office365.us, *.teams.microsoft.us
Windows Management	Microsoft (global CDN)	*.update.microsoft.com, *.delivery.mp.microsoft.com
Defender for Endpoint	Microsoft (sovereign)	*.security.microsoft.us, *.winatp-gw-usw.microsoft.com
Customer Applications	Customer-specific	Line-of-business FQDNs, SaaS providers

For the full reference rule set with FQDN tables and network rules, see AVD Firewall Reference.

---

Device Join & Enrollment

Entra Join and Intune Enrollment: No User Interaction Required

AVD session hosts join Entra ID and enroll in Intune entirely in system context during VM provisioning — before any user ever signs in. No user MFA challenge is triggered, and no per-user Intune license is validated at enrollment time.

The provisioning flow is:

1. Azure deploys the VM and runs the AADLoginForWindows extension under the SYSTEM account
2. The extension joins the VM to Entra ID using the tenant's device join configuration
3. Intune MDM auto-enrollment fires automatically as a consequence of the Entra Join
4. Intune delivers compliance policies and configuration profiles to the device

The Intune license check occurs later — when the first user signs in, Intune verifies that the user has an eligible license (M365 E3/E5). For a properly licensed deployment this is transparent. No interactive enrollment, no MFA prompt, and no per-VM manual step is required.

Common client concern: "Will provisioning 20 VMs trigger 20 MFA challenges?"

No. The join and enrollment happen at the system level. The only MFA challenge is the one the engineer authenticates with when deploying the host pool through the Azure portal.

Entra Join Constraint

AVD session hosts join Entra ID using the AADLoginForWindows VM extension, which runs at the SYSTEM account level during VM provisioning. This mechanism is subject to the tenant-level "Users may join devices to Microsoft Entra ID" policy in Entra > Devices > Device settings.

This policy must be set to All. There is no mechanism to scope the AADLoginForWindows join to a service principal — the setting applies to user-initiated and extension-initiated joins alike. If the policy is restricted to a named group, the extension's join attempt will fail and session host provisioning will partially complete: the VM is created but it is not Entra Joined or Intune-enrolled.

"Users may join devices" must be All — mitigate with compensating controls, not by abandoning the requirement

Setting this to All creates a surface where any user in the tenant could potentially join a personal device to Entra ID. The compensating controls below close this gap without restricting AVD provisioning:

Control	How It Mitigates
Enrollment restrictions (Intune)	Block personally-owned device enrollment — even if a device joins Entra, it cannot enroll in MDM unless it is corporate-owned
Conditional Access: require compliant device (P006)	Any device that joined Entra but bypassed Intune enrollment will fail compliance checks and cannot access M365 resources
B006: Block Non-Approved Device Registration	Blocks device registration from non-US locations, preventing foreign-IP device joins

With these controls in place, the risk of "Users may join devices = All" is substantially mitigated. Document this as a known constraint with compensating controls in your SSP.

---

Data Protection

Encryption

AVD session hosts handle sensitive data in transit and at rest. The encryption posture has three layers:

Layer	Mechanism	Configuration
OS disk (at rest)	BitLocker + Server-Side Encryption (SSE)	Intune BitLocker policy applies automatically to Entra Joined session hosts; SSE uses platform-managed keys by default
Server-side encryption	Azure Storage Service Encryption (AES-256)	Enabled by default on all managed disks — no additional configuration required
Customer-managed keys (optional)	Azure Key Vault (GCC High) + Disk Encryption Set	Provides key lifecycle control for higher-sensitivity environments; requires an Azure Key Vault in the same Azure Government subscription

For environments that require CMK: create a Disk Encryption Set referencing a Key Vault in Azure Government, and associate it with the AVD host pool's managed disk configuration at provisioning time. Keys must be stored in Key Vault instances within the US Gov regions to stay within the FedRAMP High boundary.

Backup

In the assigned (personal) pool model, each user's data persists on their dedicated VM's OS disk. There are no FSLogix profile containers — the VM itself is the user's persistent workspace. Azure VM backup is the primary data protection mechanism.

Resource	Backup Approach	Policy
Session host VMs	Azure Backup for VMs	Required — enable at provisioning; data loss on VM failure or accidental deletion without it
Base image (if using Shared Image Gallery)	Shared Image Gallery replication	Replicate to at least two US Gov regions for resilience

Azure Backup policy for session host VMs:

• Navigate to Recovery Services vault > Backup > Azure Virtual Machine
• Policy type: Enhanced (supports hourly recovery points)
• Schedule: Daily at off-hours (e.g., 2:00 AM)
• Retention: Daily 30 days / Weekly 4 weeks / Monthly 12 months
• Enable Soft Delete on the vault to protect against accidental backup deletion

OneDrive Known Folder Move as a supplemental layer

Deploying OneDrive KFM through Intune redirects Desktop, Documents, and Pictures to OneDrive for Business, providing near-continuous cloud protection for user working files independent of VM backup schedules. If a VM must be rebuilt, files in KFM-redirected folders are immediately available on the replacement VM without restoring from backup. Configure via Settings Catalog: OneDrive > Silently move Windows known folders to OneDrive.

---

Secure Enclave Pricing

An AVD secure enclave is not just VM compute. The full monthly cost includes the Azure Firewall anchoring the network boundary, OS disks that run continuously regardless of VM power state, backup storage, and Log Analytics ingestion. Each component is priced independently in Azure Government — understanding the full picture prevents budget surprises after deployment.

All prices are approximate as of early 2026 (Azure Government — US Gov Virginia). Verify current rates at the Azure Government pricing calculator before budgeting.

---

AVD Control Plane

The AVD service itself — host pools, workspaces, application groups, and the gateway that brokers connections — is free. Microsoft does not charge per session, per user, or per host pool. You pay only for the underlying Azure infrastructure resources listed below.

---

Session Host Compute

For a personal (assigned) pool, select a VM size based on the workload profile of your users. Three tiers cover light, standard, and power-user scenarios — D8as_v6 is the recommended default for most deployments.

Tier	VM Size	vCPU	RAM	Best For
Light	Standard_D4s_v5	4	16 GB	Email, browser, light Office — no Teams video, no large files
Standard	Standard_D8as_v6	8	32 GB	General knowledge workers — Office, Teams, browser, line-of-business apps
Power User	Standard_D16as_v6	16	64 GB	Data analysts, developers, users with large datasets or many concurrent applications

Windows Enterprise license is included in M365 E3/E5

For AVD personal pools running Windows 11 Enterprise single-session, the Windows license is covered by M365 E3 or E5 — there is no additional OS license cost on the VM. Pricing below reflects compute only.

The "8 hr/day" column assumes 176 active hours per month (8 hours × 22 business days) using Start VM on Connect to power down VMs outside active use.

Light — Standard_D4s_v5 (4 vCPU, 16 GB RAM)

Hourly Rate	Monthly (24/7)	Monthly (8 hr/day)
$0.192/hr	$140/VM	$34/VM

Standard — Standard_D8as_v6 (8 vCPU, 32 GB RAM)

Hourly Rate	Monthly (24/7)	Monthly (8 hr/day)
$0.384/hr	$280/VM	$68/VM

Power User — Standard_D16as_v6 (16 vCPU, 64 GB RAM)

Hourly Rate	Monthly (24/7)	Monthly (8 hr/day)
$0.768/hr	$561/VM	$135/VM

---

OS Disks

OS disks are billed continuously regardless of VM power state. Stopping a VM saves compute cost but not disk cost.

Disk Type	Size	Monthly Cost/VM	Best For
Standard SSD E10	128 GB	$8	Light users — email, browser, light Office; acceptable performance
Premium SSD P10	128 GB	$20	Default — best login performance, recommended baseline
Premium SSD P20	512 GB	$70	Users with large local data (CAD files, datasets)

Start with Premium SSD P10; evaluate Standard SSD after first month

The Windows 11 OS and standard productivity applications consume 40–70 GB. A P10 128 GB disk provides comfortable headroom and the best login responsiveness. After the first month of use, users who run only browser, email, and light Office are candidates for Standard SSD E10 — saving $12/VM/month with a modest reduction in disk throughput. Do not use Standard SSD for users running data-heavy applications or frequent large file operations.

64 GB disks are not viable for personal pools

A 64 GB OS disk leaves only 4–14 GB of free space after Windows 11 and Office install. Windows Update staging alone can fill this within weeks. Always provision at least 128 GB regardless of disk tier.

---

Azure Firewall

Azure Firewall is the most significant fixed infrastructure cost in a secure enclave. It is billed by the hour regardless of traffic volume, plus a per-GB data processing fee. A single Standard-tier instance covers a 20-user deployment comfortably.

SKU	Hourly Rate	Monthly (24/7)	Data Processing
Azure Firewall Standard	$1.25/hr	$912	$0.016/GB processed
Azure Firewall Premium	$1.66/hr	$1,212	$0.016/GB processed

Standard vs. Premium for AVD: Standard tier is sufficient for the FQDN-based rules that govern AVD egress. Premium adds TLS inspection and IDPS signatures — warranted if the firewall is also inspecting general internet traffic from corporate workloads, but not required for the AVD firewall rule set described in this guide.

Data processing cost estimate: A 20-user team producing 300 GB/month of outbound traffic through the firewall adds approximately $5/month in data processing fees — not a meaningful budget variable compared to the fixed hourly cost.

Azure Firewall is a fixed cost regardless of user count

Unlike session host compute, Azure Firewall cost does not scale linearly with users. A single Standard-tier firewall serves 5 users and 50 users at the same $912/month. This makes the per-user firewall cost high for small deployments and negligible for larger ones.

Supporting networking resources (one-time, low cost):

Resource	Approx. Monthly Cost
Standard Public IP (Firewall SNAT egress)	$4
AzureFirewallSubnet (required /26)	No charge
Hub VNet	No charge
VNet peering (hub ↔ spoke, per GB)	$0.01/GB transferred

---

VM Backup

Azure VM Backup protects the OS disk (and any data disks) of each session host. Because this is a personal pool with user data persisting on the VM disk, backup is a required component of the architecture — not optional.

Backup cost has two components: the protected instance fee and backup storage consumed.

Component	Approx. Monthly Cost
Protected instance fee (per VM, any size)	$5/VM
Backup storage — LRS, 128 GB disk (P10)	$3–6/VM
Backup storage — LRS, 512 GB disk (P20)	$10–20/VM

Estimate for 20-user deployment with 128 GB disks: $160–220/month total backup cost.

Use GRS only if a secondary-region recovery requirement exists

Backup storage defaults to Locally Redundant Storage (LRS). Geo-Redundant Storage (GRS) doubles the backup storage cost and is only warranted if a regulatory or business continuity requirement mandates recovery from a region failure.

---

Log Analytics Workspace

Log Analytics ingestion is required if you are sending AVD Insights diagnostics, Azure Firewall logs, or Defender for Endpoint telemetry to a central workspace. Pricing is per GB ingested and retained.

Component	Rate
Data ingestion	$2.76/GB (Pay-As-You-Go)
Data retention (first 31 days)	Included
Data retention (beyond 31 days)	$0.10/GB/month

Estimate for a 20-user AVD enclave: AVD session diagnostics, firewall logs, and sign-in logs typically generate 5–15 GB/month. At PAYG rates this is $14–41/month — a modest cost that is often absorbed into a shared Log Analytics workspace with other workloads.

Commitment tiers reduce ingestion cost significantly

If the workspace ingests more than 100 GB/month across all workloads, Commitment Tier pricing (starting at 100 GB/day) reduces the per-GB rate substantially. Evaluate this once the workspace is established and ingestion volume is measurable.

---

Total Enclave Cost — 20-User Deployment

The table below combines all resource categories for a 20-user personal pool using D8as_v6 (32 GB) session hosts with Start VM on Connect (176 active hours/month). Firewall and backup costs are fixed regardless of VM count.

Resource	Monthly Cost	Notes
Session host compute (20 × D8as_v6, 8 hr/day)	$1,360	Start VM on Connect, 176 hr/month
OS disks (20 × Premium SSD P10, 128 GB)	$400	Billed 24/7 regardless of power state
Azure Firewall Standard	$912	Fixed regardless of user count
Public IP	$4	One per firewall
VM Backup (20 VMs, 128 GB)	$180	Instance fee + LRS storage
Log Analytics	$25	Est. 8 GB/month ingestion
Monthly Total	$2,881
Annual Total	$34,572

Nerdio Manager license not included. See Nerdio Manager for AVD below for impact on total cost.

Standard SSD downgrade opportunity: For light users (email, browser, light Office), replacing Premium SSD P10 with Standard SSD E10 reduces disk cost from $20 to $8/VM/month. Migrating all 20 users to E10 saves $240/month ($2,880/year); a realistic split of 10 light users on E10 saves $120/month ($1,440/year). This change is independent of Nerdio and requires only a disk SKU change per VM.

Azure Firewall dominates fixed cost for small deployments

For a 20-user deployment, Azure Firewall represents 32% of total monthly spend and does not decrease as the user count or compute footprint shrinks. Organizations evaluating AVD on a per-user compute cost basis alone are often surprised by this line item. It is the price of maintaining a defensible network security boundary.

---

Nerdio Manager for AVD

Nerdio Manager for Enterprise is a third-party AVD management platform that adds cost optimization, automated image management, and operational tooling on top of the native Azure AVD control plane.

Power scheduling does not require Nerdio

8-hour/day VM scheduling is achievable with a free Azure Automation Runbook — a straightforward script that stops VMs on a schedule and pairs with Start VM on Connect for on-demand restarts. For organizations that want to manage this themselves, Nerdio is not required for power scheduling alone. Nerdio's value in a personal pool deployment is right-sizing based on actual utilization data and operational efficiency for image management and monitoring.

Business Benefits

Capability	Description	Impact
Power Scheduling	Powers VMs off after business hours and on before shift start on a configurable schedule	Achievable without Nerdio via Azure Automation Runbook — Nerdio adds reliability, pre-stage warm-up, and a managed UI
Start VM on Connect integration	Starts the assigned VM when a user initiates a connection, even outside scheduled hours	Native Azure AVD feature — Nerdio surfaces this in its scheduling UI alongside power-off rules
Pre-stage scheduling	Starts VMs 15–30 minutes before scheduled shift start	Eliminates cold-start wait time — VM is ready when the user connects; not easily replicated with a basic runbook
Right-sizing recommendations	Monitors per-VM CPU and RAM utilization and flags over-provisioned hosts	Primary Azure cost lever when power scheduling is already handled — enables targeted downgrades based on evidence
Image management	Scripted actions on a golden image, automated versioning, deployment to host pool	Reduces image update effort from 4–6 hours to 30–60 minutes per cycle
Cost attribution reports	Per-user, per-VM, per-resource-group cost reporting	Makes AVD spend visible and attributable for budget reviews and chargeback
Multi-tenant MSP dashboard	Manage multiple client environments from a single pane	Operational efficiency for managed service providers supporting multiple tenants

Projected Cost Savings — 20-User Personal Pool

With 8hr/day power scheduling already handled by an Azure Automation Runbook, the remaining Azure cost savings Nerdio provides come from right-sizing — downsizing VMs whose actual CPU and RAM utilization is well below their provisioned tier.

The baseline assumes all 20 users on D8as_v6 (32 GB) at 8hr/day. After 30 days of utilization monitoring, Nerdio identifies users whose workloads fit a smaller VM:

1. Review per-VM CPU and RAM utilization in Nerdio's dashboard after the first month.
2. Downgrade users consistently below 40% RAM utilization to D4s_v5 (4 vCPU, 16 GB) — roughly half the compute cost.
3. Upgrade users regularly exceeding 70% RAM to D16as_v6 (64 GB) if performance is impacted.

This produces a mixed fleet calibrated to actual usage rather than a uniform over-provisioned tier.

Right-Sizing Savings

Resource	Baseline (8 hr/day, no Nerdio)	Moderate Right-Sizing (10 × D4s_v5)	Aggressive Right-Sizing (20 × D4s_v5)
Session host compute	$1,360	$1,020	$680
OS disks (20 × P10 128 GB)	$400	$400	$400
Azure Firewall Standard	$912	$912	$912
Public IP	$4	$4	$4
VM Backup (20 VMs, 128 GB)	$180	$180	$180
Log Analytics	$25	$25	$25
Nerdio license	—	$100	$100
Monthly Total	$2,881	$2,641	$2,301
Annual Total	$34,572	$31,692	$27,612
Annual Savings vs. Baseline		$2,880 (8%)	$6,960 (20%)

Nerdio license estimate: $5/user/month × 20 users = $100/month. Actual pricing varies — contact Nerdio for current enterprise rates.

Right-sizing savings are utilization-dependent

The moderate scenario (10 of 20 users on D4s_v5) is a realistic outcome for a mixed knowledge-worker team. The aggressive scenario (all 20 on D4s_v5) applies only if the entire team has light workloads — primarily browser, email, and light Office use with no Teams video calls or data-heavy applications. Without Nerdio's per-VM utilization data, right-sizing is guesswork. That data is Nerdio's primary financial justification in a deployment where power scheduling is already handled natively.

Resilience and Failsafe Configuration

Nerdio controls AVD costs through an Azure app registration (service principal) with delegated permissions on your subscription. This design creates a dependency: if Nerdio loses its Azure connection, all automated cost controls — power scheduling, auto-start, pre-stage timers — stop functioning. VMs that are running at the time of the disconnection continue running indefinitely until manually stopped. This is the scenario some organizations have experienced as an unexpected spike in cloud costs.

Root causes of Nerdio connection loss:

Cause	Details
Service principal secret expiry	App registration client secrets have a configurable expiry (default 1–2 years in Entra). When the secret expires, Nerdio can no longer authenticate to Azure.
App registration deleted or permissions revoked	If an administrator removes the Nerdio app registration or removes its subscription-level RBAC roles, Nerdio loses access.
Nerdio service disruption	Nerdio is a SaaS platform — an outage on Nerdio's side prevents it from executing any Azure actions, even if the service principal is healthy.

Mitigations:

1. Azure Cost Management budget alerts (independent of Nerdio). Create a budget in Azure Cost Management scoped to the AVD resource group. Set alert thresholds at 80% (warning) and 100% (critical) of the expected monthly compute cost. Budget alerts fire independently of Nerdio — they are evaluated directly against Azure billing data. This is the primary financial safety net if Nerdio stops functioning.

2. Service principal expiry monitoring. In Entra > App registrations > [Nerdio app] > Certificates & secrets, note the client secret expiry date. Create a calendar reminder or an Entra Workbook alert 60 days before expiry to rotate the secret and update it in Nerdio before it expires. Nerdio's admin portal typically shows a warning when the credential is approaching expiry — verify this alert is configured and going to a monitored inbox.

3. Azure Monitor alert on running VM count. Create a metric alert on the AVD resource group: if the count of VMs in a "running" state during off-hours (e.g., between 20:00 and 06:00) exceeds an expected baseline (e.g., more than 2 VMs running overnight), trigger an email to the IT admin. This catches the "Nerdio stopped scheduling shutdowns" scenario within hours rather than at billing review time.

   Example: for a 20-user deployment with Start VM on Connect, you would expect 0–2 VMs running at midnight on a weekday. An alert threshold of 5+ running VMs overnight is a reliable signal that power scheduling has stopped.

4. Native AVD Scaling Plans as a documented fallback. Azure natively supports scaling plans for personal host pools (Start VM on Connect + scheduled deallocation). Important: Microsoft does not support running a native AVD scaling plan and a third-party management tool (Nerdio) on the same host pool simultaneously — they conflict. The native scaling plan is a fallback for if Nerdio is decommissioned or unavailable for an extended period, not a concurrent safety net.

   To enable native scaling as a fallback: in the Azure Government portal, navigate to Azure Virtual Desktop > Scaling Plans, create a plan for personal pools with scheduled deallocation, and assign it to the host pool after disabling Nerdio's power scheduling for that pool.

5. Regular Nerdio health validation. At least monthly, verify in the Nerdio portal that the Azure connection status shows active and that the service principal last-authenticated timestamp is recent. Include this in any routine operational review.

Treat Azure Cost Management alerts as mandatory, not optional

Even with Nerdio functioning perfectly, Azure Cost Management budget alerts are a valuable independent check. They protect against misconfigured schedules, forgotten test VMs, and other cost anomalies that Nerdio would not flag. Configure them at deployment time, not after the first unexpected bill.

---

AVD Deployment Checklist

Phase 1: AVD Host Pool Configuration

The Entra Join happens at the Host Pool level during VM provisioning.

• [ ] Host Pool Settings:

  • When creating or updating the Host Pool, ensure:
    • Domain to join: Select Microsoft Entra ID
    • Enroll VM with Intune: Select Yes

• [ ] RDP Properties (SSO):

  • In the Host Pool RDP Properties blade, add or set:
    • enablerdsaadauth:i:1
    • targetisaadjoined:i:1

Phase 2: RBAC Permissions (The "Logon" Right)

Unlike AD, being a user in Entra grants you nothing here. Login rights must be explicitly assigned.

• [ ] Assign Virtual Machine User Login:

  • Navigate to the Resource Group containing your AVD VMs.
  • Click Access control (IAM) > + Add > Add role assignment.
  • Role: Virtual Machine User Login
  • Members: Your AVD user group
  • Note: Assign at the Resource Group level to cover all session hosts in the pool, including newly provisioned VMs.

• [ ] Assign Virtual Machine Administrator Login (Admins):

  • Repeat the above for IT admin accounts using the Virtual Machine Administrator Login role.

Phase 3: Personal Pool Profile & Data Persistence

In a personal (assigned) pool, each user has a dedicated VM. Their Windows profile, application settings, and local files persist on the VM's OS disk between sessions. FSLogix and Shared PC Mode are not needed and must not be deployed to personal pool VMs.

Do not deploy FSLogix or Shared PC Mode to personal pool VMs

Shared PC Mode deletes user profiles on logout — on a personal pool where profile persistence is the goal, this destroys the user's work. FSLogix profile container policies targeting Azure Files blob storage add cost and complexity with no benefit when each VM has a single dedicated user.

OneDrive Known Folder Move — recommended supplemental data protection:

KFM redirects Desktop, Documents, and Pictures to OneDrive for Business, providing near-continuous protection for user working files independent of VM backup schedules. Create a Settings Catalog profile in Intune and assign it to your AVD session host group:

Setting	Value	Reason
Silently move Windows known folders to OneDrive	Enabled	Redirects Desktop/Documents/Pictures without user interaction
Tenant ID	Your GCC High tenant ID	Required for silent KFM enrollment
Silently sign in users to OneDrive with Windows credentials	Enabled	Single sign-on for OneDrive using Entra ID credentials
Prevent users from redirecting their Windows known folders	Enabled	Locks KFM on — prevents users from moving folders back to local disk

KFM accelerates VM replacement

If a session host fails and must be rebuilt, a user with KFM active can log in to their replacement VM and immediately access all KFM-redirected files from OneDrive — no backup restore required for working files. Azure VM backup (configured in Phase 1) covers application state and data stored outside KFM-redirected folders.

Phase 4: Verification & Success Indicators

• [ ] Connect to a session host as an administrator.

• [ ] Run dsregcmd /status and verify:

  • AzureAdJoined : YES — Host is natively cloud joined
  • DomainJoined : NO — Correct for cloud-only AVD. If YES, the host was accidentally Hybrid Joined
  • AzureAdPrt : YES — Valid cloud token present

• [ ] Verify GCC High Discovery:

  GCC High

  • MdmUrl: Must point to https://enrollment.manage.microsoft.us/enrollmentserver/discovery.svc
  • MdmTouUrl: Must point to https://portal.manage.microsoft.us/TermsofUse.aspx

  Critical Sovereign Check

  If MdmUrl points to a .com address, the session host is attempting to enroll in Commercial. Check the Host Pool region and DNS records.

  Commercial

  • MdmUrl: Must point to https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc
  • MdmTouUrl: Must point to https://portal.manage.microsoft.com/TermsofUse.aspx

• [ ] Visual Verification:

  • Open Settings > Accounts > Access work or school on the session host.
  • You should see the Entra ID connection with an Info button.
  • If the Info button is missing: The host is joined but not enrolled. Check MDM User Scope in Entra.

---

Architecture Validation (AVD-Specific)

These validation questions are specific to AVD. For general Entra Join validation, see Entra Join (The Cloud-Only Path).

Data Protection: Validation Checklist

• "Are we restricting Clipboard and Drive Redirection?"

  The Boundary: If users can copy/paste sensitive content from the secure AVD session to their unmanaged home PC, or redirect local drives into the session, your data boundary is broken. These are RDP Properties, not Intune settings. Set them in the Host Pool RDP Properties blade:

  • drivestoredirect:s: (empty string = no drive redirection)
  • redirectclipboard:i:0 (disable clipboard)

• "Is Azure VM Backup enabled on all session hosts, and is the Recovery Services vault in a US Gov region?"

  The Sovereign Check: In a personal pool, user data persists on the VM OS disk. Confirm that Azure Backup is enabled on every session host and that the Recovery Services vault is in US Gov Virginia or US Gov Arizona. A vault in a commercial Azure region moves backup data outside the FedRAMP High boundary.

Sovereignty

• "Do global support staff have console access to these session hosts?"

  The Law: A login to an AVD session host from a non-US IP address by a non-US national may violate ITAR/EAR, regardless of the host's location. Enforce a Conditional Access Policy restricting AVD access to US-based IPs or named locations.

• "Is the AVD control plane in GCC High?"

  The Check: Confirm the Host Pool is deployed in US Gov Virginia or US Gov Arizona in the Azure Government portal (portal.azure.us). Session hosts deployed in the wrong portal will not benefit from the FedRAMP High boundary.

Network

• "Is all session host egress going through Azure Firewall?"

  The Check: Verify the UDR on the session host subnet has a 0.0.0.0/0 route pointing to the Azure Firewall private IP — not to the VNet gateway or internet directly. In the Azure portal, select the session host NIC > Effective routes and confirm the default route next hop is VirtualAppliance.

• "Are any session hosts running with a public IP address?"

  The Boundary: AVD session hosts should have no public IPs. Users connect through the AVD Gateway (Microsoft-managed), not directly to the VM. A public IP on a session host creates a direct attack surface outside the firewall.

---

Session Host Image Management

Golden Image Strategy

The session host image determines the applications available to every user, the OS security baseline applied before Intune policy lands, and the patching baseline at VM provisioning time. For a personal pool, managing the golden image well prevents per-VM configuration drift over time.

The recommended approach is a Shared Image Gallery (SIG) in Azure Government with a repeatable build process.

Image build workflow:

1. Create a build VM (same size as production hosts — Standard_D8as_v6 or D16as_v6) from the Windows 11 Enterprise gallery image in the Azure Government portal.
2. Install and configure applications in the image:
   • Microsoft 365 Apps (pre-configured, current channel)
   • Line-of-business applications required by all users
   • Nerdio agent (if using Nerdio Manager)
   • Remove consumer bloat: default Start Menu pins, consumer features via Group Policy
3. Run Windows Update to fully patch the image before capture.
4. Run Sysprep: %windir%\system32\sysprep\sysprep.exe /generalize /oobe /shutdown
5. Capture the deallocated VM to an Image Version in Shared Image Gallery.
6. Replicate the image version to both US Gov Virginia and US Gov Arizona.

Shared Image Gallery configuration:

Setting	Required Value
Gallery region	US Gov Virginia (primary)
Replication regions	US Gov Virginia, US Gov Arizona
Image definition OS state	Generalized
Security type	Trusted Launch (enables Secure Boot + vTPM on session hosts)
Replication count	2 per region

Build the golden image in Azure Government — not commercial Azure

Building the image in a commercial subscription and importing it to Azure Government is not a straightforward path and risks embedding commercial endpoint references in the image. Create the build VM directly in your Azure Government subscription.

Automate image builds with Azure Image Builder

Azure Image Builder (AIB) automates the build → patch → sysprep → capture → replicate pipeline using a Bicep or JSON template. For monthly patch cycles, AIB reduces the process from 2–3 hours of manual steps to a triggered pipeline job. AIB is available in Azure Government.

Image Update Cadence

In a personal pool, new image versions are not automatically applied to running VMs — users keep their VM until it is explicitly replaced. Establish a documented cadence:

Trigger	Action
Monthly Patch Tuesday	Build and validate new image version; stage in test pool 5 business days before replacing production VMs
Major application version update	New image version; coordinate VM replacement timing with users
Critical/High CVSS vulnerability	Expedited image build; replace affected VMs within the change window

---

AVD Client Configuration

Users connect to their session hosts using either the Windows App (current client) or the legacy Remote Desktop client. In GCC High, the feed subscription URL is sovereign — this is the most common first-connection misconfiguration.

Feed Subscription URL (GCC High)

Client	GCC High Feed URL
Windows App (recommended)	https://rdweb.wvd.microsoft.us/api/arm/feeddiscovery
Remote Desktop client (legacy)	https://rdweb.wvd.microsoft.us/api/arm/feeddiscovery
AVD Web Client	https://client.wvd.microsoft.us

Using the commercial feed URL blocks all GCC High workspaces

The commercial feed (rdweb.wvd.microsoft.com) will not display GCC High host pools. Users will see an empty workspace or an auth error. Always use the .us sovereign URL when subscribing.

Supported Clients by Platform

Platform	Client	GCC High Support
Windows 10/11	Windows App (Microsoft Store)	Full support
macOS	Windows App (Mac App Store)	Full support
iOS / iPadOS	Windows App (App Store)	Full support
Android	Remote Desktop (Play Store)	Supported; Windows App not yet on Android
Web browser	AVD Web Client (client.wvd.microsoft.us)	Full support — sovereign URL required

Windows App replaces the Remote Desktop client

Microsoft is transitioning from the Remote Desktop client to Windows App as the primary AVD client. Windows App handles GCC High feed discovery automatically and receives updates through the Microsoft Store. Use Windows App for all new deployments; the legacy client remains functional but is not receiving feature investment.

Connecting with Windows App

Install

Platform	Source
Windows 10/11	Microsoft Store — Windows App
macOS	Mac App Store — search "Windows App"
iOS / iPadOS	App Store — search "Windows App"

Subscribe to the GCC High Feed

1. Open Windows App
2. Click the + icon (top right) → Add Work or School account
3. Sign in with the user's GCC High Entra account — this triggers MFA
4. If the workspace does not appear after sign-in, select + Add → Workspace and enter the feed URL manually:

   https://rdweb.wvd.microsoft.us/api/arm/feeddiscovery

5. The assigned session host will appear as a desktop tile in the workspace

Feed auto-discovery

Windows App attempts feed discovery automatically on sign-in using the account's tenant home region. For GCC High tenants this should resolve to the sovereign endpoint without manual URL entry. If the workspace appears empty, the manual URL entry in step 4 is the fix.

Connect and Verify

1. Click the session host tile — Windows App launches the RDP session through the AVD Gateway
2. If prompted for credentials at the Windows login screen, SSO is not configured — verify enablerdsaadauth:i:1 is set in the host pool RDP properties
3. Once connected, open a browser inside the session and navigate to https://myip.microsoft.com — confirm the egress IP matches the Azure Firewall public IP
4. In the AVD session, open Settings → About (or run whoami /upn in a terminal) to confirm you are signed in with the correct Entra identity

Validate the Connection in CA Sign-In Logs

After a successful connection, verify E001 fired correctly:

1. Entra admin center → Monitoring → Sign-in logs
2. Filter by the user's UPN and the last 30 minutes
3. Look for a sign-in to Azure Virtual Desktop — Status should be Success, CA policy E001 should show Grant — Phishing-resistant MFA satisfied

---

Monitoring & AVD Insights

AVD Insights is a native monitoring workbook built on Azure Monitor and Log Analytics. It provides session host health, connection metrics, user experience data, and alert history — and reuses the Log Analytics workspace already deployed in Phase 1 for Azure Firewall diagnostics.

Enabling AVD Insights

1. In the Azure Government portal, navigate to Azure Virtual Desktop > Host Pools > [your host pool] > Insights.
2. Enable diagnostic settings for the host pool — send Checkpoint, Error, Management, and Feed log categories to the Log Analytics workspace.
3. Enable data collection rules on session host VMs to forward Windows event logs and performance counters:
   • Event channels: System, Application, Microsoft-Windows-TerminalServices-LocalSessionManager/Operational
   • Performance counters: CPU (% Processor Time), Memory (Available MBytes), Disk (% Free Space) at 60-second intervals

Key Monitoring Views

View	What to Watch	Action Threshold
Session Host Health	Hosts in Unavailable state	Alert on any single Unavailable host — personal pool, so 1 unavailable = 1 user impacted
Connection Reliability	Connection failure rate	Alert if > 5% failures in a 1-hour window
User Experience	Round-trip time	RTT > 150ms sustained indicates connectivity issue between user and Azure region
Resource Utilization	CPU and RAM per VM	> 85% sustained triggers right-sizing review in Nerdio
MDE Sensor Health	Active sensor count (Defender portal)	Alert if sensor count drops below total VM count — indicates VM missed onboarding

Recommended Log Analytics Alerts

// Alert: Session host entered Unavailable state
WVDAgentHealthStatus
| where Status == "Unavailable"
| summarize count() by SessionHostName, TimeGenerated

// Alert: High connection failure rate — last 1 hour
WVDConnections
| where TimeGenerated > ago(1h)
| summarize Total = count(), Failed = countif(State == "Failed") by bin(TimeGenerated, 5m)
| extend FailureRate = todouble(Failed) / todouble(Total)
| where FailureRate > 0.05

---

Control Mapping

GCC High

AVD Sovereign Tenant — CMMC Control Mapping

The AVD secure enclave architecture directly implements the following NIST SP 800-171 Rev 2 controls through mechanisms specific to the AVD deployment model. For the complete control matrix across all technologies, see Appendix A: Compliance Controls.

CMMC Practice	NIST 800-171 Control	AVD Implementation
AC.L2-3.1.1	Limit system access to authorized users	Virtual Machine User Login RBAC role is required for session host interactive sign-in — Entra group membership alone grants nothing. Users without explicit role assignment receive Access Denied at connection time regardless of license or group state.
AC.L2-3.1.3	Control the flow of CUI in accordance with approved authorizations	RDP Properties redirectclipboard:i:0 and drivestoredirect:s: prevent clipboard paste and drive mapping out of the session. CUI cannot be transferred to an unmanaged endpoint at the protocol level.
AC.L2-3.1.14	Route remote access via managed access control points	All user sessions are brokered through the AVD Gateway (Microsoft-managed sovereign service). Direct RDP to session hosts is not possible — session hosts have no public IPs and the UDR routes all traffic through Azure Firewall. The gateway is the single managed ingress point.
AC.L2-3.1.15	Monitor and control remote access sessions	Virtual Machine Administrator Login is restricted to named IT admin accounts. Privileged console sessions are logged in Entra sign-in logs, separate from user sessions, and subject to the same phishing-resistant CA requirements.
MA.L2-3.7.5	Require MFA for remote maintenance sessions	Administrative access via Virtual Machine Administrator Login is gated by Conditional Access policy A002 (phishing-resistant auth required). FIDO2 or WHfB is enforced before any privileged session is established.
PE.L2-3.10.1	Limit physical access to CUI to authorized individuals	Session hosts run in Azure Government datacenters (US Gov Virginia / US Gov Arizona). No CUI touches end-user hardware — users see only a rendered screen. Physical access to CUI is scoped to Microsoft's FedRAMP High certified facilities.
SC.L2-3.13.1	Monitor, control, and protect communications at external boundaries	Azure Firewall with deny-all default (Priority 4096) and explicit FQDN allow rules enforces boundary control at all session host egress. All denied traffic is logged to Log Analytics.
SC.L2-3.13.5	Implement subnetworks for publicly accessible system components	Session hosts have no public IP addresses and are not internet-routable. All external connectivity is inbound via the AVD Gateway service tag and outbound via Azure Firewall private IP. The session host subnet is isolated from the public internet.
SC.L2-3.13.8	Implement cryptographic mechanisms to prevent unauthorized disclosure of CUI in transit	RDP sessions are encrypted via TLS 1.2+ enforced by the AVD Gateway. No unencrypted remote session path exists in this architecture.
SC.L2-3.13.16	Protect the confidentiality of CUI at rest	Session host OS disks are encrypted with BitLocker (Intune policy) and Azure Storage Service Encryption (AES-256). All data and keys reside within the Azure Government FedRAMP High boundary.

Commercial

AVD — NIST SP 800-171 Rev. 3 Control Mapping

The AVD architecture implements the following NIST SP 800-171 Rev. 3 requirements through mechanisms specific to the AVD deployment model. For the complete control matrix, see Appendix A: Compliance Controls.

NIST SP 800-171 Rev. 3	Control Description	AVD Implementation
3.1.1	Limit system access to authorized users	Virtual Machine User Login RBAC role is required for session host interactive sign-in — Entra group membership alone grants nothing.
3.1.3	Control the flow of information	RDP Properties redirectclipboard:i:0 and drivestoredirect:s: prevent clipboard paste and drive mapping out of the session.
3.1.14	Route remote access via managed access control points	All sessions brokered through the AVD Gateway. Session hosts have no public IPs — the gateway is the single managed ingress point.
3.1.15	Monitor and control privileged remote access sessions	Virtual Machine Administrator Login restricted to named admin accounts; privileged sessions logged in Entra sign-in logs.
3.7.5	Require MFA for remote maintenance	Administrative access via Virtual Machine Administrator Login gated by phishing-resistant Conditional Access.
3.10.1	Limit physical access to organizational systems	Session hosts run in ISO 27001 / SOC 2 Type II certified Azure datacenters. No sensitive data touches end-user hardware.
3.13.1	Monitor and control communications at external boundaries	Azure Firewall with deny-all default and explicit FQDN allow rules enforces egress boundary control.
3.13.5	Implement subnetworks	Session hosts isolated with no public IPs; all external connectivity via Azure Firewall private IP.
3.13.8	Implement cryptographic protections for data in transit	RDP sessions encrypted via TLS 1.2+ enforced by AVD Gateway.
3.13.16	Protect the confidentiality of data at rest	OS disks encrypted with BitLocker and Azure Storage Service Encryption (AES-256).

---

Related Reference

For the detailed Azure Firewall rule reference (application rule collections, network rules, customer rule template, and troubleshooting KQL), see AVD Firewall Reference.

For the complete compliance control matrix, see Appendix A: Compliance Controls.