• Home
  • |
  • Blog
  • |
  • Introducing SCCM Package Conversion Manager

Introducing SCCM Package Conversion Manager

360training.com May 19, 2016 0

SCCM Packages

By Paul Heuring

So you’ve recently deployed Microsoft System Center 2012R2 Configuration Manager to replace an older implementation. But you had any number of tried and true packages that users and administrators have relied on. Rather than manually recreating them in the new environment, you could export them and import them into the new system.

Still, the new application deployment model offers some useful features missing from using Packages and Programs to deploy software. You might like to try using the Microsoft System Center Configuration Manager Package Conversion Manager, PCM, to bring those older packages into the new system.

Here is an overview of the PCM and some high level planning advice in using it.

Microsoft System Center Configuration Manager Package Conversion Manager is feature pack download for Microsoft System Center 2012 Configuration Manager that allows you to convert Configuration Manager 2007 packages into System Center 2012 Configuration Manager applications.

A Configuration Manager application contains files and programs that can be deployed to client devices. However, unlike Configuration Manager 2007 packages and programs, an application provides additional user-centric functionality.

For example, an application might contain deployment types for a local installation of a software package, a virtual application package, or a version of the application for mobile devices. Upon conversion, you can use the new features in applications such as dependencies, requirement rules, and user device affinity.

To effectively use the Package Conversion Manager it is best to plan your implementation. In a perfect world, you have a test environment wherein you can test the tool against packages imported from your production environment.  After completing testing of the converted applications, you can then export the converted applications from the test environment and then import them to the production environment. Your package conversion plan would look like the following.

1) Select the packages that you want to convert

Not all packages are suitable for conversion into applications. The best types of package for conversion to applications are those that contain user-facing software, for example:

  •     Windows update files: .msi and .msu.
  •     Microsoft Application Virtualization (App-V) programs.
  •     Windows executable files: .exe

The packages that shouldn’t be converted to applications include:

  •     System maintenance tools; for example, scripts or backup utilities.
  •     Packages that are at End-of-Life.

2) Migrate the packages for conversion into your Package Conversion Manager test environment.

Export them from your production environment into the test environment

3) Prepare the packages for conversion.

For each package you want to convert, ensure that they meet the following conditions:

  • The location specified for source files is a full UNC path, for example \\Server\Volume\File.
  • Windows update files, .msi and .msu, use only one unique Product Identification Locator (PID).

4) Select the test packages.

If possible, test packages that you select should include packages that meet the following criteria:

  • At least one test package with a readiness state of Automatic.
  • At least one test package with a readiness state of Manual.

Ideally, your test packages should be core packages, That is to say they are:

  • Packages that you know well.
  • Packages that are the most important to your business.
  • Packages that you can most easily test.

After identifying the appropriate packages for testing, move them to a separate folder in the Configuration Manager console.

5) Analyze, investigate, and convert the test packages.

You can analyze packages using three methods:

6) Test the converted applications.

Deploy the applications to test workstations to check for any problems.

7) Analyze and convert the remaining (non-test) packages.

8) Export the applications from the test environment and import them into your production environment.

You may find that the effort in converting packages is a lot less than trying to deploy old packages. The ability to take advantage of the user-centric approach to Application Deployments will serve you well.

Leave A Response »