Певні вимоги операцій відновлення Active Directory набувають додаткову значимість при використанні технології віртуальних машин. Наприклад, при відновленні контролера домену за допомогою копії файлу віртуального жорсткого диска (VHD-файл) пропускається критично важливий крок оновлення версії бази даних контролера домену після його відновлення. Реплікація буде продовжена з невідповідними номерами відстеження, наслідком чого стане база даних, неузгоджена між репліками контролерів домену. У більшості випадків ця проблема залишиться непоміченою системою реплікації і повідомлень про помилки не буде, за винятком неузгодженостей між контролерами домена.
Є два підтримуваних способу здійснення резервного копіювання та відновлення віртуалізованого контролера домену.
- Виконання системи архівації даних Windows Server в операційній системі на віртуальній машині.
Як було зазначено вище, контролери домену, що функціонують на віртуальних машинах, мають функціональні обмеження, яких немає для контролерів домену, які працюють на фізичних комп'ютерах. При архівації та відновлення віртуального контролера домену не можна використовувати деякі можливості програмного забезпечення віртуалізації і прийоми роботи.
- Не копіюйте і не клонуйте VHD-файли контролерів домену замість створення звичайних резервних копій. У разі копіювання або клонування VHD-файлу він стає застарілим. Якщо потім VHD-файл запускається в звичайному режимі, може виникнути невідповідність даних реплікації в лісі. Необхідно виконати належні операції архівації, підтримувані доменними службами Active Directory, наприклад використовуючи систему архівації даних Windows Server.
Необхідно регулярно архівувати стан системи для відновлення контролера домену в разі його збою. Стан системи містить файли журналів і дані Active Directory, реєстр, системний том (папка SYSVOL) і різні елементи операційної системи. Ця вимога в рівній мірі відноситься до контролерів домену, що функціонує на віртуальній машині або на базовому обладнанні. Процедури відновлення стану системи, що реалізуються додатками архівації, сумісними з Active Directory, розроблені таким чином, щоб забезпечувати узгодженість локальних і реплікованих баз даних Active Directory після завершення процесу відновлення, включаючи повідомлення партнерів по реплікації про скиди значення атрибута invocationID. Однак використання віртуальних середовищ розміщення і додатків створення образів операційних систем або дисків дозволяє адміністраторам обходити перевірки і контроль даних, які, як правило, виконуються при відновленні стану системи контролера домену.
У разі збою віртуальної машини, яка виконує роль контролера домену, і відсутності відкоту номера послідовного оновлення (USN) є два підтримуваних варіанти відновлення віртуальної машини.
Щоб визначити оптимальний спосіб відновлення віртуалізованого контролера домену, скористайтеся процесом, зображеним на наступному малюнку.
Процес відновлення та прийняті рішення простіше для контролерів домену тільки для читання.
Якщо є дійсна резервна копія стану системи віртуальної машини, налаштованої в якості контролера домену, можна безпечно відновити резервну копію, дотримуючись процедури, яка визначається засобом архівації, використаним для створення резервної копії VHD-файлу.
Щоб належним чином відновити контролер домену, необхідно запустити його в режимі DSRM. Необхідно запобігти запуск контролера домену в звичайному режимі. Якщо ви пропустили можливість увійти в режим DSRM під час запуску системи, вимкніть віртуальну машину, налаштовану в якості контролера домену, перш ніж завершиться процедура її запуску в звичайному режимі. Важливо запустити контролер домену саме в режимі DSRM, оскільки при запуску контролера домену в звичайному режимі відбувається збільшення значень його номерів послідовного оновлення, навіть якщо він відключений від мережі. Додаткові відомості про відкат номера послідовного поновлення см. До Додатку A: віртуалізовані контролери домену та проблеми реплікації.
Запустіть віртуальну машину, налаштовану в якості контролера домену, і натисніть клавішу F5 для переходу до екрану диспетчера завантаження Windows. Якщо з'явився запит введення облікових даних підключення, негайно натисніть кнопку Пауза на віртуальній машині, щоб призупинити запуск. Потім введіть облікові дані підключення і натисніть кнопку Відтворення на віртуальній машині. Клацніть мишею у вікні віртуальної машини і натисніть клавішу F5.
Якщо екран диспетчера завантаження система Windows не з'явився і почався запуск контролера домену в звичайному режимі, вимкніть віртуальну машину, перш ніж завершиться процедура запуску. Повторюйте ці дії до тих пір, поки не отримаєте доступ до екрану диспетчера завантаження Windows. З меню відновлення після помилок Windows немає доступу до режиму DSRM. Тому, якщо з'явилося меню відновлення після помилок Windows, спробуйте відключити віртуальну машину і включити її знову.
На екрані диспетчера завантаження Windows натисніть клавішу F8, щоб перейти до меню додаткових варіантів завантаження.
У меню Додаткові варіанти завантаження виберіть Режим відновлення служб каталогів і натисніть клавішу ENTER. Відбудеться запуск контролера домену в режимі DSRM.
Якщо відсутня резервна копія даних стану системи, створена до моменту збою віртуальної машини, можна використовувати попередній VHD-файл для відновлення контролера домену, що виконується на віртуальній машині. Якщо це можливо, створіть копію VHD-файлу, щоб при виявленні збою в процедурі або при пропуску кроку, можна було повторно виконати всі дії з копією VHD-файлу.
- Не слід розглядати наступну процедуру в якості заміни резервне копіювання інформації.
Використовуючи попередній віртуальний жорсткий диск, запустіть віртуальний контролер домену в режимі DSRM, як описано в попередньому підрозділі. Необхідно запобігти запуск контролера домену в звичайному режимі. Якщо екран диспетчера завантаження система Windows не з'явився і почався запуск контролера домену в звичайному режимі, вимкніть віртуальну машину, перш ніж завершиться процедура запуску. Докладні інструкції для входу в режим DSRM см. В попередньому підрозділі.
Клацніть правою кнопкою миші розділ Параметри. виберіть команду Створити. а потім - пункт Параметр DWORD (32 біти).
Введіть нове ім'я Database restored from backup (база даних, відновлена з резервної копії) і натисніть клавішу Enter.
Перезапустіть контролер домену в звичайному режимі.
Розгорніть вузол Журнали додатків і служб щоб перейти до журналу Служби каталогів. Переконайтеся, що в області відомостей відображаються події.
Клацніть правою кнопкою миші журнал Служби каталогів і виберіть команду Знайти. В поле Що знайти введіть 1109 і натисніть кнопку Знайти далі.
Повинна відображатися щонайменше запис події з кодом 1109. За відсутності такого запису пропустіть цей крок. В іншому випадку двічі клацніть запис і прочитайте текст, який повинен підтверджувати, що був оновлений атрибут InvocationID.