This will be the second 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.
In the first part of the Blog here we discussed what is contained in the core ConfigMgr built-in backup, how to create the Task, how to modify the SMSBCKUP.CTL file
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 Recovery
If you have ever had to do a recovery of a ConfigMgr environment, you will know that it is not a fast process by any means.
You need to have a Server ready (built if one was not available) have all your source installation prerequisites (SQL, Windows ADK, etc) and of course the Backup of ConfigMgr that you want to restore from.
Yes there are many ways that you can restore ConfigMgr, depending on what component is in the failed state (just SQL, SQL\SCCM Site, Just SCCM Site), and a bit beyond the scope of this post.
Once you have started the recovery and initial process has completed, the Data Replication Service (DRS) will rebuild the replication links with other servers in the Hierarchy, and the Data replication will start synching
While this process is running, your ConfigMgr environment will be in “Maintenance mode” and no new changes can be made untill the site is all caught up with Global and Site Data Replication.
Depending on the size of the Database and HOW OLD is the backup, this may take up to a day
Supplemental tasks for ConfigMgr Backups
The following items need to be included in your Backup plan for ConfigMgr:
- Custom SQL Services Reporting Services (SSRS) reports
- WSUS database
- Content files:
Content library
Package source files - Custom software updates
- State Migration Point
Content Files
Content library: Typically stored on the drive with most free space during install of the site server, the SCCMContentLib must be restored before you can redistribute content to distribution points.
Package source files: These must be restored before you can update content on distribution points. Run the following query in SQL Server to find the package source location for all packages and applications:
SELECT * FROM v_Package
These files must be restored to the same location where they were before the failure.
State Migration Point: Used to store the user state data in operating system deployment scenarios where you want to retain the user state of the current operating system •Folders that store the user state data are listed in the properties for the state migration point
What is Global and Site Data?
Global Data: this is the data that is common across the Hierarchy, and shared between all the management servers. i.e Collections, Update Metadata
Site Data: This is the unique data per site that is stored on each Primary. i.e Hardware Inventory, Software Distribution
SQL Server Change Tracking
- Change tracking lets Configuration Manager query for information about the changes that have been made to database tables after a previous point in time
- A site database is configured to have a retention period of 5 days. It is mostly pointless to have data then that is backed up, every 7 days or more
- The recovery process works differently depending on whether the backup is inside or outside the retention period
- Recovery will reinitialize site or global data:
- The primary site reinitializes the global data from the central administration site: The recovery process removes the existing global data for the primary site in the primary site database and replaces the data with the global data that is copied from the central administration site
- The central administration site reinitializes the site data from a primary site: The recovery process removes the existing site data for the primary site in the central administration site database and replaces the data with the site data that is copied from the primary site
To Troubleshoot Global Data Reint, have a look at the Docs Site
To Troubleshoot the Site Data Reint, have a look at the Docs Site
Why It Is Important to Back up WSUS
The initial synchronization of Windows Server Update Services (WSUS) into Microsoft System Center Configuration Manager can take a significant amount of time when WSUS servers are switched. This is a function of the amount of data, and the performance of the Microsoft SQL Server where the Configuration Manager database is hosted. Having a backup of the WSUS database with which WSUS can be restored significantly, helps reduce the recovery time.
Also Updates in the Hierarchy are signed by the WSUS server when downloading them.
Upon creation then of a new WSUS Top-level server, the updates that you have in the packages already, will have to be re-downloaded and deployed again, after the initial massive sync from the online Microsoft catalog servers.
This sync may take up to a couple of hours, depending on the categories, products and classifications that you specify needs to be synched
Additionally, the first time a client computer does a software update scan, it downloads more than 9 megabytes (MB) of data depending on the software and operating system of the client, and the same performance will happen every time the client switches to a different Software Update Point (SUP) that is using a different Software Update Services Database (SUSDB). To avoid a spike in Network traffic after a WSUS rebuild, it is important to restore the same SUSDB database.
Why It Is Important to Back up SSRS
Configuration and Compliance Management is important for every company. Custom reports and schedules configured in Configuration Manager SQL Server Reporting Services (SSRS) are an important part of this service. The IT staff have also invested much time to customize reports or subscriptions according to their needs. Therefore, it is important to add them as a part of the backup plan to ensure that this investment of time and effort is not lost.
Prerequisites files that need to be backed up for easier restoration
- ReportServer .mdf and .ldf files (SSRS Database)
- ReportServerTempDB .mdf and .ldf files (SSRS Temp Database)
- rsreportserver.config
- rssrvpolicy.config
- web.config
- bin\ReportingServicesService.exe.config
- the Reporting Services Encryption Key
It also assumes that a new server with the same name as the server is restored and joined to the same domain.
SQL Server Always On considerations
Backup database files
When a site database uses an availability group, run the built-in Backup Site server maintenance task to back up common Configuration Manager settings and files. Don’t use the .MDF or .LDF files created by that backup. Instead, make direct backups of these database files by using SQL Server.
Transaction log
Set the recovery model of the site database to Full. This configuration is a requirement for Configuration Manager use in an availability group. Plan to monitor and maintain the size of the site database transaction log. In the full recovery model, the transactions aren’t hardened until it makes a full backup of the database or transaction log. For more information, see Back up and restore of SQL Server databases.
Changes for site recovery
If at least one node of the availability group is still functional, use the site recovery option to Skip database recovery (Use this option if the site database was unaffected).
Starting in version 1906, site recovery can recreate the database on a SQL Always On group. This process works with both manual and automatic seeding.
In version 1902 or earlier, when you lose all nodes of an availability group, before you can recover the site, first recreate the availability group. Configuration Manager can’t rebuild or restore the availability node. Recreate the group, restore the backup, and reconfigure SQL. Then use the site recovery option to Skip database recovery (Use this option if the site database was unaffected).
For more information, see Backup and recovery.
