Установка клиентов Lync

Тема очень простая и избитая — установка софта на клиентские машины. Для массовых развертываний ПО существуют инструменты, такие как SMS, SCCM.  Если такого богатства нет — групповые политики.

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

Для установки сделал общую папку на сервере server1 в которую положил два дистрибутива x86 и x64 и два файла cmd, пример одного файла cmd ниже:

———————————————————-

IF EXIST «C:Program Files (x86)Microsoft Lynccommunicator.exe» GOTO End

server1Lync_installru_lync_2010_x64_615697.exe /install /Silent

IF %ERRORLEVEL%==0 (

echo Lync Installed on %computername% >> «server1Lync_installINSTALLEDx64!_%COMPUTERNAME%.txt»

) ELSE (

echo lync Failed on %computername%=%ERRORLEVEL% >> «server1Lync_installFAILEDx64!_%COMPUTERNAME%.txt»

)

:End

—————————————————————-

Скрипт проверяет наличие установленного клиента по установочному пути(можно сделать по какому то разделу в реестре) и если клиент установлен завершает работу. Далее производится установка и создается файл — при успешной установке INSTALLEDx64!_%COMPUTERNAME%.txt и при ошибке FAILEDx64!_%COMPUTERNAME%.txt по этим файлам я отслеживал на каком количестве АРМ установлен клиент.

С клиентами x86 аналогично, меняется только название дистрибутива.

Ну и последним шагом остается создать две политик, раскидать по политикам два CMD и назначить политикам WMI фильтры.

В случае если в продуктиве и Lync 2010 и Lync 2013 и разные ОС, можно так же добавлять другие WMI фильтры, а можно вставить рядок проверок в скрипты.

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

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

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

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

Роли сервера Edge

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

Access Edge роль

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

Web Conferencing роль

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

Audio/Video Edge

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

Служба XMPP

Обмен сообщениями протокола 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

Требования к DNS для сервера Edge указаны в разделе Разворачиваем Lync 2013. Подготовка инфраструктуры 2.

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

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

Требования к сертификатам представлены в разделе Разворачиваем Lync 2013. Подготовка инфраструктуры 3.

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

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

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

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

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

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

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

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

Internet – 192.168.0.0/24

Internal – 172.16.0.0/24

DMZ External – 172.16.1.0/24

DMZ Internal – 172.16.2.0/24

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

Отношения между сетями:

Internet – DMZ External->NAT

DMZ Internal->Internal -> Routing.

Internet -> Internal — NAT

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

таблица 6.1 Сетевые настройки брандмауэра

таблица 6.2 Сетевые настройки для сервера Edge

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

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

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

IP№15->IP№6

IP№16->IP№7

IP№17->IP№8

IP№18->IP№10

IP№19->IP№11

IP№20->IP№12

IP№21->IP№14

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

Таблица 6.3. Требования к портам для «внешнего» и «внутреннего» сетевых адаптеров сервера Edge.

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

Шаги развертывания Edge

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

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

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

Разворачиваем Lync 2013. Установка Lync Front End 5

Начальную установку  и настройку Lync Front End можно разделить на несколько этапов:

1. Установка необходимых компонент для Lync 2013
2. Настройка общей папки Lync
3. Создание и публикация топологии
4. Настройка локальной базы данных
5. Установка компонентов Lync
6. Установка сертификатов
7. Запуск сервисов Lync

Установка необходимых компонент для Lync 2013 Front End

Необходимые компоненты и обновления Windows 2008 R2 для Lync 2013 указаны в статье Lync 2031 Required Components.

Настройка общей папки Lync

Общую папку рекомендуется размещать на отказоустойчивом файловом хранилище. Поддерживается DFS, File Cluster.

В тестовой среде папка LyncShare создана на контроллере домена dc01.

Настройка SACL для LyncShare

Share Permissions

Удалить Everyone и добавить csAdministrators –Full Control

NTFS Permissions

Добавить Everyone –Read&Execute

Создание и публикация топологии

Для настройки топологии необходимо установить на сервер инструмент Topology Builder. Для публикации топологии учетная запись пользователя должна входить в группы: Domain Admins, RTCUniversalServerAdmins, локальный администратор LyncFE01.

Запустить Topology Builder

Указать SIP домен

Указать дополнительный SIP домены при необходимости

Создать новый сайт Lync

Указать детали сайта(Город, Область, Регион)

Далее переходим к созданию в топологии пула серверов Front End

Создание нового пула Front End

Указание FQDN пула(необходимо указать FQDN имя Active Directory)

Указать имена серверов в пуле(так же указывать FQDN компьютера в Active Directory)

Выбрать желаемый функционал( в случае если на этом этапе не выбран какой-либо функционал пула, его можно будет включить после первоначальной настройки)

