Converse agora com nosso suporte
Chat com o suporte

Recovery Manager for AD Forest Edition 10.3.1 - User Guide

Overview Getting started
Permissions required to use Recovery Manager for Active Directory Recovery Manager Console Getting and using help Configuring Windows Firewall Using Computer Collections Hybrid Recovery with On Demand Recovery Managing Recovery Manager for Active Directory configuration Licensing
Backing up data
Permissions required for the Backup operation Managing Backup Agent Using a least-privileged user account to back up data Using Managed Service Accounts Active Directory backups vs Windows System State backups Creating BMR and Active Directory backups Using the Backup Wizard Retrying backup creation Enabling backup encryption Backing up AD LDS (ADAM) Backing up cross-domain group membership Backing up distributed file system (DFS) data Backup scheduling Setting performance options Setting advanced backup options Using Forest Recovery Agent Unpacking backups Using e-mail notification Viewing backup creation results
Restoring data
Getting started with Active Directory recovery Managing deleted or recycled objects Restoring backed up Active Directory components Integration with Change Auditor for Active Directory Using granular online restore Restoring AD LDS (ADAM) Selectively restoring Active Directory object attributes Restoring objects in an application directory partition Restoring object quotas Restoring cross-domain group membership Performing a restore without having administrator privileges Reports about objects and operations Using complete offline restore Offline restore implications Restoring SYSVOL authoritatively Performing a granular restore of SYSVOL Recovering Group Policy Restoring data from third-party backups Using the Extract Wizard Restoring passwords and SID history
Full Replication Consolidating backup registration data Recovering an Active Directory forest
Forest recovery overview Deploying Recovery Manager for Active Directory Forest Edition (Disaster Recovery Edition) Permissions required to use Forest Recovery Console Forest Recovery Console Managing a recovery project Recovery methods Phased recovery Managing Forest Recovery Agent Rebooting domain controllers manually Resetting DSRM Administrator Password Purging Kerberos Tickets Managing the Global Catalog servers Managing FSMO roles Manage DNS Client Settings Configuring Windows Firewall Developing a custom forest recovery plan Backing up domain controllers Assigning a preferred DNS server during recovery Handling DNS servers during recovery Forest recovery approaches Deciding which backups to use Running custom scripts while recovering a forest Overview of steps to recover a forest Viewing forest recovery progress Viewing recovery plan Viewing a report about forest recovery or verify settings operation Handling failed domain controllers Adding a domain controller to a running recovery operation Selectively recovering domains in a forest Recovering SYSVOL Deleting domains during recovery Resuming an interrupted forest recovery Recovering read-only domain controllers (RODCs) Checking forest health Collecting diagnostic data for technical support
Using Management Shell Appendices
Frequently asked questions Best practices for using Computer Collections Technical characteristics Best practices for creating backups Best practices for creating backups for forest recovery Best practices for recovering a forest Descriptions of recovery or verification steps Ports Used by Recovery Manager for Active Directory Forest Edition (Disaster Recovery Edition) Backup Wizard Online Restore Wizard Online Restore Wizard for AD LDS (ADAM) Group Policy Restore Wizard Repair Wizard Extract Wizard Events generated by Recovery Manager for Active Directory

Removing a Backup Agent entry from the Backup Agent Management node

You can selectively remove Backup Agent entries from the list provided in the Backup Agent Management node. Removing a Backup Agent entry from that list does not affect the corresponding preinstalled agent instance in any way. Rather, it removes the agent’s registration information from the Recovery Manager Console.

You may want remove a Backup Agent entry from the list when, for example, you have uninstalled the corresponding Backup Agent instance from the computer without using the Recovery Manager Console, and the agent entry remained in the Backup Agent Management node.

To remove a Backup Agent entry
  1. In the Recovery Manager Console tree, select the Backup Agent Management node.

  2. In the right pane, right-click the Backup Agent entry you want to remove from the list.

  3. From the shortcut menu, select Remove from List.

 

Using a least-privileged user account to back up data

You can configure Recovery Manager for Active Directory (RMAD) to back up data in an Active Directory® domain under a least-privileged user account. A least-privileged user account is an account that has no other permissions except for those required to back up data with RMAD.

Using a least-privileged account to back up Active Directory® offers greater protection from unwanted changes to your Active Directory® environment, security attacks, or unsolicited access to sensitive documents or settings.

To run backup operations under a least-privileged user account, in the domain you want to back up, create an Active Directory® group named RMAD Backup Operators. Add the least-privileged user account you want to that group, and then preinstall the Backup Agent in the domain. As a result, members of the RMAD Backup Operators group are automatically granted the necessary permissions to back up data in the domain with RMAD.

To use a least-privileged user account for backup operations
  1. In the Active Directory® domain you want to back up, create a new Active Directory® group with the following name: RMAD Backup Operators

  2. To the RMAD Backup Operators group, add the least-privileged user account under which you want to back up the domain.

  3. On the domain controllers you want to back up, preinstall the Backup Agent version supplied with this release of RMAD.

    Make sure you first create the RMAD Backup Operators group, and then install the Backup Agent in the domain. During its installation, the agent locates that group and saves the group SID in the registry. Then the Backup Agent uses this group SID to check that the user account is a member of the RMAD Backup Operators group.

    If the Backup Agent supplied with this release is already preinstalled, you can repair the agent’s installation so that the agent could locate the RMAD Backup Operators group.

  4. Add the domain controllers on which you preinstalled the Backup Agent to a new Computer Collection.

  5. In the Computer Collection properties, on the Agent Settings tab, do the following:

    • Specify to access the Backup Agent with the least-privileged account you have added to the RMAD Backup Operators group.

    • Select the check box to use preinstalled Backup Agent. For more information, see Agent Settings tab subsection in Properties for an existing Computer Collection.

  6. Back up the Computer Collection.

 

