Разворачиваем 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/

Manual removal of the deceased controller

Иногда слежу за веткой Technet Серверные ОС Windows  и с завидной периодичность пользователями задается один и тот же вопрос: «Я удалил контроллер домена из сети, как правильно удалить его останки..или остатки».

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

Зачем надо полностью удалять контроллер из службы каталогов и делать другие манипуляции?

В случае если контроллер был единственным глобальным каталогом или хозяином FSMO это приведет к проблемам работы Службы Каталогов Active Directory.

Исходные данные:

Один домен source.local

Один сайт SITE01

Контроллер dc01.source.local является глобальным каталогом

Контроллер dc03.source.local является глобальным каталогом, мастером ролей PDC и RID.

Сценарий

Сервер DC03.source.local вышел из строя, восстановить его не возможно.

Решение

Для начала необходимо проверить те пункты, без которых Служба Каталогов работать корректно не может.

Это прежде всего:

1. Являются ли оставшиеся контроллеры доменов серверами глобального каталога.

Оснастка Active Directory Sites and Services ->название_сайта->название_контроллера->NTDS Settings

2. Определить хозяина FSMO ролей

Для этого можно использовать утилиту netdom, что подойдет и для Windows 2000/2003

В моем случае вышедший контроллер был мастером PDC и RID.

Для того, чтобы все роли FSMO обслуживали Службу Каталогов Active Directory, оставшимся контроллерам необходимо получить недостающие роли, в моем сценарии это контроллер DC01.

Для передачи/получения ролей необходимо использовать утилиту ntdsutil и следующие команды:

ntdsutil

roles

connections

connect to server dc01

q

Seize PDC

Seize RID Master

q

quit

Для того чтобы, понять как пишутся другие роли, в меню fsmo maintenance можно набрать «?»

На рисунки ниже представлен весь процесс передачи ролей(вводимые команды подсвечены):

После того, как все роли были переданы на dc01, необходимо перезагрузить компьютер.

Процесс удаления

Сведения о конфигурации содержаться в объекте NTDS Settings, который является дочерним объектом для объекта-сервера в оснастке Active Directory Sites and Services.

Удаление NTDS Settings

ntdsutil

metadata cleanup

connection

connect to server dc01 # подключение к фунционирующему серверу

quit

select operation target

list sites # просмотр сайтов

select site 0 # подключение к сайту

list domains in site # просмотр доменов

select domain 0 # подключение к домену

list servers in site # просмотр контроллеров домена

select server 1 # подключение к серверу, который требуется удалить

quit

remove selected server # удаление сервера

После удаления сервера в оснастке Active Directory Sites and Services останется объект-сервер DC03 и соединители репликации в объектах NTDS Settings других серверов. Оставшиеся объекты удаляем вручную.

В ADUC проверяем, что учетная запись контроллера DC03 удалена.

В DNS так же остались записи от удаленного компьютера, поэтому их нужно будет удалить вручную.

Проверка и тестирование

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

Протестируйте репликацию:

repadmin /replsum

repadmin /showrepl

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

dcdiag /v

Убедитесь, что SPN для DC03 нет

setspn -l dc03

setspn -l dc03.source.local

Официальные источники:

Using Ntdsutil.exe to transfer or seize FSMO roles to a domain controller

Clean up server metadata

How to remove data in Active Directory after an unsuccessful domain controller demotion

Доверительные отношения, mystery?!

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

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

При создании доверительных отношений различных типов предъявляются требования к  DNS и NetBIOS разрешению имен.

Существуют следующие ограничения по именованию:

1. При создании Forest Trust в New Trust wizard удаленный домен указан с помощью NetBIOS имени.

2. NetBIOS имена доменов одинаковы.

3. DNS имена доменов одинаковы.

4. SID доменов одинаковые.

Возможно есть и другие ограничения DNS и NetBIOS, о которых я забыл упомянуть. (P.S. Если такие есть, сообщите пожалуйста — буду очень признателен.)

Что касается именования контроллеров доменов, то FQDN будут разные в любом случае, а вот NetBIOS имена могут быть и одинаковые, проверим как это работает…

Ок, схема тестового стенда представлена ниже:

Два леса. В каждом лесу по одному домену domain1.local и domain2.local. NetBIOS имена доменов domain1 и domain2. FQDN контроллеров dc.domain1.local и dc.domain2.local. Уровни лесов и доменов одинаковы — Windows 2008R2.

