Среди нововведений в Windows Server 8 – и новая версия гипервизора, Hyper-V 3.0, снабженная новыми возможностями. Виртуальные машины в Hyper-V 3.0 будут поддерживать больше 16 виртуальных процессоров, и бОльший объем оперативной памяти.

Судя по информации о возможностях новой версии-конкурента VMware vSphere 5, максимальное количество поддерживаемых виртуальных процессоров вряд ли будет меньше 32.

Также появилась интересная возможность Hyper-V Replica – возможность онлайновой репликации работающей виртуальной машины по сети на другой сервер, даже расположенный в удаленной локации. Все, что для этого требуется – сетевое соединение.

На скриншотах видеодемонстрации видно, что для создания реплики достаточно указать удаленный Hyper-V-сервер, на который будет производиться репликация, и выбрать тип аутентификации – как Windows Integrated, так и по сертификатам (что, возможно, позволит реплицировать виртуальные машины на хост, находящийся в совершенно отдельном лесу Active Directory, без доверенных отношений). Передаваемые по сети данные могут сжиматься. Также, можно выбрать, какие конкретно виртуальные диски нужно реплицировать.

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

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

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

Возможнось Hyper-V Replica не зависит от используемого железа, систем хранения и сетевых подключений, и является чисто программной. Вероятно, Hyper-V Replica схожа с технологией репликации, реализованной программными решениями DoubleTake, рассказ о которых еще предстоит в нашем блоге.

Полностью видео о Windows Server 8 и Hyper-V Replica можно посмотреть здесь, примерно на 37й минуте.

Итак, что же появляется нового в новой версии VMware vSphere 5?

• Основой и платной, и бесплатной версии продукта теперь является один гипервизор – ESXi. VMware делает упор на его небольшой размер и производительность.
• vSphere Auto Deploy – новая модель распространения гипервизоров на железо, и установки патчей. Распространение работает с использованием PXE-Boot, загрузки специально подготовленного образа и файлов ответов с профилем хоста на сервер, и автоматического подключения его к vCenter. Таким образом, можно быстро, по сети, установить группу хостов виртуализации.
• Новая версия виртуальной машины – Virtual Machine version 8, включающая в себя новое виртуальное оборудование – поддержку 3D графики, например для Aero (правда, без использования аппаратного ускорения), и устройства USB 3.0.
• В качестве гостевой операционной системы поддерживается Mac OS X Server 10.6 – правда, к сожалению, не везде, а только на определенном оборудовании Apple Xserve.
• Storage DRS – автоматическое распределение хранения виртуальных машин в зависимости от нагрузки на системы хранения.
• Обновление файловой системы VMFS5 – поддержка LUN-ов больше 2 Тб.
• Поддерживается vMotion поверх сетей с высокими задержками.
• Поддержка до 32 виртуальных процессоров и до 1 Тб памяти на виртуальную машину.
• vSphere Web Client – несмотря на использование гипервизора ESXi, к нему возможен доступ из браузера.
• vCenter Server Virtual Appliance – работа сервера vCenter в качестве виртуальной машины на базе Linux.
• Поддержка виртуальными машинами считывателей смарт-карт.
• Swap to SSD – возможность разместить файл подкачки на дисках SSD, что, из-за их скорости, может сделать привлекательнее и быстрее memory overcommit.

Новое в лицензировании:

• Уменьшилось количество редакций vSphere – исчезла редакция Advanced. Так что остались только Standard, Enterprise и Enterprise Plus. Интересно, что ряд новых возможностей vSphere 5, описанных выше, будет доступен только в самой дорогой vSphere Enterprise Plus.
• Исчез лимит процессорной лицензии на количество ядер – теперь процессорная лицензия покрывает неограниченное количество ядер в одном процессоре. Сделано явно «на вырост», к требованиям прогресса
• Также исчезло лицензионное ограничение на максимальный объем физической памяти на хосте, бывшее в версии 4.
• В лицензирование добавилось понятие vRAM Entitlement – покрываемый объем общей виртуальной оперативной памяти. То есть, в организации лицензированы должны быть не только используемые хостами VMware процессоры, но и объем памяти, занимаемый всеми запущенными виртуальными машинами на всех хостах. Каждая процессорная лицензия уже включает в себя некоторый объем vRAM – например, лицензия Enterprise Plus включает в себя 48 Гб vRAM. Если виртуальные машины превышают включенный в лицензии объем, то необходимо приобретение дополнительных лицензий. Например, если есть два хоста виртуализации, каждый с одним процессором, но на каждом хосте виртуальными машинами используется по 60 Гб оперативной памяти – то две лицензии Enterprise Plus на процессор суммарно дадут объем vRAM только 96 Гб, что не покрывает общий объем в 120 Гб виртуальных машин, и потребуется докупка лицензий.
• Бесплатный гипервизор включает в себя vRAM entitlement только 8 Гб, то есть, бесплатно можно будет запустить виртуальных машин только на 8 Гб оперативной памяти суммарно.
• Проверка на соответствие vRAM Entitlement не является жесткой – только в версиях vSphere Essentials существует жесткое ограничение, не позволяющее превысить vRAM и запустить машин больше, чем лицензировано. В остальных версиях VMware будет ограничиваться срабатыванием Alert-а о том, что инфраструктура не соответствует лицензированию.

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

Если мы говорим об обычных телефонах, определить местоположение звонящего несложно – определяем, с какого номера / порта он звонит, и знаем (по таблице портов), где он находится. Гораздо интереснее, когда речь заходит об IP-телефонии. Клиент IP-телефонии (а особенно Lync) не привязан к конкретному месту – он может сегодня залогиниться с этого компьютера, через 10 минут, работая по WiFi, уйти в другой конец здания, или вообще, сидеть подключенным из дома через Edge Server или даже VPN.

Поэтому задача автоматического определения местоположения становится гораздо интереснее.

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

Одним из компонентов роли Front-End сервера Lync является служба Location Information Server. Location Information Server получает данные от пользователя, и в зависимости от настроенных параметров, определяет его местонахождение. Управляется Location Information Server исключительно из PowerShell – в графической консоли управления Lync данных опций нет.

Команды PowerShell, относящиеся к серверу местоположений, имеют вид *-CsLis*, с префиксом LIS.

Сервер LIS определяет местоположение пользователя, сравнивая полученные от него данные со своей базой данных – хранящейся на back-end сервере пула, в SQL-базе данных lis. Соответственно, базу требуется заполнить правильными данными.

Сервер LIS при определении местоположения учитывает следующие данные, возвращаемые пользователем:

• Его IP-адрес, а если точнее, IP-подсеть
• BSSID беспроводной точки доступа, если клиент Lync подключен к сети по WiFi
• Порт коммутатора, если клиент Lync подключен к сети проводом
• MAC-адрес коммутатора

Также, если клиент подключен по VPN, это тоже будет учтено при обработке местоположения.

Информация о беспроводных точках доступа заносится командой Set-CsLisWirelessAccessPoint, о коммутаторах – Set-CsLisSwitch, о портах коммутаторов – Set-CsLisPort, и о подсетях – Set-CsLisSubnet.

Примечание: BSSID – это беспроводной MAC-адрес конкретной точки доступа, выглядящий как шесть байт – точно так же, как MAC-адрес сетевой карты или коммутатора. Несколько точек доступа могут иметь одно имя сети (SSID), но они всегда будут иметь разный BSSID.

Например, мы знаем, что у нас есть некая беспроводная точка доступа с BSSID 01-02-03-04-05-06, которая расположена в здании офиса по адресу Москва, Нагорный проезд, дом 7Б, на четвертом этаже. Добавим информацию об этой точке и ее местоположении в базу Location Information Server:

Set-CsLisWirelessAccessPoint -BSSID 01-02-03-04-05-06 -Description "Точка доступа 4 этаж" -Location "Четвертый этаж" -CompanyName "ООО НашаМегаКомпания" -HouseNumber 7 -HouseNumberSuffix "Б" -StreetName "Нагорный" -StreetSuffix "проезд" -PreDirectional "" -PostDirectional "" -City "Москва" -Country "RU"

После внесений изменений в базу LIS эти изменения необходимо опубликовать:

Publish-CsLisConfiguration

Пример выполнения такой команды приведен на скриншоте:

