October 8, 2015 at 13:44Migration of SCCM 2007 to SCCM 2012 \ 1511
For a long time I "dreamed" to write on this topic, all the laziness was ... Stock up on cookies, this is for a long time. There may be some errors - let me know if you find them, please. It is difficult to subtract ~ 35,000 characters. I intentionally do not want to divide the post into several parts, so all the information collected by me will be in one place.
Upd. You can migrate from 2007 to 1511 directly, without 2012. And in general, everything written in this article is also true for migration to 1511.
1. Architecture
The SCCM 2012 hierarchy consists of three types of servers: Central Administration Site, Primary Site, and Secondary Site. Creating a four-level hierarchy like the existing SCCM 2007 hierarchy using SCCM 2012 is not possible because the SCCM 2012 hierarchy is three-level. The relationship between the servers in the Parent-Child hierarchy, the CAS server is at the head of the hierarchy, the Primary Site servers are subordinate to it, and the Secondary Site servers are subordinate to them. Starting from version 2012 SP1, stand alone Primary can be “converted” to the SCCM hierarchy, so if you have less than 90,000-95,000 clients in the hierarchy, there is no sense in the SCCM 2012 hierarchy with a CAS server.
The source and destination SCCM hierarchies cannot contain the same site codes, so all site codes must be changed during migration.
Only SCCM 2007 servers with installed SP2 or later can participate in the migration.
Extending the Active Directory directory service schema to install the SCCM 2012 hierarchy in parallel with SCCM 2007 is not necessary (if the schema extension was done to install SCCM 2007).
1.1. Central Administration Site The
CAS server is the main SCCM hierarchy server. The SCCM 2012 hierarchy cannot contain more than one CAS server, in addition, it must be installed first in the hierarchy (not relevant after 2012 SP1). The CAS server does not support all roles, since it is not used to interact with clients.
The CAS server is used to manage the entire SCCM infrastructure and is the only server on which information about the entire infrastructure is available, for example, assign discovery methods for Primary Site servers or manage administrator access roles to the SCCM hierarchy.
The CAS server supports up to 100,000 clients in the SCCM infrastructure if the SQL server has an enterprise or datacenter edition and up to 50,000 clients if the SQL server has a standard edition.
1.2. Primary Site
More than 25 Primary Site servers cannot be connected to the CAS server. Primary Site server is responsible for interacting with clients and Secondary Site servers, consolidates the received data and sends them to the CAS server.
Primary Site server supports up to 10 client management points, each of which supports up to 25,000 clients.
A Primary Site server can only manage clients connected directly to this server or clients connected to its child servers.
Primary Site server supports up to 250 Secondary Site servers and 250 Distribution points. The Primary site server can transmit data to the Secondary Site server and to Distribution points on a schedule and / or can limit the channel bandwidth used by it.
Primary Site server supports up to 50,000 clients if it coexists with SQL server and up to 100,000 clients if SQL server exists separately from Primary Site server. Edition of the SQL server is not important, unlike the CAS server. In addition, Secondary Site servers do not increase the limit of clients connected to the Primary Site server. If the CAS server has a database installed on the SQL server of the “standard” edition, the limit of clients connected to the Primary Site server and its child servers is 50000. The
Primary Site server cannot contain child Primary Site servers.
1.3. Secondary Site and Distribution Point
The migration of the Secondary Site servers is as follows - the removal of the original Secondary Site server, waiting for the next cycle of information collection, if the successful removal of the Secondary Site server is confirmed after the information is collected, the Distribution Point is installed and all data that was on the original Secondary Site server is imported into it.
For the migration of Distribution Point, it is necessary that the operating system supported by SCCM 2012 is installed on the server and the free space is two times the size of all packets on the Distribution Point.
Using Distribution Point and the Secondary Site server, you cannot manage the SCCM infrastructure, all administrative actions must be carried out on the CAS and Primary Site servers. The main task of Distribution Points and Secondary Site servers is to reduce file traffic on the network and consolidate data from clients for transmission to the parent Primary Site server.
The Secondary Site server cannot be used to assign SCCM site code to clients. If boundary groups are used to assign sites to clients and the client is assigned a Secondary Site code, the client is assigned the code of the parent site of this Secondary Site server.
Secondary Site server supports up to 250 Distribution points. Distribution point supports up to 4000 customers.
Secondary Site server supports up to 5000 clients.
2. The ability to migrate various types of objects
Unfortunately, I did not understand how to insert a plate, so the picture.
Collection migration - when performing a collection migration, all objects automatically migrate (this function can be disabled when creating a “migration job”) that are associated with this collection (except for those that cannot be migrated). Re-migration of collections is identical to the original.
Migration of objects - when performing the migration of objects, you must select all the objects that should participate in the migration.
However, there are some limitations. Collections should contain only users or only computers. Empty collections cannot be migrated and a folder will be created instead. If there are deployments including all subcollections aimed at an empty collection during migration, a new collection will be created containing all subcollections and deployments that will be aimed at it. Collections containing an unknown computer object will be migrated, but this item will be removed from the collection. Migration of linked collections is not supported (linked collections - collections containing users and computers).
The following objects and data cannot be migrated: queries, reports, customer inventory data, Intel AMT data, modified boot images, SCCM 2007 agent cache data, client history, security settings, mof files.
Report migration is not possible using SCCM. However, you can use the SQL Server Reporting Services Report Builder utility to migrate reports. To do this, you need to convert all reports in the source infrastructure so that they use SQL mechanisms. To do this, you need to install the SQL Server Reporting Services role on the databases, and then configure the access of the original SCCM hierarchy to this service (through the SCCM console, server management, role management), convert all reports to SQL reports (through the SCCM console, select the necessary reports and Click “Copy Reports to Reporting Services”). Further, reports are migrated using SQL Server Reporting Services Report Builder or the ReportSync utility.
Request migration is not possible using SCCM. It is necessary to recreate queries or export queries as “mof” files from the SCCM 2007 hierarchy and import them into SCCM 2012, this is done using the SCCM console of the source and target hierarchies.
Mof files cannot be migrated using SCCM. You must reconfigure them in the new hierarchy. The mechanism for interacting with mof files has not changed, however, changes to existing mof files may be required for full compatibility with SCCM 2012.
3. SQL server requirements
For all server roles, 64-bit editions of SQL server and windows authentication to access the database must be used.
The SQL Server Replication component is not used to replicate data between SCCM servers. This process takes place by SMS Provider. If you need to generate and view reports, you need to install the SQL Server Reporting Services component on the SQL server.
For each SCCM server, a separate instance of the SQL server must be used, and the Collation parameter of the SQL server must be the same on all servers in the SCCM hierarchy. The only Collation supported is SQL_Latin1_general_CP1_CI_AS.
For correct operation, the SCCM 2012 hierarchy server site requires that the SQL server support windows authentication. Since mixed mode supports windows authentication, its use on SQL servers of the SCCM hierarchy is possible. Thus, it is possible to use mixed or windows authentication, "Best practice" - Windows mode.
You must use the following SQL server memory consumption settings:
- if the SQL installation and the SCCM server coexist, limit the SQL server memory consumption to 50-80% of the server RAM.
- in case of separate installation of SQL and the SCCM server, limit the memory consumption of the SQL server to 80-90% of the server RAM.
- Primary Site server and CAS server require backup of 8GB of RAM on the SQL server, and Secondary Site server requires backup of 4GB of SQL server RAM.
4. Network infrastructure
requirements gallery.technet.microsoft.com/SCCM-2012-R2-Network-scheme-b01fd985
This scheme without CAS role, I did not find another scheme. But I think 99% of those reading this will do it.
5. Preparing for migration
Since the SCCM 2012 hierarchy is different from the SCCM 2007 hierarchy, it is necessary to reorganize the existing SCCM 2007 structure and make it more flat. To perform the migration, you need an account with “Read” access to all objects of the SCCM 2007 hierarchy and an account with “Read” and “Write” rights to the database, in addition, you must open the following ports: 135, 445, 1433 (all TCP).
To migrate SCCM 2007 to SCCM 2012, you need to select the source server in the 2007 infrastructure, it must be the “highest” server of the existing hierarchy, because after selecting the source server you cannot migrate all objects, servers and clients that are “above” the selected server.
Since SCCM 2012 does not support the creation of subsidiary Primary Site servers from Primary Site servers, it is impossible to migrate such a hierarchy, it is necessary to consolidate all the clients of all subsidiary Primary Site servers in the existing hierarchy into the corresponding parent Primary Site servers in the new hierarchy. Consolidation of clients occurs during the "migration" of the client. Prior to the direct migration, clients are managed by the SCCM 2007 hierarchy. When migrating a client, it should receive the code of its parent site SCCM 2012 when installing the client (via the command line key). Assigning clients the corresponding site codes of their parent Primary Site servers is consolidation.
All servers in the hierarchy that will participate in the migration must be upgraded to SCCM 2007 SP2 or higher.
Secondary servers cannot be migrated, it is necessary to remove the server and install Secondary server on it from the SCCM 2012 infrastructure (possibly together with saving data to the Distribution point).
For uninterrupted service provision, SCCM infrastructures can share existing Distribution points. The sharing of existing Distribution points is set up at the initial stages of migration. For this, an account with “Modify” rights to the SCCM object is required.
To migrate SCCM objects, you need to prepare public folders for migration, those that give access to public folders to accounts that will be responsible in the new hierarchy for access to public folders. In addition, you need to reconfigure SCCM objects so that they use the UNC path to the shared folder, this will allow you not to reconfigure the objects after migration.
Collections cannot be mixed; they cannot contain computers and users at the same time. All mixed collections need to be reorganized into collections that contain only users and only devices. In addition, collections that contain mixed collections and collections containing unknown computers cannot be migrated. Empty collections will be migrated as folders.
To migrate reports, you must install the SQL Server Reporting Services (SRS) role and convert all reports to SRS format. Report migration using SCCM is not possible, but it is possible using SQL.
Client migration avoids the redistribution of packages, this is because when migrating packages, SCCM 2012 stores information on the package number of SCCM 2007 in the database, and the client, in turn, saves data about installed packages during migration.
To migrate clients, you must create and distribute packages for installing SCCM 2012 clients in the SCCM 2007 hierarchy. In addition, you can distribute SCCM 2012 clients in any way possible, since client migration is not possible in place upgrade.
6. Preparing the target system for migration
The target hierarchy should be deployed from top to bottom: the central site should be deployed first, after it its child sites will be deployed, and then the servers and distribution points of the lower level should be deployed. If at some sites it is impossible to deploy the server from a new hierarchy, you must use the opportunity to create a distribution point for content on the client system.
It is possible to transfer content according to a customized schedule, that is, without loading the channel during business hours, or using the “Prestage Content File” and transfer it to the site offline. The “Prestage Content File” is created on the central site of the hierarchy and contains all the necessary packages.
After the hierarchy is expanded, testing is necessary. Check data replication between sites in the hierarchy, check the health of client management points and content distribution points. Check the ability to connect clients to each client management point in the hierarchy, the ability to send and receive customer data. Check the health of the deployments and all data distribution points in the hierarchy.
The next step in preparing the target infrastructure should be the “Default Client Settings”, “Boundary”, “Boundary Group”, “Security Scope” and Administrative Accounts settings. In addition, you need to create 2 accounts to access the old hierarchy and to access the database of the old hierarchy (you may need to create more accounts if you cannot connect with the same credentials to access different hierarchy sites and different database servers). “Security Scope” and “Boundary Group” are needed to reassign rights to manage content and indicate the location of content in the new hierarchy.
At the beginning of the process, the new system indicates the addresses of SCCM 2007 servers and the credentials for accessing them, starting from the highest to the lowest server in the hierarchy, all the servers that will participate in the migration are indicated. Then the choice is made which data needs to be transferred from the old system to the new one.
In fact, migration is a copy of objects from the source hierarchy to the target. Objects are migrated using “migration jobs”. Each “migration job” can migrate any number of SCCM objects. You can re-migrate SCCM objects if necessary (for example, the object has been modified). The order in which objects are migrated is not important. Roles or SCMM Primary Site servers cannot be migrated (content distribution points and Secondary Site servers can be migrated).
To copy objects from the source hierarchy to the target, it is necessary to collect data about the source hierarchy. In the process of collecting data, a relationship is established between hierarchies. Data is collected by reading information about objects and their dependencies, collections, sites and clients from the database of the target hierarchy.
To migrate clients, you must use the source hierarchy console or other means, as clients are migrated by in-place client updates. The mechanisms for installing the agent on the client computer did not change in SCCM 2012. The update can be initiated by a startup script, group policy, or installed as a package from the server in the source hierarchy. Before the client is migrated, it is managed by the original hierarchy.
The SCCM 2007 client cannot be controlled by the SCCM 2012 hierarchy and vice versa, the SCCM 2012 client cannot be controlled by the SCCM 2007 hierarchy. In the case of improperly configured site boundaries in the SCCM hierarchies, clients that receive the wrong site code (those site codes from a "different" hierarchy) will not be managed until they are assigned the correct site code. Prior to the start of migration, all clients are managed by the SCCM 2007 hierarchy; as clients migrate, they are transferred to SCCM 2012.
After the migration of clients and objects is complete, you can proceed with the migration of content distribution points. It occurs using the CAS console of the target hierarchy server (the “Migrate Distribution Point” task). When you migrate a content distribution point, binary files are updated and file storage is migrated. For the migration of the storage, it is necessary that the server has free space 2-2.5 times the space occupied by all SCCM 2007 packages on this server, since the SCCM package storage is being rebuilt.
Migration of Secondary Site servers is not possible. Instead, an “in place” upgrade of the Secondary Site server occurs only to the point of distribution of the content of the target hierarchy (this is a technical limitation of the system introduced by Microsoft in connection with changes in the mechanisms of packet replication in the hierarchy and improvements in the mechanisms for controlling packet replication traffic), preserving all packages. For the migration of the storage, it is necessary that the server has free space 2-2.5 times the space occupied by all SCCM 2007 packages on this server, since the SCCM package storage is being rebuilt.
Migration of Primary Site servers is not possible; instead of migration of Primary Site servers, objects are migrated from the Primary Site server of the old hierarchy to the CAS (or the corresponding Primary Site server) of the new hierarchy. Thus, for the "migration" of the Primary Site server, you must have the target SCCM 2012 infrastructure and a place to store packages equivalent to the space spent on the source server. Despite the fact that the CAS server cannot serve clients and cannot be a distribution point for content, it must be available on it to store all hierarchy packets.
Useful utilities:
ReportSync - utility for migrating reports from the SCCM 2007 hierarchy to the SCCM 2012 hierarchy. Available for download on the Internet.
RegKeytoMof - utility for creating mof files for inventory of non-standard registry settings. Available for download on the Internet.
ExtractContent - utility for unpacking the contents of the "Prestage Content" file. It comes bundled with SCCM 2012 and is located in the “BIN” folder of the SCCM
CMTrace distribution kit - a utility for viewing logs. It comes bundled with SCCM 2012 and is located in the Tools folder of the SCCM distribution.
Notepad - a utility for viewing logs.
7. Approximate migration process
Migration takes place in stages. You can proceed to the next stage of migration only after the complete completion of the previous stage. In the event of a failure of the target hierarchy, a painless return of the IT infrastructure to the original hierarchy is possible, since migration does not imply any changes that impede the functioning of the original hierarchy (before the client migration stage).
The first step in the migration is to create the SCCM target hierarchy in parallel with the existing hierarchy.
The second step is to prepare the hierarchies and collect information about the original hierarchy.
At the third stage, the SCCM objects are migrated.
The fourth step is the migration of SCCM clients.
The fifth step is testing the target hierarchy and decommissioning the original hierarchy.
7.1. Deploying SCCM 2012 hierarchies
1. Preparing a hardware platform for installing hierarchy servers.
2. Install or deploy the operating system and updates.
3. Installing the database server.
4. Installing the software necessary for the full functioning of the CAS server.
5. Installing the CAS server.
During the installation process, you will need to specify the languages that must be supported by the SCCM hierarchy, the database server (the account on behalf of which the CAS server is being installed must have the appropriate rights to access the database server, in addition, access must be enabled on the database server TCI \ IP), you must specify the site code of the CAS server. You can use any distribution, since the ability to enter a license after installing the server is provided.
6. Checking the health of the CAS server: check the health of the CAS server components (Monitoring panel, the Site Status and Component Status tabs), and checking the health of the console.
7. Preparing the second server to install the first Primary Site server (repeating steps 2-4).
8. Installing the Primary Site server.
During the installation process, you must specify the database server (the account on behalf of which the server is installed must have the appropriate rights to access the database server, in addition, TCI \ IP access must be enabled on the database server), the site code and specify the server, which will be the parent of this Primary Site server, that is, the CAS server of the new hierarchy. To install the Primary Site server, the same distribution kit is used as for installing the CAS server.
9. Checking the health of the Primary Site server: check the health of the Primary Site server components (Monitoring panel, the Site Status and Component Status tabs), check the health of the console, check the data replication between this server and the CAS server (replmgr.log, rcmctrl. log or Monitoring panel, the Site Status and Component Status tab), check the health of the client management points and content distribution points (mpmsi.log, mpsetup.log, smsdpmon.log Monitoring panel, the Site Status and Component Status tab »), Check the ability to connect clients to each client management point in the hierarchy , the ability to send and receive customer data.
10. Installation of all other Primary site servers in the hierarchy (repeating steps 8 and 9).
11. Checking the health of the SCCM 2012 hierarchy: check the health of the components of all servers in the hierarchy (Monitoring panel, the Site Status and Component Status tabs), check the data replication in the hierarchy (Monitoring panel, the Site Hierarchy tab), in addition verification by viewing the log files on each specific server.
12. Installing the necessary additional roles on the hierarchy server and settings (client discovery methods, client policies, push installation of clients, and so on).
13. Setting up user access rights to the hierarchy and setting up “security scopes”.
7.2. Preparing hierarchies and collecting data
1. Preparing the source hierarchy for migration. The collections and objects are prepared for migration using the SCCM 2007 console. The objects belonging to the sites in the source hierarchy does not matter, since when migrating objects, they can specify any site in the target hierarchy as the parent. As a result, objects can be migrated from any site to any, however, it is necessary to connect all sites with unique content.
2. To migrate data from the source hierarchy to the target, you need to configure the relationship between hierarchies. You need to start from the top site of the hierarchy.
3. After that, you must connect the Primary Site with unique content to the SCCM 2012 hierarchy. Both actions are performed using the SCCM 2012 console (Migration tab, Administration tabs). To do this, select the “Specify Source Hierarchy” item and enter the necessary data for the connection. SCCM 2007 hierarchy sites are connected to a central site.
4. The sharing of content distribution points is enabled using the “Share Distribution Points” item (Migration tab, Administration tabs). Sharing content distribution points is only possible after collecting information about them. This mode is necessary for continuous servicing of clients of sites in which it is impossible to install a Secondary Site server or distribution point for clients of the target hierarchy. Prior to the deployment of these roles, clients of the old and new hierarchies will use the distribution points of the content of the old hierarchy (including distribution points of content on the Primary Site servers).
7.3. SCCM Object Migration
1. After completing the initial data collection, you can begin to migrate the data from the source hierarchy to the target. To do this, select the “Create Migration Job” item (Migration tab, Administration tabs). Next, you need to choose one of two possible types of work: “Collection Migration” or “Object Migration”. After that, select the necessary objects, select the time, assign “Security Scope”, select the site to which the content will be migrated. You can re-migrate SCCM objects. If the object was changed during the migration, it can be re-migrated. Re-migration of collections is carried out using the item "Collection Migration".
Works “Collection Migration” are intended for migration of collections (together with all objects on which they depend), while works “Object Migration” migrate objects (together with all objects on which they depend). Roles or SCMM Primary Site servers cannot be migrated (content distribution points and Secondary Site servers can be migrated). Thus, the choice of objects for migration and the readiness of the target hierarchy for customer service is determined by the needs of the organization.
2. For the migration of all objects, it is necessary to consistently create migration jobs (point 1) as the previous migration jobs are completed. You can verify the success of migration operations in different ways: creating migration reports in the Reporting tab of the Monitoring panel, Migration jobs tab in the Administration panel, viewing migrated objects in the corresponding tab of the SCCM console and viewing the log file - migmctrl.log located in the logs folder.
You can use SQL Server Reporting Services to migrate reports. To do this, you need to convert all reports in the source infrastructure so that they use SQL mechanisms. To do this, you need to install the SQL Server Reporting Services role on the databases, and then configure the access of the original SCCM hierarchy to this service (through the SCCM console, server management, role management), convert all reports to SQL reports (through the SCCM console, select the necessary reports and Click “Copy Reports to Reporting Services”). Further, reports are migrated using SQL Server Reporting Services Report Builder or the ReportSync utility.
To “migrate” sms_def.mof files, you need to re-import them into SCCM 2012 or simply poll the WMI of any client machine containing the necessary classes and add them to inventory using the SCCM 2012 console. Administration panel, Client Settings tab, then either the default policy or a new one policy of client computers (not users), section “Hardware Inventory”, item “Set Classes”. The Import button or polling the client machine and adding WMI classes.
3. After the migration of all objects has been completed, it is necessary to verify the success of replication and the presence of all SCCM objects on all servers in the hierarchy using the SCCM 2012 console.
4. You need to configure the “Boundary Group” for distributing content, after migrating all the “Boundaries” you need to use the item “Boundary Groups” (Hierarchy Configuration tab, Administration tabs).
5. Creating a “Prestage Content” file for further distribution by third-party mechanisms (not SCCM mechanisms). To create this file, go to the “Software Library” tab and select the necessary packages, then use the “Create Prestage Content File” command.
6. Deploy the “Prestage Content” file to the content distribution target points using the extractcontent utility with the / p switch.
7.4. SCCM Client Migration
1. Before installing SCCM 2012 agents, it is recommended that you install the software necessary for the SCCM 2012 client to work on client machines in advance. This step is optional, but desirable since it reduces the installation time of the SCCM 2012 client and the number of installation failures. Prior to client migration, they are served by the servers in the Source Hierarchy.
2. Since client migration is, in fact, reinstalling the agent, it can be done in any way that it is possible to install the SCCM agent. Client installation methods have not changed in the new version of SCCM.
Migration of clients must be carried out in stages (500-1000 clients each) to reduce the load on the network infrastructure and database server. When migrating, you need to consolidate customers. Target hierarchy clients can belong to one of the Primary Site servers. All clients from the corresponding Primary Site server of the second level hierarchy of the source hierarchy and all its subsidiary sites migrate to each Primary Site server.
To create an agent installation package for a new hierarchy in the source hierarchy, you must copy the contents of the agent installation package from the new hierarchy. Agent installation must be performed with the SMSSITECODE = XXX key, where XXX is the code of the parent Primary Site server for this client. This is necessary to bind the client to the hierarchy.
If installation of the SCCM 2012 agent has not been completed, you need to check the ccmsetup.log log on the client machine for errors. If this log is not found on the machine, you must try to install the agent on it again, since the initial attempt to install the agent was not made (the computer may have been turned off).
7.5. Testing the target hierarchy and decommissioning the original hierarchy
1. Content distribution points are migrated after client migration is completed. To migrate content distribution points, use the “Upgrade Distribution Point” item (Migration tab, Administration tabs).
If migration is not possible (for example, there is no space on the server), you must delete the existing SCCM role of the source hierarchy and set the SCCM role of the target hierarchy. To reduce the load on the network, you can use the "Prestage Content" file.
You must remove the SCCM 2007 agent from this distribution point before migrating.
2. Removing the existing SCCM 2007 hierarchy Primary Site servers and installing the corresponding roles (Distribution Point, Secondary Site server) of the new hierarchy. It is performed using the “Create Site Systems Server” item for content distribution points and “Create Secondary Site” for Secondary Site servers.
3. Testing the target hierarchy: check data replication between sites in the hierarchy, check the health of client management points and content distribution points, check the ability of clients to connect to each client management point in the hierarchy, the ability to send and receive customer data. Check the health of the deployments and all data distribution points in the hierarchy.
4. Decommissioning the original hierarchy.
Links :
Administrator Checklists for Migration Planning in System Center 2012 Configuration Manager
Introduction to Migration in System Center 2012 Configuration Manager
Install Sites and Create a Hierarchy for Configuration Manager
Planning for Configuration Manager Sites and Hierarchy
Supported Configurations for Configuration Manager
System Center 2012 - Configuration Manager Component Add-ons and Extensions (Tools)
Migrating from Configuration Manager 2007 to Microsoft System Center 2012 R2 Configuration Manager (Lab)
ConfigMgr client automatic site assignment behavior in a multi site environment
Performing a side -by-side Migration from Configuration Manager 2007 (WindowsNoob)
System Center 2012 Configuration Manager Migration - Deep (ish) Dive Part 1 (troubleshooting)
System Center 2012 Configuration Manager Survival Guide
Specific posts:
www.css-security.com/blog/sccm -2012-migration-made-easy-part-1
www.css-security.com/blog/sccm-2012-migration-made-easy-part-2
www.css-security.com/blog/sccm-2012-migration-made-easy-part-3
anoopcnair.com/2015/08/20/upgrading-from-sccm-2007-to-sccm-2012-with-adaptiva -onesite
activedirectory.ncsu.edu/services/sccm
Upd. You can migrate from 2007 to 1511 directly, without 2012. And in general, everything written in this article is also true for migration to 1511.
1. Architecture
The SCCM 2012 hierarchy consists of three types of servers: Central Administration Site, Primary Site, and Secondary Site. Creating a four-level hierarchy like the existing SCCM 2007 hierarchy using SCCM 2012 is not possible because the SCCM 2012 hierarchy is three-level. The relationship between the servers in the Parent-Child hierarchy, the CAS server is at the head of the hierarchy, the Primary Site servers are subordinate to it, and the Secondary Site servers are subordinate to them. Starting from version 2012 SP1, stand alone Primary can be “converted” to the SCCM hierarchy, so if you have less than 90,000-95,000 clients in the hierarchy, there is no sense in the SCCM 2012 hierarchy with a CAS server.
The source and destination SCCM hierarchies cannot contain the same site codes, so all site codes must be changed during migration.
Only SCCM 2007 servers with installed SP2 or later can participate in the migration.
Extending the Active Directory directory service schema to install the SCCM 2012 hierarchy in parallel with SCCM 2007 is not necessary (if the schema extension was done to install SCCM 2007).
1.1. Central Administration Site The
CAS server is the main SCCM hierarchy server. The SCCM 2012 hierarchy cannot contain more than one CAS server, in addition, it must be installed first in the hierarchy (not relevant after 2012 SP1). The CAS server does not support all roles, since it is not used to interact with clients.
The CAS server is used to manage the entire SCCM infrastructure and is the only server on which information about the entire infrastructure is available, for example, assign discovery methods for Primary Site servers or manage administrator access roles to the SCCM hierarchy.
The CAS server supports up to 100,000 clients in the SCCM infrastructure if the SQL server has an enterprise or datacenter edition and up to 50,000 clients if the SQL server has a standard edition.
1.2. Primary Site
More than 25 Primary Site servers cannot be connected to the CAS server. Primary Site server is responsible for interacting with clients and Secondary Site servers, consolidates the received data and sends them to the CAS server.
Primary Site server supports up to 10 client management points, each of which supports up to 25,000 clients.
A Primary Site server can only manage clients connected directly to this server or clients connected to its child servers.
Primary Site server supports up to 250 Secondary Site servers and 250 Distribution points. The Primary site server can transmit data to the Secondary Site server and to Distribution points on a schedule and / or can limit the channel bandwidth used by it.
Primary Site server supports up to 50,000 clients if it coexists with SQL server and up to 100,000 clients if SQL server exists separately from Primary Site server. Edition of the SQL server is not important, unlike the CAS server. In addition, Secondary Site servers do not increase the limit of clients connected to the Primary Site server. If the CAS server has a database installed on the SQL server of the “standard” edition, the limit of clients connected to the Primary Site server and its child servers is 50000. The
Primary Site server cannot contain child Primary Site servers.
1.3. Secondary Site and Distribution Point
The migration of the Secondary Site servers is as follows - the removal of the original Secondary Site server, waiting for the next cycle of information collection, if the successful removal of the Secondary Site server is confirmed after the information is collected, the Distribution Point is installed and all data that was on the original Secondary Site server is imported into it.
For the migration of Distribution Point, it is necessary that the operating system supported by SCCM 2012 is installed on the server and the free space is two times the size of all packets on the Distribution Point.
Using Distribution Point and the Secondary Site server, you cannot manage the SCCM infrastructure, all administrative actions must be carried out on the CAS and Primary Site servers. The main task of Distribution Points and Secondary Site servers is to reduce file traffic on the network and consolidate data from clients for transmission to the parent Primary Site server.
The Secondary Site server cannot be used to assign SCCM site code to clients. If boundary groups are used to assign sites to clients and the client is assigned a Secondary Site code, the client is assigned the code of the parent site of this Secondary Site server.
Secondary Site server supports up to 250 Distribution points. Distribution point supports up to 4000 customers.
Secondary Site server supports up to 5000 clients.
2. The ability to migrate various types of objects
Unfortunately, I did not understand how to insert a plate, so the picture.
Collection migration - when performing a collection migration, all objects automatically migrate (this function can be disabled when creating a “migration job”) that are associated with this collection (except for those that cannot be migrated). Re-migration of collections is identical to the original.
Migration of objects - when performing the migration of objects, you must select all the objects that should participate in the migration.
However, there are some limitations. Collections should contain only users or only computers. Empty collections cannot be migrated and a folder will be created instead. If there are deployments including all subcollections aimed at an empty collection during migration, a new collection will be created containing all subcollections and deployments that will be aimed at it. Collections containing an unknown computer object will be migrated, but this item will be removed from the collection. Migration of linked collections is not supported (linked collections - collections containing users and computers).
The following objects and data cannot be migrated: queries, reports, customer inventory data, Intel AMT data, modified boot images, SCCM 2007 agent cache data, client history, security settings, mof files.
Report migration is not possible using SCCM. However, you can use the SQL Server Reporting Services Report Builder utility to migrate reports. To do this, you need to convert all reports in the source infrastructure so that they use SQL mechanisms. To do this, you need to install the SQL Server Reporting Services role on the databases, and then configure the access of the original SCCM hierarchy to this service (through the SCCM console, server management, role management), convert all reports to SQL reports (through the SCCM console, select the necessary reports and Click “Copy Reports to Reporting Services”). Further, reports are migrated using SQL Server Reporting Services Report Builder or the ReportSync utility.
Request migration is not possible using SCCM. It is necessary to recreate queries or export queries as “mof” files from the SCCM 2007 hierarchy and import them into SCCM 2012, this is done using the SCCM console of the source and target hierarchies.
Mof files cannot be migrated using SCCM. You must reconfigure them in the new hierarchy. The mechanism for interacting with mof files has not changed, however, changes to existing mof files may be required for full compatibility with SCCM 2012.
3. SQL server requirements
For all server roles, 64-bit editions of SQL server and windows authentication to access the database must be used.
The SQL Server Replication component is not used to replicate data between SCCM servers. This process takes place by SMS Provider. If you need to generate and view reports, you need to install the SQL Server Reporting Services component on the SQL server.
For each SCCM server, a separate instance of the SQL server must be used, and the Collation parameter of the SQL server must be the same on all servers in the SCCM hierarchy. The only Collation supported is SQL_Latin1_general_CP1_CI_AS.
For correct operation, the SCCM 2012 hierarchy server site requires that the SQL server support windows authentication. Since mixed mode supports windows authentication, its use on SQL servers of the SCCM hierarchy is possible. Thus, it is possible to use mixed or windows authentication, "Best practice" - Windows mode.
You must use the following SQL server memory consumption settings:
- if the SQL installation and the SCCM server coexist, limit the SQL server memory consumption to 50-80% of the server RAM.
- in case of separate installation of SQL and the SCCM server, limit the memory consumption of the SQL server to 80-90% of the server RAM.
- Primary Site server and CAS server require backup of 8GB of RAM on the SQL server, and Secondary Site server requires backup of 4GB of SQL server RAM.
4. Network infrastructure
requirements gallery.technet.microsoft.com/SCCM-2012-R2-Network-scheme-b01fd985
This scheme without CAS role, I did not find another scheme. But I think 99% of those reading this will do it.
5. Preparing for migration
Since the SCCM 2012 hierarchy is different from the SCCM 2007 hierarchy, it is necessary to reorganize the existing SCCM 2007 structure and make it more flat. To perform the migration, you need an account with “Read” access to all objects of the SCCM 2007 hierarchy and an account with “Read” and “Write” rights to the database, in addition, you must open the following ports: 135, 445, 1433 (all TCP).
To migrate SCCM 2007 to SCCM 2012, you need to select the source server in the 2007 infrastructure, it must be the “highest” server of the existing hierarchy, because after selecting the source server you cannot migrate all objects, servers and clients that are “above” the selected server.
Since SCCM 2012 does not support the creation of subsidiary Primary Site servers from Primary Site servers, it is impossible to migrate such a hierarchy, it is necessary to consolidate all the clients of all subsidiary Primary Site servers in the existing hierarchy into the corresponding parent Primary Site servers in the new hierarchy. Consolidation of clients occurs during the "migration" of the client. Prior to the direct migration, clients are managed by the SCCM 2007 hierarchy. When migrating a client, it should receive the code of its parent site SCCM 2012 when installing the client (via the command line key). Assigning clients the corresponding site codes of their parent Primary Site servers is consolidation.
All servers in the hierarchy that will participate in the migration must be upgraded to SCCM 2007 SP2 or higher.
Secondary servers cannot be migrated, it is necessary to remove the server and install Secondary server on it from the SCCM 2012 infrastructure (possibly together with saving data to the Distribution point).
For uninterrupted service provision, SCCM infrastructures can share existing Distribution points. The sharing of existing Distribution points is set up at the initial stages of migration. For this, an account with “Modify” rights to the SCCM object is required.
To migrate SCCM objects, you need to prepare public folders for migration, those that give access to public folders to accounts that will be responsible in the new hierarchy for access to public folders. In addition, you need to reconfigure SCCM objects so that they use the UNC path to the shared folder, this will allow you not to reconfigure the objects after migration.
Collections cannot be mixed; they cannot contain computers and users at the same time. All mixed collections need to be reorganized into collections that contain only users and only devices. In addition, collections that contain mixed collections and collections containing unknown computers cannot be migrated. Empty collections will be migrated as folders.
To migrate reports, you must install the SQL Server Reporting Services (SRS) role and convert all reports to SRS format. Report migration using SCCM is not possible, but it is possible using SQL.
Client migration avoids the redistribution of packages, this is because when migrating packages, SCCM 2012 stores information on the package number of SCCM 2007 in the database, and the client, in turn, saves data about installed packages during migration.
To migrate clients, you must create and distribute packages for installing SCCM 2012 clients in the SCCM 2007 hierarchy. In addition, you can distribute SCCM 2012 clients in any way possible, since client migration is not possible in place upgrade.
6. Preparing the target system for migration
The target hierarchy should be deployed from top to bottom: the central site should be deployed first, after it its child sites will be deployed, and then the servers and distribution points of the lower level should be deployed. If at some sites it is impossible to deploy the server from a new hierarchy, you must use the opportunity to create a distribution point for content on the client system.
It is possible to transfer content according to a customized schedule, that is, without loading the channel during business hours, or using the “Prestage Content File” and transfer it to the site offline. The “Prestage Content File” is created on the central site of the hierarchy and contains all the necessary packages.
After the hierarchy is expanded, testing is necessary. Check data replication between sites in the hierarchy, check the health of client management points and content distribution points. Check the ability to connect clients to each client management point in the hierarchy, the ability to send and receive customer data. Check the health of the deployments and all data distribution points in the hierarchy.
The next step in preparing the target infrastructure should be the “Default Client Settings”, “Boundary”, “Boundary Group”, “Security Scope” and Administrative Accounts settings. In addition, you need to create 2 accounts to access the old hierarchy and to access the database of the old hierarchy (you may need to create more accounts if you cannot connect with the same credentials to access different hierarchy sites and different database servers). “Security Scope” and “Boundary Group” are needed to reassign rights to manage content and indicate the location of content in the new hierarchy.
At the beginning of the process, the new system indicates the addresses of SCCM 2007 servers and the credentials for accessing them, starting from the highest to the lowest server in the hierarchy, all the servers that will participate in the migration are indicated. Then the choice is made which data needs to be transferred from the old system to the new one.
In fact, migration is a copy of objects from the source hierarchy to the target. Objects are migrated using “migration jobs”. Each “migration job” can migrate any number of SCCM objects. You can re-migrate SCCM objects if necessary (for example, the object has been modified). The order in which objects are migrated is not important. Roles or SCMM Primary Site servers cannot be migrated (content distribution points and Secondary Site servers can be migrated).
To copy objects from the source hierarchy to the target, it is necessary to collect data about the source hierarchy. In the process of collecting data, a relationship is established between hierarchies. Data is collected by reading information about objects and their dependencies, collections, sites and clients from the database of the target hierarchy.
To migrate clients, you must use the source hierarchy console or other means, as clients are migrated by in-place client updates. The mechanisms for installing the agent on the client computer did not change in SCCM 2012. The update can be initiated by a startup script, group policy, or installed as a package from the server in the source hierarchy. Before the client is migrated, it is managed by the original hierarchy.
The SCCM 2007 client cannot be controlled by the SCCM 2012 hierarchy and vice versa, the SCCM 2012 client cannot be controlled by the SCCM 2007 hierarchy. In the case of improperly configured site boundaries in the SCCM hierarchies, clients that receive the wrong site code (those site codes from a "different" hierarchy) will not be managed until they are assigned the correct site code. Prior to the start of migration, all clients are managed by the SCCM 2007 hierarchy; as clients migrate, they are transferred to SCCM 2012.
After the migration of clients and objects is complete, you can proceed with the migration of content distribution points. It occurs using the CAS console of the target hierarchy server (the “Migrate Distribution Point” task). When you migrate a content distribution point, binary files are updated and file storage is migrated. For the migration of the storage, it is necessary that the server has free space 2-2.5 times the space occupied by all SCCM 2007 packages on this server, since the SCCM package storage is being rebuilt.
Migration of Secondary Site servers is not possible. Instead, an “in place” upgrade of the Secondary Site server occurs only to the point of distribution of the content of the target hierarchy (this is a technical limitation of the system introduced by Microsoft in connection with changes in the mechanisms of packet replication in the hierarchy and improvements in the mechanisms for controlling packet replication traffic), preserving all packages. For the migration of the storage, it is necessary that the server has free space 2-2.5 times the space occupied by all SCCM 2007 packages on this server, since the SCCM package storage is being rebuilt.
Migration of Primary Site servers is not possible; instead of migration of Primary Site servers, objects are migrated from the Primary Site server of the old hierarchy to the CAS (or the corresponding Primary Site server) of the new hierarchy. Thus, for the "migration" of the Primary Site server, you must have the target SCCM 2012 infrastructure and a place to store packages equivalent to the space spent on the source server. Despite the fact that the CAS server cannot serve clients and cannot be a distribution point for content, it must be available on it to store all hierarchy packets.
Useful utilities:
ReportSync - utility for migrating reports from the SCCM 2007 hierarchy to the SCCM 2012 hierarchy. Available for download on the Internet.
RegKeytoMof - utility for creating mof files for inventory of non-standard registry settings. Available for download on the Internet.
ExtractContent - utility for unpacking the contents of the "Prestage Content" file. It comes bundled with SCCM 2012 and is located in the “BIN” folder of the SCCM
CMTrace distribution kit - a utility for viewing logs. It comes bundled with SCCM 2012 and is located in the Tools folder of the SCCM distribution.
Notepad - a utility for viewing logs.
7. Approximate migration process
Migration takes place in stages. You can proceed to the next stage of migration only after the complete completion of the previous stage. In the event of a failure of the target hierarchy, a painless return of the IT infrastructure to the original hierarchy is possible, since migration does not imply any changes that impede the functioning of the original hierarchy (before the client migration stage).
The first step in the migration is to create the SCCM target hierarchy in parallel with the existing hierarchy.
The second step is to prepare the hierarchies and collect information about the original hierarchy.
At the third stage, the SCCM objects are migrated.
The fourth step is the migration of SCCM clients.
The fifth step is testing the target hierarchy and decommissioning the original hierarchy.
7.1. Deploying SCCM 2012 hierarchies
1. Preparing a hardware platform for installing hierarchy servers.
2. Install or deploy the operating system and updates.
3. Installing the database server.
4. Installing the software necessary for the full functioning of the CAS server.
5. Installing the CAS server.
During the installation process, you will need to specify the languages that must be supported by the SCCM hierarchy, the database server (the account on behalf of which the CAS server is being installed must have the appropriate rights to access the database server, in addition, access must be enabled on the database server TCI \ IP), you must specify the site code of the CAS server. You can use any distribution, since the ability to enter a license after installing the server is provided.
6. Checking the health of the CAS server: check the health of the CAS server components (Monitoring panel, the Site Status and Component Status tabs), and checking the health of the console.
7. Preparing the second server to install the first Primary Site server (repeating steps 2-4).
8. Installing the Primary Site server.
During the installation process, you must specify the database server (the account on behalf of which the server is installed must have the appropriate rights to access the database server, in addition, TCI \ IP access must be enabled on the database server), the site code and specify the server, which will be the parent of this Primary Site server, that is, the CAS server of the new hierarchy. To install the Primary Site server, the same distribution kit is used as for installing the CAS server.
9. Checking the health of the Primary Site server: check the health of the Primary Site server components (Monitoring panel, the Site Status and Component Status tabs), check the health of the console, check the data replication between this server and the CAS server (replmgr.log, rcmctrl. log or Monitoring panel, the Site Status and Component Status tab), check the health of the client management points and content distribution points (mpmsi.log, mpsetup.log, smsdpmon.log Monitoring panel, the Site Status and Component Status tab »), Check the ability to connect clients to each client management point in the hierarchy , the ability to send and receive customer data.
10. Installation of all other Primary site servers in the hierarchy (repeating steps 8 and 9).
11. Checking the health of the SCCM 2012 hierarchy: check the health of the components of all servers in the hierarchy (Monitoring panel, the Site Status and Component Status tabs), check the data replication in the hierarchy (Monitoring panel, the Site Hierarchy tab), in addition verification by viewing the log files on each specific server.
12. Installing the necessary additional roles on the hierarchy server and settings (client discovery methods, client policies, push installation of clients, and so on).
13. Setting up user access rights to the hierarchy and setting up “security scopes”.
7.2. Preparing hierarchies and collecting data
1. Preparing the source hierarchy for migration. The collections and objects are prepared for migration using the SCCM 2007 console. The objects belonging to the sites in the source hierarchy does not matter, since when migrating objects, they can specify any site in the target hierarchy as the parent. As a result, objects can be migrated from any site to any, however, it is necessary to connect all sites with unique content.
2. To migrate data from the source hierarchy to the target, you need to configure the relationship between hierarchies. You need to start from the top site of the hierarchy.
3. After that, you must connect the Primary Site with unique content to the SCCM 2012 hierarchy. Both actions are performed using the SCCM 2012 console (Migration tab, Administration tabs). To do this, select the “Specify Source Hierarchy” item and enter the necessary data for the connection. SCCM 2007 hierarchy sites are connected to a central site.
4. The sharing of content distribution points is enabled using the “Share Distribution Points” item (Migration tab, Administration tabs). Sharing content distribution points is only possible after collecting information about them. This mode is necessary for continuous servicing of clients of sites in which it is impossible to install a Secondary Site server or distribution point for clients of the target hierarchy. Prior to the deployment of these roles, clients of the old and new hierarchies will use the distribution points of the content of the old hierarchy (including distribution points of content on the Primary Site servers).
7.3. SCCM Object Migration
1. After completing the initial data collection, you can begin to migrate the data from the source hierarchy to the target. To do this, select the “Create Migration Job” item (Migration tab, Administration tabs). Next, you need to choose one of two possible types of work: “Collection Migration” or “Object Migration”. After that, select the necessary objects, select the time, assign “Security Scope”, select the site to which the content will be migrated. You can re-migrate SCCM objects. If the object was changed during the migration, it can be re-migrated. Re-migration of collections is carried out using the item "Collection Migration".
Works “Collection Migration” are intended for migration of collections (together with all objects on which they depend), while works “Object Migration” migrate objects (together with all objects on which they depend). Roles or SCMM Primary Site servers cannot be migrated (content distribution points and Secondary Site servers can be migrated). Thus, the choice of objects for migration and the readiness of the target hierarchy for customer service is determined by the needs of the organization.
2. For the migration of all objects, it is necessary to consistently create migration jobs (point 1) as the previous migration jobs are completed. You can verify the success of migration operations in different ways: creating migration reports in the Reporting tab of the Monitoring panel, Migration jobs tab in the Administration panel, viewing migrated objects in the corresponding tab of the SCCM console and viewing the log file - migmctrl.log located in the logs folder.
You can use SQL Server Reporting Services to migrate reports. To do this, you need to convert all reports in the source infrastructure so that they use SQL mechanisms. To do this, you need to install the SQL Server Reporting Services role on the databases, and then configure the access of the original SCCM hierarchy to this service (through the SCCM console, server management, role management), convert all reports to SQL reports (through the SCCM console, select the necessary reports and Click “Copy Reports to Reporting Services”). Further, reports are migrated using SQL Server Reporting Services Report Builder or the ReportSync utility.
To “migrate” sms_def.mof files, you need to re-import them into SCCM 2012 or simply poll the WMI of any client machine containing the necessary classes and add them to inventory using the SCCM 2012 console. Administration panel, Client Settings tab, then either the default policy or a new one policy of client computers (not users), section “Hardware Inventory”, item “Set Classes”. The Import button or polling the client machine and adding WMI classes.
3. After the migration of all objects has been completed, it is necessary to verify the success of replication and the presence of all SCCM objects on all servers in the hierarchy using the SCCM 2012 console.
4. You need to configure the “Boundary Group” for distributing content, after migrating all the “Boundaries” you need to use the item “Boundary Groups” (Hierarchy Configuration tab, Administration tabs).
5. Creating a “Prestage Content” file for further distribution by third-party mechanisms (not SCCM mechanisms). To create this file, go to the “Software Library” tab and select the necessary packages, then use the “Create Prestage Content File” command.
6. Deploy the “Prestage Content” file to the content distribution target points using the extractcontent utility with the / p switch.
7.4. SCCM Client Migration
1. Before installing SCCM 2012 agents, it is recommended that you install the software necessary for the SCCM 2012 client to work on client machines in advance. This step is optional, but desirable since it reduces the installation time of the SCCM 2012 client and the number of installation failures. Prior to client migration, they are served by the servers in the Source Hierarchy.
2. Since client migration is, in fact, reinstalling the agent, it can be done in any way that it is possible to install the SCCM agent. Client installation methods have not changed in the new version of SCCM.
Migration of clients must be carried out in stages (500-1000 clients each) to reduce the load on the network infrastructure and database server. When migrating, you need to consolidate customers. Target hierarchy clients can belong to one of the Primary Site servers. All clients from the corresponding Primary Site server of the second level hierarchy of the source hierarchy and all its subsidiary sites migrate to each Primary Site server.
To create an agent installation package for a new hierarchy in the source hierarchy, you must copy the contents of the agent installation package from the new hierarchy. Agent installation must be performed with the SMSSITECODE = XXX key, where XXX is the code of the parent Primary Site server for this client. This is necessary to bind the client to the hierarchy.
If installation of the SCCM 2012 agent has not been completed, you need to check the ccmsetup.log log on the client machine for errors. If this log is not found on the machine, you must try to install the agent on it again, since the initial attempt to install the agent was not made (the computer may have been turned off).
7.5. Testing the target hierarchy and decommissioning the original hierarchy
1. Content distribution points are migrated after client migration is completed. To migrate content distribution points, use the “Upgrade Distribution Point” item (Migration tab, Administration tabs).
If migration is not possible (for example, there is no space on the server), you must delete the existing SCCM role of the source hierarchy and set the SCCM role of the target hierarchy. To reduce the load on the network, you can use the "Prestage Content" file.
You must remove the SCCM 2007 agent from this distribution point before migrating.
2. Removing the existing SCCM 2007 hierarchy Primary Site servers and installing the corresponding roles (Distribution Point, Secondary Site server) of the new hierarchy. It is performed using the “Create Site Systems Server” item for content distribution points and “Create Secondary Site” for Secondary Site servers.
3. Testing the target hierarchy: check data replication between sites in the hierarchy, check the health of client management points and content distribution points, check the ability of clients to connect to each client management point in the hierarchy, the ability to send and receive customer data. Check the health of the deployments and all data distribution points in the hierarchy.
4. Decommissioning the original hierarchy.
Links :
Administrator Checklists for Migration Planning in System Center 2012 Configuration Manager
Introduction to Migration in System Center 2012 Configuration Manager
Install Sites and Create a Hierarchy for Configuration Manager
Planning for Configuration Manager Sites and Hierarchy
Supported Configurations for Configuration Manager
System Center 2012 - Configuration Manager Component Add-ons and Extensions (Tools)
Migrating from Configuration Manager 2007 to Microsoft System Center 2012 R2 Configuration Manager (Lab)
ConfigMgr client automatic site assignment behavior in a multi site environment
Performing a side -by-side Migration from Configuration Manager 2007 (WindowsNoob)
System Center 2012 Configuration Manager Migration - Deep (ish) Dive Part 1 (troubleshooting)
System Center 2012 Configuration Manager Survival Guide
Specific posts:
www.css-security.com/blog/sccm -2012-migration-made-easy-part-1
www.css-security.com/blog/sccm-2012-migration-made-easy-part-2
www.css-security.com/blog/sccm-2012-migration-made-easy-part-3
anoopcnair.com/2015/08/20/upgrading-from-sccm-2007-to-sccm-2012-with-adaptiva -onesite
activedirectory.ncsu.edu/services/sccm