Moving from MDT/WDS to Autopilot – Real-World Lessons, Wins & Gotchas
Hi all, We’ve been moving away from an ageing WDS + MDT setup and over to Windows Autopilot, and I thought I’d share a few key lessons and experiences from the journey. In case anyone else is working through the same transition (...or about to). Why the change? MDT was becoming unreliable, drivers/apps would randomly fail to install, WDS is on the way out, and we needed a more remote-friendly approach. We also wanted to simplify things for our small IT team and shift from Hybrid Azure AD Join to Azure AD Join only. We’re doing this as a phased rollout. I harvested existing device hashes using a script from a central server, and manually added machines that weren’t online at the time (most of which were just unused spares, we haven't introduced new hardware yet). If you want a copy of this auto-harvest, please see my next post, this script is useful as it'll just go off and import the hardware hashes into Intune, and can run against multiple computers at a time. (I will add the link to the post once made). Some of the biggest hurdles: • 0x80070002 / 0x80070643 errors (typically due to incomplete registration or app deployment failures) • Enrollment Status Page (ESP) hangs due to app targeting issues (user vs device) and BitLocker config conflicts • Wi-Fi setup with RADIUS (NPS) was complex, Enterprise Certificates and we're still using internal AD for authentication, so user accounts exist there and sync over to Azure. • Legacy GPOs had to be rebuilt manually in Intune, lots of trial and error • Some software (like SolidWorks) wouldn’t install silently via Intune, so I used NinjaOne to handle these, along with remediation scripts in Intune where needed We also moved from WSUS to Windows Autopatch, which improved update reliability and even helped with driver delivery via Windows Update. What’s gone well: Device provisioning is more consistent, updates are more reliable, build time per machine has dropped, and remote users get systems faster. It’s also reduced our reliance on legacy infrastructure. What I’m still working on: Tightening up compliance and reporting, improving detection/remediation coverage, figuring out new errors that may occur, and automating as much manual processes as possible. Ask me anything or share your own experience! I’m happy to help anyone dealing with similar issues or just curious about the move. Feel free to reply here or message me. Always happy to trade lessons learned, especially if you’re in the middle of an Autopilot project yourself. Cheers, Timothy Jeens
Radius certificate question
I have set-up a NPS Radius server. I want to manually do an export of a certificate, and import it on a private laptop of an employee to get rid of the warning of an untrusted connection. This is what I have done: - On another server than my DC I installed AD CA, and gave it the name for example “Test CA” - Made a copy of the RAS and IAS server template and name it 'Radius template' - Then I published the template with ‘certificate template to isue’ - On my domain controller where NPS is installed, I see that in the ‘trusted root certification authorities’ the certificate “Test CA” is present. - Still on my DC, in the ‘personal certificate folder’ I created a new certificate based on the template (Radius template) and I see the a certificate on my DC with the name ‘dcname.domain.be’. This is issued by ‘Test CA’ and has server authentication and client authentication. - On my NPS server, in ‘network policies’ I changed the PEAP authentication method to use the created certificate (dcname.domain.be). - I exported the Root certificate “Test CA” and imported that on another, non-domain joined laptop (in the ‘trusted root certification authorities’ folder). If I try to connect to the WiFi netwerk, I still get a warning that the connection is not trusted. On my smartphone the same problem. If I ignore the warning, everything works. I know you can have a public CA certificate, but my local domain is .local. First I want to solve the above.