10 Steps to Migration: Configuration Manager 2012

Microsoft's release of the System Center 2012 suite at the Microsoft Management Summit in Las Vegas this April included System Center Configuration Manager (formerly known as SCCM), which takes care of client, server, and device management. Configuration Manager 2012 is all about "the new way of working": Bring Your Own Device (BYOD) and work anywhere. The new version of Configuration Manager takes a big step in that direction by focusing on the user instead of the device. Configuration Manager 2012 is rebuilt on three pillars:

The first pillar represents the ability for users to access their applications on any device. The second pillar represents the integration of other System Center products, such as System Center Endpoint Protection, parts of System Center Mobile Device Manager, and support for Microsoft Application Virtualization (App-V). The third pillar represents the simplified hierarchy of Configuration Manager 2012 and its support for roles-based administration. You can map your organizational roles to administrative roles in Configuration Manager 2012.

User-Centricity

Microsoft has transformed Configuration Manager from a systems-management platform to one that centers on the user. To support the user-centricity principle, Microsoft developed a new application model. This model uses three new terms, as Table 1 shows.

An application contains information about the application and can hold one or more deployment types. A deployment type specifies the installation files and installation method, such as one of the following methods:

Other methods are planned:

For each deployment type, you need to set requirement rules and settings. These will be used to determine how applications need to be installed on a device on which the user is logged on. The application can be deployed to a user collection; depending on the requirement rules, a deployment type is used to install or start the application.

Do we need to recreate all our old packages and programs in Configuration Manager 2012 and its new application model? No, because Configuration Manager 2012 has a migration feature.

The Migration Feature

Until now, there hasn't really been a manageable way to upgrade older versions of Configuration Manager (e.g., upgrading Microsoft Systems Management Server -- SMS -- to SCCM 2007). The upgrade path was a difficult hurdle. The most common method was rebuilding the environment from scratch and then recreating the objects by hand, or by upgrading the environment in place if the hardware was suitable for the new version.

The migration feature is an important new feature in Configuration Manager 2012. This feature allows you to preserve the time and money you've invested in SCCM 2007 and migrate it to the new Configuration Manager environment. The migration feature even lets you migrate the environment in a phased way instead of in one big bang.

The process of migrating to Configuration Manager 2012 is a side-by-side migration, so you need to build a new Configuration Manager 2012 hierarchy next to the current Configuration Manager 2007 hierarchy. The migration feature helps you with the migration of most objects through three types of migration jobs:

The collection migration job is used to migrate selected collections with all related objects, such as a package, advertisement, or configuration baselines. You can use the object migration job to migrate selected objects. The previously migrated object migration job is used to migrate objects that were previously migrated but have since been updated in the SCCM 2007 source hierarchy. You can use these migration jobs to migrate these types of objects (as Figure 1 shows):

Figure 1: Remigrating Changed Classic Packages 

During the migration process, you can share distribution points that still reside in the Configuration Manager 2007 environment with your new Configuration Manager 2012 clients. This way, your migrated clients can access content on the old distribution points during the migration process. After migrating all your objects and clients to the new environment, you can migrate a distribution point automatically or manually. The server on which the distribution point resides needs to meet certain requirements if you want to migrate a distribution point automatically (as Figure 2 shows):

Figure 2: Converting Distribution Point Content to the New Content Library

You can automatically upgrade distribution points such as branch distribution points, distribution point shares, and standard distribution points. When a branch distribution point is installed in Windows XP, you first need to upgrade the OS to Windows 7. Use the branch distribution point management task to migrate the distribution point from XP to Windows 7 without redistributing the content. A big advantage of the ability to migrate the distribution points is that you don't need to use the WAN because the content stays on the server.

Other Migration Tools

Besides the out-of-the-box migration feature, Microsoft has developed two Configuration Manager 2012 migration-related products: the Package Conversion Manager and the Physical-to-Virtual (P2V) Migration Toolkit. Another helpful tool for easing the migration is the Coretech Package Source Changer, developed by the Configuration Manager community.

Package Conversion Manager. The Package Conversion Manager is a Configuration Manager console add-on that lets you convert your migrated classic packages to the new Configuration Manager 2012 application model. Classic packages that are migrated from Configuration Manager 2007 are supported in Configuration Manager 2012 but do not support use of the new model's enhanced features. Using the Package Conversion Manager to migrate classic packages is highly recommended.

After you install the Package Conversion Manager, which Figure 3 shows, the packages ribbon in the Configuration Manager 2012 console is extended with the following three options:

Figure 3: Package Conversion Dashboard 

The Analyze Package option analyzes the classic package and determines whether it can be converted to the new application model. After the classic package has been analyzed, it is assigned a readiness state. Based on its readiness state, a classic package can be converted automatically, manually, or not at all.

To convert a package that has a readiness state supporting automatic conversion, simply select the package and then click the Convert Package button in the Configuration Manager 2012 console. A package with a manual readiness state might have a dependent package that must be converted, or there might be no source content available for the primary site. Depending on the issue, you can use the Fix and Convert option to identify and fix it, with the help of the Fix and Convert Wizard. Before every conversion, the package is analyzed and the validity of the readiness state is determined, as is the package's validity for conversion to the new application model. After the conversion is completed, you still need to test the deployment of the applications in your lab environment. Classic packages such as driver software or programs such as defrag are not applicable for conversion to the new model because they are hardware-related instead of user-related.

