This is the second part in a series about migrating from SCCM 2007 to CM 2012. For a high-level overview of the migration process, please click here: Migrating from SCCM 2007 to System Center 2012 Configuration Manager – (windowsmanagementexperts.com).
There are several key points that are worth mentioning again from the first article. The first is the planning your migration is vital. You must determine what data needs to be migrated, and what data needs to be rebuilt or redesigned. Second, collections are now either user or device based, not both. If you rely on collections with both users and devices, those collections will have to be redesigned. Third, not everything can be migrated. For a full list of what can and cannot be migrated, see this TechNet article: https://technet.microsoft.com/en-us/library/gg712991.aspx.
Setting up your migration
When setting up your migration, you need an Active Directory account that has full administrator rights in CM 2012. Microsoft recommends making this account the computer account for the 2012 primary server. This same account needs read access to all objects in your SCCM 2007 site. It also needs db_datareader and smsschm_users access to the SCCM 2007 database. You also must add this account to the “Distributed COM Users” group on your SCCM 2007 site server. By granting this account essentially read access to your SCCM 2007 environment, CM 2012 can make no modifications to it, so there is no risk of one system messing up the other system.
You must also open ports 445, 135, and 1433 (all TCP) from your CM 2012 server to your SCCM 2007 server. Port 1433 is for access to the SQL server, so adjust that accordingly if your SQL server runs on a different port.
Once your migration account and ports are configured, open your CM 2012 console and click on the “Administration” node. Expand the “Migration” tab, and right-click on “Source Hierarchy”. Select the “Specify Source Hierarchy” option. This is where you tie your SCCM 2007 system to your CM 2012 system. You should get a windows like this:
From this window, you specify all of the settings required for migration. In this window, the “Top-level Configuration Manager site server” is the FQDN of your SCCM 2007 server. Also, “source hierarchy” means your SCCM 2007 environment, and “destination hierarchy” means you CM 2012 environment. I recommend using the same account for the SMS Provider access and the SQL Server access. Once all of the information is provided, click OK, and CM 2012 begins to scan your SCCM 2007 environment.
Migrating objects
Once CM 2012 is done scanning the environment, you can set up migration jobs. From the CM 2012 console, select the “Administration” node, then the Migration tab, right-click on Migration Jobs, and select “Create Migration Job”. Give your job a name, then select the “Job type” drop-down box. You are presented with three options – Collection migration, Object migration, and Objects modified after migration.
Object migration is packages, task sequences, driver packages, images, etc. This makes a direct copy of the object, so if your source directory changes, you will have to change it on the package once it is imported into CM 2012. Migrate your objects in this order:
1. Software Distribution Packages
2. Operating System Deployment Images
3. Operating System Deployment Drivers
4. Operating System Deployment Driver Packages
5. Recreate your Boot Images (not migrate)
6. Task Sequences
Following this order will ensure that your task sequences are migrated successfully. Migrating your boot images is possible, but CM 2012 will want to recreate them with the newest version of WinPE, so recreating them is usually a better method then migration.
When migrating any objects, simply select the type, then the object (or group of objects), and then click Next.
You are then asked to confirm the sites. You should be able to keep the defaults. The next screen asks you to assign security scopes. Security scopes are outside of the scope of this article, but they basically are the new way to assign security rights in CM 2012 and work a lot like groups. Select the appropriate scopes, and click next. Read over the job information, then click next. The schedule window allows you to either run the job now, or schedule it. If you are migrating a lot of objects at once, scheduling the job may be beneficial, because the import process can be resource intensive on both the SCCM 2007 and CM 2012 servers. You can also specify what to do if there is a conflict. This runs based on the object ID and not the name, so be mindful of that. You can either set it to not overwrite current objects, or overwrite objects. Finally, you can have the system keep the same folder structure in the console.
After completing this window, click Next and view the Summary. If everything is correct, click Next and the migration job will execute.
Collection migration is exactly what it says – it migrates collections and their settings. This is also where you can migrate advertisements and turn them into deployments. The system reads the fact that there are advertisements related to the collection, and asks you if want to migrate those as well. If you plan to migrate advertisements, I would recommend doing collections last, because the packages and task sequences must be in place before the deployments can be created.
To migrate a collection, right-click on “Migration Jobs” and select “Create Migration Job”. Give the job a name, and leave “Job type” as “Collection”. Keep in mind that you cannot migrate collections that have both users and devices. These collections will not even show up in this list. You can click the “View Collections that Cannot Migrate” to see a list of these collections.
If you want to migrate advertisements, keep the “Migrate objects that are associated with the specified collections” option checked.
Check the collections that you want to migrate, and click Next.
The screen will list the deployments and packages associated with the collections that you selected. You can uncheck any of these options if you do not want to migrate something. Keep “Software Distribution Packages” checked, even though you have already migrated them. Click Next when you are ready to move on to the next screen.
Click Next through the site ownership screen. The next screen is the Security Scope screen. Apply security scopes as needed. Click Next through the next two screens (Collection Limiting and Site Code Replacement). Review the information on the next screen, and click Next. Configure schedule, conflict options, and organizational folder options on the Settings screen. These are the same settings we saw when migrating objects. The only new addition is the “Enable programs for deployment in the destination hierarchy after an advertisement is migrated from a source hierarchy”. This option does exactly what is says – activates a deployment after it is migrated. Click Next after all of the settings are configured. Review the summary, and click Next to run the job.
The final migration “Job type” is “Objects modified after migration”. This allows you to update an object if it is already been migrated. It will overwrite the object in the CM 2012 environment, so be careful when using this. It runs off the object ID, so just changing the object name will not keep it from being overwritten.
Summary
The most important thing with migrating from SCCM 2007 to CM 2012 is planning. It is critical to the success of your migration. When done correctly, migration can be very easy and really cut down on the time that you must maintain two systems. Lay out what you want to migrate and a timetable to get it done, and let the system do the rest.
Please be sure to come back for the third part in the series about how to migrate clients.
