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 JeensMoving from MDT/WDS to Autopilot part 2
Hi everyone Following up on my previous post about moving from MDT/WDS to Windows Autopilot, I wanted to share some of the more detailed parts of the deployment and config that might help others working through similar issues. Wi-Fi (RADIUS + NPS + Azure AD Join): This was hands-down one of the trickiest bits. We use a local RADIUS server (Windows NPS) with certificates for EAP authentication, and users authenticate using local AD credentials, despite Autopilot devices being Azure AD joined. I had to build a custom Wi-Fi configuration profile in Intune that handled certificate trust, proper targeting, and worked with our existing NPS policies. If anyone needs help with this scenario, I’m happy to share more details. I’ll be posting the full configuration soon. BitLocker Conflicts: BitLocker generally worked but only after cleaning up overlapping configurations. Intune allows BitLocker settings to be applied via multiple paths (Device Configuration, Endpoint Security, Encryption, even legacy GPOs via ADMX). I found they MUST be aligned across all sources — otherwise, ESP fails or encryption doesn’t trigger. My fix: consolidate BitLocker settings under Endpoint Security and Windows Configurations and ensure nothing else contradicts them, they give different options hence the need for the two. App Deployment + Detection Scripts: Some software just doesn’t play nice with Intune alone. We had issues with SolidWorks and other legacy tools. For these, I used NinjaOne to run custom silent installers and Intune detection scripts to track success and reapply if needed. For complex installs, I had to fall back on Proactive Remediation scripts to detect and fix problems. Compliance Baselines & Settings: We're gradually shifting to Intune-based compliance. I ported over our core GPO baselines and rebuilt them using Configuration Profiles, Settings Catalog, and Security Baselines. Compliance policies then reference these, so non-conformant machines are flagged. Still evolving this as we onboard more devices. Licensing Requirements: For anyone wondering, some of these capabilities require specific licensing. We're running "Microsoft 365 E3" + "Enterprise Mobility + Security E3", which gives us access to: Proactive Remediations Intune-based compliance management Scripted deployments and reporting Note, only 1 user in the tenant needs these two licences to enable the features. Summary This move to Autopilot wasn’t just a deployment change, it pushed us to rethink how we handle security, authentication, app installs, and policy enforcement. There’s still more to do, but we’ve built a solid foundation that’s scalable and more resilient than our old MDT-based approach. If you’re dealing with similar challenges or stuck on something like Wi-Fi, BitLocker or app installs, feel free to reach out. I’ve probably hit the same wall and am happy to compare notes or share scripts/settings if it helps. Cheers, Timothy JeensMicrosoft Patching is not working until User logon to the newly imaged device
Hi All, I have a customer that they have two separate SCCM and WSUS environments in the same domain and they use SCCM for OS imaging and WSUS for patch updates. The problem is end user hast to logon to the device after imaging the OS using SCCM to kick start the patching process from WSUS. My client's understanding is that it should work without user logon to the device since GPO targeted to all authenticated users. Please also note that the computer objects and other settings are working without any issues. I would appreciate if anyone come across such a behavior and there is any workaround that we can do kick start the patching regardless of user login or is this behavior by design? Thanks, DilanMDT 8456 Now Available
We are pleased to announce that the Microsoft Deployment Toolkit (MDT), version 8456, is now available on https://aka.ms/mdtdownload and replaces MDT version 8450. This update introduces support for Windows 10 version 1809 and Windows Server 2019 as well as the latest version of Windows Assessment and Deployment Kit (ADK).
