Use the following sections to help you plan for the Microsoft System Center 2012 Configuration Manager migration of objects that are associated with specific features in Configuration Manager.

Planning to Migrate Software Updates

You can migrate software update objects, such as software update packages and software update deployments.

To successfully migrate software update objects, you must first configure your destination hierarchy with configurations that match your source hierarchy environment. This requires the following actions:

  • Deploy an active software update point in the destination hierarchy.

  • Configure the catalog of products and languages to match the configuration of your source hierarchy.

  • Synchronize the software update point in the destination hierarchy with a Windows Server Update Services (WSUS).

When you migrate software updates, consider the following:

  • Migration of software update objects can fail when you have not synchronized information in your destination hierarchy to match the configuration of your source hierarchy.

    Warning
    It is not supported to use the WSUSutil tool to synchronize data between a source and destination hierarchy.
  • You cannot migrate custom updates that are published by using System Center Updates Publisher. Instead, custom updates must be republished to the destination hierarchy.

When you migrate from Configuration Manager 2007 to System Center 2012 Configuration Manager, the migration process modifies some software updates objects to the System Center 2012 Configuration Manager format. Use the following table to help you plan the migration of software update objects from a supported Configuration Manager 2007 source hierarchy to System Center 2012 Configuration Manager.

Configuration Manager 2007 object System Center 2012 Configuration Manager object

Software update lists

Software update lists are converted to software update groups.

Software update deployments

Software update deployments are converted to deployments and update groups.

Note
After you migrate a software update deployment from Configuration Manager 2007, you must enable it in System Center 2012 Configuration Manager before you can deploy it.

Software update packages

Software update packages remain software update packages.

Software update templates

Software update templates remain software update templates.

Note
The Duration value in Configuration Manager 2007 deployment templates does not migrate.

When you migrate from a supported System Center 2012 Configuration Manager hierarchy to another System Center 2012 Configuration Manager hierarchy, the software updates objects are not modified.

Planning to Migrate Content

You can migrate content from a supported source hierarchy to your destination hierarchy. For a Configuration Manager 2007 source hierarchy, this content includes software distribution packages and programs and virtual applications, such as Microsoft Application Virtualization (App-V). For a System Center 2012 Configuration Manager source hierarchy, this content includes applications, and App-V virtual applications. When you migrate content between hierarchies, it is the compressed source files that migrate to the destination hierarchy.

Packages and Programs

Virtual Applications

Advertisements

Applications

Planning to Migrate Collections

You can migrate the criteria for collections from a supported System Center 2012 Configuration Manager source hierarchy. To migrate System Center 2012 Configuration Manager collections, you use an object-based migration job. When you migrate a collection, you migrate the rules for the collection and not information about the members of the collection or information or objects related to the members of the collection.

Migration of the collection object is not supported when you migrate from a Configuration Manager 2007 source hierarchy.

Planning to Migrate Operating System Deployments

You can migrate the following operating system deployment objects from a supported source hierarchy:

  • Operating system images and packages. The source path of boot images are updated to the default image location for the Windows Administrative Installation Kit (Windows AIK) on the destination site. The following are requirements and limitations to migrating operating system images and packages:

    • To successfully migrate image files, the computer account of the SMS Provider server for the destination hierarchies top-level site must have Read and Write permission to the image source files of the source sites Windows AIK location.

    • When you migrate an operating system installation package, ensure that the configuration of the package on the source site points to the folder that contains the WIM file, and not to the WIM file itself. If the installation package points to the WIM file, the migration of the installation package will fail.

    • When you migrate a boot image package from a Configuration Manager 2007 source site, the package ID of the package is not maintained in the destination site. The result of this is that clients in the destination hierarchy cannot use boot image packages that are available on shared distribution points.

  • Task sequences. When you migrate a task sequence that contains a reference to a client installation package, that reference is replaced with a reference to the client installation package of the destination hierarchy.

    Note
    When you migrate a task sequence, Configuration Manager might migrate objects that are not required in the destination hierarchy. These objects include boot images and Configuration Manager 2007 client installation packages.
  • Drivers and driver packages.

Planning to Migrate Desired Configuration Management

You can migrate configuration items and configuration baselines.

Note
Uninterpreted configuration items from Configuration Manager 2007 source hierarchies are not supported in System Center 2012 Configuration Manager. You cannot migrate or import these configuration items. For information about uninterpreted configuration items, see the “Uninterpreted Configuration Item” section in the About Configuration Items in Desired Configuration Management topic in the Configuration Manager 2007 documentation library.

You can import Configuration Manager 2007 Configuration Packs to System Center 2012 Configuration Manager. The import process automatically converts the Configuration Pack to be compatible with System Center 2012 Configuration Manager.

Planning to Migrate AMT-Based Computers that are Provisioned for Out of Band Management

