Tw-city.info

IT Новости
2 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Восстановление контроллера домена

Восстановление после сбоев Active Directory

Однако многие приемы, используемые для восстановления после простых сбоев, применимы и к катастрофическим отказам. В данной статье рассматривается, как устранить последствия двух наиболее типичных аварий: отказа DC и случайного удаления объектов

Обычно Active Directory (AD) — ключевая сетевая служба в любой компании, без нее невозможна работа всех прочих механизмов. Поэтому важно заранее подготовиться к авариям различных типов, которые могут произойти в лесу.

Масштабы аварий AD могут быть очень разными. Это может быть просто сбой единственного контроллера домена (DC) или случайное удаление одного объекта. Сложнее, если случайно удалена целая иерархия организационных единиц (OU). В худшем случае требуется восстанавливать целый домен или лес.

Стратегия резервного копирования

В первую очередь необходимо иметь материал для восстановления. По меньшей мере, требуются последние резервные копии состояния системы не менее чем двух контроллеров домена в каждом домене леса. Последние резервные копии состояния системы можно получить с помощью Windows Server Backup (Windows Server 2008 и более новые версии), NTBackup (Windows Server 2003 и Windows 2000 Server) и большинства других инструментов резервного копирования. Однако лучше всего проверить резервные копии, чтобы убедиться в их исправности. Важно использовать инструмент резервного копирования, совместимый со службой Volume Shadow Copy Service (VSS). Программы резервного копирования, в которых применяются образы дисков или моментальные снимки виртуальных машин, как правило, несовместимы с AD. Восстановление резервной копии с помощью одного из этих инструментов может привести к серьезным проблемам репликации, известным как возврат номера последовательного обновления (USN).

В некоторых компаниях ответственность за резервное копирование и восстановление серверов возлагается на одних специалистов, а обслуживание AD — на других. В результате возникают две проблемы. Во-первых, отсутствует прямой контроль над процессом резервного копирования, что затрудняет проверку резервных копий. Во-вторых, для многих инструментов требуется наличие агента на каждом обслуживаемом DC, а это косвенно ведет к расширению доступа к DC.

Чтобы смягчить эти проблемы, я часто применяю двухуровневый подход к резервному копированию DC. С помощью сценария Windows Server Backup запускается на DC каждый вечер, а резервные копии за одну или две недели хранятся локально на DC. Папка, содержащая резервные копии, объявляется общей, и доступ к ней ограничивается инструментом резервного копирования, так как многие инструменты могут работать с общей папкой без агента. Кроме того, иногда я сохраняю файлы архива на соседних DC внутри сайта. Поэтому, например, если в сайте имеются контроллеры домена DC1 и DC2, резервные копии DC1 хранятся в общей папке на DC2, и наоборот.

Перечислим преимущества двухуровневого подхода.

  • Снижается риск, связанный с зависимостью резервного копирования от другой группы специалистов.
  • Выполнить восстановление можно немедленно из собственных файлов резервных копий, имеющихся под рукой, не ожидая, пока восстановлением займутся специалисты другой группы.
  • Не нужно тратить время на ожидание, пока резервная копия будет передана через канал WAN из другого сайта, в случае удаленного резервного копирования.

Используемый сценарий для запуска Windows Server Backup вместе с соответствующими инструкциями опубликованы в блоге по адресу briandesmond.com/blog/managing-local-backups-withwindows-server-backup/.

Восстановление DC

Важное достоинство AD — в основном неизменное состояние DC. Помимо возможности исполнения одной или нескольких ролей мастера операций (FSMO), каждый DC должен быть копией других контроллеров в домене, если исключить потенциальные задержки репликации, зависящие от топологии. Если DC выходит из строя из-за неисправности, неизменность состояния очень удобна, поскольку устраняется необходимость в сложном восстановлении из резервной копии. Вместо этого можно просто заново установить Windows и преобразовать сервер в DC с помощью утилиты Dcpromo, а затем реплицировать данные (предполагается, что в домене больше одного DC). Если в домене лишь один DC, отказоустойчивость можно значительно повысить, развернув второй контроллер.

Но перед переустановкой и повторным преобразованием DC необходимо очистить AD. Последняя операция выполняется в два этапа. На первом этапе захватываются любые роли FSMO, которыми может обладать DC, на другом DC в домене. Если неясно, на каких DC размещены роли FSMO в домене, выполните команду

