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 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.
Azure VPN Gateway and MFA Timeout Issue for Point to Site Connections
Hi, I'm having trouble getting MFA working with an Azure P2S IKEv2 VPN using RADIUS auth. It seems that the auth response timeout on the gateway is set so low (looks like 5 sec) that I don't have enough time to authenticate using MFA. I've verified this both with DUO Auth and Azure MFA; both have the same result. I initiate the VPN connection, enter credentials, and before I can answer the phone call to verify MFA, another request is initiated and a second call comes through. If I successfully verify either or both calls, the connection fails. However, if I use a push notification to the cell phone for verification and I can verify in under 5 sec, the connection is completed. I've also pointed my Palo Alto VPN device (where I have a specified timeout of 60 sec) at my MFA server and was able to log in successfully to that VPN - this determines the issue is not with my MFA server setup. I've created a bug request with Microsoft on this as there doesn't seem to be a way to change the timeout. Has anyone else encountered this issue or found a workaround??MFA and Azure IKEv2 P2S VPN Failing - Timeout Issue?
Hi, I'm having trouble getting MFA working with an Azure P2S IKEv2 VPN using RADIUS auth. It seems that the auth response timeout on the gateway is set so low (looks like 5 sec) that I don't have enough time to authenticate using MFA. I've verified this both with DUO Auth and Azure MFA; both have the same result. I initiate the VPN connection, enter credentials, and before I can answer the phone call to verify MFA, another request is initiated and a second call comes through. If I successfully verify either or both calls, the connection fails. However, if I use a push notification to the cell phone for verification and I can verify in under 5 sec, the connection is completed. I've also pointed my Palo Alto VPN device (where I have a specified timeout of 60 sec) at my MFA server and was able to log in successfully to that VPN - this determines the issue is not with my MFA server setup. I've created a bug request with Microsoft on this as there doesn't seem to be a way to change the timeout. Has anyone else encountered this issue or found a workaround??