You cannot migrate the AMT provisioning information between hierarchies and must take additional steps before you can manage an AMT-based computer out of band in the destination hierarchy. These steps include the removal from clients of the AMT provisioning information from the source site, and then provisioning new information from a site in the destination hierarchy. To do this, make sure that you have installed and configured a site in the destination hierarchy for AMT provisioning, and then use one of the following strategies:

  • In the source site, remove the AMT provisioning information and select the option Disable automatic provisioning. Migrate the client. Then in the destination site, provision the AMT-based computer.

  • In the destination site, configure the AMT Provisioning Removal Account in the Out of Band Management Component Properties: Provisioning tab. Specify a Windows account that has been specified as an AMT User Account in the source site. For migration from a supported Configuration Manager 2007 site, ensure this AMT User Account has the Platform Administration (Configuration Manager 2007 SP2) or PT Administration (Configuration Manager 2007 SP1) permission. Migrate the client and assign it to the destination site. Then remove the provisioning information from the AMT-based computer by using the AMT Provisioning Removal Account, and provision it again.

    Warning
    If the account that you specify for the AMT Provisioning Removal Account is not an AMT User Account for the computer, or the AMT User Account does not have the required permission, or if the audit log contains data, you will not be able to remove the provisioning information from the destination site. If you are not sure whether the AMT-based computer is configured with this AMT User Account, for Configuration Manager 2007 source sites either check and update the management controller in the Configuration Manager 2007 site, or remove the provisioning information when the client is still assigned to the Configuration Manager 2007 site. If AMT auditing is enabled, either clear the audit log or disable auditing when the client is still assigned to the Configuration Manager 2007 site. For more information about how to manage the audit log in Configuration Manager 2007, see How to Manage the Audit Log for AMT-based Computers in the Configuration Manager 2007 documentation library.
  • Migrate the client. Manually remove the provisioning information in the BIOS extensions of the AMT-computer. Then in the destination site, provision the AMT-based computer.

For more information about how to remove the AMT provisioning information, configure AMT User Accounts, and update the management controllers from a Configuration Manager 2007 site, see the following topics in the Configuration Manager 2007 documentation library:

For more information about to configure AMT provisioning and the AMT Provisioning Removal Account in a System Center 2012 Configuration Manager site, and how to remove AMT provisioning information in a System Center 2012 Configuration Manager site, see the following:

Planning to Migrate Boundaries

You can migrate boundaries from a supported Configuration Manager 2007 source site, or a supported System Center 2012 Configuration Manager source hierarchy. When you migrate boundaries from Configuration Manager 2007, each boundary from the source site migrates at the same time and is added to a new boundary group that is created in the destination hierarchy. When you migrate boundaries from a System Center 2012 Configuration Manager hierarchy, each boundary you select is added to a new boundary group in the destination hierarchy.

Each automatically created boundary group is enabled for content location but not for site assignment. This prevents overlapping boundaries for site assignment between the source and destination hierarchies. When you migrate from a Configuration Manager 2007 source site, this helps prevent new Configuration Manager 2007 clients that install from incorrectly assigning to the System Center 2012 Configuration Manager destination hierarchy. By default, System Center 2012 Configuration Manager clients do not automatically assign to Configuration Manager 2007 sites.

During migration, if you share a distribution point with the destination hierarchy, any boundaries that are associated with that distribution automatically migrate to the destination hierarchy. In the destination hierarchy, migration creates a new read-only boundary group for each shared distribution point. If you change the boundaries for the distribution point in the source hierarchy, the boundary group in the destination hierarchy updates with these changes during the next data gathering cycle.

Planning to Migrate Reports

System Center 2012 Configuration Manager does not support the migration of reports. Instead, use SQL Server Reporting Services Report Builder to export reports from the source hierarchy, and then import them to the destination hierarchy.

Note
Because there are schema changes for reports between Configuration Manager 2007 and System Center 2012 Configuration Manager, test each report that you import from a Configuration Manager 2007 hierarchy to ensure that it functions as expected.

For more information about reporting, see Reporting in Configuration Manager.

Planning to Migrate Organizational and Search Folders

You can migrate organizational folders and search folders from a supported source hierarchy to a destination hierarchy. In addition, from a System Center 2012 Configuration Manager source hierarchy, you can migrate the criteria for a saved search to a destination hierarchy.

By default, the migration process maintains your search folder and administrative folder structures for objects and collections when you migrate. However, in the Create New Migration Job Wizard, on the Settings page, you can configure a migration job to not migrate the organizational structure for objects by clearing the check box for this option. The organizational structures of collections are always maintained.

One exception to this is a search folder that contains virtual applications. When an App-V package is migrated, the App-V package is transformed into an application in System Center 2012 Configuration Manager. After migration of the search folder, only the remaining packages are found, and the search folder cannot locate an App-V package because of this conversion to an application when the App-V package migrates.

When you migrate a saved search from a System Center 2012 Configuration Manager source hierarchy, you migrate the criteria for the search, and not the information about the search results. Migration of a saved search is not applicable from a Configuration Manager 2007 source site.

Planning to Migrate Asset Intelligence Customizations

You can migrate customizations for Asset Intelligence from a supported source hierarchy to a destination hierarchy. There are no significant changes to the structure of Asset Intelligence customizations between Configuration Manager 2007 and System Center 2012 Configuration Manager.

Note
System Center 2012 Configuration Manager does not support the migration of Asset Intelligence objects from a Configuration Manager 2007 site that is using Asset Intelligence Service 2.0 (AIS 2.0).

Planning to Migrate Software Metering Rules Customizations

There are no significant changes to software metering between Configuration Manager 2007 and System Center 2012 Configuration Manager. You can migrate your software metering rules from a supported source hierarchy to a destination hierarchy.

By default, software metering rules that you migrate to a destination hierarchy are not associated with a specific site in the destination hierarchy and instead apply to all clients in the hierarchy. To apply a software metering rule to clients at a specific site, you must edit the metering rule after it migrates.

See Also