Восстановление active. Восстановление рабочего стола Active Desktop в Windows XP

Любой пользователь операционной системы Windows XP может рано или поздно столкнуться с тем, изображение на рабочем столе сменится сообщением о сбое Active Desctop. Вообще это очень интересная функция, которая позволяет размещать на рабочем столе сводки новостей, например, котировки валют, то есть различные динамичные элементы. Но вот только пользуются этим единицы, а глючит весьма и весьма часто. Да ещё и вирусы её «любят».

Попытка нажать на кнопку «восстановить рабочий стол active desktop» при этом зачастую либо ничего не выдает, либо выкидывает вот такую ошибку:

Для решения такой проблемы первым делом проверьте системный диск C:\ несколькими антивирусными программами и перезагрузитесь. Только после этого можно уже идти дальше.

Как восстановить рабочий стол?!

Для восстановления Active Desctop есть несколько путей. Самый правильный путь — с помощью исправления в реестре Windows. Для этого запускаем Редактор реестра. Сделать это можно нажав кнопку «Пуск» и выбрав пункт меню «Выполнить»:

В строке «Открыть» пишем команду и нажимаем кнопку ОК. Откроется редактор реестра Windows. В нем надо найти ветку

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Desktop\Components

Сделать это можно двумя путями. Первый — просто по очереди открывая ветки в соответствии с указанным выше порядком. Второй — через поиск по F3 введя как критерий поиска слово «Components». Там нас интересует параметр DeskHtmlVersion :

Кликаем по нему дважды чтобы изменить. Меняем значение этого параметра на ноль — 0 и нажимаем на кнопку «ОК». Закрываем редактор реестра, перезагружаемся и проверяем — ошибка восстановления рабочего стола должна устранится.

Если Вы панически боитесь лезть в параметры реестра Windows XP, боясь там чего-либо напортачить (что тоже не лишено смысла), то можно сделать «ход конём». Вам надо создать нового локального пользователя Windows через Панель Управления и зайти в систему под ним. Старого пользователя можно удалить. Большой минус такого способа заключается в том, что Вы потеряете все настройки старой учетной записи.
Но убрать ошибку active desktop и восстановить рабочий стол Windows XP это поможет.

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

Бэкап делается утилитой ntbackup (для Windows 2000/2003), или утилитой архивации в Windows 2008/2008 R2. Для восстановления нужно чтобы при архивации была обязательно отмечена опция System State (состояние системы).

Ели архивация делалась сторонними утилитами — нужно обратиться к справке этих утилит для восстановления.

Выполнение обычного (невторитарного) восстановления Active Directory

С помощью этого восстановления восстанавливается все объекты на момент резервного копирования AD.

1. Перезагрузите компьютер по клавише F8 в режиме Directory Restore Mode.
2. Запустите утилиту NTDSUtil. В приглашении ntdsutil введите команду files и нажмите Enter.
3. В приглашении file maintenance выполните команду Header и прочитайте информацию о последних созданных резервных копиях. Информация о проведенном ваме резервном копировании должна содержаться в абзаце Previous Full Backup.
4. Два раза выполните команду Quit, чтобы выйти из утилиты NTDSUtil.
5. Запустите утилиту ntbackup. Перейдите по ссылке Advanced Mode и в окне Backup Utility перейдите на вкладку Restore and Manage Media.
6. На вкладке Restore and Manage Media раскройте узел созданной вами резервной копии и установите флажок напротив строки System State, а затем нажмите на кнопку Start Restore. Нажмите OK в окне предупреждения. В окне Confirm Restore нажмите на кнопку Advanced и просмотрите возможности в окне Advanced Restore Options. Закройте окно Advanced Restore Options и в окне Confirm Restore нажмите на кнопку OK.
7. После окончания процесса резервного копирования произведите перезагрузку компьютера в обычном режиме.

Восстановление, при котором можно восстановить отдельно удаленные объекты Active Directory

1. Перезагрузите контроллер домена по клавише F8 в режиме Directory Restore Mode и произведите полное восстановление контроллера домена аналогично предидущему случаю, но по окончании восстановления не производите перезагрузку.

