IT-блог компании "ЛанКей" » office communications server 2007 r2

Развертывание OCS 2007 R2 в отдельном лесу

Ярослав Никифоров — Fri, 09 Apr 2010 12:32:31 +0000

Как известно, Office Communications Server 2007 R2 всю свою информацию хранит в Active Directory, и при развертывании он изменяет лес AD – расширяет схему, создает новые атрибуты пользователей. Бывают случаи, когда изменение схемы Active Directory основного леса нежелательно – а тем не менее, развернуть и использовать OCS надо, и хочется использовать все прелести объединенных коммуникаций.

Для решения такой задачи существует специальное развертывание Office Communications Server, называемое развертыванием в ресурсном лесу (resource forest). Это значит, что параллельно с существующим у нас основным лесом и доменом мы можем развернуть совершенно отдельный лес, в котором и будет располагаться OCS. Это решение поддерживается Microsoft и описано в паре англоязычных документов, ну а чтобы не отсылать читателя к ним, мы расскажем по-русски, как это сделать.

Пусть у нас есть некий основной домен с пользователями, называющийся например mycompany.ru. Соответственно, пользователи имеют e-mail-адреса логин@mycompany.ru, пользуются Outlook’ом, Exchange (неважно каким, но лучше конечно 2007/2010 ).

Развертывание OCS в ресурсном лесу будет состоять из следующих шагов:

Развертывание отдельного леса, с именем например myocs.local
Установка доверия между доменами
Развертывание OCS в лесу myocs.local
Создание в этом лесу учетных записей-заглушек для пользователей основного домена
Наслаждение работой с объединенными коммуникациями Microsoft

Шаг 1 – развертывание отдельного леса

Для отдельного леса нам понадобится один компьютер, который будет служить контроллером домена этого леса. Конечно, в идеале их должно быть как минимум два, но поскольку мы рассматриваем тестовый вариант – можно ограничиться одним компьютером. И, конечно, для удобства это будет виртуальная машина, запущенная под управлением Hyper-V на Windows Server 2008 R2.

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

Итак, мы установим компьютер операционной системой Windows Server 2008 R2, назовем его dcrf, и промотируем его до домен-контроллера. При создании домена укажем, что это новый домен нового леса. А домен назовем myocs.local.

Уровень домена/леса должен быть не ниже 2003 – так требует OCS. Поскольку ресурсный лес будет обслуживаться только этим контроллером – смело ставим уровень леса в Windows Server 2008 R2.

Я использую для контроллера именно Windows Server 2008 R2, потому что в нем есть встроенные коммандлеты для управления Active Directory, что очень поможет нам на шаге 4, при создании пользователей-заглушек с информацией из основного домена.

Так как нам необходимо, чтобы между доменами было доверие – то контроллеры доменов dc.mycompany.ru и dcrf.myocs.local должны находить друг друга. Поэтому следующим шагом будет соответствующая настройка DNS – создадим на DNS-сервере dcrf.myocs.local форвардинг на IP-адрес контроллера dc.mycompany.ru, а на DNS-сервере dc.mycompany.ru – conditional forwarding для домена myocs.local на IP-адрес dcrf.myocs.local.

На этом же сервере развертывается Enterprise Root Certification Authority, который будет использован для выдачи сертификатов для серверов OCS.

Шаг 2 – настройка доверия между доменами

После того, как мы добьемся, что оба домена друг друга увидят – разрешат имена серверов, можно настраивать доверие.

Достаточно создать 1-way trust от ресурсного домена к основному – то есть, ресурсный домен доверяет логиниться к себе пользователям из основного. Открываем AD Domains and Trusts на dcrf.myocs.local, и создаем External Trust, 1-way outgoing, до домена mycompany.ru. И, соответственно, на контроллере dc.mycompany.ru создаем External Trust, 1-way incoming.

Итог – мы создали ресурсный лес, и установили доверие с основным рабочим доменом.

Шаг 3 – развертывание OCS в ресурсном лесу

Далее, совершенно обычным образом развертываем Office Communications Server 2007 R2 на серверах в ресурсном лесу. Я назвал такие сервера ocsse.myocs.local и ocsmed.myocs.local, на которых будут развернуты Standard Edition и Mediation Server соответственно. Edge-сервер нам не потребуется – все пользователи будут авторизоваться посредством доверия между доменами, с помощью обычных своих учетных данных.

Установим мы серверы на для удобства тоже на виртуальных машинах – но уже само виртуальные машины будут содержать Windows Server 2008. Поскольку Office Communications Server 2007 R2 не очень хорошо работает на Windows Server 2008 R2, придется использовать предыдущую версию операционной системы.

При установке OCS крайне важно указать следующее – в качестве домена для установки мы выбираем домен myocs.local. А в качестве SIP-домена мы указываем домен mycompany.ru. Это необходимо, поскольку мы хотим, чтобы SIP-адреса пользователей совпадали с их email-адресами, то есть, относились бы к домену mycompany.ru.

Я не буду расписывать подробно установку OCS, настройку и связь с VoIP-шлюзом - это можно найти в соответствующих статьях на этом же блоге.

Главное, что нужно изменить после инсталляции OCS – указать в параметрах Front-End сервера Standard Edition тип авторизации пользователя - только NTLM.

Это важно, поскольку стоящая по умолчанию настройка – Kerberos and NTLM – не позволит авторизоваться пользователям основного домена.

В результате мы получаем два сервера Office Communications Server 2007 R2 в ресурсном лесу, и следующим нашим шагом будет создание пользователей-заглушек.

Шаг 4 – создание и синхронизация информации о пользователях

Поскольку пользовательские учетные записи располагаются в основном домене, а OCS-у требуется, чтобы у него были свои учетные записи, со списком контактов и соответствующими параметрами – необходимо создать отключенные пользовательские аккаунты в домене myocs.local, для которых будут храниться настройки Office Communications Server. А для того, чтобы не приходилось дублировать и синхронизировать пароли – необходимо обеспечить взаимосвязь между действующим аккаунтом пользователя в основном домене, и отключенным аккаунтом пользователя в ресурсном лесу.

Известно, что основным идентификатором пользователя в домене является его SID – Security Identifier. После установки OCS (и соответствующего расширения схемы AD) в ресурсном лесу у объекта пользователя присутствует специальное поле msRTCSIP-OriginatorSID – нам необходимо записать в него SID пользователя из основного домена. Таким образом, в ресурсном лесу у пользователя будет два SID-а – один обычный, относящийся к ресурсному лесу, и второй, который мы занесем вручную – SID пользователя из основного рабочего домена.

Ну и конечно, для того, чтобы в контакт-листе Communicator отображалась полноценная информация о пользователе – необходимо указать имя и фамилию пользователя, его телефон, должность, и e-mail.

