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:

• Set up the required permissions for migration
• Specify the source hierarchy
• Monitor the migration
• Create and run migration jobs
• Share and upgrade distribution points
• Migrate secondary sites
• Migrate clients
• Clean up after the migration
• Decommission site systems

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:

1. Create a user account in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in. For this scenario, a user account named Migrate will be used.
2. In the source site's Configuration Manager Console, expand the Site Database node, expand the Security Rights node, right-click Users, and choose Manage ConfigMgr Users to launch the ConfigMgr Users Wizard.
3. On the Welcome page, click Next.
4. On the User Name page, select Add a new user (if not already selected) and click the Browse button. Navigate to and select your migration account.
5. On the User Rights page, you can accept the listed rights, add or modify rights, or copy rights from another user (or group). Select the Add another right or modify an existing one option and click Next.
6. On the Add Right page, choose Site in the Class drop-down list. In the Instance drop-down list, leave the (All Instances) option selected. In the Rights box, select the Read check box. You need to add Read access to all the objects you want to migrate. Although Read access is all you need to migrate objects such as packages, advertisements, and update lists, this account requires Read, Modify, and Delete permissions for the Site object if you're going to share and upgrade source distribution points. After selecting the required rights, click Next.
7. Back on the User Rights page, review the rights you have chosen. As Figure 1 shows, leave the option The listed rights are sufficient selected and click Next.
8. On the Summary page, click Next. After you see the message The ConfigMgr User Wizard completed successfully on the Wizard Completed page, click Close.

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

1. On the source site, open SQL Server Management Studio (SSMS). When prompted, connect to the server.
2. Expand the Security node, right-click Logins, and choose New Login.
3. In the Login name box, click Search and find the migration account, as shown in Figure 2. Click OK.

4. Expand Databases in SSMS.
5. Right-click your database's name and choose Properties.
6. Under Select a page, click Permissions. In the Users or roles box, highlight the migration account, as shown in Figure 3.
7. Grant the migration account Connect, Execute, and Select permissions. Click OK.

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:

1. In the Configuration Manager Console, go to the Administration workspace, expand the Migration folder, right-click Source Hierarchy, and choose Specify Source Hierarchy to open the dialog box shown in Figure 4.

2. In the Source hierarchy drop-down list, select New source hierarchy.
3. In the Top-level Configuration Manager site server box, enter the Fully Qualified Domain Name (FQDN) of your top-level SCCM 2007 primary site server. You should always begin the migration at the top-level source site and work your way down to lower-level sites if you have multiple source sites to migrate.
4. To specify the user account that will be used to access the SMS Provider, click the Set button next to the User Account box and choose New Account.
5. In the Windows User Account dialog box shown in Figure 5, browse to the migration account, input its password twice, and click the Verify button. Make sure the correct SQL Server FQDN is displayed and click the Test connection button to verify that the account can access the source site's SQL Server instance. After you receive the message The connection was successfully verified, click OK.

6. Specify the user account that will be used to access the SQL Server source database. It can be the same account you used for the SMS Provider, a different user account, or a computer account.
7. If you want to share your existing SCCM 2007 distribution points, select the Enable distribution point sharing for the source site server check box. If you aren't ready to share distribution points yet, you can always come back later and select this option. I like to perform object migrations first, then share distribution points before migrating the clients.
8. Click OK to begin the process of gathering data from the source site. If you get the error message shown in Figure 6, the accounts you entered in the Specify Source Hierarchy dialog box aren't members of the source site server's local Distributed COM Users group. If you receive this error message, set the correct group membership and rerun the data gathering process by right-clicking the source hierarchy in the Configuration Manager Console and choosing the Gather Data Now option.

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.

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.

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 Files\Microsoft Configuration Manager\inboxes\mmctrl.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 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.

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

Table 1: Sample Message IDs and Their Descriptions

Message ID	Description
500	The SMS_Migration_Manager component started
8600	SCCM2012.Globomantics.com (GBL) site server connected and authenticated successfully to the SCCM2007.Globomantics.com site server
8616	Gathering from source site server SCCM2007.Globomantics.com (GLB) to SCCM2012.Globomantics.com (GBL) begins
8605	Gathering process from source site server SCCM2007.Globomantics.com (GLB) to SCCM2012.Globomantics.com (GBL) has finished

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 Files\Microsoft Configuration Manager\Logs. 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.

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.

Table 2: Objects That Can Be Migrated and How to Migrate Them