2. Запустите утилиту NTDSUtil и в приглашении ntdsutil введите authoritative restore. Нажмите Enter.

3. В приглашении authoritative restore введите вопросительный знак и нажмите Enter. Прочитайте список доступных команд этого режима.

4. В приглашении authoritative restore введите команду restore subtree

OU=User_OU,DC=Domain,DC=local

OU = User_OU , DC = Domain , DC = local

5. Нажмите Yes в окне подтверждения.

OU=User_OU Имя востанавливаемого контенера:

DC=Domain Имя вашего домена

DC=local имя домена.

6. Дважды выполните команду quit, чтобы выйти из NTDSUtil, а затем перезагрзуите компьютер в нормальном режиме.

7. Проведите принудительную репликацию с другими контроллерами домена и убедитесь, что организационное подразделение User_OU со всеми вложенными объектами восстановлено на обоих контроллерах домена.

Нет похожих постов...

• базу данных Active Directory и журналы транзакций;
• системные файлы и файлы запуска, находящиеся под защитой Windows;
• системный реестр контроллера домена;
• всю зонную информацию DNS, интегрированную с Active Directory;
• папку Sysvol;
• базу данных регистрации классов СОМ+;
• базу данных службы сертификатов (если контроллер домена является также сервером службы сертификатов);
• информацию кластерной службы;
• метакаталоги информационной Интернет-службы Microsoft (IIS) (если служба IIS установлена на компьютере).

Все эти компоненты должны копироваться и восстанавливаться целиком из-за их тесной интеграции. Например, если на сервере службы сертификатов был создан сертификат, который был назначен на объект Active Directory , то база данных службы сертификатов (содержащая запись о создании объекта) и объект Active Directory (содержащий запись о том, что сертификат назначен на объект ) должны быть сохранены.

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

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

Другая проблема, которую нужно рассмотреть в связи с резервным копированием контроллера домена - это частота создания резервной копии. Служба Active Directory предполагает, что давность резервной копии не может превышать время жизни объектов-памятников. По умолчанию время жизни объекта-памятника составляет 60 дней. Причина этого ограничения связана с тем способом, которым Active Directory использует объекты-памятники. Когда объект удален, он фактически не удаляется из каталога до тех пор, пока не истечет время жизни объекта-памятника. Вместо этого объект маркируется как объект -памятник, и большинство его атрибутов удаляются. Затем объект -памятник копируется на все другие контроллеры домена. По истечении времени жизни объекта-памятника он наконец удаляется из каталога на каждом контроллере домена. Если восстановить контроллер домена из резервной копии, давность которой превышает время жизни объекта-памятника, то в каталоге можно обнаружить информацию, несогласованную между контроллерами домена. Допустим, что пользователь был удален из каталога через день после создания резервной копии, а соответствующий объект -памятник оставался в каталоге 60 дней. Если бы резервная копия была восстановлена на контроллере домена более чем через 60 дней, после того как объект стал объектом-памятником, то на восстановленном контроллере домена был бы этот пользовательский объект , и поскольку объект -памятник более не существует, то контроллер домена не стал бы его удалять. В таком сценарии восстановленный контроллер домена имел бы копию объекта, который не существует ни в каком другом каталоге. По этой причине система резервирования и программа восстановления предотвращают попытки восстановления каталога из резервной копии, хранящейся дольше, чем период удаления объектов-памятников.

Хотя время жизни объектов-памятников накладывает жесткое ограничение на частоту резервного копирования, очевидно, что создавать резервные копии контроллеров домена лучше гораздо чаще, чем каждые 60 дней. Возникнет много проблем, если восстанавливать контроллер домена из резервной копии, более давней, чем пара дней. Поскольку восстановление Active Directory включает восстановление всей информации о состоянии системы, эта информация будет восстановлена до предыдущего состояния. Если сервер является также сервером службы сертификатов, то все удостоверения, выпущенные до того, как была создана резервная копия, не будут включены в базу данных службы сертификатов. Если были обновлены драйверы или установлены какие-либо новые приложения, они не смогут работать, потому что будет сделан откат системного реестра к предыдущему состоянию. Почти все компании поддерживают такой режим резервного копирования, в котором некоторые серверы копируются каждую ночь. Контроллеры домена должны включаться в такой режим резервирования.