Общая таблица атрибутов , которые нам необходимо перенести из основного домена для пользователя, выглядит следующим образом:

читаем из основного домена	пишем в ресурсный домен	что это за атрибут
cn	cn	Имя объекта в AD
objectSID	msRTCSIP-OriginatorSID	SID объекта
telephoneNumber	telephoneNumber	Телефон
displayName	displayName	Полное имя
givenName	givenName	Имя
Surname	Surname	Фамилия
physicalDeliveryOfficeName	physicalDeliveryOfficeName	Офис
l	l	Город
Country	Country	Страна
Title	Title	Должность
Mail	Mail	Адрес e-mail
Company	Company	Название компании

Создавать объекты и переносить атрибуты, конечно, можно и вручную – но это неинтересно и долго. Как я уже упомянул, в Windows Server 2008 R2 есть коммандлеты PowerShell, которыми я и воспользуюсь.

Вот простейший скрипт, от которого можно отталкиваться в собственных случаях:

$srcdc = "dc.mycompany.ru" # исходный домен
$srcbase = "OU=Domain users,DC=mycompany,DC=ru" # OU, который сканируем на предмет пользователей
$dstdc = "dcrf.myocs.local" # ресурсный домен
$dstbase = "OU=OCS Users,DC=myocs,DC=local" # OU, в котором будут созданы объекты-заглушки.
New-PSDrive -Name DstAD -Root "" -Server $dstdc -PSProvider ActiveDirectory -Cred MYOCS\Administrator # подключаемся к ресурсному домену с правами администратора, который может создавать объекты.
New-PSDrive -Name srcAD -Root "" -Server $srcdc -Cred MYCOMPANY\user -PSProvider ActiveDirectory # подключаемся к исходному домену с правами просто пользователя, который может хотя бы читать данные из исходного AD.
cd srcAD:
$usrs = get-ADUser -SearchBase $srcbase -Filter * -Properties mail # выбираем всех пользователей в указанном OU.
cd dstAD:
foreach ($u in $usrs) {
   echo $u.name
   New-ADUser -Path $dstbase -DisplayName $u.Name -Name $u.name -GivenName $u.GivenName -Surname $u.Surname -SamAccountName $u.samAccountName -OtherAttributes @{'mail'=$u.mail;'msRTCSIP-OriginatorSid'=$u.SID} # создаем пользователя, указывая для него необходимые аттрибуты. Пользователь создается отключенным - Disabled.
}
cd c:
remove-psdrive srcad
remove-psdrive dstad

Этот скрипт не совсем полный – он не переносит должности, название компании, город и офис. Мне это было не нужно - но это всегда можно дописать самостоятельно

Можно заметить, что в ресурсном домене мы создаем пользователей, не указывая для них пароли. Это действительно неважно – так как пользователи будут авторизоваться по своим собственным учетным данным в основном домене, а затем уже просто сопоставляться с отключенными аккаунтами в ресурсном лесу.

После создания пользователей-заглушек мы обычным образом включаем их – Enable for Office Communications Server, и настраиваем – Configure for Office Communications Server.

В основном домене необходимо будет сделать лишь одно изменение – добавить в атрибут proxyAddresses пользователей адрес вида sip:логин@mycompany.ru. Это необходимо для того, чтобы при запуске Communicator пользователю не приходилось бы вручную указывать свой SIP-адрес для входа. Сделать это можно с помощью ADSI Edit, с помощью Email Address Policy в Microsoft Exchange, или написать свой скрипт – как угодно.

Шаг 5 – запускаем и работаем

Все! теперь можно смело ставить на клиентские компьютеры Office Communicator. Также необходимо импортировать на клиентские компьютеры сертификат того корневого центра сертификации, который использовался при создании сертификатов для серверов OCS. В нашем случае это сертификат с центра сертификации dcrf.myocs.local. Импортировать этот сертификат нужно в раздел «Доверенные корневые центры сертификации».

Конечно, необходимо добавить в DNS-зону mycompany.ru записи sip.mycompany.ru и _sipinternaltls._tcp.mycompany.ru – подробнее смотрите в статье по установке и настройке Office Communications Server 2007 R2.

После этого можно смело запускать Office Communicator, и работать!

Итоги семинара ЛанКей по новым серверным решениям.

Сергей Ерин — Sun, 28 Mar 2010 20:11:01 +0000

Итак, 19 марта 2010 года состоялся семинар ЛанКей по новым серверным решениям – спасибо всем, кто присутствовал! Семинар посетили более 40 человек и надеюсь, что никто не пожалел о том, что пришёл! (Судя по заполненным анкетам, в основном, семинар всем понравился ) Посетители узнали о новых возможностях и преимуществах для бизнеса таких продуктов, как Windows Server 2008 R2, Exchange Server 2010, Office Communications Server 2007 R2, а также решениях GFI.

Для тех, кто по каким-то причинам не смог посетить семинар, мы решили выложить видеозаписи докладов:

Доклад по Windows Server 2008 R2:

Доклад по Exchange Server 2010:

Доклад по Office Communications Server 2007 R2:

Доклад по GFI:

Также, вы можете отдельно скачать сами презентации:

Презентация Windows Server 2008 R2

Презентация Exchange Server 2010

Презентация Office Communications Server 2007 R2

Презентация GFI: Часть 1, Часть 2.

Внимание! Все материалы презентаций являются собственностью компаний LanKey, Microsoft и GFI. Без письменного разрешения владельцев запрещается частичное или полное копирование и публикация любых материалов данных презентаций.

Централизованное заполнение контакт-листов в Office Communicator

Ярослав Никифоров — Fri, 18 Dec 2009 01:36:15 +0000

В процессе развертывания Office Communications Server в организации, и, соответственно, развертывания пользователям Office Communicator, мы сталкиваемся с одной неприятной особенностью. Любой пользователь, запустивший Communicator в первый раз, увидит пустой контакт-лист, и ему придется добавлять другие контакты в список вручную. А он чаще всего хочет обратного – чтобы он сразу видел список своих коллег.

Дело в том, что контакт-листы в Office Communicator хоть и хранятся на сервере, но вовсе не заполняются автоматически, как, например offline address book в Exchange. А заполнять контакты вручную ни пользователь, ни (тем более) администратор не хотят и не имеют времени. Следовательно, рассмотрим вопрос, как нам автоматизировать такую задачу.

Вообще есть два способа организации контакт-листов – мы можем добавить контакт, например, по его SIP-адресу. Либо – мы можем создать на сервере distribution-группу, в которую уже будут добавлены различные контакты, и добавить пользователю эту группу рассылки. Каждый вариант имеет свои плюсы и минусы, и каждый вариант добавляет определенной работы администратору в случае появления в организации нового сотрудника

Способ №1 – добавление в контакт-лист отдельных контактов

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

Добавляются пользователи в контакт-лист следующим образом:

Открываем на сервере Office Communications Server программу cmd и переходим в каталог C:\Program Files\Microsoft Office Communications Server 2007 R2\ResKit\WMI Samples\. Как – что значит, у вас нет этого каталога? Вы до сих пор не поставили OCS Resource Kit? Бегом ставить!
В этом каталоге лежит скрипт LCSAddContacts.wsf, который нас и интересует. Для его работы нужно создать два текстовых файла – один файл со списком пользователей, которых мы добавляем, второй файл со списком пользователей, к кому в контакт-листы мы добавляем пользователей из первого файла. Назовем первый файл contacts.txt, а второй – users.txt. Файлы должны содержать всего лишь SIP-адреса, по одному на строчку, например:sip:user01@domain.com sip:user02@domain.com sip:user03@domain.com
Запускаем на выполнение нужный скрипт следующей командой:
cscript LCSAddContacts.wsf /usersfile:файл_списка_пользователей /contactsfile:файл_списка_контактовв нашем случае эта команда будет выглядеть так:
cscript LCSAddContacts.wsf /usersfile:users.txt /contactsfile:contacts.txt

Можно дописать еще аргумент /contactsgroup:имя_группы – тогда контакты будут добавлены не в группу «Все контакты», а в группу с указанным именем.

Ну а еще можно дописать аргумент /delete – тогда перечисленные в файле контакты будут не добавлены, а удалены из контакт-листов указанных пользователей.

Способ №2 – использование групп рассылки

Помимо контакта мы можем добавить в контакт-лист группу рассылки. Это даст нам несколько очевидных преимуществ, но и несколько очевидных минусов. Плюсы – контакты пользователя сразу организованы по группам. Когда в организации появится новый сотрудник, нам всего лишь надо добавить его в нужную distribution-группу в Active Directory, и он (при следующем обновлении адресной книги) окажется в контакт-листах пользователей самостоятельно.

Минусы такого подхода тоже присутствуют. Например – клиент не может ни добавить, ни удалить пользователя из группы рассылки – само собой, это можно сделать, только изменив состав группы средствами Active Directory. Также в качестве групп рассылки, которые можно добавить в Communicator, не поддерживаются динамические группы рассылки Exchange. А жаль – как было бы удобно например, создать динамический список рассылки «Все», и добавить его пользователям! А в дальнейшем даже не заморачиваться добавлением свежезаведенного пользовательского аккаунта ни в какие группы рассылки.

Еще одним существенным минусом добавления групп рассылки в контакт-лист пользователя является то, что автоматизированного средства, подобного используемому в вышеприведенном примере №1, в поставке OCS не присутствует. На помощь пришел написанный товарищем Sver и выложенный на форумы TechNet собственный скрипт – за что ему (или ей) огромное спасибо.

Важное условие использования скрипта – группа должна быть distributed, и группе должен быть присвоен адрес e-mail, по которому она и добавляется в контакт-лист. Проще всего использовать те же самые группы рассылки, которые используются и в Exchange.

Вот текст скрипта – назовем его LCSAddGroups.wsf:








LCSAddGroups.wsf

This WMI script progmatically adds Distribution Lists for LCS Users.

Обратите внимание – в процедуре AddContactGroups нужно прописать необходимое количество строчек вызова, указав имя добавляемой группы (как оно будет отображаться в Communicator), и e-mail адрес группы рассылки.

Далее. Для вызова данного скрипта необходимо подготовить файл списка пользователей, которым мы добавляем данные группы. Файл должен быть таким же, как и для примера №1 – один SIP-адрес на одной строчке.

Затем – запускаем скрипт:

cscript LCSAddGroups.wsf /UsersFile:файл_список_пользователей

После отработки можно запускать Communicator и увидеть свежедобавленные группы с пользователями.

Установка разрешения видео в Microsoft Office Communicator

Ярослав Никифоров — Fri, 06 Nov 2009 22:37:27 +0000

Мы знаем, что для того, чтобы определить максимальное качество видео, разрешенное участникам видеозвонков в Office Communications Server, нужно задать параметр на закладке Video в настройках сервера Front-End.

Но, кроме этого, ограничение на максимальное качество видеокартинки задается и на клиенте – ключом реестра.

Вообще Office Communicator имеет такую интересную особенность, что в нем невозможно принудительно задать использование определенного видеоразрешения – можно лишь ограничить его сверху, или «порекомендовать», выбрав большой или маленький размер видео в окне звонка. И даже в таком случае, качество видео будет варьироваться прямо по ходу разговора, адаптируясь к скорости сети и мощности процессора.

За задание максимально разрешенного размера видеокартинки на клиенте ответственна ветка реестра HKEY_CURRENT_USER\Software\Microsoft\RTC\Quality, а именно – два находящихся в ней ключа типа DWORD – MaxAllowedSendVideoSize, и MaxAllowedReceiveVideoSize. Как следует из названия, первый ключ ограничивает максимальное качество отправляемой удаленному абоненту видеокартинки, второй ключ – максимальное качество принимаемой от удаленного абонента видеокартинки. Эксперименты показали, что ключи эти могут принимать следующие значения:

«MaxAllowedSendVideoSize»=dword:00000001 «MaxAllowedReceiveVideoSize»=dword:00000001	Качество видео – только CIF (352×288)
«MaxAllowedSendVideoSize»=dword:00000002 «MaxAllowedReceiveVideoSize»=dword:00000002	Качество видео – до VGA (640×480)
«MaxAllowedSendVideoSize»=dword:00000004 «MaxAllowedReceiveVideoSize»=dword:00000004	Какой-то очень странный режим, сильно вытянутый по горизонтали – уж не картинка ли для RoundTable?
«MaxAllowedSendVideoSize»=dword:00000008 «MaxAllowedReceiveVideoSize»=dword:00000008	Качество видео – до HD (1280×720)

Кстати, по умолчанию этих ключей, да и всей ветки, в реестре нет – нужно ее создать. После задания этих ключей необходимо перезапустить Communicator.

Повторюсь – эти ключи не задают точный формат видео – задается лишь максимально разрешенный к использованию. Реальное качество картинки может меняться в течение разговора в зависимости от скорости сети и мощности процессора. Ну и конечно, вышеуказанные ключи влияют только на качество видеозвонка один на один – при конференции с тремя и более участниками качество видео всегда CIF (352×288).

Эксперименты показали, что видеозвонок в HD-качестве очень неплохо так загружает процессор компьютера – например, Core2 Duo 3,06 GHz в течение HD-звонка почти все время загружен на 80-85%.

Интеграция OCS 2007 R2 и Google Talk / Jabber

Ярослав Никифоров — Fri, 16 Oct 2009 22:35:15 +0000

