In this blog, I’ll walk you through some powerful troubleshooting techniques to help you tackle issues during Windows Autopilot Device Preparation (AP-DPP), whether it’s application installation failures or other bumps along the way.
Introduction
With the introduction of Windows Autopilot Device Preparation (AP-DPP), troubleshooting enrollment issues has become more critical, especially when problems like application installation failures arise. So, how do we determine what caused these issues?
When Autopilot Device Preparation encounters a problem, you might see a message on the device saying that device setup couldn’t be completed and that you need to contact your organization’s support. But wait, you’re the support person, right?
In Autopilot v1, we could easily use the enrollment status tracking CSP to pinpoint which apps failed to install. However, with Windows Autopilot Device Preparation, this process has changed. The familiar enrollment status page we used in Autopilot v1 is no longer in play. Instead, the bootstrapper and Intune Management Extension (IME) now manage the entire provisioning flow.
So, how can we troubleshoot application installation failures with Windows Autopilot Device Preparation? Let’s walk through some basic troubleshooting steps you can take to identify the root cause.
Autopilot Device Enrollment Monitor
Microsoft gave us a lovely new Autopilot Device Enrollment monitor, which we could use to determine the deployment status. When you click on it, it provides an overview of the Autopilot deployment with additional details.
By clicking on the report, you’ll see additional details, including the status of apps and scripts marked as ‘required’ in the Autopilot Device Preparation profile. But what if we ended up with something weird? What if the deployment looked successful, but somehow, there were no Apps listed in the report?
Do we wait a few minutes (which is the ideal approach), dive into dissecting the entire enrollment process, or start by checking the Known Issues?
AP-DPP Known Issues
Before diving into new event logs, it’s always a good idea to check for known issues with AP-DPP. For instance, the App Control for Business Managed Installer might be the culprit behind your problem. I’ve written about this before, showing how I discovered the managed installer was responsible for the broken application reporting. It’s worth taking a look at that blog for context.
Looks like Microsoft figured out the same thing. They’ve documented it here: Known issue: Windows Autopilot device preparation with Win32 apps and managed installer policy | Microsoft Community Hub.
In addition, the local administrator setting in Entra might also be disrupting the Autopilot Device Preparation enrollment. In both cases, we ended up with a successful deployment, even though some required apps failed to install.
If your issue isn’t listed in the Known Issues, it’s time to roll up our sleeves and get to the heart of what went wrong with those app installations. The next step? Are we going to use the get-windowsautopilotdiagnostics tool?
Autopilot Diagnostics Tool
Let me be blunt: NO, the Get-WindowsAutopilotDiagnostics.ps1 tool isn’t useful when we need to troubleshoot AP-DPP enrollment failures. It’s designed for the original Autopilot (APv1) and doesn’t work for Autopilot Device Preparation (APv2)
Instead, head over to the device itself. Once you’re logged in, it’s all about diving into the event logs. The good news is, with Autopilot Device Preparation, we’ve got some fresh, shiny logs at our disposal. Ready to take a look?
Troubleshooting AP-DPP Bootstrapper Event Log and TSM Registry Key
When your users experience strange errors during Autopilot Device Preparation, troubleshooting can feel like a game of detective work (when not using the new Autopilot Monitor). Fortunately, several powerful methods are at your disposal to help you track down what’s going wrong. Beyond the Bootstrapper event log and AutopilotSettings TSM registry key, don’t forget to check the DevicePreparation initialprovider registry key, an essential part of the troubleshooting puzzle. Let’s start with the Bootstrapper event log first!
1. Bootstrapper Event Log: Real-Time Updates
The Bootstrapper event log is your go-to source for real-time information during the Autopilot Device Preparation process. As the BootstrapperAgent orchestrates the provisioning flow, it logs detailed steps, progress, and errors.
These logs are generated through the Intune Management Extension Bootstrapper Agent etw provider
This agent captures key milestones such as:
- The start and completion of provisioning tasks
- Progress updates for various preparation steps
- Errors or issues encountered during the provisioning flow
The real magic of this BootStrapper log? It gives you real-time insight into the entire provisioning process. Fun fact: this very bootstrapper log helped me uncover a bug in Autopilot Device Preparation that’s now a known issue.
Autopilot Device Preparation | Entra Local Administrator Bug
👉 Check it out here
However, there is one caveat: the Bootstrapper event log currently doesn’t log application installation progress in full detail,
so it might not be the go-to resource for troubleshooting app installation failures. Still, it’s invaluable for tracking the overall process.
2. DevicePreparation Registry Key: Workload Progress
Let’s check the registry in addition to the Bootstrapper event logs. Specifically, we need to examine the AutopilotSettingsDevicePreparation registry key.
As you can see above, the DevicePreparation registry key might reveal that the DevicePrepPage (DPP) agent provisioning failed. But, as always, it only gives you part of the story. Cracking the case of a broken Autopilot DPP enrollment is all about piecing together the clues!
3. Using the TSM Registry Key for Troubleshooting
But if you unfold the DevicePreparation key, you will notice that there is a AutopilotSettings TSM registry key inside of it.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\AutopilotSettings\TSM
Remember those clues we’re piecing together? This registry key is another goldmine for unraveling the AP-DPP mysteries. It stores information about the device preparation steps handled by the BootstrapperAgent. Each value here represents a specific step in the provisioning process and gives you insights like:
- StateType: The current state of the device preparation (e.g., “Initializing,” “Provisioning”).
- ProcessName: The process being executed at that moment.
- StateName: The step or status name, like “App Installation” or “Device Enrollment.”
- EventMessage: Messages or events tied to the current preparation step.
We can also spot the collection of this telemetry information in the Bootstrapper Agent DLL
When you combine this telemetry with the Bootstrapper event logs, you get a comprehensive view of what’s happening—and what might be going wrong. It’s all about connecting the dots!
4. Initialprovisioning Registry Key
If you’re unsure which phase the Autopilot Device Preparation enrollment is in or if the Intune Management Extension (IME) seems to be doing something else while claiming to install required apps or scripts, the ProvisioningInitialprovisioning registry key can clarify the situation.
The Initialprovisoning registry key holds the current workload progress in JSON format. When the device is enrolled, this workload information is sent to the device, updating the registry key as provisioning moves forward. By examining this key, you can verify the provisioning progress of the Autopilot Device Preparation steps, and it helps confirm which phase the process is in (OrchestrationContext and Previous Progress).
An important field to focus on is the PreviousProgress batch. When opening this key we will notice that the previous workload phase before the error ocrured was the Win32apps provisioning phase.
This insight can help pinpoint if the issue lies with app installations or another phase in the process.
5. Connecting the Dots: Combining Logs and Registry Keys
By combining the Bootstrapper event logs, AutopilotSettings TSM registry key, and DevicePreparation InitialProvisioning registry key, you get a clearer and more complete picture of the Autopilot Device Preparation process
- The Bootstrapper event log gives you real-time insights into the overall progress and any errors that occur during provisioning.
- The AutopilotSettings TSM registry key provides a step-by-step snapshot of the device preparation state, allowing you to track progress and identify potential issues.
- The DevicePreparationInitialProvisioning registry key gives you detailed information about the current workload and provisioning phase (in my case the Win32apps provisioning phase).
When combined, these resources help you quickly pinpoint the issue and track the progress of the Autopilot Device Preparation process more effectively.
6. Pro Tip: Manually Activating the Bootstrapper Event Log
One useful tip: the Bootstrapper event log is automatically enabled when the Intune Management Extension (IME) is installed, but you can also manually activate the Bootstrapper event log provider before the IME is installed. By registering the log provider with wevtutil, you can start collecting logs even before the IME gets involved, which could give you early insights into what’s going wrong.
While the Bootstrapper event logs and AutopilotSettings TSM registry keys provide useful insights into the overall Autopilot Device Preparation process, they don’t always give us the fine-grained details needed to pinpoint issues with app installations. If the Autopilot Device Enrollment Monitor or Bootstrapper logs don’t provide enough clarity, it’s time to dive into more detailed troubleshooting. This is where the IME logs come in handy. Let’s explore how to use CMTrace and the IME logs to troubleshoot app installation failures more precisely.
IME Event Log Troubleshooting
If you’ve discovered that Autopilot is stuck on the Win32App provisioning workload (as indicated by the TSM or Provisioning logs), your issue is likely related to app installation failures. While the Autopilot Device Preparation logs and registry keys give you an excellent high-level overview of the provisioning process, they don’t specifically track the detailed progress or success of application installations. This is where the Intune Management Extension (IME) logs come in handy.
The IME logs will provide you with the detailed information you need to troubleshoot Win32 app installation issues and identify what went wrong during the provisioning process.
As shown above, even with all the new Windows Autopilot device Preparation event logs, the Intune Management Extension should tell us enough! When we zoom in, we will notice that the Reporting registry key holds all the information about whether the application itself is detected.
If the detection state is 2, the application is not detected. If the detection state is 1, the application is detected. Once you find the one with the wrong detection state, note the GUID, as this GUID is the APPID.
With this App ID, you know which application was not detected. If you don’t want to spend time in the Intune Management Event log, you can also copy and paste that ID after this URL to find out which app it was
https://intune.microsoft.com/#view/Microsoft_Intune_Apps/SettingsMenu/~/0/appId
But maybe it’s easier to open the ProvisioningProgress registry key just above the reporting one, as that registry key also holds the WorkloadID (appid) and the Friendlyname, which could make more sense.
CMTrace and the IME Log: Uncovering Installation Failures
While the Autopilot Device Preparation logs and IME registry keys offer valuable insights, you can take it a step further by using the CMTrace tool to dive deeper into the Intune Management Extension (IME) logs.
CMTrace, originally developed by Microsoft as part of the Configuration Manager toolkit, is a powerful log viewer that makes analyzing IME logs much easier. It highlights errors and warnings, helping you quickly pinpoint issues like application installation failures or failed detections. For instance, in earlier troubleshooting efforts, CMTrace helped us identify the ManagedInstallerStatus as the root cause.
However, here’s the catch: Microsoft no longer provides a direct download link for CMTrace. If you don’t already have it, you’ll need to extract it from a Configuration Manager installation or obtain it through alternative methods. Despite this, it remains an invaluable tool for effectively troubleshooting IME logs.
Spotting Application Installation Failures
The IME logs (Appworkload) provide detailed information about each step in the Autopilot Device Preparation process, including application installation. Using CMTrace, you can quickly find any application installation failures by filtering for errors or issues related to app installation.
The logs will often point to specific application detection failures or issues with the application WorkloadID, which corresponds to the AppID.
The power of CMTrace lies in its ability to highlight errors, show you the sequence of actions, and even offer useful context for identifying the exact cause of installation failures.
Patch My PC’s IME Deep Dive Webinar
If you’re unsure how to approach the application troubleshooting process or want to gain more in-depth knowledge of the IME log, you’re in luck. Patch My PC has already conducted an excellent IME Deep-Dive Webinar, which goes into detail on how to troubleshoot application installation failures using the IME logs.
Even though the IME Deep Dive Webinar is focused on troubleshooting IME-specific issues, the knowledge gained can be directly applied to troubleshooting Autopilot Device Preparation (AP-DPP) issues as well. If an application fails to install during Autopilot, using CMTrace and analyzing the IME logs will help you pinpoint exactly where things went wrong, whether it’s a detection issue, a missing dependency, or a conflict during the provisioning process.
Conclusion:
When Autopilot encounters issues during the Device Preparation process, the first step is to check the Autopilot Monitor. The monitor provides a quick overview of the deployment status, helping you identify any workloads that might be causing delays or failures. However, it doesn’t always give you all the details you need to troubleshoot complex issues.
That’s where the Bootstrapper event log and Provisioning registry keys come into play. These tools offer deeper insights into the current state of the Autopilot Device Preparation process, helping you pinpoint exactly where things are getting stuck.
Once you’ve identified the failing workload—whether it’s app provisioning or another step—you can take things further by analyzing the IME logs. These logs provide the granular details needed to troubleshoot specific issues. If the Autopilot Monitor is lacking critical information (or if you’d rather not wait for updates), diving into the logs is your next logical step.
With tools like CMTrace, you can quickly uncover the root cause of the problem, whether it’s a detection issue, a missing dependency, or another configuration conflict.
By combining the insights from the TSM registry keys, Bootstrapper logs, and IME logs, you’ll have a comprehensive view of the process, making it easier to resolve issues and get your Autopilot enrollment back on track.