в окне командной строки. Затем можно захватить роли FSMO с использованием утилиты Ntdsutil. Следуйте инструкциям в разделе Seize FSMO roles в статье Microsoft «Using Ntdsutil.exe to Transfer or Seize FSMO Roles to a Domain Controller» (support.microsoft.com/kb/255504). При захвате роли FSMO не рекомендуется подключать к сети первоначального обладателя роли.

Поскольку нельзя вернуть первоначального владельца роли FSMO, второй шаг — удалить метаданные конфигурации отказавшего контроллера домена в AD. Это можно сделать с помощью утилиты Ntdsutil. Выполните действия, описанные в статье Microsoft «How to Remove Data in Active Directory After an Unsuccessful Domain Controller Demotion» (support.microsoft.com/kb/216498). Однако, если используется версия оснастки Active Directory Users and Computers для Server 2008 (или более новой), это можно сделать, удалив учетную запись DC в организационной единице Domain Controllers.

Повторное назначение компьютера контроллером домена через сеть может оказаться неприемлемым, если из-за большого объема реплицируемых данных сеть подвергается перегрузке. В этом случае существует еще два варианта. Первый — восстановить состояние системы DC из резервной копии и продолжать работу. Второй — использовать функцию восстановления с носителя (Install from Media, IFM), появившуюся в Windows 2003. Благодаря IFM можно задействовать резервную копию состояния системы (подготовленную с помощью NTBackup в Windows 2003) или носитель IFM (созданный с использованием Ntdsutil в Server 2008 или новой версии) и указать Dcpromo базу данных на IFM-носителе. IFM-носитель, подготовленный в Windows 2003, необходимо сначала восстановить в другом месте файловой системы (в этом случае его может использовать Dcpromo). DC внесет необходимые изменения в базу данных на носителе и реплицирует только изменения, так как носитель был создан через сеть.

Жизненный цикл объекта AD

Между удалением объекта и изъятием записи из базы данных AD нет непосредственной связи. Чтобы не нарушить согласованность модели репликации AD, объекты сначала переводятся в состояние, именуемое «захоронением», как показано на рисунке 1. Вместо того чтобы применять распределенный механизм для репликации физического удаления из базы данных, AD реплицирует изменение атрибута, указывающего, что объект удален.

При удалении объекта из AD атрибуту isDeleted присваивается значение True, и почти все атрибуты объекта удаляются. Объект перемещается в контейнер Deleted Objects, а атрибут lastKnownParent отмечается различающимся именем (DN) родительского объекта, прежде чем объект удаляется. Объект, отмеченный как удаленный, невидим для любых инструментов, опрашивающих AD, если не добавить специальный элемент управления LDAP, указывающий на необходимость показывать помеченные к удалению объекты в поисковых результатах AD. Этот элемент управления есть в различных бесплатных инструментах формирования запросов LDAP (таких, как AdFind из www.joeware.net).

Объект останется удаленным в течение определенного времени. По умолчанию время существования «захоронения» в лесу определяется операционной системой первого DC леса. В таблице показано время существования «захоронений» по умолчанию. При обновлении AD время существования «захоронений» для леса не меняется.

Периодически на каждом DC запускается фоновый процесс, именуемый «сбором мусора». «Сборщик мусора» просматривает базу данных в поисках «захоронений» старше установленного для леса срока их существования и удаляет их из базы данных AD.

До того как «захоронение» удалено «сборщиком мусора», можно восстановить объект, реанимировав его. После реанимации восстанавливаются лишь немногие атрибуты, сохранившиеся в процессе «захоронения». Например, атрибуты, сохраненные для объекта пользователя, включают SID пользователя, журнал SID и имя пользователя (sAMAccountName). Обратите внимание, что в этом списке отсутствуют такие атрибуты, как пароль пользователя, членство в группах или демографическая информация (например, имя и подразделение). Списком атрибутов, сохраняемых при «захоронении» объекта, можно управлять, изменяя атрибут searchFlags в определении индивидуального атрибута в схеме. Количество атрибутов не ограничено, но нельзя добавлять связанные атрибуты, такие как членство в группе или база данных почтовых ящиков, содержащая почтовый ящик пользователя.

В лесу AD на функциональном уровне леса (FFL) Server 2008 R2 можно активировать новую функцию — корзину Active Directory Recycle Bin. Как показано на рисунке 2, благодаря корзине Active Directory появляется промежуточное состояние между удалением и «захоронением» объекта. Объект, находящийся в новом удаленном состоянии, не отображается в результатах поиска, но все его атрибуты (в том числе связанные атрибуты, такие как членство в группах) сохраняются.

