Разворачиваем 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 переходить к следующим этапам только после завершения предыдущих.