Процесс восстановления

Существуют две причины, из-за которых, возможно, придется восстанавливать Active Directory [ 13 ] .

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

Если планируется восстанавливать Active Directory , потому что базу данных на одном из контроллеров домена больше нельзя использовать, то имеются следующие два варианта процесса [ 13 ] .

• Первый вариант состоит в том, чтобы вообще не восстанавливать Active Directory на отказавшем сервере, а создать еще один контроллер домена , назначив другой сервер, на котором выполняется система Windows Server 2003, контроллером домена. Таким способом будут восстановлены функциональные возможности контроллера домена, а не служба Active Directory на определенном контроллере домена.
• Второй вариант состоит в восстановлении отказавшего сервера и последующем восстановлении базы данных Active Directory на этом сервере. В этом случае будет выполнено восстановление при отсутствии полномочий (non- authoritative ). При таком восстановлении база данных Active Directory восстанавливается на контроллере домена, а затем все изменения, сделанные к Active Directory после создания резервной копии, реплицируются на восстановленный контроллер домена .

Если планируется восстанавливать Active Directory , потому что кто-то удалил большое количество объектов из каталога, то необходимо восстановить базу данных Active Directory на одном из контроллеров домена, используя резервную копию, которая содержит удаленные объекты. Затем требуется сделать восстановление при наличии полномочий ( authoritative ), в процессе которого все восстановленные данные отмечаются так, чтобы они реплицировались на все другие контроллеры домена, перезаписывая удаленную информацию.

Для восстановления Active Directory необходимо архивировать данные состояния службы [ 4 ] , [ 6 ] : реестр, базу данных регистрации СОМ+, системные загрузочные файлы и базу данных служб сертификации (если это сервер служб сертификации). При перезагрузке компьютера в режиме восстановления служб каталогов необходимо войти в систему с администраторскими правами, используя правильные имя и пароль учетной записи Security Accounts Manager . При этом нельзя использовать учетную запись администратора Active Directory , так как службы Active Directory отключены и нельзя их средствами проверить подлинность учетной записи. Для этого применяется база данных учетных записей

Active Directory в Windows Server 2008. Контроллеров домена должно быть несколько, это золотое правило, которому необходимо следовать во всех средних и крупных организациях. Принцип восстановления при наличии нескольких контроллеров существенно меняется. Давайте попробуем понять почему. Представим, что вы имеете два контроллера домена с именами DC1 и DC2 (это контроллеры одного домена). Оба будут иметь идентичную базу данных Active Directory, и если вы измените ее на одном, она автоматически обновится на другом, это процесс репликации.

Теперь определимся с расписанием резервного копирования:

Воскресенье - полная резервная копия системного раздела (описана в первой части статьи)

Понедельник - Суббота - создание состояния системы systemstate (описано в первой части статьи)

Все было отлично, но в четверг из-за неполадок перестал работать контроллер домена DC1. У вас есть несколько путей для восстановления контроллера, рассмотрим их.

• Путь первый : восстановить состояние системы (systemstate), которое было сделано в среду. Для этого вам понадобится запустить контроллер в режиме DSRM (Режим восстановления службы каталогов) и используя программу Windows Server Backup восстановить состояние. Но для этого контроллер должен загрузиться в DSRM, такой возможности может и не быть.
• Путь второй: если загрузить контроллер в DSRM не получается, процедура восстановления начинается с запуска восстановления системного раздела, архив которого был создан в воскресенье. После того как вы восстанавливаете DC1 из этого архива ваш компьютер идет в нормальную загрузку.

И вот здесь что при первом варианте, что при втором появляется два контроллера, у которых не синхронизованы базы Active Directory. DC1 имеет версию базы на день резервной копии, а DC2 текущую, самую новую версию.

