Walid Hegazy

How To Do :) IT

System center configuration manager 2012 R2 (Part 10) Migration from SCCM 2007

Leave a comment

You already know that there is no in place upgrade from the old SCCM2007 to 2012 what if you had an existing SCCM 2007 …simply you will build your new SCCM 2012 as we did during the last 9 parts and then migrate you data from the 2007 SCCM.

 

image

 

 

In Microsoft System Center 2012 R2 Configuration Manager, the built-in migration functionality replaces in-place upgrades of existing Configuration Manager Infrastructure by providing a process that transfers data from active Configuration Manager 2007 sites. Migration can transfer most data from Configuration Manager 2007.

Data That You Can Migrate to Configuration Manager 2012

Migration can migrate most objects from Configuration Manager 2007 to System Center 2012 Configuration Manager. The migrated instances of some objects must be modified to conform to the System Center 2012 Configuration Manager schema and object format. These modifications do not affect the data in the Configuration Manager 2007 database.

You can migrate the following types of objects:

·         Collections

·         Advertisements

·         Boundaries

·         Software distribution packages

·         Virtual application packages

·         Software Updates:

o    Deployments

o    Deployment packages

o    Templates

o    Software update lists

·         Operating System Deployment:

o    Boot images

o    Driver packages

o    Drivers

o    Images

o    Packages

o    Task sequences

·         Desired Configuration Management:

o    Configuration baselines

o    Configuration items

·         Asset Intelligence customizations

·         Software metering rules

Data That You Cannot Migrate to Configuration Manager 2012

Migration cannot successfully convert some Configuration Manager 2007 objects and data to the System Center 2012 R2 Configuration Manager Database schema during migration. These objects and data must be recreated in the System Center 2012 R2 Configuration Manager database.

You cannot migrate the following types of objects:

·         Queries

·         Security rights and instances for the site and objects

·         Configuration Manager 2007 reports from SQL Server Reporting Services

·         Configuration Manager 2007 web reports

·         Client inventory and history data

·         AMT client provisioning information

·         Files in the client cache

Migration Concepts in System Center 2012 Configuration Manager

The table below is about the concepts and terms that you encounter when you migrate from System Center 2007 SP2 Configuration Manager to System Center 2012 R2 Configuration Manager.

Concept

More information

Source hierarchy

A Configuration Manager 2007 SP2 hierarchy that contains data that you want to migrate. You specify a source hierarchy when you specify the top-level site of a source hierarchy. After you specify a source hierarchy, the top-level site of the destination hierarchy gathers data from the database of the designated source site to identify the data that you can migrate.

Source sites

The sites in the source hierarchy that have data that you can migrate to your destination hierarchy.

Destination hierarchy

The System Center 2012 R2 Configuration Manager hierarchy where migration runs to import data from the site database of a source hierarchy.

Data gathering

The ongoing process of identifying the information in a source hierarchy that you can migrate to System Center 2012 R2 Configuration Manager. Configuration Manager checks the source hierarchy on a schedule to identify any changes to information in the source hierarchy that you previously migrated and that you might want to update in the destination hierarchy.

Migration jobs

The process of configuring the specific objects to migrate, and then managing the migration of those objects to the destination hierarchy.

Client migration

The process of transferring information that clients use from the database of the source site to the database of the destination hierarchy. This migration of data is then followed by an upgrade of client software on devices to the client software version from the destination hierarchy.

Clean up migration data

The process of finishing migration from a source hierarchy by removing information about the migration from the destination hierarchies database.

 

Specify a Source Hierarchy for Migration

From the Administration workspace, expand Migration, and then click Source Hierarchy. click Specify Source Hierarchy.

image344[4]

For Top-level Configuration Manager site server, enter the SCCM 2007 SP2 top-level site name or IP.

Specify source site access accounts that have the following permissions:

·         Source Site Account: Read permission to the SMS Provider for the specified top-level site in the source hierarchy.

