В Exchange 2007/2010 некоторые свойства объектов являются многозначными. То есть, фактически представляют из себя массив. Самый простой пример – набор smtp-адресов почтового ящика.

[PS] C:Windowssystem32>Get-Mailbox Stas | fl Name,EmailAddresses

Name: Stas
EmailAddresses: {smtp:st@buldakov.ru, SMTP:stas@buldakov.ru}

Сегодня с Олегом Крыловым пытались вывести в csv-файл похожий объект. Изначально задача стояла такая – нужно вывести разрешения AD на коннектор получения в csv-файл. Для начала через Get-ReceiveConnector получаем сам объект-коннектор, затем смотрим права на него через Get-ADPermissions. Получается примерно следующее:

Столбец Rights – то что нам необходимо. Пытаемся его перенаправить прямо в Export-Csv. Получается следующий файл:

Немного не то, что мы ожидали. Вместо самого значения свойства в csv-файл ушёл его тип. Давайте попробуем посмотреть, почему так произошло. Для этого посмотрим что это за объекты:

Сразу видно, что нужные нам свойства (AccessRights и ExtendedRights) являются многозначными. Возникает вопрос – как их корректно вывести в csv-файл? Верный ответ удалось подсмотреть здесь. Итого команда получается следующая:

Get-ReceiveConnector "EVLAB-EXDefault EVLAB-EX" | Get-ADPermission |
Select User,
@{Name='AccessRights';Expression={[string]::join(";",($_.AccessRights))}},
@{Name='ExtendedRights';Expression={[string]::join(";",($_.ExtendedRights))}} |
Export-Csv c:exp.txt

На выходе имеем следующий файл:

Ура!

Ни разу не писал про процесс обновления Enterprise Vault. Исправляю это упущение, благо процесс этот пошагово в подробностях расписан в документе Upgrade_Instructions.chm, идущем в комплекте с каждым новым дистрибутивом.

Подготовка

Подготовка к обновлению:

  • Если необходимо, меняем модель восстановления всех баз EV на Simple
  • Делаем резервное копирование всех баз и хранилищ
  • Устанавливаем и запускаем Deplyment Scanner из нового дистрибутива
  • Если необходимо, меняем права доступа для служебной учётки EV (из под неё будет проходить обновление баз – необходимо будет назначить её владельцем)
  • Подготовка к изменениям в службе индексирования

Необходимо будет убедиться, что кэш для службы индексирования настроен. Делается это через свойства сервера EV. На закладке Cache находятся настройки кэша для службы индексирования. Continue Reading »

На днях официально вышел Exchange 2010 SP2. Автоматическое перенаправление OWA между сайтов – одна из интересных функций реализованных в его составе. Что из себя представляет? Если у нас имеется многосайтовая почтовая организация, то в случае, если сотрудник из одного сайта пытается полключаться к OWA через другой сайт, то возможны были 2 варианта – перенаправление и проксирование запроса. В случае с перенаправлением сотрудник получал ссылку на адрес нужного ему CAS-сервера, через который он должен был входить.

После установки SP2 такой запрос автоматически перенаправляется на нужный CAS-сервер, при этом сотрудник не должен второй раз вводить свои учётные данные – он будет автоматически перенаправлен в свой ящик. Фактически это поведение описывает SSO (Single Sign-On) в случае использования многосайтовой конфигурации.

Для настройки используется ключ -CrossSiteRedirectType командлета Set-OWAVirtualDirectory. По умолчанию этот параметр выставлен в Manual. Доступны следующие его значения:

  • Manual. Поведение по умолчанию, описанное выше. То есть пользователь получит ссылку на нужный ему CAS-сервер
  • Silent. Новое поведение, включающее механизм SSO. Если используется FBA – необходимо использовать SSL.

Полный список новшеств можно посмотреть здесь.

