Вся правда о Single Item Recovery

   Несмотря на относительно давнее появление функции Single Item Recovery, а появилась она в Exchange 2010 год назад, у многих отсутствует понимание того, что это такое, как это правильно использовать и как это связано с резервным копированием.

   Итак, во-первых, речь идет о восстановлении удаленных сообщений пользователя. В Exchange 2003/2007 при удалении сообщения пользователем в Outlook оно перемещалось в папку удаленных сообщений, либо пользователь мог удалить сообщение «жестко», удерживая Shift, так что сообщение удалялось без попадания в папку удаленных сообщений. После этого пользователь мог восстановить сообщение, воспользовавшись функцией восстановления в Outlook, т.к. удаленное сообщение хранилось некоторое время в почтовой базе (по умолчанию 14 дней) до удаления его процессом обслуживания почтовой базы. Но пользователь мог удалить досрочно сообщение из базы, лишая себя и администратора возможности восстановления сообщения. Таким образом, удаленное тем или иным способом сообщение рано или поздно исчезало из почтовой базы. Единственный способ в Exchange 2003/2007 восстановления утраченного сообщения заключался в создании регулярных резервных копий почтовых баз. Восстановив почтовую базу на отдельном сервере из резервной копии, можно было восстановить нужное сообщение и перенести его в рабочую базу. Процесс непростой, а в случае больших объемов информации и очень-очень длительный. А кто из нас не сталкивался с ситуацией, когда начальству надо найти «то, не знаю что, и не знаю за какой период»? Вот и приходилось восстанавливать все непосильно нажитое за многие годы и не по одному разу. Если пересчитать на деньги, то процесс восстановления получался очень дорогим удовольствием.

   Что нам дал Exchange 2010? Механизм восстановления стал более функциональным и оперативным во всех отношениях. Для любого почтового ящика можно включить механизм Single Item Recovery. В результате пользователь не может полностью удалить сообщение – оно в конце концов оказывается в служебной папке его почтового ящика и хранится там, неподвластное пользователю, некоторое время (retention period) до удаления процессом Managed Folder Assistant.

   Что это означает для наших резервных копий? Их можно отложить на промежуток времени равный retention period! Например, если его установить в 30 дней, то резервное копирование с целью восстановления удаленных сообщений можно делать не чаще одного раза в месяц! А если поставить 365 дней, то целый год нам не нужно делать резервное копирование почтовой базы! Конечно это происходит за счет увеличения размеров почтовых ящиков и почтовой базы в целом. А что мы получаем взамен? Экономия места под резервные копии. Но это не самое вкусное: мы получаем возможность оперативного поиска (да оно работает по почтовой базе!) и оперативного восстановления удаленных почтовых сообщений. Все вместе это дает колоссальную экономию средств и времени.

Вывод. Таким образом, правильно спроектировав хранилище почтовых баз, мы можем использовать механизм Single Item Recovery как прекрасную функциональную замену резервному копированию.

Примечание 1. Single Item Recovery это не единственный вариант замены резервного копирования. В этом прелесть Exchange 2010. Для больших внедрений надо рассматривать внедрение системы управления записями – в ней будет храниться история всей почтовой переписки с возможностью оперативного поиска.

Примечание 2. Ростом почтовой базы при использовании Single Item Recovery можно и нужно разумно управлять. Во-первых, включать Single Item Recovery нужно не тотально на всех почтовых ящиках, а там где это действительно нужно. Во-вторых, как альтернативу можно использовать персональные архивные почтовые ящики (отчасти конечно). В-третьих, как альтернативу можно рассматривать запись всех сообщений с помощью правил транспортного сервера в общий архивный почтовый ящик (как приближение к системе управления записями).

Примечание 3. Есть другой момент, который надо тут упомянуть для полной картины, но подробное рассмотрение которого, выходит за рамки этой статьи – резервное копирование с целью восстановления полностью утраченной почтовой базы. Новое решение, которое предлагает Exchange 2010 вместо резервного копирования в этом случае – именуется DAG. Single Item Recovery и DAG позволяют полностью исключить потребность в резервном копировании почтовых баз.

   Отмечу еще две полезные функции, которые дает нам Exchange 2010. Они связаны с Single Item Recovery, но имеют специфическое назначение – защита от злоупотреблений, и это вносит некоторую путаницу в понимание Single Item Recovery.

   Что если мы не хотим, чтобы почтовый ящик автоматически очищался от удаленных сообщений? Автоматику можно отключить, включив на почтовом ящике litigation hold! После этого процесс Managed Folder Assistant даже по истечении retention period не будет очищать служебные папки почтового ящика, где хранятся удаленные сообщения. Более того из такого почтового ящика будет невозможно ничего удалить никаким способом. Хорошая защита от злоупотреблений.

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

   Надеюсь, мои разъяснения по поводу Single Item Recovery помогли вам понять, что такое Single Item Recovery, как оно соотносится с резервным копированием и защитой от злоупотреблений.

   Полезные ссылки:

1. Подробное описание механизмов Single Item Recovery в блоге команды Exchange:

http://blogs.technet.com/b/exchange/archive/2009/09/25/3408389.aspx

2. Процедуры восстановления удаленных элементов:

http://blogs.technet.com/b/exchange/archive/2010/04/26/3409870.aspx

http://technet.microsoft.com/en-us/library/ff660637.aspx

3. Информация Technet по теме статьи:

http://technet.microsoft.com/en-us/library/ee364755.aspx

Реклама

Решение проблемы регистрации виртуальных машин в DNS

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

При генерации пула виртуальных машин VMware View  (linked clones pool) создаются учетные записи компьютеров в указанном контейнере AD. Виртуальные машины запускаются, получают ip адреса по протоколу DHCP, регистрируют себя на DNS серверах. Как правило регистрация в DNS серверах настроена как secure, т.е. только компьютер-создатель записи имеет право ее изменять и удалять. Этот механизм защищает DNS сервер от атак подмены адресов. Когда мы запускаем повторную генерацию пула виртуальных машин (recompose) происходит следующее: существующие виртуальные машины удаляются как объекты и файлы на виртуальной платформе, а также удаляются их учетные записи из AD, после чего происходит создание новых виртуальных машин, включение их в домен и запуск. Теперь появилась новая виртуальная машина со старым именем, и это имя она пытается зарегистрировать в DNS, но такое имя там уже есть, и создано оно от имени другой учетной записи! – SID новой виртаульной машины другой. В результате получаем проблему: после регенерации пула виртаульные машины не могут себя зарегистрировать в DNS, пока мы не очистим его вручную, или пока не пройдет самоочистка DNS от старых записей (если она настроена).

Так как ничего путного в документации по VMware View  мне не попалось, пришлось обратиться в уважаемому Интернету. И удивительное дело – ничего по этой проблеме серьезного не обнаружилось: всего несколько сообщений типа «я отключил DNS secure updates и – о чудо! –  все заработало». Но отключение безопасных обновлений DNS это не только глупость, но и смертельный приговор всей AD.

Проблема для меня была негорящей и поэтому оставалась открытой пару месяцев. Но вот на днях пришлось взяться за нее серьезно, но взяться серьезно не получилось: поиск в Интернете сразу вывел на комментарий в блоге, где предлагалось работающее решение (после его тестирования могу сказать, что действительно работает). Хотя сама статья блога совершенно неправильная, ссылку приведу ради путного комментария http://paulslager.com/?p=1232

Суть решения:

1.       Создать скрипт с командами:

start ipconfig.exe /release

 timeout /t 5

2.       Назначить его как Shutdown скрипт для виртальных машин пула либо через родительскую машину, либо через групповые политики. Я использовал групповые политики, и это сработало.

Теперь после инициации recompose VMware View  выключает виртуальные машины, выполняя в гостевых операцилнных системах Shutdown, при этом срабатывает скрипт и освобождает ip адрес (в том числе удаляется запись в DNS).

Побочный эффект: ip адрес сбрасывается при любой перезагрузке виртуальной машины.

Еще один вариант, который мне пришел в голову:  настроить на DNS серверах максимально короткое время самоочистки (scavenging). Оно будет равно 2-3 часа. Если сгенерировать пул ночью, то к утру виртуальные машины в любом случае пропишутся в DNS. Вариант отметается как издевательство на DNS и AD: даже в небольшой сети будет лавина обновлений и очисток DNS плюс лавина репликаций между домен-контроллерами для обновлений зон.

Заключение

Как видите ситуация достаточно специфическая, и невозможно однозначно сказать кто «виноват». Microsoft вроде как не при чем: откуда операционной системе знать, что ее убивают? С другой стороны VMware View не знает, с каким именем операционная система регистрируется в DNS и регистрируется ли вообще. Возлагать на VMware сохранение SID-ов – это лишиться всячекой поддержки от Microsoft на веки вечные: есть лишь один поддерживаемый механизм клонирования операционных систем Windows – sysprep.

Единственный вариант, который я вижу, это автоматизация от VMware: научить VMware View агента, установленного в операционной системе, запускать ipconfig.exe /release в ответ на инициацию процедуры recompose.

Если кто-то из специалистов по VMware знает более правильное решение, то буду рад увидеть его в комментариях к этой статье.

Outlook, AD, ANR – настраиваем поиск в адресной книге

Жизненные ситуации настолько разнообразны, что предусмотреть все сценарии использования программного обеспечения невозможно.  Иногда до удивления непонятно как разработчики программ умудряются предусмотреть некоторые сценарии. И этого скорее говорит не о предусмотрительности, а о правильном проектировании основ. В данном случае я виду речь об Outlook, Active Directory и поиске в адресной книге.

Вот какая ситуация возникла у пользователя, который обратился на форум Technet-RU:

«Нам необходимо добавить два дополнительных поля для поиска (cn и DisplayNameSimple, с помощью ANR) в скачиваемую на клиенты OAB (Outlook 2010, 2007; в режиме кэширования).»

Первая мысль была, что такое сделать невозможно, т.к. OAB не настраивается в Outlook. Но оказывается, задача имеет решение: разработчики Active Directory и Outlook заложили в основу чрезвычайно мощные технологии – настраиваемая индексация атрибутов LDAP и поисковый алгоритм Ambiguous Name Resolution.

Отмечу, что мы рассматриваем распознавание имен при написании их в полях Outlook To:, BCC: и т.п.

1.      Что такое Ambiguous Name Resolution

Формальное описание алгоритма поиска ANR можно найти в MSDN

В статье KB243299  можно найти описание некоторых сценариев использования ANR.

Суть в том, что обычный запрос к LDAP требует составления фильтра поиска, а ANR позволяет выполнить поиск без указания фильтра: объекты в LDAP ищутся по нескольким заранее определенным атрибутам. Например, вы можете напечатать имя или фамилию адресата, либо алиас его почтового адреса – поиск будет выполнен без точного указания того, что именно вы ввели.

2.      Настраиваем нужные атрибуты

Чтобы включить атрибут в алгоритм поиска ANR нужно сделать две вещи: включить индексацию атрибута и пометить его флагом fANR. Для этого:

a.       Запускаем оснастку настройки схемы Active Directory Schema.

b.      Находим нужный атрибут.

c.       Выставляем флаги индексации, ANR и репликации в Global Catalog (поисковые запросы всегда выполняются на GC).

Подробные шаги можно найти в статье http://www.msexchange.org/articles/Ambiguous-Name-Resolution.html

3.      Настраиваем Outlook

Для того чтобы поиск по дополнительным атрибутам заработал, нужно внести изменения в реестр согласно статье KB831124 How to force Outlook 2010, Outlook 2007, or Outlook 2003 to resolve proxy addresses and custom properties in Cached Exchange Mode.

Дело в том, что когда Outlook находится в режиме кэширования, то поиск выполняется только в OAB, а не в LDAP. Причем в OAB версии 4 для поиска используются следующие индексированные атрибуты:

·         mailNickname (Alias)

·         displayName (Display Name)

·         physicalDeliveryOfficeName (Office)

·         sn (Last Name)

·         givenname (First name)

·         SMTPaddress (email address)

Добавление ключа реестра заставляет Outlook даже в режиме кэширования выполнять поиск в LDAP и, следовательно, использовать все индексированные в LDAP атрибуты в алгоритме ANR, что нам и требовалось для решения исходной задачи.

 

Таким образом можно включить в поиск любой необходимый вам атрибут, например, табельный номер (Employee ID) или атрибут пользователя (Custom attribute 1 — 15).

Да будут ваши пользователи еще более довольными! :-)