SOLUTIONS WALKTHROUGH

Surviving Microsoft
Active Directory Failures
with Rubrik

Rubrik Technical Marketing

September 2023
Table of Contents

3 OVERVIEW
3 Technology Overview

3 Introduction to AD Replication

6 Time Synchronization

9 Name Resolution With DNS

10 Prerequisites

12 INTRODUCTION TO RUBRIK VM RECOVERY OPTIONS

13 PHYSICAL WINDOWS RECOVERY OVERVIEW

13 RECOVERING ACTIVE DIRECTORY DOMAIN CONTROLLERS WITH RUBRIK

13 Introduction to AD Backup and Recovery

14 Restoring an Individual Active Directory Domain Controller

15 Non-Authoritative Restore With NTFRS Replication

16 Non-Authoritative Restore With DFS-R Replication

18 Restoring an Entire Active Directory Domain

19 Authoritative Restore With NTFRS Replication

21 Authoritative Restore With DFS-R Replication

23 Restoring an Entire Active Directory Forest

24 VERIFYING AD DC RECOVERY SUCCESS

24 Windows Event Viewer

27 DCDiag

29 RepAdmin

30 CONCLUSION

30 VERSION HISTORY
 OVERVIEW

This document walks through the process of recovering either a failed individual Active Directory (AD) Domain
Controller (DC) or an entire domain in the context of a Disaster Recovery Plan (DRP) with Rubrik.

Although Microsoft AD Domain Services (DS) is a distributed service leveraging data replication at the
application level, it is sometimes better to recover a failed DC rather than deploying a new Windows Server
machine and promoting it to a new DC in the same domain. For instance, in the case of a DRP where the
recovery site doesn’t normally host any running workloads, it’s not possible to rely on native AD replication and
have a couple of DCs already running on the DR site. Moreover, in the event of a total failure of the primary
site, it would be required to seize the Flexible Single Master Operations (FSMO) roles to have a fully functional
directory back up and running. This becomes an even greater challenge when considering failback or test
failover operations.

Throughout this document, users will be provided with steps to properly and safely recover Microsoft AD DCs
with Rubrik.

TECHNOLOGY OVERVIEW
Before describing how to actually recover AD DCs with Rubrik, it’s important to understand some of the key
concepts and technologies that are critical for Active Directory to work.

Introduction to AD Replication
Active Directory Domain Services are Microsoft’s multi-master directory services. As per Microsoft, AD DS
provides “secure, structured, hierarchical data storage for objects in a network such as users, computers,
printers and services. Active Directory Domain Services provide support for locating and working with
these objects.”

This multi-master, distributed architecture allows you to create or modify objects from any writable DC in the
forest or domain. These changes are then replicated to all other DCs using one of the two replication methods
available in Windows Server:

• File Replication Service (NTFRS)

• Distributed File System Replication (DFS-R)

Understanding which replication technology is utilized in your environment is critical to ensure you will take the
right steps to recover AD DCs in the event of a failure.

Keep in mind that if the functional level of your domain is Windows Server 2003, then NTFRS is used to replicate
AD data. The use of DFS-R for the same purpose was introduced with Windows Server 2008. But having AD
DCs running only Windows Server 2008 or later versions, and a domain functional level of Windows Server
2008 or above, does not guarantee that DFS-R is the replication technology in use in your AD environment.
Specifically, if your AD was created with versions of Windows prior to Windows Server 2008 and then upgraded,
there is a chance that NTFRS is still the underlying replication method. In fact, migrating from NTFRS to DFS-R
for AD replication is not done automatically. It has to be planned carefully and done manually.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 3

 There are a couple of ways to verify which replication method is in use in your environment:

1. Using the command-line interface:

Open a CMD prompt and type dfsrmig /GetGlobalState

If the result is the following, then NTFRS is still in use for AD replication:

If the result says the global state is “Eliminated”, then DFS-R is utilized for AD replication:

If the result is anything different, then it likely means that the migration process has been started, but is
not complete yet. To learn more about how to migrate from NTFRS to DFS-R, read Microsoft’s SYSVOL
Replication Migration Guide.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 4

 2. Using the Active Directory Users and Computers management console:

Make sure you enable the Advanced Features from the console’s View menu and expand your domain.
You will then see the System container:

