Migrating from SCCM 2007 to SCCM 2012

The new features in Microsoft System Center 2012 Configuration Manager (SCCM 2012) are well worth the time and money it takes to migrate from System Center Configuration Manager 2007 (SCCM 2007). If the new Role-Based Administration security model or the ability to manage Windows RT (WinRT), Windows 8, Apple iOS, and Google Android phones isn't enough to entice you, maybe the ability to use applications to deploy software, which requires little storage space due to single instancing at the file level on distribution points, is. Microsoft has also redesigned the UI, site hierarchies, security, and package deployments.

I'll show you how to migrate from SCCM 2007 to SCCM 2012. Migrating to SCCM 2012 requires at least SCCM 2007 SP2. I'm assuming you have SCCM 2012 installed and running properly and have extended the Active Directory (AD) schema. (If you extended the AD schema for SCCM 2007, there's no need to do it again, as nothing has changed.) After discussing the site hierarchy changes (including a new type of site), I'll show you how to:

Understanding the Site Hierarchy Changes

SCCM 2007 gave us many reasons to create multiple sites. The main reasons were security boundaries and controlling data flow to distribution points on the opposite end of slow or unreliable WAN links. Primary sites could have child primary or secondary sites, and secondary sites didn't require a Microsoft SQL Server installation.

SCCM 2012's Role-Based Administration lets you control security at the object level (and higher) and define client agent settings to collections instead of assigning them site-wide. Controlling the data content of distribution points can now be accomplished using bandwidth throttling and rate limit scheduling. You might even be able to replace existing secondary sites with an SCCM 2012 distribution point now that SCCM 2012 secondary sites require SQL Server. You can migrate a single SCCM 2007 site to a single SCCM 2012 site, multiple SCCM 2007 sites to multiple SCCM 2012 sites, or multiple SCCM 2007 sites to a single SCCM 2012 site, which is the most popular scenario. Whichever migration scenario you choose, this is your chance to redesign the entire SCCM environment utilizing the new technologies.

The new Central Administration Site (CAS) is a special type of site used mainly for administrative purposes and to connect primary sites. Parent primary sites can no longer have child primary sites—they can have only child secondary sites. A CAS can't contain management or distribution points, so when it comes to servicing clients, it isn't your friend. A few reasons to use a CAS would be that you need to support more than 100,000 clients, you require reporting capabilities at a high level, or there are political or legal reasons. Most organizations won't need a CAS, and it would only add unnecessary complexity. If you don't need a CAS, you should install a primary site that is capable of creating child secondary sites if needed.

Before I start explaining how to migrate from SCCM 2007 to SCCM 2012, a quick lesson on migration terminology is in order. The SCCM 2007 site you're migrating from is called the source site. The SCCM 2012 site you're migrating to is called the destination site. The migration process requires unique site codes for the source and destination sites. For example, my source site has a site code of GLB, whereas my destination site has a site code of GBL. If you accidentally give the source and destination sites the same site code, your migration will fail.

Setting Up the Required Permissions

Before you begin the migration, you need to set up permissions so that the destination site can access objects from the source site. The destination site requires access to the source site's SMS Provider (Read permissions for the Site object and all other objects) and SQL Server database (Connect, Execute, and Select permissions for the source site's database). In a multi-domain or forest environment, trust relationships might need to be put in place if they don't already exist. Permissions can be delegated to either user or computer accounts. The Microsoft documentation states that if a computer account is used, it must be a member of the source domain Distributed COM Users security group. But, in reality, no matter whether a user or computer account is used, the account still requires being a member of the local Distributed COM Users group on the source site server. Granting access to the local Distributed COM Users group allows the account to launch, activate, and use DCOM objects on the source site server. The account you use also needs Read access to all data source locations for packages and drivers.

To grant a user account access to the source site's SMS Provider, follow these steps:

Figure 1: Granting the Migration Account Permissions to the Source Site's SMS Provider

To grant a user account access to the source site's SQL Server database, follow these steps:

Figure 2: Specifying the Migration Account

Figure 3: Granting the Migration Account Permissions to the Source Site's SQL Server Database

Setting Up the Source Hierarchy

Now you're ready to begin the migration process. The first task is to set up the source hierarchy by following these steps:

Figure 4: Setting Up the Source Hierarchy

Figure 5: Choosing and Verifying the Migration Account When Setting Up the Source Hierarchy

Figure 6: Receiving an Error Message Noting That the Data Gathering Process Failed

