Меню Рубрики

Установка lync edge server

welcometoviktorp

Установка Lync. Edge часть 2

После, того как Lync Front End сервер был установлен пришло время разворачивать Edge.

Инсталляция Edge сервера практически ничем не отличается от инсталляции других ролей, изначально необходимо определить эту роль в топологии, настроить локальное хранилище, где будет храниться топология и синхронизировать информацию с Central Management Store. Разница состоит в том, что Lync Edge не входит в домен AD и по этому топологию в процессе инсталляции роли нужно будет копировать вручную. Еще одна особенность заключается в том, что Edge сервер подключен к инфраструктуре с помощью двух сетевых адаптеров. Один сетевой адаптер «внутренний» подключен к внутренней сети, второй сетевой адаптер «внешний» подключен к сети DMZ или напрямую к сети Интернет.

Настройку Edge сервера начнем с настройки «внешнего» сетевого адаптера. На данный сетевой адаптер будет натироваться трафик с внешнего сетевого адаптера TMG.

Прежде всего в свойствах адаптера можно отключить следующие опции:

-Client for Microsoft Networks

File and Printer Sharing for Microsoft Networks

Register this connection’s addresses in DNS

Сетевые настройки следующие:

«внутренний» сетевой адаптер напрямую подключен во внутреннюю сеть.

Сетевые настройки следующие:

Так как маршрут по умолчанию настроен на «внешнем» сетевом адаптере для того, чтобы трафик маршрутизировался во внутреннюю сеть или сети, необходимо добавить статически маршруты ко всем подсетям, где размещены серверы и клиенты Lync.

Route add -p 172.16.30.0 mask 255.255.255.0 172.16.30.1

Разрешение имен серверов осуществляется через внутренний сервер DNS 172.16.30.2.

После настройки сетевых адаптеров необходимо указать в Primary DNS Suffix FQDN сервера Edge: edge-lync.xxx.lync и добавить в зону DNS xxx.lync запись типа A edge-lync.xxx.lync.

Сервер Edge был добавлен в топологию при настройке Fron End в первой части

Для того, чтобы скопировать топологию на Edge сервер, ее изначально экспортируют в архив ZIP с помощью Lync Power Shell и копируют файл на сервер Edge, он будет нужен на этапе инсталляции.

Export-csconfiguration –filename c:\topology_export.zip

Осталась непосредственно инсталляция роли Edge.

Как и для роли Front End необходимо выполнить инсталляцию NET. Framework 3.5.1

После этого можно запускать помощник развертывания Lync 2010 и переходить в раздел Install or Update Lync Server System

Первое, что нужно сделать как обычно — установить Local Configuration Store:

В процессе инсталляции, указать экспортированный файл topology_export.zip

Далее осталось установить файлы Lync

В процессе установки компонентов Lync у меня возникло предупреждение: WARNING! Host not found in topology. По этому поводу у Microsoft существует KB: http://support.microsoft.com/kb/2500649 и после исправления FQDN в Primary DNS Suffix проблема была решена.

Перед тем, как начать настройку сертификатов нужно, импортировать сертификат центра сертификации RootECA в локальное хранилище компьютера Local Computer-> Trusted Root Certification Authorities.

Процесс запроса сертификатов начинается с запуска помощника

Запрос сертификата для внутреннего интерфейса Edge сервера. Сертификат можно запрашивать Online указав центр сертификации dc\RootECA и учетные данные администратора.

Далее сертификат назначается.

Запрос сертификата для внешнего интерфейса Edge выглядит идентично. В ходе запроса можно будет добавить еще одно имя sip.xxx.lync, которое будет использоваться клиентами Lync для автоматического входа без использования SRV и Phone Lync.

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

P.S. Репликация между CMS и Edge серверов происходит с помощью HTTPS 4443, у других серверов Lync по SMB.

Для проверки можно выполнить следующие шаги:

1. Запустить на Front End сервере: invoke-CsManagementStoreReplication edge-lync.xxx.lync

2. Запустить Get-CsManagementStoreReplicationStatus

Результат должен быть похож на скриншот ниже

После того, как инсталляция сервера Lync Edge завершена, необходимо разрешить удаленным пользователям подключаться к Lync. Для этого в Lync Control Panel->External User Acceess проверьте две настройки.

источник

welcometoviktorp

Разворачиваем Lync 2013. Установка lync Edge 6

Для чего нужен сервер Edge?

Сервер Edge необходим для подключений внешних клиентов к инфраструктуре Lync без VPN соединений. Обычно внешние клиенты подключаются к серверу Edge через общедоступную сеть «Интернет». Фактически Edge является проксирующим сервером, когда внешние клиентские подключения терминируются на сервере Edge и далее перенаправляются на внутренние Lync серверы или клиенты.

В проекте были запланированы подключения к инфраструктуре Lync внешних клиентов из сети «Интернет», не планировалась федерация с другими организациями и с публичными IM. Так же допускалась возможность балансировки нагрузки внешнего трафика, поэтому ниже указана информация с учетом проектных требований. Единственное допущение которое было сделано, это количество серверов Edge, на тестовом полигоне развернут один сервер по причине нехватки ресурсов, хотя требования и таблицы составлены с учетом нескольких серверов Edge.

Edge сервер состоит из нескольких ролей(сервисов), которые выполняют определенные задачи.

Единая точка подключение входящего и исходящего трафика протокола SIP.

Возможность подключения внешних клиентов к собраниям системы Lync.

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

Обмен сообщениями протокола XMPP с федеративными партнерами XMPP.

Основные требования для серверов Edge

Все требования для серверов Edge можно найти на TechNet, я отмечу те требования, которыми руководствовался я на этапе проектирования Edge.

