This will be the first part of a new series of posts, regarding different topics in ConfigMgr.
ConfigMgr can be a daunting product to use, and especially to someone new to the product (or even some old hands).
To simplify some of the concepts, and to assist you in better understanding, and ultimately using the tool more effectively, this series is being created.
First up, we have the Backing up of ConfigMgr.
By far, I personally believe that this is the most important configuration that needs to be done, and done correctly, in your ConfigMgr environment, in order to save you headaches, when you have to restore.
Unfortunately, almost every customer that I engage with, have some issue around the backups, not being configured correctly. Most of this is due to the complexity of the restore process, and the things that are never thought
Part 1 of this blog will focus on the core backup of ConfigMgr.
Part 2 of this blog will focus on the supplemental Backup tasks that need to be carried out, as the built-in backup is not sufficient for a fast, painless recovery.
So Let’s talk Backups
Success and failure of a recovery process is directly related to strict execution of a backup plan and control mechanisms for it.
The objects that have to be included in the backup plan depend on the type of hierarchy and the number of sites in your hierarchy.
The Configuration Manager Backup Process can be divided into four basic steps:
- Backup of the Microsoft SQL Server database.
- Backup of the Configuration Manager configuration (state).
- Backup of additional objects.
- Archiving all of the above.
Basically, Configuration Manager offers an internal backup task to execute backups on a schedule. This task would take care of steps from 1 through 2 only.
For the database portion of the backup, alternatives to using the built-in backup task are Microsoft SQL Server Backup and System Center Data Protection Manager.
For details on how to use System Center Data Protection Manager, see:
When backing up Configuration Manager configuration, no other tool than the built-in maintenance task is supported.
Step 3 and Step 4 have to be implemented externally. This means, Configuration Manager does not provide any mechanisms to run step 3 and step 4. Part of step 3 is usually performed manually, while other portions of that step can be automated.
Step 4 is accomplished by using external backup tools or the after backup.bat file (for more information, see below The AFTERBACKUP.BAT File). We can use Microsoft System Center Data Protection Manager or any other backup solution to archive the contents.
Built-in Backup Maintenance Task
The Built-in Maintenance Task starts the Backup Service to initiate the Volume Shadow Copy Service (VSS) Backup. It is intended to enable administrators to restore the Site Database and the configuration settings for a Configuration Manager Site.
Objects Included in Backup
These are the objects, which are included in a site Backup, when we do not modify the smsbkup.ctl file.
- Configuration Manager Site database (local or remote).
- Configuration Manager Installation folders (recurse):
Additional files that form part of the backup:
- install.map – This file contains configuration settings for the site.
- ConfigMgrAdminUISetup.log – This is the log file from console installation.
- BackupDocument.xml – This is the SMS Writer result file.
- ConfigMgrBackup.ini – This is the basic configuration for the backup task created at runtime.
- smsbkup.log – This is the backup task result file, containing all actions for this one task.
- SMS registry keys (saved in SMSbkSiteRegSMS.dat).
- CD.Latest folder – downloaded ConfigMgr CB Installation files for your site version
As you can see, this is the core information needed to restore a ConfigMgr environment.
One important note is to always remember that Virtual Machine Snapshots\Checkpoints are NOT a viable (or supported) backup method, which largely has to do with how the data replication between sites work, and the versions of replication groups in the DB, how the data is shared across the environment etc…
It is advisable to have the backup location on a different volume than the one that stores the SQL Server database files, so that the writes to the volume is minimal when volume snapshot is active.
Table 1: Description of the backup task configuration options
|Enable task||Check to enable the task for this site|
|Backup Destination||Destination path for the Backup folder. Can be local or Network Universal Naming Convention (UNC) path. If local path is chosen and the SQL Server database is remote, both local paths have to be defined. It is advisable to have the backup location on a different volume than the one that has SMS data and the one that has SQL Server database files, so that the writes to the volume is minimal when the volume snapshot is active.|
|Schedule||Select days and time of day.|
|Enable Alerts for Backup task failures||Enable to let the task create alerts if backup fails.|
When the task runs, it recreates the folder [BackupDestinationPath]\[SiteCode]Backup
To help prevent tampering of the backup files, store the files in a secure location. The most secure backup path is to a local drive so that you can set the New Technology File system (NTFS) file system permissions on the folder. Irrespective of which option you select, Configuration Manager does not encrypt the backup data that is stored in the backup path.
Here are some pros and cons regarding the location of backup set:
- Local drive on site server for site data and database: Specifies that the backup files for the site and site database are stored in the specified path on the local disk drive of the site server. You must create the local folder before the backup task runs.
The Local System account on the site server must have Write NTFS file system permissions to the local folder for the site server backup.
The Local System account on the computer that is running SQL Server must have Write NTFS permissions to the folder for the site database backup.
- Network path (UNC name) for site data and database: Specifies that the backup files for the site and site database are stored in the specified UNC path. You must create the share before the backup task runs.
The computer account of the site server and the computer account of the SQL Server, if SQL Server is installed on another computer, must have write NTFS and share permissions to the shared network folder.
- Local drives on site server and SQL Server: Specifies that the backup files for the site are stored in the specified path on the local drive of the site server, and the backup files for the site database are stored in the specified path on the local drive of the site database server. You must create the local folders before the backup task runs.
The computer account of the site server must have Write NTFS permissions to the folder that you create on the site server. The computer account of the SQL Server must have Write NTFS permissions to the folder that you create on the site database server. This option is available only when the site database is not installed on the site server.
The folder name or share name that is used for the backup destination does not support the use of Unicode characters.
Checking the Status of a Backup
The Backup Maintenance Task creates the file ConfigMgrBackup.ini containing basic information about the site setup configuration. These parameters are used to prepopulate fields in the Setup Wizard interface, when restoring a site.
Also, the folder contains an XML file with the particular steps executed during Backup Task (VSSWriter):
Verify that the Site Backup maintenance task is completed successfully by reviewing all of the following:
- Review the BackupDocument.xml file for occurrences of backupSucceeded=”yes” for each group.
- Review the timestamp on the files in the backup destination folder that the Backup Site Server maintenance task created. Verify that the timestamp has been updated with a time that coincides with the time when the Backup Site Server maintenance task was last scheduled to run.
- In the Component Status node in the Monitoring workspace, review the status messages for SMS_SITE_BACKUP. When site backup is completed successfully, you see message ID 5035, which indicates that the site backup was completed without any errors.
- When the Backup Site Server maintenance task is configured to create an alert, if backup fails, you can check the Alerts node in the Monitoring workspace for backup failures.
- In <Configuration Manager Installation Folder>\Logs, review Smsbkup.log for warnings and errors. When site backup is completed successfully, you see:
with a timestamp and message ID
When the backup maintenance task fails, you can restart the backup task by stopping and restarting the SMS_SITE_BACKUP service.
When the Alert option is activated, alerts appear on the home page of the administration node, and in the monitoring space of the console.
The SMSBKUP.CTL File
The SMSBKUP.CTL definition file is located in [System Center Configuration ManagerInstallationFolder]\inboxes\smsbkup.box. It controls which actions are taken by the backup task and the order of those actions.
The default file would contain the following actions:
- Stop related services
- SMS_SITE_COMPONENT_MANAGER and SMS_EXECUTIVE
- File backup
- Registry Backup
Editing the SMSBKUP.CTL definition file is supported by Microsoft. The file contains an explanation for the syntax of each action. The customer might, for example want to stop any additional services before the backup starts or they may want to include additional files in the backup process. The file contains sections that are prepared for these customizations.
Customizations and Examples
We can customize the file for additional functionality. It is a text based file, which can be edited using notepad (or similar tools).
A SMSBKUP.CTL file containing wrong syntax will lead to an inoperable VSS_Writer Service (SMS_SITE_VSS_WRITER).
Only add customizations in those sections that are marked with E d i t i n g A l l o w e d.
The SMSBKUP.CTL file uses some default variables as shown below:
Variables taken from the Site configuration
|SITE_CODE||Three characters site code|
|SITE_DB_SERVER||Site’s site system running SQL server|
|PROVIDER_SERVER||Server hosting SMS provider|
|SITE_SERVER_ROOT_DIR||SMS root directory on site server|
|SITE_DB_NAME||Site database name|
Variables created inside the SMSBKUP.CTL file
SITE_SERVER_DEST = %SITE_BACKUP_DESTINATION%\SiteServer
SITE_DB_SERVER_DEST = %SITE_BACKUP_DESTINATION%\SiteDBServer
PROVIDER_SERVER_DEST = %SITE_BACKUP_DESTINATION%\ProviderServer
Define additional Variables
Where MyToken is the token variable and FOO is its value.
Stop Services and tasks
Where %SITE_SERVER% is auto replaced with the site server name and SMS_SITE_COMPONENT_MANAGER is the Service name (not the display name of the service).
This makes the backup execution pause for the specified number of minutes.
Backup additional files
file %SITE_SERVER_ROOT_DIR%\scripts %SITE_SERVER_DEST%\SMSServer\scripts
file c:\Default_Unattended.xml %SITE_SERVER_DEST%
Source File Destination folder
Uses either available variables or local full paths.
Backup additional Registry hives
reg \\%SITE_SERVER%\HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate %SITE_SERVER_DEST%\WindowsUpdate.dat
Start a program or service
Any change to the smsbkup.ctl file will require the VSS Writer Service to be restarted for the changes to take effect.
All changes are reflected in smswriter.log in the configuration manager logs folder.
Every step within the CTL file is logged in SMSBKUP.LOG:
When the CTL file contains invalid data, backup will not finish successfully, and you will see errors in smswriter.log
The afterbackup.bat File
The afterbackup.bat file must be created manually and placed in the following directory to have it executed: [System Center Configuration ManagerInstallDir]\inboxes\smsbkup.box
When the backup task executes, it checks the folder for existence of the file and if it is present, it will be executed.
The AfterBackup.bat file will only be triggered, when the backup task is completed successfully.
Message in SMSBKUP.LOG if file is not found:
AFTERBACKUP.BAT file does not exist at its predefined location SMSBKUP inbox.
Message in SMSBKUP.LOG if file is found:
Started AFTERBACKUP.BAT successfully.
Actions of the afterbackup.bat file are not logged in SMSBKUP.Log, so if you want those recorded, you will need to implement logging inside the afterbackup.bat file.
This is an example of how the afterbackup.bat might look like. It is a simple form of copying the snapshot folder to a network location and does not contain a compression mechanism nor retry, in case of a network failure.
rem only works for german date/time
rem adjust as appropriate for your regional settings
if exist %TARGET% goto :FollowUp
if not exist %TARGET% md %TARGET%
echo copy files
xcopy “%SOURCE%” “%TARGET%\” /e /y /c /v
Compressing the Snapshot Folder
We recommend to compress the snapshot folder. When we use the afterbackup.bat file to archive the snapshot folder, we cannot rely on the backup tool compression mechanism. As Windows does not provide a tool for this purpose, customers are encouraged to use their preferred compression tool to compress the folder before it is archived.
Using the SQL Server Maintenance Plan
Configuring the SQL Server Maintenance Plan to make a backup of the Configuration Manager database will give you a backup of the Configuration Manager database only. In certain scenarios, it might be a good choice to let SQL Server backup the databases.
For more information on how to setup a Maintenance Plan to back up the Configuration Manager Databases
Remember that a maintenance task for cleanup should be implemented to remove old backups. For more information, See: SQL Maintenance cleanup
Checking the Status of a Backup
Open Microsoft SQL Server Management Studio and expand Management > Maintenance Plans. On the context menu of your backup maintenance plan, select View History.
Activate Job History for the desired database and look for the success message:
Backup ReportingServices DBs.Subplan_1,,,The job succeeded.
Volume Shadow Copy Configuration
The Volume Shadow Copy Service (VSS) is a set of (COM) Application Programming Interfaces (APIs) that implements a framework to allow volume backups to be performed, while applications on a system continue to write to the volumes. The VSS provides a consistent interface that allows coordination between user applications that update data on disk (the SMS Writer service), and those that back up applications (the Backup Manager Service). With this service, you can create a point in time image (shadow copy) of one or more volumes. These shadow copies can then be used to perform backup operations.
For more information about VSS, see the topic in the Windows Server TechCenter: Volume Shadow Copy Service
The Configuration Manager backup process uses the Windows Volume Shadow Copy Service, and associated components to perform site backups.
VSS requires sufficient storage space to create and maintain shadow copies. By default, the storage association (where VSS keeps the differences) is set to the same drive being shadow copied (self). Using the default storage association, with the source and backup destination on the same volume causes VSS to shadow all changes to the volume while the snapshot is active, and also increases the disk churn while the backup files are being written. This can lead to high disk Input/output (I/O) and disk space consumption during the backup process. If too much space is used, then the snapshot creation, and subsequently the Configuration Manager Site backup task can fail.
Table 3: Benefits of the backup methods
|Benefits of using the Backup Maintenance Task in Configuration Manager||Benefits of using the SQL Server Backup task|
|It is built-in, so you can configure it directly within the console without having to go somewhere else to configure, run, or monitor your backups.||By using SQL Server compressed data files for backup, you will reduce backup storage costs when compared to using the Configuration Manager Backup task.|
|We generate in-console alerts if the backup task fails.||No downtime of Configuration Manager during backup.|
|We create an INI file during backup that we read during recovery to auto-populate most of the Setup wizard, so you cannot accidentally input incorrect information or options that might cause recovery to fail.||Maintained by SQL Server Admin|
|You can modify the backup control file (smsbkup.ctl) to change the behavior of the backup service.||More granular Backup configuration|
|As we backup the logs directory, you will be able to go back and look at the logs from your latest backup.|
|Maintained by Configuration Manager Admin.|
Using Data Protection Manager to Back up Your Site Database
Starting in System Center 2012 Configuration Manager SP1, you can use System Center Data Protection Manager to back up your site database. You must create a new protection group in System Center Data Protection Manager for the site database computer. On the Select Group Members page of the Create New Protection Group Wizard, you select the SMS Writer service from the data source list, and then select the site database as an appropriate member.
Configuration Manager does not support Data Protection Manager backup for a SQL Server cluster that uses a named instance, but does support Data Protection Manager backup on a SQL Server cluster that uses the default instance of SQL Server.
Even though we have enabled here the backing up of ConfigMgr (Site settings) and the SQL DB, this is still not sufficient for a complete restore
In Part 2 we will be discussing the additional tasks that need to be taken, as well as the regularity of the backups, why it is important to back up daily.
I hope that the above has given you some guidance on how the built-in task works, how we can use the SMSBKUP.CTL file to add to our backup sets.