Попробуем настроить доверительные отношения между лесами(Forest Trust).

Первым шагом для разрешения имен между лесами. Способов несколько:

1. Условная пересылка

2. Зона заглушка

3. Вторичная зона

Проверять разрешение имен удобно с помощью утилиты nslookup.

 Шаги создания доверительных отношений с помощью New Trust wizard описаны на странице Create a forest trust

В процессе создания Forest trust удаленный домен необходимо указывать с помощью DNS имени.

Результат создания доверительных отношений (Forest Trust) отображен ниже:

Далее я посмотрел будут ли работать доверительные отношения в следующих сценариях:

-Два контроллера находятся в разных подсетях и разделены маршрутизатором

-В свойствах сетевых адаптерах на контроллерах доменов отключен  NetBIOS over TCP/IP

Результаты были идентичными.

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

В результате  решений проблемы, как я вижу несколько:

1. Переименование контроллера домена. Если на контроллере работают другие сервисы, например центр сертификации или сервер Exchange в этом случае переименовать контроллер не удастся.

2. Установить второй контроллер домена. Более надежный, но требует дополнительных ресурсов.

Если кто-то дочитал эту статью до конца и у него есть мысли буду рад на эту тему пообщаться, спасибо!

Exchange 2010 ActiveSync users cannot synchronize an EAS device for the first time

В инфраструктуре развернут один виртуальный сервер Exchange с ролями Mailbox, Hub, CAS. При попытке тестирования подключения к серверу Exchange с помощью ActiveSync на ресурсе testexchangeconnectivity отображается следующая ошибка:

Причина проблемы — группа Exchange Servers не имеет прав доступа к объекту почтового ящика пользователя в Active Directory. Нарушается наследование прав ACL в Active Directory. Если быть более точным, не хватает следующих прав доступа:

Для восстановления прав доступа необходимо зайти в закладку Security пользователя, далее Advanced активировать опцию «Include inheritable permissions from this object’s parent» и попробовать доступ к почтовому ящику используя Active Sync. Проблема с доступом к ActiveSync решена, но через некоторое время разрешения «Create, Delete» к объекту msExchActiveSyncDevices будут утеряны. Нехватка прав доступа может приводить к самым разным не предсказуемым проблемам.

Самостоятельные сбрасывания разрешений на объекты чаще всего связаны с AdminSDHolder.

AdminSDHolder — это объект-контейнер в разделе каталога домена CN=AdminSDHolder, CN=System,<Domain DN> — например, CN=AdminSDHolder, CN=System, DC=north, DC=com.

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

Каждый час на контроллере домена роли PDC выполняется процесс SDPROP, который просматривает текущие значения ACL защищаемых объектов групп и пользователей и значения объекта AdminSDHolder.  В случае не совпадения ACL защищаемых объектов устанавливаются идентичными ACL объекту AdminSDHolder.

Идентифицировать защищаемые объекты можно по атрибуту adminCount равному 1.

Get-ADUser -LDAPFilter "(objectcategory=person)(samaccountname=*)(admincount=1)"

Для решения проблем с доступом к объектам необходимо выполнить следующие действия:

1. Идентифицировать защищаемые объекты, выполнив следующую команду в Active Directory PowerShell:

Get-ADUser -LDAPFilter «(objectcategory=person)(samaccountname=*)(admincount=1)»

2. В соответствии с security best practise, для административных целей создать специализированные учетные записи, которые не должны иметь почтовые ящики и другие атрибуты Exchange.

3. После того, как учетные записи пользователей были удалены из защищаемых AdminSDHolder административных групп, значение атрибута admincount останется равным 1, поэтому необходимо вручную поменять значение атрибута на 0 (ноль).

4.  Восстановить права доступа см. выше.

После этого права доступа на объекты Exchange будут восстановлены и не будут утеряны после отработки процесса SDPROP.

О AdminSDHolder:

http://technet.microsoft.com/ru-ru/magazine/2009.09.sdadminholder(en-us).aspx

Exchange ActiveSync Returned an HTTP 500 Error:

http://technet.microsoft.com/en-us/library/620c5ce8-3595-4658-9a7a-ec76c10e4a69.aspx