Читать еще:  Домен и контроллер домена

Объект на стадии удаления можно восстановить точно в том состоянии, в котором он был в момент удаления с использованием того же процесса, который применялся для реанимации. По умолчанию объект остается на стадии удаления в течение времени, равного сроку существования «захоронения» в лесу, в соответствии с таблицей. Этот период можно изменить, изменив атрибут msDSdeletedObjectLifetime леса.

После окончания срока существования объекта, отмеченного как удаленный, «сборщик мусора» перемещает объект на этап утилизации. Утилизация — функциональный эквивалент «захоронения», с одним отличием: нельзя реанимировать утилизированный объект или восстановить его из резервной копии.

Механизмы восстановления объектов

С каждым новым выпуском AD становится все более зрелой, и механизмы восстановления удаленных объектов совершенствуются. В Windows 2000 единственным способом восстановить объект, отмеченный как удаленный, было выполнить принудительное восстановление из резервной копии. Вместе с Windows 2003 появилась концепция реанимации из «захоронений», чтобы получить частичную копию удаленного объекта, не восстанавливая его из резервной копии. В Server 2008 R2 добавилась корзина Active Directory, что позволяет полностью вернуть удаленный объект без восстановления.

Важно отметить, что срок хранения резервной копии AD (а также носителя IFM) — такой же, как у «захоронения». Если включена корзина Active Directory, срок хранения равен меньшему из сроков существования объекта, отмеченного как удаленный, и утилизированного объекта. Например, если срок существования объекта, отмеченного как удаленный, — 180 дней, а утилизированного объекта — 60 дней, то срок хранения будет 60 дней. Таким образом, невозможно восстановить отмеченный как удаленный объект из резервной копии, которая старше этих значений.

Принудительное восстановление

Если требуется получить объект или группу объектов из резервной копии, часто приходится использовать принудительное восстановление. Пункт Directory Services Restore Mode (DSRM) в загрузочном меню (вызываемом нажатием клавиши F8) DC предназначен для принудительного восстановления. Если выполнить загрузку в режиме DSRM, AD не запускается, а база данных переводится в автономный режим. Можно восстановить базу данных AD из резервной копии в режиме DSRM, а затем выбрать восстанавливаемые объекты с помощью Ntdsutil. Обратите внимание, что невозможно выполнить восстановление, если на контроллерах домена Server 2008 и более новых версий остановлена служба NTDS AD.

В ходе принудительного восстановления AD увеличивает внутренний номер версии восстанавливаемых объектов. В результате после подключения DC к сети эти объекты будут реплицированы по всему домену, и восстановленная версия становится глобально действующей.

Часто принудительно восстанавливаются организационные единицы (OU), содержащие множество объектов (учетные записи пользователей, групп, компьютеров, других OU). Предположим, случайно удалена организационная единица Executives из домена contoso.com. Чтобы вернуть OU и все ее содержимое, необходимо выполнить следующие шаги.

1. Загрузитесь в режиме DSRM и выполните регистрацию с паролем DSRM, заданным во время работы Dcpromo.

2. Восстановите системное состояние из резервной копии, созданной до аварии. Не перезагружайте компьютер. Это типичная ошибка, особенно в спешке.

3. Откройте командную строку и запустите Ntdsutil.

4. Запустите команду

5. Воспользуйтесь командой

6. Просмотрите и подтвердите предупреждения безопасности. Затем будет выдано сообщение, подобное показанному на рисунке 3. Обратите внимание на сформированные текстовые и LDIF-файлы.

Восстановление Active Directory из резервной копии

В этой статье мы покажем, как восстановить контроллер домена Active Directory из резервной копии System State, созданной ранее (см. статью Резервное копирование Active Directory) и рассмотрим типы и принципы восстановления DC в AD.

Допустим у вас вышел из строя контроллер домена AD, и вы хотите восстановить его из созданной ранее резервной копии. Прежде чем приступить к восстановлению DC, нужно понять какой сценарий восстановления контроллера домена вам нужно использовать. Это зависит от того, есть ли у вас в сети другие DC и повреждена ли база Active Directory на них.

Восстановление контроллера домена AD через репликацию

Восстановление DC через репликацию – это не совсем процесс восстановления DC из бэкапа. Этот сценарий может использоваться, если у вас в сети есть несколько дополнительных контроллеров домена, и все они работоспособны. Этот сценарий предполагает установку нового сервера, повышение его до нового DC в этом же сайте. Старый контроллер нужно просто удалить из AD.

