Karthik's ConfigMgr & Intune Blogsite

So I finally got the time and opportunity to write a few experiences coming through our ConfigMgr site Upgrades and Migrations so far ...

Before we even go at that level, I just want a make a few notes on the key features which got changed from SCCM 2007 to SCCM 2012 - So, In SCCM 2012 no longer uses mixed or native site modes.  Instead, it supports multiple management points on the same site, where a management point can be configured to support secured HTTPS client communication using PKI, and other management points can be configured to support unsecured HTTP communication.  Load balancing a management point using Network Load Balancing (NLB) is no longer needed. Microsoft does not support performing an in-place upgrade from SCCM 2007 to SCCM 2012.  To upgrade, you must perform a side-by-side migration.  This is due to SCCM 2012 now being a native 64-bit application and changes in site types and site relationships.

In SCCM 2012, you can't change the parent relationship of an active site.  You can make a site a child of another one only when installing it as a new site.  This is due to the new database replication model.

When a CAS site is deployed, a primary site must also be deployed to manage systems and users (normally in the same location as the CAS).  Having a CAS also allows you to deploy additional primary sites.  If a CAS site isn't installed because you are working on a small deployment, then the first site deployed in the hierarchy is a primary site.  You can't install additional primary sites if you don't have a CAS server.  However, you can install secondary sites as child sites of the single primary site server.

A primary site in SCCM 2012 is similar to primary sites in SCCM 2007.  A primary site is no longer needed as a boundary for client agent settings or security or for network bandwidth control.  In SCCM 2012, instead of creating different sites to manage clients, you create different collections.  You can configure custom client agent settings using collection-based targeting.

Secondary sites in SCCM 2012 provide the same functionality as in SCCM 2007.  Microsoft has introduced a new technology in SCCM 2012 that provides the ability to remove secondary sites.  This is the capability of distribution points to implement bandwidth throttling and scheduling.

Secondary sites can no longer be installed from the SCCM setup.  They must be installed from the console.  These are the available options presented by setup.

                                                    

SCCM 2012 sites can now publish site data to Active Directory (AD) trusted forests for improved support to clients there.  Although beta 2 supports clients in workgroups, it does not support clients in untrusted forests.

Upgrading SCCM 2007 to SCCM 2012 is not supported
Due to changes introduced in SCCM 2012, if you want to keep your SCCM data and objects, you have to do a side-by-side migration.  This was common when going from SMS 2003 to SCCM 2007 but now Microsoft provides built-in tools to assist with the migration.  Before you use these tools, you have to have the new SCCM 2012 hierarchy deployed and functioning.  SCCM 2012 introduces no new changes to the Active Directory (AD) Schema from SCCM 2007, so if your AD schema has already been extended for SCCM 2007, you don't have to extend it for SCCM 2012.  Just make sure that you don't have overlapping boundaries in AD from the SCCM 2007 and the SCCM 2012 hierarchies.  On the SCCM 2012 console, there's a Migration page where you'll specify the Source Hierarchy, which is the SCCM 2007 hierarchy that you want to migrate data and objects from.

                                                

Source Hierarchy
For the source hierarchy you specify the top-level site of the ConfigMgr 2007 hierarchy (must be at SCCM SP2 level).  If you have child sites on your SCCM 2007 hierarchy, you can then configure them as additional source sites so you are able to select objects to migrate from them.  You can migrate objects from multiple sites into one SCCM 2012 site, allowing you to consolidate sites.  You can even migrate data from more than one SCCM 2007 hierarchy and from untrusted AD forests, with the limitation of migrating one hierarchy at a time.  Site codes on source and target sites and hierarchies must be unique.  You can't re-use site codes from a source hierarchy to the new one.

Distribution Points
A Distribution Point now has throttling and scheduling features.  The PXE service point role has been moved as a component of a distribution point.  Now Distribution Points can also be installed on workstations that are members of the AD domain.

Secondary Sites
If you need to control SCCM traffic from a site server to another location, you can now use the SCCM 2012 distribution point, which includes throttling and scheduling features.  You would only need a secondary site if you also need to control traffic sent from client systems to the site server, as the secondary site has a Management Point.  The PXE server role is now part of the Distribution Point.  Secondary sites and other system roles have to be manually uninstalled from the SCCM 2007 hierarchy and redeployed on the SCCM 2012 hierarchy. 