Mediation Server будет совмещен с сервером Front End.

Так как инфраструктура для сервера Edge не подготовлена, шаг создания его в топологии пропущен

Создание сервера Back End в топологии Lync

На этом шаге необходимо указать заранее созданную папку Lync

Создание Web Services URL для внутренних подключений используется домен uc.loc, для внешних подключений uc.org.

Сервер OWA не развернут, поэтому его определим в топологии позже.

После того, как все шаги первоначальной настройки пройдены, можно изменить SIMPLE URL, так как это определено на этапе проектирования DNS.

После того, как топология создана ее необходимо опубликовать, а перед этим создать необходимые базы данных включая Central Management Database

Создать CMS:

Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn lynbe01.uc.loc -SqlInstanceName RTC -UseDefaultSQLPaths -Report «C:\logs\InstallCMS.html»

После успешного выполнения команды – в SQL создается база XDS и lis. Ключ –UseDefaultSQLPaths – указывает, что файл базы данных и журналы транзакций будут размещены в директории MSSQL/DATA.

Примеры и описание ключей Install-CsDatabase

После того, как база CMS создана можно опубликовать топологию:

Выбор опции публикации топологии

Выбор сервера Central Management

Дополнительные базы можно создать позже с помощью командлета Install-CsDatabase

Результаты публикации

Создание дополнительных баз данных Lync

Install-CsDatabase -ConfiguredDatabases -SqlServerFqdn Lyncbe01.uc.loc -ForInstance RTC -UseDefaultSqlPaths -Report «C:\logs\InstallDatabases.html»

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

Когда все базы были созданы в процессе публикации топологии возникли следующие предупреждения

На сколько я понял SQL Server Recover Interval это максимальное время восстановления при монтировании базы данных:

"Use the recovery interval option to set the maximum number of minutes per database that Microsoft® SQL Server™ needs to recover databases. Each time an instance of SQL Server starts, it recovers each database, rolling back transactions that did not commit and rolling forward transactions that did commit but whose changes were not yet written to disk when an instance of SQL Server stopped. This configuration option sets an upper limit on the time it should take to recover each database. The default is 0, indicating automatic configuration by SQL Server. In practice, this means a recovery time of less than one minute and a checkpoint approximately every one minute for active databases."

По умолчанию значение 0, для Lync предлагают использовать 5, тем не менее предупреждения являются не критичными и их можно игнорировать.

Дальнейшие шаги выполняются из меню …

Настройка локальной базы данных

Выбрать Step 1 Install Local Configuration Store

Выбрать опцию Retrieve directory from Central Management Store 

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

Для установки компонентов Lync необходимо выбрать Step 2 Setup or Remove Lync Server Components

Установка сертификатов

Сертификат создан заранее, поэтому на этом этапе их необходимо скопировать на сервер, поместить в хранилище сертификатов и назначить сервисам Lync, выбрав Step 3 Request, Install or Assign Certificates.

Запуск сервисов

После установки сертификатов нужно будет запустить сервисы Lync. Для удобства можно воспользоваться помощником Step 4: Start Services.

После запуска сервисов я обнаружил, что сервис Front End находится в состоянии Starting. При этом в журнале раздел, Lync отображается предупреждение:

Компонент User Replicator  периодически обновляет информацию о пользователях Active Directory и синхронизирует с БД Lync. По умолчанию User Replicator  выполняет синхронизацию со всеми доменами леса. В случае если сервер Lync FE не может подключиться к какому либо домену служба Lync Server Front-End не переходит в состояние Started.

Существует несколько вариантов решения вопроса:

1. Открыть доступ для сервера Lync FE ко всем доменам( выбранным контроллерам или всем) леса.
2. Ограничить область синхронизации с помощью Set-CsUserReplicatorConfiguration (http://technet.microsoft.com/en-us/library/gg398540.aspx)

После того, как сервер LyncFE01 установлен, можно приступить к установке сервера LyncFE02.

Установка LyncFE02 состоит из пунктов:

1. Установка необходимых компонент для Lync 2013
2. Настройка локальной базы данных
3. Установка компонентов Lync
4. Установка сертификатов

*В случае если для всех серверов Front End используется один сертификат, его необходимо импортировать на сервер LyncFE02.uc.loc

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

Разворачиваем Lync 2013. Установка Lync Back End 4

В данной части приведено описание установки SQL сервера Back End.

Общие требования для серверов SQL:

Microsoft SQL Server 2008 R2

Microsoft SQL Server 2012

Выделенный сервер

Lync 2013 не поддерживает:

32-бит редакции SQL

SQL Server Web Edition и SQL Server Workgroup

Технологии отказоустойчивости:

SQL Clustering не поддерживается в случае нового развертывания инфраструктуры Lync 2013

В случае обновления предыдущих версий до Lync 2013 и когда SQL Back End уже определен в топологии Lync, допускается использования текущего сервера SQL, но рекомендуется переход на SQL Mirroring

В моем случае был установлен один сервер SQL 2008 R2 на Windows 2008 R2, процесс инсталляции описан ниже.

Выбрать пункт новой инсталляции

Указать ключ продукта

Согласится с лицензионным соглашением

Установить файлы поддержки для продолжения инсталляции

Указать роль

Указать компоненты для выбранной роли

Выбор места хранения экземпляра RTC, в данном сценарии местом хранения баз данных RTC является диск E:\

Проверка требований для дисков

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

Настройка доступа к базам экземпляра RTC

Настройка отправки уведомлений об ошибках

Проверка требований перед установкой

Финальная информация перед установкой.

После того, как сервер SQL 2008 R2 будет установлен, необходимо установить Service Pack 1 для SQL 2008 R2 и перезагрузить сервер.

Необходимо обратить внимание на требование для брандмауэров. В моем случае не сервере SQL работал Windows Firewall.

Протокол	Порт	Направление	Сервис
TCP	1433	Входящий	Экземпляр SQL по умолчанию
UDP	1434	Входящий	SQL Server Browser
TCP	Статический порт для экземпляра RTC*	Входящий	Экземпляр SQL RTC

*Для того, чтобы определить порт для экземпляра RTC необходимо открыть:

SQL Configuration Manager ->SQL Server Netwrok Configuration ->Protocols for RTC

Разворачиваем Lync 2013. Подготовка инфраструктуры 3

Для всех серверов инфраструктуры Lync требуется настроить сертификаты, кроме SQL Lync Back End. Общие требования для сертификатов следующие:

Все сертификаты должны поддерживать server authorization(Server EKU)

Все сертификаты должны содержать CRL Distribution Point (без HTTP CDP Windows Phone 8 не будут подключаться к Lync 2013)

Поддерживается следующая длинна ключа: 1024, 2048(по умолчанию), 4096

Алгоритм шифрования по умолчанию RSA. ECDH_P256, ECDH_P384, и ECDH_P521 алгоритмы хэширования так же поддерживаются.

Сертификат Front End сервера

c	Значение
Тип Шаблона	WebServer
Экспортируемый закрытый ключ	Да
Длинна ключа	2048
subject name/Common name	LyncPoolFE01.uc.loc
Subject Alternative DNS Name	LyncPoolFE01. uc.loc
	LyncpoolFE01.uc.org
	Lyncdialin. uc.org
	Lyncmeet. uc.org
	LyncAdmin. uc.org
	LyncIntWeb. uc.loc
	LyncExtWeb. uc.org
	LyncDiscoverInternal.uc.org
	Lyncdiscover.uc.org
	LyncFE01. uc.loc
	LyncFE02. uc.loc

Сертификат для HLB

Параметр	Значение
Тип Шаблона	WebServer
Экспортируемый закрытый ключ	Да
Длинна ключа	2048
subject name/Common name	LyncIntWeb. uc.loc
Subject Alternative DNS Name	LyncIntWeb. uc.loc
	Lyncdialin. uc.org
	Lyncmeet. uc.org
	LyncAdmin. uc.org

Сертификат для Edge. Внешний адаптер

Параметр	Значение
Тип Шаблона	WebServer
Экспортируемый закрытый ключ	Да
Длинна ключа	2048
subject name/Common name	Sip.uc.org
Subject Alternative DNS Name	Sip.uc.org
	LyncWebCon.uc.org

В Lync 2013 Preview имеется возможность добавлять сертификат или имя в сертификат для AV Edge.

Более подробное описание:

http://blogs.technet.com/b/nexthop/archive/2012/10/09/lync-server-2013-preview-using-set-cscertificate-for-audio-video-edge-and-oauthtokenissuer-certificate-maintenance.aspx

http://technet.microsoft.com/en-us/library/gg398920.aspx

Сертификат для Edge. Внутренний адаптер

Параметр	Значение
Тип Шаблона	WebServer
Экспортируемый закрытый ключ	Да
Длинна ключа	2048
subject name/Common name	LyncPoolEdge01.uc.loc

Сертификат для обратного проксирующего сервера

Параметр	Значение
Тип Шаблона	WebServer
Экспортируемый закрытый ключ	Да
subject name/Common name	LyncExtWeb.uc.org
Subject Alternative DNS Name	LyncExtWeb.uc.org
	LyncDialin.uc.org
	LyncMeet.uc.org
	Lyncdiscover.uc.org

Сертификат для Office WAC.

Параметр	Значение
Тип Шаблона	WebServer
Экспортируемый закрытый ключ	Да
Длинна ключа	2048
subject name/Common name	LyncWAC.uc.org

Сертификаты должны быть установлены в хранилище компьютера.

Разворачиваем Lync 2013. Подготовка инфраструктуры 2

Подготовка DNS

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

Разберем случай когда внутреннее пространство имен DNS и внешнее различны.

Имя домена Active Directory — uc.loc и branch.uc.loc

Внешняя  зона  — uc.org.

SIP домен – uc.org.

Ниже на рисунке 2.1 представлена общая архитектура инфраструктуры Lync

Рисунок 2.1. общая архитектура инфраструктуры Lync

• Два сервера Front End Enterprise объединенных в пул;
• Один сервер SQL;
• Два сервера Edge объединенных в пул;
• Один сервер Web App;
• Один сервер обратный прокси;
• Создание федерации не планируется.

Для того, чтобы таблица именования была более общей, вместо конкретных значений IP, будут указаны номера.

Тип DNS	Тип Записи	Именование	Описание	№ IP-адрес
Front End сервер
Внутренний DNS	A	LyncFE01.uc.loc	FQDN сервера в зоне uc.loc	1
Внутренний DNS	A	LyncFE02.uc.loc	FQDN сервера в зоне uc.loc	2
Внутренний DNS	A	LyncPoolFE01.uc.loc	FQDN пула в зоне uc.loc	1
Внутренний DNS	A	LyncPoolFE01.uc.loc	FQDN пула в зоне uc.loc	2
Внутренний DNS	A	LyncPoolFE01.uc.org	FQDN пула в зоне uc.org	1
Внутренний DNS	A	LyncPoolFE01.uc.org	FQDN пула в зоне uc.org	2
Внутренний DNS	SRV	_sipinternaltls.uc.org	Авто обнаружение для внутренних клиентов.
Hardware Load Balancing
Внутренний DNS	A	LyncIntWeb.uc.loc	Внутренний Web Url	3
Внутренний DNS	A	LyncDialin.uc.org	FQDN для Dialin конференций	3
Внутренний DNS	A	LyncMeet.uc.org	FQDN для подключений к конференциям	3
Внутренний DNS	A	LyncAdmin.uc.org	FQDN для администрирования	3
Внутренний DNS	A	LyncDiscoverInternal.uc.org	Авто обнаружение для мобильных клиентов	3
Edge сервер
Внешний DNS	A	Sip.uc.org	служба Access Edge	15
Внешний DNS	A	LyncWebCon.uc.org	служба веб-конференций сервера Edge	16
Внешний DNS	A	LyncAV.uc.org	служба аудио-видео сервера Edge	17
Внешний DNS	A	Sip.uc.org	служба Access Edge (балансировка)	18
Внешний DNS	A	LyncWebCon.uc.org	служба веб-конференций сервера Edge(балансировка)	19
Внешний DNS	A	LyncAV.uc.org	Служба аудио-видео сервера Edge(балансировка)	20
Внешний DNS	SRV	_sip._tls.uc.org	Авто обнаружение внешних клиентов
Внутренний DNS	A	LyncEdge01.uc.loc	FQDN сервера	9
Внутренний DNS	A	LyncEdge02.uc.loc	FQDN сервера	13
Внутренний DNS	A	LyncPoolEdge01.uc.loc	FQDN пула серверов Edge для подключения внутренних клиентов	9
Внутренний DNS	A	LyncPoolEdge01.uc.loc	FQDN пула серверов Edge для подключения внутренних клиентов	13
Обратный прокси сервер
Внешний DNS	А	LyncDialin.uc.org	FQDN для Dialin конференций	21
Внешний DNS	А	LyncMeet.uc.org	FQDN для подключений к конференциям	21
Внешний DNS	А	LyncExtWeb.uc.org	Внешний Web URL	21
Внешний DNS	А	Rproxy.uc.org	FQDN сервера в зоне uc.org(не обязательно)	21
Внешний DNS	А	LyncDiscover.uc.org	Авто обнаружение для мобильных клиентов, подключенных к внешней сети «Интернет».	21
Внутренний DNS	А	Rproxy.uc.loc	FQDN сервера	14
Внутренний DNS	A	LyncDiscover.uc.org	Авто обнаружение для мобильных клиентов, подключенных к внутренней сети	14
SQL сервер
Внутренний DNS	A	LyncBE01.uc.loc	FQDN сервера в зоне uc.loc	4
Lync Office Web App Server
Внутренний DNS	A	LyncWAC.uc.org	FQDN сервера во внутренней зоне uc.org	5
Внешний DNS	A	LyncWAC.uc.org	FQDN сервера в зоне uc.org	22

Ниже представлены более подробно записи SRV:

Автоматическое обнаружение для внешних клиентов

_sip._tls.uc.org SRV service location: _sip._tls.uc.org

priority       =  0

weight         =  0

port           = 443

svr hostname   = sip.uc.org

Автоматическое обнаружение для внутренних клиентов

_sip._tls.uc.org SRV service location: _sipinternaltls._tcp.uc.org

priority       =  0

weight         =  0

port           = 5061

svr hostname   = LyncPoolFE01.uc.org

Источники:

DNS Requirements: http://technet.microsoft.com/en-us/library/gg398386.aspx

Lync 2013 Autodiscover: http://blog.schertz.name/2012/12/lync-2013-client-autodiscover/

Разворачиваем Lync 2013. Подготовка инфраструктуры 1.

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

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

Продуктивная среда состояла приблизительно из 20 доменов, которые обслуживали порядка 60 контроллеров домена. Серверы Lync были развернуты в корневом домене. Учетные записи пользователей Lync так же находились в корневом домене.

В подготовительные этап обычно входит:

1. Подготовка Службы Каталогов Active Directory

2. Подготовка инфраструктуры DNS

3. Подготовка сертификатов

Подготовка Службы Каталогов Active Directory

Предварительные требования, для Lync 2013  описаны в статье Active Directory Infrastructure Requirements.

Изначально необходимо убедиться, что текущая инфраструктура не была подготовлена для других версии Lync или OCS/LCS.

Для того, чтобы определить была ли служба каталогов подготовлена ранее, необходимо посмотреть в разделе схемы наличие объекта CN=ms-RTC-SIP-SchemaVersion, версия ПО определяется с помощью значения атрибута rangeUpper:

Версия	rangeUpper
LCS 2005 sp1	1006
OCS 2007	1007
OCS 2007 R2	1008
Lync 2010	1100
Lync 2013	1150

В моем случае, выяснилось, что один из регионов пытался внедрить Live Communications Server 2005, соответственно в разделе схемы был найден объект CN=ms-RTC-SIP-SchemaVersion:

Далее был добыт дистрибутив LCS 2005 SP1 и с помощью утилиты LcsCmd, которая находится в каталоге «Setup/I386» проверена подготовка схемы, леса и домена(ов):

Проверка схемы:

LcsCmd /forest /action:checkschemaprepstate /l:c:\logs\checkschema.html

Результат:

Проверка леса:

LcsCmd /forest /action:checkforestprepstate /l:c:\logs\checkforest.html

Результат:

Проверка домена uc.loc:

LcsCmd /domain:uc.loc /action:checkdomainprepstate /l:c:\logs\checkdomain.html

Для LCS 2005 так же была характерна еще одна процедура — это «DomainAdd» которая предназначалась для наделения правами группы RTCDomainServerAdmins разрешениями для управления Live Communication Server, настройками, размещенными в корневом домене.

Если uc.loc корневой домен, а branch.uc.loc дочерний, команда выглядит следующим образом:

LcsCmd.exe /domain:uc.loc /action:CheckDomainAddState /refdomain:branch.uc.loc /l:c:\logs\checkdomainadd.html

Результаты:

Live Communications Server 2005 хранит настройки в Active Directory в доменной партиции в разделе System/Microsoft/RTC Service

В разделе Pools находятся находятся серверы Standart или пулы серверов Enterprise. В разделе Global Settings собственно хранятся глобальные настройки инфраструктуры LCS.

В случае если оставить все как есть, при подготовке Active Directory настройки для Lync 2013 будут добавляться в этот же контейнер, это сделано для совместимости продуктов. Размещение контейнера с настройками Lync в разделе домена имеет ряд недостатков и в следующих версиях после LCS 2005 Microsoft решил пересмотреть место хранения настроек и определил стандартную для многих приложений партицию конфигурации. Учитывая эти факты, а так же учитывая, что LCS 2005 в инфраструктуре заказчика уже давно не было — было решено удалить все «хвосты» LCS 2005 в Active Directory. Фактически требовалось удалить пулы серверов, контейнер RTC Service, группы RTC*, а так же ACE из ACL на контейнерах в Active Directory.

Удаление контейнера и групп вручную в принципе возможно, но идеологически не верно — как минимум в ACL останутся SIDы удаленных групп — весь этот мусор не радует глаз добросовестного администратора :). Поэтому удаление необходимо производить с помощью средств LCS 2005.