After the data is successfully gathered, you can review the high-level information from the Summary tab at the bottom of the Configuration Manager Console. As Figure 7 shows, my data gathering process found 84 items. Data gathering occurs every four hours by default. You can change the default interval by opening the properties of the source hierarchy. Your options are every 1, 2, 4, 8, 12, 18, or 24 hours. Prior to running migration jobs, you'll want to be sure a data gathering operation is performed to ensure you have the latest metadata from the source site. You can use the Gather Data Now option any time you want to gather data outside the predefined interval periods.

Figure 7: Reviewing Sample Results from a Data Gathering Process

Monitoring the Migration

You can monitor each step of the migration. Whether you're monitoring the data gathering process or the results of a migration job, you can find the basic information by going to the Administration workspace, expanding Migration, and clicking Migration Jobs. When you run a migration job, the status of that job is displayed in the Status column. "Not Started" is displayed until the job begins to run, then "Running" will be displayed until the job finishes, in which case "Completed" is shown. You might have to refresh the screen a few times to see the status changing (pressing F5 works).

After the data gathering or migration job has completed, there are two tabs at the bottom of the screen: Summary and Objects in Job. As Figure 8 shows, the Summary tab displays high-level information about the job properties, object migration progress, and related objects. If there are problems with a migration, there will be alerts you can view by clicking the Alerts link.

Figure 8: Displaying High-Level Information About a Data Gathering or Migration Job

The Objects in Job tab displays each object's name, migration status, object type, object ID (from the source site), and messages, as shown in Figure 9. For more detailed information, you can open the E:Program FilesMicrosoft Configuration Managerinboxesmmctrl.box folder (or wherever you installed SCCM 2012). When you see the 16777217.SYN file appear, the gathering process has begun. (The .SYN file is an instruction file telling SCCM 2012 what to do.) The .SYN file is there for only a moment, so if you blink, you might miss it. Once this file has appeared and disappeared, you can view a more detailed status of the process in the SMS_Migration_Manager component, which you can access by going to the Monitoring workspace, expanding System Status, and clicking Component Status. To review the messages, right-click SMS_Migration_Manager, select Show Messages, choose All, and set the viewing period. (I always go with the default of one day ago.)

Figure 9: Displaying Information About the Objects in a Job

Figure 10 shows some sample messages from a data gathering process. Although the short description "The component started" is easy to read, the longer descriptions are best viewed by hovering your cursor over the description you want displayed.

Figure 10: Reviewing Messages from a Data Gathering Process

The message IDs and their descriptions are summarized in Table 1.

If you need even more information (e.g., for troubleshooting purposes), you can open the migmctrl.log file found in the Logs folder that's part of the SCCM 2012 installation directory. For exampIe, I installed SCCM 2012 on the E drive, so my logs are in E:Program FilesMicrosoft Configuration ManagerLogs. The migmctrl.log file contains a lot of information, so if you want to quickly get your latest migration information, press Ctrl+F and search for SYN. I opened the migmctrl.log file shown in Figure 11 using the CMTrace utility found in the SCCM 2012 support tools.

Figure 11: Examining the migmctrl.log File

Creating and Running Migration Jobs

There are three types of migration jobs: collection migration, object migration, and objects modified after migration. The objects to be migrated depend on the type of migration job created and run. Table 2 shows the objects that you can migrate and the types of migration jobs you can use to migrate them.

Objects that can't be migrated using the Microsoft Migration utility are:

Migrations typically last weeks and even months. During this time, it's not uncommon for objects in the source site to be modified. The objects modified after migration job type lets you migrate items that have been migrated to the destination site but later edited in the source site—and you want the changed object to be migrated to the destination site.

Migrating Collections

The first type of migration job I'll cover is the collection migration job. Suppose that you have an SCCM 2007 collection named Windows 7 Clients, which Figure 12 shows. It contains four systems: Client4, Client5, Test, and Test3. It also contains three subcollections: Marketing (an empty collection), OSD (contains one system CM2007Client) and Sales (an empty collection).

Figure 12: Examining the SCCM 2007 Collection and Subcollections

To create a collection migration job, you use the Create Migration Job Wizard. You can access this wizard by going to the Administration workspace in the Configuration Manager Console, expanding Migration, right-clicking Migration Jobs, and selecting Create Migration Job.

On the General page of the Create Migration Job Wizard, you need to give the migration job a name and description. You also need to select Collection migration from the Job type drop-down list. Clicking Next will bring you to the Select Collections page.