В Exchange 2007/2010 для работы с переговорными комнатами появился специальный тип объектов. По большому счёту, он является разновидностью обычного почтового ящика. После того как для всех переговорных комнат созданы эти объекты возникает вопрос каким образом пользователи могут просматривать занята переговорная комната или нет? Эту информацию выводит помощник по планированию, который не даст забронировать переговорку, если там уже что-то запланировано (это поведение можно изменить).

Помощник по планированию предоставляет информацию о занятости переговорной комнаты в не очень нагляном виде. Гораздо удобнее подключить календарь комнаты и посмотреть на какое время у переговорной комнаты назначены встречи. Но для этого необходимо будет в явном виде предоставить права доступа к календарю переговорной комнаты. Для этого можно использовать командлет Add-MailboxFolderPermission. Более того, для календаря специально можно задать группы разрешений – AvailabilityOnly и LimitedDetails. Первая группа прав позволяет в календаре просматривать только информацию о занятости комнаты, вторая – кроме этого позволяет видеть заголовки совещаний. Каждому календарю делать права доступа долго. Интереснее было бы попробовать права назначить сразу всем. С помощью Васи Гусева получился такой небольшой скрипт:

$MBX = Get-Mailbox -RecipientTypeDetails RoomMailbox
$MBX | ForEach {Add-MailboxFolderPermission -Identity ($_.Alias + ":Calendar")
-AccessRights LimitedDetails -User Default}

Илья Сазонов скинул ссылку на решение задачи в одну строку:

ForEach ($Mailbox in (Get-Mailbox -RecipientTypeDetails RoomMailbox))
{ Add-MailboxFolderPermission -Identity "$($Mailbox.Name):Calendar"
-AccessRights LimitedDetails -User Default }

Как-то так.

Как-то писал о назначении административных прав доступа для администраторов региональных офисов. В Lync Server, с одной стороны, эта операция выполняется значительно проще. С другой стороны, места для манёвра при назначении прав доступа сильно меньше.

Чтобы назначить необходимые для администрирования Lync Server права региональным администраторам и ограничить их границами только своей инфраструктуры делается следующее:

  • Создаём Security-группу (если в региональном офисе свой домен – то в этом домене)
  • Запускаем следующий командлет:
New-CsAdminRole -Identity "Local CSAdministrator" -Template CSAdministrator
-ConfigScopes "site:SiteId" -UserScopes "OU:OU=LocalStaff,DC=domain,DC=local"

Здесь “Local CSAdministrator” – группа безопасности, созданная на первом шаге. В неё входят администраторы регионального офиса. CSAdministrator – используем в качестве шаблона группу с полными правами доступа (можно использовать любой из стандартных шаблонов, список которых можно получить через командлет Get-CsAdminRole). В ключе ConfigScope указываем в качестве области действия идентификатор сайта, связанного с региональным офисом (список сайтов, а так же их идентификаторы можно получить через командлет Get-CsSite). В ключе UserScope можно указать организационную единицу, в рамках которой может применять свои права региональный администратор. Последние два ключа необязательны.

Lync/Communicator позволяет брать информацию из Out-of-Office почтового ящика пользователя и показывать его в свойствах учётной записи пользователя.

Столкнулся с забавной ситуацией. У одного сотрудника появился в Lync статус из Out-of-Office и не пропал. Даже после того как его отключили в Outlook. Первым делом был удалён локальный кэш Lync’а. Впрочем, это не помогло. Абсолютно случайно, при проверке настроек Lync увидел что была отключена интеграция с Outlook. Тут то всё и встало на свои места. По какой-то причине при включенном OOF пользователь отключил в Lync интеграцию с Outlook. В итоге Lync перестал обновлять информацию из Outlook и статус OOF в нём подвис.

В Lync/Communicator картинка такая:

А в настройках OOF в Outlook такая:

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

Проблема – перестали показываться напоминания. Первым делом необходимо проверить повторяется ли эта проблема в OWA. Это позволит понять на стороне сервера или на стороне клиента возникает проблема. Оказалось что и в OWA и в мобильном клиенте, использующем ActiveSync, напоминания появляются. Что автоматически означает, что проблема на стороне клиента.

