Що таке USN Rollback
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
...........................................................................
з Event ID 2095
і з Event ID 2103
Перше з цих подій фіксується лише одного разу, при першій після виникнення проблеми перезавантаження, друге ж буде з'являтися і при кожній наступній перезавантаження контролера домену.
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г. Завантажити контролер домену в звичайному режимі.
2. Дозволити вхідну і вихідну реплікацію для контролера домену. Перед включенням реплікації в якості запобіжного заходу рекомендую перевірити, що показується командою repadmin / showrepl значення Invocation ID змінилося в порівнянні зі старим, зафіксованим на кроці 1а
Включення реплікації проводиться командами
repadmin / options імя_КД -DISABLE_INBOUND_REPL
repadmin / options імя_КД -DISABLE_OUTBOUND_REPL
4. Запустити з призупиненого стану (якщо вона ще не запустилася сама) службу Netlogon
Після виконання цих кроків я рекомендую (хоча це не обов'язково) ще раз перезавантажити контролер домену і виконати його діагностику за допомогою команди dcdiag: після ліквідації USN Rollback можуть проявитися і інші помилки (див. Наприклад вже згадуваний випадок російською форумі Technet - там довелося усувати і проблеми з SYSVOL, і не видалені вчасно ( «застрягли») через непрацюючі реплікації об'єкти).
Вдалого вам відновлення. І більше так не робіть.