Это самый простой способ, который гарантирует что вы не внесете непоправимых изменений в AD. В этом сценарии база ntds.dit, объекты GPO и содержимое папки SYSVOL будут автоматически реплицированы на новый DC с DC-ов, оставшихся онлайн.

Если размер базы ADDS небольшой и другой DC доступен по скоростному каналу, это намного быстрее, чем восстанавливать DC из бэкапа.

Типы восстановления Active Directory: полномочное и неполномочное

Есть два типа восстановления Active Directory DS из резервной копии, в которых нужно четко разобраться перед началом восстановления:

    Authoritative Restore (полномочное или авторитативное восстановление) – после восстановления объектов AD выполняется репликация с восстановленного DC на все остальные контроллеры в домене. Этот тип восстановления используется в сценариях, когда упал единственный DC или все DC одновременно (например, в результате атаки шифровальщика или вируса), или когда по домену реплицировалась поврежденная база NTDS.DIT. В этом режиме у всех восстановленных объектов AD значение USN (Update Sequence Number) увеличивается на 100000. Таким образом восстановленные объекты будут восприняты всеми DC как более новые и будут реплицированы по домену. Полномочный способ восстановления нужно использовать очень аккуратно.

Восстановление контроллера домена AD из system state бэкапа

Итак, предположим, что у вас в домене только один DC. По какой-то причине вышел из строя физический сервер, на котором он запущен.

У вас есть относительно свежий бэкап System State старого контроллера домена, и вы хотите восстановить Active Directory на новом сервере в режиме полномочного восстановления.

Чтобы приступить к восстановлению, вам нужно установить на новом сервер туже версию Windows Server, которая была установлена на неисправном DC. В чистой ОС на новом сервере нужно установить роль ADDS (не настраивая ее) и компонент Windows Server Backup.

Для восстановления Actve Directory вам нужно загрузить сервер в режиме восстановления служб каталогов DSRM (Directory Services Restore Mode). Для этого запустите msconfig и на вкладе Boot выберите Safe Boot -> Active Directory repair.

Active Directory repair mode» srcset=»https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode.png 575w, https://winitpro.ru/wp-content/uploads/2019/10/safe-boot-greater-active-directory-repair-mode-300×196.png 300w» sizes=»(max-width: 575px) 100vw, 575px» />

Перезагрузите сервер. Он должен загрузиться в режиме DSRM. Запустите Windows Server Backup (wbadmin) и в правом меню выберите Recover.

В мастере восстановления выберите, что резервная копия хранится в другом месте (A backup stored on another location).

Заметем выберите диск, на котором находится резервная копия старого контроллера AD, или укажите UNC путь к ней.

wbadmin get versions -backupTarget:D:

Выберите дату, на которую нужно восстановить резервную копию.

Укажите, что вы восстанавливаете состояние System State.

Выберите для восстановления «Исходное размещение» (Original location) и обязательно установите галочку «Выполнить заслуживающее доверия восстановление файлов Active Directory» (Perform an authoritative restore of Active Directory files).

Система покажет предупреждение, что эта резервная копия другого сервера, и что при восстановлении на другом сервере может не завестись. Продолжаем.

Согласитесь с еще одним предупреждением:


После этого запустится процесс восстановления контроллера домена AD на новом сервере. По завершении сервер потребует перезагрузку (имя нового сервера будет изменено на имя DC из бэкапа).

Загрузите сервер в обычном режиме (отключите загрузку в DSRM режиме)

Авторизуйтесь на сервере под учетной записью с правами администратора домена.

При первом запуске консоли ADUC я получил ошибку:

При этом на сервере нет сетевых папок SYSVOL and NETLOGON. Чтобы исправить ошибку:

  1. Запустите regedit.exe;
  2. Перейдите в ветку HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetlogonParameters
  3. Измените значение параметра SysvolReady с 0 на 1;
  4. Потом перезапустите службу NetLogon: net stop netlogon & net start netlogon

Попробуйте открыть консоль ADUC еще раз. Вы должны увидеть структуру вашего домена.

Итак, вы успешно восстановили свой контроллер домен AD в режиме Authoritative Restore. Теперь все объекты в Active Directory будут автоматически реплицированы на другие контроллеры домена.

Читать еще:  Доменная учетная запись что это

Если у вас остался единственный DC, проверьте что он является хозяином всех 5 FSMO ролей и выполните их захват, если нужно.

