Recover a Site Database in ConfigMgr 2012 R2

In the event that your stand alone Primary Site has failed, assuming that you have a good backup (backup created by the Site Backup maintenance task), the process of recovering the site is not that dramatic. Lets say that your site database for some reason has been corrupted or failed. In such an event, using the Recover a site option is the way forward. Let’s go through the necessary steps to recover a failed site database.


In this scenario we have a ConfigMgr 2012 R2 stand alone Primary Site server with SQL Server 2012 CU3 (everything running on the same machine). The site database has been corrupted and we need to recover it from a good backup.

Recover a Site Database

When recovering a site database in ConfigMgr 2012 and later, use the setup from the installation media. If you’d launch setup from the site server, the option to Recover a site is greyed out. Since we’re recovering a corrupted site database, it’s necessary that we detach that corrupted database from the SQL Server first. Otherwise the recovery process would fail if we tried to recover a site database that already exists on the SQL Server.
1. Launch splash.hta from the ConfigMgr installation media and click on Install.
2. Select Recover a site and click Next.
3. Select Recovery the site database using the backup set at the following location. In this scenario we’re only recovering the site database, and therefor the site server recovery steps are greyed out. If you’ve backed up and recovered the site database using other methods, e.g. using DPM or other backup solutions, you should select Use a site database that has been manually recovered. But since that’s not the scenario here, we’ll not choose that option. Click Next.
4. On the Site Recovery Information page, we’d have the option to select a reference Primary Site or CAS if we’d have a hierarchy. Specifying such a site, would configure it as the authoritative source of data in the event that we would not have a site database backup or when conflicts occur between sites. In this scenario we only have a stand alone Primary Site, so there’s nothing for use to configure here. Click Next.
5. On the Product Key page, choose the licensed edition. In my lab environment I’m using the evaluation edition. Click Next.
6. Accept the license terms and click Next.
7. Click Next on the Prerequisite Licenses.
8. Either choose to download the prerequisite files, or if you have previously downloaded them, browse to the location. Click Next.
9. On the Site and Installation Settings page, the settings you’ll see specified here are taken from the site database backup of the site server specified earlier. Click Next.
10. On the Database Information page, you have the option to specify a SQL Server for the site database recovery. In a scenario when you have a stand alone Primary Site server with a remote SQL Server for the site database and the SQL Server completely fails, you can reinstall the SQL Server from the OS and up (assuming that re-installing the OS is needed) to a supported version of SQL Server. This can then be used for the site database recovery process. In our scenario, our SQL Server is running just fine and we’re only recovering the corrupted database. So we could just reuse the SQL Server and specify it’s FQDN. Click Next.
11. We’re now asked to specify the locations for the SQL Server data file and transaction log file. Leave the default locations and click Next.
12. Select wheter you’d like to join the CEIP or not and click Next.
13. On the Settings Summary page, click Next.
14. Once the prerequisite checks have completed, click Begin Install.
15. The recovery process now beings. This may take a while, so now would be a good time to stretch your legs. Once the process has completed, click Next.
16. The Post-recovery actions are now presented to you, and it’s recommended that you take those actions.
That’s all, your site database has now been recovered. For more information about site recovery in ConfigMgr 2012 R2, check out the documentation.


Nickolaj Andersen

Chief Technical Architect and Enterprise Mobility MVP since 2016. Nickolaj has been in the IT industry for the past 10 years specializing in Enterprise Mobility and Security, Windows devices and deployments including automation. Awarded as PowerShell Hero in 2015 by the community for his script and tools contributions. Creator of ConfigMgr Prerequisites Tool, ConfigMgr OSD FrontEnd, ConfigMgr WebService to name a few. Frequent speaker at conferences such as Microsoft Ignite, NIC Conference and IT/Dev Connections including nordic user groups.


  • FYI – an update to my findings.
    Prior to detaching the database, I ran the following first (in our LAB) from an elevated command prompt and it worked a treat:
    CD C:\Program Files\Microsoft Configuration Manager\Bin\x64\00000409

  • Thanks for the great article. Just one thing I was wondering, as we have detached the database, when the recovery is running the various components are logged as trying to shutdown, but of course if there is no backend database (as it was detached) then this seems to take 10 minutes per component before eventually each one fails to stop and is ignored.
    Is this expected (and as it’s currently only tried this for 3 components so far over 30 mins, could this potentially take hours to cycle through the 70 components before it considers all of them assumed stopped, or should we actually be shutting down the SCCM Windows Services first perhaps?
    Thanks in advance!