SCCM to SCCM 2012 Migration

http://www.css-security.com/author/rdelserone/



SCCM 2012 – Migration Made Easy – Part 1

As we all wait in anticipation for Configuration Manger 2012, there are a number of concerns that present themselves from an administrator’s perspective. One of those primary concerns, and the topic of this post, is the lack of upgrade path from SCCM 2007. At first glance it seems like a show stopper as companies may balk at a whole new infrastructure while already having one already in place for SCCM 2007. However, as Microsoft has made giant strides forward in terms of Systems Management and Hierarchy Simplification with ConfigMgr 2012, they have also reduced the pains of migration immensely. With the release of ConfigMgr 2012 RC some of you may be gearing up for testing, with that in mind the first part of this three part blog will highlight the requirements for preparing a migration along with any caveats and information pertaining to the migration process.

ConfigMgr 2012 Hierarchy

In order to properly migrate an SCCM 2007 environment, it is necessary to have the ConfigMgr 2012 Hierarchy planned and in place prior to the migration. All roles and required services will need to be installed and operating properly. This includes the configuration of the SUP. If the SUP is not configured, conversion of Update Lists to Update Groups as well as Update Deployments to Deployment and Update Groups will not take place.

As ConfigMgr 2012 has several additional abilities over SCCM 2007, throttling to DPs for example, it is reasonable to believe that a consolidation of sites may need to occur. Migrating multiple 2007 sites into one 2012 site is supported allowing for consolidation of the SCCM Hierarchy during migration. It is also possible to migrate multiple SCCM 2007 Hierarchies; however they must be performed one at a time.

ConfigMgr 2007 Environment

The current ConfigMgr 2007 environment will need to be at a minimum of Service Pack 2 in order for the migration to take place. Any previous version will not be supported.

Migration Account

A domain account will be necessary to connect to the ConfigMgr Site Database(s) as well as the SMS Provider. This account should be created as a service account and will require the following access:
• Read & Execute Access to the SCCM 2007 Database(s)
• Full Access to the SMS Provider

Active Directory

The requirements for ConfigMgr 2012 in regards to Active Directory changes are virtually the same as with 2007. Therefore, if the Schema in your environment was extended for 2007, all that is required is adding access permissions to the System Management container for the new Server Name(s) for ConfigMgr 2012.

Networking

SCCM 2012 places additional focus on boundaries. The boundaries and boundary groups are used to assign access to the Role Based Management as well as applicable distribution points and so on. It is vital to eliminate any overlapping boundaries particularly in regards to Active Directory Sites.

Secondary Sites

Secondary sites cannot be migrated. The sites must be uninstalled from SCCM 2007 and re-installed in ConfigMgr 2012. This is primarily because Secondary sites now use SQL Replication instead of file replication. There are no databases for secondary sites therefore the migration utility has nothing to migrate. Installing a secondary site using the ConfigMgr 2012 media will install SQL Express in order to facilitate this new configuration.
However, if secondary sites were being used to throttle network traffic to different locations this can now be accomplished with standard Distribution Points.

Client Deployment

I place information regarding client deployment as part of the requirements for migration only because the ConfigMgr 2012 client requires .Net Framework 4.0. While the installation of the client will also install this prerequisite it would be more feasible to install (if not already part of your current OS configurations) to install the framework prior to the client upgrade/deployment.

Please stay tuned as Part 2 of this three part blog will provide information on the types of objects and information that can be migrated, how they will present themselves in the 2012 environment, and what items cannot be migrated.

SCCM 2012 – Migration Made Easy – Part 2

In Part 1 of this blog series I presented an overview of the requirements for preparing a migration from Configuration Manager 2007 to 2012.  With that information in hand I believe that you should have a general understanding of the pre-requisites necessary to begin your migration process.

Migration Objects

We’re going to cover the types of objects that can be migrated and how they are translated to Configuration Manager 2012.  Bulleted below are all of the objects that can be migrated from ConfigMgr 2007 to ConfigMgr 2012.

• Boundaries
• Collections
• Software Packages
• Virtual Application Packages
• Software Update Deployment Packages
• Software Update Deployment Templates
• Software Update Lists
• Operating System Boot Images
• Operating System Driver Packages
• Operating System Drivers
• Operating System Images
• Operating System Install Packages
• Task Sequences
• DCM Configuration Baselines
• DCM Configuration Items
• Asset Intelligence Catalog
• Asset Intelligence Hardware Requirements
• Asset Intelligence Software List
• Software Metering Rules

Boundaries