Известно, что пользователи Office Communications Server 2007 R2, используя Office Communicator, могут общаться не только друг с другом, но и с клиентами других систем обмена сообщениями – AOL (и официальным ICQ), MSN Live Messenger, Yahoo – этот процесс называется федерация (federation). Пользователи видят таких клиентов в своем списке контактов, видят их состояние присутствия (так же, как и федеративные пользователи видят их состояние), и могут обмениваться текстовыми сообщениями.

Теперь количество интегрируемых с OCS систем увеличилось. Первого октября команда разработчиков Office Communications Server выпустила бесплатное дополнение для OCS 2007 R2 – XMPP Gateway, сервер для федерации с системами, работающими по протоколу Jabber – а это, например, Google Talk, или известный в России QIP.

Сервер XMPP Gateway устанавливается в сети периметра – той же самой, где находится сервер Edge. Сосуществовать с другими ролями OCS эта роль не может – для нее нужен отдельный сервер (или виртуальная машина). И, несмотря на то, что роль называется Gateway – она требует для работы лишь один сетевой интерфейс. Главное – чтобы XMPP Gateway мог связаться с сервером Edge по TCP-порту 5061, и с другими Jabber-серверами в Интернете по TCP-порту 5269. Второго мы можем добиться, например опубликовав порт 5269 на нашем внешнем firewall.

Обязательное требование к серверу XMPP Gateway – что он не должен быть членом домена, в котором развернут Office Communications Server. Рекомендуется, чтобы этот сервер просто принадлежал какой-либо рабочей группе.

Давайте попробуем развернуть эту роль и на практике посмотреть, как же можно связать пользователей Communicator и Google Talk:

Коротко о Jabber

Давайте сначала разберемся, как работает протокол XMPP.

По своей сути протокол – это специально сформированные сообщения в формате XML. Клиенты XMPP общаются с сервером по порту 5222. Серверы общаются между собой по порту 5269. Для того, чтобы два сервера могли обмениваться информацией между собой, используется так называемый Dialback – первый сервер подключается ко второму по порту 5269, и второй сервер устанавливает встречное соединение с первым, тоже на порт 5269.

Поскольку XML-сообщения это по сути открытый текст – протокол позволяет шифровать передаваемый межсерверный трафик по протоколу TLS.

Поиск нужного сервера

Если пользователь хочет отправить сообщение на адрес someuser@somedomain.ru – сервер выполняет DNS-запрос на получение записи типа SRV с именем _xmpp-server._tcp.somedomain.ru. Ответ DNS-сервера и содержит имя Jabber-сервера (или серверов) домена somedomain.ru, и порт, к которому нужно произвести подключение.

Структура сети

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

У нас есть контроллер домена DC, он же центр выдачи цифровых сертификатов, сервер OCS (Standard Edition), сервер EDGE (типа Consolidated Edge, все три роли на одном. Самое главное – что на нем есть Access Edge). Расположим в сети периметра сервер JABBER. Пользователи нашего OCS имеют SIP-адреса из домена, скажем, external.ru.

Сервер Access Edge имеет сетевое имя sip.external.ru.

Установка сервера JABBER

Установим на нем 64-битный Windows 2003 или 2008 – я остановился на 2003 R2 Datacenter. Оставляем этот сервер в рабочей группе, и припишем в настройках имени компьютера DNS-суффикс external.ru – чтобы его полное имя совпадало с тем, какой сертификат мы ему выдадим.

Связь сервера JABBER с сервером EDGE будет проходить по зашифрованному каналу – следовательно, оба сервера должны иметь сертификаты. Импортируем сертификат корневого центра сертификации DC в соответствующее хранилище сервера JABBER, и выдадим этому серверу сертификат шаблона Web Server на полное имя компьютера – jabber.external.ru. На сервере EDGE сертификат на имя sip.external.ru сертификат уже присутствует с момента развертывания OCS.

Установка XMPP Gateway

Скачаем с сайта Microsoft Download Center дистрибутив XMPP Gateway и запустим его. Сам дистрибутив программу не установит, а лишь разархивируется в каталог C:\Program Files\Microsoft Office Communications Server 2007 R2\XMPP Installer. Куда мы зайдем и запустим setup.exe.

Первый пункт установки развернет нам файлы приложения. После него нужно настроить IP-адрес для шлюза. Находим файл C:\Program Files\Microsoft Office Communications Server 2007 R2\XMPP Gateway\TGWConsoleGUI.dll.config и открываем его Блокнотом.

Впишем в него IP-адрес сервера JABBER, в два параметра. Первый параметр – для адреса, к которому будет получать доступ сервер EDGE. Второй параметр – для адреса, к которому будут получать доступ внешние серверы из Интернета. Для нас это один и тот же адрес, допустим, 192.168.1.222:

Сохраняем файл и возвращаемся в программу установки.

Второй шаг запустит программу настройки. Эта же программа будет доступна в дальнейшем через ярлык в Administrative Tools. Кстати, при любом изменении в этой программе необходимо рестартовать службу Office Communications XMPP Gateway.

Настройка программы – параметры доступа к OCS

Первый раздел программы слева – SIP Configuration, то есть связка с OCS. На первой закладке в поле Domain нужно указать SIP-домен организации, то есть в нашем тестовом случае, external.ru. В поле Host Name указывается имя сервера EDGE – в нашем случае, это sip.external.ru.

Нажимаем кнопку Save.

На второй закладке нужно выбрать сертификат для TLS-шифрования трафика с сервером EDGE. Выбираем ранее полученный нами сертификат на имя сервера jabber.external.ru.

На третьей закладке можно выбрать домен и убедиться, что сервер JABBER подключается к серверу EDGE.

Внимание: проверяется только возможность подключения, то есть доступность сервера по IP-адресу. Никакой трафик, вроде авторизации и так далее, не передается, то есть информация об успехе подключения всего лишь говорит что сервер нам доступен, а не то что он действительно работает правильно.

Настройка программы – параметры XMPP Configuration

В закладке Allow list мы указываем, с какими именно Jabber-доменами мы хотим «дружить», и методику связи с ними – в частности, следует ли использовать TLS или достаточно простого TCP подключения. Сервер gmail.com для Google Talk в отличие от многих других может работать и без TLS.

В поле Domain Name вводим домен, с пользователями которого мы хотим связываться – в нашем случае это gmail.com. Метод подключения выбираем TCP Dialback – то есть, без сертификатов и шифрования. Нажимаем OK – и домен появляется в списке.

На второй закладке мы ничего не указываем – потому что мы выбрали подключение без шифрования.

На третьей закладке мы можем проверить доступность серверов gmail.com.

Так же, как и раньше, проверяется только возможность подключения.

Раздел Settings можно не настраивать, оставив все по умолчанию.

Теперь можно вернуться в программу установки и нажать Start services.

Настройка сервера EDGE

Теперь, для того, чтобы наш EDGE знал, куда следует переадресовывать запросы на адреса для Jabber, нужно открыть оснастку управления на сервере EDGE, выбрать свойства сервера и найти закладку Allow.

