Modernize Your PKI → Optimize Productivity → Reduce Risks    |Here’s how to replace Microsoft PKI with EJBCA

  • Home
  • Blog
  • SCCM 2012 – Migration Made Easy – Part 1

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.