There are still quite some companies that have to migrate their SCCM 2007 environment to Configuration Manager 2012 R2, even though it is 2015 now. One of the important things during a migration are migration of the software packages. The thing with the inbuilt migration tool is that packages will be migrated to … packages. Not what I would want, because I would like to use applications or better said, the application model. In the trainings that I give I always say that you should use the application model and move away from the legacy packages (unless really not possible). In a migration scenario where you use the inbuilt tool, you first have to migrate your packages to packages in CM 2012 R2 and then convert the packages to applications with a conversion plug-in. Both steps might require extra actions depending on the situation before migration can start.

The idea to write this blog came when a colleague of mine called me for some advise, or better said some discussion on what to do best in regard to a migration from SCCM 2007 to CM 2012 R2. My colleague wanted to start using the application model, but did not like to first migrate and then convert packages. The first thing that came into my mind was to use Powershell and create applications. Exploring the options of Powershell and Configuration Manager during a project some time ago made me very enthusiastic and inspired to do more with Powershell. So my advise was: what if you skip migration the ConfigMgr way and use Powershell?

First of all migrations are perfect for cleaning up your environment, get rid of stuff you do not use anymore and maybe rethink your setup, naming convention etcetera. The negative side of migration tools are that people tend to take the easy road and do a 1 on 1 migration keeping al the unnecessary content. My advise is to take a step back and look at your environment and analyze where changes can or should be made. Look at the way you want to deploy applications (machine or user) and look at the source location. Make a list of applications that need to be migrated, who the owner is and who will test the application. My experience in projects are that applications are a lot of the times the reason that projects are not ready in time, so tip of the day…. start with applications asap!!

Ok, to get back to Powershell…. you do not have to make all kind of scripts to create applications, you can also use separate command lines if you want. There are different types of applications, to not make this blog to long I will look at the following type

  • App-V.

How can you create an application with PowerShell?

PWS_ApplicarionCreating an application with PowerShell consists of 2 steps:

With New-CMApplication cmdlet

With Add-CMDeploymenttype cmdlet

You can click the links to see which parameters you can use with the 2 commands.

I am not going to publish scripts here, there are enough sources available on the internet with examples to help you with that. Instead of a script you can execute command lines and to create more then 1 application you can use a CSV file as input for your PowerShell commands. So the first thing you have to do is make a file with all the variables needed for the command you have to execute. To keep it simple we start PowerShell either from the ConfigMgr console or you can start it from the server. The difference is that if you start PowerShell from the console the ConfigurationManager module will be loaded and otherwise you have to load it yourself. I personally like to use the PowerShell ISE (Interactive Script Editor). I use the following code to load the ConfigMgr module and connect to the PowerShell drive:

$ConfigModulePath = Join-Path $(Split-Path $env:SMS_ADMIN_UI_PATH) ConfigurationManager.psd1

Import-Module $ConfigModulePath

$SMSDRV = Get-PSDrive -PSProvider CMSite

cd $($SMSDRV):”

Next I want to create an application by using the New-CMApplication cmdlet. I am not gonna add extra’s to the application, I will just give it a name:

New-CMApplication -Name TestApp1

This will create an application on which we can build further. Now we can create the deployment types that we need for the different deployments. We will create an AppV deployment type by using the cmdlet Add-CMDeploymenttype

This cmdlet has a lot of parameters (see the link above) that can be used if you need. For an AppV you can use the following command line:

Add-CMDeploymentType -AppV5xInstaller -ApplicationName “TestApp1” -AutoIdentifyFromInstallationFile “\\…TestApp1.appv” -ForceForUnknownPublisher $True

And there we have created an application with a Appv deployment type. The only thing left to do is to put the commands together and add the parameters as variables so you can import a CSV file (think Import-CSV cmdlet) where all the variables are stored in. This part I leave up to you to discover….and have some fun. Once you got this worked out, you can distribute the content and create the deployments in a similar way as well as the collections to deploy to.

As you can see creating applications with PowerShell is not that difficult and once you have a CSV file with the variables you can create many applications in one go. As already stated above there are many source available on the internet that you can investigate and learn from. Most work will be creating the CSV file. In my opinion it is easy to use this method to migrate packages to applications and skip the Migration tool in Configuration Manager. Actually PowerShell can help you in many ways and make you job easier. You probably need to do some testing, let me rephrase this… you have to test and please do not test in your production environment, but use your test environment!

Feel free to give comments or if you disagree let me know what you think, in the mean time enjoy exploring.