Moving your package source after migration

UPDATE: I’ve posted my Package and Application scripts (https://blogs.technet.com/b/configmgrdogs/archive/2013/05/09/package-amp-application-source-modification-scripts.aspx)

If you haven’t checked out the Package Conversion Manager for ConfigMgr 2012 RTM/SP1 yet, you’re missing out.

https://www.microsoft.com/en-au/download/details.aspx?id=34605

The PCM is provided by Microsoft to help you convert those migrated ConfigMgr 2007 Packages, into the newer (and better) ConfigMgr 2012 App Model Applications.

While PCM is really cool, this article is not going to show you how to use it, because frankly, it’s way too easy to use!

One of the limitations of PCM, is while it’ll do a great job converting your Packages to Apps, it does not do anything with your package/application source. This can be a major problem if your migrated package source was hosted locally on your old ConfigMgr 2007 server. Of course you should all be using UNC paths for your source, however even if you’re doing the right thing, if you want to decommission the old 2007 server, somehow you’ll need to move that package source.

I’m here to help!

Let’s use our favourite test application – Adobe Reader – and we’ll quickly convert the package, and then move the package source to the new ConfigMgr server.

In my demo, I’m using two package source shares to imitate a common environment

\\SP1RTM\OldSource$ This would be our old 2007 package source share

\\SP1RTM\Source$ This will be our new 2012 package source share

I’ve converted my old package to a shiny new 2012 Application

And if we open the single Deployment Type, we’ll see that the source is still on the old package source share

Now, this will actually work quite nicely. Having an external package source is not only supported, but recommended in larger environments. BUT, in small to medium environments you’ll want to decommission the old 2007 to save on licensing and management.

In 2007 there was two supported ways to move this package source. You either raised a Microsoft PSS case and they supplied you with a VB Script, or you manually went through each package source and changed the share path.

In 2012 SP1, we now have Powershell to do the work!

We’ve now got a myriad of Powershell cmdlets available for ConfigMgr 2012 SP1. (NOTE: Powershell support was added at SP1 so none of the following is applicable to RTM)

Anoop C Nair has a great write up of all the cmdlets available

https://gallery.technet.microsoft.com/CM-2012-SP1-List-of-Cmdlets-a7bce79d

First, we need to import the ConfigMgr Powershell Module (NOTE: the module will only run in the x86 Powershell console)

Import-Module 'C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\bin\ConfigurationManager.psd1'

Next, connect to the Central/Primary site where you’ll be targeting your commands

 Set-Location PRI:

Now that we’re connected, we can take a look at that Adobe Reader Deployment Type (DT)

Get-CMDeploymentType –ApplicationName “Adobe Reader” – DeploymentTypeName “Install Reader”

Whoa, lots of info! But the relevant part for this tutorial is the <Location></Location> tags

Luckily, we don’t have to modify the SDMPackageXML because the product group have given us a cmdlet to modify it without touching it directly.

Set-CMDeploymentType –ApplicationName “Adobe Reader –DeploymentTypeName “Install Reader” –MsiOrScriptInstaller –ContentLocation “\\SP1RTM\Source$\Applications\Adobe Reader”

If we now open up the DT, we can see the source location has changed to our new share.

Voila! With Powershell integration, doing these manual admin tasks is a whole lot easier, especially if you start using programming logic and piping information from one cmdlet to another.

In my next post, I’ll be posting a script to move *every* package source of applications that you’ve migrated.

Matt Shadbolt