Intune Windows 10 app install behaviour and the Enrollment Status Page

So this is a fairly short post but I thought I would share an interesting scenario I encountered when working with enrolling AAD joined Windows 10 devices into Intune. These devices;

1. Were Autopilot provisioned 
2. Had 2 win32 apps deployed (Azure Information Protection Client and Office 365)
3. Had 1 store app deployed (Company Portal)
4. Had 1 line of business app deployed which included the installation of the Configuration Manager client. This would hence be bringing the device into a Co-managed state.

Initially I wanted access to the device blocked until the AIP client, Office 365 and the Company Portal was installed so I configured a custom Enrollment Status Page (ESP);

I logged into the M365 Device Management Portal and navigated to Device Enrollment > Windows Enrollment > Enrollment Status Page

Created the ESP, ensuring the Block device use until these required apps are installed if they are assigned to the user/device option was selected and I specified all apps other than the LOB application, with the intention of this app installing last

I ended up getting intermittent failures with this configuration so I attempted by including only the LOB app as a blocking app, still the same intermittant results.

Now this was my misunderstanding, but even if you select specific apps to be blocking apps within the ESP, if there are other required app deployments it doesnt necessarily mean that the apps specified within the ESP will be installed first. So in my scenario, sometimes one of the apps was failing to install and others, two were failing.

I havent looked into the logs for this but I belive it was due to the LOB app being installed at some point before any of the blocking apps had been installed. My LOB app was enabling the device for Co-management and in my scenario the client apps workload was only enabled for "Pilot Intune". I even attempted for testing purposes to query individual devices based on thier hostname in order to be included into the device collection scoped for the pilot co-management workloads as soon as the device appeared within the Configuration Manager console using the following query;

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.Name = "Hostname"

But ultimately the default Co-management workload values are set first and taking into consideration policy refresh there was still enough delay to cause a problem for app install.

So ultimately at this moment in time there is no way to control the install order of required app deployments. In order to get around the issue in my scenario I simply deployed all apps within the device context and the LOB app within the user context, meaning it will always install last. I also set the LOB app as a blocking app meaning that by the time the user is able to log on to the system, the installation is completed and the LOB app is a considerable way through its process and the Configuration Manager client is installed.

Providing you are only using Win32 apps you could also consider creating app dependencies as another way of controlling app install order, however you would need to ensure you are provisioning Windows 10 1903 devices in order to be able to tracks these apps within the ESP. 

As we always say, every day is a learning day and if anyone has any comments or suggestions then please feel free to drop a comment within this post.

Thanks for reading!