This small blog will be about some misunderstandings about Proactive Remediations and Autopilot.
1. Introduction
Some time ago, I wrote a blog about how faulty PowerShell scripts could ruin or delay your Autopilot deployment.
Autopilot & Pre-Provisioning’s Infinite Play…uh…Waiting list – Call4Cloud
In this blog above, I showed you how a PowerShell script could delay your Autopilot enrollment by 30 minutes. The PowerShell timeout causes those 30 minutes
But what about Intune Proactive remediations? Proactive remediations are just some PowerShell Scripts that are scheduled to run on your device, right? Are those also executed during Autopilot? Some of you say yes, and some of you say no…
So let’s find out!
2. The Basics
Microsoft tells us that the client policy retrieval occurs after a restart of the device or the Intune Management Extension. Guess what gets installed during Autopilot: the IME.
But still, I couldn’t explain why some of you aren’t noticing the execution of Proactive remediations during Autopilot. I decided to look at what happens when you enroll your device with Autopilot and have assigned some proactive remediations to your devices.
As shown above, I made sure I added Proactive remediation to enable Bitlocker on all devices
To make sure I could spot the proactive remediation 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 (Proactive remediations) will kick in
3. The Details
Now that we have proof that Proactive Remediations will be executed during the Device phase when enrolling your device with Windows Autopilot, 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.
It will get one script that needs to be executed in return. This Health Script 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 ProActive remediations during Autopilot.
A good ESP is a Short ESP
It’s always good practice to make sure only the really really really core apps…. not selecting all apps or selecting 100 apps as required apps!
4. Tracked
I guess it’s pretty safe to say there is a good chance the proactive 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
}
}