The Select Collections page lets you not only choose the collections you'd like to migrate but also view collection migration status. As Figure 13 shows, the page lists all the collections and specifies whether they've been migrated, whether they contain devices or users, and whether any collections are blocked from migration. For this example, I selected the Windows 7 Clients collection and its subcollections for migration.

Figure 13: Choosing the Collections to Migrate

If you have a large number of collections, it might be easier to click the View Collections that Cannot Migrate button rather than scrolling through all your collections. The Collections That Cannot Be Migrated dialog box lists not only the collections that won't be migrated but also the reason why, as shown in Figure 14. After you review the collections that won't migrate, click Close to go back to the Select Collections page.

Figure 14: Finding Out Why Some Collections Can't Be Migrated

At the bottom of the Select Collections page, notice the Migrate objects that are associated with the specified collections check box. If you leave this check box selected, objects that have been advertised to the collections (e.g., packages, baseline configuration items) will be migrated.

I prefer to migrate my objects separately from the collections so I always clear the Migrate objects that are associated with the specified collections check box. Here's why: When you leave this check box selected and click Next, you'll see a list of the objects to migrate on the Select Objects page. Deselecting an item on this page adds that object and any object that depends on it to the global exclusion list. For example, if you have an Operating System Deployment (OSD) task sequence that uses a Microsoft Deployment Toolkit (MDT) package and you deselect the MDT package so that it's not migrated, the OSD task sequence that uses the MDT package will be added to the exclusion list as well as the MDT package itself. If the task sequence were migrated and run, it would fail because the task that calls for the MDT package couldn't run. Items that are added to the exclusion list are global for all migration jobs. So, if that same OSD task sequence is advertised to another collection, when you migrate that second collection, the MDT package and the OSD task sequence would be excluded from migration. In addition, this global exclusion list is applied to all source site migrations. So, if you have the OSD task sequence advertised to a parent and child source site, it would be excluded from migration from both source site locations. (Note that if you happen to exclude an item that you need, you can remove it from the exclusion list by highlighting either Source Hierarchy or Migration Jobs in the Configuration Manager Console and choosing Edit Exclusion List from the ribbon.)

Assuming that you want to migrate your objects separately from the collections, clear the Migrate objects that are associated with the specified collections check box. Click Next to go to the Security Scope page.

On the Security Scope page, choose the Default security scope. Security scopes dictate which users have specific levels of access to objects within SCCM 2012. Unless you have created other security scopes using Role-Based Administration, the Default security scope will be the only selection. You can create additional security scopes by clicking the Create Security Scope button. Click Next.

The Collection Limiting page lets you collapse collections from multiple source sites into a single SCCM 2012 site. For example, if you already have a collection named Windows 7 Clients and were now migrating another collection named Windows 7 Clients from a different source site, you have the option to either combine all Windows 7 Clients into a single limiting collection or keep them separate. Assuming that you don't have any collections to collapse, click Next.

The Site Code Replacement page reveals which queries contain the source site code and shows that the source site code will be changed to the destination site code. After reviewing the code on this page, click Next.

The Review Information page shows actions that either you or SCCM 2012 must take to control the scope of the migrated collections. The page also shows the objects that might be modified by SCCM 2012 during the migration (such as site code changes) or that might require additional configuration before the object can be migrated. You can save all this information to a text file for review later. I highly recommend doing so just in case you need the information. When you're finished reviewing and saving the information, click Next.

On the Settings page, you need to configure settings in three sections, as shown in Figure 15. In the first section, you need to specify whether you want to run the migration job now (the default) or at a later date and time. You can also specify that you don't want to run the job. In the second section, you need to tell SCCM 2012 what to do when it encounters a previously migrated object that has since been changed in the source site and the current migration job will be migrating that same object again. The default setting is to not migrate updated objects, but you can tell SCCM 2012 to overwrite the object in the destination site if desired. In the third section, you need to specify whether or not to transfer the folder structure. By default, SCCM 2012 will transfer your folder structure from the source hierarchy to the destination hierarchy. If you want to design and create your folder structure from scratch, you need to clear the check box in the third section. For this example, leave all three defaults selected and click Next.

Figure 15: Scheduling the Migration Job

The Summary page lets you review your settings. After doing so, click Next. Finally, click Close on the Completion page.

In the Configuration Manager Console, you can monitor the status of the collection migration job by refreshing the screen until you see a status of Completed. Then, at the bottom of the screen, you'll see two tabs: Summary and Objects in Job. The Summary tab gives you a high-level overview about how many objects were migrated, how many objects failed to migrate, and how many objects were skipped. To get detailed information about which objects migrated, failed to migrate, or were skipped, click the Objects in Job tab.