Восстановление отдельных объектов в AD

Если вам нужно восстановить отдельные объекты в AD, воспользуйтесь корзиной Active Directory. Если время захоронения уже просрочено, или ActiveDirectory RecycleBin не включена, вы можете восстановить отдельные объекты AD в режиме авторитаивного восстановления.

Вкратце процедура выглядит следующим образом:

  1. Загрузите DC в DSRM режиме;
  2. Выведите список доступных резервных копий: wbadmin get versions
  3. Запустите восстановление выбранной резервной копии: wbadmin start systemstaterecovery –version:[your_version]
  4. Подтвердите восстановление DC (в не полномочном режиме);
  5. После перезагрузки запустите: ntdsutil
  6. activate instance ntds
  7. authoritative restore

Укажите полный путь к объекту, который нужно восстановить. Можно восстановить OU целиком:

restore subtree ″OU=Users,DC=winitpro,DC=ru″

Или один объект:

restore object “cn=Test,OU=Users,DC=winitpro,DC=ru”

Данная команда запретит репликацию указанных объектов (путей) с других контроллеров домена и увеличит USN объекта на 100000.

Выйдите из ntdsutil: quit

Загрузите сервер в обычном режиме и убедитесь, что удаленный объект был восстановлен.

Восстановление контроллера домена

Восстановление состояния системы из резервной копии можно выполнить на том же физическом компьютере или на другом компьютере того же типа и той же модели, имеющем идентичную конфигурацию (оборудование).
Корпорация Майкрософт не поддерживает восстановление резервной копии состояния системы на другом физическом компьютере другого типа, модели или имеющем другую конфигурацию. В данном случае корпорация Майкрософт предоставляет только ограниченную техническую поддержку. Даже в случае совпадения типа и модели обоих компьютеров могут отличаться драйверы, оборудование или микропрограммное обеспечение.

В данной статье рассматривается процесс создания резервной копии состояния системы на одном компьютере и последующее восстановление этой резервной копии на другом физическом компьютере того же типа и той же модели

Добавление от 15.08.2006 12:45:

Aww
Да статью эту читал . Там про оборудование довольно туманно и непонятно . ЧТо у них идентичное .
Молодцы микрософт , наверно везде на полках стоят такие же компьютеры

a9-serg-64
сеть большая?
Может проще домен переделать а данные из бэкапа восстановить?

наверно везде на полках стоят такие же компьютеры
для сохранения структуры АД ставят 2-й контроллер. а бэкап о котором говорим он индивидуальный и только для ремонта именно этого компьютера . например для случая когда HDD «помер»

a9-serg-64
На новом 925 чипсет , один процессор . На нём HT включить можно?
В SAFE MODE грузится?

Может(!) стоит попробовать сделать так: (ведь дело, как я понимаю, упёрлось в драйвера)

Ставим новую ОС.
Ставим ещё одну новую ОС.
По одной проходим restore system state после чего она не грузится.
На второй ОС(рабочей) запускаемся
копируем INF на убитую ОС
копируем SYSTEM32 (без замены, просто дописываем файлы, которых нет)
и подменяем файл system32configsystem (предварительно сделав копию)
Пробуем запустить.

Сам не пробовал, и но вдруг..

Добавление от 15.08.2006 13:04:

ЗЫ. Не понимаю, как оно
a9-serg-64
Комп просто виснет при загрузке и все .
Если у STL2 винты SCSI, а у 925 — IDE.
Должен бы выпадать в недоступное у-во загрузки.

Добавление от 15.08.2006 13:09:

Sioln
Про винты правильно такие и есть . Загрузка начинается , но виснет .
Загрузочное устройство видит , boot.ini поменял .

a9-serg-64
Пробовал стандартно поставить систему и вывернуть с бекапа . Не вышло .
Комп просто виснет при загрузке и все . без синих экранов

Выходит что виснет не после переустановки, а после восстановления из бакапа ?

Добавление от 15.08.2006 13:55:

Вот очень хорошая статья, она для w2k но и для w2k3 думаю тоже подойдет

Добавление от 15.08.2006 13:58:

Добавление от 15.08.2006 13:58:

a9-serg-64
Берете диск СД, запускаете установку, выбираете восстановление.
Где то тут на форуме я уже на этот вопрос отвечал. Недели 2 назад.
Виснет скорее всего из за ACPI. Restory mode вам ее подправит.

