This blog takes a closer look at if—and how Remediations (former name ProActive Remediations) are executed during the Enrollment Status Page (ESP), while a device is being enrolled with Windows Autopilot
1. Introduction
A while back, I showed how a single PowerShell script could delay your Windows Autopilot deployment by 30 minutes. That blog stirred up another question: what about Remediations? Some say they run during Autopilot (Me).

Others say they don’t. Time to find out who’s right. Remediations are just some PowerShell Scripts that are scheduled to run on your device, right?

During enrollment, the Platform Scripts (PowerShell) are executed during the device setup and are executed before the Win32Apps will be installed. Because of this, the Enrollment Status Page will be stuck on identifying apps until the PowerShell scripts are executed. If you interested in how that happens read this blog: Enrollment Status Page Hangs | Stuck on Identifying Apps | ESP.
Let’s dive into basics of client policy retrieval a bit before diving in
2. Client Policy Retrieval
Microsoft tells us that the client policy retrieval occurs after a restart of the device or the Intune Management Extension. Guess what gets installed when the device is getting enrolled with Intune: the IME.

But still, I couldn’t explain why some of you aren’t noticing the execution of Remediations during Autopilot. I decided to look at what happens when you enroll your device and have assigned them to your devices.

As shown above, I made sure I added the scripts to enable Bitlocker on all devices and configured it to run hourly
Please Note: If you set it to daily, the remediations would NOT run during Autopilot

To make sure I could spot the Remediations in action I added an additional app that prompts the user from the system context for some questions

While gazing at that screen I opened an explorer window and opened the Intune Management and Agentexecutor logs. As shown below. When your device is enrolling with Autopilot, the Health Scripts (Remediations) will kick in


3. Remediations Executed with 5-minute Delay
Now that we have proof that Remediations will be executed during the Device phase when your device is getting enrolled, let’s look at the details to see if we can find out why some of you aren’t spotting them during Autopilot.
Before looking at the details in the IME log, I first needed to find myself the proper Script id

With this ID I could search through the IME and executor log to find some more details. I reenrolled the device and started the Autopilot enrollment again. At the same moment the Device ESP started (09:44), I also opened a PowerShell session to be sure I knew the time it started.

As shown above, the AgentExecutor.log file changed at 9:50. When opening the IME log, we will notice that the IME will start requesting the health scripts. (remediations)

It will get one script that needs to be executed in return. The Remediations will be scheduled. To do so, it starts calculating the earliest time it needs to be executed. In this process, it first needs to fetch the time (Get_UtcNow)

With the current time fetched, it could compare the current time and the time the job needs to be scheduled

The Job will be queued and scheduled. When looking at the scheduled UTC time, we will notice that exactly 5 minutes after the Device ESP phase started, the “Job” will be run

5 Minutes! That could be the perfect reason why some of you aren’t noticing the execution of the Remediations during Autopilot. Some of them nearly had any Win32App configured in the ESP… with it, the remediations didn’t have the change to even be executed during Windows Autopilot.
4. Tracked
I guess it’s pretty safe to say there is a good chance the Remediations will be executed during your Autopilot enrollment, but just like with PowerShell scripts, we need to beware that they aren’t tracked during the Enrollment Status Page Device Setup Phase.

So, there is also a good change that when you configure some massive Proactive Remediations, they will not reach the finish line as “they” are not tracked! Maybe you could ask yourself why they aren’t tracked. I guess MN and I share the same opinion.

and….I guess if the ESP could tell you exactly what is happening in detail, I would be out of a job.
Conclusion
Proactive Remediations will be executed during Autopilot but with a 5-minute delay. If you like to have as few apps as possible in your ESP blocking apps, there is a chance they aren’t executed.

Great article! I always warn– be careful what is put into the proactive remediation scripts… don’t launch anything that might directly conflict with your app installs. For example, I have a script that detects the presence of Dell Optimizer and if present, it uninstalls it. However, that was running during OOBE when other installs were happening, and it caused a big issue (obviously).
I determined an excellent way to prevent this during OOBE, however… configure the detect script to detect WWAHost.exe running and immediately halt the script as successful so that the remediation script wouldn’t run:
try {
$OOBE = (Get-Process -Name WWAHost -ErrorAction SilentlyContinue)
If ($OOBE) {
Write-Host “Cannot run while OOBE is running.”
#Exit Successful in order to prevent Remediation now.
Stop-Transcript
exit 0
}
$Dell = (Test-Path -Path “C:\Program Files\Dell\DellOptimizer\DellOptimizer.exe”)
If (!$Dell) {
Write-Host “Dell Optimizer is not installed.”
Stop-Transcript
exit 0
}
Else {
Write-Host “Dell Optimizer is installed. Perform Remediation.”
Stop-Transcript
exit 1
}
}