To view the newly migrated collections, go to the Assets and Compliance workspace. Under Device Collections, you'll now have a Windows 7 Clients folder (and not a collection), as shown in Figure 16. The folder contains two collections: Marketing and OSD. The contents of the Windows 7 Clients folder (Client4, Client5, Test and Test3) is dumped into the Devices node, and you're left with two empty collections (Marketing and OSD). For this reason, it's sometimes better to create limiting collections in SCCM 2012 and not rely on migrating them from SCCM 2007. You probably won't get what you expect.

Figure 16: Examining the Newly Migrated Collections

Migrating Reports

SCCM 2007 classic reports can't be migrated using the Microsoft Migration utility, but there's a helpful utility named ReportSync. You first need to migrate your SCCM 2007 reports into SSRS, then ReportSync can migrate those reports to SCCM 2012 and update their data source. Kent Agerlund's great blog post "Migrate reports from SCCM 2007 to SCCM 2012 SP1" contains step-by-step instructions as well as a link to the free ReportSync utility.

Migrating Packages and Advertisements

Migrating packages and advertisements is best done with an object migration job. Packages are probably the biggest part of your migration, but you might not need to migrate all of them. A good rule of thumb is to not migrate packages that haven't been used in the past six to eight months.

When creating packages in SCCM 2007, you can use either drive letters or Universal Naming Convention (UNC) paths for package sources. In SCCM 2012, you can only use UNC paths. So, you might need to change the package source locations for your newly migrated packages. (Don't change them in the SCCM 2007 site.) Coretech offers a great free tool named Package Source Changer, which Figure 17 shows, that's a piece of cake to use.

Figure 17: Using the Package Source Changer Tool to Change Paths

This tool lets you change package source locations set as a drive letter to a UNC path and change an old UNC path to a new UNC path. After you download this tool, run PackageSourceChanger.exe as an Administrator. Accept the license agreement and follow these steps:

When migrating advertisements, they're disabled in the destination site by default. If you choose to migrate advertisements, you need to enable the programs after the migration. You could decide to not migrate advertisements and create new deployments for your migrated packages. (Deployments are what advertisements are called in SCCM 2012.) The advertisements that have already run on your clients will be included in the clients' history, which is maintained on the clients, so you needn't worry that all the packages will be deployed yet again—this isn't the case.

Migrating OSDs

When migrating an OSD, you must migrate all its components, including packages, task sequences, .wim image files, drivers, and driver packages. The ability to migrate your OSDs successfully will depend on whether you created the OSD with MDT integration or not. If your SCCM 2007 environment has MDT integrated, it can be a bit more cumbersome to migrate. A MDT task sequence within SCCM 2007 creates tasks that have the Solution Accelerators logo, which is shown in Figure 18.

Figure 18: Looking for the Solution Accelerators Logo

These tasks won't migrate properly. One workaround is to duplicate the task sequence and edit it. (You don't want to break the existing SCCM 2007 OSD service, so you shouldn't make any changes to the task sequence that's being used.) Specifically, you can delete all the tasks that have the Solution Accelerators logo on them. I like to take screen shots of the tasks before I start deleting them so that once the task sequence is migrated, I can easily put the tasks back where they belong. Optionally, once you get the duplicated task sequence migrated, you can create a completely new MDT task sequence and copy and paste the tasks from the migrated task sequence to the new task sequence, which will be using a newer version of MDT. The ability to copy entire folders makes this a snap.

Another workaround is create an empty custom task sequence in SCCM 2007 and copy all your custom tasks (e.g., driver packages, application installations) from the existing working task sequence into the custom task sequence. Then, you just need to migrate the custom task sequence, create a new task sequence, and copy your custom settings into the new task sequence.

How your driver packages were created will determine whether they're migrated. If you added your drivers to the driver store in the source site, then created your driver packages, you should be okay as long as you have Read permissions (or sometimes Read and Execute permissions) on the driver sources. If you created driver packages without importing the drivers into the driver store first, the driver packages won't migrate.

Sharing and Upgrading Distribution Points

Distribution points contain data for all your SCCM 2007 packages that have been advertised. Usually there's quite a lot of data residing on a distribution point, so you first need to decide whether to create new SCCM 2012 distribution points or share the source site's distribution points with your new SCCM 2012 destination site. Sharing the SCCM 2007 distribution points allows the destination site to use the existing data content without sending large amounts of data to a new SCCM 2012 distribution point. After the migration is complete, you can upgrade the SCCM 2007 distribution points to SCCM 2012 distribution points if you choose, as long as the minimum hardware requirements for SCCM 2012 distribution points are met.