Collections
Collections containing both users and systems or devices can't be migrated.  If you have these collections in SCCM 2007 and you need to migrate them, start separating users from systems.  This also applies to linked or sub-collections that may have resources of a type different than the parent.  Empty collections are migrated as an organizational folder of the same name.  If you select to migrate a collection that is linked to another one or has sub-collections, the dependent collections are automatically selected for migration.  Because collections in SCCM 2012 are global data, they are evaluated at each site in the hierarchy.  Plan to limit the scope of a collection after it is migrated (by limiting the members to another collection) to avoid having unanticipated members that could be unexpected targets of advertisements targeting the collection.  Collection-based migration jobs disable advertisements targeting the collection by default, but this option can be disabled during the migration job configuration.

Packages
Packages and Programs, part of Software Distribution, can be automatically migrated (the metadata of the package objects).  For content migration (binary files) see the "Shared Distribution Points" section below.  Most of the time, a package setting includes the package source.  Ensure that all your packages in the SCCM 2007 hierarchy are using a UNC path as the source file location.  App-V packages are converted to applications during the migration but a deployment needs to be created afterwards.  Distribution Point Sharing does not apply to App-V packages.

Server Locator Point
This is no longer a site system role.  The functionality of the Server Locator Point (SLP) has been included in the Management Point (MP).

Software Update Point
If you are going to migrate Software Update objects, you must have first deployed a Software Update Point (SUP) on your new SCCM 2012 hierarchy.  The new SCCM 2012 SUP must contain the same updates as the SCCM 2007 SUP before the migration.  You can use wsusutil.exe to assist you with this.  The migration supports converting Update Lists to Update Groups, migrating Deployments to Deployments and Update Groups, and migrating Software Update Packages and Templates.

Reporting Point
The standard Reporting Point role (Web reporting) is no longer supported in SCCM 2012.  Only the Reporting Services Point, based on SQL Server Reporting Services (SSRS), is supported.  Migrating SCCM 2007 Web reports or SQL Server Reporting Services reports from SCCM 2007 to SCCM 2012 is not supported.  Due to this, you may want to start using SQL Server Reporting Services on SCCM 2007 now because you can export these reports to an RDL file and then import it into your SCCM 2012 hierarchy.  You can copy your standard Web reports in your SCCM 2007 hierarchy to SQL Reporting Services on the same hierarchy to help you prepare.

Shared Distribution Points
One of the migration tools offered by Microsoft is to be able to share Distribution Points (DP) from the SCCM 2007 hierarchy with the SCCM 2012 hierarchy.  This way, you can deploy software to clients that have been migrated to SCCM 2012 without having to push the content of packages to an SCCM 2012 DP, as they can obtain content from the shared SCCM 2007 DP.  Once the migration completes, it is not supported to keep sharing the DPs as a DP can be shared only when the SCCM 2007 hierarchy where the shared DP belongs to remains as the active source hierarchy.  The exceptions to what can be shared from an SCCM 2007 DP are boot images and App-V content.  Note that upgrading an SCCM 2007 DP to SCCM 2012 automatically is supported (except branch DPs) as long as the DP is the only SCCM role on the system and there's sufficient free disk space as used space will be doubled during the upgrade from the old SMSPKG$ share to the SCCM 2012 content library.  You can also manually upgrade an SCCM 2007 DP by uninstalling it, then deploy it in the SCCM 2012 hierarchy and use the new pre-stage content feature to get the content of packages to it.

Upgrading Clients
The minimum operating system requirement for the SCCM 2012 client is Windows XP SP2 (x64) and SP3 (x32).  The documentation may call it an upgrade but really the SCCM 2007 client is not upgraded to the SCCM 2012 client.  The SCCM 2007 client is actually uninstalled, and then the SCCM 2012 client is installed.  The client's inventory data is not migrated so once the SCCM 2012 client is installed, it has to send full inventory data to the SCCM database.  Due to this, plan to migrate the clients in controlled phases as to not to overload your network.  The SCCM 2012 client is now x64 platform but x32 is supported.  The .Net Framework 4.0 is a requirement for the SCCM 2012 client, and it is installed automatically during the installation of the client.  Because the installation of the .Net Framework 4.0 takes some time, you may want to pre-deploy it to the clients. The client's SMS GUID and execution history is kept during the uninstall/reinstall so the system with the new SCCM 2012 client does not rerun advertisements that it has already run.  Client's historical inventory data is not kept.  If you need this historical data, you would need to keep an SCCM 2007 site active after migration until this data is no longer needed.