Я подобное проделывал еще с 2000 серврером. Все удалось запустить.
Правда от многих ошибок в эвентлоге избавиться так и не удалось.
Но проработало почти 2 года, пока не появилась возможность перенести все на новое железо и 2003 сервер.

ВладимирН
К сожалению не выходит почему-то , поиск предыдущих версий не дает результата . Просто предупреждает дальше , когда выбираешь раздел , что там есть другая система .

Note If the Setup program does not detect a previous installation but just continues to the partitioning screen, an in-place upgrade may not be possible. To detect an existing installation, the Boot.ini file must be correct, the installed registry files must be intact, and the [h]Build number[/h]must be the same. If these are not all true, Setup will not find the installation to do an in-place upgrade.

Может build number не соответствует . Диск то родной , кстати лицензионный , тока он без сервис пака . А на рабочей стоял конечно сервис пак 1 .

Попробуй как здесь написано, у меня все пракатывало, ставил с HP на IDE:

После того как будет установлена операционная система войдите в систему с учетной записью администратора. С помощью оснастки «Управление дисками» убедимся что системному разделу соответствует буква “C”.
Создайте папку C:Backup. Поместим в нее копию файла Boot.ini, папку C:WindowsRepair. Файл Boot.ini находится в корневом каталоге системного раздела. Также в папку C:Backup скопируем файл hal.dll который находится в папке C:WindowsSystem32.
Теперь выполним следующие действия, чтобы восстановить резервную копию:
a. Нажмите кнопку «Пуск», выберите пункт «Выполнить», введите команду «ntbackup» и нажмите кнопку «ОК».
b. В меню «Сервис» выберите пункт «Параметры», перейдите на вкладку «Восстановление» и выберите параметр «Всегда заменять файл на компьютере».
c. Восстановите состояние системы и системный диск из резервной копии. Состояние системы включает папку Sysvol. Убедитесь, что файлы восстанавливаются в исходное размещение.

После завершения операции восстановления перед перезагрузкой компьютера выполните следующие действия:
a. Замените файл Boot.ini, папку C:WindowsRepair., файл Hal.dll на копии, которые были созданы ранее.

Далее выполните следующие действия для принудительного восстановления службы репликации файлов (FRS).
a. В меню Пуск выберите пункт Выполнить, введите команду regedit и нажмите клавишу ВВОД.
b. Найдите следующий раздел реестра:
HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNtFrsParametersReplica Sets
c. Разверните раздел Replica Sets, найдите подраздел, соответствующий набору репликации DOMAIN SYSTEM VOLUME (SYSVOL SHARE).
d. Затем найдите в подразделе Cumulative Replica Sets подраздел, соответствующий имени подраздела, найденного в результате предыдущего действия.
e. Разверните подраздел Cumulative Replica Sets, щелкните подраздел, соответствующий набору репликации Sysvol, и дважды щелкните BurFlags.
f. В появившемся окне Изменение параметра DWORD в поле Значение введите число D4 и нажмите кнопку ОК.

После перезагрузки сервера и восстановления им всех драйверов перезагружаем сервер еще раз.

Добавление от 16.08.2006 16:39:

После установки и до наворота бекапа наверни сервис пак, это обязалово, а еще проверь что дистри которой ставищ был тотже что и упал

Спасибо всем за советы .

Сделал так как ты написал , все прокатило .
Так раньше делал , но вот файл hal.dll не менял . А это важно .
Указанный тобой параметр в реестре не нашел .
Поменял другой отсюда : http://support.microsoft.com/?id=263532
Единственное система и офис сразу заорали про новую активацию в связи с изменением железа .
Т.е. лучше пользоваться левым , будет меньше проблем .

Я разобрался почему не шло восстановление поверх с компакта .
Это был глюк майкрософта . У меня 2003 русская лицензионная не патченая .
Сделал инсталяцию чистую , хотел запустить репайр , так она даже сама себя не увидела
После интеграции в дистрибутив сервис пака , такая возможность появилась .
Так что спаибо микрософту за потраченный день .

Еще раз всем спасибо . Подчеркиваю , что прокатило в чистом виде то то , что посоветовал Dima_ADMin .
.

Неполномочное восстановление AD DS

Неполномочное восстановление AD DS выполняется средствами Windows Server Backup и может потребоваться в самых разных случаях . Сценарий восстановления также зависит от используемой версии операционной системы и версии гипервизора (если контроллеры домена работают в виртуальной среде). Большинство из возможных вариантов я рассмотрю в этой статье.

Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.