Expand the System container, then look for either the File Replication Service sub-container and
expand it to display what’s in the Domain System Volume (SYSVOL share) sub-container; or the DFS-R-
GlobalSettings sub-container and expand it to display the content of the Topology sub-container.

If NTFRS is used to replicate AD data, you will something similar to this:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 5

 If SYSVOL replication is handled by DFS-R, then you will observe something like this:

Time Synchronization
One of the key success factor of AD replication is time synchronization between DCs. In order to ensure smooth
recovery of your AD DCs, follow these best practices:

• On the DC hosting the PDC Emulator FSMO role in the root domain of your forest, configure the Windows
Time Service to synchronize with an external time source using the NTP protocol. Make sure UDP port 123
is not blocked anywhere then open a CMD prompt and run these commands:

– w32tm /config /manualpeerlist:external.time.server /syncfromflags:manual /

reliable:yes /update

– net stop w32time && net start w32time

• On the DC hosting the PDC Emulator FSMO role in each of the child domains of your forest, repeat the
procedure described above, but set the /manualpeerlist parameter with the FQDN of the PDC Emulator
of the root domain.

• On all other DCs in the forest, open a CMD prompt and run the following commands:

– w32tm /config /syncfromflags:domhier /reliable:no /update

– net stop w32time && net start w32time

If there are too many DCs in your environment to do this manually, and for all other domain members, then using
Group Policies is easier.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 6

 Launch the Group Policy Management Console (gpmc.msc), create a new Group Policy Object (GPO), configure
it with the parameters described below and link it to your domain or to the appropriate Organizational
Units (OUs):

• Navigate to Computer Configuration\Administrative Templates\System\Windows Time Service\Time

Providers:

• Enable the Windows NTP Client:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 7

 • Configure the Windows NTP Client to use NT5DS instead of NTP. This will instruct the domain members
to locate the DC hosting the PDC Emulator FSMO role and synchronize their clock with it:

There are a few commands to help you verify what is the time source of any given domain member:

• First, identify which DC is hosting the PDC Emulator FSMO role:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 8

 • You can easily identify the configured time source and verify that it matches the information you
previously received:

• Finally, you can also get the synchronization status:

To learn more about time synchronization for Active Directory, read the corresponding article on
Microsoft TechNet.

Name Resolution With DNS

Name resolution with Domain Name Services (DNS) is another important component on which the proper
functioning of AD and its replication depend. AD DCs effectively use DNS to communicate with each other.
Features such as Active Directory-integrated DNS zones make it easier for you to deploy DNS by eliminating the
need to set up secondary zones, and then configure zone transfers.

To make the recovery process of AD DCs easier and faster, all DCs that are also DNS servers should have more
than one DNS server configured in their TCP/IP parameters, like in the example shown below:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 9

 PREREQUISITES
The following prerequisites should be in place to ensure the recoverability of AD DCs:

• The Rubrik Backup Service (RBS) is installed on each AD DC and is registered with the corresponding
cluster, as shown in the below screenshot. RBS is a lightweight agent that triggers Microsoft’s VSS
framework to ensure VSS-compatible applications consistency:

• For physical AD DCs, a new Windows Host must be created for each in Rubrik cluster

• An appropriate SLA Domain is assigned to all AD DCs

• Application-consistent backups of AD DCs are taken. This is achieved with the help of RBS with Rubrik
4.2.1 and later versions. If the AD DC is virtual then the Application Consistency option of the VM in
Rubrik must be set to “Automatic”, as shown below:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 10

 You can verify that an application-consistent snapshot has been successfully captured:

1. In the Rubrik user interface, in the corresponding job details:

2. In the Windows Event Viewer of the backed up server:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 11

 INTRODUCTION TO RUBRIK VM RECOVERY OPTIONS

Rubrik has offered support for backing up and restoring VMware vSphere virtual machines since version 1.0, and
introduced support for Microsoft Hyper-V VMs and Nutanix AHV VMs as of version 4.0. When recovering a VM,
Rubrik provides three main options:

• Instant Recovery – The Instant Recovery option intentionally powers off and renames the production
VM while re-creating it from the Rubrik backups. Upon completion, a VM with the exact same name and
parameters as the original will be created, connected to the network and powered on.

