Appendix C.2: AVD Firewall Reference

This appendix provides the Azure Firewall rule reference for Azure Virtual Desktop deployments in GCC High. Rules use Microsoft-maintained FQDN tags wherever they exist and explicit FQDNs only where no tag is available. For architecture context and the network topology, see Scenario: Azure Virtual Desktop.

Commercial equivalents

This appendix targets GCC High deployments. Microsoft's FQDN tags (WindowsVirtualDesktop, Office365, MicrosoftIntune, WindowsUpdate, WindowsDiagnostics, MicrosoftActiveProtectionService) are documented as cloud-aware. For commercial tenants, substitute the explicit .us domain suffixes in the remaining rules with .com equivalents — the tag-based rules do not change.

FQDN tag content gaps in GCC High — pair tags with explicit fallbacks

Service tags (IP-based) are reliably cloud-aware and resolve to sovereign IP ranges automatically. FQDN tags (FQDN-based) do not always carry their full sovereign FQDN list. The Azure Firewall FQDN tags overview documents that customers cannot inspect or modify tag contents — Microsoft hand-curates the FQDN list per tag, and sovereign endpoints sometimes lag or are missing entirely. Observed in deployments: *.wvd.azure.us (the GCC High AVD broker domain) is documented under the WindowsVirtualDesktop service tag but is not reliably present in the WindowsVirtualDesktop FQDN tag — traffic falls through to the deny-all even when the rule is correctly configured.

The pattern in this appendix is to pair every FQDN tag with explicit sovereign FQDNs as a fallback. The tag still buys forward compatibility for what Microsoft does maintain in it; the explicit fallback closes the gap. If you find another denied FQDN that should be covered by a tag, add it explicitly to the corresponding rule rather than assuming the tag is wrong.

---

Rule Structure and Priority Model

Rules are organized into application rule collections and network rule collections. Within each collection, rules are evaluated top-to-bottom. Collections are evaluated lowest-priority-number first. The deny-all catch-all at priority 4096 terminates any traffic not matched by an explicit allow.

Application rules and network rules have separate priority namespaces

In the Azure Firewall UI, Application rule collections and Network rule collections are configured in separate tabs with independent priority numbering. A network rule at Priority 200 and an application rule at Priority 200 do not conflict — they are evaluated independently.

Application rule collections (FQDN-based, for TCP/HTTP/HTTPS traffic):

Priority	Collection	Scope
100	AVD-Control-Plane	AVD platform (tag) + deployment-specific storage, ServiceBus, Key Vault, ARM, Graph, agent hub
110	Cert-Services	Third-party CRL/OCSP (Entrust, DigiCert, GlobalSign)
120	M365	Microsoft 365 (Office365 tag) and Intune (MicrosoftIntune tag)
130	Windows-Management	Windows Update, diagnostics, activation, browser, NCSI, SmartScreen, CRL/OCSP
140	Defender-For-Endpoint	MDE sensor communication (MAPS tag + portal)
150	Third-Party-Security	Proofpoint URL Defense, PhishAlarm
160	Azure-Backup	Recovery Services Vault control plane and queue-storage backend (AzureBackup tag + explicit sovereign FQDNs)
200–299	Customer-*	Customer-specific application rules (see template)
4096	Deny-All-Log	Catch-all deny with logging

Network rule collections (IP/port-based, evaluated before application rules for matching traffic):

Priority	Collection	Scope
200	Essential-Ports	DNS, IMDS, Azure health probe, NTP
210	Teams-Media	Teams audio/video UDP ports
220	Azure-Services	Entra ID, Azure Monitor, KMS activation via service tags

---

Application Rule Collections

Priority 100: AVD-Control-Plane

Rule Name	Protocol	Target	Purpose
AVD-Platform	HTTPS:443	fqdnTag: WindowsVirtualDesktop plus explicit FQDNs: *.wvd.azure.us, ecs.office.com, *.attest.azure.us	AVD gateway, broker, attestation, side-by-side stack, connection center, and Azure Attestation. *.wvd.azure.us covers the GCC High broker domain that the FQDN tag does not reliably carry (see the FQDN-tag-gap warning above). ecs.office.com is the AVD connection center — Microsoft's endpoint reference documents it without a service tag, so it must be listed explicitly. *.attest.azure.us covers Azure Attestation regional endpoints (sharedugv.ugv.attest.azure.us, shareduga.uga.attest.azure.us, etc.) used by Trusted Launch VMs at boot to validate TPM and Secure Boot state. The AzureAttestation service tag exists but is IP-based (NSG / network rules only); for application-rule FQDN coverage the wildcard is required.
AVD-Deployment	HTTPS:443	*.blob.core.usgovcloudapi.net, *.table.core.usgovcloudapi.net, *.servicebus.usgovcloudapi.net, *.vault.usgovcloudapi.net, management.usgovcloudapi.net, pasff.usgovcloudapi.net, graph.microsoft.us, agenthubprod.azureedge.us, fs.microsoft.com, portal.azure.us, *.portal.azure.us, *.hosting.portal.azure.us, *.azureportal.usgovcloudapi.net, *.applicationinsights.us, *.loganalytics.us, *.msidentity.us, *.usgovtrafficmanager.net, *.windowsazure.us, *.s-microsoft.com	Storage, ServiceBus, Key Vault, ARM, Graph, agent hub, and Windows config service — deployment-specific endpoints not covered by the tag. Azure Government portal — two distinct namespaces: the user-facing landing URL (portal.azure.us, *.portal.azure.us, *.hosting.portal.azure.us) is what administrators type into the address bar, while the portal extension hosting infrastructure (*.azureportal.usgovcloudapi.net) is where individual blades — including the Microsoft Entra admin center's IAM, Conditional Access, and Application blades — actually load their JavaScript, React framework (reactblade.azureportal.usgovcloudapi.net), and per-blade sandboxed iframes (sandbox-N.reactblade.azureportal.usgovcloudapi.net). Both wildcards are required: missing the second namespace makes the portal landing page load while every blade inside fails with a generic loading error. Azure portal resource-blade dependencies are pulled in from the Azure portal allowlist (US Government Cloud) — specifically *.applicationinsights.us (Application Insights blade), *.loganalytics.us (Log Analytics / KQL queries), *.msidentity.us (identity-platform-specific blade content), *.usgovtrafficmanager.net (Traffic Manager blade), *.windowsazure.us (legacy Azure namespace still used by older blade extensions), and *.s-microsoft.com (Azure Marketplace storefront). These wildcards are documented by Microsoft as required for full Azure portal admin functionality and are required only when AVD users perform Azure resource administration from inside the session. Specific resource blades pull additional endpoints already covered by other rules — Storage Explorer uses *.blob.core.usgovcloudapi.net (here), Key Vault blade uses *.vault.usgovcloudapi.net (here), and the AAD admin blade uses Graph endpoints in the M365 collection.
AVD-Deployment-Http	HTTP:80	ctldl.windowsupdate.com, fs.microsoft.com	Certificate trust list and Windows config service — HTTP-only access path (the HTTPS access path is covered by AVD-Deployment)

---

Priority 110: Cert-Services

Rule Name	Protocol	Target FQDNs	Purpose
Cert-Services	HTTPS:443, HTTP:80	*.entrust.net, *.digicert.com, *.globalsign.com	CRL/OCSP for third-party certificate authorities

---

Priority 120: M365

Rule Name	Protocol	Target	Purpose
Office365	HTTPS:443	fqdnTag: Office365 plus the explicit fallback list aligned to the GCC High M365 Common and Office Online endpoint table: *.edge.skype.com, www.office.com, www.microsoft365.com, *.office365.us, *.gov.online.office365.us, *.usgovcloud.microsoft, *.usgovcloud-static.microsoft, *.usgovcloud-usercontent.microsoft, *.auth.microsoft.us, *.gov.us.microsoftonline.com, login.microsoftonline.us, graph.microsoftazure.us, entra.microsoft.us, *.entra.microsoft.us, entra.microsoft.com, *.entra.microsoft.com, login.microsoftonline.com, login-us.microsoftonline.com, loginex.microsoftonline.com, login.windows.net, graph.windows.net, clientconfig.microsoftonline-p.net, *.microsoftonline-p.com, *.msauth.net, *.msauthimages.us, *.msftauth.net, *.msftauthimages.us, *.cdn.office.net, officehome.msocdn.us, lpcres.delve.office.com, has.spserv.microsoft.com, officeclient.microsoft.com, config.svc.cloud.microsoft, *.officeapps.live.com, *.office.delivery.microsoft.com, officecdn.microsoft.com, officecdn.microsoft.com.edgesuite.net, office15client.microsoft.com, officepreviewredir.microsoft.com, officeredir.microsoft.com, r.office.microsoft.com, insertmedia.bing.office.net, to-do.microsoft.com, wcpstatic.microsoft.com, account.activedirectory.windowsazure.us, gov.teams.microsoft.us, *.gov.teams.microsoft.us, statics.teams.microsoft.com, *.nel.measure.office.net, attachments.office365-net.us, oneclient.sfx.ms, g.live.com, admin.onedrive.us, *.svc.ms, *.aadrm.us, *.informationprotection.azure.us, admin.microsoft.com, outlook.office365.com	Exchange, SharePoint, Teams signaling, M365 portal, Office Online, Office desktop client activation and delivery, Microsoft Entra auth UI and branding, Office Home, Delve, Outlook hosted add-ins, My Apps, and Entra ID account management. The fallback list groups roughly as: the GCC High *.office365.us namespace (covers portal.office365.us, www.office365.us, outlook.office365.us, OSI, Loki, Tasks via wildcard); the new Microsoft 365 Unified Domains namespace (*.usgovcloud.microsoft, *.usgovcloud-static.microsoft, *.usgovcloud-usercontent.microsoft) into which Microsoft is migrating SaaS UI experiences such as the M365 portal and My Apps; GCC High native auth and Graph (*.auth.microsoft.us, *.gov.us.microsoftonline.com, plus the explicit login.microsoftonline.us central token endpoint and graph.microsoftazure.us AAD Graph in case the Office365 fqdnTag's coverage drifts); the Microsoft Entra admin center for both sovereign and commercial namespaces (entra.microsoft.us, *.entra.microsoft.us, entra.microsoft.com, *.entra.microsoft.com) — Microsoft documents both wildcards as required for GCC High in the Entra ID FAQ because the admin center's MSAL bootstrap follows the same instance-discovery pattern as login.microsoftonline.com; the Entra auth UI CDN family (*.msauth.net, *.msauthimages.us, *.msftauth.net, *.msftauthimages.us) plus the legacy auth UI shell wildcard (*.microsoftonline-p.com, which consolidates secure.aadcdn.microsoftonline-p.com, login.microsoftonline-p.com, and nexus.microsoftonline-p.com into one entry) which the Office365 FQDN tag claims to carry but in practice does not reliably resolve sovereign-cloud variants; the cross-cloud auth and instance-discovery endpoints required by MSAL bootstrap and OneAuth/WAM (login.microsoftonline.com, login-us.microsoftonline.com, loginex.microsoftonline.com, login.windows.net, graph.windows.net, clientconfig.microsoftonline-p.net) — see the Why login.microsoftonline.com (commercial) is required in GCC High info note immediately below this table for the rationale and Microsoft source citations; the M365 UI shell, Office Home, and Delve (*.cdn.office.net, officehome.msocdn.us, lpcres.delve.office.com); Office Online and document cache (*.officeapps.live.com, *.office.delivery.microsoft.com); Office desktop client config and redirects (officeclient.microsoft.com, office15client.microsoft.com, officeredir.microsoft.com, officepreviewredir.microsoft.com, r.office.microsoft.com, officecdn.microsoft.com, officecdn.microsoft.com.edgesuite.net); Office "Insert Media" (insertmedia.bing.office.net); the Outlook hosted add-in service (has.spserv.microsoft.com); Web Conferencing Provider static for Outlook→Teams meeting join (wcpstatic.microsoft.com); Microsoft To Do (to-do.microsoft.com); the unified Microsoft Cloud config endpoint (config.svc.cloud.microsoft); Teams/Skype configuration (*.edge.skype.com); cross-cloud redirect targets that GCC High inherits (www.office.com, www.microsoft365.com); the My Apps / Entra ID account portal backend API (account.activedirectory.windowsazure.us); the GCC High Microsoft Teams namespace (gov.teams.microsoft.us, *.gov.teams.microsoft.us, statics.teams.microsoft.com) — required for Teams real-time signaling and the Trouter routing service (e.g., go.trouter.gov.teams.microsoft.us), documented as AllowRequired in GCC High Microsoft Teams row 31, with statics.teams.microsoft.com (Row 21) covering the Teams web client static asset CDN; the M365 Network Error Logging endpoint (*.nel.measure.office.net) — covering m365cdn.nel.measure.office.net and officehub.nel.measure.office.net, which Office and M365 web clients use for browser-side network error reporting; the Exchange attachment service (attachments.office365-net.us) — note this is a different TLD from *.office365.us so the wildcard does not catch it; OneDrive sync client endpoints (oneclient.sfx.ms, g.live.com, admin.onedrive.us) — documented as DefaultRequired in GCC High SharePoint/OneDrive Row 10 and reinforced in OneDrive Sync Release Notes (suppressing g.live.com will silently break OneDrive sync; allow-list, do not block); SharePoint sync infrastructure (*.svc.ms, Row 20); and Azure Information Protection / sensitivity labels (*.aadrm.us, *.informationprotection.azure.us, Row 30) — required for any tenant using AIP / unified labeling / Microsoft Purview Information Protection; and the commercial M365 admin center and Outlook bootstrap endpoints (admin.microsoft.com, outlook.office365.com) which OneAuth/WAM probes during the same instance-discovery flow as login.microsoftonline.com — when a GCC High user opens the M365 admin center or starts an Outlook desktop session, the client first reaches the commercial endpoint to learn the tenant's home cloud, gets the sovereign-cloud redirect, and completes the actual session at admin.microsoft.us / outlook.office365.us. Without these two entries, the M365 admin center loads blank and Outlook desktop sign-in stalls before reaching the sovereign endpoint. Both carry the #disable-next-line no-hardcoded-env-urls Bicep directive as intentional CAB evidence. The wildcard *.office365.us is preferred over enumerating sovereign subdomains so future GCC High *.office365.us rollouts are covered automatically.
Intune	HTTPS:443	fqdnTag: MicrosoftIntune plus explicit FQDNs: *.manage.microsoft.us, intune.microsoft.us, discovery.dm.microsoft.us, imeswdsc-afd-pri.manage.microsoft.com	Intune MDM enrollment, device-management discovery, policy delivery, and the Microsoft Intune admin center. The explicit *.manage.microsoft.us covers the Intune service endpoints (manage.microsoft.us, r.manage.microsoft.us, etc.) documented by Microsoft; intune.microsoft.us is the GCC High Intune admin portal URL — documented as a US Government customer-designated endpoint — required when administrators open the Intune admin center from inside an AVD session. discovery.dm.microsoft.us is the sovereign MDM device-management discovery endpoint — clients hit it during the enrollment handshake and during subsequent MDM check-ins; not reliably carried by the FQDN tag in GCC High. imeswdsc-afd-pri.manage.microsoft.com is the Intune Management Extension Win32 app delivery service (IME Software Distribution Service via Azure Front Door) — the FQDN is intentionally .com because Microsoft hosts Win32 content delivery as a single global service with no sovereign equivalent; without this entry, Win32 app deployments fail silently and the IME log shows HTTP 0 connection-refused errors that are easy to misdiagnose as content-URL problems rather than a firewall block. Carries the #disable-next-line no-hardcoded-env-urls Bicep directive as intentional cross-cloud CAB evidence. The MicrosoftIntune FQDN tag does not reliably carry any of these in GCC High.
Entra-Registration	HTTPS:443	enterpriseregistration.windows.net, enterpriseregistration.microsoftonline.us	Entra ID device registration endpoint. Required at first boot for Entra-joined and hybrid-joined session hosts to register; not carried by the Office365 or MicrosoftIntune FQDN tags. Both variants are listed: .windows.net is the legacy commercial cross-cloud namespace that current desktop clients still target, and .microsoftonline.us is the GCC High sovereign ADRS endpoint documented by Microsoft and required by Intune partner service endpoints. Different builds of the device-registration client target different endpoints; allowing both eliminates the version-dependency.

Why commercial endpoints appear in a GCC High allow list

The Office365 rule explicitly allows several commercial-cloud endpoints — login.microsoftonline.com, login.windows.net, graph.windows.net, *.microsoftonline-p.com, the legacy login-us.microsoftonline.com, and the Microsoft Entra admin center wildcards entra.microsoft.com / *.entra.microsoft.com — even though the tenant authenticates against login.microsoftonline.us and administrators land at entra.microsoft.us. This is not a leak; Microsoft documents these as required for GCC High in two places. The auth endpoints are listed in Microsoft 365 Common and Office Online row 14 (and the same row appears in the DoD endpoint list). The Entra admin center wildcards are listed in the Microsoft Entra ID FAQ — How can I allow Microsoft Entra admin center URLs on my firewall or proxy server?, which explicitly enumerates *.entra.microsoft.com, *.entra.microsoft.us, and *.entra.microsoftonline.cn together — meaning Microsoft considers all three TLD variants reachable from any cloud's admin center.

Why MSAL probes the commercial endpoint: MSAL.js, MSAL.NET, and OneAuth/WAM start every auth flow with an instance discovery call to login.microsoftonline.com/common/discovery/instance to determine which sovereign cloud the tenant lives in. The discovery response identifies the tenant as sovereign and redirects the actual sign-in to login.microsoftonline.us — but the discovery probe itself targets the commercial endpoint. Without firewall reachability, the MSAL bootstrap stalls and downstream pages (myapps.microsoft.us, the Entra admin center at entra.microsoft.us, the M365 portal, anything embedding MSAL.js) load blank. The Entra admin center follows the same pattern: a probe to entra.microsoft.com precedes the redirect to entra.microsoft.us. See National clouds — authentication endpoints for the cloud-discovery model.

Sign-in via the commercial endpoint still fails as designed: Reaching login.microsoftonline.com over the network does not enable sign-in there. Entra enforces sovereign authentication for sovereign tenants and returns AADSTS900439 — USGClientNotSupportedOnPublicEndpoint if a sovereign client tries to sign in via the public endpoint. Allowing the FQDN at the firewall lets the discovery probe complete; it does not let users sign in via the commercial endpoint.

For CAB review: This entry exists to support the documented MSAL/OneAuth instance-discovery probe required by Microsoft's published GCC High endpoint list. It supports authentication availability, not commercial authentication. The Bicep #disable-next-line no-hardcoded-env-urls directive on these lines suppresses the standard Bicep linter warning for hardcoded environment URLs precisely because this exception is intentional and source-cited.

Add your tenant's SharePoint Online and OneDrive domains explicitly

The Office365 FQDN tag is documented as covering SharePoint Online, but in GCC High deployments tenant-specific subdomains commonly fall through to the deny-all — the same FQDN-tag-gap pattern called out at the top of this appendix. For each tenant whose users connect from this AVD environment, add <tenant>.sharepoint.us (SharePoint sites) and <tenant>-my.sharepoint.us (OneDrive for Business) as explicit fallback FQDNs — either appended to the Office365 rule's targetFqdns, or as a per-customer collection at Priority 200+ following the Customer Application Rule Template. Without the -my variant, OneDrive for Business sync fails silently while the SharePoint site itself appears to load.

Teams media traffic goes through network rules, not application rules

Teams audio and video (real-time media) use UDP ports 3478–3481 and 49152–53247 (ephemeral). These cannot be matched by FQDN-based application rules because UDP traffic is evaluated by Azure Firewall network rules only. See Network Rules: Teams-Media below.

---

Priority 130: Windows-Management

Rule Name	Protocol	Target	Purpose
WindowsUpdate	HTTPS:443, HTTP:80	fqdnTag: WindowsUpdate	Windows Update, Delivery Optimization, WSUS catalog, and App metadata
WindowsDiagnostics	HTTPS:443	fqdnTag: WindowsDiagnostics plus explicit FQDNs: *.events.data.microsoft.com, *.wosc.services.microsoft.com, *.pipe.aria.microsoft.com	Windows telemetry, Connected User Experiences, and OneSettings (Windows OS configuration delivery). The explicit *.events.data.microsoft.com covers versioned telemetry subdomains (e.g., v20.events.data.microsoft.com); the explicit *.wosc.services.microsoft.com covers Microsoft's newer OneSettings namespace (prod.client.wosc...) under the unified services.microsoft.com umbrella, which the tag's curated list has not yet picked up; the explicit *.pipe.aria.microsoft.com wildcard covers the Aria telemetry pipeline at any subdomain — both the browser-side variant (browser.pipe.aria.microsoft.com) used by Edge and Office browser components, and the M365 Common variant (tb.pipe.aria.microsoft.com) documented in GCC High M365 Common row 32. All three entries are forward-compatible with future subdomain rollouts.
WNS	HTTPS:443	*.wns.windows.com	Windows Push Notification Service — toast/tile notifications, Microsoft Store update push, MDM notification channel. Not currently covered by any FQDN tag.
Store-Licensing-Activation	HTTPS:443, HTTP:80	*.sls.microsoft.com, licensing.mp.microsoft.com, displaycatalog.mp.microsoft.com, titles.gcch.mos.svc.usgovcloud.microsoft, services.autopatch.microsoft.us, storeedgefd.dsx.mp.microsoft.com, adl.windows.com	Windows/Office activation, Store catalog and delivery (storeedgefd.dsx.mp.microsoft.com is the Microsoft Store Edge front door used to fetch Store apps and metadata), Autopatch control plane, and Windows Update App Delivery Layer (adl.windows.com)
PowerShell-Gallery	HTTPS:443	www.powershellgallery.com, psg-prod-eastus.azureedge.net, cdn.oneget.org	PowerShell Gallery — the registry that Install-Module, Find-Module, Update-Module, and Save-Module hit by default. www.powershellgallery.com serves the NuGet v2/v3 API and metadata; psg-prod-eastus.azureedge.net is the Azure CDN node that the gallery redirects package downloads to. cdn.oneget.org is retained for back-compat with the older OneGet / PackageManagement provider catalog. Not covered by any FQDN tag. Without these, Install-Module ExchangeOnlineManagement, Install-Module Microsoft.Graph, and other tooling installs fail with a NuGet provider error or a generic connection-refused. If new *.azureedge.net deny entries appear after deployment, the gallery has rotated to a different CDN node — add the observed FQDN; do not wildcard *.azureedge.net (shared with unrelated services). Reference: PowerShell Gallery overview.
Edge-Browser	HTTPS:443, HTTP:80	edge.microsoft.com, msedge.api.cdp.microsoft.com	Edge update and configuration. The HTTP:80 path is required because Edge's update channel falls back to plain HTTP for differential download and CRX delivery when HTTPS metadata is already cached; without it the cached path emits HTTP requests that fall through to the deny-all.
NCSI	HTTP:80	www.msftconnecttest.com, windows.msn.com, windows.msn.cn	Network Connectivity Status Indicator
SmartScreen-Watson	HTTPS:443	*.smartscreen.microsoft.com, *.urs.microsoft.com, *.watson.microsoft.com, unitedstates1.ss.wd.microsoft.us	SmartScreen URL reputation + Watson error reporting. The first three wildcards cover the commercial namespace; unitedstates1.ss.wd.microsoft.us is the GCC High SmartScreen explicit endpoint documented in MDE Standard Connectivity URLs - US Government. Used by Microsoft Defender SmartScreen for protection, reporting, and Network Protection / custom URL indicators on session hosts; the commercial wildcards do not catch *.wd.microsoft.us.
CRL-OCSP	HTTP:80, HTTPS:443	ocsp.msocsp.com, mscrl.microsoft.com, oneocsp.microsoft.com, crl.microsoft.com, crl2.microsoft.com, *.pki.core.windows.net, www.microsoft.com, go.microsoft.com	Microsoft certificate revocation list and OCSP distribution

---

Priority 140: Defender-For-Endpoint

Rule Name	Protocol	Target	Purpose
MAPS	HTTPS:443	fqdnTag: MicrosoftActiveProtectionService	Cloud-delivered protection (block-at-first-sight, reputation, sample submission)
Security-Compliance-Portals	HTTPS:443	*.security.microsoft.us, security.microsoft.us, compliance.microsoft.us, purview.microsoft.us, winatp-gw-usgt.microsoft.com, unitedstates1.cp.wd.microsoft.us, unitedstates1.x.cp.wd.microsoft.us	Microsoft 365 security and compliance admin portals plus MDE GCC High service endpoints. *.security.microsoft.us / security.microsoft.us: Microsoft Defender XDR portal (Defender for Endpoint, Defender for Office 365, Defender for Identity, Defender for Cloud Apps unified surface). compliance.microsoft.us, purview.microsoft.us: Microsoft Purview portal — DLP, Information Protection, eDiscovery, audit; documented as AllowRequired in GCC High M365 Common Row 26. winatp-gw-usgt.microsoft.com: the Microsoft Defender for Endpoint GCC High Command-and-Control gateway, documented in MDE Standard Connectivity URLs - US Government. Note: earlier versions of this appendix listed *.winatp-gw-usw.microsoft.com; that pattern is not in current Microsoft documentation and is replaced by the explicit winatp-gw-usgt.microsoft.com GCC High C2 endpoint. unitedstates1.cp.wd.microsoft.us and unitedstates1.x.cp.wd.microsoft.us: the GCC High MAPS / cloud-delivered protection / security intelligence update endpoints — these are not reliably carried by the MicrosoftActiveProtectionService FQDN tag in GCC High and are explicitly listed by Microsoft in the same MDE doc.

---

Priority 150: Third-Party-Security

Rule Name	Protocol	Target FQDNs	Purpose
Proofpoint	HTTPS:443, HTTP:80	urldefense.us, *.urldefense.us, addin-us.securityeducation.com	Proofpoint URL Defense rewrite/click-through, PhishAlarm reporting add-in

---

Priority 160: Azure-Backup

Outbound rules for Azure VM backup from session hosts to the Recovery Services Vault. Only required when Step 13 of the deployment runbook is followed with the public-access path (default). If the deployment uses a private endpoint instead, this rule collection is unused — backup traffic stays inside the VNet — but leaving it in place causes no harm.

Rule Name	Protocol	Target	Purpose
AzureBackup	HTTPS:443	fqdnTag: AzureBackup plus explicit FQDNs: *.backup.windowsazure.us, *.queue.core.usgovcloudapi.net	Azure VM backup outbound to the Recovery Services Vault (*.backup.windowsazure.us) and the storage-account queue backend used for backup orchestration (*.queue.core.usgovcloudapi.net). The AzureBackup FQDN tag exists but, per the FQDN-tag-gap warning, is not reliably populated with sovereign FQDNs in GCC High — pair the tag with the explicit fallbacks. The blob backend (*.blob.core.usgovcloudapi.net) and ARM endpoint (management.usgovcloudapi.net) are already covered by the AVD-Deployment rule and do not need to be repeated here; auth via login.microsoftonline.us is already covered by the Office365 rule.

Skip this collection if the vault uses a private endpoint

The private-endpoint alternative described in Step 13 routes backup traffic over a private IP inside the AVD VNet, so the firewall is not in the data path and these FQDN rules are never matched. The collection can be deleted from the Bicep template if you are certain you will not switch back to public access. Most deployments leave it in place — the rule collection is small and silently no-ops on the private path.

Priority 170: Client-Tenant-Endpoints

Tenant-specific FQDNs (SharePoint Online, OneDrive, and any other per-deployment hostnames) supplied through the clientTenantFqdns parameter rather than hard-coded in the template. The rule collection is generated only when the parameter is non-empty — by default the template ships without this collection at all, and adding a tenant's hostnames is an edit to the parameter file, not to avd-firewall.bicep. See Tenant-Specific Endpoints (Parameter File) for the deployment pattern.

---

Network Rule Collections

Priority 200: Essential-Ports

Traffic that cannot be expressed as FQDNs (IP-based or protocol-based infrastructure requirements).

Rule Name	Protocol	Source	Destination	Destination Port	Purpose
DNS	UDP, TCP	Session host subnet	Any	53	DNS resolution (use Azure DNS or your DNS resolver IP)
IMDS	TCP	Session host subnet	169.254.169.254	80	Azure Instance Metadata Service — required for VM identity tokens
Azure-HealthProbe	TCP	Session host subnet	168.63.129.16	80	Azure load balancer health probe — required for VM reachability
NTP	UDP	Session host subnet	Any	123	NTP time sync

IMDS and Azure health probe must be allowed

169.254.169.254 (IMDS) and 168.63.129.16 (health probe) are link-local addresses that Azure uses for internal platform communication. If your UDR sends all traffic to the firewall and these destinations are blocked by the deny-all rule, VMs will lose their managed identity tokens and health probe responses — causing enrollment failures, Intune policy application errors, and VM unavailability in the load balancer.

Priority 210: Teams-Media

Teams real-time audio and video require UDP. Azure Firewall cannot inspect UDP by FQDN — these ports must be opened by IP range or service tag.

Rule Name	Protocol	Source	Destination	Destination Ports	Purpose
Teams-STUN-TURN	UDP	Session host subnet	AzureCloud.usgovvirginia, AzureCloud.usgovariz	3478–3481	STUN/TURN for Teams media relay
Teams-Media-Ephemeral	UDP	Session host subnet	AzureCloud	49152–53247	Teams audio/video media streams

Why such a wide port range?

Teams uses ephemeral UDP ports (49152–53247) for peer-to-peer and relay media. The Microsoft transport relay selects from this range based on session negotiation. Narrowing the range causes intermittent audio/video failures that are difficult to diagnose because HTTPS signaling continues to work.

Priority 220: Azure-Services

Service-tag rules for Azure platform services where IP-range coverage is more reliable than FQDN matching, and for KMS activation's non-HTTPS port.

Rule Name	Protocol	Source	Destination (Service Tag)	Destination Ports	Purpose
AzureActiveDirectory	TCP	Session host subnet	AzureActiveDirectory	443	Entra ID IP range coverage
AzureMonitor	TCP	Session host subnet	AzureMonitor	443	Log Analytics, diagnostics, Azure Monitor
KMS-Activation	TCP	Session host subnet	AzureCloud	1688	Windows KMS license activation

---

Session-Host Subnets (Parameter File)

Every Allow rule in avd-firewall.bicep is scoped to a sourceAddresses list driven by the avdSubnetAddressSpace parameter. The parameter is an array — every entry in the array becomes a permitted source CIDR on every rule. A request whose source IP doesn't match any entry falls through the Allow collection and hits the Deny-All-Log rule at Priority 4096, even when the destination FQDN is otherwise allowed.

This matters when you add a host pool. The Multi-Pool Variant of the deployment runbook places each host pool in its own subnet (see Step 3 of Appendix C.1 § Multi-Pool Variant). Each new subnet must be added to avdSubnetAddressSpace and the firewall policy redeployed before the new pool's session hosts can reach Microsoft endpoints. Otherwise the symptom is a flood of denies for FQDNs that are visibly present in the Allow rules — including the AVD DSC artifact endpoint (wvdportalstorageblob.blob.core.usgovcloudapi.net, covered by the *.blob.core.usgovcloudapi.net wildcard in Priority 100: AVD-Control-Plane). The DSC extension fails with "The underlying connection was closed" after 17 retry attempts; the firewall logs show the deny against the deny-all-log collection rather than the named allow rule.

Parameter file template

using './avd-firewall.bicep'

// Session-host subnet CIDR blocks — one entry per host pool.
// Verify against the actual subnets in your AVD VNet before redeploying.
param avdSubnetAddressSpace = [
  '10.0.0.0/24'        // pool 1 (default subnet)
  '10.0.2.0/26'        // large pool A (≈34 VMs)
  '10.0.2.64/26'       // large pool B (≈31 VMs)
  '10.0.2.128/27'      // pool 3
  '10.0.2.160/27'      // pool 4
  '10.0.2.192/27'      // pool 5
  '10.0.2.224/27'      // pool 6
]

For single-pool deployments the template default — ['10.0.0.0/24'] — works without override. The override is required only when adding additional subnets.

Common quick fix and its trade-off

When the symptom of "DSC extension fails on new pool's VMs, firewall logs show denies for FQDNs that are in Allow rules" first appears in a deployment, the fastest unblock is to widen avdSubnetAddressSpace to a single VNet-spanning entry (e.g., ['10.0.0.0/16'] to cover the entire VNet) and redeploy. Pros: ≈5 minutes including redeploy, no need to enumerate every subnet. Cons: any IP in the VNet now matches as a source, including future subnets that weren't intended to be session hosts. For initial unblock or audit timelines the quick fix is acceptable; for steady-state operation, replace it with the explicit per-subnet array above so an unintended subnet doesn't quietly inherit AVD egress rights.

Troubleshooting checklist

If a new pool's VMs can't reach Microsoft endpoints:

1. Confirm the deny pattern is source-IP-based, not destination-FQDN-based. Use Query 1 of the Firewall Troubleshooting KQL below filtered to the session host's private IP. If the denies are against destinations that ARE in the Allow rule collections (e.g., *.blob.core.usgovcloudapi.net, manage.microsoft.us, fs.microsoft.com), the cause is almost certainly a missing entry in avdSubnetAddressSpace.
2. Verify the session host's NIC subnet. Azure portal → VM → Networking → primary NIC → Subnet. Confirm that CIDR is present in the deployed avdSubnetAddressSpace.
3. Confirm the deployed firewall policy has the expected source addresses. Azure portal → Firewall Policies → fwp-avd-prod-usgovva → any application rule collection → any rule → Source field. Should show every entry from avdSubnetAddressSpace.
4. Redeploy the firewall policy if the source-address list is stale: az deployment group create --resource-group <shared-RG> --template-file avd-firewall.bicep --parameters <tenant>.bicepparam. Bicep diffs and updates only the rule sources; rules are live the moment the deployment completes.

---

Tenant-Specific Endpoints (Parameter File)

The base avd-firewall.bicep template is intentionally generic — no tenant names, no SharePoint hostnames, nothing that varies per deployment. Tenant-specific FQDNs (the SharePoint Online and OneDrive hostnames for your Microsoft 365 tenant — <tenant>.sharepoint.us, <tenant>-my.sharepoint.us, and friends) are supplied at deployment time through a Bicep parameter file.

This separation matters whenever the base template is updated. Pulling a new version of avd-firewall.bicep (a new Microsoft-required FQDN, a sovereign-cloud endpoint correction, an additional service category) does not touch the parameter file — and the parameter file's tenant list does not need to be merged into a freshly downloaded template. Each side evolves independently.

How the parameter is consumed

A single clientTenantFqdns array = [] parameter is declared at the top of the template. When non-empty, the template generates an application rule collection at Priority 170 named Client-Tenant-Endpoints whose targetFqdns is the parameter value. When the parameter is empty (the default), the rule collection is omitted entirely — Azure Firewall rejects rule collections that contain zero rules, so the conditional avoids deploying an empty collection.

Parameter file template

The companion file avd-firewall.example.bicepparam shipped alongside avd-firewall.bicep is the starting point for a per-tenant parameter file. Copy it, rename it (tenant.bicepparam is a fine choice), and replace the contoso placeholders with the real tenant hostnames.

Download: avd-firewall.example.bicepparam

using './avd-firewall.bicep'

param clientTenantFqdns = [
  'contoso.sharepoint.us'
  'contoso-my.sharepoint.us'
  'contoso-files.sharepoint.us'
  'contoso-myfiles.sharepoint.us'
]

The four hostnames above cover the standard SharePoint Online / OneDrive surface in GCC High. <tenant>.sharepoint.us is the root site collection host, <tenant>-my.sharepoint.us is OneDrive, and the -files / -myfiles variants are reached by the OneDrive sync client and certain Office desktop sharing flows. Adding extra entries — line-of-business apps the tenant routes through the firewall, partner endpoints, vendor APIs — is just adding strings to the array; no template changes required.

Deploy with the parameter file

Reference the parameter file with --parameters on the same az deployment group create invocation documented in Step 2 of the deployment runbook:

az deployment group create \
  --resource-group rg-avd-prod-usgovva \
  --template-file avd-firewall.bicep \
  --parameters tenant.bicepparam

The CLI resolves the parameter file relative to the current directory; place it next to the template (or pass an absolute path) and the deployment picks up both the base policy and the tenant-specific collection in a single call.

Keep parameter files outside the published material

Real tenant hostnames are deployment data, not documentation. Hold the parameter files in a separate location — a private repository, a key vault secret, an internal SharePoint, or a private folder of this repo that the public build excludes — and pull the appropriate one at deployment time. The base template stays the single source of truth that every deployment can re-pull; the parameter files stay tenant-private.

---

Customer Application Rule Template

Customer-specific applications are added at Priority 200–299. Each customer deployment adds its own collection with a unique priority number within that range. Use this pattern when an application needs multiple rules grouped together (a primary host, a separate auth chain, a CDN, an API) — for simple lists of tenant FQDNs, the parameter file is shorter and avoids template edits altogether.

Assessment Checklist

Before deploying, inventory the applications your AVD users will access and categorize each:

• Government portals — agency-specific web applications (common: SAM.gov, USASpending.gov, MAX.gov)
• File sharing / transfer — SFTP servers, managed file transfer services, large file upload portals
• Line-of-business SaaS — CRM, ERP, project management, HR systems
• Authentication chains — OAuth providers for those SaaS apps (may require additional auth FQDNs)
• Vendor-specific tooling — specialized software with cloud licensing or telemetry (e.g., engineering software license servers, GIS platforms)
• Video conferencing (non-Teams) — Zoom, Webex, Google Meet each have their own FQDN/port requirements
• Print/scan services — cloud print services if local printing is required from AVD sessions

Template Structure

Collection: Customer-[AppName]
Priority: 200 (increment by 1 for each additional collection)
Action: Allow

Rules:
  [AppName]-Primary    HTTPS:443    [primary FQDNs]       Primary application
  [AppName]-Auth       HTTPS:443    [auth FQDNs]          OAuth/SAML auth chain
  [AppName]-CDN        HTTPS:443    [CDN FQDNs]           Static assets / CDN
  [AppName]-API        HTTPS:443    [API FQDNs]           API endpoints

Common Categories and Known FQDNs

Category	Common FQDNs to Add	Notes
Salesforce	*.salesforce.com, *.force.com, *.my.salesforce.com	The *.my.salesforce.com entry is required — the base *.salesforce.com does not cover custom subdomain auth redirects
ServiceNow	*.service-now.com, *.servicenow.com	Two domains used across product versions
Zoom	*.zoom.us, *.zoomgov.com, *.zoom.com	UDP 8801–8802 may be needed for media; add network rule if required
Workday	*.workday.com, *.myworkday.com, *.wd[n].myworkday.com	wd[n] varies by tenant; identify your tenant's subdomain first
Adobe Acrobat (cloud)	*.acrobat.com, *.arclabs.com, *.adobelogin.com	License activation uses *.adobelogin.com — if missing, Acrobat starts in trial mode
Esri / ArcGIS	*.arcgis.com, *.esri.com, *.arcgisonline.com	GIS platform with many CDN subdomains; start with wildcard, narrow after logging

Identify unknown FQDNs before deny-all goes live

Before adding the deny-all rule, run the firewall in allow-with-logging mode for 2–4 weeks with session hosts in production use. Export the firewall logs, extract the unique FQDNs, and use them to build your customer-specific rule collections. The KQL queries in the Troubleshooting section below are designed for this workflow.

---

Firewall Troubleshooting KQL

These queries run against the Log Analytics workspace connected to your Azure Firewall diagnostic settings. The firewall must have structured (resource-specific) logging enabled, sending Application rule log to AZFWApplicationRule and Network rule log to AZFWNetworkRule. See AVD Deployment Runbook § Step 5 for the diagnostic-settings configuration. If your firewall is still on the legacy "(Azure Diagnostics)" categories, the logs land in AzureDiagnostics with a free-form msg_s column instead — these queries will return no rows until you migrate.

Query 1: All Denied Traffic (Triage)

Surfaces every denied connection — application and network rule denials — sorted by frequency.

union AZFWApplicationRule, AZFWNetworkRule
| where Action == "Deny"
| extend Destination = coalesce(Fqdn, DestinationIp)
| summarize DenyCount = count(), LastSeen = max(TimeGenerated)
    by SourceIp, Destination, DestinationPort, Protocol, RuleCollection
| order by DenyCount desc
| take 100

Query 2: Single Host Investigation

When a user reports a specific application is broken, filter to their session host IP to see only their denied connections.

// Replace with the session host private IP of the affected user's session
let TargetIP = "10.x.x.x";
union AZFWApplicationRule, AZFWNetworkRule
| where Action == "Deny"
| where SourceIp == TargetIP
| extend Destination = coalesce(Fqdn, DestinationIp)
| project TimeGenerated, SourceIp, Destination, DestinationPort, Protocol, RuleCollection, Rule
| order by TimeGenerated desc

Query 3: FQDN Baseline (Before Deny-All Activation)

Run this during the allow-with-logging validation period to build your customer application rule list. This query shows every unique FQDN reached by session hosts — sorted by frequency — which becomes the input for building Priority 200+ customer collections.

// Set time range to cover representative business usage (1–2 weeks recommended)
AZFWApplicationRule
| where Action == "Allow"
| where isnotempty(Fqdn)
// Exclude already-documented infrastructure FQDNs to focus on unknown destinations
| where Fqdn !endswith ".microsoft.com"
    and Fqdn !endswith ".microsoft.us"
    and Fqdn !endswith ".windows.net"
    and Fqdn !endswith ".usgovcloudapi.net"
| summarize
    HitCount = count(),
    UniqueHosts = dcount(SourceIp),
    LastSeen = max(TimeGenerated)
    by Fqdn, DestinationPort
| order by HitCount desc

Export and categorize the baseline

Export the results of Query 3 to CSV and sort by HitCount. The top entries by hit count are the applications your users depend on most heavily. Group the FQDNs by application (often recognizable by domain) and build one customer rule collection per application. Low-frequency FQDNs that appear from only one or two hosts are candidates for closer review before allowing.

---

Update Procedure

The Bicep template is the source of truth for the rule set. Do not edit rules through the Azure portal — portal edits drift silently from the template, get overwritten on the next deployment, and leave no CAB-reviewable diff. Every rule change flows through the template.

When to deploy an update

• New application FQDNs discovered via the Query 3 baseline that need to be promoted into an allow rule.
• Microsoft documentation changes to required endpoints for AVD, M365, Intune, or MDE that are not absorbed by the existing FQDN tags (the WindowsVirtualDesktop, Office365, MicrosoftIntune, WindowsUpdate, WindowsDiagnostics, and MicrosoftActiveProtectionService tags auto-update; changes outside those tags' scope surface as new denies in Query 1).
• A new workload added to the AVD environment (new SaaS, new line-of-business app, new security tool).
• Retirement of a rule for a decommissioned application.

Prerequisites

• Azure CLI installed on the change operator's workstation, authenticated to Azure Government.
• Read/write access to the target resource group via a PIM-activated role (typically Firewall Contributor or Network Contributor).
• The Bicep template (avd-firewall.bicep) and the deployment script (load-firewall.azcli) under version control — every change reviewed and approved before deployment.
• An approved CAB ticket for CM.L2-3.4.3 evidence.

Deployment script: load-firewall.azcli

The three deployment commands wrapped as a runnable Azure CLI script. Commands 1 and 2 run once per firewall; command 3 runs on every rule update. Replace the placeholder values (<subscription-guid>, <firewall-name>, <rg-name>, <policy-name>) with the customer-specific values before running.

Download: load-firewall.azcli

# 1. Connect to Azure Government
az cloud set --name AzureUSGovernment
az account set --subscription <subscription-guid>
az login

# 2. One-time: associate the firewall with the policy object represented by the Bicep template.
# az network firewall update --name <firewall-name> --resource-group <rg-name> --firewall-policy <policy-name>

# 3. Every update: deploy the Bicep template + tenant parameter file to the resource group.
az deployment group create --resource-group <rg-name> --template-file avd-firewall.bicep --parameters <tenant>.bicepparam

Bicep template: avd-firewall.bicep

The full Azure Firewall policy expressed as a Bicep template — one resource per rule collection, parameterized on location, policy name, and AVD subnet CIDR. Deploy with the Deployment script above; the deployment is idempotent and a previous-template redeploy is the rollback path.

Download: avd-firewall.bicep

param location string = 'usgovvirginia'
param firewallPolicyName string = 'fwp-avd-prod-usgovva'
param avdSubnetAddressSpace string = '10.0.0.0/24'

@description('Tenant-specific FQDNs (e.g., contoso.sharepoint.us, contoso-my.sharepoint.us). Supplied per deployment via a .bicepparam file; leave empty to deploy the base policy unchanged.')
param clientTenantFqdns array = []

// 1. Create the Firewall Policy
resource firewallPolicy 'Microsoft.Network/firewallPolicies@2023-09-01' = {
  name: firewallPolicyName
  location: location
  properties: {
    sku: {
      tier: 'Standard'
    }
  }
}

// 2. Network Rule Collections (Evaluated First)
resource networkRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2023-09-01' = {
  parent: firewallPolicy
  name: 'DefaultNetworkRuleCollectionGroup'
  properties: {
    priority: 200
    ruleCollections: [
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Essential-Ports'
        priority: 200
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'DNS'
            ipProtocols: ['UDP', 'TCP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['*']
            destinationPorts: ['53']
          }
          {
            ruleType: 'NetworkRule'
            name: 'IMDS'
            ipProtocols: ['TCP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['169.254.169.254/32']
            destinationPorts: ['80']
          }
          {
            ruleType: 'NetworkRule'
            name: 'Azure-HealthProbe'
            ipProtocols: ['TCP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['168.63.129.16/32']
            destinationPorts: ['80']
          }
          {
            ruleType: 'NetworkRule'
            name: 'NTP'
            ipProtocols: ['UDP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['*']
            destinationPorts: ['123']
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Teams-Media'
        priority: 210
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'Teams-STUN-TURN'
            ipProtocols: ['UDP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['AzureCloud.usgovvirginia', 'AzureCloud.usgovariz']
            destinationPorts: ['3478-3481']
          }
          {
            ruleType: 'NetworkRule'
            name: 'Teams-Media-Ephemeral'
            ipProtocols: ['UDP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['AzureCloud']
            destinationPorts: ['49152-53247']
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Azure-Services'
        priority: 220
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'NetworkRule'
            name: 'AzureActiveDirectory'
            ipProtocols: ['TCP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['AzureActiveDirectory']
            destinationPorts: ['443']
          }
          {
            ruleType: 'NetworkRule'
            name: 'AzureMonitor'
            ipProtocols: ['TCP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['AzureMonitor']
            destinationPorts: ['443']
          }
          {
            ruleType: 'NetworkRule'
            name: 'KMS-Activation'
            ipProtocols: ['TCP']
            sourceAddresses: [avdSubnetAddressSpace]
            destinationAddresses: ['AzureCloud']
            destinationPorts: ['1688']
          }
        ]
      }
    ]
  }
}

// Conditional rule collection for client tenant-specific FQDNs.
// Wrapped in a ternary so the collection is omitted entirely when the
// parameter is empty (Azure Firewall rejects collections with zero rules).
var clientTenantRuleCollection = empty(clientTenantFqdns) ? [] : [
  {
    ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
    name: 'Client-Tenant-Endpoints'
    priority: 170
    action: { type: 'Allow' }
    rules: [
      {
        ruleType: 'ApplicationRule'
        name: 'Tenant-Endpoints'
        protocols: [{ protocolType: 'Https', port: 443 }]
        targetFqdns: clientTenantFqdns
        sourceAddresses: [avdSubnetAddressSpace]
      }
    ]
  }
]

// 3. Application Rule Collections (Evaluated Second)
resource applicationRuleCollectionGroup 'Microsoft.Network/firewallPolicies/ruleCollectionGroups@2023-09-01' = {
  parent: firewallPolicy
  name: 'DefaultApplicationRuleCollectionGroup'
  dependsOn: [
    networkRuleCollectionGroup
  ]
  properties: {
    priority: 300
    ruleCollections: concat([
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'AVD-Control-Plane'
        priority: 100
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'AVD-Platform'
            protocols: [{ protocolType: 'Https', port: 443 }]
            fqdnTags: ['WindowsVirtualDesktop']
            targetFqdns: [
              '*.wvd.azure.us'
              'ecs.office.com'
              '*.attest.azure.us'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'AVD-Deployment'
            protocols: [{ protocolType: 'Https', port: 443 }]
            targetFqdns: [
              '*.blob.core.usgovcloudapi.net'
              '*.table.core.usgovcloudapi.net'
              '*.servicebus.usgovcloudapi.net'
              '*.vault.usgovcloudapi.net'
              'management.usgovcloudapi.net'
              'pasff.usgovcloudapi.net'
              'graph.microsoft.us'
              'agenthubprod.azureedge.us'
              'fs.microsoft.com'
              'portal.azure.us'
              '*.portal.azure.us'
              '*.hosting.portal.azure.us'
              '*.azureportal.usgovcloudapi.net'
              '*.applicationinsights.us'
              '*.loganalytics.us'
              '*.msidentity.us'
              '*.usgovtrafficmanager.net'
              '*.windowsazure.us'
              '*.s-microsoft.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'AVD-Deployment-Http'
            protocols: [{ protocolType: 'Http', port: 80 }]
            targetFqdns: [
              'ctldl.windowsupdate.com'
              'fs.microsoft.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Cert-Services'
        priority: 110
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'Cert-Services'
            protocols: [
              { protocolType: 'Https', port: 443 }
              { protocolType: 'Http', port: 80 }
            ]
            targetFqdns: ['*.entrust.net', '*.digicert.com', '*.globalsign.com']
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'M365'
        priority: 120
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'Office365'
            protocols: [{ protocolType: 'Https', port: 443 }]
            fqdnTags: ['Office365']
            targetFqdns: [
              '*.edge.skype.com'
              'www.office.com'
              'www.microsoft365.com'
              '*.office365.us'
              '*.gov.online.office365.us'
              '*.usgovcloud.microsoft'
              '*.usgovcloud-static.microsoft'
              '*.usgovcloud-usercontent.microsoft'
              '*.auth.microsoft.us'
              '*.gov.us.microsoftonline.com'
              'login.microsoftonline.us'
              'graph.microsoftazure.us'
              'entra.microsoft.us'
              '*.entra.microsoft.us'
              'entra.microsoft.com'
              '*.entra.microsoft.com'
              #disable-next-line no-hardcoded-env-urls
              'login.microsoftonline.com'
              'login-us.microsoftonline.com'
              'loginex.microsoftonline.com'
              'login.windows.net'
              #disable-next-line no-hardcoded-env-urls
              'graph.windows.net'
              'clientconfig.microsoftonline-p.net'
              '*.microsoftonline-p.com'
              '*.msauth.net'
              '*.msauthimages.us'
              '*.msftauth.net'
              '*.msftauthimages.us'
              '*.cdn.office.net'
              'officehome.msocdn.us'
              'lpcres.delve.office.com'
              'has.spserv.microsoft.com'
              'officeclient.microsoft.com'
              'config.svc.cloud.microsoft'
              '*.officeapps.live.com'
              '*.office.delivery.microsoft.com'
              'officecdn.microsoft.com'
              'officecdn.microsoft.com.edgesuite.net'
              'office15client.microsoft.com'
              'officepreviewredir.microsoft.com'
              'officeredir.microsoft.com'
              'r.office.microsoft.com'
              'insertmedia.bing.office.net'
              'to-do.microsoft.com'
              'wcpstatic.microsoft.com'
              'account.activedirectory.windowsazure.us'
              'gov.teams.microsoft.us'
              '*.gov.teams.microsoft.us'
              'statics.teams.microsoft.com'
              '*.nel.measure.office.net'
              'attachments.office365-net.us'
              'oneclient.sfx.ms'
              'g.live.com'
              'admin.onedrive.us'
              '*.svc.ms'
              '*.aadrm.us'
              '*.informationprotection.azure.us'
              #disable-next-line no-hardcoded-env-urls
              'admin.microsoft.com'
              #disable-next-line no-hardcoded-env-urls
              'outlook.office365.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'Intune'
            protocols: [{ protocolType: 'Https', port: 443 }]
            fqdnTags: ['MicrosoftIntune']
            targetFqdns: [
              '*.manage.microsoft.us'
              'intune.microsoft.us'
              'discovery.dm.microsoft.us'
              #disable-next-line no-hardcoded-env-urls
              'imeswdsc-afd-pri.manage.microsoft.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'Entra-Registration'
            protocols: [{ protocolType: 'Https', port: 443 }]
            targetFqdns: [
              'enterpriseregistration.windows.net'
              'enterpriseregistration.microsoftonline.us'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Windows-Management'
        priority: 130
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'WindowsUpdate'
            protocols: [
              { protocolType: 'Https', port: 443 }
              { protocolType: 'Http', port: 80 }
            ]
            fqdnTags: ['WindowsUpdate']
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'WindowsDiagnostics'
            protocols: [{ protocolType: 'Https', port: 443 }]
            fqdnTags: ['WindowsDiagnostics']
            targetFqdns: [
              '*.events.data.microsoft.com'
              '*.wosc.services.microsoft.com'
              '*.pipe.aria.microsoft.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'WNS'
            protocols: [{ protocolType: 'Https', port: 443 }]
            targetFqdns: ['*.wns.windows.com']
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'Store-Licensing-Activation'
            protocols: [
              { protocolType: 'Https', port: 443 }
              { protocolType: 'Http', port: 80 }
            ]
            targetFqdns: [
              '*.sls.microsoft.com'
              'licensing.mp.microsoft.com'
              'displaycatalog.mp.microsoft.com'
              'titles.gcch.mos.svc.usgovcloud.microsoft'
              'services.autopatch.microsoft.us'
              'storeedgefd.dsx.mp.microsoft.com'
              'adl.windows.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'PowerShell-Gallery'
            protocols: [{ protocolType: 'Https', port: 443 }]
            targetFqdns: [
              'www.powershellgallery.com'
              'psg-prod-eastus.azureedge.net'
              'cdn.oneget.org'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'Edge-Browser'
            protocols: [
              { protocolType: 'Https', port: 443 }
              { protocolType: 'Http', port: 80 }
            ]
            targetFqdns: [
              'edge.microsoft.com'
              'msedge.api.cdp.microsoft.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'NCSI'
            protocols: [{ protocolType: 'Http', port: 80 }]
            targetFqdns: [
              'www.msftconnecttest.com'
              'windows.msn.com'
              'windows.msn.cn'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'SmartScreen-Watson'
            protocols: [{ protocolType: 'Https', port: 443 }]
            targetFqdns: [
              '*.smartscreen.microsoft.com'
              '*.urs.microsoft.com'
              '*.watson.microsoft.com'
              'unitedstates1.ss.wd.microsoft.us'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'CRL-OCSP'
            protocols: [
              { protocolType: 'Http', port: 80 }
              { protocolType: 'Https', port: 443 }
            ]
            targetFqdns: [
              'ocsp.msocsp.com'
              'mscrl.microsoft.com'
              'oneocsp.microsoft.com'
              'crl.microsoft.com'
              'crl2.microsoft.com'
              #disable-next-line no-hardcoded-env-urls
              '*.pki.core.windows.net'
              'www.microsoft.com'
              'go.microsoft.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Defender-For-Endpoint'
        priority: 140
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'MAPS'
            protocols: [{ protocolType: 'Https', port: 443 }]
            fqdnTags: ['MicrosoftActiveProtectionService']
            sourceAddresses: [avdSubnetAddressSpace]
          }
          {
            ruleType: 'ApplicationRule'
            name: 'Security-Compliance-Portals'
            protocols: [{ protocolType: 'Https', port: 443 }]
            targetFqdns: [
              '*.security.microsoft.us'
              'security.microsoft.us'
              'compliance.microsoft.us'
              'purview.microsoft.us'
              'winatp-gw-usgt.microsoft.com'
              'unitedstates1.cp.wd.microsoft.us'
              'unitedstates1.x.cp.wd.microsoft.us'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Third-Party-Security'
        priority: 150
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'Proofpoint'
            protocols: [
              { protocolType: 'Https', port: 443 }
              { protocolType: 'Http', port: 80 }
            ]
            targetFqdns: [
              'urldefense.us'
              '*.urldefense.us'
              'addin-us.securityeducation.com'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Azure-Backup'
        priority: 160
        action: { type: 'Allow' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'AzureBackup'
            protocols: [{ protocolType: 'Https', port: 443 }]
            fqdnTags: ['AzureBackup']
            targetFqdns: [
              '*.backup.windowsazure.us'
              '*.queue.core.usgovcloudapi.net'
            ]
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
      {
        ruleCollectionType: 'FirewallPolicyFilterRuleCollection'
        name: 'Deny-All-Log'
        priority: 4096
        action: { type: 'Deny' }
        rules: [
          {
            ruleType: 'ApplicationRule'
            name: 'Deny-All-Application'
            protocols: [
              { protocolType: 'Https', port: 443 }
              { protocolType: 'Http', port: 80 }
            ]
            targetFqdns: ['*']
            sourceAddresses: [avdSubnetAddressSpace]
          }
        ]
      }
    ], clientTenantRuleCollection)
  }
}

Post-deployment validation

Run these checks immediately after every deployment before closing the CAB ticket:

1. Rule count and structure. In the Azure portal, confirm the firewall policy shows the expected collection names and priorities. The count of rules per collection should match the template. Any discrepancy means the deployment silently failed or the template does not reflect what was intended.
2. Re-run Query 1 (All Denied Traffic). Check the 15 minutes immediately following the deployment for new denies on traffic that was previously allowed. A spike is an early warning that a rule was accidentally narrowed or removed.
3. Smoke-test the common paths — one user signs into AVD, opens Teams, opens Outlook, opens a SharePoint site, triggers a Windows Update check. If any path that worked before the deployment now fails, compare the Bicep diff against the deployment target and prepare rollback.
4. Export the rule listing (az network firewall policy rule-collection-group show) and attach to the CAB ticket as evidence of the post-deployment state.

Rollback

Rollback is a redeploy of the previous template:

git checkout <previous-commit> -- avd-firewall.bicep
az deployment group create --resource-group <rg-name> --template-file avd-firewall.bicep --parameters <tenant>.bicepparam
git checkout HEAD -- avd-firewall.bicep

The parameter file is not rolled back — only the template. Tenant-specific FQDNs are deployment data, not part of what's being reverted; the same parameter file deploys against the prior template state.

The deployment is idempotent — redeploying the prior state restores the prior rule set. If a rule is actively breaking production, rollback is always faster than attempting a forward-fix.

CAB evidence

Every deployment should close its CAB ticket with:

• The Git commit hash of the Bicep template deployed.
• The diff between the previous and new template.
• The az deployment group create command output.
• The Query 1 validation result (empty result or explained exceptions).
• The smoke-test log.

This package satisfies CM.L2-3.4.3 (Configuration Change Control) and CM.L2-3.4.4 (Security Impact Analysis) for the AVD network boundary.