A Configuration Manager (formerly SCCM, also called ConfigMgr or MECM) site is only as recoverable as the backup and paperwork you have on the day the site server dies. In this post I'll set up the Backup Site Server task properly, cover what it does not protect, explain why the CD.Latest folder matters so much, and finish with a readiness checklist you can review every quarter. The companion post walks through the site recovery itself, step by step.
How it works#
Configuration Manager supports two backup sources for a site recovery: a successful run of the built-in Backup Site Server maintenance task, or a site database you back up and restore yourself (for example with a SQL Server maintenance plan or Data Protection Manager). You can back up a central administration site (CAS) and primary sites. Secondary sites have no backup task; you recover them by reinstalling them from the console.
The backup task uses the SMS Writer service (SMS_SITE_VSS_WRITER) and the Volume Shadow Copy Service. It reads the control file <InstallFolder>\Inboxes\smsbkup.box\smsbkup.ctl, briefly stops the site services while the snapshot is taken, and then starts them again.
| Backed up by the task | Not backed up by the task |
|---|---|
| Site database (MDF and LDF files) | Content library and package source files |
| Site server registry keys | WSUS database and update files |
| Site server folders and files | Custom or modified SSRS reports, the report server database and its encryption keys |
The CD.Latest folder | User state data on state migration points; the System Center Updates Publisher database |
Each run replaces the previous snapshot in the destination folder. If a run fails halfway, you can be left with no usable snapshot at all, which is why archiving matters.
Prerequisites#
- Full administrator rights in the console and local administrator rights on the site server.
- A backup destination you create in advance: a local folder (the most secure, because you control the NTFS permissions), a UNC share, or local folders on both the site server and a remote SQL Server. The backup data isn't encrypted, so lock the folder down.
- Write permission for the right identity: Local System on a local folder, or the site server and SQL Server computer accounts on a share.
- An archive location off the site server, ideally covered by your normal backup product.
Step-by-step#
1. Enable the Backup Site Server task#
Go to Administration › Site Configuration › Sites, select the site and choose Site Maintenance Tasks in the ribbon. Edit Backup Site Server, select Enable this task, then Set Paths to choose the destination. Schedule it outside working hours, and turn on the option to raise an alert when the backup fails.
Run it at least every five days, because the site database keeps SQL Server change tracking data for five days by default. In a hierarchy, Microsoft suggests at least twice a week; daily is a sensible default. Note that the schedule uses local time when you run the console on the site server, and UTC when you run it from another computer.
2. Archive every snapshot with AfterBackup.bat#
After a successful backup, the task runs AfterBackup.bat if it finds one in <InstallFolder>\Inboxes\smsbkup.box. Use it to copy each snapshot to dated folders on another server, so a corruption that goes unnoticed for a few cycles doesn't leave you with only bad backups:
@echo off
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "D:\Scripts\Archive-CMBackup.ps1"$source = 'E:\CMBackup'
$archive = '\\backup01\CMArchive'
$target = Join-Path $archive (Get-Date -Format 'yyyy-MM-dd')
robocopy $source $target /E /R:2 /W:10 /NP | Out-Null
# Keep the 14 newest archives
Get-ChildItem $archive -Directory | Sort-Object Name -Descending |
Select-Object -Skip 14 | Remove-Item -Recurse -Force3. Add SQL Server backups where they fit#
A native SQL Server backup of the site database is a supported alternative or complement. It gives you point-in-time options and fits into the DBA team's existing routine. During recovery you restore it yourself and then choose the "manually recovered" database option in setup.
BACKUP DATABASE [CM_PS1]
TO DISK = N'F:\SQLBackup\CM_PS1_full.bak'
WITH COMPRESSION, CHECKSUM, INIT;If the site database lives in a SQL Server Always On availability group, keep running the Backup Site Server task for the site settings and files, but don't rely on the MDF and LDF files it produces. Back up the database directly with SQL Server instead, with the database in the Full recovery model, which the availability group requires. A SQL Server backup can't be restored straight into the availability group; you restore it on a standalone instance first and then move it back.
4. Back up what the task skips#
- Content library and package sources: include both in your file system backup. They must come back to the same paths, and the content library must be restored before you can redistribute content. The query
SELECT * FROM v_Packageagainst the site database lists every package source path. - WSUS: back up the WSUS database (SUSDB) and keep a note of the content folder; see the WSUS maintenance guide for keeping it lean.
- Reporting: back up the report server databases, the SSRS encryption key, and the source of any custom or modified reports.
- User state: back up the folders listed under Folder details on the state migration point properties.
5. Protect the CD.Latest folder#
CD.Latest holds the setup files that match your exact site version, including the Redist folder. You recover a site by running setup from a copy of it, not from the original installation media, because a site that has taken in-console updates can't be recovered from baseline media. The backup task copies CD.Latest into the backup destination, so your archived snapshots contain it. Without a matching copy you can't recover the site; the only workaround is to build a lab site at the same version, or use a working CAS or child primary as a reference site.
6. Consider a site server in passive mode#
Site server high availability adds a second site server in passive mode at a CAS or child primary site. It shares the site database and needs the content library on a remote share. Promotion is manual (Administration › Site Configuration › Sites, Nodes tab, Promote to active), there's no automatic failover, and only one passive server is supported per site. It shortens recovery from a lost site server dramatically, but it doesn't replace backups: it protects neither the database nor you from a corruption that replicates.
7. Document the site#
Setup resets account passwords during recovery, and several settings live outside the backup. Record, and store securely off the site server:
- Site code, site name, site server FQDN and installation path.
- SQL Server name, instance, database name, version and edition, and the SQL Server Service Broker port (4022 by default).
- Every account in Administration › Security › Accounts, with where its password is kept; PXE and task sequence passwords; Windows sideloading keys.
- Certificates: IIS web server certificates for HTTPS roles, imported distribution point certificates, and any SQL Server encryption certificate used for BitLocker management recovery data.
- Site system roles per server, installed out-of-band hotfixes, and cloud connections such as tenant attach.
Get-CMSiteRole | Select-Object NetworkOSPath, RoleName |
Export-Csv D:\CMDocs\SiteRoles.csv -NoTypeInformation
Get-CMAccount | Export-Csv D:\CMDocs\Accounts.csv -NoTypeInformationVerify#
- In Monitoring › System Status › Component Status,
SMS_SITE_BACKUPshows status message ID 5035 (backup completed without errors) and, if you use it, 5040 (AfterBackup.bat started). smsbkup.log(in<InstallFolder>\Logsand the backup destination) ends with the 5035 message. With a remote SQL Server, checksmssqlbkup.logon the database server; VSS writer problems show insmswriter.log.- File timestamps in the destination and the newest dated archive match the last scheduled run.
- No backup failure alerts in Monitoring › Alerts. If the task failed, fix the cause and restart the
SMS_SITE_BACKUPservice to run it again.
Recovery-readiness checklist#
- Backup Site Server task enabled, succeeding at least every five days, with failure alerts on.
- At least two weeks of dated archives off the site server, each containing
CD.Latest. - SQL Server backups of the site database (required for availability groups), plus SUSDB and the report server databases.
- Content library, package sources and user state folders in the file system backup.
- Site documentation, account list and certificate exports stored in a vault you can reach without Configuration Manager, Active Directory sign-in on the failed server, or the site's own file shares.
- A recovery rehearsed in an isolated lab, with timings, at least once a year and after major version upgrades.
- Your plan sits inside the wider disaster recovery order: Active Directory first (see the AD forest recovery guide), then SQL Server and Configuration Manager, alongside services such as Exchange Server.
Tips and gotchas#
- A backup you have never restored is a hope, not a plan. Test with an isolated network so the lab site can't talk to production clients.
- Pause the backup task during an in-console upgrade, and take a fresh backup right after it, so
CD.Latestin the archive matches the new version (see the upgrade guide). - Don't put the backup destination on the same disk as the site database; losing one disk shouldn't cost you both.
- Restoring to a newer SQL Server version is supported; changing the edition, for example Standard to Enterprise, isn't.
