Recover a ConfigMgr Current Branch site - my ramblings

System Center Configuration Manager landing page

I have some time off this week so I'm getting through some of the jobs that I've been putting on the long finger for a while. One of those jobs is to move my ConfigMgr lab to new hardware. I could've just copied the VHDX files and created new VMs but where is the fun in that? I haven't had to recover a ConfigMgr Current Branch site yet so I thought that this would be a good opportunity to test the process before I have to do it in production. Note that I will be recovering ConfigMgr Current Branch 1610 (standalone Primary Site).

I previously blogged about the new backup requirements for ConfigMgr Current Branch. You can read that blog post here. Essentially you must ensure that you back up the CD.Latest folder. This folder contains that installation files required to recover in case of a disaster and the contents change every time you upgrade. In order to recover a site you must have a copy of these installation files and the version MUST match the version of the site contained in the backup. During this process I will deliberately use the wrong installation files first to see what happens.

Backup best practice.

First I'd like to offer a little advice on backup best practice for ConfigMgr Current Branch (or ConfigMgr in general). The product includes a maintenance task which backs up the required files to recover a site (this includes the CD.Latest folder). However this isn't the recommended approach among serious ConfigMgr admins. It is recommended to use a SQL maintenance plan instead. You have a little bit more work to do to make sure that you include everything as CD.Latest folder is not automatically included. Steve Thompson has a great blog on this here.

Some of the considerations in a production environment are as follows:

• SQL backup compresses the files rather than just copying them
• SQL backup includes retention periods and data integrity checks
• SQL backup allows you to select other databases like ReportServer and SUSDB
• SQL backup does not require any interruption to ConfigMgr services
• SQL backups allow you to configure email notifications
• SQL backup allows more scheduling control

Remember also that there are a number of additional items that should be backed up to assist in recovery in case of a disaster, for example:

• Make a note of the current SQL server version (very important)
• Content library
• Source files
• SSRS

OK, so I've spent some time going on about why SQL backup is better. However I didn't use it for this job. I used the trusty maintenance task as it's only my lab and just a once-off job. I also didn't bother with the additional items. I just copied what I wanted to retain.

Preparation

So what is to be done in advance? The following tasks are required once I have my backup:

• Turn off old CM server (if it is still alive)
• Create new VM and install Operating System (does not have to be the same OS as before but the same drive configuration is recommended), patch and join to domain
• The server name must be the same as previously
• Install server prerequisites (Nickolaj Andersen has a great tool for this)
• Install ADK for Windows 10 (there are a number of versions but they all have some issues - do your research first before you pick one)
• Install the same SQL version as before

So now let's recover the site. I'll do it wrong first to show you the difference.

Recover the site - the wrong way

Let's use traditional thinking here. In previous versions of ConfigMgr we would just download the ISO and recover from backup - so let's do that.

The latest version of Current Branch is 1606. See that there are Current Branch and Long Term Service Branches. LTSB is not suitable in any situation in my opinion. 

What happens when I try to install this version and use my 1610 backup?

The restore fails as expected with the error:

"The site was being recovered using a different build number than the build version of the ConfigMgr backup. The recovery build number must match with the previous installed build version".

(I don't like the way the wizard allows you to continue to the actual setup before failing. It should fail earlier, perhaps at the dialog box where you configure the location of the backup files. After all the wizard interrogates the backup at that stage and knows that you are recovering a primary site as opposed to a CAS. In my opinion it should also know at that stage that there is a version mismatch.)

Recover the site - the correct way

Now let's do it right. Copy the backup contents to the new server and launch splash.hta (found in the root of CD.Latest).

Complete the wizard to recover the site. It's pretty similar to the regular site installation wizard.

Select "Install".

Read the information before you begin.

Choose "Recover a site".

In my case I want to recover the site server and database from backup. Your needs may be different.

The wizard detects that you have a backup of a primary site. Other options are greyed out.

Enter the license key.

Accept the various license terms.

Download the prerequisite files.

Choose the ConfigMgr installation folder.

The server name and database name are prepopulated.

Choose the database and log file locations (I'm choosing defaults in my lab - you would not do this in production).

Read the telemetry information. Click Next to continue.

Read the settings summary and click Next to continue.

Prerequisites check has passed with some warnings. Click "Begin Install".

The recovery commences. This can take a while. This one took about 45 minutes for a very small lab environment......

...and we're done.

Finally we are warned about some post-recovery tasks.

Everything looks OK.

Note: now have a look at the security permissions on the System Management container. The old site server computer account will be seen as Unknown (even though the new one has the same name). Remove it and delegate full control to the new server.

I hope this blogpost was useful. Until next time.....