Part 1 - Planning of the Migration Process Mapping
Introduction
The process of migrating over from an on-premise SCCM infrastructure to Intune for Modern Workplace Management can be quite a huge task depending on your current SCCM infrastructure and also specific roles in which it plays.
In one of our previous article series we covered the transition of having a Co-Management environment in which you can experience the best of both worlds with having policies configured between both SCCM and Intune and having the ability to change the affinity between both environments from whether being shared 50/50 or controlled completely by one or the other.
We find that Co-Management or other hybrid type solutions are indeed a great way to have the best of both worlds but it can also be one of those options in which organizations are apprehensive to move over completely to Intune and this can be for various types of reasons which prevent them from making this decision.
This article series we will cover everything you will need to take into consideration from the planning and all the way to the actual migration of your current setup.
This first part shall discuss various categories to consider when planning on how you will migrate into Intune but more on the perspective of the objects and the roles your on-premise environment plays.
This series does take into account that you do indeed hold the appropriate licensing to manage your Intune with an E5 license assigned to your Intune Administrator account with both Intune Admin & Global Admin privileges.
More licensing information can be found here
Migration of Devices
This is perhaps the biggest deal breaker in a sense when it comes to making the decision of actually moving over into Intune.
Not necessarily thinking of the devices being synced into Azure AD or your AD being solely within Azure but more about the mixture of your endpoint estate in your on premise SCCM.
So Windows 10 are really the only endpoints in which you can manage, there are exceptions for some versions of Windows 8.1 (supported devices can be seen here
) so if your estate has a mixture of OSes from Windows 8.1 (hopefully not below!) then you may face an issue in which you would potentially consider a migration in which devices would be left out from Modern Workplace Management hence why many organisations would stick or investigate a Co-Management perspective where they can add their Windows 10 endpoints to a desired collection which would be shared between your on-premise environment and Intune.
Migration of Applications & Packages
This section perhaps one of the most important, well they all are very important but perhaps more on the bulk-ish side of the migration. So things we have to take into account would be the following questions;
- How many applications do we have
- How many packages do we have
- How many are using a .msi
- How many are using a .exe
- How many Windows 10 based apps do we hold (.appx)
So knowing how many applications and packages in total is one thing. The next part which can be somewhat challenging for administrative effort is where the file types come into play.
For example .MSI applications are easier to import into both Intune and SCCM due to the metadata which it holds which is able to complete the process a lot quicker, and these are seen in Intune as
Line of Business Applications.
Windows10 based applications which have the .appx file extension also carry the same less burden appeals like the ones above as these are seen as
Line of Business Applications.
Where Office applications are concerned these can be offloaded to where we can create Office 365 Applications on demand with configurations of any channel as well as the type of products we want to include (subject to licensing such as Visio and Project) which are categorised as
Microsoft 365 Apps for Windows 10.
But of course we have the packages within our on-premise SCCM which are considered legacy based, which was how SCCM 2007 used to handle all applications in this same format which now update has its caveats. So packages can commonly utilise script based installs as well as .exe file extensions and these would need to go into a process which they will have to be converted into the new file format called
.intunewin
and these are categorised as
Windows App (Win32) applications
.
Can be potentially the most time consuming section depending on the software library count which you have.
Migration of Collections
For our main source of grouping both devices and users we would perhaps want to either maintain our current tree structure of collections or may even want to improve them.
Within your Azure AD or Intune Administration console you are able to create groups which can be either user or device based and also explicit members (Direct Membership for On-Prem) can be assigned or dynamic based rules (Query Membership for On-Prem) which we would be able to create a criteria for which devices can be added into the group.
Collections are also our logical group objects within our on-premise SCCM environment for deployments of applications, programs, software updates, Task Sequences etc.. so we want to ensure that we are able to migrate a healthy managed collection structure that already exists or even take the opportunity to improve this.
Migration of Client Policies
Alongside the default client policy in which in most real-case scenarios we ensure its priority is the lowest, we also may have a lot of custom client policies with many settings which can apply again to the desired collections that are also based on another filtering criteria.
Here we want to ensure that our custom policies will be indeed brought over but we must take into consideration that a lot of settings which are specified in these policies may not be fully covered in just one profile within Intune as there are various other profiles it can be split into such as;
- Compliance Policies
- Configuration Policies
- Conditional Access Policies (some small elements)
There are also migration processes for your GPOs (Group Policy Objects) which we will cover further in another part of this series.
Migration of Baselines & Scripts
This section will be quite interesting with how we would perhaps looking into the migrations of these.
There are various areas in which configuration baselines can be split across to formulate and keep the same structure to provide what is needed here. So within the Intune environment we have the PowerShell Scripts
which we can use for our script packages which can be deployed to your Windows 10 endpoints where needed.
The more interesting one would be the configuration baselines, which though partly can be done within the PowerShell Scripts section, but they may also be more fitting within the Endpoint Analytics
features of Intune in which we can not only consolidate them into proactive remediation packages
and have a breakdown of how many would be remediated and failed, but then there is also the functionality of where we can create baselines to represent the progress of them which in fact provides a small functionality of historical data to compare both with, as opposed to perhaps a Data Warehouse role which would have to be installed on your on-premise SCCM environment.
Migration of Task Sequences
A form of very interesting creativity here in how we would go about the process of migrating the Task Sequences into Intune.
So a Task Sequence being a sequence of various of actions of course installing the operating system as well as being followed by various settings, Pre OS conditions, Post OS conditions and of course software. Now of course Intune doesn't utilise Task Sequences as such, but this perhaps where Windows AutoPilot
would come into play.
Whilst the OS would be installed either by your specific vendor of choice, third party or even done internally, what we can do is control all of the settings, configurations and software deployments. There are various areas in which this would split up such as;
- Autopilot Deployment Profiles
- Enrollment Pages
- Apps
- Conditional Access Profiles
- Compliance Profiles
- Windows Update Rings
There is a great amount here in which we can provide a consolidation for your task sequences to ensure a smooth transition.
Migration of Antimalware Policies
Similar to client policies above we now take into consideration of the Antimalware configuration in which your devices are most likely managed by Windows Defender from your on-premise SCCM.
Custom Antimalware policies as well as further configurations for firewalls, device security (Bitlocker) and more can be migrated smoothly into the Intune environment with very similar categories as well as utilising Defender ATP.
Migration of Software Update Management
This process is perhaps a lot more simplified when it comes to the migration as we wouldn't need to migrate the physical updates, but more around the ADR (Automatic Deployment Rules) we can bring over if they are available within your environment.
Software updates are now handled by rings respectively for normal Windows Updates and also for feature based updates when wanting to upgrade the build versions of your Windows 10 endpoints.
Migration of Reporting
Various reports are available by default in both environments (Intune & SCCM) so it will really be a case of which reporting information is vital to you. Besides the default reporting and charts we have within our Dashboard, we also have the ability pull out further information by using the Intune Data Warehouse source in which we can create a dashboard either through Power BI or SSRS using its OData feed.
There are a lot of box standard reports used within SCCM and don't think many organisations have used all of them, where in this case it leaves the option available for those who may want to pick and choose which information they do want to see which can be shared by some of the default Intune reports and the data source of the Data Warehouse.
Next Part
The next parts of these series we will explore each of these sections in a more finer technical and design detail on how we would make the migration process smooth from your on-premise environment to Modern Workplace Management.