Теперь, когда клиент Lync подключится в сеть, будучи подключенным к этой беспроводной точке доступа – в клиенте автоматически появится строчка «Четвертый этаж», которую мы задали в поле Location. Ну а если клиент будет подключен не к этой беспроводной точке – строчки местоположения автоматически не появится

Например, в моем Lync автоматически отобразилось, что в момент, когда был сделан этот скриншот, я нахожусь в офисе:

Решение на данный момент: деинсталлировать апдейт 2449742. Ждем какого-нибудь исправления от Microsoft.

UPD: Проблема признана командой разработчиков Exchange, пока решение то же – не ставить данный апдейт.

UPD 2: Проблема решена, Microsoft выпустил исправление.

Для Windows Server 2008 R2:

• Windows6.1-KB977020-v2-x64.msu – 0,6 Мб.
• Windows6.1-KB979099-x64.msu – 2,2 Мб.
• Windows6.1-KB979744-x64.msu – 6,5 Мб.
• Windows6.1-KB982867-v2-x64.msu – 4,4 Мб.
• Windows6.1-KB983440-x64.msu – 3,5 Мб.
• FilterPack64bit.exe – 3,9 Мб.

Для Windows Server 2008:

• Windows6.0-KB973136-x64.msu – 0,7 Мб.
• Windows6.0-KB977592-x64.msu – 0,3 Мб.
• Windows6.0-KB977624-v2-x64.msu – 3,2 Мб.
• Windows6.0-KB979744-x64.msu – 6,5 Мб.
• Windows6.0-KB979917-x64.msu – 3,5 Мб.
• Windows6.1-KB983440-x64.msu – 3,5 Мб.
• FilterPack64bit.exe – 3,9 Мб.

Update: совсем забыл указать требуемые для установки роли Unified Messaging компоненты:

• UcmaRuntimeSetup.exe – 16 Мб.
• SpeechPlatformRuntime.msi – 2,8 Мб.

Например, если зайти в окно библиотеки документов, и выбрать пункт «Создать документ», а затем попытаться сохранить его, то откроется следующее окно:

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

При этом, если открыть существующий документ из SharePoint и сохранить его, либо указать в имени файла полный путь с именем – например, http://шарепойнт/имя_библиотеки/файл.docx, то сохранение произойдет. То есть, имеется проблема с отображением web-папок.

Решение: нужно выполнить следующих два шага:

Скачать и установить обновление Microsoft для web-папок по адресу http://www.microsoft.com/downloads/details.aspx?displaylang=ru&FamilyID=17c36612-632e-4c04-9382-987622ed1d64 (ссылка дана для русского Office, в случае других языков необходимо выбрать нужный). Не обращайте внимания, что в списке предназначенных операционных систем указаны только Windows XP и Windows 2003 – именно это обновление и нужно устанавливать на Windows 7.

Затем, установить для ярлыка вызова Microsoft Word в меню «Пуск» настройку совместимости «Запускать в режиме совместимости – Windows XP с пакетом обновления 3″. Только в этом случае окно сохранения документов изменится в стиле Windows XP и будет отображать библиотеки SharePoint:

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

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

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

1. Развертывание отдельного леса, с именем например myocs.local
2. Установка доверия между доменами
3. Развертывание OCS в лесу myocs.local
4. Создание в этом лесу учетных записей-заглушек для пользователей основного домена
5. Наслаждение работой с объединенными коммуникациями 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.

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

Создавать объекты и переносить атрибуты, конечно, можно и вручную – но это неинтересно и долго. Как я уже упомянул, в 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, и работать!

Для обеспечения более сильной защиты применяется так называемая многофакторная аутентификация – то есть, аутентификация из нескольких шагов. Отличным примером средства многофакторной аутентификации являются смарт-карты, или другие устройства, схожие со смарт-картами, например, USB-ключи eToken.

Несомненное достоинство ключа eToken перед смарт-картой – он не требует специального считывателя, а просто вставляется в свободный порт USB.

Аутентификация по смарт-карте или ключу может использоваться при входе в Windows, при подключении к VPN или RDP, при подключении к Outlook Web App.

Требуется только, чтобы на компьютере пользователя находился драйвер для смарт-карт или USB-ключей.

Например, при входе в Outlook Web App – вместо окна ввода логина и пароля выводится запрос на выбор сертификата:

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