Using Managed Service Accounts

Recovery Manager for Active Directory (RMAD) supports MSA/gMSA accounts for:

  • Scheduled backups - the account can be specified for scheduled tasks in the Computer Collection properties on the Schedule tab or in Task Scheduler.

  • Scheduled replication tasks (Fault Tolerance)

  • For PowerShell® scripts launched from the domain controller side before and/or after creating a backup. (Scripts run from the Recovery Manager for Active Directory console are not supported)

Note

Recovery Manager for Active Directory has deprecated support for a group managed service account (gMSA) to be specified as the account to connect to the backup agent for manually triggered backups. Managed service accounts will continue to be supported for scheduled backup tasks. In accordance with Microsoft®, it is recommended to not use a group managed service account (gMSA) for interactively initiated network connections such as Recovery Manager for Active Directory manually triggered backups. To enforce this recommendation and to address the vulnerability CVE-2023-21524 (https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-21524), Microsoft has limited the usages of managed service accounts with a Windows Update. By removing support for a gMSA to connect to the backup agent, this ensures an attacker does not exploit the RMAD backup agent to perform actions or access resources over the network. To utilize the benefits and security provided by a group managed service account (gMSA), we highly recommend that a gMSA account is used for the scheduled backup task. See Setting user account for scheduled tasks

MSA/gMSA account requirements:

  • You can use Managed Service Account (in Windows Server® 2008 or higher) or Group Managed Service Account (in Windows Server® 2012 or higher).

  • Add the $ character at the end of the account name (e.g. domain\computername$) and leave the Password field blank.

  • The MSA/gMSA account must be a member of the local Administrator group on the RMAD machine.

How to create a Group Managed Service Accounts (gMSA)

Although the following instructions will configure gMSA accounts in your Active Directory® Forest, we recommend you first review the Microsoft® article: Getting Started with Group Managed Service Accounts

Note

Even with the -EffectiveImmediately switch shown below, you must wait 10 hours after issuing this command before continuing. This ensures that the key has replicated throughout the domain so that all domain controllers can generate a password for your gMSA account.

  1. If you have never used gMSA accounts before, you must prepare Active Directory® by creating a KDS Root Key with one of the following PowerShell® commands on a domain controller:

    In production, issue the command:

    Add-KdsRootKey -EffectiveImmediately

    In a test lab with minimal domain controllers, it’s safe to issue this command:

    Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

    Run this command once in each Domain of the Forest.

    NOTE: For more information, see Create the Key Distribution Services KDS Root Key and this Microsoft Blog post.

  2. (Optional) If you plan to use the same gMSA account on more than one host (for example, you have more than one RMAD server), then it may be easier to create a group for the hosts you plan to use it on. We suggest a Domain-Local Security group for this purpose. The following PowerShell® commands will create the group in the default Users container, then add your RMAD server as a member:

    Add-ADGroupMember -Identity <GroupName> -Members <RMADServer$>

    Repeat the command above for each RMAD server you want to use the gMSA account.

    NOTE: If you use a group, then you must either restart the host(s) you added as members or run the command klist purge –li 0x3e7 on each host before performing step 4 below. This is to refresh the computer’s Kerberos ticket so it will include the new group SID in its NT Token.

  3. Create the gMSA account using the following PowerShell command:

    New-ADServiceAccount -Name <gMSAName> -DNSHost <gMSAName.domain> -PrincipalsAllowedToRetrieveManagedPassword <AccountName>

    Where:

    • <gMSAName> is the name of your gMSA account. For example: “gMSABackup”

    • <gMSAName.domain> is the gMSA account followed by the domain. For example: “gMSABackup.contoso.com”

    • <AccountName> is either <RMADServer$>, or the group name you created in step 2 above.

NOTE: If using remote storage for backups, the account for each domain controller being backed up, needs to be added to the "PrincipalsAllowedToRetrieveManagedPassword" property for the gMSA account. Use the following command:
SetADServiceAccount -Identity <gMSAName> -PrincipalsAllowedToRetreiveManagedPassword <AccountName>.

  1. After the gMSA account is created, you must install it on each host it will be used on (for example; on your RMAD server). Do this by running the following PowerShell® command on each host:

    Install-ADServiceAccount -Identity <gMSAName>

  2. (Optional) You can test that the gMSA account can be used by running the following PowerShell® command on each host where you installed the gMSA account:

    Test-ADServiceAccount <gMSAName>

    A result of True shows the gMSA account is ready to be used.

For more details, see Getting Started with Group Managed Service Accounts.

 

Active Directory backups vs Windows System State backups

The Active Directory and Windows System State backups are very similar. The key components that Recovery Manager for Active Directory (RMAD) backs up as part of the AD system state are the Registry, the NTDS.dit file, and SYSVOL.

What differences do they have?

  • Windows System State backup is a full backup of the Windows operating system; Active Directory® backup contains only pieces of Active Directory® that allow you to restore the domain controller on a clean operating system.

  • Windows System State backups contain more components - not all of these components are necessary for Active Directory recovery, e.g. IIS Metabase, Cluster Services, etc.

  • Windows System State backup may contain viruses in the components of the operating system.

  • Windows System State backups are larger than Active Directory® backups.

For the list of Windows System State backup components, see Microsoft documentation.

RMAD enables the backup and restoration of the following Active Directory® components on domain controllers:

  • DIT Database

  • SYSVOL

  • Registry, including all registry hives and the file NTUSER.DAT

RMAD Disaster Recovery Edition also supports Bare Metal Recovery (BMR) backups. With BMR backups, you can completely rebuild the server if necessary.

 

Documentos relacionados

The document was helpful.

Selecione a classificação

I easily found the information I needed.

Selecione a classificação