Читать еще:  Установка второго контроллера домена 2020 r2

Неполномочное восстановление AD DS

Выполнять неполномочное восстановление будем через бэкап System State нашего КД.

Того же эффекта можно добиться, используя бэкап критически важных томов, а также при восстановлении из полного бэкапа сервера 1 .

Немного теории

Перед началом процесса восстановления контроллера домена необходимо четко себе представлять что же произойдет после, а произойдет следующее:

  1. Система возвратится в состояние на момент снятие бэкапа (это очевидно);
  2. Будет сгенерирован новый DSA Invocation ID;
  3. Текущий пул RID будет сброшен и получен новый;
  4. Произойдет неполномочное восстановление SYSVOL.

Теперь о каждом пункте подробнее, начиная со 2.

DSA Invocation ID

Invocation ID — это уникальный guid-идентификатор базы данных ntds.dit. Сбрасывая этот параметр, контроллер домена сообщает своим «соседям» о том, что он был восстановлен из бэкапа. То есть, по сути, восстановленный КД становится другим источником репликации и ему требуются все изменения в AD, начиная с момента создания бэкапа.

Этот механизм необходим, чтобы избежать отката номеров последовательных обновлений (USN Rollback 2 ), который заключается в следующем.

AD работает таким образом, что между контроллерами домена передаются лишь последние изменения, а не вся база целиком. Каждый КД поддерживает значение USN своих соседей (up-to-dateness vector). Если другой КД вдруг сообщает свой USN и он оказывается выше «запомненного», значит на другом КД произошли изменения и их надо получить посредством репликации данных. Откат к состоянию бэкапа возвращает максимальный последовательный номер изменений восстановленного сервера к меньшему значению. В итоге все другие КД, получая с восстановленного контроллера его USN, будут уверены, что все изменения с него уже реплицированы, ведь их «запомненные» значения USN восстановленного КД будет больше. Все изменения, внесенные в AD на восстановленном КД в промежутке восстановленного USN и «запомненных» USN на других КД, никогда не будут реплицированы на другие контроллеры. Подобная ситуация приведет к рассогласованию баз данных.

RID Pool

Любой принципал безопасности (пользователь, компьютер, группа) в AD имеет уникальный идентификатор, называемый SID. SID, в свою очередь, состоит из нескольких значений, последним из которых является относительный идентификатор — RID.

Если на момент создания резервной копии у КД имеется выданный пул идентификаторов (а на деле в 99% случаев так оно и будет, за исключением ситуации, когда на момент бэкапа пул был израсходован полностью, а связи с хозяином RID для получения нового пула не было), то после восстановления из бэкапа контроллер домена начнет использовать этот пул заново и в лесу появятся принципалы безопасности с одинаковыми SID.

Чтобы такой ситуации не было, во время неполномочного восстановления пул RID сбрасывается и запрашивается новый.

Если же вы восстанавливаете весь лес AD, не забудьте повысить границу выдаваемого пула 3 и сбросить текущие пулы на контроллерах домена 4 .

Переходим к последнему пункту.

SYSVOL restore

Этот момент самый очевидный из всех рассматриваемых. По умолчанию осуществляется именно неполномочное восстановление SYSVOL, чтобы стянуть последние актуальные данные с других КД. Если же необходимо полномочное восстановление 5 , то достаточно поставить соответствующую галочку в мастере WSB или выставить флаг -sysvol, если используете командную консоль.

Когда нужно неполномочное восстановление

Неполномочное восстановление может понадобиться в нескольких ситуациях:

  1. Рабочий КД вышел из строя в связи с аппаратными/программными проблемами и нет желания разворачивать полностью свежий КД (например потому что на старом были какие-то важные приложения и данные);
  2. При откате к снимку виртуальной машины. Если:
    • КД имеет ОС старше Windows Server 2012;
    • Гипервизор не поддерживает VM-Generation ID (все до Windows Server 2012), вне зависимости от гостевой ОС.

Во всех остальных случаях используются другие сценарии восстановления.

Подготовка

К моменту восстановления у вас должны быть:

  1. Резервная копия (я подключил к виртуализованному КД отдельный диск, на который ранее был скопирован бэкап состояния системы);
  2. Пароль DSRM. Придется загружаться в режиме восстановления AD, сервисы будут остановлены, а потому зайти под доменной учеткой не получится, только под локальным админом.

«Операции восстановления, которые выполняются с помощью следующей процедуры, не поддерживаются Майкрософт и должны использоваться только в крайнем случае при отсутствии других вариантов».

