In this blog, I will show you how a specific Microsoft Intune policy could mess up your cloud-based Autopilot Device Preparation Application reporting even while the Autopilot Device Preparation enrollment seems successful.
1. Introduction
Before exploring the new Autopilot Device Preparation profile, let’s briefly return to the “old” Autopilot and the corresponding Enrollment Status Page.
Configuring the blocking apps in the Enrollment Status Page (ESP) Settings would require the device to install those apps for a successful Autopilot Enrollment.
This works pretty well in regular Autopilot, especially with the best-effort option that was added, but how does it work with the new Windows Autopilot device Preparation?
With Windows Autopilot Device Preparation, we also have the same option to define the applications that need to be installed during the Autopilot Device Preparation Enrollment.
With Autopilot Device Preparation, we could add a maximum of 10 apps to the profile. When those apps are configured as required and assigned to the same just-in-time device group we configured in the profile, we should be good to go, right? I thought so, too!
I wiped my virtual machine and restarted the enrollment. After going through the whole flow, the device completed the Autopilot Device Preparation required setup.
Still all good, right? Well, I guess not. Let me tell you why!
2. Autopilot Device Preparation Monitor
After the Windows Autopilot Device Preparation enrollment required setup finished successfully, I started checking out the installation status in the corresponding Autopilot device Preparation monitor in Intune.
Monitoring the deployment status helps troubleshoot a possible enrollment failure and can quickly tell whether the end user had a seamless user experience.
I noticed that it mentioned that the deployment status was a success! Again, nothing to worry about, right?
So, I clicked on the device enrollment report, and this is what it showed me.
All the required apps defined in the policy are now showing as not installed. Okay, that’s definitely weird, as I was expecting this reporting to be near real-time and really accurate.
Luckily, I also have access to other tenants, who showed me an accurate status in near real-time. That’s odd. What is happening in my tenant? After waiting a minute or two, the non-installed status switched to the in progress status?
That is even more weird. So, I opened the device and clicked on the managed apps.
I hoped this managed apps overview would give me a good application installation status.
Again… it mentioned that it was waiting for the install status. So what happened?
3. What Happened
My first idea was a stupid idea because I started looking at the Microsoft enrollment status tracking CSP and the corresponding registry to find out what was happening.
If you look at the screenshot above, it’s evident that Autopilot Device Preparation is no longer using enrollment status tracking CSP.
Since the enrollment status tracking was not showing me anything, I needed to open the Cmtrace tool and the Intune Management Extension log. After scrolling through the whole Win32app installation process (which seems to be all okay) in the IME log, I started noticing something.
After loading the app results and giving me some lovely red errors, it started the content info request. In that request, it also mentioned the managedinstallerstatus to be 2
Now, I was starting to question myself. I believe this Managed Installer Status should be 1 if we weren’t using the managed installer. Before doing anything else, I needed to know for sure. I opened the Intune Management Extension Win32applugin.dll and opened the contentmanagerv2
Within a few seconds of walking through the code, it showed me what I was looking for! It showed me the ManagedInstallerStatus with a value of 2 and the fact that: the managed installer opt-in is enabled, but the policy has not been set
With that managedinstallerstatus set to 2 and the managed installer opt-in enabled, it’s evident that somehow the managed installer is enabled in my tenant?
4. The Managed Installer
When I noticed the opt-in for the managed installer, I remembered that some time ago, after reading the Patch My PC blog about WDAC, I wanted to test WDAC again, and now with the managed installer from Intune.
Windows Defender Application Control/ App Control for Business is a crucial component in mobile device management (MDM) and plays a significant role in protecting organizational data.
If you haven’t read that blog about WDAC, please do, as it will give you some good insights into configuring WDAC.
https://patchmypc.com/wdac-intune
I opened the endpoint security blade in Intune and the App Control for Business tab.
Oh… well, as shown above, that makes a lot of sense; the managed installer was still enabled. This got me curious, and after spending some time on the Win32AppPlugin code, it was obvious that the app report process also checks if the managed installer feature is enabled.
This could explain why my application reporting was broken in the Windows Autopilot Device Preparation Deployment Application Monitor. To be sure. I disabled the managed installer, aka I Opted out. (Opt-in is disabled)
After waiting for a few minutes, I reenrolled my device. This time, the reporting was very fast and accurate!
We can conclude that if you have the managed installer enabled in Intune, the Autopilot Device Preparation Application reports will malfunction. The funny thing is that the required setup will also finish successfully, even when the required apps fail to be detected/installed.
This is pretty weird if you asked me. If you want to hear and read more about how you could troubleshoot app installation failure during the Autopilot Device Preparation deployment, keep an eye out for some future blogs!
5. Microsoft’s Fix
At least after first spotting the error, much work is done to fix the reporting in the back end. Even when the required app fails to install, and the Autopilot device Preparation enrollment thinks it is successful, the Device deployment details will now mention the failed application instead of showing in progress, which is a good improvement!
The fix ensures that new devices are accurately reported and administrators can view the deployment status data in real-time.
So that’s something, at least. Luckily, Microsoft added this to the known issues list once Autopilot device Preparation went GA
Conclusion
for everyone experiencing weird application reporting issues during Windows Autopilot Device Preparation, please ensure you don’t have the managed installer turned on (Managed Installer Opt-In). If the managed installer is enabled, the application report data will not be accurate, and your device will finish the required setup successfully even with application failure!