На этой закладке нажимаем Allow и вписываем – домен gmail.com, и хост, на который нужно переадресовывать запросы – у нас это jabber.external.ru.

Естественно, нужно позаботиться о том, чтобы сервер EDGE знал, как найти IP-адрес сервера JABBER – например, указав его в файле hosts.

Настройка внешнего DNS

Как я говорил ранее, не только мы устанавливаем соединение с другим Jabber-сервером – и этот сервер должен установить еще одно соединение с нами. Для этого он должен нас найти.

Открываем консоль внешнего DNS-сервера, обслуживающего наш SIP-домен, и создаем там запись типа А для сервера JABBER – я назвал его xmpp.external.ru. Так как порт 5269 моего сервера я просто опубликовал на аппаратном firewall – то для этой записи A я указываю IP-адрес firewall-а.

Создаем еще одну запись, типа SRV, с именем _xmpp-server._tcp – именно по ней нас и найдут внешние сервера. Укажем порт 5269 и хост xmpp.external.ru – тот, который мы прописали чуть выше.

Проверка

Все! Настройка закончена. Если все прошло как надо, все нужные порты и записи присутствуют и службы запущены – мы можем добавить в Communicator запись с gmail-а, и увидеть статус присутствия, написать сообщения и даже получить ответ

Пользователь Google Talk в свою очередь увидит наш статус присутствия и тоже сможет нам писать.

Послесловие

Как можно видеть на картинке выше, в моем Communicator присутствуют еще записи из доменов qip.ru и jabber.ru, без состояния присутствия. Дело в том, что эти сервера требуют обязательного шифрования трафика по TLS – а значит, нужно будет присвоить серверу xmpp.external.ru сертификат, причем от публичного центра сертификации. Так что – продолжение экспериментов следует

После обновления Windows не запускается Office Communications Server

Ярослав Никифоров — Thu, 15 Oct 2009 07:16:16 +0000

14 октября была выпущена очередная порция критических обновлений операционных систем от Microsoft. Но после их установки на серверы Office Communications Server или Live Communications Server службы OCS/LCS не запускаются.

Проблема в обновлении KB974571 – «MS09-056: Vulnerabilities in CryptoAPI could allow spoofing». После установки этого обновления службы Front-End, Access Edge не запустятся.

Например, для Office Communications Server 2007 R2 в журнале событий появляются записи:
Event Type: Error Event Source: OCS Server Task Category: (1000) Event ID: 12290 Description: The evaluation period for Microsoft Office Communications Server 2007 R2 has expired. Please upgrade from the evaluation version to the full released version of the product.

Event Type: Error Event Source: OCS Server Task Category: (1000) Event ID: 12299 Description: The service is shutting down due to an internal error. Error Code: C3E93C23 (SIPPROXY_E_INVALID_INSTALLATION_DATA) Resolution: Check the previous event log entries and resolve them. Restart the server. If the problem persists contact product support.

Решение: если вы еще не разворачивали обновления – не устанавливайте обновление KB974571. Если уже установили – деинсталлируйте это обновление.

Поскольку данное обновление имеет статус «Критическое» – его установка в дальнейшем крайне желательна. Ожидаем разрешения проблемы и свежего обновления от Microsoft.

Клиент Office Communications Server для iPhone

Ярослав Никифоров — Thu, 27 Aug 2009 13:06:31 +0000

Случилось интересное – полку клиентов для Office Communications Server прибыло! Появился клиент для Apple iPhone, зовущийся iDialog, уже доступный для покупки через AppStore.

iDialog требует для работы iPhone или iPod с прошивкой 2.0 или выше. Поддерживается работа с OCS 2007 и OCS 2007 R2, как с корпоративной, так и с hosted-инфраструктурой. Взаимодействие клиента и серверов OCS происходит через роль Communicator Web Access Server.

Возможности:

Отображается список контактов и групп со статусами присутствия, возможен поиск по контакт-листу и GAL.
С контактами можно обмениваться короткими сообщениями. Можно добавлять нескольких пользователей в разговор.
Если мы через контакт-лист можем видеть телефон контакта – мы можем инициировать телефонный вызов на этот номер.
Выводится уведомление о входящем вызове, и доступно управление этим вызовом – перенаправление на телефонный номер (хоть на этот же iPhone) или голосовую почту.
Возможна отправка e-mail выбранному контакту – если настроена электронная почта на iPhone.
Звонки по SIP не поддерживаются, видео тоже, удаленный рабочий стол тем более .

Вот скриншоты с официального сайта клиента – http://www.modalitysystems.com/idialog/:

Группы списка контактов	Список контактов
Поиск по списку контактов	Обмен короткими сообщениями
Просмотр информации о контакте	Просмотр информации о контакте
Управление входящим вызовом

Цена клиента составляет 10$.

Так что теперь устройств, работающих совместно с Office Communications Server становится все больше!

Пример развертывания Office Communications Server 2007 R2 – часть 4

Ярослав Никифоров — Mon, 17 Aug 2009 11:05:53 +0000

В предыдущих частях мы развернули Office Communications Server для компьютерных пользователей. Теперь подошло время начать потихоньку интегрировать его с телефонией.

За интеграцию с телефонией (с теми АТС, которые не умеют напрямую работать с OCS) отвечает специальная роль, называемая Mediation Server. Mediation Server занимается преобразованием звукового потока из форматов G.xxx в формат Microsoft RTAudio – собственный кодек Microsoft. А между Mediation Server и ATC будет находиться VoIP-шлюз.

Развертывание Mediation Server

Выделим серверу MEDIATION две сетевые карты. Одной сетевой картой он будет подключен к локальной сети – назовем это соединение Local, и присвоим соответствующий IP-адрес. Второй сетевой картой сервер будет подключен к VoIP-шлюзу. Я не выделял отдельного коммутатора, а подключал напрямую патчкордом. Назовем это соединение VoIP, и соответственно присвоим IP-адрес из подсети, определенной нами для VoIP-шлюза. Поскольку согласно заводским настройкам IP-адрес шлюза 10.1.10.10/16, то мы, не особо фантазируя, назначим сетевой карте адрес 10.1.10.1 и маску 255.255.0.0. DNS никакого не указываем. Чтобы не загружать соединение с шлюзом лишним ненужным трафиком – отключим на нем NetBIOS over TCP.

Вводим сервер MEDIATION в домен, и запускаем на нем программу установки Office Communications Server. Дополнительных ролей от сервера не потребуется. Выбираем Deploy other server roles – Deploy mediation server.

Install files for Mediation server – развертываем файлы на жесткий диск. Затем запускаем активацию сервера. Указываем пароль для существующей учетной записи службы (она у нас создалась на этапе развертывания сервера OCS). После активации данные о сервере появились в AD, но сам сервер еще не запущен – ему не сопоставлены сертификаты и не настроены адреса шлюза и сервера OCS.