Удаление инфраструктуры LCS 2005 производится в три этапа:

1. Деактивация компонент

2. Удаление файлов LCS

3. Удаление подготовки домена и леса.

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

Деактивация Standard Edition:

lcscmd.exe /Server:lcs.branch.uc.loc /Role:SE /Action:Deactivate /Force /refdomain:branch.uc.loc

После того, как сервер деактивирован, контейнер RTC Service/Pools будет пустым.

Далее предстоит удалить разрешения, которые были созданы с помощью DomainAdd для домена branch.uc.loc:

LcsCmd.exe /domain:uc.loc /action:DomainRemove /refdomain:branch.uc.loc /l:c:\logs\remove_domainadd.html

Проверка:  LcsCmd.exe /domain:uc.loc /action:CheckDomainAddState /refdomain:branch.uc.loc /l:c:\logs\checkdomainaddremove.html

После этого можно приступать к удалению подготовки доменов

Lcscmd /domain:branch.uc.loc /action:domainunprep /l:c:\logs\uc.loc_unprepdom.html

Lcscmd /domain:uc.loc /action:domainunprep /l:c:\logs\uc.loc_unprepdom.html

При этом должны удалиться группы RTC*, а так же записи ACE с этими группами на контейнерах в разделе домена

Результаты проверки подготовленности домена uc.loc

