Moving to a fully managed Intune/Autopilot/AzureAD setup is not an overnight task, it needs careful planning and migration, no-one is expecting you to wipe every device and instantly move to Autopilot, that simply isn’t realistic for larger organisations.
That’s not to say give up now and don’t bother, especially with Windows 10 EOL looming, now is the time to start looking at migrating both OS and management type.
This post will look at the higher level considerations when planning your move, if you want step-by-step instructions for configuring a new tenant, I have a book in-progress which will cover this, plus the PowerShell and Graph commands behind it, watch this space!
So, where do we start?
Audit what you have
Before any sort of migration, you need to know what you are dealing with. Whilst you could theoretically lift and shift your group policies, wrap your applications and sync your users and groups, that won’t help you in the long run.
Use this opportunity to review your group policies and see what is still relevant today, do you really need to be blocking MSN messenger from starting up, or filter on devices running Windows XP and 7? Document what you have an what you actually need moving forward.
The same thing for your applications, see which are actually still being used, which were even applications to begin with (we’ve all pushed out registry keys via an app as a quick fix), which now have a cloud-based offering. Do you really need 3 different web browsers and PDF software? Use this as an excuse to rationalise, the less apps you have, the less you have to update, support and worry about when a zero-day comes along.
For those applications remaining, consider how you are going to manage and deploy them, for the standard free applications, would a third party be an option, what about winget? Are any suitable candidates for re-packaging into MSIX?
How is your on-prem AD structured and could it be improved? You can use this as a way to implement proper role-based personas and deploy config policies and applications accordingly.
Consider your Android/iOS devices as well, are they corporate managed or is it a free-for-all? How would you like it to look? If your main apps are cross-platform, use your personas to deploy apps across all devices to give a more seamless experience.
Don’t forget to involve your security team in these decisions as well.
Plan your baselines
Now you know what you want your Intune environment to look like, you need to start planning your policies. I always recommend starting with the security policies and building from there. These are your building blocks in any environment and should apply across the estate. You want your devices to be secure straight from the initial provisioning (I’m deliberately avoiding using the word “build” here).
Consider your on-prem policies you reviewed earlier, what did you have at the high level around encryption, firewall, protection. If you are starting out, the built-in baselines will help, but have a look at the other options available within the Endpoint Security blade as these are more feature rich and may serve you better.
Make use of the baseline recommendations from the likes of CIS and NCSC, you don’t have to follow them to the letter, but they may flag some things you had not previously considered.
Once you have your security policies in place and assigned, you can…
Add your policies
Look at your GPO audit earlier, remove anything configured in a baseline and start configuring what’s left. Where possible use Settings Catalog for a better overall experience.
You can technically import your current GPOs directly into Intune, but it is best to use this as an excuse to clean things up so I would never recommend a straight lift and shift (it’s like moving your servers as they are into Azure, technically possible and ticks the boxes, but not a great idea)
Consider your personas here and assign accordingly, just watch for conflicts.
Don’t be tempted to throw everything into one massive policy, it will be cumbersome, more difficult to manage and troubleshoot and the lack of granularity will make things difficult when you need to make exceptions for particular users (I’m looking at you IT staff and C-Levels)
Consider your exclusions carefully, whilst you can duplicate a policy, do you really want multiple policies with one changed setting and 50 others the same? It’s better to remove that single setting and move it into a new policy.
Make sure your policy names and descriptions are properly done, “Test policy” is not a good idea.
Also consider how you are going to test new and updated policies in the future, consider a ringed approach as you would for Windows updates so you can thoroughly test before deploying to production. Better still, have a dev tenant to be extra careful. You can always copy your policies between them
Windows Updates
You will (hopefully) have been using an on-prem solution for Windows Updates, whether that is SCCM, WSUS or something else.
After creating your new update rings in Intune (or ideally, use Autopatch), make sure you remove any policies or configurations on-prem which are configuring your Windows updates to let Intune take over this workload for you. Any on-prem settings will override whatever updates are being configured in Intune.
When configuring your update ring members, make sure you look at the bigger picture, you don’t want to risk losing an entire department due to a faulty update so whilst adding your entire IT team into a preview ring may sound sensible, things will not go well when you lose IT for hours whilst you resolve the issue (which is now even harder because you have no IT machines!). Make sure you look at hardware types, key business applications and departments. Ideally in your second ring you want to capture as much variety as possible so you can be happy there won’t be any nasty surprises when your broad ring deploys to everyone else.
Files and Shares
This is the modern world, your users will be able to provision devices from anywhere in the world, do you really want them to need a VPN to access their files? Not to mention drive mapping isn’t quite as native as it was with on-prem AD.
For your user data, migrate them to OneDrive, you can still manage things, but save yourself disk space on the servers, don’t worry about offline files breaking (we all know they will) and point-in time restores can be user-initiated. Not to mention the auto-save functionality!
Don’t think this means you don’t need to backup centrally though, consider a third party backup option.
For your central file shares, look at SharePoint or even linking through to Microsoft Teams depending on your org structure. You can push out SharePoint libraries to display within Windows Explorer so the users won’t need to use the web interface.
If you are licensed for Intune, chances are you are licensed for both OneDrive and SharePoint so why not use it? No-one really enjoys managing file servers anyway!
Printers
Just take a hammer to them Office Space style.
If you must have them, look at Universal Print from Microsoft or one of the follow-me options from someone like Papercut. After Print Nightmare, deploying printers is not quite as easy as it should be so you’re looking at either application, or PowerShell scripts to deploy non-Microsoft options.
Deploy Your Apps
After reviewing and rationalising your applications, package (as Win32 or MSIX) them up (test them thoroughly) and deploy them. Don’t forget the uninstall commands and uninstall groups, you never know when you might need to rapidly remove applications from machines.
Now Azure AD supports nested groups, I prefer to create groups for each application (install and uninstall) and then nest inside them as it makes the estate easier to understand and manage.
Avoid MSI Line of Business apps at all costs, the time spent wrapping into a Win32 will be less than you’ll spend troubleshooting the things.
For your Office apps, packaging the Office Deployment kit as a Win32 application often behaves better than using the built-in policy option, especially during Autopilot.
Test
Build a machine using Autopilot and hybrid-join an on-prem machine. VMs will work ok, but testing on a physical machine is always helpful to watch for any driver or BIOS issues. Windows 365 is also an option here for additional testing if neither a physical or VM are available.
After building, check your policies have applied without errors, check for conflicts and test your applications for both install and uninstall. The last thing you want is an urgent app uninstall to fail because you didn’t test it. For your installations, make use of the Available assignment option, it’s quicker than waiting for a required install.
When you have finished testing, test again and then ask someone else to test. This is a considerable change and not to be rushed into (if you are in a rush, call in an expert, they will have seen it all before)
Document
You are probably the only person who understands the environment right now, give it 6 months and you will probably have forgotten some of it too. Document everything, if you have had to drop in a PowerShell script as a bodge, document it, in a few months it may be native to Intune and you can transfer it over. This tool will get you started.
Make sure you keep the documentation updated and also your environment updated, Intune is constantly evolving and your policies should evolve with it.
Please store them somewhere useful as well, your personal My Documents is not the correct location.
Back it up
Intune does not have any native backup functionality, if you break a policy, delete a policy, you have to dig through the audit logs to see what changed and then manually restore them. Ideally you should backup before making any changes, then again afterwards, think of it like a snapshot before making a change on a server. You can use this tool or my free backup website, or if you would rather self-host, buy a copy
Start Migration – the only case for Hybrid
You will hear a lot of hate for Hybrid Azure AD Joined Machines (and rightly so), but this is when using combined with Autopilot, which is mostly unecessary with Windows Hello for Business and Cloud Trust SSO.
For net-new devices, or device rebuilds, move them to Autopilot with Azure AD Joined devices.
However, nobody is expecting you to rebuild every single device overnight. You can hybrid join your existing devices and use Intune for applications, policies etc. Move them into an OU without any policies attached and all of your machines will be managed by the same MDM platform.
As your devices are replaced or fail, use that excuse to rebuild them into the fully modern world
Hopefully this has been useful to guide you along the way