Следующий шаг выполняется не из мастера установки, а из консоли настройки Office Communications Server 2007 R2. Можно конечно установить административные утилиты и на сервер MEDIATION, но, я думаю, это не имеет смысла – мы все будем конфигурировать централизованно. Поэтому переключаемся на сервер OCS и на консоль управления Office Communications Server.

В разделе Mediation Servers после обновления должен появиться наш свежеразвернутый сервер. Щелкаем на нем правой кнопкой и выбираем Properties.

В открывшемся окне мы указываем параметры, которые нужны серверу MEDIATION чтобы найти остальные серверы.

В поле Communications Server listening IP – мы указываем адрес той сетевой карты, которая подключена к локальной сети. В поле Gateway listening IP – мы указываем адрес той сетевой карты, которая подключена к сети VoIP-шлюза. В полях A/V Edge Server и Location profile мы пока ничего не указываем – потому что внешнего сервера еще пока нет, и голосовой профиль мы не конфигурировали.

Переходим на следующую страницу.

В поле FQDN мы пишем полное имя сервера OCS. Порт, по которому MEDIATION будет с ним связываться, оставляем неизменным – мы изначально на сервере OCS его не меняли. В поле PSTN Gateway Address вписываем IP-адрес VoIP-шлюза. Проверяем, что порт и метод подключения (TCP или TLS) соответствуют шлюзу. Мы шлюз не перенастраивали, поэтому оставляем эти поля как есть. Нажимаем OK. Соглашаемся с тем, что мы не указали Edge Server, location profile, и с тем, что изменения вступят после перезапуска Mediation Server.

Возвращаемся назад на сервер MEDIATION. Выбираем следующий шаг, запрашиваем и назначаем серверу сертификат на этот сервер.

После назначения сертификата возвращаемся в консоль управления на сервер OCS и запускаем сервер Mediation.

Сервер запустился. Правда, пока от него толку нет, потому что не настроена самая важная вещь – голосовая политика.

Голосовая политика организации

Голосовая политика определяет план нумерации в организации, определяет маршруты при звонках на городские номера, и, поскольку с точки зрения OCS, имеющиеся внутренние номера телефонов организации – тоже внешние, то политика определяет и методику связи с ними.

Допустим, у нас есть внешний телефонный номер +7 (495) 788-80-43, привязанный к АТС. Есть существующие телефоны, трехзначная нумерация – номера от 100 до 200. Выход в город производится через 9. Соответственно, междугородние звонки – 9-8-код города-телефон.

Мы хотим сделать, чтобы набранные в OCS трехзначные номера соединяли бы нас с внутренними абонентами, набранные семизначные – с городскими в коде города 495, начинающиеся с 8 – с междугородними или федеральными, и начинающиеся с + тоже звонили бы в город.

В соответствии с этим мы и начинаем планировать политику.

Запускаем консоль управления Office Communications Server, щелкаем правой кнопкой по Forest – Properties – Voice properties. На закладке Location Profiles щелкаем Add.

Важная тема – это название Location Profile. Если мы хотим нормально проинтегрировать OCS и Exchange UM – нам нужно правильно назвать Location Profile. Location Profile должен быть обязательно вида имя_профиля.имя_нашего_домена. Требования к пункту имя_профиля – такие же, как к любому корректному имени DNS – латинские буквы, цифры, без пробелов. Этот же идентификатор в дальнейшем будет использоваться как имя Exchange UM Dial Plan. Например, корректным в нашем случае будет назвать профиль – moscow.uc.ru.

Кроме имени профиля мы заносим более удобочитаемое имя в поле Display Text. Затем нам надо добавить Normalization Rules.

Правила нормализации

Именно Normalization Rules определяют телефонные номера, которые могут вводить пользователи OCS, и то, как они будут обрабатываться. Чуть выше мы вывели несколько желаемых исходящих маршрутов – на трехзначные номера в офисе, на семизначные в Москве, на федеральные и междугородние. Вот теперь и будем создавать такие правила нормализации.

Правила нормализации вводятся в виде исходное выражение - целевое выражение. Выражения записываются в виде .NET Regular Expresson. Полностью синтаксис я расписывать не буду – он есть в MSDN – а покажу его на примере наших маршрутов.

Первый маршрут – назовем его 3-digits – будет отвечать за дозвон на трехзначные номера телефонов, от 100 до 200. Сами трехзначные номера никак преобразовывать не надо – надо передавать на АТС в том же самом виде, в котором они были набраны.
Исходным выражением будет: ^(\d{3})$
Результатом будет: $1

Поясню, что делает это выражение. Начинаем обрабатывать входящий номер с начала – символ ^. После этого проверяем, есть ли три цифры – символ \d обозначает цифру от 0 до 9, а {3} – появление цифры три раза. После скобок идет признак конца строки – $. То есть, например, номер из четырех или двух цифр под это правило нормализации не подойдет.
Результатом преобразования будет $1 – то есть, то, что выбрано между скобок – без изменений. А между скобок у нас попадает три цифры – значит, результатом правила будет телефонный номер в три цифры, точно такой же, как и набранный. Он и будет впоследствии передан на АТС.

Казалось бы, зачем нам правило преобразования, которое ничего не преобразовывает? Но – если мы его не создадим, то Office Communications Server вообще не поймет, что надо обратить внимание на набранный телефонный номер из трех цифр, и скажет нам – мол, извини, ты набрал номер, о котором я ничего не знаю.

Параметры для первого правила нормализации заданы. Пункт Internal enterprise extension мы не включаем, а Use translation… не отключаем.

Вторым правилом будет обработка семизначного набранного номера. Опять нажмем Add для Normalization Rules.

Семизначный набранный номер должен быть передан на нашу АТС и стать исходящим вызовом в Москву. Раз это внешний номер – приведем его к стандартному виду, с кодом страны и города.
Исходным выражением будет: ^(\d{7})$
Результирующим выражением будет: +7495$1

То есть, к набранному семизначному номеру мы присоединяем спереди код страны и города Москвы. Например, набранный 7888043 станет +74957888043. При этом, замечу, что для OCS абсолютно все равно, вводится ли номер сплошными цифрами, или с пробелами, или с дефисами или скобками.

Третьим правилом нормализации мы создадим преобразование номеров вида 8-123-4567890 – указании вместо восьмерки кода страны +7.
Исходное выражение будет: ^8(\d{10})$
Результирующее выражение: +7$1

Вот мы и создали три правила нормализации, необходимые нам для обработки вызовов. Теперь необходимо привязать к Location Profile еще и маршруты. У нас с вами один Mediation Server, поэтому все внешние вызовы пройдут через него.

Переходим на закладку Routes и добавляем маршруты:

