В этой статье я постараюсь рассказать о новой функции в Windows Server 2008 R2 дающей новые возможности по восстановлению удаленных объектов Active Directory.
Active Directory Recycle Bin (ADRB) – “корзина AD” – позволяет минимизировать простой вашей службы каталогов за счет расширенных возможностей по сохранению и восстановлению случайно удаленных объектов Active Directory без необходимости прибегать к восстановлению из бекапа и перезагрузки контроллеров домена.
После включения функции ADRB все атрибуты удаленных объектов начинают сохраняться, что позволяет после восстановления получить объект в том же состоянии, в каком он был непосредственно перед удалением. Например, при восстановлении пользователя он автоматически получает членство в группах, в которых он был и соответствующие полномочия, которыми обладал в момент удаления в домене.
ADRB функционирует как в среде Active Directory Domain Services (AD DS) так и в Active Directory Lightweight Directory Services (AD LDS).
ВАЖНО
- По умолчанию функция ADRB в Windows Server 2008 R2 не включена. Прежде чем включить эту функцию, вам необходимо будет поднять функциональный уровень леса до уровня windows Server 2008 R2, что в свою очередь требует иметь Windows Server 2008 R2 на всех контроллерах домена в лесу или на всех серверах содержащих AD LDS.
- В этой версии Windows Server 2008 R2 процесс включения функции ADRB необратим. После включения этой функции вы уже не сможете ее отключить.
Сценарии восстановления удаленных объектов AD
Windows Server 2008 R2 предлагает два подхода к управлению удаленными объектами AD. Вы можете выбирать, работать, не включая функциею ADRB или включить ее.
Если функция ADRB не включена, то система Windows Server 2008 R2 функционирует при удалении объектов AD так же, как и предыдущие системы Windows Server 2003/2008. При удалении объект не удаляется физически из AD, а лишь помечается как удаленный – “tombstone”. У объекта удаляется большинство атрибутов, кроме жестко привязанных, часть изменяются и дописываются новые. Если не запрещено объект перемещается в скрытый контейнер CN=Deleted Objects.
Восстановить такой объект возможно из бекапа AD, применив режим authoritative restore, что бы объект был реплицирован на остальные контроллеры домена. Минус такого восстановления в том, что необходимо перегружать контроллер домена в режиме Directory Services Restore Mode (DSRM). В этом режиме он не может обслуживать пользователей. Так же при таком методе будут потеряны все изменения сделанные после бекапа.
Так же такой объект можно реанимировать из состояния “tombstone”. Этот метод восстановления позволяет избежать простоя контроллера домена из-за перезагрузки в режиме DSRM. Но и этот метод имеет свои минусы, удаленные атрибуты придется восстанавливать, а так же членство в группах.
Более подробно о методах восстановления объектов, читайте в моей прошлой статье Восстановление удаленных элементов в Active Directory.
Вот схема жизненного цикла объекта AD в Windows Server 2003/2008 и Windows Server 2008 R2 с не включенной функцией ADRB.
Если функция ADRB включена, то в системе Windows Server 2008 R2 удаление объекта AD происходит по-другому, чем описано выше. Вот схема жизненного цикла объекта AD в Windows Server 2008 R2 с включенной функцией ADRB.
Давайте рассмотрим подробнее что изменилось.
Удаленный объект
После включения функции ADRB, когда происходит удаление объекта AD, система сохраняет все атрибуты этого объекта и помечает этот объект как “логически удаленный”, это новый статус объекта в Windows Server 2008 R2. Удаленный объект перемещается в контейнер CN=Deleted Objects, где находится в состоянии “логически удаленный” в течение времени жизни удаленного объекта (deleted object lifetime).
Вы можете восстановить удаленный объект используя процесс восстановления “логически удаленных” объектов в течение времени жизни удаленного объекта (deleted object lifetime). В этот же период времени вы можете восстановить этот объект из бекапа используя режим authoritative restore.
Переработанный объект (Recycled)
После истечения времени жизни удаленного объекта (deleted object lifetime) “логически удаленный” объект становится “переработанным объектом” и большинство его атрибутов удаляются. “Переработанный объект” это новый статус объекта в Windows Server 2008 R2. Эти объекты остаются в контейнере CN=Deleted Objects в течение времени жизни переработанного объекта (recycled object lifetime). По окончании этого времени процесс garbage collection удаляет их физически из AD.
ВАЖНО
“Переработанный объект” не может быть восстановлен с использованием процесса восстановления “логически удаленных” объектов или реанимирован как объект “tombstone”. Это новый режим работы Windows Server 2008 R2.
Не пытайтесь восстанавливать “переработанный объект” с помощью бекапа, используя режим authoritative restore. Вместо этого Microsoft рекомендует восстанавливать “логически удаленный” объект в течение времени его жизни.
ВАЖНО.
После включения функции ADRB, все объекты которые были удалены и находились в состоянии “tombstone” переходят в состояние “переработанный объект”. Эти объекты больше не отображаются в контейнере CN=Deleted Objects и не подлежат восстановлению через ADRB. Восстановить эти объекты возможно только до включения функции ADRB с помощью бекапа, используя режим authoritative restore.
Время жизни удаленных и переработанных объектов
Время жизни удаленного объекта определяется значением атрибута msDS-deletedObjectLifetime, а время жизни переработанного объекта, значением атрибута tombstoneLifetime. По умолчанию значение атрибута msDS-deletedObjectLifetime равно нулю. Когда значение атрибута msDS-deletedObjectLifetime равно нулю, это говорит о том, что время жизни удаленного объекта равно времени жизни переработанного объекта. По умолчанию, время жизни переработанного объекта равно значению атрибута tombstoneLifetime, которое равно нулю. В Windows Server 2008 R2, когда значение атрибута tombstoneLifetime равно нулю, то время жизни переработанного объекта равно 180 дней. Итого в днях по умолчанию оба время жизни удаленного объекта равно 180 дней, затем он становится переработанным объектом на 180 дней и затем удаляется окончательно.
Вы можете изменять значения атрибутов msDS-deletedObjectLifetime и tombstoneLifetime в любое время. Если вы измените, значение по умолчанию атрибута msDS-deletedObjectLifetime, оно больше не будет коррелировать со значением атрибута tombstoneLifetime. О том как изменять значения этих атрибутов напишу чуть позже.
Восстановление объектов Active Directory из бекапа используя authoritative restore
Чтобы определить, можете ли вы использовать определенный бекап AD DS, чтобы успешно восстановить ранее удаленный объект через authoritative restore, Microsoft предлагает проверить значение времени жизни результирующего бекапа в вашем лесу Active Directory. Значением времени жизни результирующего бекапа в вашем лесу Active Directory, является количество дней в течение которых любой бекап в этом лесу Active Directory эффективен для восстановления среды Active Directory. (Задачи восстановления могут включать восстановление случайно удаленных данных или активацию контроллеров домена с носителей.)
Microsoft предполагает, что значением времени жизни результирующего бекапа является наименьший параметр двух атрибутов msDS-deletedObjectLifetime и tombstoneLifetime. Исходя из выше сказанного значение времени жизни результирующего бекапа по умолчанию равно 180 дням.
ВАЖНО
Microsoft рекомендует, чтобы значение времени жизни результирующего бекапа в вашей среде Active Directory было равно или больше чем 180 дней, чтобы гарантировать, что вы сможете использовать имеющиеся бекапы для authoritative restore в течении длительного времени.
Хотя Microsoft и позволяет изменять значения атрибутов msDS-deletedObjectLifetime и tombstoneLifetime, однако не рекомендует этого делать.
Если значение атрибута msDS-deletedObjectLifetime меньше значения атрибута tombstoneLifetime, то восстановление объектов с использованием authoritative restore возможно только в период действия атрибута msDS-deletedObjectLifetime .
Попытки восстановить переработанный объект с помощью authoritative restore не увенчаются успехом, т.к. после репликации восстановленный объект опять станет переработанным. Это правило так же работает если вы вручную перевели статус удаленного объекта в переработанный объект.
Восстановление объектов Group Policy (GP) или Exchange объектов
Вы можете использовать ADRB для восстановления всех удаленных объектов которые до этого хранились в AD DS. Однако если вы используете ADRB, чтобы восстановить объекты GP или Exchange объекты, вы восстановите только ту информацию, которая была в AD DS, а не полностью сами объекты.
Для создания и восстановления архивных копий объектов GP рекомендуется использовать оснастку Group Policy Management, а затем вручную создать связи с необходимыми сайтами, доменами или OU в AD DS. О том как это делается я напишу чуть позже.
Microsoft не рекомендует использовать ADRB для восстановления объектов Exchange, которые были удалены с помощью Exchange administrative tools. Вместо восстановления Microsoft рекомендует пересоздать такие объекты с помощью тех же инструментов Exchange administrative tools. Если же удаление произошло без применения инструментов Exchange administrative tools, то вы должны восстановить такие объекты через ADRB как можно быстрее. Однако, любые изменения конфигурации, которые произошли в среде между удалением этого объекта и его восстановлением, не будут восстановлены и могут привести к проблемам с Exchange.
Например, если вы используете ADRB, чтобы восстанавливать случайно удаленных получателей Exchange, таких как контакты, пользователи или группы рассылки, убедитесь, что повторно применили текущую политику Exchange или другие данные конфигурации к ним. Эти данные, возможно, были изменены с момента удаления объектов.
Требования для ADRB
Для того чтобы вы могли включить ADRB ваша среда должна соответствовать определенным требованиям.
Выполните следующие шаги перед включением функции ADRB в среде AD DS:
Запустите adprep для обновления вашей схемы AD необходимыми ADRB атрибутами. Вы должны как минимум обладать правами Schema Admin для совершения данной операции.
Важно
Если вы изначально устанавливаете лес AD на основе Window Server 2008 R2 вам не нужно выполнять adprep, ваша схема AD уже содержит необходимые атрибуты для нормального функционирования ADRB.
Если же вы устанавливаете новый контроллер Windows Server 2008 R2 в существующий лес Windows Server 2003 или Windows Server 2008 и затем оставшиеся сервера будете апгрейдить до Windows Server 2008 R2 вы должны запускать adprep, чтобы обновить схему AD необходимыми атрибутами необходимыми для работы ADRB.
- Подготовить лес запустив adprep /forestprep на сервере держателе роли operation master
- Подготовить домен запустив adprep /domainprep /gpprep на сервере держателе роли operation master
- Если у вас в среде AD DS существует контроллер домена для чтения (RODC) вы должны так же запустить adprep /rodcprep
- Убедитесь, что все контроллеры домена в лесу AD работают на Windows Server 2008 R2
- Поднимите функциональный уровень леса AD до Windows Server 2008 R2.
В следующей части статьи я расскажу о том, как включить систему ADRB в вашей среде AD.
Active Directory Recycle Bin – новые возможности восстановления объектов AD (часть 2)
В продолжение начатой статьи я постараюсь рассказать о функции в Windows Server 2008 R2 дающей новые возможности по восстановлению удаленных объектов Active Directory. А именно как включить функцию ADRB в вашей среде AD. В первой части статьи я рассказывал о том, что такое ADRB и как она работает.
Active Directory Recycle Bin (ADRB) – “корзина AD” – позволяет минимизировать простой вашей службы каталогов за счет расширенных возможностей по сохранению и восстановлению случайно удаленных объектов Active Directory без необходимости прибегать к восстановлению из бекапа и перезагрузки контроллеров домена.
И так, после того как мы подготовили лес и домены с помощью команды adprep, как это было описано в первой части статьи, мы можем перейти к следующим шагам.
Для работы функции ADRB необходимо сделать два основных шага:
- Поднять функциональный уровень леса до Windows Server 2008 R2
- Включить функцию ADRB
Поднятие уровня леса до Windows Server 2008 R2
Вы можете поднять функциональный уровень леса следующими способами:
- Используя команду Set-ADForestMode в Active Directory Module for Windows PowerShell
- Используя утилиту LDP.exe
- Используя консоль Active Directory Domains and Trusts
ВАЖНО
Обратите внимание, что нам надо поднять функциональный уровень леса, а не только домена. Поэтому использовать всем известную функцию Raise Domain Function Level в консоли Active Directory Users and Computers, будет недостаточно.
Вам потребуются права Enterprise Admin для выполнения данных процедур.
Вариант 1. С помощью Active Directory Module for Windows PowerShell
Заходим на контроллер домена с правами Enterprise Admin или запускаем Active Directory Module for Windows PowerShell через runas.
Start, Administrative Tools, правой кнопкой мыши Active Directory Module for Windows PowerShell, и выберите Run as administrator. Введите домен, логин и пароль пользователя с соответствующими правами.
В открывшемся окне PowerShell наберите следующее:
Set-ADForestMode -Identity <ADForest> -ForestMode <ADForestMode> , где <ADForest> имя корневого домена леса, а <ADForestMode> имя функционального уровня леса, нам надо набрать Windows2008R2Forest.
Вот, как эта команда выглядела у меня для домена one.local
Далее система попросит у вас подтверждение выполнения данной операции. Решайте, что вы будете делать, я согласился. Вот что у меня получилось в итоге, тоже должно получиться и у вас, если вы хотите установить ADRB.
Для получения дополнительной информации по команде Set-ADForestMode наберите Get-Help Set-ADForestMode.
Теперь давайте проверим функциональный уровень леса, сделать это мы можем командой Get-ADForest , вот что получилось у меня.
Обратите внимание на параметр ForestMode, он изменился так как нужно.
Вариант 2. С помощью утилиты LDP.exe
Вот еще один вариант, как можно изменить функциональный уровень леса с помощью утилиты LDP.exe.
Заходим на контроллер домена с правами Enterprise Admin и запускаем LDP.exe – Start, Run и набираем ldp.exe
В открывшемся окне выбираем Connection, Connect
Нажимаем ОК, подключаясь к текущему контроллеру
При подключении вы должны увидеть нечто подобное у себя.
Затем выполняем Connection, Bind
Подключаемся под текущей учетной записью, мы же с правами Enterprise Admin
Такое сообщение говорит о том, что вы успешно подключились.
Откроем древовидный вид – View - Tree.
В окне выбора ключевого узла Base DN, выберите Configuration Directory Partition
Должно получиться вот что.
Теперь перейдем к разделу CN=Partitions, нам нужно будет изменить его атрибуты.
Нам нужно изменить значение атрибута msDS-Behavior-Version, для этого в открывшемся окне, в разделе Attribute: пишем msDS-Behavior-Version, а в разделе Values: ставим значение 4 (4 – соответствует значению функционального уровня леса – Windows Server 2008 R2) В поле Operations: выбираем Replace.
Далее нажимаем кнопку Enter, чтобы наша команда попала в поле Entry List и нажимаем кнопку Run.
Теперь значение атрибута msDS-Behavior-Version изменилось, мы поменяли значение функционального уровня леса.
Вариант 3. С использованием консоли Active Directory Domains and Trusts
Этот вариант совсем простой в использовании, делается несколькими кликами мышки.
Заходим на контроллер домена с правами Enterprise Admin и открываем консоль Active Directory Domains and Trusts. Выделяем мышкой самый корень ветки - Active Directory Domains and Trusts – и нажимаем правой кнопкой, в выпадающем меню должен быть пункт – Raise Forest Function Level.
В открывшемся окне, выбираем нужный нам функциональный уровень леса и нажимаем кнопку Raise.
Система выдаст предупреждение о том, что данный процесс необратим. Ваш выбор, продолжать или отказаться. Я продолжаю и нажимаю OK.
Затем система выдает сообщение о том, что изменение функционального уровня леса прошло успешно и теперь эти изменения буду реплицированы на другие контроллеры леса.
Как мы теперь видим, функциональный уровень леса стал Windows Server 2008 R2
Теперь вы знаете, как можно изменить функциональный уровень леса, вам остается выбрать подходящий для вас вариант, проделать его и перейти к следующему шагу, непосредственно включению функции ADRB.
Включение функции ADRB
Так же как и изменить функциональный уровень леса, включить функцию ADRB вы можете несколькими способами:
- Используя команду Enable-ADOptionalFeature в Active Directory Module for Windows PowerShell (Microsoft рекомендует использовать именно этот метод)
- Используя утилиту LDP.exe
Вариант 1. С использованием команды Enable-ADOptionalFeature
Заходим на контроллер домена с правами Enterprise Admin или запускаем Active Directory Module for Windows PowerShell через runas.
Start, Administrative Tools, правой кнопкой мыши Active Directory Module for Windows PowerShell, и выберите Run as administrator. Введите домен, логин и пароль пользователя с соответствующими правами.
В открывшемся окне PowerShell наберите следующее:
Enable-ADOptionalFeature -Identity <ADOptionalFeature> -Scope <ADOptionalFeatureScope> -Target <ADEntity> где <ADOptionalFeature> – это название опции которую вы хотите включить, вы можете применить CN (common name) опции или DN (distinguished name), feature GUID или object GUID. <ADOptionalFeatureScope> – это область, на которую распространяется действие опции, <ADEntity> - это корневой домен леса.
Для получения дополнительной информации по команде Enable-ADOptionalFeature наберите Get-Help Enable-ADOptionalFeature.
Вот, как эта команда выглядела у меня для домена one.local
Enable-ADOptionalFeature ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target one.local
Для примера, эта команда равнозначна предыдущей
Enable-ADOptionalFeature ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ONE,DC=local’ -Scope ForestOrConfigurationSet -Target one.local
Далее система спросит у вас подтверждение данной операции, у вас будет выбор продолжить или отменить ее. Если вы продолжили у вас должно получиться тоже что и у меня.
Вариант 2. С использованием утилиты LDP.exe
Этот вариант немного посложнее в применении, зато дает понять ,что же происходит с системой внутри при выполнении команд через PowerShell.
Заходим на контроллер домена с правами Enterprise Admin и запускаем LDP.exe – Start, Run и набираем ldp.exe
В открывшемся окне выбираем Connection, Connect
Нажимаем ОК, подключаясь к текущему контроллеру
При подключении вы должны увидеть нечто подобное у себя.
Затем выполняем Connection, Bind
Подключаемся под текущей учетной записью, мы же с правами Enterprise Admin
Такое сообщение говорит о том, что вы успешно подключились.
Откроем древовидный вид – View - Tree.
В окне выбора ключевого узла Base DN, выберите Configuration Directory Partition
\
Должно получиться вот что.
Теперь перейдем к разделу CN=Partitions, нам нужно будет изменить его атрибуты.
Нам нужно добавить новый атрибут enableOptionalFeature, для этого в открывшемся окне очищаем значения в разделе DN, в разделе Attribute: пишем enableOptionalFeature, а в разделе Values: ставим значение CN=Partitions,CN=Configuration,DC=mydomain,DC=com:766ddcd8-acd0-445e-f3b9-a7f9b6744f2a (DC=mydomain,DC=com - меняем на соответсвующее имя корневого домена леса, а 766ddcd8-acd0-445e-f3b9-a7f9b6744f2a – это значение атрибута msDS-OptionalFeatureGUID объекта CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration, DC=mydomain,DC=com) В поле Operations: выбираем Add.
Выполняем команду нажатием кнопки Run.
Вот так вы можете посмотреть значение атрибута msDS-OptionalFeatureGUID. Вроде бы он одинаков для всех систем, но лучше проверить.
ак, выбрав и проделав один из вариантов, мы включаем функцию ADRB.
В следующей части статьи я расскажу о восстановлении объектов AD с помощью функции ADRB.
Комментариев нет:
Отправить комментарий