Наткнулся тут на не очень приятный баг в EV 9.0.1. После обновления с 9.0.0 начала расти очередь A6, которая отвечает за обновление ярлыков сообщений, которые перемещались внутри почтового ящика. То есть фактически это обновление не происходило. Оставил вопрос на форуме симантека. Получил следующий ответ – “There’s another thread on the form (https://www-secure.symantec.com/connect/forums/shortcut-processing-error-90-sp1) about a known issue with shortcut processing in EV 9.0.1. For the time being the resolution is to turn off the Moved Item updates on the Exchange mailbox policy.”

Фактически, наткнулся на баг в версии 9.0.1. Так что пока бы посоветовал воздержаться от обновления на 9.0.1 (по крайней мере, до тех пор, пока этот баг не будет исправлен).

После объединения топологий необходимо сконфигурировать пилотный сервер Lync, для того, чтобы он смог работать со старой инфраструктурой OCS 2007R2. Конфигурация выполняется в несколько шагов.

Подключение пилотного сервера к старым Edge-серверам

Процесс выполняется в Topology Builder. В свойствах нашего сайта включаем federation route и выбираем старый Edge-сервер.

Затем в свойствах нашего нового Front End сервера подключаем его к старому Edge-серверу.

Публикуем изменения в топологии.

Настройка старого Edge-сервера

На старом Edпe-сервере необходимо в явном виде разрешить подключение нового Lync-сервера. Делается это в свойствах оснастки Office Communications Server 2007 R2 на Edge-сервере. Она доступна по следующему пути – Computer Management → Services and Applications → Office Communications Server 2007 R2. В её свойствах на закладке Internal  во внутренние сервера надо будет добавить FQDN Lync-сервера.

Подключение пилотного сервера к старому Mediation-серверу

Операцию можно делать или из административной консоли Lync или через Lync Server Management Shell. Через шелл порядок подключения будет следующий:

  • Запускаем командлет Get-CsService -MediationServer. Смотрим что он возвратит в свойстве SiteId. Тот объект, что находятся в BackCompatSite нам и нужен. Необходимо посмотреть его Identity. В следующих шагах он нам понадобится
  • Командлетом Get-CsVoicePolicy смотрим какие голосовые политики существуют для старого Mediation-сервера. В свойствах PSTNUsage будут ссылки на политики созданные на старом Mediation-сервере
  • После того, как мы убедились, что старый Mediation-сервер существует, и существуют голосовые политики созданные на нём, мы можем приступить к созданию маршрута, который будет проходить через старый Mediation-сервер. Делается это командлетом New-CsVoiceRoute
New-CsVoiceRoute -Name RouteToOldMediationServer -NumberPattern ".*" -PstnUsages Local 
-PstnGatewayList @{Add="MediationServer:medsvr01.contoso.net"}

Здесь RouteToOldMediationServer – имя маршрута, Local – отсылка к старым политикам, MediationServer:medsvr01.contoso.net – старый Mediation-сервер.

  • Запускаем командлет Set-CsVoiceRoute, чтобы сделать новый маршрут дефолтным для нашего Lync-сервера
Set-CsVoiceRoute -Identity RouteToOldMediationServer -Priority 0

Перенос пилотной группы пользователей на Lync

У нас всё готово для переноса пилотной группы пользователей на Lync-сервер. Можно операцию переноса делать как через административную консоль Lync, так и Lync Server Management Shell. Через шелл опреация выглядит следующим образом:

  • Запускаем следующую команду
Get-CsUser -OnOfficeCommunicationServer | Where-Object {$_.Identity -like "*Имя Пользователя*"}

Смотрим свойство SipAddress этого пользователя

  • Запускаем процедуру его переноса
Move-CsLegacyUser -Identity "sip address" -Target "Lync_FQDN"

Будет запрос на подтверждение операции

  • Для проверки того, что пользователь переместился используем
Get-CsUser "sip address"

В свойстве RegistrarPool должен быть указан наш Lync-сервер

Проверка конфигурации

Чтобы убедиться, что настройки со старого сервера OCS были перенесены на Lync необходимо будет проверить конфигурации обеих серверов. Если что-то не было перенесено по некоторым причинам, необходимо будет вручную эти настройки воспроизвести на сервере Lync.

Проверяем через административную консоль Lync следующее:

  • Conferencing → Conferencing Policy. В OCS 2007 R2 назывались Meeting policy. Настройка Anonymous Particpants теперь настраивается прямо в политике конференций. Если политика конференций не была установлена на use per user, мигрировать должна была только дефолтная политика. Соответственно, остальные надо будет переносить вручную
  • Voice Routing → Dial Plan. Проверяем и смотрим, что мигрировали location profiles с OCS
  • Voice Routing → Voice Policy. Проверяем, что мигрировали голосовые политики. Если в голосовых политиках OCS не было установлено use per user, будет перенесена только глобальная политика. Остальные придётся переносить вручную
  • Voice Routing → Route. Проверяем, что мигрировали голосовые маршруты
  • Voice Routing → PSTN Usage
  • External User Access → External Access Policy. Проверяем, что мигрировали политики внешнего доступа
  • Monitoring and Archiving → Archiving Policy. Проверяем, что мигрировали политики архивации
  • Для проверки политик присутствия используется командлет Get-CsPresencePolicy. Смотрим на параметр Identity политик присутствия. Проверяем что такие были и в OCS

Продолжаем миграцию. После установки сервера Lync мы готовы к тому, чтобы начать объединять топологии OCS 2007R2 и Lync Server.

Объединение топологий

OCS использует WMI Framework для хранения и работы с топологией и своими настройками. Lync Server хранит настройки конфигурации в базах SQL Central Management Store. Для объединения топологий необходимо будет установить пакет WMI Backward Compatibility, чтобы Lync Server имел доступ к настройкам OCS. Находится он на установочном носителе Lync Server – setupamd4setupocswmibc.msi. Устанавливать его надо на сервер Lync, с которого будет производиться операция объединения топологий.

После этого запускаем Topology Builder. Указываем – Download topology from existing deployment. В меню действий выбираем Merge 2007 or 2007 R2 Topology. Continue Reading »

После завершения всех подготовительных мероприятий, описанных в предыдущей статье можно приступать к установке первого сервера Lync.

Необходимые условия

  • Поддерживается установка на следующие операционные системы: Windows Server 2008 x64 SP2, Windows Server 2008 R2.
  • Кроме этого должна существовать структура AD DS. Если не будут использоваться сертификаты выпущенные внешними центрами сертификации, необходимо внедрение локального центра CA.
  • Необходимо установить IIS со следующим набором компонент: Static content, Default document, HTTP errors, ASP.NET, .NET extensibility, Internet Server API (ISAPI) extensions, ISAPI filters, HTTP logging, Logging tools, Tracing, Anonymous authentication (installed and enabled by default), Windows authentication, Client Certificate Mapping authentication, Request filtering, Static content compression, IIS Management Console, IIS Management Scripts and Tools. Можно их установить через Server manager или через командную строку:
ServerManagerCmd.exe -Install Web-Server Web-Scripting-Tools Web-Windows-Auth
Web-Asp-Net Web-Log-Libraries Web-Http-Tracing Web-Stat-Compression
Web-Default-Doc Web-ISAPI-Ext Web-ISAPI-Filter Web-Http-Errors
Web-Http-Logging Web-Net-Ext Web-Client-Auth Web-Filtering Web-Mgmt-Console

Continue Reading »

Процесс миграции с OCS 2007/2007R2 на Lync Server подробно документирован. Поэтому изобретать что-то новое смысла особого нет. Я пройдусь по процессу миграции с небольшими замечаниями и дополнениями, которые не отображены в документации по миграции, но с чем мне пришлось столкнуться.

Миграция состоит из следующих этапов:

  1. Планирование
  2. Подготовка к миграции
  3. Внедрение пилотного сервера/пула серверов Lync Server
  4. Объединение топологий OCS 2007R2 и Lync Server
  5. Настройка пилотного сервера/пула серверов Lync Server
  6. Проверка миграции на пилотный сервер/пул серверов Lync Server
  7. Добавление Lync Server’ов с ролями Edge и Director
  8. Переход от пилотного внедрения в рабочую среду
  9. Выполнение некторых задач по завершении миграции
  10. Удаление старых серверов OCS 2007R2

Continue Reading »

Сервер Enterprise Vault (дальше — EV) состоит из нескольких основных компонентов: серверные компоненты — сервисы и задачи, осуществляющие функции архивирования, индексирования, хранения и восстановления; административная консоль для настройки и управления сервисами, задачами и архивами; компоненты веб-доступа для осуществления пользовательского доступа в архив и дополнительных компонентов.

В частности, для архивирования Exchange-сервера они будут следующие:

  • Плагин для Outlook, предоставляющий возможность полноценной работы с архивом через интерфейс почтового клиента
  • Аналогичный плагин для Entourage для пользователей Mac OS X
  • Расширения OWA для работы с архивами через клиент OWA
  • Мобильный поиск — для доступа к архивным документам через мобильные устройства

После установки и настройки сервера EV сервисы и задачи начинают в фоновом режиме выполнять сканирование целевых серверов (в частности Exchange) на наличие объектов, которые должны быть перемещены в архив, индексировать поступившие в архив объекты, а так же обрабатывать запросы на доступ к объектам, которые уже находятся в архиве. Для доступа к Exchange используется MAPI-клиент (MS Outlook), который ставится на сервер EV.

Большинство этих задач используют базы, размещённые на SQL-сервере (локальном или внешнем):

  • Enterprise Vault Directory — хранит настройки логической структуры нашего архива
  • Enterprise Vault Store — хранит настройки хранилища, в котором находятся архивы и их структуру
  • Enterprise Vault Monitoring — хранит данные мониторинга сервера EV (статус сервисов и задач архивирования, значения основных счётчиков производительности)

Настройки архивирования хранятся в политиках. Настроек архивирования достаточно много — регулировать можно фактически любой момент процесса архивирования, начиная от типа объектов, которые необходимо архивировать, заканчивая кнопками EV доступными в почтовом клиенте пользователю.

Для применения политик используется специальная задача — Provisioning Task. Она распространяет по специальным группам инициализации политики (одна политика на группу) — клиентские и для почтовых ящиков. Фактически при этом идёт рассылка настроек через скрытые (hidden) сообщения по почтовым ящикам, которые входят в группу. В группу инициализации могут входить кроме почтовых ящиков группы рассылок (политики применяются ко всем членам группы рассылки), организационные единицы AD (политики применяются ко всем почтовым ящикам, которые находятся в ней и ко всем членам групп рассылок, которые находятся в ней), LDAP-запросы и даже вся почтовая организация целиком.

Рассылка политик по умолчанию происходит ежедневно в полночь. Но можно сделать 2 рассылки в день. Первую в любое время с полуночи до полудня, вторую в любое время с полудня до полуночи.

После завершения рассылки политик по конечным ящикам нужно для каждого конкретного почтового ящика задействовать архивирование (по умолчанию после рассылки политик задача архивирования не может сразу же приступить к процессу архивирования).

Только после получения политик и включения архивирования для почтового ящика он начинает сканироваться на наличие архивных документов и плагин для Outlook/OWA начинает обрабатывать запросы на доступ к архивным документам. Обе задачи обрабатывает специальная задача — задача по архивированию.

В случае сбора архивных документов объекты из почтового ящика помещаются в очередь на сервере EV. Сбор документов запускается по расписанию (можно запускать раз в час или раз в 15 минут в определённое время суток). При этом, для защиты от переполнения очереди все сообщения, которые не попали в очередь до запуска очередного сбора в архив в очередь не попадают, и их перемещение в архив откладывается. После того как объект был обработан, в зависимости от настроек, он или удаляется сразу из ящика (и вместо него можно оставить объект-ярлык) или остаётся в ящике до того момента, пока объект не будет помещён в резервную копию на сервере EV.

В случае попытки открытия ярлыка или попытки восстановления объекта плагин Outlook/OWA отправляет запрос на IIS-сервер, работающий на сервере EV, тот в свою очередь достаёт объект из архива и возвращает пользователю.

Кроме этого, пользователю может быть настроен доступ к архиву в офлайне (доступа ни к почтовому серверу, ни к серверу EV нет) и возможность визуализации архива в Outlook в виде дополнительного почтового ящика — при этом будет доступен прозрачный поиск и по архиву и по почтовому ящику. При этом следует помнить, что при подключении функции офлайнового архива требуется место на диске — в папку пользователя в специальный файл складывается архив, по умолчанию его размер ограничен 4 гигабайтами.

После этого небольшого вступления можно приступить к рассмотрению системных требований, установке и дальнейшей настройке сервера EV.

Давно хотел написать несколько статей по новой версии Symantec Enterprise Vault (9.0), благо недавно вышел первый сервис пак для Exchange 2010 и есть с чем сравнить его обновлённую функцию архивирования. На последнем MCP-клубе увидел, что тема может показаться интересной.

Для начала имеет смысл определиться с терминами. Часто архивирование путают с резервным копированием (предполагаю, что связано это с тем, что достаточно давно программы, выполнявшие резервные копии назывались архиваторами). В чём же разница между этими двумя, на внешний взгляд, похожими процессами? Давайте посмотрим на определение терминов, обозначающих эти процессы.

Архивирование — процесс сбора устаревших данных с целью их дальнейшего хранения.

Резервное копирование — процесс создания копии данных, предназначенной для восстановления данных в случае их повреждения или удаления.

На лицо разница в целях процессов. Целью архивирования является хранение устаревших (исторических) данных (оригинальных документов), целью же резервного копирования является создание копий документов с возможностью их восстановления в случае повреждения или удаления оригинальных данных.

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

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

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

В следующей статье перейдём непосредственно к Symantec Enterprise Vault (как он работает, его системным требования и тд).

В первом сервис паке для Exchange 2010 появилось некоторое количество улучшений в системе встроенного архивирования, что позволяет говорить об этой функции как о серьёзной альтернативе решений для архивирования третьих фирм.

Основная идея архивирования не изменилась со времени выхода Exchange 2010 RTM. Архивация производится на основании политик хранения.

Политики хранения, в свою очередь, работают на основании тэгов хранения, которые может создать и настроить администратор почтовой организации, либо использовать дефолтную политику, которая уже имеется. Тэги используются для применения настроек хранения (не политик!) к папкам в ящике и объектам внутри папок (сообщения, записки и контакты). Настройки хранения задают период времени в течение которого объект может находиться в почтовом ящике. По истечении этого периода мы можем произвести ряд действий с объектом: удалить, переместить в архив или отметить для привлечения внимания пользователя.
Continue Reading »