• Export – The Export option, like the Instant Recovery option, creates a new VM object from the Rubrik
backups. However, it presents the ability to select the same or different hypervisor host and datastore, or
volume, as targets.

• In-Place Recovery – This recovery model leverages VMware’s Changed Block Tracking to recover only
the changed blocks within an existing virtual machine. Because of this, only the data blocks that have
changed need to be recovered, making for the fastest of these recovery options.

• Live Mount – Rubrik’s Live Mount option provides near-instantaneous recovery of a VM by publishing
the selected point-in-time snapshot of that VM as an NFS or SMBv3 share (dependent on whether the
hypervisor is vSphere, AHV or Hyper-V), to a hypervisor and powering on the VM directly from the Rubrik
cluster. This reduces the Recovery Time Objective (RTO) drastically. Interestingly, Rubrik can live mount
individual VMware virtual disks and physical volumes, as well as SQL and Oracle databases.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 12

 PHYSICAL WINDOWS RECOVERY OVERVIEW

Rubrik introduced support for Windows Full Volume Protection with version 4.2. This allows you to perform
block-based backups of entire Windows volumes, in turn enabling full volume or entire computer recovery to
similar hardware. In order to do Full Volume Protection backups, the Rubrik Backup Service must be installed on
the physical host.

The first step to recovering an entire computer is to download the Windows Recovery Tools from the Rubrik
Support Portal to a machine running Windows Server 2012 R2 or later, as well as the Windows Assessment and
Deployment Kit. This set of tools will be used to create a bootable WinPE ISO file. Burn it to a CD/DVD or USB
stick and boot the target server on it.

In parallel, live mount the volumes that you need to restore from the Rubrik user interface.

Once in the WinPE environment, the simplified recovery process is as follows:

• Open the PowerShell console

• Run the RubrikBMR PowerShell script provided with the Windows Recovery Tools

• Follow the steps given by the script to recover each volume. You will find the SMB path to the live-
mounted volumes in the Rubrik UI

• When all volumes have been restored, remove the WinPE media and restart the server

To discover the details of the physical Windows recovery process, please refer to the Rubrik User Guide, in the
Full Volume Protection for Windows chapter.

RECOVERING ACTIVE DIRECTORY DOMAIN CONTROLLERS WITH RUBRIK

INTRODUCTION TO AD BACKUP AND RECOVERY

Back in the 2000s there was no such thing as restoring a DC. Whenever one would fail, an AD admin would
simply deploy a new Windows Server, and run dcpromo to promote it as a new DC in the same domain as the
failed one to replace it. If the failed DC used to host any FSMO roles, you can easily seize them.

Although it is very common to host other infrastructure-related roles, such as DNS or DHCP, on the same
servers, it is recommended to avoid deploying any other roles or applications on AD DCs. The logic for this is
twofold: firstly, as your authentication platform, you should minimize any potential attack surface which might
be caused by these other services and applications. Secondly, in retaining only Active Directory functions on
these servers, the DC itself becomes more disposable, as the AD data can simply be replicated back from
surviving DCs in a disaster. For example, when a DC is also a file server, an antivirus server, a WSUS server or
even a backup software’s master server, it becomes critical to be able to recover this machine when it fails.

Luckily, Microsoft introduced the Volume Shadow Copy Service (VSS) with Windows Server 2003 and Windows
XP, along with the NTDS writer, which is the AD VSS Writer. It is installed when promoting a Windows Server
machine to a Domain Controller with the help of the dcpromo command. This writer is requested when a VSS-
compatible backup application wants to prepare the operating system and the VSS-enabled applications, such
as Active Directory, for an online backup. The application writers are responsible for freezing the application and
queueing incoming I /Os to allow the VSS service to create an application-consistent volume shadow copy.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 13

 In the case of Active Directory, and as per Microsoft, “The Active Directory writer requires no special actions
during backup operations” … “There is no need to use any special APIs to back up the Active Directory.”

VSS makes AD backup and recovery possible and the deploy-and-dcpromo method a thing of the past! In order
to guarantee application-consistency of AD DC backups with Rubrik, please review the prerequisites.

RESTORING AN INDIVIDUAL ACTIVE DIRECTORY DOMAIN CONTROLLER

The very first step to get a failed DC back up and running is of course to restore the entire computer. Whether
it’s a VM or a physical machine, refer to the corresponding sections of this document to learn how to restore it
with Rubrik.

Once the server itself has been restored, we recommend to unplug it from the network. In the case of a VM,
restore operations such as Export or Live Mount restore VMs disconnected from the network automatically. For
physical servers, a functioning network connection is required during the recovery process to retrieve the data
from the live-mounted volumes on Rubrik via SMB. Once this process is finished, physically unplug the ethernet
cable from the server when possible, or disable the NIC from Windows.

When only one individual DC fails in an existing domain, and other DCs are running and providing service
normally, it is important to make sure to perform a non-authoritative restore of the failed DC, or more precisely
of its SYSVOL folder. The way to achieve this depends on what AD replication method is utilized in your domain.
To know which one is used, refer to the Introduction to AD Replication section of this document.

Whether the restoration of SYSVOL is authoritative or non-authoritative, the target Windows Server machine
will have to be booted in the Directory Services Recovery Mode (DSRM). Make sure you have the DSRM admin
password with you. You will not be able to login with any domain user account because the directory services
will be stopped. An easy way to configure Windows to start in DSRM is to use the msconfig tool, and to select
“Safe boot” > “Active Directory repair”, as shown in the screenshot below:

Because Rubrik does either image-level or volume-level backups of AD DCs, the recovery process is fairly
simple. It is usually recommended to recover from the latest backup, but if you decide or have to restore from an
older backup, make sure its age does not exceed the Tombstone Lifetime (default is 60 days).

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 14

 Non-Authoritative Restore With NTFRS Replication
Once the server has restarted in DSRM, follow the steps described below to do a non-authoritative restore of a
SYSVOL replicated with NTFRS:

• Open the Windows Registry Editor with the command regedit.exe

• Navigate the registry to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\

Parameters\Backup/Restore\Process at Startup

• Change the value of the BurFlags DWORD to D2

• Close the Windows Registry Editor

• Run msconfig again and choose to restart in the normal mode by unselecting the Safe boot option:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 15

 • Make sure you re-enable the network connection when the server is restarting, by re-plugging the
ethernet cable or re-enabling the NIC from Windows for a physical machine, or re-connecting the vNIC to
the appropriate virtual switch for a VM. In case of a VMware vSphere or Hyper-V VM, also make sure that
you re-enable the “Connect At Power On” option:

• Allow the restored server time to finish starting Windows and to contact its replication partners.

• Verify that the recovery operation is successful

Non-Authoritative Restore With DFS-R Replication

Once the server has restarted in DSRM, follow the steps described below to do a non-authoritative restore of a
SYSVOL replicated with DFS-R:

• Open the Windows Registry Editor with the command regedit.exe

• Navigate the registry to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Restore

• If the Restore key doesn’t exist, create it

• Change the value of the SYSVOL STRING to “non-authoritative”. If it doesn’t not exist, create it:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 16

 • Close the Windows Registry Editor

• Run msconfig again and choose to restart in the normal mode by unselecting the Safe boot option:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 17

 • Make sure you re-enable the network connection when the server is restarting, by re-plugging the
ethernet cable or re-enabling the NIC from Windows for a physical machine, or re-connecting the vNIC to
the appropriate virtual switch for a VM. In case of a VMware vSphere or Hyper-V VM, also make sure that
you re-enable the Connect At Power On option:

• Allow the restored server time to finish starting Windows and to contact its replication partners.

• Verify that the recovery operation is successful

RESTORING AN ENTIRE ACTIVE DIRECTORY DOMAIN

When planning for disaster recovery, it’s critical to have a tested and well documented strategy to recover your
Active Directory. Because many services and applications depend on Active Directory to work, AD should be
one of the first services to restart, if not the first.

The steps to restore an entire AD domain are similar to recovering an individual AD DC, so please read the
Restoring an Individual Active Directory Domain Controller section first.

However, there are a few additional considerations:

1. You will have to select carefully which DC to restore first. The choice will depend on your environment,
FSMO roles distribution and other criteria. Usually you should select the DC hosting the PDC Emulator
role. To know which one it is in your environment, refer to the Introduction to AD Replication section of this
document. The first restored DC should also be a DNS server, which DNS client is configured to use itself
(127.0.0.1) as the primary DNS server.