Остался последний шаг, это удаление подготовленности леса

Lcscmd /forest /action:forestunprep /l:c:\logs\forest_unprep.html

Результаты выполнения команды:

Результаты проверки подготовленности леса:

С помощью ADSIEdit можно убедиться, что контейнер RTC Service удален.

Для нашей продуктивной среды в этом пункте был один существенный нюанс. Команда forestunprep удаляет весь контейнер Microsoft, но кроме контейнера RTC Service присутствовал еще один контейнер от какого-то сервиса. Результат удаления данного контейнера был не предсказуем. В результате тестирований удаление подготовки леса LCS 2005 проводилось с помощью дистрибутива OCS 2007, аналогичной командой. При выполнении forestunprep с дистрибутива OCS 2007, контейнер Microsoft не удаляется и при этом результаты проверки подготовленности леса с помощью дистрибутива LCS 2005 показывали, что лес не подготовлен.

После выполнения команды forestunprep необходимо дождаться репликации глобальных каталогов во всем лесе. Вручную удостовериться, что контейнер RTC Service удален, можно с помощью ADSIEdit, подключившись к TCP 3268 “dc=uc, dc=loc”

На этом удаление подготовки инфраструктуры от Live Communication Server 2005 была завершена, осталось выполнить подготовку схемы, леса и домена для Lync 2013.

