Background & Challenge
An organization deploying Azure Virtual Desktop (AVD) faced a fundamental challenge that every hybrid organization encounters when moving workloads to Azure: the existing Group Policy infrastructure was entirely on-premises, relying on domain-joined devices and on-prem domain controllers for policy application. AVD session hosts enrolled in Microsoft Intune — and managed via Entra ID — don't receive traditional Group Policy the same way.
The project required systematically identifying every relevant GPO in the environment, evaluating each policy setting, and determining whether it had a supported Intune equivalent. Settings without a direct Intune analog required custom configuration — either through Settings Catalog, ADMX ingestion, PowerShell scripts deployed via Intune, or remediation scripts.
The stakes were real: AVD session hosts without proper configuration would expose security gaps, break user experience expectations, and potentially violate the organization's baseline security posture.
Key principle: The goal was not to clone GPOs verbatim into Intune. It was to achieve equivalent policy outcomes using cloud-native mechanisms — and to document any gaps or differences explicitly.
My Role
I led the GPO-to-Intune migration effort as the senior systems engineer on the AVD deployment project. My responsibilities included:
- Auditing the existing GPO structure and cataloging all policy settings relevant to AVD session hosts
- Mapping each GPO setting to its Intune equivalent using Microsoft's GPO analytics tooling and manual review
- Creating and testing Intune device configuration profiles (Settings Catalog, ADMX templates, and custom OMA-URI where needed)
- Deploying ADMX-backed policies for applications not natively supported in the Intune Settings Catalog
- Writing PowerShell-based remediation scripts for settings with no direct Intune equivalent
- Validating policy application on AVD session hosts via Intune compliance reporting and endpoint diagnostic tools
- Documenting all migration decisions, gaps, and rationale for future reference and compliance review
Technical Approach
Phase 1 — GPO Audit: Exported all relevant GPOs using Group Policy Management Console (GPMC) and reviewed them in combination with Microsoft's Intune GPO Analytics tool (available in the Intune portal under Device Configuration). This tool automatically flags which settings have Intune equivalents and which do not.
Phase 2 — Settings Catalog Profiles: The majority of security baseline settings — BitLocker, Windows Defender, user rights assignments, audit policy — had direct equivalents in the Intune Settings Catalog. These were configured first as they represented the highest compliance risk if missed. Profiles were scoped to the AVD session host device group using Entra ID dynamic groups.
Phase 3 — ADMX Policy Ingestion: Several application-specific settings (browser policies, Office settings, line-of-business application configurations) were managed via ADMX templates in GPO. These were ingested into Intune using the custom ADMX import feature, then configured via the Administrative Templates profile type in Intune.
Phase 4 — Remediation Scripts: A handful of settings — primarily machine-level registry modifications and startup/shutdown script equivalents — had no Intune analog. These were handled via Intune's Platform Scripts (PowerShell) and Remediation Scripts features, with detection and remediation logic written for each.
Phase 5 — Validation: Each profile was tested on a pilot AVD session host. Policy application was verified through Intune's Device Configuration report, the MDM Diagnostics Report on the endpoint itself, and manual functional testing. A final compliance check confirmed all endpoints met the organization's security baseline before production rollout.
Key Challenges & Resolutions
Settings with no Intune equivalent: Several legacy GPO settings — particularly legacy security policies carried forward from older Windows versions — had no direct Intune equivalent. These were addressed through a combination of PowerShell remediation scripts and documented risk acceptance where the setting was no longer applicable in a cloud-hosted context.
Profile conflict resolution: Multiple Intune profiles targeting the same settings created policy conflicts, which Intune reports as errors in compliance dashboards. Resolved by auditing all assigned profiles for overlapping setting keys and consolidating into purpose-specific profiles with clear naming conventions and documented scope.
ADMX import limitations: Not all ADMX templates imported cleanly into Intune — some required version updates or manual XML editing to resolve schema validation errors. Documented each case with the resolution for future maintainers.
Time zone policy for AVD: AVD session hosts were displaying incorrect time zones for users in different regions. Traditional GPO time zone redirection doesn't apply the same way in a multi-session AVD environment. Resolved by combining an Intune configuration profile for machine-level time zone and a logon script deployed via Intune that sets user-specific time zone based on a location attribute in Entra ID.
Outcome
The Azure Virtual Desktop deployment went live with a fully documented Intune-managed policy baseline, replacing the on-premises GPO dependency for all AVD session hosts. The organization gained cloud-native visibility into endpoint compliance through the Intune dashboard, with no on-prem infrastructure required for policy application.
All migration decisions — including documented exceptions and risk acceptances — were compiled into a policy migration guide that now serves as the organization's reference for future AVD expansions and Intune policy governance.