Monday 26 August 2019

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!

1 comment:

  1. Hi Leon - this is a really good blog and thank you for posting. Sometimes the best solutions are the simple solutions - get it to run in user context as you say and then the issue is controlled. I think another way of tackling this could be to put the sccm client into provisioning mode and then remove provisioning mode using a script to run as a user app - however I am not sure if there are any great benefits doing it that way . However if you are using SCCM 1902 client you can set a time out on provisioning mode - default is 48 hours and you can modify that.

    Recently I had to use provisioning mode in order to get an SCCM task sequence to run from Intune - I wanted to get the TS working to workaround the inability, as you point out, to have control over the order of app installation. My reason for using provisioning mode was a bit different. The device on which I run the TS is in a workgroup and does not have the sccm client installed. I could install packages using the run command line TS step, but to install packages using the install software step requires a working cm client to be installed on the device. So I did this and enabled software distribution using a wmi command but it still would not install any apps. So I read the article below and enabled provisioning mode and eureka - started working. I created a rough video and put it on youtube.

    Here is the the article about provisioning mode that gave me the solution to my problem, which I explain in the video

    https://docs.microsoft.com/en-us/sccm/osd/understand/provisioning-mode

    Here is my rather rough video which gives a bit of an idea on how it works.

    https://youtu.be/dSQraBKjIfM

    ReplyDelete