IT2web

Системному администратору Windows Server

Главная --> Active Directory --> USN Rollback

USN Rollback

USN RollbackЛюбовь некоторых администраторов к ПО Acronis откровенно удивляет. Это ПО полезно, но без оглядки применять его везде и всюду не стоит…

Как правило “веселые ребята” которые упорно бэкапят контроллеры, после восстановления сильно удивляются тому что останавливается репликация и ничего кроме проблем (я называю эту ситуацию – резюме генерэйшн эвент :) ) это восстановление не приносит.

При большой любви к Acronis-у и прочим ничто не мешает выполнять сначала резервирование состояния системы (system State Backup) а потом уже снапшот диска. И коли есть желание восстановиться то можно восстановить снапшот а потом System State.


Не буду вдаваться в теорию (совсем немного) и предлагаю рассмотреть следующий сценарий.

Update Sequence Number (USN) это элемент метаданных репликации, называемый номером последовательного обновления. Каждый контроллер домена поддерживает USN, который ему специфичен. При внесении изменений в Active Directory к значению USN прибавляется 1. USN существует только в пределах контроллера домена, никакого отношения к USN на соседнем контроллере он не имеет.

Для простоты понимания можно привести следующий пример.

У двух контроллеров TEST-DC01 (USN=100) TEST-DC02(USN=200) свои значения USN. При репликации они ими обмениваются и каждый запоминает значение USN партнера, что бы после оповещения об изменениях партнер забрал произведенные изменения.

Теоретические изыски дальше будет излишними т.к. это тема для отдельной статьи.

Теперь пример.

У клиента два контроллера TEST-DC1 и TEST-DC2 на Windows Server 2003 и куча проблем в виде неработающей репликации и пр. иначе бы не позвонили :)

Проблема.

  • Репликация между контроллерами остановилась. Местные “админы” заводят пользователей поочереди на обоих контроллерах.
  • Контроллеры домена находятся в онлайне и их имена разрешаются через DNS.
  • Все необходимые для работы записи присутствуют в DNS.

Приступаем к диагностике.

  • Контроллер домена виртуализирован на сервере Hyper-V и его восстановили из снапшота двух недельной давности (хороший пример для USN rollback)
  • В журнале присутствует сообщение с ID 2095

Event Type: Error
Event Source: NTDS Replication
Event Category: Replication
Event ID: 2095
Date: 1/06/2011
Time: 4:30:20 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: TEST-DC2
Description:
During an Active Directory 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.

  • Так же в журнале присутствует сообщение ID 2103

Event Type: Error
Event Source: NTDS General
Event Category: Service Control
Event ID: 2103
Date: 1/06/2011
Time: 4:30:20 PM
User: NT AUTHORITY\ANONYMOUS LOGON
Computer: TEST-DC2
Description:
The Active Directory database has been restored using an unsupported restoration procedure.
Active Directory will be unable to log on users while this condition persists. As a result, the Net Logon service has paused.

При проверке состояния сервиса NetLogon мы убеждаемся что он действительно стоит на паузе.

C:\>sc query netlogon
SERVICE_NAME: netlogon
TYPE : 20 WIN32_SHARE_PROCESS
STATE : 7 PAUSED
(STOPPABLE, PAUSABLE, IGNORES_SHUTDOWN))
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0

Изучая ситуацию дальше, запускаем на первом контроллере TEST-DC1 команду:

C:\>repadmin /showutdvec test-dc1 dc=lab,dc=local
Caching GUIDs.
..
Default-First-Site-Name\TEST-DC2 @ USN 13435 @ Time 2011-06-01 15:37:49
Default-First-Site-Name\TEST-DC1 @ USN 12146 @ Time 2011-06-01 15:52:08

На TEST-DC2 аналогичную команду:

C:\>repadmin /showutdvec test-dc2 dc=lab,dc=local
Caching GUIDs.
..
Default-First-Site-Name\TEST-DC2 @ USN 13409 @ Time 2011-06-01 15:52:49
Default-First-Site-Name\TEST-DC1 @ USN 12146 @ Time 2011-06-01 15:04:22

В итоге, проблема заключается в том что TEST-DC1 имеет USN равный 13435, а TEST-DC2 знает о том что входящий USN был равен 13409 (ты где был? я не верю что это ты!) и как следствие выполняется блокировка обновления службы каталогов.

