This is the third and final part in a series about migrating from SCCM 2007 to CM 2012. For a high-level overview of the migration process, please click here: Migrating from SCCM 2007 to System Center 2012 Configuration Manager – (windowsmanagementexperts.com)
Migrating clients from SCCM 2007 to CM 2012 is the last step in completing your migration. As with the rest of the migration process, this step should be carefully planned and thought-out before attempting the client migration.
Migrated Client Data
When migrating clients from SCCM 2007 to CM 2012, the client GUID and advertisement history are preserved. This is how CM 2012 can put the client in the proper collections once it is migrated. Because the advertisement history is preserved, CM 2012 will also know what software has been installed on migrated clients, so any deployments to those clients will not re-run.
Data that are not migrated includes files in the client cache, data stored in the Configuration Manager Client registry, inventory information, and desired configuration management (DCM) data. CM 2012 will have to regenerate all of this data. Data the is stored in the client cache will be regenerated if the package is ran again from Software Center.
If you persist data in the client cache, this data will have to be put back after migration is complete. This may involve reinstalling the application that persists data. Also, if you have power schemes (SCCM Power Management), logging settings, or local policy settings saved in the Configuration Manager Client registry, these items will have to be repopulated.
App-V application data, because it is stored in the client cache, will also be removed. The App-V application will have to be reinstalled from Software Center to get the application to run again. Any data or settings stored with the application will also be removed.
No inventory information is transferred. As long as you put the same inventory rules in place that you have in SCCM 2007, all of this data will repopulate after an inventory cycle. Also, any data generated by desired configuration management will have to be repopulated. As long as DCM is configured in CM 2012, everything should repopulate.
The fact that a lot of this data is not migrated when you migrate your clients stresses the fact that you do not migrate clients until after CM 2012 is set up and objects are migrated. You must migrate packages, DSM settings, and recreate client settings before migrating any clients into the system.
Migrating Clients
There are four methods of migrating clients from SCCM 2007 to CM 2012. I will go over, in detail, three of these methods. The fourth method is manually installing the new clients on machines. In most environments large enough to run CM 2012, this will not be an option.
The first method is using group policy to install the client. You do this by using the “Software installation” node in your Group Policy object. I recommend doing the installation on startup (computer configuration) instead of logon (user configuration). The main reason is user vs. computer. If you install based on user, the client will try to install on any computer that a particular user logs in on, making keeping track of the migration process much more difficult. If it is applied based on computer, it will install for a particular computer once, and that’s it. To set up the install, simply copy the client.msi file from “C:\Program Files\Microsoft Configuration Manager\Client\” to a location where other GPO software installations exists. You will have to do separate installs for 32-bit and 64-bit. As long as you have your AD schema extended correctly for CM 2012, no other options or parameters should be needed (extending the AD schema is outside the scope of this article). Once the software installation is set up, the client will install on next boot up. The installation will proceed in the background and still allow the end user to log in and use the machine as if nothing is going on.
The second method is using software updates. You can add the same client.msi installer to your SCCM 2007 software update point and deploy it that way. You will need SCUP in order to do this. Adding updates via SCUP is outside the scope of this article. Again, as long as your AD schema is extended correctly, no additional parameters are needed.
The third method is to use client push to migrate clients. This is the simplest method. For this to work, you must have AD system discovery turned on. Turning discovery on will import all devices from a given organizational unit in AD into CM 2012. Once the clients are discovered, you simply add the clients to a collection in CM 2012, and push the client to the collection. It will uninstall the SCCM 2007 client and install the CM 2012 client. If a client is not turned on or not connected to your network when you push the new client, CM 2012 will continue to try to connect to the client. Once it is able to connect, it will install the client.
If you do not have your AD schema extended and want to extend it, see this TechNet blog: https://blogs.technet.com/b/configurationmgr/archive/2012/10/30/extending-the-schema-in-system-center-2012-configuration-manager.aspx. If you cannot extend your schema, add the “SMSMP=” as a parameter of your Group Policy and Software Update installations.
Best Practices
Microsoft has two recommendations that it considers as “best practice”. This first is to migrate clients in batches, and not all at once. The CM 2012 database can become overloaded with new information if you migrate too many clients at once. Also, quite a bit of network traffic is generated between the newly-migrated clients and the CM 2012 servers. According to Microsoft resources, a new client will generate 4.7 MB of traffic to sync itself with the new system. Migrating too many at once can overload your network. Sticking with 300-400 clients at time worked well for me. I would recommend taking it by organization functional unit when migrating.
The second recommendation is that you disable all advertisements and task sequences from SCCM 2007 when beginning the client migration. This will ensure that users are not trying to install software during an upgrade of their client. It will also keep network traffic lower, allowing for more clients to be migrated.
Summary
My preferred method of client migration is client push. This was very simple to do, and could be done “on-the-fly” as organizational units became ready. I was able to migrate the majority of our 6,000 clients in a week using this method. I was able to track these numbers by looking at the client push report, and also by creating a collection of computers that did not have the CM 2012 client. I could watch the successful installs, failures, and postponements from the report, and also see that number of computers in the collection drop. The biggest thing to remember is to plan. Evaluate which method works best for you, and test it thoroughly.