Какая из версий будет иметь приоритет?

Если вы будете проводить восстановление способом, описанным мной в первой части статьи, то приоритет будет иметь тот контроллер, который оставался работать, в нашей ситуации это DC2. Все что находится в Active Directory на DC1 после восстановления, будет обновлено до состояния DC2. Этот способ называется не принудительное восстановление.

А может ну его этот Windows Server Backup?

Недавно столкнулся с позицией сотрудника Microsoft, который на вопрос как восстановить контроллер домена ответил «А зачем?». Вначале я немного задумался, не шутит ли он, но потом его доводы мне стали понятны. Идея выглядит следующим образом. В организациях среднего размера, как правило, 3-4-5 и больше контроллеров домена и шанс потерять их разом близок к 0. Чтобы избежать и этого шанса мы осуществляем резервное копирование только 2-х. При этом резервное копирование происходит того или тех контроллеров которые владеют ролями FSMO и представляют особенную ценность. Все остальные просто живут своей жизнью и если какой-то выходит из строя мы просто ставим новую ОС и поднимаем новый контроллер домена, следует заметить что по времени это будут равнозначные процедуры.

Может возникнуть желание вообще перестать делать копии, авось все не потеряем, а роли FSMO можно и захватить при желании. Желание совершенно вредное и вот почему. Потеря объектов Active Directory это не только случайное удаление пользователя, вы можете случайно стереть скриптом организационное подразделение со всем содержимым и просто так вернуть из контейнера удаленных объектов, все в первоначальном виде у вас не получится. А изменения уже прореплицировались. И каждый контроллер знает об удалении. В этой ситуации вам и понадобится резервная копия.

Следуйте правилу - «Лишних резервных копий не бывает»

Приоритет при репликации

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

В Windows Server 2003 мы могли выполнить принудительное восстановление тремя способами:

Принудительное восстановление всей базы данных.

Делалась эта процедура с помощью утилиты ntdsutil. В Windows Server 2008 утилита ntdsutil осталась, но теперь мы не можем принудительно восстановить всю базу данных.

Только:

Принудительно восстановление организационного подразделения с содержимым

Принудительное восстановление отдельного объекта

Поэтому мы всегда должны знать, какие объекты были удалены. Естественно, держать такую информацию в голове вы не сможете. Для этого в Windows 2008 было создано средство «Active Directory database mounting tool»

Active Directory database mounting tool создана для улучшения, а конкретно упрощения процесса восстановления службы каталогов. В Windows 2003, если мы имели множество архивов и не знали, какой именно содержит информацию нужную для восстановления, приходилось играть в рулетку, восстанавливая тот или иной архив и проверяя его содержимое.

В Windows 2008 ситуация меняется. Используя Database Mounting Tool мы можем просматривать содержимое базы на тот или иной процесс времени.

К сожалению, мы не можем просматривать содержимое AD на любой интересующий период времени, а лишь в те моменты, когда был создан Snapshot. Скажу сразу Snapshot не является тем Snapshot-ом к которому мы привыкли, используя VmWare. Он содержит информация о наличии объектов в базе, но никоим образом не участвует в восстановлении этих объектов.

Из вышесказанного можно сделать вывод:

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

ntdsutil.exe "activate instance NTDS" snapshot create quit quit

Готовый пакетный файл можно скачать «здесь». Обязательно убедитесь в том, что Snapshot успевает закончиться до начала резервного копирования.

Рис. 1. Создание снимка Active Directory

Процесс принудительного восстановления контроллера домена с использованием состояния системы. (systemstate)

Предыстория такова, одним из администраторов было удалено организационное подразделение «BetaTesters», в котором содержалась учетная запись или записи. Точно этого мы не знаем. Информация об удалении успела реплицироваться на все контроллеры домена. У нас есть несколько архивов с Systemstate за предыдущие дни. Когда точно было удалено организационное подразделение, мы не знаем.

Для начала, нам необходимо выбрать какое состояние системы мы будем восстанавливать. Дату удаления мы не знаем. Для этого будем использовать Snapshot-ы, которые создаются у нас незадолго до резервной копии. Запустив утилиту ntdsutil, смотрим список снимков нашей AD.