2. Once the first DC server is restored, you will have to perform an authoritative restore of SYSVOL, as
described later in this document.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 18

 3. By default when a DC hosting an FSMO role starts, it tries to replicate the partition of the corresponding
FSMO from its known replication partners before it can start servicing requests for this FSMO. If the first
restored DC of the domain hosts any other FSMO role than the PDC Emulator, it is required to disable this
default behavior in order to have a fully functioning DC.

To achieve this, follow the steps below:

a. Open the Windows Registry Editor

b. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

c. Create a new DWORD and name it Repl Perform Initial Synchronizations

d. Set its value to 0

e. IMPORTANT: Make sure to reset this value to 1 after the forest is recovered completely.

4. Determine the right order to restore the remaining DCs, according to the FSMO roles and other roles and
applications they host.

5. Restore remaining DCs one by one, performing a non-authoritative restore of SYSVOL for each of them.

Authoritative Restore With NTFRS Replication

Once the server has restarted in DSRM, follow the steps described below to do a non-authoritative restore of a
SYSVOL replicated with NTFRS:

• Open the Windows Registry Editor with the command regedit.exe

• Navigate the registry to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\

Parameters\Backup/Restore\Process at Startup

• Change the value of the BurFlags DWORD to D4

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 19

 • Close the Windows Registry Editor

• Run msconfig again and choose to restart in the normal mode by unselecting the Safe boot option:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 20

 • Make sure you re-enable the network connection when the server is restarting, by re-plugging the
ethernet cable or re-enabling the NIC from Windows for a physical machine, or re-connecting the vNIC to
the appropriate virtual switch for a VM. In case of a VMware vSphere or Hyper-V VM, also make sure that
you re-enable the Connect At Power On option:

• Allow the restored server time to finish starting Windows and to contact its replication partners.

• Verify that the recovery operation is successful

Authoritative Restore With DFS-R Replication

Once the server has restarted in DSRM, follow the steps described below to do a non-authoritative restore of a
SYSVOL replicated with DFS-R:

• Open the Windows Registry Editor with the command regedit.exe

• Navigate the registry to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DFSR\Restore

• If the Restore key doesn’t exist, create it

• Change the value of the SYSVOL STRING to authoritative. If it doesn’t not exist, create it:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 21

 • Close the Windows Registry Editor

• Run msconfig again and choose to restart in the normal mode by unselecting the Safe boot option:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 22

 • Make sure you re-enable the network connection when the server is restarting, by re-plugging the
ethernet cable or re-enabling the NIC from Windows for a physical machine, or re-connecting the vNIC to
the appropriate virtual switch for a VM. In case of a VMware vSphere or Hyper-V VM, also make sure that
you re-enable the Connect At Power On option:

• Allow the restored server time to finish starting Windows and to contact its replication partners.

• Verify that the recovery operation is successful

RESTORING AN ENTIRE ACTIVE DIRECTORY FOREST

Recovering an entire Active Directory forest is similar to restoring an AD Domain. Please read the Restoring an
Entire Active Directory Domain section first.

Start by restoring the root domain of your forest, then restore child domains. After the entire forest is restored,
do not forget to reset the Repl Perform Initial Synchronizations parameter to 1 in HKEY_LOCAL_MACHINE\
SYSTEM\CurrentControlSet\Services\NTDS\Parameters

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 23

 VERIFYING AD DC RECOVERY SUCCESS

After the required AD DCs are restored, verify that time synchronization works as expected, as well as DNS.
There are multiple tools available in Windows, or downloadable for free, to help you confirm restoration is
a success.

WINDOWS EVENT VIEWER

One of the first places to take a look at is the Windows Event Viewer. There is always a ton of useful information
to read in it and information related to Active Directory is no exception.

One of the most important events to search for is event ID 1109 in the Directory Service log. This event
indicates that an new InvocationID is assigned to the DC and is logged when an Active Directory database has
been restored successfully. Setting a new InvocationID to a restored AD DC will tell its replication partners that
it has been restored and that it needs to update its data from them:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 24

 It’s not rare that errors are logged upon restart of an AD DC after it has been restored. This usually happens until
communication with the replication partners is established and an AD replication pass has occurred to update
the recovered DC data. Once everything is back to normal, you will see the event ID 1394 in the Directory
Service log:

