Schedule a System State Backup with PowerShell
In the wonderful world of Active Directory we're rather fond of System State backups. For starters, they allow for Authoritative and Non-Authoritative restores of both Active Directory and SYSVOL.
Hopefully, you'll never find yourself in a situation where you have to restore a System State backup, especially with the advent of the Active Directory Recycle Bin.
Anyway... how to use PowerShell to schedule a regular System State backup? What if you already use a product to backup? Well, I still recommend the following to compliment your existing Enterprise backup solution...
First up, make sure you have a somewhere to save the backup - a separate disk is fine and dandy.
Now, for the PowerShell:
Register-ScheduledJob -Name "System State Backup" -Trigger @{Frequency = "Daily"; At = "04:00"} -ScriptBlock {
#Create new backup policy
$Policy = New-WBPolicy
#Add System State to the policy
Add-WBSystemState -Policy $Policy
#Set backup location
$BackupLocation = New-WBBackupTarget -VolumePath "D:"
#Add backup location to policy
Add-WBBackupTarget -Policy $Policy -Target $BackupLocation
#Start backup using policy
Start-WBBackup -Policy $Policy
}
The Register-ScheduledJob cmdlet creates a scheduled task, called 'System State Backup', in the tasks scheduler library (taskschd.msc) at the following location:
\Microsoft\Windows\Powershell\ScheduledJobs\
The scheduled job runs daily at 04:00 am. The scheduled job executes a script block that performs a System State backup to the D: drive. A backup policy is created and to this we add that we want a System State backup (Add-WBSystemState) and the target backup location (New-WBBackupTarget). The job is then kicked off with Start-WBBackup.
You could tweak the script a little to backup to a time and date stamped, secure remote folder. You'll get a new, full backup every time doing this, rather than the incremental you get when backing up to a volume. This might be advantageous if you have plenty of space and wish to mount the NTDS.dit file in a recovery scenario with DSAMAIN.exe. The tweak:
#Define backup directory
$BackUpDir = "\\NINJALDS01\TEMP\$(Get-Date -Format yyMMddHHmm)"
#Create backup folder in remote location
New-Item -ItemType Directory $BackUpDir
#Define backup location
$BackupLocation = New-WBBackupTarget -Network $BackUpDir
#Add backup location into the policy
Add-WBBackupTarget -Policy $Policy -Target $BackupLocation
Here's how we look at the backup set (all backups performed, including ones to a remote drive):
Get-WBBackupSet
Here's how to get backups from a particular backup target:
$BackupLocation = New-WBBackupTarget -VolumePath D:
Get-WBBackupSet -BackupTarget $BackupLocation
And, here's how to see if our backup operations were successful, by querying the appropriate event log and event ID:
Get-WinEvent -LogName Microsoft-Windows-Backup -FilterXPath "*[System[EventID=4]]"
Comments
- Anonymous
January 01, 2003
@Dana - does the script block work outside of the scheduled job?- Anonymous
March 02, 2017
The comment has been removed
- Anonymous
- Anonymous
February 07, 2015
Thanks - Anonymous
March 06, 2015
Use PowerShell and DSAMAIN.exe to mount a backup of NTDS.dit. Have a good rummage around. - Anonymous
April 17, 2015
The term 'Register-ScheduledJob' is not recognized as the name of a cmdlet - Anonymous
April 17, 2015
I fixed the previous error by upgrading to Windows Management Framework 4.0. But now, when the job runs nothing happens. It says the operation completed successfully, but nothing is on my G: drive which is where I am pointing my backups. So I'm not sure what is going on... - Anonymous
September 09, 2015
The script works fine in a session where a user logged in but I am looking into setup to work when no users logged in. First I tried to modify the scheduled task once it been created this gives a event id 111 task terminated. - Anonymous
September 09, 2015
I was using a network path as well that's when it fails when no user logged in. If a local path then it works either case. - Anonymous
May 17, 2016
Awesome, thank you! - Anonymous
March 02, 2017
The comment has been removed