Рис. 2. Просмотр доступных снимков Active Directory

Для этого в командной строке набираем ntdsutil -> snapshot -> Activate Instance NTDS -> list all . В результате мы получим список созданных снимков Active Directory. Первый снимок создан 13 апреля. С него я и начну.

Там же монтирую командой mount c подставленным идентификатором первый снимок Active Directory. Пример на рисунке 3. После этой операции у вас появится на диске C: ссылочный объект, называющийся $SNAP_дата. Зайдя в него, вы увидите структура вашего системного диска на момент создания копии.

Рис. 3. Монтирование снимка Active Director

Снимок смонтирован. Открываю второе окошко командной строки и запускаю утилиту dsamain. Выполняем хитрую команду, которая позволяет подключить моментальный снимок в качестве LDAP-сервера. В команде укажите путь к файлу ntds.dit в смонтированном снимке и порт LDAP-сервера (я рекомендую 50001)

Рис. 4. Использование dsamain.

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



Рис. 5. Сменить контроллер домена.

В появившемся меню указываем подключение к «Имя Сервера:указанный порт в dsamain », в моей ситуации это «DC:50001 »

Рис. 6. Выбор LDAP сервера

Нажав «ОК» мы попадаем в оснастку «Active Directory пользователи и компьютеры», которая содержит данные для чтения по состоянию на момент создания снимка Active Directory. Я нахожу организационное подразделение «BetaTesters» и в нем есть пользователь «Rud Ilya». Вывод можно сделать такой: поскольку снимок был создан 13 апреля и содержит в себе удаленное подразделении, нам необходимо восстанавливать состояние системы на 13 апреля.



Рис. 7. Просмотр информации снимка AD.

Перед тем как перезагрузиться в режим восстановления службы каталогов не забудьте размонтировать снимок. Делается это командой unmount с идентификатором снимка.

Рис. 8. Размонтирование снимка

Теперь мы готовы перезагрузить один из контроллеров домена в режим восстановления службы каталогов. Как это сделать я писал в первой части статьи. Обратите внимание, что при загрузке в DSRM вы должны использовать DSRM администратора, а не доменного.



Рис. 9. Вход в DSRM. Указываем Имя_Компьютера\Администратор



Рис. 10. Список состояний системы (SystemStates)

Нам нужно восстановить состояние системы на 13 апреля, поэтому следующая команда будет: wbadmin start systemstaterecovery -version:время_создания_архива

Рис. 12. Процесс восстановления состояния системы.

Каждый объект Active Directory имеет номер версии и если на двух контроллерах у одного объекта разные номера версии, то правильным (более новым) считается тот объект, у которого версия больше. После окончания процесса восстановления необходимо запустить утилиту ntdsutil и поднять номер версии для удаленной ветки Active Directory. Т.е для нашего контейнера.

Делается это следующим образом: ntdsutil -> Activate Instance NTDS -> Authoritative restore -> restore subtree “ И указать, что должно быть восстановлено принудительно”. Пример на рисунке 13.

Рис. 13. Выбор того, что будет восстанавливаться принудительно.

Итог: Мы принудительно восстановили организационное подразделение со всем содержимым, используя состояние системы и моментальные снимки Active Directory. В Windows Server 2008 мы можем принудительно восстанавливать либо организационные подразделения со всем содержимым, либо конкретные объекты. Команда «restore database» из ntdsutil была убрана, соответственно принудительно восстановить всю базу данных Active Directory у нас не получится.

Если вы восстанавливаете архив системного диска контроллера домена и хотите добиться принудительного восстановления какой-то части AD, то сразу после восстановления, не давая контроллеру загрузиться в нормальном режиме, входим в режим восстановления службы каталогов. И используя ntdsutil, указываем, какая часть AD должна восстановиться принудительно.

Материал предоставлен ресурсом

Одним из важных аспектов использования 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 (это позволит предоставить преобразование имен для всех компьютеров, принимающих участие в процессе восстановления).