Подготовка Active Directory для Lync 2013 состоит из трех этапов:

• Подготовка схемы;
• Подготовка леса;
• Подготовка домена.

Все изменения, которые вносятся в Active Directory описаны в статье Active Directory Schema Extensions, Classes, and Attributes Used by Lync Server 2013

Подготовка Службы Каталогов для Lync 2013 в отличие от предыдущих версий производится с помощью Lync PowerShell. Поэтому для подготовки Active Directory мной использовался сервер, предназначенный для Lync Front End.

Подготовка сервера:

• Установка Microsoft .NET Framework 4.5
• Установка Windows Power Shell 3.0 (пакет Windows6.1-KB2506143-x64.msu)

Проверка текущей версии Powershell:

get-host | Select-Object version

После установки Powershell, номер версии должен быть 3.0

• Установка Windows Identity Foundation (пакет Windows6.1-KB974405-x64.msu)
• Установка компонент:

Import-Module ServerManager

Add-WindowsFeature Web-Dyn-Compression,desktop-experience,RSAT-ADDS,Web-Server,Web-Scripting-Tools,Web-Windows-Auth,Web-Asp-Net,Web-Log-Libraries,Web-Http-Tracing,Web-Stat-Compression,Web-Default-Doc,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Http-Errors,Web-Http-Logging,Web-Net-Ext,Web-Client-Auth, Web-Filtering,Web-Mgmt-Console,Msmq-Server,Msmq-Directory

• Установка исправления KB 2646886
• Установка Silverlight(необязательно)

Инсталляция Microsoft Visual C++ Minimum Runtime

Инсталляция основных компонент Lync Server 2013

Для подготовки схемы необходимо:

• Убедиться, что на контроллере с ролью «схема мастер» разрешен удаленный доступ к реестру:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg
Description: REG_SZ
Value: Registry Server
Проверить ACL winreg на предмет того, какого уровня доступа и какой группе разрешен доступ.

• Запустить Lync Server Management Shell(Start->All Programs->Microsoft Lync Server 2013) с правами схема мастера корневого домена и локального администратора на компьютере с ролью схема мастера.
•  Выполнить Install-csAdserverSchema –verbose –Report c:\logs\reportschema.html
• Убедиться, что репликация между всеми контроллерами леса прошла успешно.

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

