Running custom scripts
You can configure Recovery Manager for Active Directory (RMAD) to automatically run custom scripts on the RMAD computer before, after, or during the recovery operation.
This version of RMAD is supplied with the Microsoft Windows Script File (.wsf) file that serves as a template where you can insert your custom scripts written in the VBScript or JScript language.
The .wsf file has a number of XML elements where you can insert your scripts. Depending on the XML element where you insert it, your script will run
-
Before the recovery operation starts in the current project.
-
Each time before the restore from backup operation starts for a domain controller in the current project.
-
After the restore from backup operation completes for all domain controllers in the current project.
-
Before the reinstall Active Directory operation starts in the current project.
-
Each time before the reinstall Active Directory operation starts for a domain controller in the current project.
-
Each time the reinstall Active Directory operation completes for a domain controller in the current project.
-
After the recovery operation completes in the current project.
Technical overview
Recovery Manager for Active Directory performs the following functions:
-
Regular backup of domain controllers’ components across a network, including the Active Directory database, SYSVOL and Registry, and maintenance of one or more secure repositories containing the backed-up Active Directory data.
-
Wizard-driven, remotely administered restoration of Active Directory object data and Group Policy information from a point-in-time backup.
-
Active Directory, AD LDS (ADAM), and Group Policy comparison reporting, troubleshooting, and investigation.
Creating backups
Recovery Manager for Active Directory (RMAD) provides the facility to create backups of the Active Directory® components on domain controllers, including the Active Directory® database and Windows Server® Bare Metal Recovery (BMR) backups.
Both types of backups can be created for any Active Directory® domain controller available on the network. Backup creation is a task that can be performed on a regular basis without interrupting the operation of the domain controller.
RMAD lets you organize domain controllers into collections, and establish a backup scheduling frequency and “allowed hours” during which the backup process may run. Based on the frequency of updates to the directory data store, you can configure a backup schedule for each collection.
Depending on the requirements of your enterprise, you can configure a retention policy to specify how many backups are retained: for example, all saved backups or a number of the most recent backups. Different policy settings can be specified for different domain controller collections.
For Active Directory® backups, it is not necessary to maintain a single, centralized repository: several repositories, perhaps based on the site topology, can make your deployment more WAN-friendly. To minimize bandwidth consumption, RMAD employs agents that compress the data to be backed up, before sending it across the network.
Backup encryption
RMAD allows backups to be encrypted and protected with a password, to prevent unauthorized access.
For Active Directory backup encryption, the product uses FIPS 140-2 validated AES-256 algorithms.
Creating unpacked backups
You can have RMAD keep unpacked Active Directory® or AD LDS (ADAM) backups in any appropriate location on your network.
Unpacked backups can be reused for subsequent starts of the Online Restore Wizard or Group Policy Restore Wizard. The use of unpacked backups accelerates the backup data preparation step of those wizards, because the unpacking process may be a lengthy operation.
Using third-party backups
RMAD makes it possible to use Active Directory® or AD LDS (ADAM) backups created with third-party backup tools. Before using this feature, unpack the backup to an alternate location with the corresponding third-party backup tool, and then register the database file (ntds.dit or adamntds.dit) using the Online Restore Wizard or Online Restore Wizard for AD LDS (ADAM), respectively.
Cross-domain backup of group membership
When backing up Global Catalog servers, you have the option to force RMAD to collect group membership information from all domains within the Active Directory® forest. This option ensures that group membership spanning multiple domains is fully backed up.
It is recommended that you restore objects from Global Catalog backups that were created with this option. Otherwise, restored objects may not retrieve their membership in some local groups, because even Global Catalog servers do not store full information about group memberships. For example, information about membership in domain local groups is only stored in the home domains of those groups.
Considerations for backing up Active Directory®
In an Active Directory® environment, each domain controller maintains its own Active Directory® database. Therefore, a backup of the Active Directory® database is domain controller-specific. To completely back up Active Directory®, you must back up the directory database on every domain controller.
To restore deleted or corrupted objects, it is recommended to back up at least two domain controllers for each domain for redundancy. If you intend to restore cross-domain group membership information, then it is also necessary to back up a global catalog server.
Another reason for backing up the directory database on every domain controller is loose consistency. Replication of changes made to Active Directory® does not occur immediately. The replication process first accumulates all changes, and then provides them to the participating domain controllers. As a result, the directory database on any domain controller is normally in a state of loose consistency. The directory object data on individual domain controllers differs to some extent, given that replication updates are either in transit between domain controllers, or waiting to be initiated.
The age of the backup must also be considered. Active Directory® prevents the restoration of data older than the "tombstone lifetime" - a setting specified in Active Directory®. Because of this, an Active Directory® backup should be created at least once within the tombstone lifetime. However, it is strongly recommended that backups of the directory database be created more often than this.
Backup Storage
Backups created with Recovery Manager for Active Directory can be stored in multiple locations. Primary storage of backups allows for backup files to be saved on a distributed network, or on selected computers with physically restricted access. Recovery Manager considers these locations as primary storage and is referred to as Tier 1 storage.
Primary Storage (Tier 1)
Recovery Manager for Active Directory provides options for primary storage in local and remote locations. Local storage is refers to storage on the Recovery Manager console computer, where remote storage is storage on the backed up domain controller or other remote servers on network shares. These locations are remote due to not being on the Recovery Manager console computer. See the Local Storage tab and Remote Storage tab. For both local and remote storage locations, a primary backup path can be provided and an alternate backup path.
Primary storage is for the original backup files to be saved to the a safe location. For primary storage, the backup agent creates the backup file, compresses the data and then the file is saved to the configured storage locations. In the diagram below see lines number 1 to view the process that is taken to save the backup file to primary storage locations. The RPC protocol is used to save backups files to the console computer. For saving to remote storage locations SMB protocols are used.
The figure illustrates how Recovery Manager for Active Directory creates and saves backup files to primary storage locations.