Tired of AVD multi-session hosts failing to enroll in Intune via Terraform? Here are three real-world, battle-tested solutions to fix the conflicting enrollment models and automate your deployments properly.

AVD Multi-Session + Intune Enrollment via Terraform — A Survivor’s Guide

I remember it vividly. It was 1 AM, and the go-live for our new finance department AVD environment was just hours away. The Terraform plan ran perfectly, the host pool `avd-finance-prod-01` was up, VMs were pingable, but not a single one would show up in Intune. Every time a second user logged into a session host, the enrollment from the first user would just… break. We were stuck in a loop of hell, and the coffee was doing nothing. This, my friends, is the silent, frustrating war between AVD’s multi-session model and Intune’s very single-minded, “one device, one user” worldview. If you’re hitting this wall, you’re not crazy. Let’s talk about how to fix it.

So, What’s Actually Breaking? The Root of the Problem

Before we dive into the fixes, you need to understand why this is happening. It’s not a bug; it’s a feature clash. By default, Intune MDM enrollment is user-licensed and user-scoped. It sees the first person to log into a fresh Windows machine, says “Aha! This is Jane’s machine now,” and enrolls the device under her identity. This works great for laptops.

But on an AVD multi-session host, after Jane logs in, John logs in an hour later. Intune, seeing a new user on what it thinks is “Jane’s machine,” gets confused and the process fails for John. This conflict is why your hosts are either not enrolling consistently or are dropping out of compliance. The goal is to force Intune to enroll the device itself, not the user who happens to log in first. We need to switch the enrollment scope from “user” to “device”.

The Fixes: From “Get Me Out of This Mess” to “Built to Last”

I’ve seen teams handle this in a few different ways, depending on their timeline, tooling, and tolerance for “technical debt.” Here are the three main approaches I’ve used in the trenches.

Solution 1: The Quick and Dirty (But Effective) Group Policy Fix

Let’s be honest, sometimes you just need it to work right now. Your Terraform code has already deployed the VMs, and you can’t afford a full rebuild. This is your emergency lever.

The solution is to use a Group Policy Object (GPO) linked to the OU containing your AVD session hosts. You’re going to manually force device-level enrollment.

1. Open the Group Policy Management Console.
2. Create and link a new GPO to the appropriate OU for your session hosts.
3. Navigate to: Computer Configuration > Policies > Administrative Templates > Windows Components > MDM.
4. Find the setting named “Enable automatic MDM enrollment using default Azure AD credentials”.
5. Set it to Enabled.
6. In the “Select credential type to use” dropdown, choose “Device Credential”.

Once you run a `gpupdate /force` on the hosts (or just wait), they will use their own Azure AD device identity to enroll in Intune. Problem solved. For now.

Warning: This is a manual, out-of-band fix. It breaks the pure Infrastructure-as-Code (IaC) model. If a new engineer deploys a host pool and forgets this GPO step, you’re back at square one. Use this to put out the fire, but plan to implement a better solution.

Solution 2: The DevOps Way (The Terraform Custom Script Extension)

This is my preferred method for existing Terraform-based deployments. Instead of a manual GPO, we’re going to inject the fix directly into the VM build process using a `custom_script_extension`. We’re basically automating what the GPO does by setting the registry keys directly.

First, create a simple PowerShell script, let’s call it `Enable-IntuneDeviceEnrollment.ps1`:

# PowerShell script to set registry keys for device-based Intune enrollment
$registryPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\MDM"
$name = "AutoMDMEnrollment"
$name2 = "UseDeviceCredential"

# Create the key if it doesn't exist
If (-NOT (Test-Path $registryPath)) {
  New-Item -Path $registryPath -Force | Out-Null
}

# Set the registry values to force device credential enrollment
New-ItemProperty -Path $registryPath -Name $name -Value 1 -PropertyType DWORD -Force | Out-Null
New-ItemProperty -Path $registryPath -Name $name2 -Value 1 -PropertyType DWORD -Force | Out-Null

Now, in your Terraform code for the virtual machine (`azurerm_windows_virtual_machine`), add this extension resource block:

resource "azurerm_virtual_machine_extension" "intune_enrollment_fix" {
  name                 = "intuneEnrollmentFix"
  virtual_machine_id   = azurerm_windows_virtual_machine.main.id
  publisher            = "Microsoft.Compute"
  type                 = "CustomScriptExtension"
  type_handler_version = "1.10"

  settings = <<SETTINGS
    {
        "fileUris": ["https://yourstorageaccount.blob.core.windows.net/scripts/Enable-IntuneDeviceEnrollment.ps1"],
        "commandToExecute": "powershell -ExecutionPolicy Unrestricted -File Enable-IntuneDeviceEnrollment.ps1"
    }
  SETTINGS
}

Pro Tip: Store the PowerShell script in a place Terraform can access it, like an Azure Blob Storage container. This keeps your configuration clean and repeatable. Now, every VM you deploy with Terraform will automatically configure itself for proper Intune enrollment. Your IaC pipeline is whole again.

Solution 3: The Architect’s Choice (The ‘Golden Image’ Pipeline)

This is the “nuclear” option, but it’s also the most robust and scalable for large enterprises. Instead of fixing the VM after it’s built, you bake the solution right into the master image.

Using a tool like Packer or Azure Image Builder, you create a fully automated pipeline that:

1. Starts from a base Marketplace Windows 10/11 Enterprise multi-session image.
2. Runs all Windows updates.
3. Installs common applications (FSLogix, Teams, Office, etc.).
4. Runs a script to set the MDM enrollment registry keys (just like in Solution 2).
5. Syspreps and captures the image into an Azure Compute Gallery.

Your Terraform code then changes to deploy VMs from this custom “golden image” instead of the generic Marketplace one.

# Example of changing the source_image_id in your VM resource
resource "azurerm_windows_virtual_machine" "main" {
  # ... other config ...
  name                = "avd-prod-vm-${count.index}"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = "Standard_D4s_v3"
  
  source_image_id = "/subscriptions/YOUR_SUB_ID/resourceGroups/MyImageRG/providers/Microsoft.Compute/galleries/MyGallery/images/Win11-MultiSession-Intune-v1.2"

  # ... rest of your config ...
}

This is the most work to set up, but it pays huge dividends. VM deployment times are drastically faster because you aren’t running scripts on every boot, and your environment becomes incredibly consistent.

Comparison: Which Fix is Right for You?

There’s no single “best” answer, only the one that best fits your situation.

My advice? If you’re in a jam, use the GPO to get stable. Then, immediately plan a sprint to implement the Terraform custom script extension. If your organization is managing more than a couple of host pools, start the conversation about building a proper golden image pipeline. It will save you from another 1 AM firefight. Trust me.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions