Last Updated on March 1, 2023 by rudyooms
This small blog will be about some misunderstandings about Proactive Remediations and Autopilot. I Will divide this blog into multiple parts
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. Those 30 minutes are caused by the PowerShell timeout
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 is telling us the fact that the client policy retrieval occurs after a restart of the device or the Intune Management Extension. Guess what get’s 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 take a 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 we have some proof that Proactive Remediations will be executed during the Device phase when enrolling your device with Autopilot, let’s look at the details to find out if we could 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 know 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 1 script in return that needs to be executed. 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 will be 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 that the proactive remediations will be executed during your Autopilot enrollment but just like with PowerShell scripts we need to beware of the fact that they aren’t tracked during the Enrollment Status Page Device Setup Phase
So there is also a good change, that when you configured some massive proactive remediations, they will not reach the finish line as “they” are not tracked!
Maybe you could ask yourself, why aren’t they tracked? I guess MN and me share the same opinion…
and….I guess if the ESP could tell you exactly what is happening in detail, I will be out of a job
Conclusion
Proactive remediations will be executed during Autopilot but with a delay of 5 minutes. If you like to have as less as possible apps 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
}
}