As an Intune Administrator and someone who has deployed Intune, you can imagine the trials one undergoes as part of that process. However, there’s one issue that has really knee capped a core function of Microsoft Intune called Fresh Start. Fresh Start is intended to allow you to reset a device to the baseline image for the system, with the option of retaining or removing user files. However, in my experience, we’re finding a huge issue that appears to have two sides to it.

So What’s Going On?

So, the first side of the issue comes down to how Microsoft processes a Fresh Start request. When the request is sent to the system, it receives a confirmation from the system, and then it unenrolls the device from Intune. This is where the problem can start. If let’s say there is something wrong with the OS image, the fresh start will fail. This will then kick the user back to the login screen, where they can login, but now effectively, you can’t manage or have insight into the system.

To make matters worse, if you attempt to re-enroll the device into Intune, it reports that it is “already connected to another organization” and will not allow you to do so. This leads me to believe that there is a defect in the process wherein it either does not evaluate the image’s health before proceeding, confirm that it can successfully begin, or have a rollback function to reconnect it to Intune in the event of failure. This is of course, a worse case scenario. Despite the verbose details to Microsoft Support, they seem uninterested in escalating the matter to the Engineering group.

The second side of this issue appears to result from OEM builds. These builds often contain custom modifications or settings dictated by the manufacturer, which can create a poor experience for the users and for Microsoft Intune in general. I often found that when I used an OEM build, the profiles I built for the systems often failed because of conflicts with OEM software installed. Even when attempting to rebuild the OS from the recovery console, you’d quickly find that the Windows recovery console wouldn’t work properly or even be able to detect properly in some cases.

The replication of the OEM build defect was random, wherein out of 40 systems, around 30% of them had some kind of image defect which imacted the ability of the Fresh Start function, and out of those, about half of them were unable to properly recover via the Windows recovery console with cloud download selected. This OEM build issue did not affect Microsoft-built devices, but did affect our Dell-built devices.

Obviously, a 40% potential rate of losing device control is disastrous from a security and compliance control standpoint. Further, the bloatware from OEMs that often contain outdated drivers that are have little security vetting is concerning for anyone attempting to build a secure baseline. So, in the interest of a clean baseline image, and to avoid our other concerns, we did a clean install using the Windows 10 Media Creation Tool. When we attempted to fresh start systems that were installed with a clean image, they had no issue. When they self-enrolled through AutoPilot and applied their policies, they had no issues, across the board.

So, lesson learned. If Microsoft support changes their tune and begins to seek a resolution to the Fresh Start issue, I’ll write an update accordingly. Until then, save yourself the headache, and do clean image installs before enrolling devices.