The boundary migration process allows for a direct one to one migration of each boundary that is specified within a ConfigMgr 2007 source site.  As ConfigMgr 2012 utilizes boundary groups in conjunction with standard boundaries, the migration process will create each boundary and automatically create a boundary group (for the corresponding source site) to which the migrated boundaries will become a member.  Figure 1 shows three boundaries that have been migrated from a single ConfigMgr 2007 Site and Figure 2 shows that a single boundary group was created containing 3 boundaries.
Figure 1 – ConfigMgr 2012 Migrated Boundaries

Figure 2 – ConfigMgr 2012 Auto-Created Boundary Group

Collections

The migration of collections is by far one of the most useful processes of the utility for a couple of reasons.  First and foremost, the collections that are selected for migration are automatically scanned by the migration utility to determine if there are any software packages, advertisements, software updates, and or task sequences that are associated with the selected collection(s).  If any or all of the above are identified, the utility will provide the option to migrate those specifically referenced items to go along with the collection(s).
If you notice, “advertisements” are not present on the default list of migration objects that were previously mentioned yet are part of the collection migration.  This is not in error.  The migration of an advertisement is only an option during the collection migration, and only if an advertisement is targeting at the collection being migrated.  The purpose behind this, which is my opinion and not a published fact, is that an advertisement cannot be migrated unless its targeted collection and package are present.
Secondly, if you have a collection structure utilizing empty collections for place holders and organization, the migration utility translates those collections into organizational folders.  While I too was leery at first, after seeing the migration object translation I can say the process is very efficient.  The screen shot in Figure 3 shows the collections being selected for migration, and Figure 4 shows what those collections look like after migration.
Figure 3 – Collection Migration Wizard

Figure 4 – Migrated Collections

Important Note:  Collections containing both users and systems cannot be migrated.  It is recommended that mixed collections be separated prior to the migration task.

Software Packages

Software packages are obviously a no brainer in terms of objects available for migration.  All package options and programs are maintained during migration.  However, the migrated packages are not translated into the new “application model.”  Figure 5 shows two migrated packages and their corresponding program count.
Figure 5 – Migrated Software Packages

Microsoft has conveniently designed a Package Conversion Manager (PCM) to assist in turning your migrated Software Packages into ConfigMgr 2012 Applications.  For more information on the PCG navigate to the following link:
http://technet.microsoft.com/en-us/library/hh531519.aspx
One caveat is the source content location.  In order for the software packages to be migrated, all source file locations must utilize a UNC path.  Any package that is using a local drive as a source location will fail to migrate.

Software Updates

As mentioned in Part 1 of this blog it is necessary to have the desired ConfigMgr 2012 infrastructure installed and configured to properly execute a migration.  I must stress the importance of this in regards to migrating software updates.  While it is probably evident that Software Update point(s) are required prior to Software Updates migration, what needs to be emphasized is the Product Catalog and Update languages must match the ConfigMgr 2007 configuration perfectly and be successfully synchronized.  If a single update is missing from an entire update package the migration of that package will fail.
Important Note:  All custom updates, locally published SCUP updates, will need to be republished as they cannot be migrated.
Software update packages as well as update template still exist within ConfigMgr 2012.  Update Templates will need to have the duration settings reconfigured as it does not migrate. The migration process will convert Software Update Lists into Software Update Groups and a Software Update Deployment will be converted into a Deployment and corresponding Update Group.

Operating System Deployment Objects

During the migration of OSD objects the Drivers, Driver Packages, OS Images, and OS Install Packages (now called OS Installers) are migrated exactly as they were in ConfigMgr 2007.  The lone exceptions to the rule are the Boot Images.  While they are listed as objects that can be migrated, there some details that need identified.
The first and most impactful item is that customizations that were made to boot images in ConfigMgr 2007 cannot be migrated.  Now that some of you are screaming on the inside let me explain why.  The actual boot image WIM file is not what is being migrated.  The drivers that have been injected in the ConfigMgr 2007 boot images are being automatically injected into similarly named boot images being created from the boot WIM files from the AIK on the ConfigMgr 2012 server.  On a positive note, a good number of customization can be made to boot images through the new GUI in ConfigMgr 2012 such as Pre-Execution hooks and associated files.
Task Sequences are migrated almost identically as well.  The only change that will be made automatically is when a client installation package is being used; it will be replaced with a reference the pre-created ConfigMgr 2012 Client package.

DCM Objects

There are two items that warrant a brief outline in terms of DCM object migration.  First, ConfigMgr 2007 Configuration Packs can be imported into ConfigMgr 2012.  The Configuration pack is automatically converted to be compatible.  Second, any un-interpreted configuration items WILL NOT be migrated nor can they be imported.

