When it comes to backing up the controllers (DCs) in an Active Directory (AD) forest, each DC is a backup of the other DCs within any forest domain. So long as just one DC is operational for a domain, the domain is in service. New domain controllers can be added and will quickly synchronize with the others. If one DC fails, the others can take its place without interuption. To ensure restorability an enterprise administrator need only back up the "System State" of one DC in each domain of the forest. Taking a system state backup of one DC in each domain will allow the administrator to recreate the entire domain (including user accounts and passwords) in the event all domain controllers happened to become damaged, disabled or otherwise corrupted.
NOTE: This analysis assumes that all DCs in an AD forest are used simply as DCs, providing only services which are consistent with DCs. Any add-on third party services such as SSH or any additional applications are not included in a System State Backup.
The system state is not a complete server backup but a smaller subset representing the server's operational state at the time of backup. This includes the following list of items assuming they are installed on the server in question.
You can restore system state to the same server, or another server with identical hardware.
Using the Server Manager utility (Administrative Tools -> Control Panel) install the "Windows Backup Server" feature. This is the native Microsoft software which will perform the backup process. Remember, this is not a server roll which can also be installed using the same wizard.
Like other Windows features, the Windows Backup Server feature writes events in the server's Application event log to record begining and ending of backups as well as errors and failures. However, other log files are created for each run of the Windows Backup Server software. These are text files recorded in the C:\Windows\Logs\WindowsServerBackup\ folder. It is important to examine both log sources when debugging backup issues as both sources record different kinds of information.
For the time being we will be maintaining the SSBs for each of our forest domains on a special network share provided by our core environment SAMBA server smb-files.cs.uwaterloo.ca. This will be neseccary for two reasons.
To this end, the following share configuration has been added the the smb.conf file on the core SAMBA server.
[adbackups] writable = yes printable = no csc policy = disable path = /usr/home/adbackups browsable = no read only = no ; ea support = yes strict allocate = yes ; create mode = 0600 directory mode = 0700 guest ok = no valid users = CS-GENERAL\ctucker, ctucker preserve case = yes case sensitive = no hide dot files = yes hosts allow = 10.0.0.0/255.0.0.0
NOTES:
It is always recommended that scheduled or daemon tasks be driven by service accounts posessing only sufficient authority to perform the prescribed task. To this end the user account CSCF\cscf_server_backups has been created in the CSCF forest. It is a member of the Builtin domain group Backup Operators (in each forest domain) which is authorized to perform backups on all domain servers including domain controllers. This account's credentials will be supplied to the Windows Server Backup console when configuring the scheduled backups of the domain controllers.
On its own CSCF\cscf_server_backups will not be authorized to access the above network share \\smb-files.cs.uwaterloo.ca\adbackups to store backups. This can be corrected by mapping the account CSCF\cscf_server_backups to a SAMBA server account with authorization to read and write on this share. In the [global] section of a SAMBA server's smb.conf file the option username map can point to the location of a text file where Active Directory accounts can be mapped to accounts known to the local SAMBA server. In this case the following mapping was created which effective gives CSCF\cscf_server_backups read/write access to the adbackups network share.
...../username_map.txt:
ctucker = CSCF\cscf_server_backups
This workaround may be required if the domain controller utilizes Symantec Endpoint Protection version 12. System State backups have been known to fail with the following errors.
According to Symantec support, this problem is caused by the Application and Device Control (ADC) module installed with Symantec Endpoint Protection. Currently, uninstalling this module is the best way to prevent the above error from occuring. Symantec is aware of this bug and hope to have a fix for a future update of Endpoint Protection. To uninstall the ADC perform the following steps.
This fix may be required if the domain controller resides as a guest system on a VM Ware server. System State backups have been known to fail with the following errors.
The above mentioned string C:\windows\\systemroot\ (note the double \\) does not exist as a real Windows system path. If the backup service was looking for critical information there then it would not have found it. Hence explaining the rather cryptic error in the Application Event Logs.
Many blogs point to an error in the HKLM\SYSTEM\ControlSet\Services\LSI_SAS registry key with the value for ImagePath being incorrect. Instead of systemroot\system32\drivers\lsi_sas.sys it should read as system32\drivers\lsi_sas.sys. Making this correction should prevent this specific backup failure.
Open the Windows Server Backup console (Constrol Panel -> Administrators Tools) S