Creating migration jobs_Microsoft System Center 2012 Configuration Manager：Administration Cookbook-QQ阅读男生玄幻网

上QQ阅读APP看书，第一时间看更新

Creating migration jobs

Migrating objects (packages, collections, task sequences, and so on) from CM07 to CM12 use a different process than we used from SMS 2003 to CM07. Due to the significant changes in the backend infrastructure, we can no longer attach and upgrade an existing CM07 site server to CM12. To make our side-by-side upgrade process easier, Microsoft created a new migration process that lets us select multiple CM07 sites (even from different CM07 hierarchies if desired) to migrate objects. Migration jobs allow us to pick and choose which objects to migrate.

Getting ready

Before we create a migration job, we must have a configured Active Source Hierarchy. To configure an Active Source Hierarchy, we need valid credentials to see the objects, just as we would for granting someone read rights to objects in CM07. All migration steps are performed in the admin console under Administration | Migration.

From the Active Source Hierarchy subnode, run the Specify Source Hierarchy Wizard and observe the progress in the progress dialog as well as the migmctrl.log file on the CM12 site server. All information related to migration is logged in this file.

Configuring the Active Source Hierarchy will automatically synchronize all computer objects from the source hierarchy (or hierarchies). This process also automatically discovers all child sites of the configured CM07 site. Note that we can only migrate owned objects from the specified source hierarchy. If we need to discover and migrate objects from child sites in the CM07 hierarchy, we must also configure those as source sites. Once we have configured our source hierarchy we can create multiple migration jobs.

How to do it...

To create a new migration job, perform the following steps:

In the CM12 admin console, navigate to Administration | Migration | Migration Jobs and click on Start in the ribbon to start the New Migration Job wizard.
Enter a unique job name, and select Object migration for the job type.
Select the desired objects from the dialog:
Select the CM12 site that will own the migrated content (this is usually your CAS or single primary site).
Select the security scope to apply to the migrated objects. Create a new one if desired.
On the Settings tab, specify when the job should run, as well as advanced settings such as overwrite previously migrated objects, and transfer organizational folders:
After the job has been successfully created, we can monitor the Summary page for the job, as well as view the migrated object(s) state with the Objects tab. If required, view the migmctrl.log for additional troubleshooting information.

How it works...

The migration tool uses the credentials specified in the active source hierarchy configuration to migrate the desired object to the CM site. In this example, we selected specific objects to migrate. Notice that in the object selector dialog, we can identify which objects have already been migrated.

Note

CM users in the default roles of Full Administrator, Infrastructure Administrator, and Operations Administrator have security rights to create migration jobs.

There's more...

In addition to the object-based migration we just performed, we can also select a collection-based migration. When we specify a collection-based migration, selected collections and all objects required for those collections are migrated by default. We can clear a checkbox in the wizard so that only the collections are migrated, if desired. When we select a subcollection for migration, all the collections that are required to traverse to the root are also migrated.

Also, notice from the previous image that we can determine which collections have been migrated, which collections are device collections, and which collections are user collections. In CM12, a collection cannot contain both devices and users. Click on the View Collections that Cannot Migrate… button to view collections that meet one or more of the following criteria:

Mixed Query Collection is a collection that contains a mix of users and devices, or custom collection types.
Mixed Collection Hierarchy is a collection that has a parent collection of a different type
Multiple Collection Limiting is a collection that is limited to multiple collections using custom WQL
Collections that are a collection limited to any collection that meets the above criteria cannot be migrated

Also, notice from the previous image that some collections will be migrated to a folder instead of a collection. CM12 does not support nested collections. The migration process will ensure that collections are migrated and organized similarly to the CM07 configuration, but will not be exact. Always run the migration process in a test environment before running migration jobs in production.

Note

It's important to know that for each new package we create (software package, update package, image package, and so on), the source will automatically be inserted into the CM content library (by default, C:\SCCMContentLib) as soon as the package is created. If you run migration jobs in your test environment, ensure that you have a disk large enough to contain all files from your selected package sources. CM12 leverages a single instance source for all files which will help, but when you migrate a large number of packages, you may completely consume the hard drive(s) of your test environment simply by running the migration tool.

After we have performed object collection-based migration, we still need to migrate the actual clients in the migrated collection. We can leverage any type of client installation to meet our requirements.

Using multiple sites

As you will almost certainly be flattening your CM07 hierarchy to CM12, keep in mind that you can migrate objects and collections from multiple primary sites to a new single primary site (or central administration site) as part of your consolidation efforts, and simply assign the proper security scope to the objects.

Re-migrating objects

We can use the migration tool to re-migrate objects that were previously migrated. This is important if an object has changed in CM07,for example, package source, command-line switches, or even package source version.

DP sharing

We can configure distribution point sharing to allow CM12 clients to access CM07 distribution points to obtain content of migrated packages during our infrastructure transition to CM12. Once our migration is complete, we can use the migration tool to migrate distribution point shares (that have no other CM07 role on them) to CM12, without the need to re-send existing content to the newly-reconfigured CM12 distribution point.