P2V Migration Toolkit. With the P2V Migration Toolkit, which Figure 4 shows, you can migrate a Configuration Manager 2007 primary site server on a branch office by temporarily virtualizing the server. This step allows you to migrate the site server without investing in new hardware. The P2V Migration Toolkit lets you create a task sequence on standalone media, such as a DVD or USB stick. Or you can create a task sequence that automatically virtualizes your current Configuration Manager 2007 implementation by creating a virtual hard disk (VHD), installing Windows Server 2008 R2, configuring Microsoft Hyper-V, and creating a virtual machine (VM) for the old Configuration Manager site server. After this P2V process is finished, you can install Configuration Manager 2012 on the physical server and migrate the virtual Configuration Manager 2007 primary site server via the migration feature. The P2V Migration Toolkit can also be used as a standalone application, to virtualize a server that is not related to Configuration Manager.

Figure 4: P2V Migration Toolkit Wizard 

Coretech Package Source Changer. The Configuration Manager community is very active, developing numerous scripts and tools as freeware or in the public domain. One such tool is the Coretech Package Source Changer, which was originally developed to change the source paths of packages in Configuration Manager 2007 but which also works with Configuration Manager 2012.

With this freeware tool, you can change the package source of a package object in Configuration Manager and copy the source to a new Universal Naming Convention (UNC) share. This tool is useful for moving or copying the package source of objects that you migrate via the Configuration Manager migration feature.

10 Steps to Migration

The Configuration Manager 2012 migration process is usually part of a project that consists of diverse Microsoft Operations Framework phases. Be sure to plan your migration project and walk through the Envision, Plan, and Design phases. A well-planned and well-designed Configuration Manager environment, based on the results of the envisioning phase, is a must for a successful migration process.

The Configuration Manager migration process consists of ten global technical steps:

1. Prepare your migration.

2. Test your migration scenario.

3. Configure the migration feature.

4. Configure distribution point sharing.

5. Create migration jobs and migrate the objects.

6. Change the UNC paths of the packages in Configuration Manager 2012.

7. Convert the packages to applications.

8. Migrate the secondary sites and upgrade the distribution points.

9. Deploy the new Configuration Manager 2012 client.

10. Remove Configuration Manager 2007.

Let's look at each step in more detail.

1. Prepare your migration. When you plan to migrate to Configuration Manager 2012, you need to prepare your Configuration Manager 2007 environment to support the migration. You can perform the following steps to add migration support to your Configuration Manager 2007 environment:

2. Test your migration scenario. When migrating your assets from Configuration Manager 2007 to Configuration Manager 2012, it’s important to test your migration scenario first in a lab environment. Familiarize yourself with the migration steps in the lab environment before migrating your production environment.

3. Configure the migration feature. You can find the migration feature in the Administration workspace in the Configuration Manager 2012 console. To configure this feature, you need to first define a source hierarchy. This source hierarchy is usually the highest primary site server in the Configuration Manager 2007 hierarchy. After the source hierarchy is defined, a data-gathering process gathers all information about the source hierarchy. When this process finishes for the first time, you need to configure other sites in the hierarchy with credentials that have access to those sites. By default, the data-gathering process runs every four hours.

4. Configure distribution point sharing. Not only are all objects inventoried during the data-gathering process, so are the Configuration Manager 2007 distribution points. The eligibility of those points for sharing with Configuration Manager 2012 is also determined. You can configure distribution point sharing per site. Use this option when you have a phased migration of clients, before moving all your packages to a Configuration Manager 2012 distribution point.

5. Create migration jobs. Depending on your Configuration Manager 2007 environment, you can migrate your objects in one or more migration jobs. If your migration phase will take longer, you can remigrate the changed objects in Configuration Manager. Be aware that the longer you are in the migration phase, the longer you need to maintain two Configuration Manager environments.

6. Change the UNC paths of the packages in Configuration Manager 2012. When the source of your just-migrated packages is still on the Configuration Manager 2007 site server, you might want to move them over to the new Configuration Manager 2012 server or servers. You can do so by using the Coretech Package Source Changer. This tool can change the UNC path of the package source and copy the files and folder structure to the new package source share on the Configuration Manager 2012 server. By changing the package source at the Configuration Manager 2012 packages, you leave the original source at the Configuration Manager 2007 site intact.

7. Convert the packages to applications. After changing the UNC paths and moving the content to the new Configuration Manager site server, you can convert the classic packages to the new application model. The Package Conversion Manager add-on will help you in the conversion process.

8. Migrate secondary sites and distribution points. You cannot migrate secondary sites to Configuration Manager 2012, so take your time to investigate whether a distribution point can replace your old secondary sites. Most roles, such as PXE support and bandwidth throttling, are now also available when implementing distribution points only.

9. Deploy the new Configuration Manager 2012 client. After preparing and testing the new Configuration Manager 2012 environment, you’re ready to deploy the new Configuration Manager clients to your devices. The deployment of these clients can be done in several ways. The best option is to deploy the Configuration Manager 2012 clients with your old Configuration Manager 2007 environment. This way, you have a managed way of deploying the new clients.

10. Remove Configuration Manager 2007. To remove Configuration Manager 2007, you first need to stop the data-gathering process and clean up the migration data from the Configuration Manager 2012 database. After doing so, you can remove Configuration Manager 2007 by uninstalling the site servers.

Migrating to Configuration Manager 2012

This article has given you an overview of the Configuration Manager 2007–to–Configuration Manager 2012 migration approach. You can now identify the steps that need to be taken when migrating your Configuration Manager 2007 environment to the current version. You can get started by downloading the P2V Migration Toolkit and Package Conversion Manager and Coretech Package Source Changer.

Table 1: Application Model Terminology