The deadline for moving to Windows 11 is rapidly approaching, and with the new hardware requirements, now’s the time to review how you manage your user devices and shift to the modern cloud-native approach. While this post concentrates on your Windows devices, Intune support for macOS has improved rapidly. With the uncertainty around Workspace One, why not save license costs and manage all from the same platform?
Now, let’s examine a migration plan for your Configuration Manager-managed environments. This isn’t an overnight task, but starting now should make it more manageable before the October 2025 deadline.
Co-Management
The first step is configuring co-management for your devices and hybrid joining them into Intune. This leaves the Configuration Manager client on the devices, and you keep all of the functionality of Configuration Manager but also enable cloud features and the ability to move workloads to Intune in a staged, controlled manner.
Fortunately, enabling co-management is a straightforward process and is well documented here: Tutorial: Enable co-management for existing Configuration Manager clients
If you have any policies configured within Intune, it’s best to check if anything is configured for “All Users” or “All Devices”, which could suddenly appear when the devices are enrolled.
Pay particular attention to Windows Hello for Business, as this can be configured both at a configuration policy level and at a tenant-wide setting within Devices—Windows—Enrollment. If you’ve configured it at the tenant level, when you enable co-management, your users will be prompted to set up a WHfB PIN when they log in.
Ideally, you’ll have an empty Intune tenant before this, but if this isn’t an option, look at the assignments of any existing policies. If they’re required across the estate, test on an Autopilot-built machine initially to ensure you don’t suddenly have numerous helpdesk calls the day you flip the switch.
Now you have your devices Co-Managed, you’ll notice you have this new panel available to you:
This shows everything that can be managed in both Configuration Manager and Intune and allows you to slowly transition to Intune management.
Pilot users
You now need to configure some pilot users for testing so you can throw the switches to Pilot Intune and let Intune manage these devices without impacting the wider estate.
It’s always best to start with throwaway machines as whilst they have significantly improved, some policy settings within Intune can still “tattoo” on devices. This is when a policy has two options: “Enabled” and “Not Configured”. If you enable a setting, it will write that setting to the device (usually in the form of a registry key). You then notice an issue with the setting, log in to Intune and set it to Not Configured. In some cases, all this does is “nothing”; it simply tells the device to ignore that setting, but of course, the setting is now stuck. Whilst you could go registry digging, it’s often quicker to give it a rebuild.
After ruling out any device-killing issues, you can expand your pilot group to include some more tech-savvy users who don’t mind the odd glitch along the way. Please don’t simply deploy to your entire IT department, though. If you break all of their machines, there won’t be anyone to fix it!
Update management
We can start with the one that causes the most headaches for administrators while also being the easiest to manage with Intune and Windows updates.
By switching to Intune for managed updates, you can say goodbye to that WSUS server, free up some precious disk space, and let the devices grab their updates directly from the internet. This is especially useful in today’s hybrid working world.
If you’re licensed with Microsoft Enterprise licensing (M365 E3, M365 E5 and others), I’m not getting into licensing, so you can find the latest supported here: More about licenses. This takes the work away from you entirely and puts it into the hands of Microsoft. There are so many advantages to using Autopatch, but it really should be a no-brainer in your environment. Imagine the telemetry data Microsoft receives from devices worldwide every single day. They have so much data they can use to ensure the updates will cause the least trouble to your tenant.
You can find out more about Autopatch here: Windows Autopatch documentation.
If, however, you’re not licensed, all is not lost. You can still utilise Windows Update for Business, often referred to as WUfB (woof-b), for cloud management of your updates. Initially, you’ll need a small amount of administrative work to configure your update rings and drop users or devices into the appropriate update groups. You’ll no doubt have these in place already for your on-prem updates, so it’s more of an admin overhead than anything to really think about.
Once you have your updates configured, test with an Autopilot-only device just to be extra sure, and then switch over “Windows Update Policies” to Pilot Intune.
Policy management
The next step is to move your policies (and those PowerShell scripts, batch scripts, apps, and other bits you have in place to bodge settings) over to cloud management.
While Group Policy Analytics exists within Intune, where you could export, review, lift, and shift into Intune, you can use this as a chance to lose your technical debt.
When was the last time you reviewed your group policies and checked everything was still applicable? Did you remove that workaround you put in place for a particular issue right in the middle of Covid?
It’s a much better idea to build out from scratch, plan out what you actually need to manage and deploy accordingly.
Start with the security policies and deploy those in their respective areas within the security blade. This way, you can give security teams access to view items here without giving them the keys to the kingdom.
Personally, I prefer to avoid the built-in Windows Security baselines as I prefer to keep control over policies and settings, which is harder to do when someone else is updating them. You have to approve any changes there, but your policies are read-only until you do so, which leaves you a little stuck if you need to make a change but are not yet ready to upgrade.
When looking to assign policies, try to think of them as GPOs. If it’s something you would configure at the higher domain level (Antivirus, BitLocker, Firewall, etc.), consider assigning those to devices, while anything a bit more “user”, like the Edge homepage, can be user-assigned.
Once you have your secure baseline in place, you can start layering on your more tenant-specific settings.
Of course, you could save yourself days of work and simply deploy a secure CIS/NCSC compliant baseline from DeployIntune. This will deploy a full tenant config in less than 20 minutes. You can use this as an Intune landing zone to layer your custom policies.
It’s worth noting that Intune doesn’t yet have an alternative to Group Policy Preferences so you’ll need to think creatively for drives and printers (covered later).
As with updates, initially test everything on a cloud device, then shift to your pilot user group.
Application management
The one we all dread, applications. You need to find all of the applications in your estate, package them up into Intunewin (win32) format and upload them to Intune.
For some, this is pretty straightforward; for others, with hard-coded batch files, network paths, etc., it’s a more complicated process. Remember that applications in Intune run in the System context, so they have no access to on-prem file shares (if they do, fix your security).
As with everything else, modernise and keep your applications updated. Unless there’s a very good reason to do so, don’t package old versions of applications.
Whilst it may look appealing to drop your MSI files straight into Intune as Line of Business applications, this will cause you issues with Autopilot. MSI LoB simply call msiexec on the device, but the Intune Management Extension (IME) client, has no visibility of this. Therefore, it could also trigger an app install, which launches msiexec, and you get the always fun “another install in progress” message. Only this time, the message is in the System context, and no one can see it, so your app hangs waiting for input, everything else backs up behind it, your ESP times out, and everything fails.
When looking at your M365 Apps (or Office, as everyone calls it), the built-in GUI or even the XML is straightforward to use, but I have had better experience building it as a Win32 application using the Office Deployment Toolkit. This way, you can also use the additional features in a Win32 app, such as requirements scripts, dependencies, supersedence, etc.
Once you’re happy with your apps in Configuration Manager, you can use automated tools, such as this one from Algiz Technology, to quickly migrate them to Intune.
We automate and accelerate your migration from SCCM to Intune. The right apps, a secure tenant, always up to date.
For your off-the-shelf apps, also consider a package manager to handle updating them in the future. You can find my review of them here, and Algiz can help with purchasing and licensing them:
You can do initial testing of your apps pre-wrapping by using psexec to launch them on a sandbox in the system context. However, it’s still worth deploying to test users initially. To speed things up, deploy them as available and then self-service install (and uninstall) via Intune. Make sure to check that both Install and Uninstall work correctly. You never know when you’ll need to remove applications urgently, and that’s not the time to find out they don’t work properly!
That covers all the available workloads, which should all be in Pilot Intune and in thorough testing by now. Once you’re happy that they’re all working as expected, slide over to Intune and enjoy the benefits of cloud management.
To remove your machines from a co-managed state (if required), simply uninstall the Configuration Manager client from your devices.
As mentioned earlier, there are a few things to consider when moving to a full cloud-native Entra joined setup:
- Printers: Without GPP, there’s no native way to deploy your printers. Add in print nightmare, and things are even more exciting.
Ideally, use Universal Print from Microsoft, which includes free prints per month in your subscription or any offerings from your follow-me supplier.
If you have to deploy print-server printers, you can find scripts to get you started here, one to whitelist the server, the other to install printers. - File Shares: Again, in an ideal world, they’ll be OneDrive and SharePoint, but on-prem file servers still hang around. To access these, you’ll need to deploy Kerberos Cloud Trust (fortunately a straightforward process), and obviously, your users will need to be able to see the server, either on-prem, VPN or secure gateway from Microsoft.
You can find out how to deploy cloud trust here. - Wi-Fi: Authenticating to corporate Wi-Fi networks will need to be at the user level as the device object no longer exists on-prem. You’ll also need a way to deploy the certificates to your devices. The free method is to deploy SCEP and NDES, but it takes more to setup.
You could also look at SCEPMAN or Cloud PKI as alternatives.
Now that you have everything in place for a cloud-native setup, the only (supported) way to transition them is a device rebuild. So work this into your refresh cycle and keep it in mind when machines fail, and you’ll soon be running a cloud-managed EUC environment.
You might think that’s the end of it, but as with anything, it needs some TLC, policy monitoring, policy updates, etc. Also, what’s your plan if someone accidentally deletes key policies from your tenant? For this, you might want to consider a tenant management application such as EUCToolBox or, better still, a fully managed service from Algiz Technology!