Objects That Can be Migrated	Collection Migration Job	Object Migration Job
Advertisements	X
Asset Intelligence catalog		X
Asset Intelligence hardware requirements		X
Asset Intelligence software list		X
Boundaries		X
Collections	X
Configuration baselines	X	X
Configuration items	X	X
Maintenance windows	X
OSD boot images	X	X
OSD driver packages	X	X
OSD drivers	X	X
OSD images	X	X
OSD packages	X	X
Software distribution packages	X	X
Software metering rules		X
Software update deployment packages	X	X
Software update deployment templates	X	X
Software update deployments	X	X
Task sequences	X	X
Virtual application packages	X	X

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

• Queries
• Security rights and instances for the site and objects
• SCCM 2007 reports from SQL Server Reporting Services (SSRS)
• SCCM 2007 web reports
• Client inventory and history data
• AMT client provisioning information
• Files in the client cache

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).

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.

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.

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.

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.

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.

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:

1. Click the Configuration button and input your SCCM 2012 site server's FQDN.
2. Click the List button to get a listing of all package source locations. You can clearly see which source locations were assigned to a drive letter versus UNC paths.
3. From the list, select the source location to get a listing of all packages from that source location. In the Old Pkg Source box, your chosen source location should be displayed.
4. Click the Select Packages button to get a list of packages from that source location and choose the specific package. Input the new destination in the New Pkg Source box and click Start. The package will be copied to the new location. If you change the package source from a drive letter to a UNC path, the package will be refreshed on your distribution points. (Beware of the network traffic this could incur.)

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.

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:

• Branch cache and cloud-based distribution points are supported in SCCM 2012, but not all features are available to them, such as OSD or software updates. I wouldn't attempt an OSD from a cloud-based distribution point just yet.
• In SCCM 2012, sharing distribution points automatically creates boundary groups to be used for accessing data. These boundary groups aren't used for site assignment. Clients in the SCCM 2007 site can still access data from the distribution points as always and so will the new SCCM 2012 clients. When the migration process is successfully completed (clients and all), you can upgrade your shared distribution points to SCCM 2012 distribution points. But you better be sure you're ready because once a distribution point is upgraded to SCCM 2012, it will no longer respond to SCCM 2007 clients.
• When you upgrade an SCCM 2007 branch or standard distribution point to SCCM 2012, it becomes an SCCM 2012 standard distribution point capable of bandwidth throttling and rate limit scheduling to control data flow (new to SCCM 2012).
• SCCM 2012 primary sites support up to 250 standard distribution points, which gives many organizations the option of replacing existing SCCM 2007 secondary sites with SCCM 2012 standard distribution points.
• SCCM 2012 SP1 introduced a new type of distribution point called a pull distribution point, which is designed to pull content from another distribution point. Pull distribution points aren't capable of throttling or scheduling content flow. Only standard distribution points have these capabilities.
• In SCCM 2012 R2, updating content on distribution points has been streamlined. When SCCM 2012 R2 refreshes data on the distribution points, it updates the fastest distribution point first instead of randomly selecting a distribution point to update. In addition, you can now cancel updating a distribution point.

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:

1. Within the Configuration Manager Console, go to the Administration workspace, expand the Migration node, highlight Source Hierarchy, and click the Shared Distribution Points tab.
2. On the Shared Distribution Points tab, right-click the shared distribution point and choose Upgrade to launch the Upgrade Shared Distribution Point Wizard. (Alternatively, you can highlight the shared distribution point and choose Upgrade Distribution Point from the ribbon.)
3. Walk through the Upgrade Shared Distribution Point Wizard. The wizard is pretty self-explanatory. Just be sure to:

• Attach the distribution point to the correct site code from the Site code drop-down list on the General page.
• Select whether you want Microsoft IIS installed (if needed) on the Distribution Point page. The version of IIS that gets installed will be determined by the OS of the distribution point being upgraded. Remote Differential Compression (RDC) will be installed if it isn't already present, but the Background Intelligent Transfer Service (BITS) won't be installed.
• Choose the amount of drive space reserved, the primary and secondary content library locations, and the primary and secondary package shares location on the Drive Settings page. For those drives where you don't want SCCM content to reside, using the NO_SMS_ON_DRIVE.sms text file still works.

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:

• Don't break the existing service in the SCCM 2007 environment.
• Don't install a CAS just to have one—you should have a reason for installing it.
• The source and destination sites can't have the same site code.