Skip to main content

Appendix D: AVD Deployment Timeline

This timeline covers a greenfield GCC High Azure Virtual Desktop deployment — 20 personal-pool session hosts, one engineer, 65 hours budgeted. It is calibrated for a cloud-only tenant with no existing Azure infrastructure, no on-premises AD, and no Intune baseline. Adjust phase durations proportionally if infrastructure is partially in place.

For architecture context and network topology, see Scenario: Azure Virtual Desktop and the AVD Firewall Reference.


Deployment Parameters

ParameterValue
Tenant stateGreenfield — no existing Azure or M365 GCC High configuration
Host pool typePersonal (1 VM per user — no FSLogix, no Shared PC Mode)
Session hosts20 VMs, Windows 11 Enterprise single-session
Users20 (1:1 VM-to-user assignment)
TeamOne engineer
Total budget65 hours
Azure regionUS Gov Virginia (recommended)

The 30-Day Commitment

A 30-day delivery timeline is achievable. The 65 implementation hours fit comfortably within 30 calendar days for one engineer. What is not achievable in 30 days is provisioning a GCC High tenant and Azure Government subscription from scratch — those processes are controlled entirely by Microsoft and your client's licensing infrastructure, not by your team.

The practitioner's position should be stated explicitly at contract signing:

"We can deliver a production-ready secure enclave within 30 days from the date you provide us with Global Admin access to your GCC High Entra tenant and Subscription Owner access to your Azure Government subscription. The clock starts when access is granted, not when the contract is signed."

Setting this expectation in writing at contract signing prevents the most common source of delivery disputes on time-sensitive engagements.


Required Access (Non-Negotiable)

Two access grants are required before a single implementation hour can be logged. Both must be in hand before Day 1.

AccessRole RequiredWhy
GCC High Entra tenantGlobal AdministratorRequired to configure Conditional Access, Intune enrollment, Entra Join policies, and device compliance. Scoped roles are insufficient — tenant-wide policy changes require Global Admin during initial build.
Azure Government subscriptionSubscription OwnerRequired to create resource groups, deploy VNets, Azure Firewall, host pools, and assign RBAC. Contributor role is insufficient — RBAC assignments require Owner.
Do not begin implementation without both access grants

Starting work without Global Admin or Subscription Owner is the fastest path to a failed engagement. You will hit a permission wall during Phase 1 or Phase 2, lose calendar days waiting for access to be granted, and absorb the schedule impact while the client perceives a delivery failure. Require both access grants as a contract condition, not a courtesy request.


Provisioning Lead Times (Customer Responsibility)

These timelines are outside the engineer's control. Clients who say "we need this in 30 days" must be made aware of them at the earliest opportunity — ideally before the contract is signed.

ItemTypical Lead TimeNotes
GCC High Entra tenant provisioning10–15 business daysRequires an AOS-G (Authorized Cloud Service Provider) reseller and Microsoft vetting. Cannot be self-provisioned.
Azure Government subscription provisioning5–10 business daysRequires an existing EA or MCA-Gov agreement. New subscriptions occasionally require manual Microsoft approval.
EA / Volume Licensing processIndeterminateOrganizations without an active EA must negotiate one before subscription provisioning can begin. If the EA admin has left the organization, Microsoft requires a formal process to designate a new one — this alone can take 2–4 weeks.
M365 GCC High license procurement3–5 business days after EA is activeMust be in place before identity and Intune phases begin.
The EA administrator gap is the least visible and most disruptive risk

An organization that has lost its EA administrator cannot provision or modify subscriptions until Microsoft acknowledges a new one. If your client does not know who their EA administrator is, treat this as a red flag and require resolution before contract execution. Do not assume the client's Microsoft account team will resolve it quickly — Microsoft account representatives go on leave, change accounts, and have no SLA obligation to expedite internal licensing processes.


Prerequisites (Outside the 65-Hour Clock)

All items below must be resolved before implementation begins. Each is a hard blocking dependency.

ItemOwnerBlocks
Global Admin access to GCC High Entra tenant granted to engineerCustomerAll phases
Subscription Owner access to Azure Government subscription granted to engineerCustomerPhase 1
M365 GCC High E3 or E5 licenses procured for all 20 usersCustomerPhases 2, 5
List of 20 users with confirmed UPNsCustomerPhase 4
IP address plan approved (VNet CIDR, subnet CIDRs)Engineer + CustomerPhase 1
Region confirmed (US Gov Virginia recommended)CustomerPhase 1
"Users may join devices to Microsoft Entra ID" policy change approvedCustomer leadershipPhase 4

Phase Summary

PhaseFocusHoursCumulative
1Azure Network Foundation99
2Identity & Conditional Access817
3Intune Baseline7.524.5
4AVD Build10–1234.5–36.5
5MDE Onboarding337
6Firewall Tuning845
7CA Policy Enforcement449
8End-to-End Testing756
9Documentation & Handoff460
Contingency565

Phase 1 — Azure Network Foundation

Hours 1–9

ActivityHours
VNet, session host subnet, Azure Firewall subnet, UDR (0.0.0.0/0 → Firewall)2
Azure Firewall deployment and initial application rule configuration3.5
Network rules (Essential-Ports, Teams-Media)1
Log Analytics workspace + Azure Firewall diagnostic settings0.5
NSG on session host subnet0.5
DNS configuration0.5
Azure Backup vault (for VM disk backup)1

Personal pool note: Because user data persists on the VM OS disk (no FSLogix), Azure Backup on VM disks is required here, not deferred. A user whose VM is deleted without a backup loses their profile and all locally stored data.

The Azure Firewall provisions in 10–15 minutes. Use that wait time to begin Phase 2 preparation.

Start from the AVD Firewall Reference rule collections rather than building rules from scratch. The initial rule set covers Priority 100–140 baseline; customer application rules are tuned in Phase 6.


Phase 2 — Identity & Conditional Access

Hours 9–17

ActivityHours
Break-glass accounts (2) — .onmicrosoft.com domain, YubiKey or long password in vault0.5
Restricted Management AU creation and security group assignment0.5
Entra security groups (EID_Emergency_Admin_Exclusions, EID_MFA_Exempt_Users, EID_Phishing_Resistant_Auth_Enforcement, EID_Service_Accounts, EID_TAP_Users, EID_Users_On_Managed_Devices, AVD_Users)1
Authentication methods: passkey (FIDO2), TAP policy, phishing-resistant auth strength definition1
Conditional Access policies — all 13 policies in Report-Only mode4
Verify break-glass accounts excluded from all policies0.5
Confirm "Users may join devices to Microsoft Entra ID" = All0.5

CA policies stay in Report-Only through Phase 6. Enabling Block or Grant controls before AVD is verified working will block enrollment, Intune sync, and MDE onboarding. Enforce in Phase 7 only.

WHfB provisioning gap — address in user onboarding communication before go-live. Windows Hello for Business cannot be provisioned over an RDP session. Every user must register a passkey or Microsoft Authenticator method at mysignins.microsoft.com before their first AVD login. If phishing-resistant CA is enforced at go-live and a user has not pre-registered, their session will be blocked with no actionable error message.


Phase 3 — Intune Baseline

Hours 17–24

ActivityHours
MDM User Scope → All (or targeted AVD_Users group)0.5
Enrollment restrictions — block Personally Owned Windows device enrollment0.5
OIB import and assignment to AVD session host Entra group2.5
Compliance policy for AVD session hosts (MDE risk level, BitLocker, OS version)1
Windows Update rings (conservative ring for session hosts)0.5
OneDrive KFM policy (Settings Catalog: Silently move known folders, Tenant ID, SSO, Prevent redirect)0.5
Verify first manually-enrolled test VM receives all policies2

Do not deploy FSLogix or Shared PC Mode policies 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 policies targeting blob/SMB storage are not needed because each VM has a dedicated user whose profile stays on the local disk.

Verify the test VM fully before provisioning the remaining 19 VMs. A policy error discovered on VM 1 is a 30-minute fix; the same error discovered after provisioning all 20 requires 20 remediation actions.


Phase 4 — AVD Build

Hours 24–34

ActivityHours
Host Pool creation — Personal type, Direct assignment, US Gov Virginia0.5
Application Group + Workspace creation0.5
RDP Properties: enablerdsaadauth:i:1, targetisaadjoined:i:1, redirectclipboard:i:0, drivestoredirect:s:0.5
RBAC: Virtual Machine User Login → AVD_Users group (Resource Group scope)0.5
RBAC: Virtual Machine Administrator Login → IT admin accounts0.5
AVD service principal — Virtual Machine Contributor on Resource Group (required for Start VM on Connect)0.5
20 VM provisioning in batches — Windows 11 Enterprise, Entra join, Intune enroll3
Start VM on Connect configuration1
Direct user-to-VM assignments (20 users → 20 VMs)1
Sample verification: dsregcmd /status, Intune enrollment, sovereign MdmUrl check2
(Optional) Nerdio Manager — service principal onboarding, power schedule configuration1–2

Start VM on Connect is not optional. Without it, all 20 VMs run 24/7 at full compute cost. The AVD service principal must have Virtual Machine Contributor on the resource group or it silently fails to start VMs on user connection — users receive a generic "remote session couldn't be started" error with no indication of root cause.

Use Direct assignment (not Automatic) for a named 20-user deployment. Direct assignment makes user-to-VM mapping explicit, simplifies support ("which VM is yours?"), and enables consistent VM naming (e.g., ENCL-USR-01 through ENCL-USR-20).

The Entra join constraint — "Users may join devices" must be All

The AADLoginForWindows VM extension that Entra-joins the session hosts runs at SYSTEM level and is subject to the tenant-level "Users may join devices to Microsoft Entra ID" policy. It cannot be scoped to a service principal. This policy must be set to All or VM provisioning silently fails at the join step. Mitigate with enrollment restrictions (blocks personal device MDM enrollment) and P006 (requires compliant device for resource access). See Scenario: Azure Virtual Desktop for the full compensating control set.


Phase 5 — MDE Onboarding

Hours 34–37

ActivityHours
Enable MDE–Intune connector at security.microsoft.us0.5
Create EDR policy (Auto from connector, All samples, Expedited telemetry)0.5
Create Antivirus policy (Tamper Protection on, Real-Time Protection on, Cloud-Delivered Protection: High)0.5
Assign both policies to AVD session host Entra group0.5
Verify all provisioned VMs show sensor health: Active in Defender portal1

Allow 15–30 minutes after policy assignment for devices to check in and onboard before checking the Defender portal.


Phase 6 — Firewall Tuning

Hours 37–45

ActivityHours
End-to-end connectivity test: user connects, opens Teams, Outlook, SharePoint1
KQL Query 1 (All Denied Traffic) — review and categorize denies1.5
Add customer application FQDNs to Customer-* collections (Priority 200+)2
Teams audio/video test — verify UDP 3478–3481 and 49152–53247 pass1
Second deny log review after rule additions1
Activate deny-all catch-all rule (Priority 4096)0.5
Final connectivity sweep with deny-all active1

Inventory customer applications before this phase. A Microsoft-only workload (Teams, Outlook, SharePoint) resolves in 4 hours. Each undiscovered SaaS application adds 30–90 minutes to identify and build its FQDN chain (primary domain, OAuth redirect, CDN, API endpoint). The Customer Application Rule Template and KQL queries are designed for this workflow.

This phase has the highest schedule variance in the engagement. Two or three undiscovered SaaS applications can consume the contingency reserve on their own.


Phase 7 — CA Policy Enforcement

Hours 45–49

Enable CA policies from Report-Only to Enforced in risk order. Allow 15–30 minutes between enabling each high-risk policy and confirming no unexpected blocks in Entra sign-in logs.

PolicyEnable OrderRisk Level
B001 Block Legacy Authentication1Low
B003 Block Device Code Flow2Low
B005 / B006 Block Non-Approved Registration3Low
B002 Block Non-Approved Locations4Medium
A001 Require MFA5Medium — verify all 20 users have MFA registered first
A002 Require Phishing-Resistant Auth6High — verify all users have passkey or WHfB enrolled
P006 Require Compliant Devices7High — verify all 20 VMs are Intune-compliant before enabling
B007 / B008 High Risk Sign-In Blocks8Low operational impact
Do not enable P006 before verifying all VMs are Intune-compliant

If any of the 20 session hosts is non-compliant when P006 is enforced, users assigned to that VM will be blocked from all M365 resources. Check Intune > Devices > All Devices and confirm every VM shows Compliant before enabling this policy.


Phase 8 — End-to-End Testing

Hours 49–56

ActivityHours
Full user simulation: connect, work session, disconnect, reconnect — verify profile persists on personal VM1.5
Verify clipboard is blocked (attempt paste from local machine into session)0.5
Verify drive redirection is blocked (attempt to map local drive into session)0.5
MDE portal: confirm all 20 VMs at sensor health Active0.5
Intune portal: confirm all 20 VMs compliant0.5
Entra sign-in logs: review for unexpected CA blocks since enforcement1
Azure Backup: run test backup job, verify recovery point created for a sample VM1
Start VM on Connect: power down a VM, connect as that user, verify VM auto-starts0.5
ASR rule review: check Defender portal for false-positive hits across the pool1

Phase 9 — Documentation & Handoff

Hours 56–60

DeliverableHours
As-built: VNet/subnet CIDRs, firewall rule collections, AVD host pool configuration1
Runbook: user onboarding (VM assignment, MFA pre-enrollment, first-login steps)1
Runbook: user offboarding (retire Intune, disable Entra device, delete VM if decommissioning)0.5
Runbook: VM replacement (re-provision, re-assign user, restore profile from Azure Backup)0.5
Customer walkthrough: Defender portal, Intune compliance dashboard, firewall deny logs1

Contingency Reserve — 5 Hours

Likely DrawEstimated Hours
Azure Government subscription approval delay (calendar, not implementation hours — but unblocking activities take time)1–2
Firewall tuning overrun — each undiscovered SaaS application beyond the Microsoft baseline0.5–1.5 per app
CA enforcement rollback — diagnosing unexpected blocks after enabling P006 or A0021–2

The 5-hour contingency is adequate for a well-prepared engagement. If the customer cannot confirm their application inventory before Phase 6, treat the contingency as pre-consumed and have a change-order conversation before starting.

📩 Don't Miss the Next Solution

Join the list to see the real-time solutions I'm delivering to my GCC High clients.