·         Source Site Database Account: Read and Execute permission to the SQL Server database for the specified top-level site in the source hierarchy.

image345[4]

Click OK to save the configuration. This opens the Data Gathering Status dialog box, and data gathering starts automatically.

image346[4]

Click Close

image347[4]

It will run by Default every 4 hours to make sure the data is always up to date .

image348[4]

The Migration Job

With the Source Hierarchy data gathering complete we now can move to the actual migration of objects. In order to begin migrating any data from SCCM 2007 we must first create a migration job. There are three types of migration jobs…

  • Collection Migration For migrating the collections and you can select associated items such as packages and advertisements to be migrated along with the collection. Advertisements cannot be migrated outside of the collection migration job. Also, when migrating collections both maintenance windows and collection variables will be transferred.

 

  • Object Migration For migration of all the items that is not a collections.

­­­­­­­­­­­­­­­­­­­­­

  • Objects modified after migration. As the migration of all SCCM 2007 data can be lengthy, depending on the complexity of the originating environment, it is possible that data on the 2007 side may be altered during the course of the migration. This option allows for that data to be updated without having to manually delete previously migrated objects.

It is not required to migrate “all” data at once as multiple jobs of each type can be configured.

Boundaries Migration

From the Migration section on the ribbon click Create Migration Job This will start the migration job wizard.

image349[4]

 

Fill the job Name and select the type as object migration. Click Next.

image350[4]

 

Select the Discovered Boundaries form the data gathering process. Click Next.

image351[4]

Click Next.

image352[4]

Select the Default Security scope. Click Next.

image353[4]

Click Next.

image354[4]

We will choose to Run the job now. Click Next.

image355[4]

Click Next.

image356[4]

Click Close.

image357[4]

Boundaries Migrated

image358[4]

Collections migration

From the Migration section on the ribbon click Create Migration Job This will start the migration job wizard.

image359[4]

Fill the job Name and select the type as collection migration. Click Next.

image360[4]

 

Select the Collections you need to migrate, Mark the Migrate objects that are associated with specified collections, Click Next. (You can also view the collections that can’t be migrated)

image361[4]

image362[4]

The Objects related to our selected collection are automatically selected, you can deselect the objects you don’t need to migrate and Click Next.

image363[4]

Select the Owner site in the Destination hierarchy, Click Next.

image364[4]

Select the Default Security scope, Click Next.

image365[4]

Click Next.

image366[4]

Click Next.

image367[4]

Click Next.

image368[4]

On the Settings, leave the default and Click Next.

image369[4]

Review the Summary, Click Next.

image370[4]

Click Close.

image371[4]

You can review the migctrl.log and smsprov.log log files to monitor your migration.

Updating the package source in Configuration Manager 2007

In SCCM 2007 you could specify the Package Source as local directory or UNC path, but in SCCM 2012 only UNC Path is available so all the migrated packages with local path will give error because source can’t be found or distributed

image372[4]

image373[4]

You can fix this manually if you have few packages but in our case we have too many packages with the same case, luckily there is very nice tool for that called Coretech Package Source Changer

It can be downloaded from here:

CoretechPackageSourceChanger-0.3.zip 244.59 kB

CoretechPackageSourceChanger-0.9.1.zip 246.99 kB

We will run the tool on the sccm 2007, click Configure and fill the old SCCM 2007 data.

image374[4]

Set the package source (Local Drive Source), Set the New UNC Path that you wish as new Package source.

image375[4]

Click on Select Package, Select Desired Package “Migrated monce”

image376[4]

Click Start.

image377[4]

After all the package sources are copied to the new location, we will run the tool again on the SCCM 2012 to fix the data source written within the package configuration

image378[4]

Same way, configure it to connect to the new SCCM 2012,

image379[4]

Just switch the old and the new source locations. Select all the packages, Click Start

image380[4]

If you open any of those packages now you can see that the package source is updated.

image381[4]

Now the source files for the packages can be accessed.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s