Вариантов два – либо проблема появилась в результате сбоя кэша или в результате сбоя профиля Outlook. Первый вариант проверяем отключением кэша. Если в онлайн-режиме напоминания не появляются – скорее всего проблема со сбоем в профиле Outlook. Исправляется это созданием дополнительного профиля и/или удалением старого. Не забываем при этом, что все архивные pst-файлы необходимо будет в новом профиле подключить заново.

Видел в интернете варианты попыток решения проблемы с использованием ключей /resetfolders и /cleanreminders:

outlook.exe /resetfolders
outlook.exe /cleanreminders

Нужно чётко понимать что эти ключи делают. Первый – просто восстанавливает потерянные папки. Полный список ключей с описанием можно посмотреть здесь. А вот второй может помочь – так как запускает процесс повторного создания напоминаний на клиенте. Ещё будет полезен ключ /cleanprofile, который удаляет неправильные ключи из реестра для дефолтного профиля и создаёт правильные.

Предупреждение: то что написано ниже может оказаться неверным. Так как официальная документация по Windows Server 8 отсутствует, то о работе некоторых функций можно только догадываться. Так что используйте на свой страх и риск.

В составе файловых сервисов в Windows Server 8 DP появилась крайне интересная функция дедупликации данных. Что такое дедупликация – фактически это процесс фильтрации данных в контейнере с данными на наличие совпадающих данных и дальнейшая организация хранения дублирующихся данных в единственном числе и корректное предоставление к ним доступа. Дедупликация в продуктах МС уже встречалась. В частности, Exchange 2000/2003/2007 использовали дедупликацию в пределах отдельных почтовых баз (называлось это SIS – Single Instance Storage). Windows Storage Server умеет делать дедупликацию файловых хранилищ (правда на файловом уровне). Производители аппаратных хранилищ данных часто встраивают в свои решения дедупликацию. Symantec во многих своих продуктах так же её использует и достаточно активно продвигает. В общем дедупликация – это полезно, а теперь и (в составе Windows Server 8) бесплатно. Хочется верить, что эта функция доживёт до RTM версии стандартного серверного дистрибутива. Continue Reading »

После завершения переноса данных сервера почтовых ящиков на новые сервера и удаления старых можно приступать к переключению на новые транспортные сервера. Можно это делать сразу после установки первого транспортного сервера. Порядок не принципиален. Основная работа по переключению будет идти с DNS-сервером и коннекторами.

Для начала можно перенести транспортные правила со старых серверов на новые. Делается это через Exchange Management Shell на любом сервере Exchange 2010 следующим образом:

$file = Export-TransportRuleCollection -ExportLegacyRules
Set-Content -Path d:rules.xml -Value $file.FileData -Encoding Byte
[Byte[]]$Data = Get-Content -Path d:rules.xml -Encoding Byte -ReadCount 0
Import-TransportRuleCollection -FileData $Data

Для того чтобы новые транспортные сервера сервера могли отправлять почту необходимо для них создать во внешней DNS-зоне A-записи и MX-записи, ссылающиеся на эти A-записи. Чтобы при этом почта проходила спам-фильтры на принимающих серверах (при их наличии) необходимо так же проконтролировать, что провайдер в обратной зоне для внешнего ip-адреса транспортных серверов укажет в PRT-записях их dns-имена. Так же имеет смысл создать корректную SPF-запись, либо, если она уже существует – добавить в неё новые транспортне сервера.

Следующим шагом необходимо создать и настроить Send-коннектор для новых транспортных серверов, через него будет уходить почта во внешний мир. Можно новые транспортные сервера добавить в уже существующий send-коннектор, который использует старые транспортные сервера.

В том случае если создаётся новый send-коннектор, старый можно отключать. Сразу удалять его не стоит – может пригодится, если по каким то причинам придётся его заново использовать. Если новые транспортные сервера были добавлены в существующий send-коннектор, то из него нужно удалить старые транспортные сервера. Но этот вариант, с моей точки зрения, менее красив, так как откатиться к старому send-коннектору в случае каких-либо проблем будет сложнее.