Метод №1

Данный метод не является лечением от USN Rollback, он скорее предотвращает его возникновение т.к. основан на ключе реестра который сообщает что служба каталогов была восстановлена из резервной копии.

При восстановлении снапшота виртуальной машины (можно читать как при восстановлении с помощью Акрониса) необходимо.

  • Загрузить контроллер в DSRM (Directory Service Restore Mode) режиме. Если вы загрузились в обычном режиме то переходите к методу №2.
  • Открыть редактор реестра, найти ветку
HKLM\System\CurrentControlSet\Services\NTDS\Parameters

в ней ищем параметр DSA Previous Restore Count и ставим его в 0. Если значения нет то создавать его не надо.

  • Добавляем Database restored from backupв
HKLM\System\CurrentControlSet\Services\NTDS\Parameters
Data type: REG_DWORD
Value: 1
  • Выполняем перезагрузку.
  • Проверяем что значение DSA Previous Restore Count стало равным 1.
  • В журнале Directory Service проверьте события ID 1109 или ID 1587. Эти события подтверждают что база Active Directory восстановлена нормально.

Метод №2

Тут все немного сложнее. Придется либо обновлять резюме :) либо запастись терпением при чтении мануалов.

Вам придется с проблемного контроллера удалять Active Directory, затем очистить метаданные из AD и восстанавливать роль контроллера.

  • На проблемном контроллере запускаем утилиту dcpromo с ключом /forceremoval
  • После завершения процедуры выключаем контроллер.
  • Процедура чистки метаданных подробно описана в статье базы знаний микрософта, но я для объема полноты приведу пошаговую инструкцию.
C:\>ntdsutil
ntdsutil: metadata cleanup
metadata cleanup: connections
server connections: connect to server test-dc1
Binding to test-dc1 ...
Connected to test-dc1 using credentials of locally logged on user.
server connections: quit
metadata cleanup: select operation target
select operation target: list domains
Found 1 domain(s)
0 - DC=lab,DC=local
select operation target: select domain 0
No current site
Domain - DC=lab,DC=local
No current server
No current Naming Context
select operation target: list sites
Found 1 site(s)
0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
select operation target: select site 0
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
Domain - DC=lab,DC=local
No current server
No current Naming Context
select operation target: list servers in site
Found 2 server(s)
0 - CN=TEST-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
1 - CN=TEST-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
select operation target: select server 1
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
Domain - DC=lab,DC=local
Server - CN=TEST-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
DSA object - CN=NTDS Settings,CN=TEST-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local
DNS host name - TEST-DC2.lab.local
Computer object - CN=TEST-DC2,OU=Domain Controllers,DC=lab,DC=local
No current Naming Context
select operation target: quit
metadata cleanup: remove selected server
Transferring / Seizing FSMO roles off the selected server.
Removing FRS metadata for the selected server.
Searching for FRS members under "CN=TEST-DC2,OU=Domain Controllers,DC=lab,DC=local".
Deleting subtree under "CN=TEST-DC2,OU=Domain Controllers,DC=lab,DC=local".
The attempt to remove the FRS settings on CN=TEST-DC2,CN=Servers,
CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=lab,DC=local failed because "Element not found.";
metadata cleanup is continuing.
"CN=TEST-DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,
CN=Configuration,DC=lab,DC=local" removed from server "test-dc1"
metadata cleanup: quit
ntdsutil: quit
Disconnecting from test-dc1...

Осталось совсем немного.

На вкладке “Name Servers” оснастки DNS удаляем записи контроллера из Forest и Domain DNS зон. В завершении открываем оснастку Active Directory Sites and Services и удаляем проблемный контроллер.

PS. Собственно разговор начинался с того что использование Акрониса для бэкапа контроллеров домена не есть хорошая практика, а в итоге получилась заметка про USN rollback.

Думаю что моя статья поможет кому то в борьбе со зверем или заставит скорректировать свои “бэкапные” предпочтения.

source: http://blog.wadmin.ru/2011/07/usn-rollback/

Комментарии  

 
#1 Егор 31.03.2014 03:17
Спасибо за подробную информацию!
Нюансы, нюансы...
Цитировать