Get-CsAdServerSchema -Report c:\logs\verify_schema.html

Результат:

(рассмотреть в мониторе как работает этот цмдлет)

Я считаю, что переходить к подготовке леса не убедившись, что репликация изменений схемы между всеми доступными контроллерами прошла — не совсем корректно. По крайней мере при этом сохраняется контроль над процессом обновления Active Directory, и  в случае каких то проблем администратор решает проблемы последовательно и переходит к следующему этапу обновления. Возможно, что такой подход не экономит время, но однозначно экономит нервы :). На обновление 20 доменов(60 контроллеров) было потрачено около трех часов.

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

Скрипт в соответствии с списком контроллеров (DomainControllers.txt) отображает название контроллера, значение rangeUpper, значение rangeLower. Файл DomainControllers.txt формируется вручную.

—————————————————————————————————————————————————-

strFileName = «DomainControllers.txt»

Set objFSO = CreateObject(«Scripting.FileSystemObject»)
If (objFSO.FileExists(strFileName)) Then

Set f = objFSO.OpenTextFile(strFileName, 1, False)
Do While (f.AtEndOfStream <> true)
strDCName = f.Readline
set Obj = GetObject(«LDAP://» & strDCName & «/CN=ms-RTC-SIP-SchemaVersion,CN=Schema,CN=Configuration,DC=mbrd,DC=ru»)

WScript.Echo now & «,» & strDCName & «,» & obj.rangeUpper & «,» & obj.rangeLower

Set Obj = nothing

Loop

End If

—————————————————————————————————————————————————-

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

Команда для подготовки леса:

Enable-CsAdForest –GroupDomain uc.loc –GlobalCatalog dc01.uc.loc –Verbose –Report c:\logs\EnableForest.html

Экспериментально было замечено, что если команда Enable-CsAdForest не содержит атрибуты GroupDomain и GlobalCatalog подготовка леса заканчивалась с ошибкой:

После того, как лес подготовлен в конфигурационной партиции появится контейнер «RTC Services»

А так же в оснастке ADUC в контейнере Users появятся новые группы CS* и RTC*.

Для проверки обновления леса на контроллерах так же был сделан маленький скрипт:

—————————————————————————————————————————————————-

Содержание файла test-forest.ps1

import-csv .\DomainControllers.txt | foreach-object {
$DC = $_.DC

$Result = get-csAdForest -GlobalSettingsDomainController $DC

write-host «$result $dc»

}

—————————————————————————————————————————————————-

Содержание файла DomainControllers.txt

DC

dc01.uc.loc

dc02.branch.uc.loc

—————————————————————————————————————————————————-

Ниже представлен результат выполнения сценария. В нем видно, что dc01.uc.loc подготовлен, а до dc02.branch.uc.loc обновление еще не дошло.

Осталась только подготовка домена. Для того, чтобы подготовить домен uc.loc необходимо воспользоваться командой:

Enable-csaddomain -domain uc.loc -report c:\logs\prepdomain.html

Тут так же существует небольшой нюанс — имя домена должно быть FQDN, иначе отображается ошибка:

Проверить подготовку домена можно с помощью команды

Get-csaddomain -domain uc.loc -report c:\logs\prepdomain.html

Результат выполнения команды:

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

На этом подготовку Службы Каталогов можно считать завершенной.

Мои выводы:

• Перед подготовкой Active Directory необходимо воспроизведение всей процедуры на тестовом стенде.
• Контроллер(ы) тестового стенда должны содержать экземпляр Службы Каталогов, которая работает в продуктивной среде.
• На создание тестового стенда и тестирования необходимо выделить 4-5 дней.
• В не зависимости от полученной информации в ходе интервью с администраторами инфраструктуры всегда проверять инфраструктуру Active Directory на соответствие минимальным требованиям Lync 2013 и на существование в инфраструктуре предыдущих версий ПО.
• При обновлении Active Directory переходить к следующим этапам только после завершения предыдущих.

Lync 2013 Required Components

Установка Lync 2013 ничем не отличается от Lync 2010. Ниже представлены компоненты, необходимые для установки Lync 2013 Standard Edition.

1. Установка Microsoft .NET Framework 4.5

2. Установка Windows Power Shell 3.0 (пакет Windows6.1-KB2506143-x64.msu)

Проверка текущей версии Powershell:

get-host | Select-Object version

После установки Powershell, номер версии должен быть 3.0

3. Установка Windows Identity Foundation (пакет Windows6.1-KB974405-x64.msu)

4. Установка предварительных IIS компонент

Import-Module ServerManager

Add-WindowsFeature Web-Dyn-Compression,desktop-experience,RSAT-ADDS,Web-Server,Web-Scripting-Tools,Web-Windows-Auth,Web-Asp-Net,Web-Log-Libraries,Web-Http-Tracing,Web-Stat-Compression,Web-Default-Doc,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Http-Errors,Web-Http-Logging,Web-Net-Ext,Web-Client-Auth, Web-Filtering,Web-Mgmt-Console,Msmq-Server,Msmq-Directory

5. Установка исправления

FIX: Heap corruption occurs when a module calls the InsertEntityBody method in IIS 7.5

6. Установка Silverlight

Установка Lync. Ресурсный лес часть 4.

 Во время проведения пилотных проектов основная задача, это показать Заказчику интересный ему функционал продукта. При этом изменения в продуктивной среде должны быть минимальны. Так как в ходе развертывания инфраструктуры Lync, есть необходимость в подготовки Службы Каталогов Active Directory, то изменения в инфраструктуру вносятся значительные, что не желательно.  В этом случае полезным будет развертывание инфраструктуры Lync в ресурсном лесу AD. Сценарий развертывания Lync в ресурсном лесу официально поддерживается Microsoft.

Общая схема решения следующая:

Forest1 ресурсный лес, в котором находятся отключенные объекты пользователей с включенными атрибутами Lync(Lync enabled). Forest2 лес, в котором находятся пользователи, которые будут подключаться к Lync. Межу Forest1 и Forest2 настроены двух сторонние доверительные отношения Forest Trust.

Каким образом пользователи из Forest2 получают доступ к серверу Lync в Forest1?

Для каждого пользователя из Forest2 создаются отключенные пользователи в Forest1 с идентичным набором атрибутов, а так же значение атрибута ObjectSid пользователя из Forest2 копируется в атрибут msRTCSIP-OriginatorSID пользователя из Forest1

На странице Populating the Required Attributes for Lync Server указаны атрибуты пользователей.

Копировать значение атрибута Object SID можно с помощью следующих способов:

1. Вручную с помощью ADSIEdit.msc

2. С помощью скрипта

3. С помощью Microsoft Identity Lifecycle Manager 2007 FP1 или Microsoft Identity Integration Server 2003 SP2

Первые два способа не требуют дополнительного ПО и подходят для тестовых и пилотных сред. В продуктивной среде используют Microsoft Identity Lifecycle Manager 2007 FP1 или Microsoft Identity Integration Server 2003 SP2 это обусловлено тем, что при создании пользователя в Forest2 автоматически создается отключенный пользователь в Forest1 с необходимыми атрибутами. Документация по настройке MIIS/ILM представлена в документе Deploying Lync Server 2010 in a Multiple Forest Environment.

В случае если в ресурсном лесе уже используется Exchange можно воспользоваться утилитой SID Mapping Tool по сути это скрипт который копирует SID из атрибута msExchMasterAccountSid в msRTCSIP-OriginatorSID.

Для создания пользователей в ресурсном лесу Forest1 я использовал свой скрипт.

Зайти на контроллер в Forest1, в Powershell запустить модуль AD и сменить директорию на C:\

Get-ADUser -SearchScope Subtree -SearchBase «OU=Lync_Users, DC=xxx, DC=yyy» -Filter * -server контроллерForest2:3268 -Properties ObjectSID, Name, samAccountName, displayName, givenName, surName, telephoneNumber, Mail | Export-csv -Path c:\forest2users.csv -Delimiter «;» -NoTypeInformation

$UPN = $_.SamAccontName+»@domain.lync»

Import-csv .\forest2users.csv -Delimiter «;» | foreach-object { New-ADuser -SamAccountName $_.SamAccountName -Name $_.Name -UserPrincipalName $UPN -emailaddress $_.mail -otherAttributes @{‘msRTCSIP-OriginatorSid’=$_.ObjectSID} -path «OU=Lync_users,DC=domain,DC=lync»}

*

Get-ADUser -собирает информацию о пользователях в лесу Forest2

Import-csv — создает пользователей в лесу Forest1

Клиент Lync на компьютерах Windows XP, Vista не может подключиться к серверу FrontEnd

При подключении клиента Lync к серверу Front End появляется следующая ошибка:

После просмотра лог файла SIP на FrontEnd сервере, стало понятно, что проблема кроется в расхождении настроек NTLM у сервера и клиента:

«There is a mismatch between ntlm security settings on client and server computer»

На сервере Windows 2008 R2 по умолчанию установлены следующие настройки в локальных политиках(Local Security Policy):

На клиентах Windows XP и Vista 128 битное шифрование не требуется и данные настройки отключены.

Для решения вопроса можно установить идентичные настройки на клиенте(с помощью редактора локальных групповых политик), либо убрать требование 128 битного шифрования не сервере.

KB: http://support.microsoft.com/kb/982021/en-us