Переходим к кульминации.

Восстановление

Хочу отметить, что мой сервер перед операцией восстановления полностью доступен. Если же у вас более сложный случай, то возможно вам понадобится установочный диск операционной системы. В любом случае сценарий восстановления будет отличаться.

Есть несколько способов загрузить сервер в режиме восстановления служб каталогов и я воспользуюсь самым простым из них — нажатие F8 во время загрузки.

bcdedit /set safeboot dsrepair
shutdown -t 0 -r
После выполнения восстановления выполните команду bcdedit /deletevalue safeboot для загрузки в нормальном режиме.
Третий способ — использовать всем знакомую утилиту Msconfig (Загрузка -> Параметры загрузки -> Безопасный режим -> Восстановление Active Directory).
После восстановления также не забудьте вернуть сервер в нормальный режим загрузки.

Итак, нажав F8 дожидаемся загрузки сервера и входим под учетной записью локального администратора:

Вводим пароль DSRM, дожидаемся пока система загрузится.

Не забудьте выбрать Восстановление системы:

После этого увидите предупреждение:

Подтверждаем, далее нажимаем Восстановить и снова соглашаемся с всплывшим предупреждением. Дожидаемся окончания процесса восстановления и перезагружаемся.

Active Directory: копирование и восстановление

Одним из важных аспектов использования Active Directory является восстановление в случае отказа. Для защиты от отказа стоит всегда иметь надежную резервную копию Состояния системы (System State). Резервное копирование состояния системы позволяет обеспечить сохранение файлов, критических для функционирования системы.

В число этих файлов входят Active Directory, системный реестр и содержимое папки SYSVOL, которая содержит регистрационные сценарии и шаблоны групповых политик. При отказе контроллера домена лучшим способом восстановления является вообще отказ от восстановления.

Всегда, если позволяет пропускная способность сетевого подключения и в домене присутствует второй контроллер домена, старайтесь переустановить операционную систему Windows (или восстановите ее из резервной копии ASR) и повторно запустите утилиту DCPromo для повышения сервера до контроллера домена. При этом будет получена чистая система.

Так как резервная копия Active Directory может создаваться только в составе Состояния системы, при восстановлении Active Directory необходимо восстановить и состояние системы. Если сервер полностью отказал, то восстановление системы на другом аппаратном обеспечении может привести к проблемам.

Если после восстановления возникают проблемы, проведите исправление операционной системы для устранения всех ошибок конфигурации.

Таким образом, если все остальные попытки исправления проблемы завершились неудачно и в наличии есть действительная резервная копия состояния системы, и необходимо восстанавливать базу данных Active Directory, можно воспользоваться одним из трех типов восстановления.

  • Основной (Primary) — выберите этот вариант, если восстанавливается первый контроллер домена и в домене больше не включено ни одного контроллера домена. При выборе этого варианта восстановление остальных контроллеров домена должно быть неавторитетным (Nonauthoritative).
  • Авторитетный (Authritative) — используется только тогда, когда базу данных Active Directory необходимо привести в состояние, в котором она находилась в момент создания резервной копии. Такое восстановление должно выполняться только при возникновении серьезных ошибок, например, удаление подразделения, или при необходимости выполнить откат всех предыдущих действий. Этот вариант восстановления требует запуска команды ntdsutil после восстановления для выбора объектов, авторитетных для репликации.
  • Неавторитетный (Nonauthoritative) — этот вариант восстановления используется в 99% случаев восстановления базы данных Active Directory. Этот вариант приводит к восстановлению данных, после чего контроллер домена получает обновления от других контроллеров домена в пределах леса (что позволяет восстановить синхронизацию).

При запуске восстановления Active Directory вариант восстановления выбирается в диалоговом окне Дополнительные параметры восстановления (Advanced Restore Options) в приложени Backup. Еще раз подчеркиваю, восстановление должно рассматриваться только как последняя возможность.

Если контроллер домена является единственным сервером DNS и в службе DNS используются зоны, интегрированные в Active Directory, данные зоны DNS окажутся недоступными при загрузке контроллера домена в режиме восстановления службы каталогов.

Если состояние системы восстанавливается по сети с помощью утилиты резервного копирования от третьей фирмы, может потребоваться внесение соответствующих записей в файл Hosts (это позволит предоставить преобразование имен для всех компьютеров, принимающих участие в процессе восстановления).

Ссылка на основную публикацию
Adblock
detector