Если у нас имется специальный коннектор для приёма анонимных сообщений от внутренних smtp-серверов, то его необходимо перенести на один из новых транспортных серверов, а внутренние smtp-сервера перенастроить на использование в качестве смарт-хоста нового транспортного сервера. Если список ip-адресов внутренних smtp-серверов будет велик, то вручную его переносить на новый коннектор будет затруднительно. Используем для этого EMS:

$connector = Get-ReceiveConnector "EX2007HTRelay"
Set-ReceiveConnector "EX2010HTRelay" -RemoteIPRanges $connector.RemoteIPRanges

Так как send-коннектор для старых транспортных серверов мы отключили, то можно удалять из нешней DNS-зоны MX-записи, ссылающиеся на старые сервера. Так же можно удалить существующие для них PTR-записи. Затем отключаем Receive-коннекторы на старых серверах. После этого старые транспортные сервера перестанут отправлять и получать почту из внешнего мира.

Осталось удалить A-записи для старых транспортных серверов и почистить от них существующую SPF-запись. Затем через Programs and Features запускаем программу удаления Exchange 2007 и удаляем роли Hub Transport и Client Access Server (ранее мы уже переключили клиентский доступ на новые сервера), а так же Exchange Management Tools.

После удаления последнего сервера с ролью Hub Transport/Client Access Server миграция будет считаться завершённой.

Предыдущие версии гипервизора от MS (идущие в комплекте с Windows 2008 и Windows 2008 R2) обрабатывали удаление снимков виртуальных машин достаточно криво – необходимо было сразу после удаления снимка выключать виртуальную машину. В процессе выключения данные из снимка объединялись с родительским файлом vhd или avhd. Понятно, что после удаления снимка выключать виртуальную машину не всегда было возможно. В итоге могло быть несколько удалённых снимков, которые так и не были объединены в родительский файл. И вот в этот момент слияние всех этих оставшихся файлов превращалось в настоящий квест.

Относительно недавно стал доступен дистрибутив для разработчиков следующей версии Windows Server со следующей версией гипервизора на борту. Вот тут в комментариях Александр Станкевич задал интересный вопрос – “Раз уж появились различные “живые сценарии”, то и слияние (Merge) дисков, после удаления Snapshot’ов, теперь будет выполняться без необходимости выключения виртуальной машины?”

Вроде бы пока я не видел чтобы это утверждение кто-то проверил – так что, возможно, буду первым.

Что у нас имеется – свежеустановленная операционная система Windows Server 8 Developer Preview с ролью Hyper-V. Далее подключаем её в качестве хоста к VMM 2008 R2 (подключается!) и заливаем из библиотеки виртуальную машину. Так получилось, что это оказалась Windows 2003. Далее ставим разное ПО чтобы можно было сделать пару снимков, которые бы друг от друга немного отличались. В итоге получаем следующее. Имеется 2 снимка:

Физически они все три состояния виртуальной машины представляют три файла:

Первый файл – 2003std86.vhd – представляет собой состояние виртуальной машины на момент создания снимка “with Outlook”, второй файл представляет собой изменение состояния виртуальной машины на момент создания снимка “win2003test”, ну и в третьем файле находится изменение состояния виртуальной машины на текущий момент со времени предыдущего снимка.

Логично предположить, что если мы будем удалять второй снимок – то в его файл должно вставиться изменение состояния виртуальной машины из третьего файла. Если будем удалять только первый снимок – то второй файл будет объединён с первым. Попробуем удалить снимок “win2003test”. После удаления в поле статуса виртуальной машины появится текст “Merge in Progress”:

По завершении объединения в папке виртуальной машины у нас будут находиться следующие файлы:

Видно, что третий файл был объединён со вторым, за счёт чего последний стал чуть больше. Ну и для закрепления удалим оставшийся первый снимок “with Outlook”. Опять в поле статуса виртуальной машины появится “Merge in Progress” и по завершении у нас останется только один файл:

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