A Windows Server domain controller logs Directory Services event 2095 when it encounters a USN rollback
This article describes how to detect and recover if a Windows Server domain controller is incorrectly rolled back by using an image-based installation of the operating system.
Applies to: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Original KB number: 875495
This article is intended for only technical support agents and IT professionals. If you’re looking for help with a problem, please ask the Microsoft Community.
Summary
This article describes a silent Active Directory replication failure that is caused by an update sequence number (USN) rollback. A USN rollback occurs when an older version of an Active Directory database is incorrectly restored or pasted into place.
When a USN rollback occurs, modifications to objects and attributes that occur on one domain controller do not replicate to other domain controllers in the forest. Because replication partners believe that they have an up-to-date copy of the Active Directory database, monitoring and troubleshooting tools such as Repadmin.exe don’t report any replication errors.
Domain Controllers log Directory Services Event 2095 in the Directory Services event log when they detect a USN rollback. The text of the event message directs administrators to this article to learn about recovery options.
Example of Event 2095 log entry
Log Name: Service Source: Microsoft-Windows-ActiveDirectory_DomainService Date: Event ID: 2095 Task Category: Replication Level: Error Keywords: Classic User: Computer: SERVER.contoso.com Description: During an Active Directory Domain Services replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers. Because the remote DC believes it is has a more up-to-date Active Directory Domain Services database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory Domain Services database or replicate them to its direct and transitive replication partners that originate from this local DC. If not resolved immediately, this scenario will result in inconsistencies in the Active Directory Domain Services databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations. To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support. The most probable cause of this situation is the improper restore of Active Directory Domain Services on the local domain controller. User Actions: If this situation occurred because of an improper or unintended restore, forcibly demote the DC.
The following topics discuss how to detect and recover from a USN rollback in a Windows Server-based domain controller.
Supported methods to back up Active Directory on domain controllers that are running Windows Server 2012 and later versions
Windows Server 2012 adds support for Hyper-Visor Generation ID (GenID). This allows the virtual guest to detect the disk volumes that have a new ID, and respond to the new GenID. In Active Directory, Directory Services reacts as if the domain controller was restored from a backup. It then generates a new Invocation ID. By using the new Invocation ID, the database instance can safely re-enter replication in the forest.
Supported methods to back up Active Directory on domain controllers that are running Windows Server 2003 or later versions of Windows Server
Over a domain controller’s life cycle, you may have to restore, or «roll back,» the contents of the Active Directory database to a known good point in time. Or, you may have to roll back elements of a domain controller’s host operating system, including Active Directory, to a known good point.
The following are supported methods that you can use to roll back the contents of Active Directory:
- Use an Active Directory-aware backup and restoration utility that uses Microsoft-provided and Microsoft-tested APIs. These APIs non-authoritatively or authoritatively restore a system state backup. The backup that is restored should originate from the same operating system installation and from the same physical or virtual computer that is being restored.
- Use an Active Directory-aware backup and restoration utility that uses Microsoft Volume Shadow Copy Service APIs. These APIs back up and restore the domain controller system state. The Volume Shadow Copy Service supports creating single point-in-time shadow copies of single or multiple volumes on computers that are running Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2. Single point-in-time shadow copies are also known as snapshots. For more information, search «Volume Shadow Copy Service» in Microsoft Support.
- Restore the system state. Evaluate whether valid system state backups exist for this domain controller. If a valid system state backup was made before the rolled-back domain controller was incorrectly restored, and if the backup contains recent changes that were made on the domain controller, restore the system state from the most recent backup.
Typical behavior that occurs when you restore an Active Directory-aware system state backup
Windows Server domain controllers use USNs together with the invocation IDs to track updates that must be replicated between replication partners in an Active Directory forest.
Source domain controllers use USNs to determine what changes have already been received by the destination domain controller that is requesting changes. Destination domain controllers use USNs to determine what changes should be requested from source domain controllers.
The invocation ID identifies the version or the instantiation of the Active Directory database that is running on a given domain controller.
When Active Directory is restored on a domain controller by using the APIs and methods that Microsoft has designed and tested, the invocation ID is correctly reset on the restored domain controller. domain controllers in the forest receive notification of the invocation reset. Therefore, they adjust their high watermark values accordingly.
Software and methodologies that cause USN rollbacks
When the following environments, programs, or subsystems are used, administrators can bypass the checks and validations that Microsoft has designed to occur when the domain controller system state is restored:
- Starting an Active Directory domain controller whose Active Directory database file was restored (copied) into place by using an imaging program such as Norton Ghost.
- Starting a previously saved virtual hard disk image of a domain controller. The following scenario can cause a USN rollback:
- Promote a domain controller in a virtual hosting environment.
- Create a snapshot or alternative version of the virtual hosting environment.
- Let the domain controller continue to inbound replicate and to outbound replicate.
- Start the domain controller image file that you created in step 2.
- Examples of virtualized hosting environments that cause this scenario include Microsoft Virtual PC 2004, Microsoft Virtual Server 2005, and EMC VMWARE. Other virtualized hosting environments can also cause this scenario.
- For more information about the support conditions for domain controllers in virtual hosting environments, see Things to consider when you host Active Directory domain controllers in virtual hosting environments.
- Starting an Active Directory domain controller that is located on a volume where the disk subsystem loads by using previously saved images of the operating system without requiring a system state restoration of Active Directory.
- Scenario A: Starting multiple copies of Active Directory that are located on a disk subsystem that stores multiple versions of a volume
- Promote a domain controller. Locate the Ntds.dit file on a disk subsystem that can store multiple versions of the volume that hosts the Ntds.dit file.
- Use the disk subsystem to create a snapshot of the volume that hosts the Ntds.dit file for the domain controller.
- Continue to let the domain controller load Active Directory from the volume that you created in step 1.
- Start the domain controller that the Active Directory database saved in step 2.
- Scenario B: Starting Active Directory from other drives in a broken mirror
- Promote a domain controller. Locate the Ntds.dit file on a mirrored drive.
- Break the mirror.
- Continue to inbound replicate and outbound replicate by using the Ntds.dit file on the first drive in the mirror.
- Start the domain controller by using the Ntds.dit file on the second drive in the mirror.
Even if not intended, each of these scenarios can cause domain controllers to roll back to an older version of the Active Directory database by unsupported methods. The only supported way to roll back the contents of Active Directory or the local state of an Active Directory domain controller is to use an Active Directory-aware backup and restoration utility to restore a system state backup that originated from the same operating system installation and the same physical or virtual computer that is being restored.
Microsoft does not support any other process that takes a snapshot of the elements of an Active Directory domain controller’s system state and copies elements of that system state to an operating system image. Unless an administrator intervenes, such processes cause a USN rollback. This USN rollback causes the direct and transitive replication partners of an incorrectly restored domain controller to have inconsistent objects in their Active Directory databases.
The effects of a USN rollback
When USN rollbacks occur, modifications to objects and attributes aren’t inbound replicated by destination domain controllers that have previously seen the USN.
Because these destination domain controllers believe they’re up to date, no replication errors are reported in Directory Service event logs or by monitoring and diagnostic tools.
USN rollback may affect the replication of any object or attribute in any partition. The most frequently observed side effect is that user accounts and computer accounts that are created on the rollback domain controller do not exist on one or more replication partners. Or, the password updates that originated on the rollback domain controller don’t exist on replication partners.
The following steps show the sequence of events that may cause a USN rollback. A USN rollback occurs when the domain controller system state is rolled back in time using an unsupported system state restoration.
- An administrator promotes three domain controllers in a domain. (In this example, the domain controllers are DC1, DC2, and DC2, and the domain is Contoso.com.) DC1 and DC2 are direct replication partners. DC2 and DC3 are also direct replication partners. DC1 and DC3 aren’t direct replication partners but receive originating updates transitively through DC2.
- An administrator creates 10 user accounts that correspond to USNs 1 through 10 on DC1. All these accounts replicate to DC2 and DC3.
- A disk image of an operating system is captured on DC1. This image has a record of objects that correspond to local USNs 1 through 10 on DC1.
- The following changes are made in Active Directory:
- The passwords for all 10 user accounts that were created in step 2 are reset on DC1. These passwords correspond to USNs 11 through 20. All 10 updated passwords replicate to DC2 and DC3.
- 10 new user accounts that correspond to USNs 21 through 30 are created on DC1. These 10 user accounts replicate to DC2 and DC3.
- 10 new computer accounts that correspond to USNs 31 through 40 are created on DC1. These 10 computer accounts replicate to DC2 and DC3.
- 10 new security groups that correspond to USNs 41 through 50 are created on DC1. These 10 security groups replicate to DC2 and DC3.
- DC1 experiences a hardware failure or a software failure. The administrator uses a disk imaging utility to copy the operating system image that was created in step 3 into place. DC1 now starts with an Active Directory database that has knowledge of USNs 1 through 10. Because the operating system image was copied into place, and a supported method of restoring the system state wasn’t used, DC1 continues to use the same invocation ID that created the initial copy of the database and all changes up to USN 50. DC2 and DC3 also maintain the same invocation ID for DC1 well as an up-to-date vector of USN 50 for DC1. (An up-to-date vector is the current status of the latest originating updates to occur on all domain controllers for a given directory partition.) Unless an administrator intervenes, DC2 and DC3 don’t inbound replicate the changes that correspond to local USN 11 through 50 that originate from DC1. Also, according to the invocation ID that DC2 uses, DC1 already has knowledge of the changes that correspond to USN 11 to 50. Therefore, DC2 doesn’t send those changes. Because the changes in step 4 do not exist on DC1, logon requests fail with an «access denied» error. This error occurs either because passwords do not match or because the account does not exist when the newer accounts randomly authenticate with DC1.
- Administrators who monitor replication health in the forest note the following situations:
- The Repadmin /showreps command-line tool reports that two-way Active Directory replication between DC1 and DC2 and between DC2 and DC3 is occurring without error. This situation makes any replication inconsistency difficult to detect.
- Replication events in the directory service event logs of domain controllers that are running Windows Server do not indicate any replication failures in the directory service event logs. This situation makes any replication inconsistency difficult to detect.
- Active Directory Users and Computers or the Active Directory Administration Tool (Ldp.exe) show a different count of objects and different object metadata when the domain directory partitions on DC2 and DC3 are compared to the partition on DC1. The difference is the set of changes that map to USN changes 11 through 50 in step 4.
Note In this example, the different object count applies to user accounts, computer accounts, and security groups. The different object metadata represents the different user account passwords.
Although the symptoms that are mentioned in step 6 represent some of the effect that a USN rollback can have on user and computer accounts, a USN rollback can prevent any object type in any Active Directory partition from replicating. These object types include the following:
- The Active Directory replication topology and schedule
- The existence of domain controllers in the forest and the roles that these domain controllers hold
Note These roles include the global catalog, relative identifier (RID) allocations, and operations master roles. (Operations master roles are also known as flexible single master operations or FSMO.)
The size of the USN hole may represent hundreds, thousands, or even tens of thousands of changes to users, computers, trusts, passwords, and security groups. (The USN hole is defined by the difference between the highest USN number that existed when the restored system state backup was made and the number of originating changes that were created on the rolled-back domain controller before it was taken offline.)
Detect a USN rollback on a Windows Server domain controller
Because a USN rollback is difficult to detect, a Windows Server 2003 SP1 or later version domain controller logs event 2095 when a source domain controller sends a previously acknowledged USN number to a destination domain controller without a corresponding change in the invocation ID.
To prevent unique originating updates to Active Directory from being created on the incorrectly restored domain controller, the Net Logon service is paused. When the Net Logon service is paused, user and computer accounts can’t change the password on a domain controller that will not outbound-replicate such changes. Similarly, Active Directory administration tools will favor a healthy domain controller when they make updates to objects in Active Directory.
On a domain controller, event messages that resemble the following are recorded if the following conditions are true:
- A source domain controller sends a previously acknowledged USN number to a destination domain controller.
- There is no corresponding change in the invocation ID.
These events may be captured in the Directory Service event log. However, they may be overwritten before they’re observed by an administrator.
You may suspect that a USN rollback has occurred. However, you don’t see the correlating events in the Directory Service event log. In this scenario, check for the Dsa Not Writable registry entry. This entry provides forensic evidence that a USN rollback has occurred.
- Registry subkey: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
- Registry entry: Dsa Not Writable
- Value: 0x4
Deleting or manually changing the Dsa Not Writable registry entry value puts the rollback domain controller in a permanently unsupported state. Therefore, such changes are not supported. Specifically, modifying the value removes the quarantine behavior added by the USN rollback detection code. The Active Directory partitions on the rollback domain controller will be permanently inconsistent with direct and transitive replication partners in the same Active Directory forest.
Recover from a USN rollback
There are three approaches to recover from a USN rollback.
- Remove the Domain Controller from the domain. To do this, follow these steps:
- Remove Active Directory from the domain controller to force it to be a standalone server. For more information, see Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion.
- Shut down the demoted server.
- On a healthy domain controller, clean up the metadata of the demoted domain controller. For more information, see Clean up Active Directory Domain Controller server metadata.
- If the incorrectly restored domain controller hosts operations master roles, transfer these roles to a healthy domain controller. For more information, see Transfer or seize Operation Master roles in Active Directory Domain Services.
- Restart the demoted server.
- If you are required to, install Active Directory on the stand-alone server again.
- If the domain controller was previously a global catalog, configure the domain controller to be a global catalog. For more information, see How to create or move a global catalog.
- If the domain controller previously hosted operations master roles, transfer the operations master roles back to the domain controller. For more information, see Transfer or seize Operation Master roles in Active Directory Domain Services.
- Restore the system state of a good backup. Evaluate whether valid system state backups exist for this domain controller. If a valid system state backup was made before the rolled-back domain controller was incorrectly restored, and the backup contains recent changes that were made on the domain controller, restore the system state from the most recent backup.
- Restore the system state without system state backup. You can use the snapshot as a source of a backup. Or you can set the database to give itself a new invocation ID by using the procedure in the To restore a previous version of a virtual domain controller VHD without system state data backup section of Running Domain Controllers in Hyper-V.
References
- Things to consider when you host Active Directory domain controllers in virtual hosting environments
- Virtualized domain controller Architecture
Контроллер домена Windows Server регистрирует событие 2095 служб каталогов при обнаружении отката USN
В этой статье описывается, как обнаружить и восстановить, если контроллер домена Windows Server неправильно откатывается с помощью установки операционной системы на основе образа.
Применимо к: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2
Исходный номер базы знаний: 875495Эта статья предназначена только для агентов технической поддержки и ИТ-специалистов. Если вы ищете помощь по проблеме, обратитесь в сообщество Майкрософт.
Сводка
В этой статье описывается сбой автоматической репликации Active Directory, вызванный откатом последовательного номера обновления (USN). Откат USN происходит при неправильном восстановлении или вставке более старой версии базы данных Active Directory.
При откате USN изменения объектов и атрибутов, происходящие на одном контроллере домена, не реплицируются на другие контроллеры домена в лесу. Поскольку партнеры по репликации считают, что у них есть актуальная копия базы данных Active Directory, средства мониторинга и устранения неполадок, такие как Repadmin.exe не сообщают об ошибках репликации.
Контроллеры домена регистрируют событие служб каталогов 2095 в журнале событий служб каталогов при обнаружении отката USN. Текст сообщения о событии позволяет администраторам ознакомиться с этой статьей, чтобы узнать о вариантах восстановления.
Пример записи журнала события 2095
Log Name: Service Source: Microsoft-Windows-ActiveDirectory_DomainService Date: Event ID: 2095 Task Category: Replication Level: Error Keywords: Classic User: Computer: SERVER.contoso.com Description: During an Active Directory Domain Services replication request, the local domain controller (DC) identified a remote DC which has received replication data from the local DC using already-acknowledged USN tracking numbers. Because the remote DC believes it is has a more up-to-date Active Directory Domain Services database than the local DC, the remote DC will not apply future changes to its copy of the Active Directory Domain Services database or replicate them to its direct and transitive replication partners that originate from this local DC. If not resolved immediately, this scenario will result in inconsistencies in the Active Directory Domain Services databases of this source DC and one or more direct and transitive replication partners. Specifically the consistency of users, computers and trust relationships, their passwords, security groups, security group memberships and other Active Directory Domain Services configuration data may vary, affecting the ability to log on, find objects of interest and perform other critical operations. To determine if this misconfiguration exists, query this event ID using http://support.microsoft.com or contact your Microsoft product support. The most probable cause of this situation is the improper restore of Active Directory Domain Services on the local domain controller. User Actions: If this situation occurred because of an improper or unintended restore, forcibly demote the DC.
В следующих разделах описывается обнаружение и восстановление после отката USN в контроллере домена под управлением Windows Server.
Поддерживаемые методы резервного копирования Active Directory на контроллерах домена под управлением Windows Server 2012 и более поздних версий
Windows Server 2012 добавлена поддержка идентификатора поколения Hyper-Visor (GenID). Это позволяет виртуальному гостю обнаруживать тома диска с новым идентификатором и реагировать на новый GenID. В Active Directory службы каталогов реагируют так, как если бы контроллер домена был восстановлен из резервной копии. Затем создается новый идентификатор вызова. Используя новый идентификатор вызова, экземпляр базы данных может безопасно повторно ввести репликацию в лесу.
Поддерживаемые методы резервного копирования Active Directory на контроллерах домена под управлением Windows Server 2003 или более поздних версий Windows Server
В течение жизненного цикла контроллера домена может потребоваться восстановить или «откатить» содержимое базы данных Active Directory до известного хорошего момента во времени. Или может потребоваться откат элементов операционной системы узла контроллера домена, включая Active Directory, до известной хорошей точки.
Ниже приведены поддерживаемые методы, которые можно использовать для отката содержимого Active Directory.
- Используйте служебную программу резервного копирования и восстановления с поддержкой Active Directory, которая использует API, предоставляемые корпорацией Майкрософт и протестированные Корпорацией Майкрософт. Эти API-интерфейсы неавторитетно или авторитетно восстанавливают резервную копию состояния системы. Восстанавливаемая резервная копия должна создаваться с той же операционной системы и с того же физического или виртуального компьютера, на который выполняется восстановление.
- Используйте программу резервного копирования и восстановления с поддержкой Active Directory, которая использует API службы теневого копирования томов Майкрософт. Эти API-интерфейсы резервного копирования и восстановления состояния системы контроллера домена. Служба теневого копирования томов поддерживает создание теневых копий одного или нескольких томов на компьютерах под управлением Windows Server 2003, Windows Server 2008 или Windows Server 2008 R2. Теневые копии с одним моментом времени также называются моментальными снимками. Дополнительные сведения см. в разделе «Служба теневого копирования томов» в служба поддержки Майкрософт.
- Восстановите состояние системы. Оцените, существуют ли допустимые резервные копии состояния системы для этого контроллера домена. Если действительная резервная копия состояния системы была выполнена до неправильного восстановления контроллера домена с откатом и если резервная копия содержит последние изменения, внесенные в контроллере домена, восстановите состояние системы из последней резервной копии.
Типичное поведение, возникающее при восстановлении резервной копии состояния системы с поддержкой Active Directory
Контроллеры домена Windows Server используют usN вместе с идентификаторами вызова для отслеживания обновлений, которые должны реплицироваться между партнерами по репликации в лесу Active Directory.
Исходные контроллеры домена используют usN для определения того, какие изменения уже были получены конечным контроллером домена, запрашивающим изменения. Контроллеры домена назначения используют usn для определения того, какие изменения следует запрашивать от исходных контроллеров домена.
Идентификатор вызова определяет версию или экземпляр базы данных Active Directory, запущенной на заданном контроллере домена.
При восстановлении Active Directory на контроллере домена с помощью API и методов, разработанных и протестированных корпорацией Майкрософт, идентификатор вызова правильно сбрасывается на восстановленном контроллере домена. контроллеры домена в лесу получают уведомление о сбросе вызова. Поэтому они соответствующим образом корректируют свои значения высоких водяных знаков.
Программное обеспечение и методологии, вызывающие откат USN
Если используются следующие среды, программы или подсистемы, администраторы могут обойти проверки и проверки, которые корпорация Майкрософт разработала при восстановлении состояния системы контроллера домена:
- Запуск контроллера домена Active Directory, файл базы данных которого был восстановлен (скопирован) на место с помощью программы создания образов, например Norton Ghost.
- Запуск ранее сохраненного образа виртуального жесткого диска контроллера домена. Следующий сценарий может вызвать откат USN:
- Повышение уровня контроллера домена в виртуальной среде размещения.
- Создайте snapshot или альтернативную версию виртуальной среды размещения.
- Позвольте контроллеру домена продолжить реплицировать входящий и исходящий репликацию.
- Запустите файл образа контроллера домена, созданный на шаге 2.
- Примерами виртуализированных сред размещения, которые вызывают этот сценарий, являются Microsoft Virtual PC 2004, Microsoft Virtual Server 2005 и EMC VMWARE. Другие виртуализированные среды размещения также могут вызвать этот сценарий.
- Дополнительные сведения об условиях поддержки для контроллеров домена в виртуальных средах размещения см. в статье Что следует учитывать при размещении контроллеров домена Active Directory в виртуальных средах размещения.
- Запуск контроллера домена Active Directory, расположенного на томе, где загружается дисковая подсистема, с помощью ранее сохраненных образов операционной системы без необходимости восстановления состояния системы Active Directory.
- Сценарий A. Запуск нескольких копий Active Directory, расположенных в подсистеме диска, в котором хранится несколько версий тома
- Повышение уровня контроллера домена. Найдите файл Ntds.dit в подсистеме диска, которая может хранить несколько версий тома, на котором размещен файл Ntds.dit.
- Используйте подсистему диска, чтобы создать snapshot тома, на котором размещается файл Ntds.dit для контроллера домена.
- Продолжайте разрешать контроллеру домена загружать Active Directory из тома, созданного на шаге 1.
- Запустите контроллер домена, сохраненный базой данных Active Directory на шаге 2.
- Сценарий Б. Запуск Active Directory с других дисков в неработающем зеркало
- Повышение уровня контроллера домена. Найдите файл Ntds.dit на зеркальном диске.
- Разорвать зеркало.
- Продолжайте входящую репликацию и исходящую репликацию с помощью файла Ntds.dit на первом диске в зеркало.
- Запустите контроллер домена с помощью файла Ntds.dit на втором диске в зеркало.
Даже если они не предназначены, каждый из этих сценариев может привести к откату контроллеров домена до более старой версии базы данных Active Directory с помощью неподдерживаемых методов. Единственный поддерживаемый способ отката содержимого Active Directory или локального состояния контроллера домена Active Directory — использовать служебную программу резервного копирования и восстановления с поддержкой Active Directory, чтобы восстановить резервную копию состояния системы, созданную из той же установки операционной системы и того же физического или виртуального компьютера, который восстанавливается.
Корпорация Майкрософт не поддерживает какой-либо другой процесс, который принимает snapshot элементов системного состояния контроллера домена Active Directory и копирует элементы этого состояния системы в образ операционной системы. Если администратор не вмешается, такие процессы вызывают откат USN. Такой откат USN приводит к тому, что партнеры прямой и транзитивной репликации неправильно восстановленного контроллера домена имеют несогласованные объекты в базах данных Active Directory.
Последствия отката USN
При откате USN изменения объектов и атрибутов не реплицируются контроллерами домена назначения, которые ранее видели USN.
Так как эти контроллеры домена назначения считают, что они актуальны, ошибки репликации не отображаются в журналах событий службы каталогов или в средствах мониторинга и диагностики.
Откат USN может повлиять на репликацию любого объекта или атрибута в любой секции. Наиболее часто наблюдаемый побочный эффект заключается в том, что учетные записи пользователей и компьютеров, созданные на контроллере отката домена, не существуют в одном или нескольких партнерах по репликации. Кроме того, обновления паролей, которые были созданы на контроллере отката домена, не существуют в партнерах по репликации.
На следующих шагах показана последовательность событий, которые могут вызвать откат USN. Откат USN происходит при откате состояния системы контроллера домена во времени с помощью неподдерживаемого восстановления состояния системы.
- Администратор продвигает три контроллера домена в домене. (В этом примере контроллерами домена являются DC1, DC2 и DC2, а домен — Contoso.com.) DC1 и DC2 являются партнерами по прямой репликации. DC2 и DC3 также являются прямыми партнерами по репликации. DC1 и DC3 не являются партнерами прямой репликации, но получают исходные обновления транзитивно через DC2.
- Администратор создает 10 учетных записей пользователей, соответствующих usn от 1 до 10 в DC1. Все эти учетные записи реплицируются в DC2 и DC3.
- Образ диска операционной системы записывается в DC1. Это изображение содержит запись объектов, соответствующих локальным usN от 1 до 10 в DC1.
- В Active Directory внесены следующие изменения:
- Пароли для всех 10 учетных записей пользователей, созданных на шаге 2, сбрасываются в DC1. Эти пароли соответствуют usn от 11 до 20. Все 10 обновленных паролей реплицируются в DC2 и DC3.
- В DC1 создается 10 новых учетных записей пользователей, соответствующих USN 21–30. Эти 10 учетных записей пользователей реплицируются в DC2 и DC3.
- В DC1 создается 10 новых учетных записей компьютеров, соответствующих USN 31–40. Эти 10 учетных записей компьютеров реплицируются в DC2 и DC3.
- В DC1 создается 10 новых групп безопасности, соответствующих USN 41–50. Эти 10 групп безопасности реплицируются в DC2 и DC3.
- DC1 испытывает сбой оборудования или программного обеспечения. Администратор использует программу создания образа диска для копирования образа операционной системы, созданного на шаге 3, на место. DC1 теперь начинается с базы данных Active Directory, которая знает об usn от 1 до 10. Так как образ операционной системы был скопирован на место, а поддерживаемый метод восстановления состояния системы не использовался, DC1 продолжает использовать тот же идентификатор вызова, который создал начальную копию базы данных, и все изменения до USN 50. DC2 и DC3 также поддерживают один и тот же идентификатор вызова для DC1, а также актуальный вектор USN 50 для DC1. (Актуальный вектор — это текущее состояние последних исходных обновлений, возникающих на всех контроллерах домена для определенной секции каталога.) Если администратор не вмешается, DC2 и DC3 не реплицируют входящий трафик изменения, соответствующие локальным usN 11–50, исходящим из DC1. Кроме того, в соответствии с идентификатором вызова, который использует DC2, DC1 уже знает об изменениях, которые соответствуют USN от 11 до 50. Поэтому DC2 не отправляет эти изменения. Так как изменения, внесенные в шаге 4, не существуют в DC1, запросы на вход завершаются ошибкой «доступ запрещен». Эта ошибка возникает из-за того, что пароли не совпадают или учетная запись не существует, когда более новые учетные записи случайным образом проходят проверку подлинности с помощью DC1.
- Администраторы, отслеживающие работоспособность репликации в лесу, отмечают следующие ситуации:
- Программа Repadmin /showreps командной строки сообщает, что двусторонняя репликация Active Directory между DC1 и DC2, а также между DC2 и DC3 выполняется без ошибок. В этой ситуации трудно обнаружить любое несоответствие репликации.
- События репликации в журналах событий службы каталогов контроллеров домена под управлением Windows Server не указывают на сбои репликации в журналах событий службы каталогов. В этой ситуации трудно обнаружить любое несоответствие репликации.
- Пользователи и компьютеры Active Directory или средство администрирования Active Directory (Ldp.exe) отображает разное количество объектов и метаданные объектов, если секции доменных каталогов в DC2 и DC3 сравниваются с разделом в DC1. Разница заключается в наборе изменений, сопоставленных с изменениями USN с 11 по 50 на шаге 4.
Примечание. В этом примере разное число объектов применяется к учетным записям пользователей, учетным записям компьютеров и группам безопасности. Различные метаданные объекта представляют разные пароли учетных записей пользователей.
Хотя симптомы, упомянутые на шаге 6, представляют собой некоторые последствия, которые откат USN может оказать на учетные записи пользователей и компьютеров, откат USN может предотвратить репликацию любого типа объекта в любой секции Active Directory. К этим типам объектов относятся следующие:
- Топология и расписание репликации Active Directory
- Наличие контроллеров домена в лесу и роли, которые эти контроллеры домена удерживают
Примечание. К этим ролям относятся глобальный каталог, выделение относительных идентификаторов (RID) и операции, master роли. (Роли master операций также называются гибкими операциями master или FSMO.)
Размер дыры USN может представлять сотни, тысячи или даже десятки тысяч изменений пользователей, компьютеров, доверия, паролей и групп безопасности. (Отверстие USN определяется разницей между наибольшим номером USN, которое существовало при резервном копировании состояния системы, и числом исходных изменений, созданных на контроллере домена с откатом до его отключения.)
Обнаружение отката USN на контроллере домена Windows Server
Так как откат USN трудно обнаружить, контроллер домена Windows Server 2003 с пакетом обновления 1 (SP1) или более поздней версии регистрирует событие 2095, когда исходный контроллер домена отправляет ранее признанный номер USN на контроллер домена назначения без соответствующего изменения идентификатора вызова.
Чтобы предотвратить создание уникальных обновлений для Active Directory на неправильно восстановленном контроллере домена, служба сетевого входа приостановлена. Когда служба сетевого входа приостановлена, учетные записи пользователей и компьютеров не могут изменить пароль на контроллере домена, который не будет реплицировать такие изменения из исходящего трафика. Аналогичным образом средства администрирования Active Directory будут предпочитать работоспособный контроллер домена при обновлении объектов в Active Directory.
На контроллере домена сообщения о событиях, похожие на следующие, записываются при выполнении следующих условий:
- Исходный контроллер домена отправляет ранее признанный номер USN на контроллер домена назначения.
- Соответствующее изменение в идентификаторе вызова отсутствует.
Эти события могут быть записаны в журнал событий службы каталогов. Однако они могут быть перезаписаны, прежде чем они будут замечены администратором.
Вы можете подозревать, что произошел откат USN. Однако коррелирующие события не отображаются в журнале событий службы каталогов. В этом сценарии проверка для записи в реестре Dsa Not Writable. Эта запись предоставляет судебно-медицинские доказательства того, что произошел откат USN.
- Подраздел реестра: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
- Запись реестра: Dsa Not Writable
- Значение: 0x4
Удаление или изменение значения записи реестра Dsa Not Writable вручную переводит контроллер домена отката в состояние постоянно неподдерживаемого. Поэтому такие изменения не поддерживаются. В частности, изменение значения удаляет поведение карантина, добавленное кодом обнаружения отката USN. Разделы Active Directory на контроллере домена отката будут постоянно несовместимы с партнерами прямой и транзитивной репликации в том же лесу Active Directory.
Восстановление после отката USN
Существует три подхода к восстановлению после отката USN.
- Удалите контроллер домена из домена. Для этого выполните следующие действия:
- Удалите Active Directory из контроллера домена, чтобы сделать его автономным сервером. Дополнительные сведения см. в статье Контроллеры домена не понижают корректно при использовании мастера установки Active Directory для принудительного понижения.
- Завершите работу пониженного сервера.
- На работоспособном контроллере домена очистите метаданные пониженного контроллера домена. Дополнительные сведения см. в статье Очистка метаданных сервера контроллера домен Active Directory.
- Если неправильно восстановленный контроллер домена размещает операции master ролей, перенесите эти роли в работоспособный контроллер домена. Дополнительные сведения см. в статье Передача или захват ролей хозяина операций в доменные службы Active Directory.
- Перезапустите пониженный сервер.
- Если требуется, снова установите Active Directory на автономном сервере.
- Если контроллер домена ранее был глобальным каталогом, настройте его как глобальный каталог. Дополнительные сведения см. в статье Создание или перемещение глобального каталога.
- Если ранее размещенные на контроллере домена операции master роли, перенесите операции master роли обратно в контроллер домена. Дополнительные сведения см. в статье Передача или захват ролей хозяина операций в доменные службы Active Directory.
- Восстановите состояние системы хорошей резервной копии. Оцените, существуют ли допустимые резервные копии состояния системы для этого контроллера домена. Если действительная резервная копия состояния системы была выполнена до неправильного восстановления контроллера домена с откатом, а резервная копия содержит последние изменения, внесенные на контроллере домена, восстановите состояние системы из последней резервной копии.
- Восстановление состояния системы без резервного копирования состояния системы. Вы можете использовать snapshot в качестве источника резервной копии. Кроме того, вы можете задать для базы данных новый идентификатор вызова, выполнив процедуру в разделе Восстановление предыдущей версии виртуального контроллера домена VHD без резервного копирования данных состояния системыраздела Выполнение контроллеров домена в Hyper-V.
Ссылки
- Что следует учитывать при размещении контроллеров домена Active Directory в виртуальных средах размещения
- Архитектура виртуализированного контроллера домена
Обратная связь
Были ли сведения на этой странице полезными?
Лучшее решение при USN Rollback?
Возникла следующая ситуация:
Есть 3 КД: DC, DC2, DC3.
DC — бывший основной КД. Находится в состоянии UNS Rollback.
DC2 — основной КД. Владелец ролей FSMO.
DC3 — нормально реплицируется и работает.Потенциальный метод решения проблемы — понизить/повысить DC и жить дальше(рекомендовано Microsoft), но есть нюанс. На DC развернут единственный AD CS. Понизить КД без удаления службы невозможно. Насколько я понимаю, удаление службы грозит невозможность проверки выданных сертификатов (на основании самоподписного Root). Крайне нежелательно, так как есть куча клиентов на терминальном доступе.
Закралась мысль попробовать восстановить DC с помощью штатного Backup/Restore (чтобы изменить значение Invocation ID). После включить репликацию и удалить значение — DSA not writeable.
Вопрос следующий — лучшее ли это решение в данной ситуации или я упустил какой-то нюанс?
Может можно сделать всё проще?
Не повредит ли восстановление DC службе AD CS?P.S. Нет практического опыта переноса службы AD CS на другой сервер. Источники в интернете противоречивы. Возможности сделать cname DC на другой КД нет, так как DC обязательно нужен в сети с таким же именем.
- Вопрос задан более трёх лет назад
- 482 просмотра
Комментировать
Решения вопроса 2
Alexey Dmitriev @SignFinder
Wintel\Unix Engineer\DevOps«Насколько я понимаю, удаление службы грозит невозможность проверки выданных сертификатов (на основании самоподписного Root).»
Почему вы так думаете?
CA не нужно наличие ADDS на той же машине для функционирования.Плюс она бекапится и восстанавливается довольно просто. Так что бекапы, DC force removal, install new OS, promote new DC, restore CA.
Последний пункт даже правильнее звучит так — build new VM, restore CA.Ответ написан более трёх лет назад
Нравится 1 4 комментарияSergei Shevchenko @Irish_Blood Автор вопроса
Возможно. Но при попытке понизить КД — однозначно требует удалить службу AD CS.
Проверено лично!Sergei Shevchenko @Irish_Blood Автор вопроса
Меня очень волнуют потенциальные проблемы с сертификатами.
Если я сделаю force removal при установленном там AD CS — насколько это может повлиять?Alexey Dmitriev @SignFinder
Sergei Shevchenko, я не в курсе, никогда не имел CA размещенным с какими-то другими ролями.
При force removal вы можете потерять членство бывшего DC в домене, придется после metadata cleanup перевводить в домен.
CA нужно забекапить, а лучше вообще поднять новую VM на любом сервере и перенести.Вообще главный ответ на ваш вопрос он таков — не стоит в продакшн среде делать то, в чем вы не уверены.
Sergei Shevchenko @Irish_Blood Автор вопроса
Alexey Dmitriev,согласен, именно потому и пришел задать вопросы.
Может у кого был практический опыт с переносом CA без отзыва сертификатов.
В любом случае, большое вам спасибо за мнение и мысли!Чиню домены.
Представьте себе, что в один не очень прекрасный день вы решили восстановить один из ваших контроллеров домена (КД) из резервной копии, которую вы по привычке сделали старым проверенным средством снятия образа диска, типа Acronis TrueImage. Или решили откатить ваш виртуализованный КД к старому снимку, сделанному средствами гипервизора (и всё это работало не под Windows Server 2012). Или же вам, как и мне однажды, не повезло: из-за сбоя RAID-контроллера, который управляет аппаратным зеркальным томом, содержащим систему КД, некоторое время тому назад из этого зеркала вылетел один диск, а после перезапуска RAID-контроллер решил загрузить систему именно с этой, устаревшей половинки зеркала.
И вот, после перезагрузки вы обнаруживаете, что ваш контроллер домена — уже не совсем контроллер домена: он совершенно не желает авторизовывать пользователей и реплицировать изменения базы данных Active Directory (AD) с другими КД. Если провести стандартную диагностику проблем AD с помощью утилит dcdiag, то мы увидим следующее (часть выдачи dcdiag для краткости опущена, важные для дальнейшего изложения признаки выделены жирным шрифтом):
Doing primary tests
Testing server: Default-First-Site-Name\DC2
Starting test: Advertising
Warning: DsGetDcName returned information for \\DC1.domain.loc, when
we were trying to reach DC2.
SERVER IS NOT RESPONDING or IS NOT CONSIDERED SUITABLE.
……………………. DC2 failed test Advertising
…………………………………………………………………Starting test: Replications
[Replications Check,Replications Check] Inbound replication is
disabled.
To correct, run «repadmin /options DC2 -DISABLE_INBOUND_REPL»
[Replications Check,DC2] Outbound replication is disabled.
To correct, run «repadmin /options DC2 -DISABLE_OUTBOUND_REPL»
……………………. DC2 failed test Replications
Starting test: RidManager
……………………. DC2 passed test RidManager
Starting test: Services
w32time Service is stopped on [DC2]
NETLOGON Service is paused on [DC2]
……………………. DC2 failed test Services
— то есть, контроллер домена не объявляет себя контроллером домена, репликация базы данных AD отключена, а служба Netlogon («Сетевой вход в систему» в русской версии) находится в приостановленном состоянии. Если вы посмотрите в журнал событий Active Directory, то вы обнаружите в нём два характерных сообщения об ошибках:с Event ID 2095
и с Event ID 2103
Первое из этих событий фиксируется лишь однажды, при первой после возникновения проблемы перезагрузке, второе же будет появляться и при каждой последующей перезагрузке контроллера домена.
Если вы наблюдаете эти признаки, то это означает, что вы столкнулись с героем этой статьи — USN Rollback: возвращением текущего максимального последовательного номера изменений (USN) КД к старому, меньшему значению (с помощью номеров последовательных изменений — USN — Active Directory отслеживает, какие именно изменения следует передавать при репликации между контроллерами домена, подробнее об этом ниже). Прочитать официальную информацию от Microsoft об этой проблеме можно в Technet Library (применительно к специфике виртуализованных контроллеров домена) или статье 885875 MS KB (на английском языке).
Хотя механизм возникновения данной проблемы изложен в указанных выше статьях, считаю необходимым для полноты изложения остановиться на нём и в этой статье (те, кому это не интересно или некогда это читать, могут перейти сразу к описанию процедуры восстановления в разделе Собственно рецепт). Потому что, чтобы понять, чем плохо возвращение текущего максимального универсального номера последовательных изменений к старому значению, нужно знать, как используются эти номера при обновлении копий базы данных Active Directory.
Active Directory спроектирована таким образом, чтобы при синхронизации (репликации) можно было передавать на целевой КД не всю базу данных, а только те изменения, которые не были ещё получены целевым КД. Для этого каждый измененный (в т.ч. вновь созанный) в базе данных AD объект или атрибут объекта маркируется в своих метаданных идентификатором КД (Invocation ID), на котором было первоначально произведено это изменение, и последовательным номером (USN) этого изменения на данном первоначальном КД (посмотреть метаданные для любого объекта и всех его атрибутов можно командой repadmin /showmeta ). При каждом изменении, первоначально произведенном на данном КД, этот номер увеличивается. Кроме того, каждый КД хранит у себя список максимальных номеров реплицированных изменений для каждого из известных ему КД-источников обновлений (идентифицируемых по Invocation ID) для каждого из разделов каталога — up-to-dateness vector (его можно посмотреть командой repadmin /showutdvec ). И при репликации КД запрашивает только те изменения, номер USN которых выше максимального номера уже полученного изменения.
Из этого описания видно, что если текущий максимальный номер USN по какой-то причине уменьшится, то изменения, промаркированные номерами USN в промежутке между новым текущим максимальным номером USN и запомненными на других КД максимальными номерами реплицированных изменений, никогда не будут реплицированы на эти другие КД, то есть, база данных AD окажется в рассогласованном состоянии — её содержимое на разных контроллерах доменов навсегда останется разным.
Поскольку все алгоритмы работы AD опираются на то, что содержимое баз данных на разных КД является (или достаточно быстро становится) одинаковым, то описанное выше положение дел является недопустимым. Чтобы его избежать, в механизм репликации AD был добавлен элемент контроля, проверяющий в момент первой репликации КД, что текущий максимальный номер USN на контроллере домена не меньше, чем максимальный номер реплицированных изменений, известных его партнерам по репликации. Если это условие не соблюдается, то AD блокирует входящую и исходящую репликацию, а также помечает (в реестре) свою копию базы данных как недоступную для записи по причине возвращения номера USN к меньшему значению — что как раз вызывает те самые симптомы, что описаны в начале статьи.
Обнаружение USN Rollback срабатывает, к сожалению, не всегда. Если контроллер домена после восстановления из образа долго не имеет связи с другими КД, и на нём за это время происходит много изменений, то после восстановления связи может оказаться, что на момент первой репликации после восстановления текущий максимальный номер USN окажется больше максимального номера реплицированных изменений, то условие отсутствия USN Rollback будет формально соблюдено, фактически имевший место откат назад номеров изменений обнаружен не будет и часть изменений так и останется не реплицированной. Такой вариант вполне реален при восстановлении КД после катастрофического отказа где-нибудь в филиале, где из-за того же отказа пострадала и связь. Так что, обнаружив приведенные в начале статьи симптомы, можно даже порадоваться — всё могло быть и хуже.
Как лечить USN Rollback
Лучшее лечение — это, как известно, профилактика. В применении к теме данной статьи это означает: делать резервные копии базы данных AD (она входит в раздел Состояние системы для КД) регулярно, и делать их программой, которая знает, как копировать и, главное — как восстанавливать базу данных AD. Простейшая из таких программ — это встроенная Windows Server Backup. Использование правильных программ исключает большинство возможных случаев возникновения USN Rollback, а если вдруг такая беда случилась (например, из-за сбоя RAID-контроллера, зеркалирующего системный диск) — без особых проблем восстановить базу данных AD.
Но вот что делать если беда уже случилась, а резервной копии базы данных AD нет? Рекомендации производителя — Microsoft — просты и незатейливы: понизить принудительно контроллер домена, удалить его метаданные из AD и повысить обратно. Процедуры эти просты и многократно описаны, здесь я на них останавливаться не буду. В большинстве случаев это можно проделать вполне безболезненно, и, собственно говоря, при наличии возможности именно так и стоит делать.
Интереснее другой вопрос — что делать, если принудительное понижение с последующим понижением — не вариант? Например, если на КД стоит какая-то программа, которая, с немалой степенью вероятности, не перенесёт такие манипуляции. Или USN Rollback возник на единственном контроллере вновь созданного домена, в котором уже были созданы учётные записи новых пользователей. Или вот, например, был случай на русском форуме Technet, когда системный администратор умудрился загнать в состояние USN Rollback все контроллеры корневого домена леса — как сохранить лес? В таких случаях рекомендованный производителем способ решения проблемы не годится. Но выход, тем не менее, есть.Чтобы понять, как этот выход работает, следует рассмотреть две вещи: как при корректном восстановлении базы данных AD удаётся избежать USN Rollback, и какие именно изменения вносятся в конфигурацию КД при обнаружении этого состояния.
Для обеспечения корректности работы восстановленной базы данных программа восстановления делает одну простую вещь: она после завершения восстановления (а оно производится при загрузке в режиме службы восстановления каталогов) записывает в реестр новое значение для Invocation ID в параметр «HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\New Database GUID», заставляя AD при запуске во время следующей загрузки в нормальном режиме сменить Invocation ID — то есть заставляет выглядеть (с точки зрения механизма репликации базы данных AD) восстановленный контроллер домена как новый, совершенно другой КД, изменения на котором учитываются независимо от прежних, сделанных его до восстановления.
Что же касается реакции на USN Rollback то она включает в себя две вещи: во-первых, для подверженного ей КД отключается (установкой флагов DISABLE_INBOUND_REPL и DISABLE_OUTBOUND_REPL в атрибуте Options объекта «NTDS Settings», связанного с объектом данного КД в разделе конфигурации) входящая и исходящая репликация, во-вторых в реестре этого КД в параметре «HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters\DSA not writeable» (типа REG_DWORD) фиксируется, что база данных AD не является допустимой по причине возникновения USN Rollback (значение параметра устанавливается равным 4). При обнаружении этого последнего параметра происходит запись в журнал события с кодом 2103, а служба Netlogon ставится в приостановленное состояние.
И в свете всего вышеизложенного становится понятно, что нужно делать, чтобы вывести контроллер домена из состояния USN Rollback:
Собственно рецепт.
Предупреждение. Приведенные ниже действия не опираются на официальные рекомендации Microsoft (хотя и проверены мной лично). Они могут привести к возникновению рассогласованных копий базы данных Active Directory на разных контроллерах доменов (см. ниже). Поэтому используйте их под свою ответственность и только в крайнем случае.
Предупреждение 2. Если на пострадавшем контроллере домена в БД AD были внесены какие-либо изменения после возникновения состояния USN Rollback, то эти изменения, скорее всего, никогда не будут реплицированы на другие контроллеры домена, даже после восстановления по указанной ниже процедуре (причины были рассмотрены в предыдущем разделе). Из-за этого произойдёт рассогласование копий БД. И впоследствии это может вылиться в странное поведение (например, несовпадающие пароли учётных записей) или даже в нарушение репликации (ошибка 8606). Если USN Rollback был обнаружен сразу же, и контроллер домена был вовремя заблокирован, то вероятность возникновения таких ошибок невелика. Но если это был, например, восстановленный из образа диска контроллер где-нибудь в филиале, то последствия могут быть весьма неприятными. Я надеюсь рассмотреть, как можно заранее вычислить такие изменения и сделать их доступным для репликации, в одной из следующих статей.
1. Заставить AD изменить Invocation ID. Хотя можно сделать это, напрямую записав соответствующий параметр в реестр, я считаю предпочтительным сделать это с помощью штатного Backup/Restore — это заодно устранит и возможные рассогласования копий папки SYSVOL на пострадавшем контроллере домена и других КД и позволит избедать возможных проблем с её репликацией (это другая тема, которую я тут не затрагиваю). Последовательность действий примерно следующая (я не расписываю подробно все шаги, поскольку они отражены во многих руководствах):
1а. Подготовительные действия. Установить, если ещё не установлен, компонент архивации и подготовить место, куда будет записана резервная копия (либо чистый локальный либо съёмный диск, либо пустую общую сетевую папку). Рекомендую также посмотреть (командой repadmin /showrepl ) зафиксировать текущий Invocation ID контроллера домена.
1б. Выполнить резервное копирование состояния системы (а лучше, если позволяет время и место на диске/папке — всего системного тома).
1в. Загрузиться в режиме восстановления службы каталогов и восстановить состояние системы. Рекомендую делать это от имени локальной учётной записи администратора режима восстановления службы каталогов (я наблюдал случаи, когда попытка восстановления состояния системы при регистрации под доменным администраторам приводила к необъяснимым сбоям).
1г. Загрузить контроллер домена в обычном режиме.
2. Разрешить входящую и исходящую репликацию для контроллера домена. Перед включением репликации в качестве меры предосторожности рекомендую проверить, что показываемое командой repadmin /showrepl значение Invocation ID изменилось по сравнению со старым, зафиксированным на шаге 1а
Включение репликации производится командами
repadmin /options имя_КД -DISABLE_INBOUND_REPL
repadmin /options имя_КД -DISABLE_OUTBOUND_REPL
3. Удалить отметку о том, что база данных AD находится в недопустимом для записи состоянии по причине USN Rollback. Для этого надо запустить редактор реестра, выбрать ключ HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters, найти в нём параметр «DSA not writeable» (его значение должно быть равно 4) и удалить этот параметр.
4. Запустить из приостановленного состояния (если она ещё не запустилась сама) службу Netlogon
После выполнения этих шагов я рекомендую (хотя это не обязательно) ещё раз перезагрузить контроллер домена и выполнить его диагностику с помощью команды dcdiag: после ликвидации USN Rollback могут проявиться и другие ошибки (см. например уже упоминавшийся случай на русском форуме Technet — там пришлось устранять и проблемы с SYSVOL, и не удалённые вовремя («застрявшие») из-за неработавшей репликации объекты).
Удачного вам восстановления. И больше так не делайте.
- Сценарий A. Запуск нескольких копий Active Directory, расположенных в подсистеме диска, в котором хранится несколько версий тома
- Scenario A: Starting multiple copies of Active Directory that are located on a disk subsystem that stores multiple versions of a volume