Первый назовем 3-digits. Выражение Target regular expression будет как и выше, ^(\d{3})$
В качестве шлюза укажем наш сервер mediation.uc.ru.

Второй будет для звонков по России (и Москве, раз мы преобразовали семизначный московский номер в международный формат +7495номер). Результирующее выражение будет: ^\+7(\d{10})$
Обращаю внимание, что знак + мы для порядка экранируем обратным слэшем. Шлюзом будет все тот же Mediation Server.

Третьим маршрутом добавим для разнообразия звонки в США. Результирующее выражение будет: ^\+1(\d{10})$
Шлюзом будет все тот же Mediation Server.

Пример развертывания Office Communications Server 2007 R2 – часть 3

Ярослав Никифоров — Mon, 17 Aug 2009 10:29:35 +0000

Итак, продолжим. Теперь на очереди – развертывание Office Communications Server 2007 R2.

Развертывание Office Communications Server 2007 R2

Мы развернем три сервера OCS 2007 R2 – один основной сервер OCS, один сервер сопряжения с телефонией MEDIATION, и сервер внешнего доступа EDGE.

Напомню, что версия 2007 R2 является только 64-битной, и может ставиться на Windows 2008 – чем мы и воспользуемся.

Сетевые настройки и подготовка

Присоединяем сервер OCS в домен uc.ru.
Перед установкой Office Communications Server 2007 R2 устанавливаем следующие серверные роли: Web Server, Remote Admin Tools\Active Directory Domain Services, и Message Queuing, включая Directory Service Integration.

Установка Office Communications Server 2007 R2

Установка – процесс, состоящий из последовательных шагов, которые запускаются из мастера установки Office Communications Server 2007 R2. Удостоверяемся, что мы вошли на сервер OCS под пользователем UC\Administrator, являющимся администратором домена и леса.
Запускаем инсталляцию, ставим необходимые пререквизиты – VC Redistributable и .NET Framework.
Открываем раздел Deploy Standard Edition Server.

Подготовка Active Directory

Перед установкой Office Communications Server, так же как и Exchange, должен подготовить под себя схему Active Directory. Запускаем Prep Schema. Указываем местоположение файлов схемы – по умолчанию из дистрибутива. Запускаем загрузку схемы.

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

Затем запускаем Prep Forest. Указываем местоположение настроек – либо в разделе конфигурации каждого домена, либо в корневом домене. Хранение в каждом домене увеличит трафик репликации, но зато не потребуется постоянная доступность корневого домена. Хранение в корневом домене Так как у нас домен ровно один, он же корневой – нам все равно, и мы выбираем Configuration Partition.

Подтверждаем, что мы создаем группы для домена uc.ru. Далее, проверяем, что в качестве SIP-домена тоже указан uc.ru. Запускаем создание групп.
После создания групп в домене с несколькими глобальными каталогами необходимо дождаться, чтобы группы среплицировались на все глобальные каталоги. Так как у нас контроллер один, он же единственный глобальный каталог – мы ждать не будем.
Затем запускаем шаг Prep Current Domain. Этот шаг назначит полномочия в домене созданным в предыдущем шаге группам.
Следующим шагом можно делегировать административные полномочия каким-нибудь группам или пользователям. Казалось бы, если мы будем настраивать все из-под пользователя Administrator – у нас и так максимальные полномочия. Но это не совсем верно - по умолчанию пользователь Administrator не включается в группу RTCUniversalServerAdmins, что не позволит нам например настраивать Response Group. Поэтому идем в Active Directory Users and Computers, и включаем Administrator’а в группу RTCUniversalServerAdmins.

Развертывание сервера

Запускаем мастер Deploy Server.
Мастер спросит нас, какие из дополнительных компонент сервера Standard Edition мы хотим поставить на этот сервер. Среди них, в частности, Response Group. Так как нам нет причин себя ограничивать – мы ставим все эти компоненты.

Для работы служб Office Communications Server 2007 установка создаст в домене необходимые службы – у нас есть возможность или выбрать ранее созданные учетные записи, или разрешить создать новые.
Далее требуется указать внешний адрес web-сервера или серверов – так как у нас нет внешних серверов, мы ничего не указываем.

Так как устанавливаемый нами сервер – Standard Edition, то программа установки развернет на этом же сервере SQL Server Express Edition, запросив у нас желаемое местоположение файлов базы.

Начальная конфигурация сервера

Запускаем мастер Configure Server. На этом этапе у нас есть возможность добавить или изменить SIP-домены. SIP-домен может отличаться от домена AD в том случае, если например, внутри организации имя домена org.local, а внешние e-mail-адреса все в домене org.ru. Мы наверняка захотим, чтобы SIP-адреса пользователей совпадали с их e-mail-адресами, поэтому имя SIP-домена нужно указать правильно. В нашем случае это не надо, оставляем SIP-домен uc.ru.

Далее указывается, каким образом клиенты будут находить информацию для автоматического входа. Мы оставим настройку по умолчанию – использование DNS. Затем включим домен uc.ru как поддерживающий авто-вход.

Далее, пока откажемся от настройки доступа для внешних пользователей – мы сделаем это позже.

Настройка сертификатов

Очень важную роль в работе Office Communications Server 2007 R2 играют сертификаты – так как все коммуникации, проходящие через Office Communications Server 2007 R2, шифруются и подписываются сертификатами.
Запускаем шаг Configure Certificate. Создадим новый запрос и отправим его в наш доменный CA. Длину ключа желательно указывать не больше 1024 бита – так рекомендовано для Office Communications Server. Сертификат по умолчанию помечается как экспортируемый – чтобы мы смогли его перенести на другой сервер в случае поломки этого.
Заполняем поля Organization, Organizational Unit, State, City. Можно видеть, что в поле Subject Alternate Name указано имя sip.uc.ru, для универсального нахождения сервера с клиентов.
После отправки запроса и получения сертификата от CA необходимо назначить его серверу, нажав на кнопку Assign.

Настройка сертификата для Web-сервера

Данный сертификат надо сгенерировать вручную. Это можно сделать через IIS Manager – Server Certificates, или через оснастку MMC Certificates (Local Computer) – Request New Certificate.

Открываем IIS Manager, находим Default Web Site, открываем Properties, и закладку Directory Security. Нажимаем на Server Certificate. Запускаем мастер по выдаче сертификатов, аналогичный предыдущему шагу.

Выбираем немедленную отправку запроса в CA, указываем имя для сертификата, длину ключа (по умолчанию 1024 бита), заполняем как и ранее поля организации.

В качестве Common Name необходимо указать полное имя сервера – ocs.uc.ru.

В завершении подтверждаем порт защищенного сайта – 443, и имя CA, куда отправляется запрос.

Запуск Office Communications Server 2007 R2

