Recently I did a ConfigMgr 2012 R2 to 1511 migration. Case is, it was needed to be installed on a new server. This new server has a different computername and IP-address and different partitions as well. When you want to recover an existing ConfigMgr installation, you need to have a server with the same computername, IP-address and partitions too. Therefore I have choosen not to re-use the ConfigMgr back-up, but using migrations tools.
Let's have a look at current situation first. The existing server is build on Windows Server 2008 R2, SQL Server 2008 R2 and ConfigMgr 2012 R2, where the Primary server installation is separated from SQL installation. You may upgrade SQL Server in-place with Microsoft support, but an in-place Windows Server upgrade is not supported. Therefore a new server with a current (2012 R2) server installation is needed. When using Windows Server 2012 an in-place upgrade to 2012 R2 is supported. Otherwise not!
When building a new server, and there's a need to use the existing ConfigMgr database, the computername, IP-address and partitions must be same. Because I want to change the name and partition both, recovery is not possible. Therefore I used a new server build on Windows Server 2012 R2, SQL Server 2014 SP1 and and ConfigMgr 1511. During installation a new Site code and name is requested. The existing name cannot be re-used.
After installation start the migration tools, and migrate all objects needed to the new server. Remember you cannot migrate collections when coming from ConfigMgr 2012. For some reason that is possible only from ConfigMgr 2007 environments. Other objects migrate fine indeed. After migration remember to update ConfigMgr client too, so management can be done from the new server.
All went fine during this migration. Hope it helps!
Update 28-12-2015: Within the Object migration task, collections can be selected as well. As asked by Conor O'Farrell within the comments, both deployments and collections can be migrated successfully. On my software package however the program was disabled after migration, without the possibility to enable it during migration. So yes, you can migrate all stuff needed from ConfigMgr 2012 R2 to 1511. Just great!
Sources used:
Backup and Recovery in Configuration Manager
How to move the ConfigMgr 2012 site database to a new SQL server
Supported configurations for System Center Configuration Manager
Planning a Migration Job Strategy in System Center 2012 Configuration Manager
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!
When migrating ConfigMgr 2007 to 2012 (Side-by-Side) it's possible to use Migration Jobs to copy collections and objects. Microsoft has build-in Migration Jobs for doing this, and it's doing a great job! Today I used the Object migration for copying software packages, drivers, driver packages, images and task sequences. All content will be imported into the new ConfigMgr 2012 database. The wizard will looks like this:
Just select everything needed, and save a lot of time!
The following will be mentioned during "Review migration job information".
In a few steps the source location is mentioned. Before or after migration the source location may be updated when pointing to the old ConfigMgr 2007 server. For software packages the following tool can be used: Coretech Package Source Changer.
For driver packages and Windows images I haven't find a good solution yet. Maybe someone can share a script for doing this?
