SCCM 2012 – Migration Made Easy – Part 3

In Part 1 we discussed the requirements overview on preparing for a migration and in Part 2 we covered the types of objects that are available for migration and the exclusions. In this final write up in the series we will go through the process using the migration utility that has been hyped up by Microsoft within Configuration Manager 2012.

The first step in configuring the migration process is to “Specify Source Hierarchy.” This is both crucial and required in order to move forward with the migration plans. Specifying the Source Hierarchy allows ConfigMgr 2012 to gather all of the necessary data from SCCM 2007 in order to identify the objects that can be migrated.

Let’s go ahead and walk through this process. All of the migration tools are located under the administration section of the console.

Expand the Migration folder to reveal three options.

• Source Hierarchy
• Migration Jobs
• Distribution Point Upgrades

Either right-click on “Source Hierarchy” or from the ribbon, select “Specify Source Hierarchy.”

The first page of the Source Hierarchy wizard is now presented and there are a number of things to be configured. In order to properly acquire all of the information from the SCCM 2007 environment, it is necessary to start by specifying the top most level primary site. In most cases, the top level primary site in an SCCM 2007 hierarchy is a Central Primary.

With the Top-level Configuration Manager 2007 site server specified, the access accounts will need to be configured. As noticed in the screen shots, the necessary permissions have been laid out already.

• Read access to the SMS Provider.
• Read & Execute on the source site SQL Server

As with most SMS Providers access the account being specified will require Distributed COM Users permissions within AD. Microsoft outlines on TechNet that when specifying a computer account this permission is required, but I would recommend that you validate this access even when using a domain user account.

Once all of the accounts have been entered and “OK” has been selected, the data gathering process will immediately start. A progress window will appear showing the steps of data gathering.

If an error occurs during the data gathering process, nine times out of ten it is permission related. The ratio may indeed be even higher but we’ll go with 90% for now. Once the initial data gathering process has been completed the status of the Source Hierarchy will show a status of “Ready for next gathering process.”

With the Source Hierarchy data gathering complete it is now possible to move into the actual migration of objects. In order to begin migrating any data from SCCM 2007 we must first create a migration job. From the Migration section either right-click or use the ribbon and select “Create Migration Job.” This will start the migration job wizard.

There are three types of migration jobs…

• The Collection Migration option is the most comprehensive. When using this type of migration job it is possible to select associated items such as packages and advertisements that are targeted at the collections in question. Advertisements cannot be migrated outside of the collection migration job. Also, when migrating collections both maintenance windows and collection variables will be transferred. However, AMT client provisioning data cannot be migrated.
• Object Migration will allow for the migration of all the items outside of collections. Please refer to Part 1 of this blog series for a list of the objects available for migration.
• The last option, Objects modified after migration, has a rather specific purpose. As the migration of all SCCM 2007 data can be lengthy, depending on the complexity of the originating environment, it is possible that data on the 2007 side may be altered during the course of the migration. This option allows for that data to be updated without having to manually delete previously migrated objects.

The next step in the process is to select the collection(s) that will be migrated. It is not required to migrate “all” collections at once as multiple jobs of all types can be configured. The number of jobs will, by default, increase with the complexity of the SCCM 2007 environment as well as with the number of Sites and Security scopes within ConfigMgr 2012.

As you can see above, all of the collections will be displayed as they are laid out in SCCM 2007. Simply select all of the collections that are to be migrated. If the source environment has an immense number of collections, click the search button to display a complete list which can be sorted and narrowed to more effectively locate the desired collection. If migrating associated data with the collection is not required, uncheck the Migrate objects that are associated with the specified collection option at bottom of the wizard page.

As you browse through, it might be possible that the desired collection does appear in either the default list or in the search area. If this occurs, select View Collections that Cannot Migrate. There are 4 scenarios in which a collection will not be available for migration which are outlined below.

• Mixed Query Collections – collections containing users and computers —This can be eliminated by segregating the mixed collections on the SCCM 2007 side prior to the migration (which is recommended by Microsoft)
• Mixed Collection Hierarchy – collections where the parent and child collections are of different sites
• Multiple Collection Limiting – collection with limited by more than one other collection
• Limited to Blocked Collection – collection that is limited by a collection that cannot be migrated.

