SCCM Application migration with better content handling

Microsoft provides an Export-CMApplication PowerShell commandlet as a way to export an SCCM Application and then a matching Import-CMApplication commandlet to import it again. These commandlets have one big limitation (in my opinion): The way content is handled: your content folder structure is completely lost and each imported Application’s content location is left pointing to a cryptic GUID path:

The content location of the imported application is cryptic

This creates a maintenance nightmare for ongoing administration:

• It is more difficult to read GUIDs than vendor/application names, version numbers, etc
• Trying to navigate Application content is a manual, slow, painful process
• There is no logical structure to the content folder anymore. Every organisation I have worked in has some sort of structure when storing their application source files. Eg: \Vendor\Application Name\Version. There are numerous benefits for keeping a structure like this rather than a flat one with just GUIDs.

An alternative

I have written 2 PowerShell scripts which better handle the Application content during migration in addition to a few other features:

• The content location path of the imported Application is controllable and therefore has structure & is more human readable
• By forcing imported Application content into a specific structure, any structure issues/differences from the source are resolved/fixed.
• Distribution of imported content to a Distribution Point Group (optional)
• The Application can be renamed as part of the import process
• Being PowerShell scripts, they can easily be extended to do additional work (in other versions of these scripts I have the script create Collections and Deploy the imported Applications).

These scripts are available at GitHub: https://github.com/auash/SCCMApplicationMigration

An example

Exporting

The source Application that we want to migrate:

The Application is 7-Zip, it has one Deployment Type, and currently has a poorly structured content location

The CSV used by the script which contains the Application(s) to work on:

The configuration defines:

• The name of the Application in our source SCCM (“7-Zip (original)”)
• The name we want the Application to have in our destination SCCM (“7-Zip (imported)”) ie: a rename will occur
• The 3x ‘Folder’ columns define the destination content folder structure. So in this example the content will be placed in a structure like: “<root folder provided>\Igor Pavlov\7-Zip\21.07\”

The configuration of my Export script has my source SCCM Site details added:

The log file after running the Export-SCCMApplications.ps1 script:

By default, the script exports the Application metadata and content to 2 folders in the same location where the script is located:

Exported metadata file inside the ‘AppInfo’ folder

Exported content inside the ‘Content’ folder.

As each Deployment Type on an Application can have its own content location specified, a folder is created for each Deployment Type. In the above screenshot the Deployment Type name was “MSI Install” and so a folder was created with that same name. The content for each Deployment Type is then copied to the matching folder.

Importing

After performing the export you need to make the ‘AppInfo’, ‘Content’ and script files available to the system where you will be running the import. You could achieve this by making the folder available as a share, or, move the folder to a different location. Regardless of the method used to move the content, once moved you must create a share which exposes the ‘AppInfo’ and ‘Content’ folders via a UNC path. This is because the built-in SCCM import functionality requires these items to be provided via a UNC path.

The configuration of my Import script:

Note :

• $RootAppContentDestinationPath is where the imported Application content will be copied to.
• I have specified a Distribution Point Group name of “All DPs”. This is a DP Group that already exists in the destination SCCM Site.
• $RootAppInfoSourcePath and $RootAppContentSourcePath have UNC paths to the exported Application information from earlier. These must be UNC paths.
• I have modified the $ApplicationFolderInSCCM variable. I have specified a subfolder under the root ‘Application’ location (this folder already exists).

The log file after running the Import-SCCMApplications.ps1 script:

The result

Content is now structured:

The imported Application was renamed and its location in the SCCM Console:

Content is distributed to the DP Group that was specified: