SCCM 2012 – Migration Made Easy – Part 2

In Part 1 of this blog series I presented an overview of the requirements for preparing a migration from Configuration Manager 2007 to 2012. With that information in hand I believe that you should have a general understanding of the pre-requisites necessary to begin your migration process.

The boundary migration process allows for a direct one to one migration of each boundary that is specified within a ConfigMgr 2007 source site. As ConfigMgr 2012 utilizes boundary groups in conjunction with standard boundaries, the migration process will create each boundary and automatically create a boundary group (for the corresponding source site) to which the migrated boundaries will become a member. Figure 1 shows three boundaries that have been migrated from a single ConfigMgr 2007 Site and Figure 2 shows that a single boundary group was created containing 3 boundaries.

Figure 1 – ConfigMgr 2012 Migrated Boundaries

Figure 2 – ConfigMgr 2012 Auto-Created Boundary Group

The migration of collections is by far one of the most useful processes of the utility for a couple of reasons. First and foremost, the collections that are selected for migration are automatically scanned by the migration utility to determine if there are any software packages, advertisements, software updates, and or task sequences that are associated with the selected collection(s). If any or all of the above are identified, the utility will provide the option to migrate those specifically referenced items to go along with the collection(s).

If you notice, “advertisements” are not present on the default list of migration objects that were previously mentioned yet are part of the collection migration. This is not in error. The migration of an advertisement is only an option during the collection migration, and only if an advertisement is targeting at the collection being migrated. The purpose behind this, which is my opinion and not a published fact, is that an advertisement cannot be migrated unless its targeted collection and package are present.

Secondly, if you have a collection structure utilizing empty collections for place holders and organization, the migration utility translates those collections into organizational folders. While I too was leery at first, after seeing the migration object translation I can say the process is very efficient. The screen shot in Figure 3 shows the collections being selected for migration, and Figure 4 shows what those collections look like after migration.

Figure 3 – Collection Migration Wizard

Figure 4 – Migrated Collections

Important Note: Collections containing both users and systems cannot be migrated. It is recommended that mixed collections be separated prior to the migration task.

Software packages are obviously a no brainer in terms of objects available for migration. All package options and programs are maintained during migration. However, the migrated packages are not translated into the new “application model.” Figure 5 shows two migrated packages and their corresponding program count.

Figure 5 – Migrated Software Packages

Microsoft has conveniently designed a Package Conversion Manager (PCM) to assist in turning your migrated Software Packages into ConfigMgr 2012 Applications. For more information on the PCG navigate to the following link:

https://technet.microsoft.com/en-us/library/hh531519.aspx

One caveat is the source content location. In order to facilitate a seamless migration for the software packages, all source file locations should utilize a UNC path. Any package that is using a local drive path as a source location when migrated will fail to distribute unless the specified path and corresponding source content are both present on the ConfigMgr 2012 Server.

As mentioned in Part 1 of this blog it is necessary to have the desired ConfigMgr 2012 infrastructure installed and configured to properly execute a migration. I must stress the importance of this in regards to migrating software updates. While it is probably evident that Software Update point(s) are required prior to Software Updates migration, what needs to be emphasized is the Product Catalog and Update languages must match the ConfigMgr 2007 configuration perfectly and be successfully synchronized. If a single update is missing from an entire update package the migration of that package will fail.

Important Note: All custom updates, locally published SCUP updates, will need to be republished as they cannot be migrated.

Software update packages as well as update template still exist within ConfigMgr 2012. Update Templates will need to have the duration settings reconfigured as it does not migrate. The migration process will convert Software Update Lists into Software Update Groups and a Software Update Deployment will be converted into a Deployment and corresponding Update Group.

During the migration of OSD objects the Drivers, Driver Packages, OS Images, and OS Install Packages (now called OS Installers) are migrated exactly as they were in ConfigMgr 2007. The lone exceptions to the rule are the Boot Images. While they are listed as objects that can be migrated, there some details that need identified.

The first and most impactful item is that customizations that were made to boot images in ConfigMgr 2007 cannot be migrated. Now that some of you are screaming on the inside let me explain why. The actual boot image WIM file is not what is being migrated. The drivers that have been injected in the ConfigMgr 2007 boot images are being automatically injected into similarly named boot images being created from the boot WIM files from the AIK on the ConfigMgr 2012 server. On a positive note, a good number of customization can be made to boot images through the new GUI in ConfigMgr 2012 such as Pre-Execution hooks and associated files.

Task Sequences are migrated almost identically as well. The only change that will be made automatically is when a client installation package is being used; it will be replaced with a reference the pre-created ConfigMgr 2012 Client package.

There are two items that warrant a brief outline in terms of DCM object migration. First, ConfigMgr 2007 Configuration Packs can be imported into ConfigMgr 2012. The Configuration pack is automatically converted to be compatible. Second, any un-interpreted configuration items WILL NOT be migrated nor can they be imported.

There are no significant changes to either Asset Intelligence or Software Metering. Therefore, the migration of these two categories is basically seamless and will appear in ConfigMgr 2012 just as they did in 2007.

• SCCM Queries
• Site Security and Instance Rights
• Object Security and Instance Rights
• SCCM Reports
• Client Inventory
• Client History Data
• AMT Provisioning Data
• Client Cache Files
• Boot Image Customizations
• Secondary Site

Please check back for Part 3 which will cover the actual migration process including creating migration jobs, what those migrated items look like in the new console, and some items around migration cleanup. And as always I hope this information is beneficial to all those looking into Configuration Manager 2012.