Since the ConfigMgr 2012 release (April 2012), I'm doing both implementations and 2007 migrations a lot. ConfigMgr 2012 is still the best choice for on-premises and remote device management.
With Microsoft Intune integration (part of Enterprise Mobility Suite) for mobile device and application management, you have best of both worlds. Microsoft mentions that 'No one else offers this functionality!'. Therefore ConfigMgr and EMS is the best solution for deploying and managing Windows 10 on PC's, tablets and mobile devices.
Additionally, ConfigMgr 2016 (ConfigMgr as a service, which is called just 'ConfigMgr' from now on) will support MDM-based management for Windows devices, fully on-premises, with no ConfigMgr agent required. In that case you can choose between full (with ConfigMgr agent) and MDM-based (no ConfigMgr agent) management.
But what to do if organizations are still on ConfigMgr 2007 these days?
On Microsoft TechNet there was a question about this several months ago. I did a post on Twitter today as well. The answer sounds promising: ConfigMgr 2016 does support migrating from ConfigMgr 2007 R2 SP2 and R3 SP2, which is really great news! So no need to migrate to ConfigMgr 2012 first before going to 2016. Thanks to Peter Daalmans (@pdaalmans) on this one.
ConfigMgr 2016 will be generally available in Q4 CY2015 (which is really soon!). Technical Preview 4 is released last week, which is the last technical preview before the general availability (GA) of the current branch of ConfigMgr.
During a ConfigMgr 2007 distribution point migration IIS must be installed (if it isn't installed yet) and content can be converted. Because of IIS installation (which ConfigMgr will do for you, if you select this in the wizard) a restart may be triggered. In my case an unexpected restart was done on a Windows Server 2008 R2 system. This because of an "unknown" MSI installation. As far as I can see only the "Remote Differential Compression" (RDC) feature is installed and the "Microsoft Visual C++ 2010 x64 redistributable".
When distribution points are not "eligible for upgrade", which they were in my case, just make sure no other roles (eg PXE service point) then distribution point are installed. Just make sure there is enough available disk space also - need 100% free space in order to carry out conversion to ConfigMgr 2012 content library. When removing PXE service point, clean up disk space, and wait a while (or reboot the server), distribution points are finally eligible for upgrade.
Source: Microsoft TechNet
When looking in SMS_DP$\SMS\BIN\vcredist.log-MSI_vc_red.msi on the server the following lines are displayed:
MSI (s) (68:4C) [10:55:25:452]: Note: 1: 1707 MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219 -- Installation completed successfully.
MSI (s) (68:4C) [10:55:25:452]: Windows Installer installed the product. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 0.
MSI (s) (68:4C) [10:55:25:452]: Value of RebootAction property is MSI (s) (68:4C) [10:55:25:452]: Windows Installer requires a system restart. Product Name: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Product Version: 10.0.40219. Product Language: 0. Manufacturer: Microsoft Corporation. Type of System Restart: 2. Reason for Restart: 1.
MSI (s) (68:4C) [10:55:25:452]: Product: Microsoft Visual C++ 2010 x64 Redistributable - 10.0.40219. Restart required. The installation or update for the product required a restart for all changes to take effect. The restart was deferred to a later time.
MSI (s) (68:4C) [10:55:25:468]: Deferring clean up of packages/files, if any exist MSI (s) (68:4C) [10:55:25:468]: MainEngineThread is returning 3010 MSI (s) (68:34) [10:55:25:468]: RESTART MANAGER: Session closed.
MSI (s) (68:34) [10:55:25:468]: No System Restore sequence number for this installation.
When looking in Event Viewer the server is rebooted a second afterwards (on 10:55:26 exactly):
The process f:\06ce98a1da047515c72afeca1f47e3\Setup.exe (########) has initiated the restart of computer ######## on behalf of user ######## for the following reason: Other (Planned) Reason Code: 0x80000000 Shutdown Type: restart
So yes, "Microsoft Visual C++ 2010 x64 redistributable" did need a restart, and your server will be down for a few moments.
Furthermore Microsoft TechNet mentions that the ConfigMgr 2007 client must be removed on Branch distribution points only. During migration on a Standard distribution point however the following message is displayed "Failed to update binaries". After removing the ConfigMgr 2007 client, converting content was done successfully without any problem. When migrating packages is done, the following message is displayed: "Completed reassign distribution point". So next time, I will remove the ConfigMgr 2007 client on Standard distribution points before migration also.
Be aware that only packages which are migrated to ConfigMgr 2012 will be converted to the SCCMContentLib folder. Other old packages will still be left in the old package share folder and can be removed afterwards manually. Just make sure that packages migrated does not have the "Copy the content in this package to a package share on distribution points" have selected in properties. Otherwise they will be on your new ConfigMgr 2012 server in package share folder also. After that you will have new distribution points running!
Source: Microsoft TechNet
This month things started again, doing a ConfigMgr migration already! A migration in ConfigMgr is nothing more then installing a new Site Server and starting migration jobs, but still you must know what to do! Things must be done in the right order for doing it okay. I will mention the steps to follow and issues experienced for you.
Install and configure a new Site Server first and make sure you have permissions enough to access both the old and new Site Server. Then start with the migration. It can be done in a few steps (days).
1. Specify Source Hierarchy
The account used must have the required permissions to access the SMS Provider in ConfigMgr 2007. I can be both a computer or user account. I used both before, as long as you can access the Site Server. The other account mentioned here must have access to the ConfigMgr database. After that the migration can be started.
2. Share Distribution Points
Select all the Distribution points (DP's) which are needed for migration. In this situation they can be used both for ConfigMgr 2007 and 2012 migration. It can be both Branch, Protected or Standard DP's.
3. Create Migration Jobs
You can create one or multiple jobs to migrate collections and objects. In my experience they are all running fine, but there's no option to change source locations. When source files are located on the old Site Server they must be migrated to a new location. There are multiple scripts to find on the web for doing that. HERE and HERE.
When migrating taks sequences as well all content located in the task sequence is migrated as well. This means all driver packages, drivers, software packages, boot images, OS images will migrated also. Because there's no option to unselect content (all is needed for the task sequence) it will be a time consuming job.
You cannot choose to export task sequences in ConfigMgr 2007 and import them in ConfigMgr 2012 SP1 again because it's a new file format (zip instead of xml). Bad luck!
4. Upgrade ConfigMgr Clients
When content is migrated to the new Site Server it's time to upgrade the ConfigMgr clients. This can be done from ConfigMgr 2012 when system discovery is done. Just make sure DotNet Framework 4 is installed on the clients, because it's needed to install the client.
When Forefront Endpoint Protection (FEP) 2010 is installed, it will be removed automatically and when Client policy is changed, System Center 2012 Endpoint Protection (SCEP) 2012 will be installed. No need to do anything when things are configured the right way.
5. Upgrade Distribution Points
This step can be done during or before upgrade ConfigMgr clients as well. You need a new ConfigMgr client to access a upgraded DP, so both are needed. Migrating DP's can take many hours because they will be converted to the new Content Library share. Ensure that the location that you selected on the Drive Settings page of this wizard contains sufficient free disk space for this content to convert.
If the content will remain on the same drive, conversion requires free space on that drive that is equal to slightly more than twice the estimated volume of the migrated packages. If the content will move to a new drive, conversion requires free space on that drive that is equal to the estimated volume of the migrated packages.
Before you upgrade a Branch DP, uninstall the ConfigMgr 2007 client software. When you upgrade a Branch DP that has the ConfigMgr 2007 client software installed, the content that was previously deployed to the computer is removed from the computer, and the upgrade of the DP fails! Without the client it goes fine all the way!
6. Stop Gathering Data
When you are satisfied about migrated collections, objects and DPs it's time to stop the connection to ConfigMgr 2007. You can choose to delete existing migration jobs also. After that (or after a while to make sure things are okay) you can uninstall ConfigMgr 2007 sites and servers. The migration is completed now!
Hope above steps are clear and help you to migrate ConfigMgr sites. In a next blogpost I will mention some issues which were seen during the migration. Nice to be back again!
