MEMCM - Migration from On Premise to Intune - Part 3 - Migration of Software

In this next part we will investigate on how we will go about the planning of the migration of the whole Software Library estate into Intune.

There are many categories within the Software Library which have different variants on how we will go about the migration and also equivalent options.

Not every single object within your Software Library could be applicable to migrate into Intune so therefore we need to outline what can be migrated, and relevant alternatives which provide the same service to standard for your managed endpoints.

Just to analyze once again we have various types of objects such as

• Applications
• Packages
• Task Sequences
• Drivers
• Script Packages
• Configuration Baselines

In the very first part of the series we did cover a good amount of information so we will do a slight recap but this time we will cover more basis on how the application migration planning will go.

If we look at the basis on how we would migrate our on-premise estate to Intune in most cases our application estate would consist of various file type categories with the main ones being;

• .MSI
• .MSIX
• .Appx

Application Categories
So firstly we need to establish the different kinds of applications which we can actually migrate. So to summarize here are the different ones;

• Line of Business Applications - This category is for the main file extensions above being .msi, .msix, .appx. These are very straight forward imports very similar to what you would see when importing applications with the same file extensions in SCCM.
• Windows App (Win32) - This category is for the script based packages which utilize a .exe or other script files which will act as your main installation command. And very similar to the on-premise SCCM you will need to configure the detection methods which will check if the application already exists on your endpoint and also to detect a successful installation. These applications however are not something you can just import into your Intune portal as they need to be firstly converted into a .intunewin file extension. One of the best tools you can use for this can be found here
  

For those for are managing mobile devices within your on-premise SCCM such as;

• Android (.appk applications)
• iPhone/iPad (.ipa applications)
• Mac OSX Devices (.intunemac applications)

A lot of areas to cover in this particular section which will be able to replicate a similar process to how your on-premise Task Sequences would work when transitioning into Intune.

So Windows AutoPilot is really the method of building machines and as well as enrolling of new devices, but what we will do is have a side by side analysis on what you would typically see in a standard task sequence and output an equivalent where your entire process in Intune will be able to replicate the entire process of your task sequence to maintain the same standard of service which you were providing before.

Of course we will take the actual building of the OS and machine itself out of the equation but look more into the process of the post OS tasks which we can make Intune responsible for to complete the build. And of course where you may have other Post OS install steps which are more customized this guide may have pointed out areas in which you can use these, and perhaps even further extended into different Intune policies which will be discussed in another part.

Task Sequence Task/Group: Join Domain
On-Premise Solution: So within SCCM a domain join step would be included by default to specify the domain and OU which the machine will be placed into. More advanced techniques involve using Task Sequence variables in the pre-build section of your Task Sequence which would be able to detect the type of machine and going by certain criteria would determine how the machine would join the domain and where it would be placed.
Intune Solution #1: Domain Join Profile - Just before I put the obvious option of an AutoPilot profile thought I would pick on this one for a moment. The domain join profile will do quite a similar step to the on-premise one however here you can define a prefix for your machines in this profile by default as well as configure the domain it will join and OU it will be placed in. Where SCCM would use a collection to deploy its task sequence Intune would use an Azure AD group to be assigned to this profile.
Intune Solution #2: AutoPilot Deployment Profile - Of course we can't forget this one. We might find this will probably be the answer to all of them as the Deployment Profile will handle the configuration of everything, but have to take into account other components such as the Enrollment Profile Page which would essentially be a close replication of what you would see on a Task Sequence splash screen during WinPE phase. The reason for putting this option second is because in reality your machine will join the Azure AD Domain by default, but if wanting to add an additional layer of where you want them to be placed a Domain Join Profile is what you will require. You can however use the Deployment Profile settings to apply a device template which will allow you to construct the naming convention for new devices once they go through the enrollment process.

Task Sequence Task/Group: Install ConfigMgr Client
On-Premise Solution: So within SCCM this step would be to install the Configuration Manager Client and also the Software Centre, which is what would be used to be able to be able to receive deployments & policies from your management server.
Intune Solution #1: Company Portal Deployment- Within your Modern Workplace Management you wouldn't be using a client as such, however you may want to use the Company Portal application which is the equivalent to how Software Centre works. Now it's not absolutely necessary as you can still get deployments from Intune without it as well as a web-based version of your Company Portal. But in a more user-friendly perspective and as well as bridging the gap from an on-premise solution to Intune this maybe best. There are further bits to this as you would ideally need to obtain this from the Windows Store for Business to grab the correct license which will sync into your Intune.
Intune Solution #2: AutoPilot Deployment Profile - Used in conjunction with the solution above we can point the Company Portal deployment to the Azure AD Group which contains all of the AutoPilot based devices or devices in general. In a case of a Task Sequence scenario, the Auto Pilot would install this application during your enrollment setup.

Task Sequence Task/Group: Install Applications/Install Packages
On-Premise Solution: So within SCCM the step to Install Applications would comprise of a list of applications which would have to be enabled to be eligible to be installed in Task Sequences first and then added into the step. You can also use Task Sequence or Collection based variables to determines lists too. Install Packages quite similar where you select the package then the corresponding program.
Intune Solution #1: Application Deployment - In this case as we covered earlier deploying applications already groups SCCM Application & SCCM Package based applications into one group. So essentially we can import those into Intune (with converting script based to .intunewin of course) and deploy them to Azure AD Groups.
Intune Solution #2: AutoPilot Deployment Profile - In conjunction with AutoPilot we can deploy those same applications to the Azure AD Group which AutoPilot devices are part of so they are a prerequisite before auto enrollment has been completed.

Task Sequence Task/Group: Install Software Updates
On-Premise Solution: So within SCCM the Install Software Updates step really just initiates a sync between the built machine and your SUP (Software Update Point) to obtain the latest updates applicable to the machine.
Intune Solution #1: Windows 10 Update Rings - In Intune we can create Update Rings where we can customise the type of updates that will come through as well as there deferral periods and the type of update channels it will use. These profiles can be deployed to an Azure AD Group
Intune Solution #2: AutoPilot Deployment Profile -In conjunction with AutoPilot we can deploy those same update rings to the Azure AD Group which AutoPilot devices are part of so they are a prerequisite before auto enrollment has been completed.

Task Sequence Task/Group: Bitlocker Encryption (Optional)
On-Premise Solution: So within SCCM you will have a group with a couple of steps to prepare Bitlocker via its TPM module and then proceed with the Bitlocker encryption and where to play its recovery key.
Intune Solution #1: Disk Encryption Profile - In Intune in the EndPoint Security Window we can create a Disk Encryption policy for Windows 10 utilising Bitlocker where we can configure the settings and to which drive the encryption will be applicable to whether it be to the System Drive or other drives. The policy can be deployed to an Azure AD Group.
Intune Solution #2: AutoPilot Deployment Profile -In conjunction with AutoPilot we can deploy those same policies to the Azure AD Group which AutoPilot devices are part of so they are a prerequisite before auto enrollment has been completed.

And as for other Post OS install bits (where enrolment completes) any policies which you will configure in Intune maybe applicable to your machine also. For SCCM you would have your default client policies amongst other custom based policies which Intune can also do which may also answer for other bits in your specific Task Sequences depending on the kind of setup you have.

Where your drivers are concerned for your hardware, they follow a similar pattern to where the AutoPilot is concerned where the responsibility is down to the OS build provided to your hardware provider for when it comes to building the machines.

Having said that there are other ways in which some drivers can be migrated or at least an alternative in which it can transition into your Modern Workplace Management.

Windows 10 Update Rings
Windows 10 Update Rings have the ability to include Windows based drivers which would be applicable to your hardware vendor which will allow your endpoint to utilize the best and latest drivers available to be applicable with your current Windows 10 version.

Depending on the level of drivers which are covered by your initial OS build before AutoPilot comes into play, the windows updates will really either maintain or update the current drivers that you have. Below is a screenshot showing where the settings is located.

Application Based Driver Deployment
If there are more specialized types of drivers which you want to include in addition to your initial build, another way for this to work is to perhaps build a Windows App (Win32) based application which would be part of a script based installation which can be applied specific to your Azure AD groups which can have rules to only include a specific vendor.

For example if we take a Lenovo laptop (oddly enough typing this on one :) ) you have applications such as the Lenovo System Update utility. We can have this where the application can be installed on only Lenovo laptops which can obtain the latest drivers. In some cases alot of customers have a package in their on-premise SCCM which may already contain a tool such as this specific to their hardware vendors and they can in turn be migrated into Intune.

Script Based Deployment
Not exactly as described above though we are talking about a script based application. In this case I'm speaking of a method in which you can run a PowerShell Script package which can perhaps trigger an action on a tool which may already be installed on your laptop such as a Lenovo System Update utility, similar to how a scheduled task would work.
This would be great within a proactive remediation script task which we will cover more in the next section.

Configuration Baselines and its child items of Configuration Items cannot exactly be directly imported into Intune, but they can indeed be replicated into Proactive Remediation Scripts.

In SCCM you would have configuration items into a configuration baseline, however in this case the proactive remediation script is just one object which does make it easier to manage the objects going forward.

Below is a screenshot of the settings of a remediation script to outline the similarities of a configuration item within SCCM.

PowerShell Script packages also have the same caveat. But easily can be replicated as long as you export the powershell script used in your on--premise SCCM packages and then upload these into an Intune PowerShell script.

See below the configuration of a PowerShell Script which obtains a list of Windows 10 updates.

The next part we will go deeper into the configuration of the Software Update migration where we will analyze how to bring over your update policies and automatic deployment rule configurations.