Backing Up ConfigMgr
Everyone knows about the backup maintenance task for ConfigMgr. You configure that, and you’re good to go if your site ever fails. What you may not realize is that you actually need a little bit more than that if you don’t want to recreate your applications and packages and have to redistribute everything to your distribution points. Also, in case you’ve never looked, the backup maintenance task only keeps the most previous backup. If you want to keep multiple, you will have to do some scripting.
I will go over the other folders that you need to backup, how to retain multiple days’ worth of backups, and finally provide a PowerShell script that you can use to automatically do all of this for you.
There are at least five additional folders that you need to backup. The reason I say “at least” is because the number will depend on how many distribution points you have in your environment. The following folders will exist on any central administration server (CAS) or primary site server (PSS) that you have.
Additionally, you will need to backup the SMSSIG<drive letter>$ folder on each distribution point. This folder can be accessed by going to \\<server name>\SMSSIG$, which is the best way to access the share for backup. If you have a bunch of distribution points, this folder is not critical to backup. You will still be able to redeploy your distribution points from your reinstalled site. It will just increase the time it takes, because you will have to delete them from the system and add them back. If you have a bunch of applications or packages, this process can take a lot of time, so be careful and really consider whether it’s worth the extra time to script it and disk space to house the backups.
In both the SMSPKG<drive letter>$ and SMSSIG<drive letter>$, the <drive letter> is the drive letter where the folder exists.
As I said at the beginning, attached to this post is a PowerShell script to do the backup for you. You will need to change a few things. First, in line 2, change the directory where you want your backups stored. The script places the backups in folders for the date. For example, if my backups went to \\server01\backups\sccm, then 20160329, 20160330, and 20160331 would be subfolders containing the database backup created by the maintenance task, and the folders listed above. The \\server01\backups\sccm location is what I would enter in line 2:
This step creates a PowerShell drive for this location, which is much easier to reference later in the script.
Next, on line 5, change this to the directory where the ConfigMgr maintenance task saves it’s backup. The script actually copies that backup, which includes the database, to our new backup directory that also contains the content backups. The script grabs everything contained in this directory.
Finally, in line 8, set the number of days that you want to retain the complete backup. I recommend 7 days, but it’s up to you.
That’s it. Your script is ready to run.
Executing the Backup
There’s a few ways to execute the backup. First, you can schedule a task to run, but you want to ensure that it doesn’t execute until after the ConfigMgr maintenance task completes. My preferred method is to use the AfterBackup.bat script. This is a bat file that you can put on your CAS or PSS that ConfigMgr will execute after the ConfigMgr maintenance task completes. It should read like this:
C:\Windows\system32\WindowsPowerShell\v1.0\powershell.exe -executionpolicy bypass -noexit -command “. ‘E:\scripts\backup-sccm.ps1′”
Be sure to change the command parameter to the location of your script. Make sure to get the quotes correct, and keep the period and space. The PowerShell script that we are referencing should probably live on your CAS or PSS, so that ConfigMgr always has it available.
The AfterBackup.bat file must be stored in <ConfigMgr Installation Directory>\inboxes\smsbkup.box.
All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistant.