Предполагается, что до применения процедуры аварийного восстановления сервера существовали, но в силу ряда причин стали недоступны.

Причины могут быть следующие:

  • Отказ оборудования сервера
  • Неудачная установка сервис-пака (с некоторыми оговорками, подробнее ниже)
  • Перенос сервера на новое оборудование.

В нашем случае имя почтового сервера не меняется.

В случае с неудачной установкой сервис-пака перед проведением процедуры аварийного восстановления необходимо удалить следы Exchange с почтового сервера. Процедура удаления следующая:

  1. Убеждаемся что Exchange Management Shell и Exchange Management Console закрыты.
  2. Идём в оснастку сервисов, останавливаем сервис «Microsoft Exchange Active Directory Topology Service» и меняем его тип запуска на disabled.
  3. Останавливаем и меняет типа запуска на disabled у сервисов начинающихся на «Microsoft Exchange» и у сервиса «Microsoft Search (Exchange Server)».
  4. Перезапускаем сервер.
  5. Через редактор реестра удаляем ветки: «HKLMSOFTWAREMICROSOFTEXCHANGE» и «HKLMSYSTEMCURRENTCONTROLSETSERVICESMSEXCHANGE*».
  6. Через любой файловый менеджер переименовываем оставшуюся папку %Program Files%MicrosoftExchange Server в %Program Files%MicrosoftOld Exchange Server.
  7. Перезапускаем сервер.
  8. Через Windows Installer Cleanup Utility удаляем следующее: Microsoft Exchange 2007 Enterprise Anti-Spam Signature, Microsoft Exchange 2007 Enterprise Block List Update, Microsoft Exchange 2007 Standard Anti Spam-filter Update, Microsoft Exchange Client Language Pack, Microsoft Exchange Server, Microsoft Full Text Indexing Engine for Exchange, Microsoft Exchange Full text indexing Services
  9. Перезапускаем сервер.

Предполагается, что к моменту аварийного восстановления новый сервер полностью подготовлен (установлена такая же операционная система, что и на предыдущем, он введён в домен, установлены все необходимые для установки Exchange обновления и программы).
Continue Reading »

Ранее я подробно расписывал один из способов настройки службы автообнаружения. В ситуации с несколькими smtp-доменами, которые активно используются сотрудниками компании ситуация несколько усложняется. При подключении клиент Outlook делает несколько проверок способов доступности сервера автообнаружения, и тот способ, который вернёт успешную проверку будет использоваться клиентом Outlook в течение сессии. Порядок проверки следующий:

  1. Проверяется доступность файла https://domain.com/AutoDiscover/AutoDiscover.xml
  2. Проверяется доступность файла https://autodiscover.domain.com/AutoDiscover/AutoDiscover.xml
  3. Проверяется результат, возвращаемый методом перенаправления http
  4. Проверяется наличие записи _autodiscover._tcp.domain.com (для Outlook 2007 необходимо обновление описанное в статье 939184)

Что из этого следует в случае наличия нескольких smtp-доменов?

2. Сертификат, установленный на наших CAS-серверах в поле Subject Alternative Names по идее должен (но не обязан!) содержать записи autodiscover для всех наших smtp-доменов + имена всех наших CAS серверов. С одной стороны самый простой способ (достаточно в SAN внести данные для всех доменов), с другой стороны самый немасштабируемый способ (в случае появления нового smtp-домена, который должен обслуживаться службой автообнаружения надо будет перевыпускать сертификат, что в случае с сертификатом, выданным внешним центром сертификации, может вызвать некоторые неудобства).

3. Для каждого smtp-домена, запись автообнаружения которого не внесена в поле SAN (о котором говорится в предыдущем пункте) можно настроить перенаправление http запросов сервиса автообнаружения на сервер службы автообнаружения. Минус у способа один – необходим дополнительный ip-адрес для сайта заглушки, который будет перенаправлять запросы на обнаружение сервиса автообнаружения на рабочий сервер службы автообнаружения.

4. Для каждого smtp-домена, запись автообнаружения которого не внесена в поле SAN и не настроено перенаправление запросов к службе автообнаружения можно настроить srv-запись _autodiscover._tcp.domain.com с портом 443, ссылающуюся на сервер службы автообнаружения. Способ имеет ограничения – если dns-зона нового smtp-домена поддерживается сторонней организацией, скорее всего доступа к созданию srv-записей не будет. С другой стороны этот способ проще в настройке чем настройка перенаправления http запросов.

Ниже дана настройка перенаправления http запросов в службу автообнаружения.
Continue Reading »

Примерно 2 недели назад на симантековском файлконнекте появился доступ к Enterprise Vault 9.0. Из нового заявлено следующее:

  • Появилась поддержка архивирования почтовых ящиков и общих папок, которые находятся на серверах Exchange 2010 SP1. Кроме этого добавлены скрипты PowerShell для управления доступа к архивам.
  • Появились специальные счётчики, которые регулируют запуск сихронизации оффлайнового хранилища (Vault Cache) при достижении определённых значений (а не только по расписанию).
  • Появилась поддержка Sharepoint 2010.
  • Некоторые улучшения архивирования серверов Domino.
  • Добавлены новые ключи в утилиту FSAUtility, добавлена утилита FSAUndelete.
  • Поддерживаются MacOS X версий 10.5 (Leopard) и 10.6 (Snow Leopard).
  • Сделали доступ к Microsoft Entourage 2008 Web Services Edition через клиента для MacOS X.

Поддержки Outlook 2010 пока нет. Обещают с первым сервис паком для девятки в конце этого года.