Выбираем Start Services для запуска всех служб.
Проверку настроек сервера мы запускать не будем, так как пока не активированы пользователи, не настроена голосовая политика и DNS.

Настройка DNS

Для того, чтобы клиенты могли пользоваться авто-входом, не указывая постоянно имя сервера, необходимо создать соответствующие записи в внутреннем DNS.
На сервере DC запускаем консоль управления DNS, и открываем зону uc.ru нашего домена.
Выбираем Other New Records… – Service Location (SRV)
Указываем службу _sipinternaltls, протокол _tcp, приоритет 0, номер порта – стандартный 5061, и имя хоста – полное имя сервера Office Communications Server – ocs.uc.ru. Важно, чтобы имя хоста завершалось точкой после .ru.

Данная запись укажет внутренним клиентам, использующим протокол TLS, на сервер входа.
Такая запись в домене должна быть только одна, поэтому если серверов несколько, настраивается Load Balancer. У нас один сервер, поэтому запись на него и указывает.

Установка административных утилит

Особенностью Office Communications Server 2007 R2 является то, что по умолчанию с установкой сервера административные утилиты не ставятся. Не зная этого, можно долго медитировать на меню Start – Administrative Tools, выискивая, куда подевалась нужная программа.

Для их установки нужно в оболочке Autorun, откуда мы запускаем все шаги по установке ролей сервера, щелкнуть по пункту Install administrative tools в правой части окна.

Настройка Office Communications Server 2007 R2

Необходимо разрешить пользователям использовать аудио и видео через Office Communications Server 2007 R2. Для этого запускаем оснастку управления Office Communications Server 2007 R2 из Administrative Tools.
Щелкаем правой кнопкой на Forest – uc.ru, и выбираем Properties – Global Properties. Выбираем закладку Meetings. Для политики по умолчанию Default Policy нажимаем Edit…

Включаем web conferencing, IP audio и IP video. Также разрешаем dial-in conference – возможность по телефону дозвониться и войти в конференцию, и требование ввода при этом пин-кода.

Включение пользователей

Включение возможностей OCS для пользователей производится через оснастку Active Directory Users and Computers, измененную при установке Office Communications Server. Поэтому ее надо запускать с сервера OCS, так как мы не устанавливали такие расширения на сервер DC, и не увидим там необходимых закладок для пользователя.

Запускаем Active Directory Users and Computers. Находим пользователей, и выбираем для них Enable users for Communications Server.

Выбираем сервер, к которому привязываем пользователей – он у нас один.
Затем выбираем, каким образом генерировать SIP-адрес для пользователей – проще всего, чтобы он совпадал с адресом e-mail. Запускаем создание.

Затем для тех же пользователей выбираем Configure Office Communication Users. Включаем для пользователей все возможности – federation, remote access, public IM, enhanced presence. Затем включаем Enterprise Voice, и запускаем изменение.

Пример развертывания Office Communications Server 2007 R2 – часть 2

Ярослав Никифоров — Mon, 17 Aug 2009 09:13:08 +0000

Продолжаем наши игры . На очереди – развертывание Exchange 2007 SP1.

Развертывание Exchange 2007 SP1

Мы развернем простейшую инфраструктуру Exchange, объединив четыре доменных роли Client Access, Hub Transport, Mailbox и Unified Messaging на одном сервере – EXCHANGE.

Сетевые настройки

Отключим протокол IP6 и Windows Firewall. Присоединим сервер EXCHANGE к домену uc.ru.

Подготовка к установке Exchange 2007 SP1

Исходя из того, что мы будем развертывать все 4 доменные роли Exchange 2007 SP1 на этом сервере, мы устанавливаем следующие роли сервера:

Web Server – устанавливаем все дополнительные службы, исключая только службу FTP. Автоматически установится Windows Process Activation Service.
.NET Framework 3.0 Features.
Desktop Experience.
Remote Server Administration Tools – Active Directory Domain Services Tools.
Windows PowerShell.

После установки всех ролей перезагружаем сервер.

Подготовка леса и домена

Удостоверяемся, что мы вошли на сервер EXCHANGE под пользователем UC\Administrator, который является Scheme Admin. Запускаем установку Exchange 2007 SP1 в режиме подготовки леса:

Setup.com /ps

Программа установки подготовит схему Active Directory для Exchange 2007 SP1.

Setup.com /p /on:UniCom

Программа установки создаст соответствующие служебные объекты в текущем домене.

После завершения создания объектов необходимо удостовериться, что все эти объекты среплицировались на все контроллеры нашего домена.

Данный шаг подготовки домена необходимо выполнять для всех доменов, в которых так или иначе будет использоваться Exchange 2007 – размещены сервера либо находятся пользователи. Но так как у нас и домен один, и контроллер один – мы данный шаг выполняем всего один раз, и не проверяем репликацию.

Установка Exchange 2007 SP1

После подготовки Active Directory запускаем инсталляцию Exchange 2007 SP1.
Выбираем для установки четыре доменные роли: Mailbox, Client Access, Hub Transport и Unified Messaging. Запускаем процесс установки.
По завершении установки перезагружаем сервер.

Конфигурация сертификатов для Exchange 2007 SP1

Необходимо получить сертификат из доменного CA, чтобы присвоить его на службы Exchange, вместо самоподписанного сертификата, создаваемого по умолчанию.
Запускаем Exchange Management Shell. Получаем список используемых Exchange сертификатов:

Get-ExchangeCertificate | ft services,thumbprint,isselfsigned -auto

В полученном списке видим, что основные службы Exchange используют самоподписанный сертификат.

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

New-ExchangeCertificate –GenerateRequest –DomainName exch.uc.ru,exch –FriendlyName exch.uc.ru –PrivateKeyExportable:$true –keysize 1024 –path C:\certreq.txt

Полученный запрос мы должны отдать CA: открываем Internet Explorer, и вводим https://dc.uc.ru/certsrv/
Выбираем Request Certificate – Submit Advanced Request – Submit a Request…
Вставляем в поле текст из файла, сгенерированного командой New-ExchangeCertificate. Выбираем Template – Web Server, и нажимаем Submit.
Скачиваем результирующий сертификат, выбрав пункт Download Certificate, и сохраняем его в файл C:\certnew.cer
Открываем опять Exchange Management Shell, и импортируем получившийся сертификат в хранилище сертификатов сервера:

Import-ExchangeCertificate –Path C:\certnew.cer | Enable-ExchangeCertificate –Services IIS,POP,IMAP,UM,SMTP

Теперь снова получаем список всех сертификатов, отмечаем, какой имеет статус SelfSigned и сопоставлен со службами, и удаляем его:

Remove-ExchangeCertificate

Настройка пользователей и групп

Включаем для созданных пользователей и Distribution групп почтовые ящики.
Unified Messaging настроим позднее, после установки Office Communications Server 2007 R2.