AD replication should be watched closely as well. If it fails, other errors or failures are most likely to occur,
often leading the restored DC to become unreliable. When recovery is done successfully, you should see the
following event IDs in the Windows Event Viewer, depending on whether the AD replication technology in your
environment is NTFRS or DFS-R:

• In an AD environment that uses DFS-R for replication, you will see the event ID 1104 logged in the DFSR
Windows log. It indicates that DFS-R replication has restarted successfully after a restore operation:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 25

 • When NTFRS is in use for AD replication, you will observe event IDs 13553 and 13554 in the NtFRS
Windows log, showing that the recovered AD DC was added to the replication topology:

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 26

 • Finally, event ID 13516 will be logged in the NtFRS Windows log to notify that all post-restoration
operations are complete:

DCDIAG
DCDiag is a diagnostics tool built in Windows to monitor an AD DC’s health. To start with, you can simply open
a command prompt and type dcdiag. A healthy DC should report all tests as passed successfully. However,
running this tool right after a restoration will probably display multiple errors and warnings. This is both because
a recovered DC should be given enough time to finalize replication with its partner, and because dcdiag reports
all recent errors and warnings, even if they have been cleared since they were logged.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 27

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 28
 If some of the tests fail and you want to dig deeper, you can use dcdiag /v and redirect the output to a text file.

REPADMIN
A healthy AD replication status should be observed after a successful recovery of AD DCs. To monitor this,
Windows Server provides another command line tool called repadmin. It allows to watch many aspects of
replication, but you can start easy by displaying the replication summary. To do this, simply open a command
prompt and type repadmin /replsum:

After the recovered DC has completed an update of its data from its replication partners, the command should
not display any failures or errors.

If you want to see a little more details about the status of the latest replication of the different partitions
between the replication partners, use repadmin with the parameter /showrepl:

The latest replication attempt of all partitions between the replication partners should all be successful.

Note: do not expect to see replications between each of your AD DCs. In fact, the replication topology is
built and adjusted as needed automatically by the Knowledge Consistency Checker (KCC) process.

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 29

 CONCLUSION

While Active Directory backup and recovery is generally not an easy thing to comprehend, Rubrik provides
a VSS-compatible solution to ensure successful application-consistent backups of Active Directory Domain
Controllers. To accommodate both physical and virtual deployments, Rubrik allows AD DCs to be backed up
either using an image-level approach for VMs, or a volume-level approach for physical machines. Both methods
allow recovery of entire DC servers in the event of a failure of one of them, or to meet disaster recovery needs.

Throughout this document, we covered when and how to perform an authoritative or non-authoritative restore
of SYSVOL after the server itself has been restored, in order to guarantee the consistency of the domain or
the forest.

To learn more about Rubrik and how it can help simplify data protection, from backup to replication to disaster
recovery to archival, visit www.rubrik.com.

VERSION HISTORY

Version Date Summary of Changes Owner

1.0 January 2019 Initial Release Pierre-Francois Gugliemi

Added reference to in-place recovery & removed

1.1 February 2022 Kev Johnson
restrictions on AHV Live Mount

Product naming and boilerplate updates &

1.2 September 2023 removed Microsoft Active Directory Replication Mike Preston
Status Tool section

Rubrik is on a mission to secure the world’s data. With Zero Trust Data Security™, we help organizations achieve
business resilience against cyberattacks, malicious insiders, and operational disruptions. Rubrik Security Cloud,
powered by machine learning, secures data across enterprise, cloud, and SaaS applications. We help organizations
uphold data integrity, deliver data availability that withstands adverse conditions, continuously monitor data risks and
Global HQ threats, and restore businesses with their data when infrastructure is attacked.
3495 Deer Creek Road 1-844-4RUBRIK For more information please visit www.rubrik.com and follow @rubrikInc on X (formerly Twitter) and Rubrik on LinkedIn.
Palo Alto, CA 94304 [email protected] Rubrik is a registered trademark of Rubrik, Inc. All company names, product names, and other such names in this
United States www.rubrik.com document are registered trademarks or trademarks of the relevant company.

sw-surviving-microsoft-active-directory-failures-with-rubrik / 20230913

Solutions Walkthrough | Surviving Microsoft Active Directory Failures with Rubrik 30