There are a few things you should know about sharing and upgrading distribution points when designing and implementing SCCM 2012:

To share SCCM 2007 distribution points, go to the Administration workspace in the Configuration Manager Console, expand Migration, click Source Hierarchy, highlight the source hierarchy you already created, and choose Configure from the ribbon. Then in the bottom left corner, select the Enable distribution-point sharing for this source site check box and click OK. You can view your shared distribution points by highlighting Source Hierarchy and clicking the Shared Distribution Points tab at the bottom. This tab also gives you valuable information about which distribution points can and can't be migrated in the Eligible to Upgrade column.

To share a distribution point, the account used to access the source site's SMS Provider requires only Read access. However, to upgrade a distribution point to an SCCM 2012 standard distribution point, you need Read, Modify, and Delete access to the Site object. You can upgrade shared distribution points to SCCM 2012 distribution points by following these steps:

You can monitor the distribution point upgrade by expanding the Migration node in the Administration workspace, clicking Distribution Point Migration, and highlighting your distribution point. You might need to refresh the screen to see the status changing. You can also monitor the distribution point upgrade by reviewing the ConfigMgrSetup.log.

Migrating SCCM 2007 Secondary Sites to SCCM 2012 Distribution Points

In SCCM 2007, administrators use secondary sites in a few scenarios. One of the most common uses is to control the flow of data across slow or unreliable WAN links. With SCCM 2012's new throttling and scheduling capabilities, content control can be accomplished with distribution points alone. During your migration, sharing a secondary site distribution point is done just as you would share any other distribution point, but upgrading is a little different. When you upgrade an SCCM 2007 secondary site to an SCCM 2012 distribution point, SCCM first uninstalls the secondary site. Then, at the next data-gathering interval (the default interval is four hours), it upgrades the distribution point to an SCCM 2012 standard distribution point.

There were some problems in the early days of migration. When upgrading an SCCM 2007 secondary site to an SCCM 2012 (no service pack) distribution point, the presence of the PXE Service Role could prevent the upgrade. This problem was resolved in SCCM 2012 SP1 and should no longer be an issue. If you haven't installed SP1 and you encounter this scenario, you need to remove the PXE Service Role prior to upgrading the distribution point.

Migrating SCCM 2007 Secondary Sites to SCCM 2012 Secondary Sites

If you need to retain your secondary sites in SCCM 2012, you can upgrade an SCCM 2007 secondary site shared distribution point to an SCCM 2012 secondary site. First, you need to create the SCCM 2012 secondary site. (SQL Server is now required, but the free Express editions are supported.) Then, when upgrading the secondary site shared distribution point on the General page of the Upgrade Shared Distribution Point Wizard, select the SCCM 2012 Secondary Site Code from the Site code drop-down list.

Migrating Clients

Migrating clients should be performed only after all objects required by the clients have been migrated. Typically, this is one of the last steps in the migration process. There are many ways to deploy the SCCM 2012 client, including client pushing and using logon or startup scripts. No matter how you choose to migrate your clients, SCCM first uninstalls the SCCM 2007 client, then installs the new SCCM 2012 client. To avoid overlapping boundaries, you don't need to use boundary groups for client site assignment. When assigning your clients a site code, use the property SMSSiteCode=GBL (not SMSSiteCode =Auto).

Cleaning Up

After you completed the migration process, you might want to clean up some items. First, the clients from the source site aren't deleted in the source site. Therefore, you might want to delete the clients that have been migrated to the destination site so that your reports about the source site reflect the true number of clients. You also might want to delete the migration history for the source hierarchy. To do so, go to the Administration workspace, expand the Migration node, highlight Source Hierarchy, and select the Clean Up Migration Data option on the ribbon.

Decommissioning the SCCM 2007 Site Systems

When you're ready to completely decommission your source sites, you should start from the lowest child site (i.e., start at the bottom and work your way up). Remove SCCM 2007 roles from all site systems and re-use the hardware elsewhere in your network or, if virtual site systems were used, you can reclaim the hard drive space. Next, disconnect the child primary sites from the parent primary sites and delete all secondary sites. It's also a good idea to delete any old source site code information from AD.

Three Golden Migration Rules

I hope this guide will help you get started with your migration process and alleviate a bit of the pain that can go with it. I'll leave you with the three golden migration rules that should be followed for a successful migration: