Sunday, 7 August 2016

ConfigMgr Current Branch - real world migration from ConfigMgr 2012R2

System Center Configuration Manager landing page

ConfigMgr Current Branch 1606 was released to GA this week and there has been a lot of excitement about the in-place upgrade to the latest version. I've done quite a number of upgrades from ConfigMgr 2012R2 to Current Branch so I thought that this would be a good time to describe some of the real world issues associated with this operation. Many of the ConfigMgr 2012R2 implementations we encounter are installed on Windows 2008R2 servers. This was ok at the time. However if we want to configure Windows 10 servicing we now require Windows Server 2012R2 on the Primary Site Server and Software Update Points.

Previously I've blogged about migrating using ConfigMgr's built-in migration process. See that here This works well and you can migrate from many previous versions (as far back as ConfigMgr 2007 SP2). In this case though you end up with a new site code and this isn't always the required outcome.

In this blog I'll describe the steps required to upgrade from ConfigMgr 2012R2 (installed on Windows Server 2008R2) to Current Branch 1606 (installed on Windows Server 2012R2).

ConfigMgr 1602 supports the in-place upgrade of the Operating System from Windows Server 2008R2 to Windows 2012R2. See the details here However some customers don't like in-place upgrades of the operating system and would like to start off with a freshly installed OS. To achieve this we must back up the site and restore it to a new Windows 2012R2 server. I've listed the high level steps to carry out this operation below:

Notes:
  1. In this blog I'm referring to the 2008R2 server as "old" and the 2012R2 server as "new"
  2. These steps are based on migrating a standalone Primary Site server configured as a Software Update Point.
Migration steps:
  • If you are using VMs take a snapshot of old
  • Back up the existing environment - I like to back up all the SQL databases with a SQL maintenance plan. It's also easy to back up the ConfigMgr site on old using the native ConfigMgr Site Backup maintenance task. Restart the SMS_Site_Backup component to start the backup immediately and monitor progress in the smsbkup.log file.
  • Deploy new Windows 2012R2 server, fully patch and join domain - use any name for now but use the same drive configuration as old.
  • Install Windowd ADK 10 - you can still use ADK 1511 (download it here) . A new ADK version 1607 has just been been released and can be downloaded here. Official ConfigMgr support for ADK 1607 has not been announced at time of writing.
  • Install ConfigMgr 2012 pre-requisites on new as normal (roles and features)
  • Copy source content, content library, WSUS metadata share from old to new while retaining permissions - if you are using VMs it's easier to detach the VHDs from old and attach them to new.
  • Turn off old.
  • Rename new box to original Primary Site Server name
  • Optionally re-use the static IP address on new. It shouldn't matter as ConfigMgr uses DNS. However it can be useful to avoid recreating firewall rules.
  • Re-delegate permissions on System Management container
  • Install a supported SQL server version
  • Install WSUS (use SQL database) and carry out the initial WSUS metadata share configuration (use a different share name than previously, do not configure WSUS)
  • Stop WSUS services and detach WSUSDB
  • Rename SUSDB.mdf and SUSDB.ldf
  • Restore SUSDB database from old with overwrite option selected
  • Copy WSUS metadata from old share location to new share location
  • Start WSUS services
  • Install WSUS hotfix KB3095113
  • Install ConfigMgr 2012R2 and choose the recover site option, finish the wizard (we can only restore to the same ConfigMgr version)
  • Carry out the ConfigMgr 2012R2 post-recovery tasks as directed - eg update account passwords
  • Re-configure the Software Update Point to use port 8530/8531 instead of 80/443 - examine WCM.log for success
  • Verify ConfigMgr site and component status
  • Test ConfigMgr functionality
  • Run TestDBUpgrade for ConfigMgr Current Branch 1511
  • Perform in-place upgrade to ConfigMgr Current Branch 1511
  • Back up Configuration.mof (it will be overwritten by the upgrade)
  • Perform in-console upgrade to ConfigMgr Current Branch 1602 or 1606
  • Optionally install MDT and re-configure integration
  • Upgrade ConfigMgr clients to 1602/1606

Issues encountered


I encountered a number of issues during the process (mostly WSUS Issues).
  • If there is an existing WSUS GPO you must change the port from 80 to 8530
  • You may have to additionally open port 8530 between VLANs
  • I was unable to open the WSUS console. The following error appeared in the event log "The WSUS administration console has encountered an unexpected error. Index was outside the bounds of the array". This was solved by adding the HTTP Activation feature (I'd forgotten that one).
  • WSUS broke after KB3159706 - see TechNet forum for more details. This was solved by opening an elevated Command Prompt window, and then running "C:\Program Files\Update Services\Tools\wsusutil.exe postinstall /servicing"
  • Reporting was broken - there were duplicates of all reports preceded by an underscore. This was solved by removing and re-adding the reporting point


I hope some of the information here will be helpful for you. Until next time....

10 comments:

  1. Great post. Thanks. Does it matter if you do SCCM 2012 R2 > 1606 on the old server (1511 then update) then restore the backup to a Server 2012 R2 box? Any reason why you prefer restoring SCCM 2012 R2 to Server 2012 R2 then update to 1606? Thanks.

    ReplyDelete
  2. No it doesn't matter. It just makes more sense to do it this way. Then you don't have to worry about upgrading the ADK on the old server. Also, what if you have issues with the upgrades? You will have to spend time troubleshooting on a server that you are about to replace.

    ReplyDelete
  3. Hi
    we have SCCM 2012 SP1 no R2. Can we use this steps too ?
    Thanks

    ReplyDelete
    Replies
    1. Yes, this is supported for in-place upgrade to 1511

      Delete
  4. I am intending to also upgrade the remote SQL server from SQL 2008 to SQL 2016. That will mean restoring the old DB to a newer version of SQL. Do you see any issues here?

    ReplyDelete
    Replies
    1. You can't do that. You must use the same version of SQL for the restore.

      Delete
    2. i believe if we move database role to a new sql server (having sql 2016), it should work as long as version is same or higher.

      Delete
    3. That's different. I'm saying you have to restore to the same version.

      Delete
  5. Hi Gerry,
    Thank you very much for this (and the site)! Our scenario is to take our SCCM 2012 R2 SP1 server and build a new SCCM 1606 server. We would also be building a new SQL server. Then I would migrate the 2012 to the 1606 ; is that a supported path. I keep finding "You need to upgrade to 1511 before you migrate to 1606" notes and I'm confused about the migration path options. I think they are confusing the migration and in-place upgrade terminology.

    ReplyDelete
    Replies
    1. You don't need to do a ConfigMgr migration at all. You can do an in-place to 1511 and then an in-console upgrade to 1606. If you want to "migrate" to a later operating system then you should use the backup/restore method.

      Delete