Once all of the collections have been selected for this particular migration job, the next page of the wizard will take us through the object selection (assuming it was chosen to do so). This page will only display the objects that are directly linked to the selected collections.

This page is very self-explanatory in that, if there are associated objects to the collections they can be migrated as part of the same job. A few additional notes…

• In order to migrate the advertisements their associated packages must also be migrated
• Migrated advertisements are not enabled by default (an option to enable is available thought it is not a Best Practice)

When migrating objects from SCCM 2007 it is necessary to specify the ConfigMgr 2012 content owner. The content owner, for lack of a better description, is the site from which you want the data to originate. If the migration is a single site, this section does not require any additional discussion. However, if there are multiple hierarchies being utilized in 2012, the desired content owner will need to be specified to allow for the proper assignment of data.

The next option is the assignment of a security scope. The security scope is part of the new role based administration model to assign the appropriate rights to the migrated objects based on the defined scopes. As we will not be getting into the detailed overview of Role Based Administration we will just move forward and assume the default scope will be selected.

This step of the process is designed to provide you with the ability to limit collections that can in scope once migrated. Let me explain a little further. In ConfigMgr 2012 all collections are global. The means that a collection created from any part of the hierarchy is available to all sites. So, for instance, if you were to migrate a collection from a child primary site that contains “All Windows 7 Systems” from that site when it is brought into the ConfigMgr 2012 environment that collection would now have all of the Windows 7 systems from the entire hierarchy. The migration tool recognizes these issues and allow you to provide the correct collection limiting (limiting is required in 2012).

This step is simple enough. If you have collections that contain queries using the Site Code from the SCCM 2007 environment they will be replaced with the correct site code from the ConfigMgr 2012 environment. This is an automatic process and does not require any configuration.

Now that you have gone through most of the migration job wizard there will be a window providing a review of the configurations and provides some information around the objects that have been chosen to migrate. It also provides information surrounding actions that might need or should be taken prior to the initialization of the migration job.

A new, and useful, feature of the review page is the ability to save the presented information to a file. This obviously will allow the proper tracking of tasks and migration processes for review as well as providing a record of the pre-migration recommendations. I recommend saving all of the files during your migration process as too much information is never a bad thing.

The settings page of the wizard is where the scheduling of the migration job is configured as well as the defining of actions that will occur while the migration job is running.

The first section of this page is for the scheduling of the migration job. There are three options and they are all self-explanatory…

• Do not run the migration job
• Run the migration job now
• Schedule the migration job

The second section outlines how to handle objects that have been previously migrated. The default selection is Do not migrate updated options which would be my general recommendation. When selecting the collections or objects to migrate the status of those items are provided, (migrated | not migrated), and those that have been migrated should be skipped. If indeed there are items that have been updated since a previous migration job has been run then use the Objects modified after migration job to update them.

Under the additional settings the Transfer the organizational folder structure for objects from Configuration Manager 2007 to the destination site has been pre-selected. If however, you don’t want any of the folder structures to come over during migration, simply uncheck this box. Some organizations may be using this migration as a reason to re-organize data and how items in the ConfigMgr environment are structured so they would chose not to migrate the folder structure. I, on the other hand, find it quite useful.

The last option is one we touched briefly on earlier which enables programs for deployment once migrated. This option needs to be weighed carefully as the ConfigMgr 2012 environment should be set up completely before using it. I make that statement with confidence as in the event an advert and program is enabled on migration and is targeted at a collection that has increased in scope, a number of systems that were not originally intended to run this program may do so. It is not difficult to go through and enable the programs after migration which also provides time to review what systems/users will be targeted.

The last pages of the wizard are ones that configuration manager administrators are very familiar with…summary, progress, completion. This is why I don’t think we all need to review them.

We have now reached the conclusion of the Migration Made Easy blog series. As always, I sincerely hope that the information that I have included here has been useful, at least in small part, to assist in your upcoming migration.

If you have located this page and have not reviewed Part 1 or 2 click here for a list of my blogs.