Asset Intelligence & Software Metering

There are no significant changes to either Asset Intelligence or Software Metering.  Therefore, the migration of these two categories is basically seamless and will appear in ConfigMgr 2012 just as they did in 2007.

Non-Migration Objects

The following objects cannot be migrated…

• SCCM Queries
• Site Security and Instance Rights
• Object Security and Instance Rights
• SCCM Reports
• Client Inventory
• Client History Data
• AMT Provisioning Data
• Client Cache Files
• Boot Image Customizations
• Secondary Site

Please check back for Part 3 which will cover the actual migration process including creating migration jobs, what those migrated items look like in the new console, and some items around migration cleanup.  And as always I hope this information is beneficial to all those looking into Configuration Manager 2012.

Article by Rick Delserone

Senior Consultant
An Authority on Configuration Manager
Posted on: Wednesday, May 16th, 2012

inShare2

SCCM 2012 – Migration Made Easy – Part 3

In Part 1 we discussed the requirements overview on preparing for a migration and in Part 2 we covered the types of objects that are available for migration and the exclusions. In this final write up in the series we will go through the process using the migration utility that has been hyped up by Microsoft within Configuration Manager 2012.

Configuring the Source Hierarchy

The first step in configuring the migration process is to “Specify Source Hierarchy.” This is both crucial and required in order to move forward with the migration plans. Specifying the Source Hierarchy allows ConfigMgr 2012 to gather all of the necessary data from SCCM 2007 in order to identify the objects that can be migrated.

Let’s go ahead and walk through this process. All of the migration tools are located under the administration section of the console.

Expand the Migration folder to reveal three options.

• Source Hierarchy
• Migration Jobs
• Distribution Point Upgrades

Either right-click on “Source Hierarchy” or from the ribbon, select “Specify Source Hierarchy.”

The first page of the Source Hierarchy wizard is now presented and there are a number of things to be configured. In order to properly acquire all of the information from the SCCM 2007 environment, it is necessary to start by specifying the top most level primary site. In most cases, the top level primary site in an SCCM 2007 hierarchy is a Central Primary.

With the Top-level Configuration Manager 2007 site server specified, the access accounts will need to be configured. As noticed in the screen shots, the necessary permissions have been laid out already.

• Read access to the SMS Provider.
• Read & Execute on the source site SQL Server

As with most SMS Providers access the account being specified will require Distributed COM Users permissions within AD. Microsoft outlines on TechNet that when specifying a computer account this permission is required, but I would recommend that you validate this access even when using a domain user account.

Once all of the accounts have been entered and “OK” has been selected, the data gathering process will immediately start. A progress window will appear showing the steps of data gathering.

If an error occurs during the data gathering process, nine times out of ten it is permission related. The ratio may indeed be even higher but we’ll go with 90% for now. Once the initial data gathering process has been completed the status of the Source Hierarchy will show a status of “Ready for next gathering process.”

The Migration Job

With the Source Hierarchy data gathering complete it is now possible to move into the actual migration of objects. In order to begin migrating any data from SCCM 2007 we must first create a migration job. From the Migration section either right-click or use the ribbon and select “Create Migration Job.”  This will start the migration job wizard.

There are three types of migration jobs…

• The Collection Migration option is the most comprehensive. When using this type of migration job it is possible to select associated items such as packages and advertisements that are targeted at the collections in question. Advertisements cannot be migrated outside of the collection migration job. Also, when migrating collections both maintenance windows and collection variables will be transferred. However, AMT client provisioning data cannot be migrated.
• Object Migration will allow for the migration of all the items outside of collections. Please refer to Part 1 of this blog series for a list of the objects available for migration.
• The last option, Objects modified after migration, has a rather specific purpose. 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.

The next step in the process is to select the collection(s) that will be migrated. It is not required to migrate “all” collections at once as multiple jobs of all types can be configured. The number of jobs will, by default, increase with the complexity of the SCCM 2007 environment as well as with the number of Sites and Security scopes within ConfigMgr 2012.

As you can see above, all of the collections will be displayed as they are laid out in SCCM 2007. Simply select all of the collections that are to be migrated. If the source environment has an immense number of collections, click the search button to display a complete list which can be sorted and narrowed to more effectively locate the desired collection. If migrating associated data with the collection is not required, uncheck the Migrate objects that are associated with the specified collection option at bottom of the wizard page.

As you browse through, it might be possible that the desired collection does appear in either the default list or in the search area. If this occurs, select View Collections that Cannot Migrate. There are 4 scenarios in which a collection will not be available for migration which are outlined below.

