Архив
Разворачиваем 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)
- Установка 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
welcometoviktorp 