Сегодня было объявлено о выпуске PST Capture Tool – утилиты для сбора сообщений из pst-файлов пользователей в почтовые ящики пользователей и/или архивы. Поддерживается импорт в Exchange 2010/Office 365/Exchange Online. Можно так же импортировать в почтовые ящики на Exchange 2007, но этот сценарий официально не поддерживается.

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

PST Architecture Overview

Утилита состоит из следующих компонентов:

  • Серверная часть (Central Service)
  • Консоль администратора (PST Importer Console)
  • Агенты, установленные на компьютеры пользователей (PST Agent)

Процесс сбора происходит в два этапа:

  • Сначала через консоль администратора создаётся задание на поиск pst-файлов. Далее через агентов осуществляется поиск (можно его достаточно гибко настраивать – например искать только на определённых дисках). Список найденных pst-файлов затем отображается в консоли администратора.
  • Затем создаётся список из pst-файлов, которые планируется импортировать в почтовый ящик пользователя. После чего можно сопоставить разные pst-файлы разным почтовым ящикам и запустить процесс импорта.

Скачать утилиту можно отсюда. Документация доступна здесь.

Давеча с Олегом Крыловым вышел разговор про FSMO-роль RID Master, в связи с тем, что Олег решил начать читать ресурскит по Windows 2008 Active Directory.

С первым его вопросом о том, сколько относительных идентификаторов выделяет RID Master только что созданному контроллеру домена ответ ясен – стандартный выделяемый пул для новых контроллеров домена (и для неновых тоже, впрочем) – 500 штук.

Со вторым вопросом, о том, в какой момент контроллер домена начинает запрашивать очередную порцию идентификаторов ситуация оказалась немного сложнее. Ресурскит утверждает, что запрос очередной порции идентификаторов происходит после того, как в запасе у контроллера домена остаётся только 20% (100 штук по молчанию) идентификаторов от размера пула. Однако же, имеется статья в базе знаний, которая утверждает, что с Windows 2000(!) SP4 поведение немного поменялось – запрос происходит уже при количестве оставшихся идентификаторов 50% от размера пула (250 штук по умолчанию). База знаний источник более надёжный, чем ресурскит. Но давайте попробуем проверить.

Итак, у нас имеется контроллер домена на базе Windows 2008 Server. Уровень домена – Windows 2000 native.

Информацию по RID master можно получать через команду:

dcdiag /v /test:ridmanager

Наш первый контроллер домена является по совместительству RID Master’ом и уже выдал сам себе первую порцию идентификаторов (с 1100 по 1599):

Вводим второй контроллер домена, смотрим информацию по пулу идентификаторов:

Видно, что RID Master выделил пул индентификаторов с 1600 по 2099 (rIDAllocationPool). При этом, новых объектов этот контроллер домена пока ещё не создавал, поэтому следующий объект получит идентификатор 1600 (rIDNextRID). Теперь, с помощью следующего скрипта создадим 250 пользователей в специально сделанной под это организационной единице Test Users в корне нашего домена:

for /L %i in (1,1,250) do (dsadd user "cn=User%i,ou=Test Users,dc=test,dc=loc"
-pwd P@ssw0rd -upn "user%i@test.loc" -samid "User%i" -fn "Test%i" -ln "User%i"
-display "User%i, Test%i")

Смотрим информацию по пулу идентификаторов:

Видно, что RID Master уже выделил контроллеру домена очередную порцию идентификаторов (с 2100 по 2599), то есть процесс пошёл так, как и описано в статье из базы знаний.

Echange 2010 SP2 вышел уже почти 2 месяца как. Со времени его выпуска наткнулись на один неприятный баг. Нашли как его обходить. Так что можно приступать и к обновлению.

Порядок обновления ролей в сайте следующий:

  1. CAS
  2. Hub Transport
  3. UM
  4. Mailbox

При обновлении используется setup.com /M:Upgrade /InstallWindowsComponents или графический режим. В процессе обновления предыдущая установка удаляется и заново ставится Exchahge 2010 SP2. Настройки подтягиваются из AD. Предварительно, при первом запуске процедуры обновления запускается мастер, обновляющий схему. Нужно помнить, что учётная запись, от имени которой происходит обновление схемы должна быть в группах Schema Admins и Enterprise Admins. Continue Reading »

Ранее я уже писал о том, что обещали в официальных пресс-релизах по поводу выхода Enterprise Vault 10.0. Сейчас дошли руки установить его и посмотреть. Начну смотреть настройки почти с самого верха, то есть с сайта.

Сайт

В связи с изменениями в службе индексирования немного изменились настройки в административной консоли. В частности, в свойствах сайта настройки индексирования с закладки Archive Settings убрали. Continue Reading »

После установки SP2 на Exchange 2010 на некоторых CAS-серверах в Event-Log начнёт с завидной периодичностью появляться предупреждение с ID 1309:

Event code: 3005
Event message: An unhandled exception has occurred.
Event ID: 16bd39e6a1304f19a0c9575b8a0899c4
Event sequence: 565
Event occurrence: 170
Event detail code: 0

Application information:
    Application domain: /LM/W3SVC/1/ROOT/EWS-1-129707580288317561
    Trust level: Full
    Application Virtual Path: /EWS
    Application Path: C:Program FilesMicrosoftExchange ServerV14ClientAc...
    Machine name: EU-HUB2

Process information:
    Process ID: 8012
    Process name: w3wp.exe
    Account name: NT AUTHORITYSYSTEM

Exception information:
    Exception type: IndexOutOfRangeException
    Exception message: Index was outside the bounds of the array.

Пользователям это грозит следующим: перестаёт запускаться помощник OOF (причём в OWA он работает), клиент Mail под MacOS перестаёт подключаться к почтовому серверу, ломается интеграция с клиентом Lync. Приятного мало. MS (здесь, здесь и здесь) в качестве временного решения проблемы предлагает следующее:

After you install Exchange 2010 SP2, 'MSExchangeServicesAppPool' may crash on
startup. The w3wp process will keep running but may fail to service any EWS
requests. This may result in the loss of OOF (Out of Office), Availability, Lync
State features, and EWS clients such as Mac Outlook may not work properly.

То есть остановка и, затем, ручной запуск пула MSExchangeServicesAppPool проблему решает. До следующей перезагрузки сервера. Так что рекомендовал бы подождать появления RU1 для Exchange 2010 SP2, прежде чем обновляться на Exchange SP2.

Update: кажется выяснили, что причиной такого поведения является наличие в названии базы данных, где находится почтовый ящик пользователя следующих символов: (, :, “, ). То есть временное решение проблемы выглядит следующим образом:

1. Удаляем из имени базы символы, указанные выше. Information Store при этом перезапускать не надо.
2. Через IIS Manager перезапускаем пул MSExchangeServicesAppPool.

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