• Mixed Query Collections – collections containing users and computers                                                                                                                                                                                                                                                                                                     —This can be eliminated by segregating the mixed collections on the SCCM 2007 side prior to the migration (which is recommended by Microsoft)
• Mixed Collection Hierarchy – collections where the parent and child collections are of different sites
• Multiple Collection Limiting – collection with limited by more than one other collection
• Limited to Blocked Collection – collection that is limited by a collection that cannot be migrated.

Object Selection

Once all of the collections have been selected for this particular migration job, the next page of the wizard will take us through the object selection (assuming it was chosen to do so). This page will only display the objects that are directly linked to the selected collections.

This page is very self-explanatory in that, if there are associated objects to the collections they can be migrated as part of the same job. A few additional notes…

•  In order to migrate the advertisements their associated packages must also be migrated
• Migrated advertisements are not enabled by default (an option to enable is available thought it is not a Best Practice)

Content Ownership

When migrating objects from SCCM 2007 it is necessary to specify the ConfigMgr 2012 content owner. The content owner, for lack of a better description, is the site from which you want the data to originate. If the migration is a single site, this section does not require any additional discussion. However, if there are multiple hierarchies being utilized in 2012, the desired content owner will need to be specified to allow for the proper assignment of data.

Security Scope

The next option is the assignment of a security scope. The security scope is part of the new role based administration model to assign the appropriate rights to the migrated objects based on the defined scopes. As we will not be getting into the detailed overview of Role Based Administration we will just move forward and assume the default scope will be selected.

Collection Limiting

This step of the process is designed to provide you with the ability to limit collections that can in scope once migrated. Let me explain a little further. In ConfigMgr 2012 all collections are global. The means that a collection created from any part of the hierarchy is available to all sites. So, for instance, if you were to migrate a collection from a child primary site that contains “All Windows 7 Systems” from that site when it is brought into the ConfigMgr 2012 environment that collection would now have all of the Windows 7 systems from the entire hierarchy. The migration tool recognizes these issues and allow you to provide the correct collection limiting (limiting is required in 2012).

Site Code Replacement

This step is simple enough. If you have collections that contain queries using the Site Code from the SCCM 2007 environment they will be replaced with the correct site code from the ConfigMgr 2012 environment. This is an automatic process and does not require any configuration.

Reviewing the Migration Job

Now that you have gone through most of the migration job wizard there will be a window providing a review of the configurations and provides some information around the objects that have been chosen to migrate. It also provides information surrounding actions that might need or should be taken prior to the initialization of the migration job.

A new, and useful, feature of the review page is the ability to save the presented information to a file. This obviously will allow the proper tracking of tasks and migration processes for review as well as providing a record of the pre-migration recommendations. I recommend saving all of the files during your migration process as too much information is never a bad thing.

The Settings Page

The settings page of the wizard is where the scheduling of the migration job is configured as well as the defining of actions that will occur while the migration job is running.

The first section of this page is for the scheduling of the migration job. There are three options and they are all self-explanatory…

• Do not run the migration job
• Run the migration job now
• Schedule the migration job

The second section outlines how to handle objects that have been previously migrated. The default selection is Do not migrate updated options which would be my general recommendation. When selecting the collections or objects to migrate the status of those items are provided, (migrated | not migrated), and those that have been migrated should be skipped. If indeed there are items that have been updated since a previous migration job has been run then use the Objects modified after migration job to update them.

Under the additional settings the Transfer the organizational folder structure for objects from Configuration Manager 2007 to the destination site has been pre-selected. If however, you don’t want any of the folder structures to come over during migration, simply uncheck this box. Some organizations may be using this migration as a reason to re-organize data and how items in the ConfigMgr environment are structured so they would chose not to migrate the folder structure. I, on the other hand, find it quite useful.

The last option is one we touched briefly on earlier which enables programs for deployment once migrated. This option needs to be weighed carefully as the ConfigMgr 2012 environment should be set up completely before using it. I make that statement with confidence as in the event an advert and program is enabled on migration and is targeted at a collection that has increased in scope, a number of systems that were not originally intended to run this program may do so. It is not difficult to go through and enable the programs after migration which also provides time to review what systems/users will be targeted.

The last pages of the wizard are ones that configuration manager administrators are very familiar with…summary, progress, completion. This is why I don’t think we all need to review them.

Summary

We have now reached the conclusion of the Migration Made Easy blog series. As always, I sincerely hope that the information that I have included here has been useful, at least in small part, to assist in your upcoming migration.