Сетевые требования

  • 2 сетевых адаптера. Один сетевой адаптер служит для внешних подключений, второй – для внутренних.
  • Трафик «внешнего» и «внутреннего» сетевых адаптеров не должен маршрутизироваться (http://technet.microsoft.com/en-us/library/gg412847.aspx)
  • Трафик входящий и исходящий для внутреннего сетевого адаптера Edge не поддерживает NAT.

*Рекомендация – минимум 3 внешних IP-адреса для внешних подключений. Для двух серверов Edge, использующих балансировку DNS должно быть выделено 6 внешних IP-адресов. Так же можно использовать и один IP адрес, но при этом для внешних подключений будут использоваться нестандартные порты, что может вызвать проблемы подключений на стороне клиентов.

Шлюз по умолчанию указывается на «внешнем» адаптере Edge и ручным способом на сервере Edge указываются все подсети где находятся внутренний серверы Lync и клиенты.

Требования к DNS

На TechNet дана рекомендация использования DNS серверов для Edge в зоне DMZ, чаще всего этого сервиса там нет, поэтому рекомендуется использовать внешний DNS сервер и в HOSTS указать необходимые хосты из внутренней сети. Я в нарушении этой рекомендации использовал внутренний DNS.

Требования к сертификатам

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

Балансировка нагрузки

Основное требование – тип балансировки для «внутреннего» и «внешнего» сетевых адаптеров должен быть одинаковым. В качестве балансировки нагрузки можно использовать DNS или HLB.

Требования к портам

Требования к портам указаны в таблице 6.3

Описание сетевой инфраструктуры

В компании Заказчика для обслуживания сетевой инфраструктуры центрального офиса (ЦО) развернут один брандмауэр, к которому подключены все сети ЦО. Упрощенная диаграмма представлена на рисунке 6.1

Рисунок 6.1. Диаграмма сетей, подключенных к брандмауэру

Сеть DMZ Internal создана для того, чтобы выполнялись сетевые требования для сервера Edge.

Internet – DMZ External->NAT

DMZ Internal->Internal -> Routing.

Таблицы 6.1 и 6.2 с сетевыми настройками брандмауэра и сервера Edge представлены ниже

Необходимо определить какой IP адрес будет прикреплен к ролям Edge сервера, в данном примере распределение будет следующим см. рисунок 1.1:

  • Access Edge – IP№6
  • Web Conf Edge — IP№7
  • A/V — IP№8

Соотвестветнно трансляция NAT на брандмауэре должна быть настроена примерно следующим образом:

Требования к портам

*Требования для сетевых адптеров представлены в двух закладках документа

  1. НастройкаDNS, создание записей дляEdge, настройка суффиксаDNS для сервераEdge.
  2. Настройка сети на сервереEdge
  3. Создание сертфикатов и копирование на серверEdge.
  4. Создание топологии и копирование файла с настройками топологии на серверEdge
  5. Установка компонентLync 2013 на сервереEdge
  6. Включение возможности подключения внешних пользователей к серверу Edge.

Настройка DNS, создание записей для Edge, настройка суффикса DNS для сервера Edge

Записи DNS должны быть созданы заранее. Суффикс DNS для сервера Edge настраивается в том же разделе где и имя компьютера:

Настройка сети на сервере Edge

Для настройки сети необходимо настроить два сетевых адаптера и указать статические маршруты к сетям где находятся клиенты и серверы Lync.

Создание сертфикатов и копирование на сервер Edge

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

Создание топологии и копирование файла с настройками топологии на сервер Edge

Октываем Topology Builder и запускаем мастер создания нового пула Edge серверов.

Указать название пула серверов Edge (в случае балансировки DNS, для внутренних адаптеров должно быть несколько записей в DNS вида: LyncPoolEdge01.uc.loc = IP1(Edge 01 сервер),LyncPoolEdge01.uc.loc = IP2(Edge02 сервер) и т.д.)

Указать следующие настройки:

— Будет ли пул Edge серверов использовать единственный IP

— Используется ли федерация

— Используется ли XMPP федерация

На сетевых адаптерах сервера Edge были настроены только IP адреса версии IPv4

Указать DNS-имена для сервисов Edge

Указать именование сервера в пуле и IP-адрес «внутреннего» адаптера.

Указать IP-адреса, настроенные на внешнем сетевом адаптере сервера Edge для его ролей.

Указать внешний IP(тот который на сетевом оборудовании) с которого будет транслироваться трафик на A/V Edge.

Указать с каким серверов Front будет работать пул серверов Edge

После этого останется только опубликовать топологию и сделать экспорт в файл и скопировать на сервер Edge.

Export-CsConfiguration -FileName topology.zip

Установка компонентов Lync на сервер

Операция идентичная, той что была проделана при установке Front End, необходимо последовательно пройти все шаги (step1-step4)Единственное отличие это в первом шаге(Install Local Configuration Store) необходимо указать файл топологии.

Так же при назначении сертификатов не будет возможности OAuth, этот протокол поддерживается только «внутренними» серверами.

Проверка репликации между серверами Front End и Edge

Для того, чтобы понять что синхронизация между Front End и Edge работает можно воспользоваться командой Invoke-CsManagementStoreReplication и Get-CsManagementStoreReplicationStatus

Финальным шагом — разрешим внешним пользователям подключаться к серверам пула Edge

Покдлючение внешнего клиента — успешно..

На изображении видно, что синхронизация адресной книги не работает, это происходит из-за того что в инфраструктуре еще нет обратного проксирующего сервера.

Share this:

Понравилось это:

Похожее

а когда будет статья про развертываение клиентов Lync 2013 в домене? А если без SC ? 🙂

Читайте также:  Установка брекет систем в санкт петербурге

Вроде я писал уже развертывание клиентов Lync 2010 с помощью групповых политик, если нет в ближайшие дни выложу текст cmd файла — там две строчки.

Написал про клиентов 2010, для 2013 все одно и тоже.

Здравствуйте! Можно ли Lync установить на виртуальную машину.
Есть ли какие нибудь видео уроки?? как все начать ??

С опозданием на месяц. Да Lync 2013 полностью поддерживает виртуализацию (официально Hyper-v & VMware). Для тестовых сред думаю, что можно использовать любой гипервизор.

Здравствуйте. Подскажите, пожалуйста, возможно ли перенастроить конфигурацию портов для сервисов Edge таким образом, чтобы не транслировать порт 443 публичного IP-адреса на сервер Edge (так как порт уже занят другим сервером)?

Да возможно..в topology builder можно переопределить стандартные порты

Большое спасибо за ответ. Еще один вопрос: планирую заказать публичный сертификат для внешнего доступа. Хочу использовать один и тот же Wildcard-сертификат для Edge, Reverse Proxy и Office Web Apps External.

Все сервисы кроме Edge публикуются через Reverse Proxy (для Edge настроен NAT/PAT на интернет-шлюзе).

Текущая конфигурация:
Lync Meet: meet.contoso.com
Lync Dial-In: dialin.contoso.com
Lync External Web Services: lswebext.contoso.com
Lync Discover External: lyncdiscover.contoso.com
Lync Edge External: lyncedge.contoso.com
OWAS External: owaspublic.contoso.com

Достаточно ли будет следующего сертификата?
CN=lswebext.contoso.com
SAN=*.contoso.com

C обратным проксирующем сервером проблем не будет, с внутренним адаптером Edge тоже, а вот с внешним будут. Насколько я знаю для Access Edge необходимо наличие CN, а вилдкард сертификат не поддерживает CN.
Его кстати нет в списке тут http://technet.microsoft.com/en-us/library/hh202161.aspx

Ну и известная «запара» с которой встречался лично я в миграциях Exchange — это то, что не все мобильные клиенты поддерживают звездочку, поэтому использовать ее нужно аккуратно. Как то так..

Скорее всего буду использовать два отдельных сертификата: wildcard для Reverse Proxy и обычный single-name для Access Edge (благо внешний FQDN одинаков для всех сервисов Edge), для начала от какого-нибудь StartSSL.

Если вас не затруднит, пожалуйста, подскажите еще одну вещь. Не хочет проверяться отзыв сертификата внутреннего сервиса Office Web Apps 2013 на недоменных машинах.

Перенастроил CA (включил расширения HTTP-CDP, HTTP-AIA), выпустил и назначил ферме новый сертификат с HTTP-полями CDP/AIA (поля видны если зайти в IE на ресурс hosting/discovery и просмотреть сертификат). Валидацию тоже проходит: http://pastebin.com/sGAYgPTD

Однако десктопный клиент Lync 2013 на недоменной машине по-прежнему сообщает о том, что при проверке сертификата сервера возникла проблема и не позволяет подключаться к презентациям. Предположил, что стучится на публичный URI, но TCPView показывает, что подключение идет к внутреннему IP сервера OWAS. В чем может быть проблема? Где можно посмотреть логи проверки отзыва?

Спасибо, что уделили время.

Машина должна доверять центру сертификации. Для этого в доверенных корневых ЦС у нее должен стоять сертификат ЦС который выпустил сертификат с которым работает эта машина. Для публичных ЦС в Windows уже предустановлены эти сертификаты, для доменных машин — этот сертификат деплоится с помощью AD, а для не доменных обычно ставится вручную.

То что вы сделали- вы опубликовали списки отзывов с помощью http — это хорошо, но еще нужно импортировать сертификат центра сертификации в доверенные корневые ЦС на машине. как то так..

Импорт выполнен как в хранилище пользователя, так и в хранилище компьютера (на всякий случай). Проверял отпечаток сертификата CA в обоих хранилищах, он полностью совпадает с тем, что используется в ADCS (в настройках ADCS только один корневой сертификат) и совпадает с отпечатком сертификата, опубликованного по HTTP URL.

По тексту я так понимаю вы импортируете на клиента сертификат, который установлен на OWA 2013, да?

А тоесть, вы импортируете вроде как сертификат ЦС и опубликовываете по HTTPS тоже его?
1. Короче говоря, для не доменных машин — в хранилище компьютера должен быть добавлен сертификат ЦС, чтобы эта машина доверяла сертификату на OWA.
2. НА web сервере должны быть опубликованы CRL ЦС, который выпускает сертификат для OWA.

Технология примерно такая — клиент взаимодействует с сертификатом OWA — проверяет может ли он ЦС доверять, проверяет срок годности, проверяет список отзывов CRL ЦС для того, чтобы убедиться, что сертификат для OWA не был отозван, вот собственно и все.
Разница между доменныи и не доменным клиентом две:
1. Сертификат ЦС публикуется через AD
2. CRL публикуются через AD.

Пардон, неоднозначно выразился.

Нет, на недоменную клиентскую машину я импортирую именно корневой сертификат ЦС (Contoso-CERTSRV01-CA), размещаю его в хранилище доверенных корневых сертификатов. Сертификат Office Web Apps Server на недоменную машину я не импортирую.

Все «косвенные улики» свидетельствуют, что развертывание правильное, но презентации с включенной проверкой отзыва сертификата не работают. Через IE в свойствах сертификата видно присутствие HTTP-CDP/AIA. Эти ссылки можно скопировать в адресную строку браузера и они работают (скачивается CRL и сертификат). Более того, если сертификат OWAS скопировать на недоменный ПК (можно через Firefox или просто экспортировать с сервера), то он проходит верификацию командой CertUtil.exe -URLFetch -Verify cert.crt (логи верификации по ссылке выше). По LDAP-ссылкам естественно, не проходит, только по HTTP.

Уже даже ферму пересоздал на всякий случай, не помогло. Обновление стоит KB2863879 от 14.01.2014 (ставилось до создания фермы, все согласно документации).

А скачивать CRL по ссылке пытались с не доменной машины?

Да. Скачиваю CRL и CRT именно с недоменной машины (личный ноутбук в рабочей группе). В журналах Lync крайне информативная запись: «The certificate presented by the WAC Server or Proxy could not be validated».

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

Чудеса какие-то. Позвонил двоим знакомым инженерам, просил проконсультировать. Несмотря на то, что настройки AD Certification Services не менялись еще с четверга, сертификат OWAS тоже не менялся, только что (14:30) презентации на недоменных машинах заработали (в журнале Lync\Tracing запись «A viewing URL navigation was attempted»). Единственное, что я делал — пересоздал ферму, но это было более двух часов назад. Странно.

Кажется удалось нащупать причину проблемы. Похоже, что Windows запоминает где-то в кэше состояние верификации CRL для сертификата Office Web Apps и пока не истечет срок действия этой записи, система считает сертификат неверифицированным и не пытается выполнить проверку. Пока я не запустил ручную верификацию через утилиту командной строки certutil.exe презентации не работали. После ручной верификации запустил Lync и презентации заработали.

Добрый день Спасибо большое за цикл, весьма добротно и подробно расписано. Брал сертификат со звездочкой у Комодо, проблем не возникло с запуском служб на Эдж, а вот настройку далее пока не осилил. Подскажите, пожалуйста- я поднял только 1 ФЕ и Едж, мне необходимо поднимать РП для внешних клиентов? Вот здесь раскопал :
When using single public IP on edge server, SRV record for _sip._tls.contoso.com should map to sip.contoso.com on port 5061. Not 443 which is the default when you’re using three IP addresses. Lync setup actually sets sip to 5061, webconf to 444 and av to 443. The SRV will therefore map to av according to your suggestion and not sip.
http://social.technet.microsoft.com/Forums/lync/en-US/54059855-518f-416c-a8f2-41b3242679ec/lync-server-2013-external-access-with-1-public-ip-and-without-reverse-proxy
Дело в том, что пока не очевидно, необходим ли для меня РП или нет. Настроил 1 IP, пока результата желаемого нет. Поменял порт у SRV как советуют выше, тоже извне подключения клиентом 2013\2010 нет. Посоветуете установить РП ?

Так давайте отделим котлет от мух. Для чего нужен обратный проксирующий сервер описано тут: http://technet.microsoft.com/en-us/library/gg398069
Enabling external users to download meeting content for your meetings.
Enabling external users to expand distribution groups.
Enabling remote users to download files from the Address Book service.
Accessing the Lync Web App client.
Accessing the Dial-in Conferencing Settings webpage.
Accessing the Location Information service.
Enabling external devices to connect to Device Update web service and obtain updates.
Enabling mobile applications to automatically discover and use the mobility (Mcx) URLs from the Internet.
Enabling the Lync 2013 client, Lync Windows Store app and Lync 2013 Mobile client to locate the Lync Discover (autodiscover) URLs and use Unified Communications Web API (UCWA).

Как описал отвечающий, обратный прокси это конечно дополнительная роль(даже не роль Lync), но вот если у ваших внешних пользователей банально не будет загружаться адресная книга — не знаю удобно это им будет. Поэтому решать вам, мое мнение must have.

По поводу одного IP для Edge — с технической стороны ситуация нормальная, необходимо просто «раскидать» сервисы Edge по разным портам ну и соответственно указать не стандартные порты в SRV. По поводу звездочки — мы тут уже обсуждали ранее и лично я не увидел что для сервиса Access Edge поддерживается звездочка. Самый простой способ на вашем месте это:
1. Создать сертификат SAN и попробовать подключиться.
2. Если не уверены что у вас корректно работает автодисковер — укажите в клиенте напрямую внешний хост с портом.
3. Изначально проверьте с помощью «netstat -an» а правда ли у вас слушает сервер на нужном вам порту и попробуйте снаружи подключиться telnet на этот порт или просканировать с помощью того же portquery. Про порты линка статья вам в помощь http://blog.schertz.name/2012/07/understanding-lync-edge-server-ports/

Спасибо за ответ! По поводу мухи- я очень долго везде курил и смотрел- она действительно не поддерживается МС, но работает. Правда не везде и не всегда- например, у разных поставщиков даже бывают проблемы. ИМХО. именно по этому МС ее и не саппортит. Просто поделился мыслью, как и Вы, что можно ставить, но возможны проблемы. Спасибо за комментарий касаемо- РП, мне все это кристально ясно, что будет, что не будет работать, и почему. Обложусь телнетом, буду проверять. Сейчас «нетворк гай» по моей просьбе тупо пронатил все порты на эдже, телнет снаружи цепляется. а вот клиент если снупером посмотреть- уже нет (2013 полный). Не сталкивались с таким ранее? Ощущение из ошибки что внутри он не находит ФЕ уже 😦
Info>

Читайте также:  Установка магнитолы рсд 310

самое простое по FQDN с Edge telnet на FE и пинг. С FE так же внутренней адаптер Edge должен быть доступен по FQDN.

Info CDATA[Discovery task(0BB5C398) sent to URL https://lyncdiscover.info.ru completed with hr=0x80f10044 Info
Info CDATA Discovery task(0BB5D0B8) sent to URL http://lyncdiscover.info.ru completed with hr=0x80f10040 Info
nfo CDATA Lync autodiscovery completed with hr: 0X80004005 sipint: sipext: authint: authext: wts: retry: 0 Info
SequenceID 1.1.1 SequenceID
hr 0x80004005 hr
Lync-autodiscovery
DNSAutoDiscovery
SequenceID>1.1.2 SequenceID
hr>0x0 hr
DNSAutoDiscovery
Info CDATAsip.info.ru:443, external, discovered added to list of auto-discovered servers Info
Info CDATA
1 server(s) returned
Server: sip.info.ru:443, external, discoveredadded to list of auto-discovered servers
signin to server=sip.info.ru:443, external, discovered
redirectedServersList=Info
nfo CDATA
VerifyOnEnableEvent result return 10
ONENABLE_FAIL_SERVER_NOT_REACHABLE
status=0x80ee001c
ACTION: SERVER NOT REACHABLE
NO MORE SERVER TO TRY
ACTION : PERMANENT ERROR Info
SequenceID>1.1SequenceID
hr 0x80ee001c hr
Login
root Извиняюсь за повтор- не понял сразу что теги срезает (

Да, это лог с клиента извне. внутри все хорошо.Сертификат у клиента есть, службы у эджа и фе запущены, репликация идет, все вроде хорошо. Без автодискавера с клиента снаружи тоже пробовал сип:443 указывать- тоже не поджигается. Вот и задумался в сторону РП. Но, наверное, не в нем дело 🙂 раз у вас заработало без него.
Смена порта по совету выше( во внешней зоне днс (с чего начался сегодняшний вечер тоже пока не принесла удачи).

Также, как и Вы использую внутренний днс на эдже….

Ну если Вы опубликовали на Edge сервере Access сервис на порту не 443, а 5061 то и подключаться клиентом необходимо на 5061, а вы указываете 443. Соответственно во внешней зоне DNS запись SRV так же должна указывать на порт 5061.

А может, я не прав в том, что одно и тоже имя использую для веб сервисов, которое я могу менять и для трех других служб, которые привязываются к одному имении(сип) тк я имею 1 ип а не три? http://rghost.ru/52394379 .С СРВ записью, если честно только сегодня задумался- до этого использовал порты которые предлагает мастер. ткт в топологии я пока ничего не менял, поменял только во внешней зоне.

По умолчанию на Edge сервере три сервиса публикуется на порту 443. В случае если IP адрес один необходимо в Topology Builder указать различные порты, вы приводили выжимку по портам из форума. Для того чтобы клиент залогинился нужно только одно имя sip.xxxx.xx, для логона достаточно этого, если этого не происходит просмотрите внимательней все шаги и рекомендации при развертывании, для вашего случая с 1 IP отличие будет только по портам.

Вы случайно не сталкивались с разверытванием IIS Application Request Routing 3.0 в качестве Reverse Proxy? IIS ARR 3.0 не пробрасывает запросы, требующие Windows Authentication на целевую ферму Lync Web Services External, постоянно выкидывает 401:Unauthorized.

Проверить можно браузером:

https://lswebext.contoso.com:443/CertProv/CertProvisioningService.svc [401]
[постоянно запрашивает учетные данные; даже если они верные, все равно после трех попыток выдает 401]

https://lswebext.contoso.com:443/dialin/
[эта страница не требует Windows-аутентификации, она проксируется нормально]

На IIS включена только анонимная аутентификация. По идее в таком случае ARR должен должен выступать как прокси и просто транслировать запросы к целевой ферме (Lync Web Services External), однако запросы до фермы не доходят. Для версии 2.5 был выпущен патч KB2732764, есть ли решение для IIS ARR 3.0 или проще взять и заменить ARR на версию 2.5?

Поспешил с выводом, запросы все-таки доходят, вот запись в логе IIS-LyncWSE:

Через Reverse Proxy:
2014-02-13 10:21:11 192.168.100.131 GET /CertProv/CertProvisioningService.svc — 4443 — 192.168.100.134 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+.NET4.0E;+.NET4.0C;+InfoPath.3;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729) — 401 0 0 2

Напрямую:
2014-02-13 10:24:28 192.168.100.131 GET /CertProv/CertProvisioningService.svc — 4443 LyncTestUser2@contoso.com 192.168.7.168 Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.3;+WOW64;+Trident/7.0;+.NET4.0E;+.NET4.0C;+InfoPath.3;+.NET+CLR+3.5.30729;+.NET+CLR+2.0.50727;+.NET+CLR+3.0.30729) — 200 0 0 4

192.168.100.131 — Front End
192.168.100.134 — Reverse Proxy Internal

Get-CsWebServiceConfiguration | fl UseWindowsAuth
возвращает Negotiate

Переставил IIS ARR на версию 2.5, накатил патч KB2732764. Клиенты Lync Mobile 2010 заработали, Lync Mobile 2013 по прежнему выдавал ошибку входа.

Полдня потратил на поиски причины и все-таки нашел. Надеюсь другим читателям тоже будет интересно узнать еще одну причину почему может не заработать Lync Mobility если используется IIS Application Request Routing.

Оказывается, если в настройках фермы IIS ARR указать вместо IP-адреса внутреннее доменное имя Front End (например lyncfront.contoso.loc), то даже при наличии установленного патча KB2732764, запросы к Lync Web Services External требующие аутентификации будут всегда отваливаться с кодом 401:Unauthorized. Если вместо доменного имени указать IP-адрес, доступ к Lync Web Services External через Reverse Proxy IIS ARR работает.

Я делал на 2,5, указывая внутренний FQDN фермы, это однозначно помню. Более того, Ваша догадка не сходится, в случае если развернут пул серверов FE, а когда развернут пул FE, то серверы в DNS представлены записями вида: poolFE01.xxx.xx=ip1, poolFE01.xxx.xx=ip2. Если вместо имени poolFE01.xxx.xx, указать один IP, то при выходе из строя одного из серверов обратный прокси перестанет проксировать. Я настраивал по следующей статье: http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx
Вы установили корневой сертификат ЦС на обратный проксирующий сервер?

> запросы к Lync Web Services External требующие аутентификации будут всегда отваливаться с кодом 401:Unauthorized. Если вместо доменного имени указать IP-адрес
>
Рискну предположить, что поскольку как Вы указали в первом посте все имена в сертификате у Вас .ком,а fqnd внутреннего FE в нем нет, то посему клиенты и отваливаются с ошибкой.

Внешние клиенты должны взаимодействовать с сертификатами, только с внешними именами — это не логично, а некоторые даже думают не безопасно, когда во внешних сертификатах присутствуют внутренние имена сервисов. Тут речь идет, что якобы обратный прокси, приняв трафик и направив его в правильном направлении(на внешний URL IIS FE port 4443) получает сообщение об ошибке 401, не знаю в чем может причина, на тестовом стенде я думаю это легко проверяется — жаль он у меня занят другими системами:).

Ответ на #38:
Да, настройку IIS ARR выполнял именно по указанной вами статье. Корневой сертификат CA установлен на машину RP (сервер не в домене, ставил вручную). DNS для RP указан публичный, но в %windir%\system32\drivers\etc\hosts прописано соответствие 192.168.100.131==lyncfront.contoso.loc.

Для целей тестирования на сервере Reverse Proxy установлен сертификат веб-сервера от корпоративного CA, содержащий CN=lyncfront.contoso.loc, а в SAN перечислены все DNS-имена как внутренние так и внешние (в том числе и lyncfront.contoso.loc). Поскольку публичный NAT еще не поднят, то для целей тестирования работоспособности сервисов Lync в записях внутреннего DNS организации все доменные имена для Reverse Proxy (lswebext.contoso.com, meet.contoso.com, dialin.contoso.com, lyncdiscover.contoso.com и т.п.) нацелены на внутренний LAN IP сервера Reverse Proxy (192.168.100.134).

Понимаю, что это костыль, но логика IIS ARR даже в таком сценарии должна корректно отрабатывать запросы.

Спасибо большое за то, что уделили время.

То есть ваши «внешние клиенты» на самом деле находятся в той же сети что и внутренний и внешним DNS вы маршрутизируете их на внутренний адрес IIS. Смоделируйте более реальную картину, когда ваши клиенты не маршрутизируются с внутренним сервером Lync FE. Самое наверное простое это добавить второй адаптер а IIS из другой не маршрутизируемой подсети, туда же добавьте «внешнего клиента» и в HOSTS укажите внешние IP для веб сервисов. Возможно мы чего то не знаем, но явно разработчики не предполагали, что это будет происходить, поэтому иногда вот такие на первый взгляд «тупые» и «по мануалу» действия могут привести к положительным результатам. Я Вас уверяю, что Вы не единственный в мире кто настраивает IIS обратный прокси — если бы это было правдой, заметок в блогах была бы куча. Я например таких тем даже не видел.

Прошу прощения, что сразу не сообщил. В моем сценарии я тестировал не доступ внешних клиентов, а именно внутренний доступ к Lync Mobility.

Дело в том, что даже внутренний доступ к Lync Mobility, если верить этой статье (https://blogs.technet.com/b/nexthop/archive/2012/11/19/configuring-reverse-proxy-for-lync-server-2010-mobility.aspx), идет через Lync Web Services External (см. диаграмму 1 в статье). Содержимое JSON-файлов, полученных от LyncDiscover и анализ трафика при помощи Fiddler Web Debugger подтверждают это предположение. Может я ошибаюсь, но IIS ARR безразлично с какого интерфейса пришел HTTP(S)-запрос. Если он слушает LAN-интерфейс и есть корректные правила URL Rewrite, то запрос будет направлен на нужный сервис (в данном случае Lync Web Services External).

Дело в том, что на данный момент сеть периметра полноценно не функционирует (внешние интерфейсы Reverse Proxy и Lync Edge повешены на виртуальный коммутатор Hyper-V, который не соединен с интернетом) и единственным способом проверить работоспособность Reverse Proxy для внутренних мобильных клиентов является описанный мной костыль. Когда коллеги-сетевики полноценно настроят DMZ для Lync со всеми маршрутами — смогу протестировать «чистый» сценарий.

Добрый.
Какие потребуются сертификаты для организации федерации?

Добрый день
при обновлении EDGA надо ли еще какие то действия производить?
(http://support.microsoft.com/kb/2809243/en)
не нашел точной информации надо ли обновлять базу?

Добрый день, Илья! Простите что с опозданием — конкретно для Edge в этом пакете обновлений только поставить само обновление стандартным для Lync установщиком, других действий по Edge делать не нужно.

Добрый день.
Сделал все как описано, но у меня почему-то не хочет работать. При подключении клиента он выдает «Lync не может найти Lync Server для lync.cg.ru. Возможно возникла проблема с конфигурацией службы доменных имен вашего домена.»

При этом с помощью wireshark я вижу, что на внешнем интерфейсе появляются пару пакетов на 443 порт, после чего lync edge сразу рвет соединение. На внутреннем интерфейсе при этом ничего не происходит.

Версия клиентов
Версия серверов
Какие доменные имена вы создали во внешней зоне? (перечислите, только ваш реальный домен не к чему светить)
Какие имена в сертификате на Edge у вас присутствуют, для обоих интерфейсов?
Ну а так же опишите сетевую конфигурацию вашего Edge, есть ли NAT между внутренним интерфейсом и клиентами?
Доступен ли интерфейс Edge для внутренних клиентов по имени?
А так же как показывает практика анализ проблем для Lync начинается не с Wireshark, а все же с логирования SIP трафика средствами Lync, там можно хотя бы понять доходят ли до клиентов SIP пакеты или нет.

Читайте также:  Установка автоматов в муниципальных учреждениях

Спасибо за ответ.
Внешний доступ у меня в итоге заработал, но только не для мобильных клиентов. Впрочем для мобильных клиентов он почему-то не работает и в локальной сети. При подключении с iphone, ipad, android получаю в ответ — ‘Не удается подключиться к серверу. Проверьте сетевое подключение или адрес сервера и повторите попытку’.

Я использовал одно внешнее доменное имя и один внешний адрес. Во внешней зоне соответственно созданы: запись А — lync-edge.ext-domain.ru и srv записи _sip._tls.ext-domain.ru и _sipfederationtls._tcp.ext-domain.ru, обе ссылающиеся на lync-edge.ext-domain.ru.

В сертификате для внутреннего интерфейса присутствует только имя lync-edge.cherry.loc, для внешнего — sip.cherry.loc, lync-edge.ext-domain.ru, cherry.loc. Внешний сертификат выпущен тем же локальным центром сертификации, что и внутренний, на мобильном устройстве установлен корневой сертификат.

NAT-ов никаких нет, внешний адрес настроен на интерфейсе lync-edge.

На клиенте соответственно отключаю автообнаружение и указываю адрес внешнего доступа — lync-edge.ext-domain.ru:5061. В адресе входа пишу — user@cherry.loc, указываю имя пользователя и пароль.

При этом в логе клиента среди прочего присутствуют строчка «ERROR APPLICATION CUcwaAppSession.cpp/2072:Auto-discovery failed, aborting sign-in!» Уж не знаю, ключевая ли это строчка, весь лог большой, сюда писать уж не стал.

Поискав по этой проблеме в интернете, у меня сложилось впечатление, что для работы с мобильными клиентами Lync FE и Lync Edge недостаточно, а нужен еще Reverse Proxy. Подскажите пожалуйста так ли это и если так, то будет ли у вас еще и статья про Reverse Proxy, а то я пока не совсем понимаю что это такое и как его устанавливать\настраивать.

День добрый!
1. Статьи не будет, так как сама по себе настройка обратного прокси гроша ломанного не стоит.
2. Мобильные клиенты не будут подключаться без обратного прокси, но кроме этого еще будут и проблемы работы толстых клиентов Lync.
3. Обратный прокси как общее понимание проксирует внешние запросы на внутренние ресурсы. ISA, TMG есть обратный прокси — раньше веб-сервисы опубликовывали через эти серверы.
4. Самый простой способ это поднять IIS ARR http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx

Попробовал настроить Reverse Proxy указанной вами ссылке http://blogs.technet.com/b/nexthop/archive/2013/02/19/using-iis-arr-as-a-reverse-proxy-for-lync-server-2013.aspx. Насколько я понял Reverse Proxy должен транслировать запросы, которые к нему приходят, на Lync Frontend Server. Но я так и не понял, где нужно указывать адрес этого самого FE. В статье указано, что например при создании фермы lyncweb.domain.com мы добавляем в него сервер lyncweb.domain.com, хотя это вроде как внешний домен и на FE явно не ссылается.

Смотрите — на FE если вы внимательно посмотрите на IIS существуют два одинаковых сайта, только один использует сокет с портами 80 и 443, а другой сокет с 8080 и 4443. Так вот к одному подключаются внутренние клиенты, а ко второму по внешним портам 80 и 443 внешние клиенты. Задача обратного прокси перенаправить внешнее подключение 80 и 443 на 8080 и 4443.
Из этого можно сделать вывод. что на этой картинке http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-84-94/5340.Figure_5F00_4.jpg

указано имя внутреннего сервера FE Lync, так как указаны порты 4443 и 8080. Просто в статье используют конфигурацию Split-DNS с одинаковыми названиями внешней зоны и внутренней. Вам надо указать, то имя которое указано в сертификате на FE. Соответственно самое простое в HOSTS на IIS прокси прописать имя FE которое в сертификате, ну и не забудьте добавить в доверенные ЦС на обртном прокси сертификат центра сертификации который выдал сертификат для FE.
Удачной попытки! )

Настроил Reverse Proxy, при добавлении серверов в Server Farms указал имя внутреннего FE Lync. Но мобильный клиент у меня по-прежнему не хочет подключаться — в ответ опять получаю ‘Не удается подключиться к серверу. Проверьте сетевое подключение или адрес сервера и повторите попытку’.

При этом кстати при добавлении второй и последующих ферм он ругнулся, что создаваемые URL Rewrite Rules могут конфликтовать с существующими — это нормально?

На Reverse Proxy в wireshark я вижу, что на внутреннем интерфейсе пакеты есть — он общается с FE по порту 4443.

Вот выдержа из лога клиента.

2014-09-22 15:17:53.041 Lync[299:715a000] INFO TRANSPORT CUcwaAutoDiscoveryResponse.cpp/119:location value is external
2014-09-22 15:17:53.042 Lync[299:715a000] INFO TRANSPORT CUcwaAutoDiscoveryResponse.cpp/195:User url is https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
2014-09-22 15:17:53.042 Lync[299:715a000] INFO TRANSPORT CHttpRequestProcessor.cpp/266:Sending event to main thread for request(0x6f54648)
2014-09-22 15:17:53.042 Lync[299:3c2a218c] INFO APPLICATION CTransportRequestRetrialQueue.cpp/822:Req. completed, Stopping timer.
2014-09-22 15:17:53.043 Lync[299:3c2a218c] INFO APPLICATION CUcwaAutoDiscoveryGetUserUrlOperation.cpp/290:Received a root response
2014-09-22 15:17:53.043 Lync[299:3c2a218c] INFO APPLICATION CUcwaAutoDiscoveryGetUserUrlOperation.cpp/224:UcwaAutoDiscoveryGetUserUrlOperation completed with url = https://lyncdiscover.domain.ru/?sipuri=sip:user@domain.ru, userUrl = https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru, status = S_OK (S0-0-0)
2014-09-22 15:17:53.043 Lync[299:3c2a218c] INFO APPLICATION CTransportRequestRetrialQueue.cpp/725:Response received for req. GET-UnAuthenticatedGet(0x6f54648): S_OK (S0-0-0) (Success); Done with req.; Stopping resend timer
2014-09-22 15:17:53.044 Lync[299:3c2a218c] INFO TRANSPORT CCredentialManager.cpp/176:getSpecificCredential for serviceId(1) returning: credType (1) signInName (user@domain.ru) domain (cherry) username (user) password.empty() (0) certificate.isValid() (0) privateKey.empty() (1) compatibleServiceIds(1)
2014-09-22 15:17:53.044 Lync[299:3c2a218c] INFO TRANSPORT CMetaDataManager.cpp/403:Received a request to get the meta data of type 0 for url https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
2014-09-22 15:17:53.044 Lync[299:3c2a218c] INFO TRANSPORT CMetaDataManager.cpp/458:Sending Unauthenticated get to get the web-ticket url
2014-09-22 15:17:53.044 Lync[299:3c2a218c] INFO TRANSPORT CTransportThread.cpp/135:Added Request() to Request Processor queue
2014-09-22 15:17:53.045 Lync[299:3c2a218c] INFO TRANSPORT CAuthenticationResolver.cpp/109:Waiting on Meta Data from https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
2014-09-22 15:17:53.045 Lync[299:659a000] INFO TRANSPORT CTransportThread.cpp/347:Sent Request() to Request Processor
2014-09-22 15:17:53.045 Lync[299:3c2a218c] INFO APPLICATION CTransportRequestRetrialQueue.cpp/385:Submitting new req. GET-AuthenticatedUserGetRequest(0x6e83da8)
2014-09-22 15:17:53.045 Lync[299:659a000] WARNING TRANSPORT CCredentialManager.cpp/317:CCredentialManager::getSpecificCredential returning NULL credential for serviceId (4) type (1)!
2014-09-22 15:17:53.046 Lync[299:3c2a218c] INFO APPLICATION CUcwaAutoDiscoveryService.cpp/1263:Submitting Authenticated AutoDiscovery request to https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
2014-09-22 15:17:53.046 Lync[299:659a000] INFO TRANSPORT TransportUtilityFunctions.cpp/689:
GET https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
Request Id: 0x133b6a8
HttpHeader:Accept

2014-09-22 15:17:53.046 Lync[299:659a000] INFO UTILITIES CHttpStreamPool.cpp/399:Allocating stream 0x6e73850 for url — https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user with persistent id as 16
2014-09-22 15:17:53.047 Lync[299:659a000] VERBOSE TRANSPORT CHttpProxyHelper.cpp/435:CHttpProxyHelper::discoverProxy : No proxy found for url https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru. Sending over direct connection.
2014-09-22 15:17:53.050 Lync[299:659a000] ERROR TRANSPORT CHttpConnection.cpp/1029:Request Type = 0x%u0x6e743a0 Error domain = kCFErrorDomainCFNetwork code = 0x2 ErrorDescription = The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 2.) ErrorFailureReason = ErrorRecoverySuggestion =
2014-09-22 15:17:53.050 Lync[299:659a000] ERROR UTILITIES CHttpConnection.cpp/958:GetAddrInfo returned error 0x8
2014-09-22 15:17:53.050 Lync[299:659a000] INFO UTILITIES CHttpStreamPool.cpp/467:Releasing stream 0x6e73850.
2014-09-22 15:17:53.050 Lync[299:659a000] INFO UTILITIES CHttpStreamPool.cpp/599:Releasing stream 0x6e73850.
2014-09-22 15:17:53.051 Lync[299:659a000] INFO TRANSPORT CHttpRequestProcessor.cpp/173:Received response of request() with status = 0x22020001
2014-09-22 15:17:53.051 Lync[299:659a000] INFO TRANSPORT CHttpRequestProcessor.cpp/201:Request resulted in E_ConnectionError (E2-2-1). The retry counter is: 0
2014-09-22 15:17:53.051 Lync[299:659a000] WARNING TRANSPORT CCredentialManager.cpp/317:CCredentialManager::getSpecificCredential returning NULL credential for serviceId (4) type (1)!
2014-09-22 15:17:53.052 Lync[299:659a000] INFO TRANSPORT TransportUtilityFunctions.cpp/689:
GET https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
Request Id: 0x133b6a8
HttpHeader:Accept

2014-09-22 15:17:53.052 Lync[299:659a000] INFO UTILITIES CHttpStreamPool.cpp/399:Allocating stream 0x14102a0 for url — https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user with persistent id as 16
2014-09-22 15:17:53.053 Lync[299:659a000] VERBOSE TRANSPORT CHttpProxyHelper.cpp/435:CHttpProxyHelper::discoverProxy : No proxy found for url https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru. Sending over direct connection.
2014-09-22 15:17:53.056 Lync[299:659a000] ERROR TRANSPORT CHttpConnection.cpp/1029:Request Type = 0x%u0x14080f0 Error domain = kCFErrorDomainCFNetwork code = 0x2 ErrorDescription = The operation couldn’t be completed. (kCFErrorDomainCFNetwork error 2.) ErrorFailureReason = ErrorRecoverySuggestion =
2014-09-22 15:17:53.056 Lync[299:659a000] ERROR UTILITIES CHttpConnection.cpp/958:GetAddrInfo returned error 0x8
2014-09-22 15:17:53.056 Lync[299:659a000] INFO UTILITIES CHttpStreamPool.cpp/467:Releasing stream 0x14102a0.
2014-09-22 15:17:53.056 Lync[299:659a000] INFO UTILITIES CHttpStreamPool.cpp/599:Releasing stream 0x14102a0.
2014-09-22 15:17:53.057 Lync[299:659a000] INFO TRANSPORT CHttpRequestProcessor.cpp/173:Received response of request() with status = 0x22020001
2014-09-22 15:17:53.057 Lync[299:659a000] INFO TRANSPORT CHttpRequestProcessor.cpp/201:Request resulted in E_ConnectionError (E2-2-1). The retry counter is: 1
2014-09-22 15:17:53.057 Lync[299:659a000] INFO TRANSPORT CHttpRequestProcessor.cpp/266:Sending event to main thread for request(0x133b6a8)
2014-09-22 15:17:53.058 Lync[299:3c2a218c] INFO TRANSPORT CMetaDataManager.cpp/572:Received response for meta data request of type 60 with status 570556417
2014-09-22 15:17:53.058 Lync[299:3c2a218c] ERROR TRANSPORT CMetaDataManager.cpp/588:Unable to get a response to an unauthenticated get to url https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
2014-09-22 15:17:53.059 Lync[299:3c2a218c] INFO TRANSPORT CAuthenticationResolver.cpp/208:MetaData retrieval for url https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru completed with status 570556417
2014-09-22 15:17:53.059 Lync[299:3c2a218c] INFO TRANSPORT CAuthenticationResolver.cpp/238:Deleting 1 pended Meta data requests for url https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
2014-09-22 15:17:53.059 Lync[299:3c2a218c] ERROR TRANSPORT CAuthenticationResolver.cpp/334:Unable to get the meta data for server url https://lync.cherry.loc/Autodiscover/AutodiscoverService.svc/root/user?originalDomain=domain.ru
2014-09-22 15:17:53.059 Lync[299:3c2a218c] INFO TRANSPORT CAuthenticationResolver.cpp/337:Failing request to the request manager
2014-09-22 15:17:53.060 Lync[299:3c2a218c] INFO TRANSPORT CRequestManager.cpp/284:Failing secure request UcwaAutoDiscoveryRequest with status E_ConnectionError (E2-2-1)
2014-09-22 15:17:53.060 Lync[299:3c2a218c] INFO APPLICATION CTransportRequestRetrialQueue.cpp/822:Req. completed, Stopping timer.
2014-09-22 15:17:53.060 Lync[299:3c2a218c] INFO APPLICATION CUcwaAutoDiscoveryService.cpp/1358:Received autodiscovery response with status E_ConnectionError (E2-2-1)
2014-09-22 15:17:53.060 Lync[299:3c2a218c] INFO APPLICATION CUcwaAutoDiscoveryService.cpp/1316:Raising Autodiscovery event with status E_ConnectionError (E2-2-1) for eventType 0
2014-09-22 15:17:53.061 Lync[299:3c2a218c] INFO APPLICATION CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/417:Received event for type 0 with status E_ConnectionError (E2-2-1)
2014-09-22 15:17:53.061 Lync[299:3c2a218c] INFO APPLICATION CUcwaAutoDiscoveryServiceRetrialWrapper.cpp/539:Autodiscovery scheduled retrial timer. Timer 0.000000 seconds
2014-09-22 15:17:53.061 Lync[299:3c2a218c] INFO APPLICATION CAlertReporter.cpp/64:Alert received! Category 1, Type 201, level 0, error E_ConnectionError (E2-2-1), context », hasAction=false
2014-09-22 15:17:53.061 Lync[299:3c2a218c] INFO APPLICATION CAlertReporter.cpp/117:Alert cleared of Category 1, Type 201, cleared 0 alerts
2014-09-22 15:17:53.062 Lync[299:3c2a218c] INFO APPLICATION CTransportRequestRetrialQueue.cpp/725:Response received for req. GET-AuthenticatedUserGetRequest(0x6e83da8): E_ConnectionError (E2-2-1) (RemoteNetworkTemporaryError); Done with req.; Stopping resend timer
2014-09-22 15:17:53.062 Lync[299:3c2a218c] INFO UI CMAlertViewController.mm/87:ObservableListItem Added event received
2014-09-22 15:17:53.062 Lync[299:3c2a218c] INFO UI CMAlertViewController.mm/97:showalert is 1
2014-09-22 15:17:53.063 Lync[299:3c2a218c] INFO UI CMConversationCommon.mm/43:not signed in
2014-09-22 15:17:53.063 Lync[299:3c2a218c] INFO UI CMConversationCommon.mm/43:not signed in
2014-09-22 15:17:53.063 Lync[299:3c2a218c] INFO UI CMConversationCommon.mm/43:not signed in
2014-09-22 15:17:53.063 Lync[299:3c2a218c] INFO UI CMConversationCommon.mm/43:not signed in
2014-09-22 15:17:53.063 Lync[299:3c2a218c] INFO UI CMConversationCommon.mm/43:not signed in
2014-09-22 15:17:53.064 Lync[299:3c2a218c] INFO UI CMNotificationManager.mm/697:desired view is alert, size 1
2014-09-22 15:17:53.064 Lync[299:3c2a218c] INFO UI CMNotificationManager.mm/737:adding the desired view
2014-09-22 15:17:53.065 Lync[299:3c2a218c] INFO UI CMNotificationManager.mm/472:reposition floating views
2014-09-22 15:17:53.065 Lync[299:3c2a218c] INFO UI CMAlertViewController.mm/104:showalert is 1
2014-09-22 15:17:53.065 Lync[299:3c2a218c] INFO UI CMAlertViewController.mm/108:showalert is 0
2014-09-22 15:17:53.066 Lync[299:3c2a218c] INFO UI CMUIUtil.mm/410:Mapping error code = 0x22020001, context = , type = 201
2014-09-22 15:17:53.066 Lync[299:3c2a218c] INFO UI CMUIUtil.mm/1708:Mapped error message is ‘Не удается подключиться к серверу. Проверьте сетевое подключение или адрес сервера и повторите попытку.

Не понимаю, что ему не нравится. Имена в сертификатах вроде все добавил.

источник