Выбрав сертификат, пользователю необходимо ввести лишь пин-код для доступа к смарт-карте или USB-ключу. И – все, авторизация пройдена! Таким образом, смарт-карта является полной заменой логину и паролю, используемому при обычной аутентификации.

Использование смарт-карты при аутентификации на рабочую станцию в Windows регулируется групповой политикой, и так же политикой регулируется поведение системы при убирании смарт-карты из считывателя (или USB-ключа из порта). Система может никак не реагировать на вытаскивание смарт-карты, может автоматически блокировать (Lock) сеанс пользователя до установки смарт-карты обратно, и может завершать (Logoff) сеанс пользователя.

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

Source: MSExchange Unified Messaging
Event ID: 1185
Task Category: UMCore
The Unified Messaging server failed to submit a message to Hub Transport server 'EXCHANGE' due to the following error: Unexpected server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

Source: MSExchange Unified Messaging
Event ID: 1423
Task Category: UMCore
A pipeline stage encountered the following error. Details : 'Microsoft.Exchange.UM.UMCore.SmtpSubmissionException: Submission to the Hub Transport server failed. The operation will be retried. ---> Microsoft.Exchange.Net.ExSmtpClient.UnexpectedSmtpServerResponseException: Unexpected SMTP server response. Expected: 220, actual: 500, whole response: 500 5.3.3 Unrecognized command

   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.CheckResponse(ServerResponseInfo response, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.Command(SmtpChunk[] chunks, SmtpCommandType command, Int32 expectedCode)
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpTalk.StartTls()
   at Microsoft.Exchange.Net.ExSmtpClient.SmtpClient.Submit()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.SubmitMessage()
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   --- End of inner exception stack trace ---

Server stack trace:
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.HandleTransientSmtpFailure(Exception e, InternalExchangeServer smtpServerToUse)
   at Microsoft.Exchange.UM.UMCore.SmtpSubmitStage.InternalDoSynchronousWork()
   at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
   at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)

Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
   at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.SynchronousWorkDelegate.EndInvoke(IAsyncResult result)
   at Microsoft.Exchange.UM.UMCore.SynchronousPipelineStageBase.EndSynchronousWork(IAsyncResult r)'

Роли Hub Transport и Unified Messaging находятся на одном и том же сервере, но тем не менее, голосовое сообщение, оставленное пользователем, в ящик получателя не попадает.

Из приведенных ошибок видно, что при попытке установления SMTP-соединения служба Hub Transport выдает ответ, что команда не распознана. По подробной информации видно, что ошибка возникает в процессе работы процедуры StartTls, то есть имеет место быть неудачная попытка установки шифрованного соединения.

Ошибка возникла из-за следующей тонкости:

Сам сервер внутри сети называется EXCHANGE.имя-домена. А опубликован в Интернет он под именем MAIL.имя-домена. Соответственно, в процессе настройки в Receive Connector захотелось внести изменения, чтобы при подключении сервер отвечал не своим внутренним именем, а внешним, отличающимся от внутреннего. Но – при несовпадении FQDN, предоставляемого в ответ на HELO или EHLO, и системного имени сервера, отказывается работать включенная по умолчанию аутентификация Exchange Server authentification. Соответственно, эта галочка и была выключена.

А если выключена Exchange Server authentication – то в ответ на команду EHLO сервер в списке допустимых команд НЕ ВЫВОДИТ команду X-ANONYMOUSTLS, и не отвечает на нее. А службы Unified Messaging пытаются установить соединение с Hub Transport именно этим способом.

Решение: в нашем случае помогло включение обратно пункта Exchange Server authentication, смена выдаваемого FQDN в окне Receive Connector обратно на внутреннее имя сервера, и перезапуск служб MSExchange Hub Transport и MSExchange Unified Messaging.

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

В преддверии выхода нового сервера мы открываем сайт, посвященный объединенным коммуникациям Microsoft – www.ocs2010.ru. А подробнее о новых возможностях нового продукта можно прочитать здесь – http://www.ocs2010.ru/2010/03/24/anonsirovany-vozmojnosti-ocs-2010/

UPDATE: Окончательное наименование нового программного продукта – Lync Server 2010.