I've come across an issue while helping partners go live a couple of times in the last week or so where the 'Join Entra ID' step fails if 'Enroll with Intune' is enabled under Integrations > Directory > Entra ID.
Symptoms
You will get the following error (or similar) when trying to deploy a new session host:
Install Join Entra ID extension
The VM will be enrolled with Intune
Error: An error occurred during Join Entra ID extension installation: System.AggregateException: One or more errors occurred. (Long running operation failed with status 'Failed'. Additional Info:'VM has reported a failure when processing extension 'hostname-join-aad' (publisher 'Microsoft.Azure.ActiveDirectory' and type 'AADLoginForWindows'). Error message: 'AAD Join failed.'. More information on troubleshooting is available at https://aka.ms/vmextensionwindowstroubleshoot. ') ---> Microsoft.Rest.Azure.CloudException: Long running operation failed with status 'Failed'. Additional Info:'VM has reported a failure when processing extension 'hostname-join-aad' (publisher 'Microsoft.Azure.ActiveDirectory' and type 'AADLoginForWindows'). Error message: 'AAD Join failed.'. More information on troubleshooting is available at https://aka.ms/vmextensionwindowstroubleshoot. ' at Microsoft.Rest.ClientRuntime.Azure.LRO.AzureLRO`2.CheckForErrors() at Microsoft.Rest.ClientRuntime.Azure.LRO.PutLRO`2.CheckForErrors() at Microsoft.Rest.ClientRuntime.Azure.LRO.AzureLRO`2.StartPollingAsync() at Microsoft.Rest.ClientRuntime.Azure.LRO.AzureLRO`2.BeginLROAsync() at Microsoft.Rest.Azure.AzureClientExtensions.GetLongRunningOperationResultAsync[TBody,THeader](IAzureClient client, AzureOperationResponse`2 response, Dictionary`2 customHeaders, CancellationToken cancellationToken) at Microsoft.Rest.Azure.AzureClientExtensions.GetLongRunningOperationResultAsync[TBody](IAzureClient client, AzureOperationResponse`1 response, Dictionary`2 customHeaders, CancellationToken cancellationToken) at Microsoft.Rest.Azure.AzureClientExtensions.GetPutOrPatchOperationResultAsync[TBody](IAzureClient client, AzureOperationResponse`1 response, Dictionary`2 customHeaders, CancellationToken cancellationToken) at Microsoft.Azure.Management.Compute.Fluent.VirtualMachineExtensionsOperations.CreateOrUpdateWithHttpMessagesAsync(String resourceGroupName, String vmName, String vmExtensionName, VirtualMachineExtensionInner extensionParameters, Dictionary`2 customHeaders, CancellationToken cancellationToken) at Microsoft.Azure.Management.Compute.Fluent.VirtualMachineExtensionsOperationsExtensions.CreateOrUpdateAsync(IVirtualMachineExtensionsOperations operations, String resourceGroupName, String vmName, String vmExtensionName, VirtualMachineExtensionInner extensionParameters, CancellationToken cancellationToken) at Microsoft.Azure.Management.Compute.Fluent.VirtualMachineExtensionImpl.CreateAsync(CancellationToken cancellationToken) --- End of inner exception stack trace --- at Microsoft.Azure.Management.Compute.Fluent.VirtualMachineImpl.CreateResourceAsync(CancellationToken cancellationToken) at Microsoft.Azure.Management.ResourceManager.Fluent.Core.ResourceActions.Creatable`4.Microsoft.Azure.Management.ResourceManager.Fluent.Core.ResourceActions.IResourceCreator<IResourceT>.CreateResourceAsync(CancellationToken cancellationToken) at Microsoft.Azure.Management.ResourceManager.Fluent.Core.DAG.CreatorTaskItem`1.ExecuteAsync(CancellationToken cancellationToken) at Microsoft.Azure.Management.ResourceManager.Fluent.Core.DAG.TaskGroupBase`1.ExecuteNodeTaskAsync(DAGNode`1 node, CancellationToken cancellationToken) at Microsoft.Azure.Management.ResourceManager.Fluent.Core.ResourceActions.CreatableUpdatable`5.ApplyAsync(CancellationToken cancellationToken, Boolean multiThreaded) at Riviere.Provision.Jobs.Partials.VMExtensions.JoinAADExtension.InstallTo(IVirtualMachine vm, AzureAdProfileOptions options, JobDetailsStringBuilder logger) in D:\a\1\s\src\Riviere.Provision\Jobs\Partials\VMExtensions\JoinAADExtension.cs:line 73. With extension result: {"name":"hostname-join-aad","type":"Microsoft.Azure.ActiveDirectory.AADLoginForWindows","typeHandlerVersion":"1.0.0.1","substatuses":null,"statuses":[{"code":"ProvisioningState/failed/-2145910734","level":"Error","displayStatus":"Provisioning failed","message":"AAD Join failed.","time":null}]}
Cause
This is caused by device enrolment restrictions within Intune. Microsoft's documentation on this: https://learn.microsoft.com/en-gb/mem/intune/enrollment/enrollment-restrictions-set.
Resolution
There are two types of restrictions that could be causing issues here. Device platform restrictions (covered in this post) or device limit restrictions (covered in Dave's post from last year).
As mentioned in the first bullet point in this Microsoft article, when AVD enrols a session host in Intune, it will always use the default policy within the device platform restrictions (Intune > Devices > Enrollment > Device platform restrictions):
"Enrollment restrictions are applied to users. For enrollment scenarios that aren't user-driven, such as Windows Autopilot self-deploying mode and Autopilot for pre-provisioned deployment, bulk enrollment (WCD), Azure Virtual desktop, or userless Apple Automated device enrollment (ADE without user device affinity), Intune enforces the default policy."
If we have a look at the default restriction named 'All Users' (this can be slightly misleading as the policy is actually assigned to all devices and not all users), we'll see that by default, everything is allowed:
For AVD to enrol session hosts in Intune, the 'Windows (MDM) Platform' setting must be allowed (the personally owned can be blocked with no issue). Once this change has been made, the error will disappear and everything will work, however, this leaves a bit of a security hole in that any users can enrol any corporate devices. The workaround to that is that have multiple restrictions and order them correctly.
Here is an example scenario:
You need to allow AVD to enrol session hosts in Intune, you don't want standard users to be able to enrol anything, but you do want IT staff to be able to enrol.
- The first step to resolve the above would be to create a security group for the IT staff that are allowed to enrol devices.
- Back to the enrolment restrictions (Intune > Devices > Enrollment > Device platform restrictions).
- Create a new restriction.
- Give it a name (I used 'All Staff' to differentiate from the default policy, but use whatever makes sense) and under the 'Platform settings' tab, swap 'MDM' to 'Block'.
- Under 'Assignments', assign 'All users'.
- Create another new restriction.
- Repeat the process above, but give it a relevant name, set whatever platform settings you want your IT team to have (do you want them to be able to enrol personally owned devices?) and assign it to the group we created in step 1.
- In the priority, drag the IT restriction to priority 1.
Comments (1 comment)