Introduction to Windows Server Active Directory Domain Services and Active Directory Health
For most corporate networks, Windows Active Directory Domain Services is the critical backbone for the support of your enterprise information structure. An improperly performing Windows Server Active Directory can be the cause of the most minor of nuisance issues, up to and including as much as the complete failure of your corporate environment’s security and authentication structure and the loss of access to your data, systems, and network shared resources.
This introduction post on the subject of the health of your Windows Server Active Directory Domain Services is part one of an occasional series of blog posts that I will have on Active Directory Health.
Performing an Active Directory Health Check in small and midsize environments can be somewhat problematic for the local, in house network and resource administrators. Often times, those smaller businesses don’t always have dedicated, full-time Active Directory administrators, because they are subdivided among other operational tasks and additional administrative responsibilities. Additionally, some smaller companies often cannot afford the product licensing and / or the needed training to overcome the learning curve for available third-party tools that might otherwise help them resolve operational and maintenance issues with their Active Directory. Many times, these application suites would otherwise reveal critical insight into the current status of the directory service in the environment and allow the administrators to take corrective action before a critical issue rears its head.
Being in a position to proactively review and analyze the current operational status, performance, configuration, and all of the available event data for the Domain Controllers in your domain and in the different domains in the forest, enables resource and network administrators the ability to maximize the current performance of their active directory service.
So, what can you, the administrator of your corporate resources do, when your work situation is much like it is outlined above?
Short of having the ability to affect the real changes needed in staffing, outsourcing, tools, and / or additional training, you can try your hand as some of the tips and tricks that we are going to outline in this series of articles.
The topic of this blog post will focus on Backing Up Active Directory Domain Services
One of the first things you want to make sure you have is a good back up of your Active Directory and that you have the ability to perform a solid restore of that back up. Backing up and restoring your Active Directory will be necessary if there is an issue with the existing Active Directory data such as a consistency issue with it due to a corruption from a hardware failure or a software fault, or even in the situation of human error.
Best practices with respect to backing up AD are to perform them regularly and on a schedule so that when necessary, administrators can perform immediate restores as needed. In addition to regular backups on a given schedule, network administrators can also perform off schedule, “on the fly” backups when they feel the added need to do so (e.g. software installation or upgrade that touches the Active Directory).
To use Windows Server Backup tools, you must install Windows Server Backup Features in Server Manager. On a default installation of the Server 2012 R2 operating system, you will find that when you first run Windows Server Backup (Wbadmin.msc) from within the Server Manager Dashboard, you’ll receive a prompt that the tools need to be installed first.
Once it’s installed, it will be available on the Administrative Tools menu as a MMC snap in. The Windows Server Backup snap-in has two wizard options: a Backup Schedule Wizard and a Backup Once Wizard.
The Windows Server Backup GUI allows you to perform critical-volumes backups and full server backups. Generally, when you are including volumes that contain system state files, you are performing a critical-volume(s) backup; when you are doing a full server backup, you are pulling all the volumes on the system.
If you should decide that you specifically want to perform a system state backup, you will need to use the Wbadmin.exe command-line tool.
When you use the wizards for backing up critical volumes, you must know which volumes to select if you’re looking to make a special selection, or you can allow the wizard to select them when you specify that you want to enable system recovery. When you use the command-line tool for backing up critical volumes, the tool will automatically select the correct volume(s).
A System state back up will include all the files that are required to recover AD DS. The System state will include the data as outlined below and perhaps additional files, registry settings, and / or other additional information, depending on the server roles installed on the target system to be backed up:
- COM+ Class Registration database
- Boot files
- Active Directory Certificate Services (AD CS) database
- Active Directory database (Ntds.dit) file and log files
- SYSVOL directory
- Cluster service information
- Internet Information Services (IIS) meta data
- Additional system files that are under Windows Resource Protection
A Critical volume back up will include all volumes that contain system state files:
- The volume that hosts the boot files
- Bootmgr file
- Boot Configuration Data (BCD) store
- The volume that hosts the Windows operating system and the registry
- The volume that hosts the SYSVOL tree
- The volume that hosts the Active Directory database
- The volume that hosts the Active Directory database log files
When you perform a Full server backup, it will include all directly attached volumes on the server, including any detected Universal Serial Bus (USB) drives or other locally attached storage. It will not include the volume where the backup is being copied by default.
General, best practices for your back up configuration should include the following considerations:
- All unique data, including all domain directory partitions, should be backed up
- Daily backups should be made of all critical volumes on at least two unique domain controllers (the best practice is to always have more than a single domain controller in the domain / forest)
- If your configuration is made up of only a single domain controller in the forest / domain, or where you have an empty root domain with a single DC (as an administrative separation boundary) you will need to perform these backups more often.
- The completed backup data should be available in the local sites where they are likely needed for restoration.
- Remote copy / transferring is permissible, but it can lead to restoration delays if the most recent backup is needed but not “yet” transferred.
- With respect to single site domains, administrators should store at least the N-1 backup file offsite in a secure location and skip versions after rotation (N-3, N-5, etc.) This provides an extra level of redundancy in the situation where one physical location is unavailable (e.g. natural disaster).
- Regardless of the number of sites / storage locations, all backups should be stored in secured locations.
- You should make sure you have regular back up of the volumes that include the information on your DNS zones when you are not using integrated Active Directory replication.
- If you use integrated Active Directory replication, DNS zone data is captured as part of system state and critical-volume backups on domain controllers, as they are also DNS servers.
- When backing up primary and secondary standalone DNS zone information, you will need to back up the zone volumes on more than one set of DNS servers in your environment to make sure that each DNS zone is fully collected (in consideration of any pending zone transfers at the time of the backup, etc.)
- If you are using application directory partitions in your forest, you will need to backup those domain controllers that replicate the application directory partitions.
- You should also create additional backups of domain controllers in geographic locations where certain business considerations might apply:
- Sites where large populations of users exist, where mission critical work is performed, or where critical users need access (e.g. corporate executives or application programmers that would need access restored quickly.)
- Where the possibility of a wide area network (WAN) outage would disrupt business.
- Any location where the restore of a system would be cost prohibitive because of slow link speeds, the size of the directory database, time to recovery is too long, etc.
That’s a wrap on this segment; I hope you’ve enjoyed this portion of the occasional series on Active Directory Health and that you will return for future installments – thanks for following my blog posts!