Что характерно, машины с Win 98 используют аутентификацию в домене Active Directory. Кое-как всё работало, пока не стали обновлять контроллеры домена до Windows Server 2008 R2.

После долгих танцев с бубном было выяснено, что протокол шифрования DES не поддерживается на WS 2008 R2, а машины Win 98 его требуют для аутентификации в домене.

Мой коллега, будучи в душе гиком-крякером, вооружился дебаггером и полез искать разницу в бинарниках LSASS.exe между версиями WS 2008 SP2 (где DES работает) и WS 2008 R2 (не работает).

Как оказалось, код, обрабатывающий DES, был просто закомментирован (безусловным переходом), но остался в бинарнике. В глаза бросилась более интересная особенность: в одном из условных переходов выполнялось сравнение с довольно длинной константой. Методом тыка было установлено, что этот код отвечает за выдачу билетов Kerberos подсистемой KDC.

Дальше – интереснее. Как известно, при аутентификации через Kerberos клиент сначала запрашивает билет на получение билетов TGT у службы Authentication Service, при этом отправляя свой запрос открытым текстом + аутентификатор (штамп времени, зашифрованный долгосрочным ключом пользователя).

Дебаггер показал, что в коде LSASS.exe зашито сравнение штампа времени с константой в формате Time Stamp. Если перевести её в читаемый вид, получится:

1986-09-19 12:05:18 GMT+0

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

После составления Privilege Account Certificate для подавшего запрос пользователя, KDC генерирует Authentication Service Reply, который содержит действительный билет TGT и сессионный ключ, который (внимание!) зашифрован с помощью ключа на основе константы (строки из восемнадцати пробелов), а не реального пароля данного пользователя.

Таким образом, если знать правильные константы, то можно представиться для KDC произвольным пользователем и получить валидный билет TGT и сессионный ключ, с помощью которых далее можно невозбранно получать доступ на любых сервисах сети, поддерживающих Kerberos.

В версиях Windows Server до 2008 R2 такого поведения обнаружено не было. Интересно, если Microsoft предоставляет исходники своих ОС специальным службам государств для ознакомления, знают ли они об этой недокументированной особенности?

[update] В ходе дальнейшего исследования была установлена третья константа… Весь описанный выше механизм работает только при условии, что текущая системная дата равна 1 апреля.

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

Содержание:

• Epic fails
• .local или ICANN
• Выделить или совместить
• Split-brain
• Уточнить или обобщить
• Последние штрихи на пути к совершенству
• Рекомендую к прочтению

Epic fails

Single-label

Вырожденный случай, когда домену Active Directory было дано DNS-имя типа company (без точек), называется single-label. Такое имя полностью противоречит идеологии DNS и не поддерживается большинством серьезных приложений, работающих с AD. С подробностями можно ознакомиться в статье Information about configuring Active Directory domains by using single-label DNS names.

Домен с single-label именем не пригоден для использования в продуктивной среде, и единственный правильный путь — избавиться от него как можно скорее.

Недопустимые символы в имени домена

Например, знак подчеркивания. Хотя в предыдущих версиях Windows Server этот знак допускался при выборе DNS-имени домена, он не соответствует стандарту RFC 1123 для DNS. Новые версии Windows Server уже не позволяют называть домены наперекор стандарту. Если домен с именем, содержащим подчеркивание, был унаследован, ожидаются большие неприятности. Например, нельзя установить Exchange 2007 и выше. Решение одно — избавиться от недопустимых символов в имени домена с помощью миграции в другой домен (предпочтительно), либо процедуры переименования домена (небезопасно).

Подробности — в статье Naming conventions in Active Directory for computers, domains, sites, and OUs.

Disjoint namespace

Один из частных случаев Disjoint namespace — это ситуация, когда Netbios-имя домена отличается от крайней левой части DNS-имени домена.

Пример:

Netbios Name = TEST
DNS Name = lab.argon.pro

С точки зрения функциональности, такая конфигурация полностью поддерживается. Но я всё же рекомендую избегать её, чтобы не вносить путаницы и неоднозначности.

Подробнее — в статье Understanding Disjoint Namespace Scenarios.

.local или ICANN

Во многих учебных руководствах можно встретить названия доменов вида company.local. Действительно, нет никакого криминала в том, чтобы использовать такие имена в учебных и тестовых целях. Хуже, когда по той же схеме называют реальные домены:

• Имя противоречит идеологии глобального DNS: не даёт гарантии отсутствия коллизий с другими такими же доменами (когда придет пора устанавливать доверительные отношения)
• Отсутствует возможность использовать данное имя для доступа из глобальной сети (когда придет пора публикации)
• На домен, владение которым невозможно подтвердить, нельзя получить публичный SSL-сертификат

Поэтому я рекомендую при именовании домена всегда использовать официально зарегистрированное глобальное имя в иерархии ICANN (Internet Corporation for Assigned Names and Numbers), которое гарантированно избавит от описанных выше недостатков.

Примеры:

argon.pro
argon.com.ru
irom.info

Выделить или совместить

Представим, что мы проектируем доменную структуру для компании Argon, которая имеет сайт по адресу argon.pro, а также использует адреса электропочты в этом же домене. Велик соблазн назвать домен Active Directory как argon.pro, не правда ли? Но этого лучше не делать по следующим причинам:

• Если внутри сети такой организации в браузере ввести адрес http://argon.pro/, то попадём мы не на сайт компании, а на первый попавшийся контроллер домена.
• Администрирование публичных и внутренних DNS-записей затруднено: все публичные DNS-записи в зоне argon.pro, которые используются из внутренней сети должны быть продублированы на внутренней зоне DNS. Также необходимо как-то обеспечивать синхронизацию этих записей.

Например, в интернете есть сайт www.argon.pro. Чтобы пользователи из внутренней сети могли на него попасть, требуется создать аналогичную запись и во внутренней зоне DNS

• Есть вероятность возникновения коллизий между внутренними и внешними именами ресурсов.

Например, во внутренней сети широко используется сервер ftp.argon.pro. Внезапно возникла необходимость предоставлять пользователям интернета файловый сервис по тому же адресу ftp.argon.pro. Что получилось? Внутренние пользователи не могут подключиться к внешнему сервису по указанному имени…

Таким образом, для домена Active Directory лучше иметь выделенное имя, отличное от сайта компании. И здесь тоже есть выбор:

• Использовать для AD полностью другое имя (argon.pro для сайта, argon.com.ru для AD)
• Использовать для AD дочернее имя (argon.pro для сайта, lab.argon.pro для AD)

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

• поддержки зарегистрированных доменных имен (оплата регистрации и DNS-хостинга только одного домена)
• доступности красивых имён для регистрации (регистрировать не нужно)
• получения публичных SSL-сертификатов (всего один wildcard-сертификат можно использовать как для сайта компании, так и при публикации ресурсов внутренней сети)

Итак, предлагаю выбрать для AD выделенный, но дочерний относительно сайта организации домен.

Примеры:

lab.argon.pro
corp.microsoft.com

Split-brain

Split-brain DNS означает использование одного доменного имени для публикации ресурсов как во внутренней сети, так и в интернете. При этом DNS-сервера внутренней сети разрешают адреса вида portal.lab.argon.pro во внутренние IP-адреса, а публичные DNS-сервера в интернете, соответственно, во внешние IP. Пример:

За счет split-brain достигаются такие полезные вещи, как, единые адреса для доступа к ресурсам как из внутренней сети, так и из интернета. Пользователю достаточно знать один адрес portal.lab.argon.pro, по которому он может добраться до своих документов, и не важно, где он находится: в офисе компании или в гостинице.

Естественно, при к опубликованным наружу ресурсам должны применяться шифрование трафика и более строгие политики безопасности.

С точки зрения инфраструктуры, удобно иметь один и тот же адрес для СRL или OCSP в SSL-сертификатах, выпускаемых внутренними CA.

При отсутствии split-brain может возникнуть необходимость создавать так называемые pinpoint-зоны на внутренних серверах DNS, такие «точечные» зоны будут содержать только те записи, для которых нужно подменить «публичные» значения, на «приватные», характерные для внутренней сети (ситуация схожа с описанной под заголовком «Выделить или совместить»).

Пример pinpoint-зоны:

Уточнить или обобщить

В литературе можно встретить советы называть домены (особенно корневой) обобщенным словом, вроде Bank, Company или Corp. На то есть причины, так как в наше время компании могут регулярно переживать слияния и поглощения, смену торговой марки. А имя домена, как известно, поменять очень сложно.

С другой стороны, при том же слиянии и поглощении компаний весьма вероятна миграция пользователей из одного домена в другой. На практике мне встречалась ситуация, когда нужно было мигрировать пользователей из десятка доменов с одним и тем же именем Bank. Как известно, установка доверительных отношений между доменами с одинаковыми именами (будь то DNS или Netbios) не возможна. Придется либо переименовывать эти домены, либо мигрировать данные в два этапа, через третий домен.

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

Последние штрихи на пути к совершенству

Итак, если следовать моим рекомендациям, для домена AD мы выбираем имя:

• глобально зарегистрированное
• выделенное (дочернее от домена сайта компании)
• специфичное
• используем split-brain

Примеры:

lab.argon.pro
corp.microsoft.com

При этом для адресов электропочты и SIP-адресов в Lync было бы приятнее использовать более короткие адреса user@argon.pro. Ничто не мешает нам сделать это, но возникнут неудобства.

Адрес электропочты у пользователя = user@argon.pro, логин входа = lab\user, user principal name = user@lab.argon.pro. Здесь легко запутаться не только пользователю, но и программам вроде Outlook и Lync.

Чтобы избежать путаницы, я рекомендую в качестве user principal name задать наиболее знакомый пользователю адрес — электропочты. Для этого нужно в свойствах AD-домена lab.argon.pro добавить почтовый домен (в нашем случае — родительский) argon.pro в список поддерживаемых UPN-суффиксов.

После небольших модификаций учетных записей, пользователи будут иметь user principal name равным адресу электропочты. Путаницы станет меньше, а такие программы, как Lync и Outlook прекратят спрашивать логин пользователя, им будет достаточно знать e-mail или SIP адрес.

Рекомендую к прочтению

Мои фундаментальные труды:

• Проектирование схемы именования объектов
• О пустых корневых доменах в Active Directory

Однако действия по установке сертификата корневого CA на каждое устройство могут быть не удобны в масштабах большого предприятия. Выход из ситуации один: веб-службы Lync должны использовать публичный SSL сертификат, выпущенный CA из списка рекомендованных.

Задача осложняется тем, что Lync использует как внутренние пути к веб службам (на front end), так и внешние (на reverse proxy). Естественно, устанавливать публичный сертификат на внутренние веб-службы только для обеспечения совместимости с Lync Mobility не очень хочется.

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

Часть работы за нас уже сделали разработчики: служба автообнаружения Lync Mobility спроектирована использовать DNS-записи:

• lyncdiscoverinternal.lab.argon.pro для нахождения веб-служб Lync из внутренней сети
• lyncdiscover.lab.argon.pro — для внешней

В обоих случаях Lync Discover выдаёт клиентам редирект на адрес внешних веб-служб Lync.

Однако если для внешних и внутренних служб используется одно DNS-имя типа lsweb.lab.argon.pro (Split-Brain DNS, внутреннее имя домена AD совпадает с публичным именем в интернете), мы имеем серьезную проблему… В такой конфигурации внутренние мобильные клиенты не будут иметь способа подключиться к внешним службам, а всегда будет попадать на внутренние службы с внутренним SSL-сертификатом.

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

Следующий важный момент — на какой IP-адрес указывает DNS-запись для внешних веб-служб при разрешении из внутренней сети. Может показаться удобным направить DNS-имя для внешних веб-служб Lync на внутренний IP-адрес reverse proxy, через который осуществляется публикация. Но если подумать о такой особенности работы мобильных устройств, как частое переключение между WiFi и мобильным интернетом, то эта идея не подходит из-за проблем с кешированием DNS-записей:

1. Устройство через WiFi разрешает внутренний IP-адрес reverse proxy
2. Переключается на мобильный интернет
3. Находит в кэше DNS для имени внешних веб-служб Lync тот же внутренний IP адрес
4. Не может подключиться, пока не истечет срок жизни кэша DNS

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

Заключение

Для беспроблемной работы Lync Mobility из внутренней сети (WiFi) должны быть обеспечены следующие условия:

• Внешние веб-службы Lync должны использовать публичный SSL-сертификат, выданный рекомендованными поставщиками
• Запись DNS типа lyncdiscover.lab.argon.pro должна вести на публичный IP-адрес reverse proxy
• Запись DNS типа lyncdiscoverinternal.lab.argon.pro не требуется
• Адрес DNS для внешних веб-служб Lync должен отличаться от адреса внутренних веб-служб и разрешаться на один и тот же на публичный IP-адрес reverse proxy как из внутренней сети, так и снаружи

Источники вдохновения

• Комменты Саши Донина к предыдущей заметке
• Lync 2010 Mobility – Do I need lyncdiscoverinternal?
• Using Lync 2010 Mobility on your Corporate WIFI Networks

• Имеется один публичный SSL-сертификат на имя autodiscover.lab.argon.pro без списка альтернативных имён (SAN)
• Имеется только один свободный публичный IP-адрес
• Стоит задача при данных ограничениях опубликовать в интернете Remote Desktop Gateway и Exchange 2010 Outlook Anywhere

Обе технологии спроектированы для обеспечения доступа из максимально ограниченных сетей (NAT-ы, брандмауэры и прокси в любых сочетаниях), поэтому используют протокол HTTPS для инкапсуляции своего трафика и жестко привязаны к порту 443 для входящих соединений.

Имея в своём арсенале TMG, задача повесить несколько сервисов на один IP адрес с одним публичным именем в SSL-сертификате решается достаточно просто: один виртуальный каталог одного сервиса направляем на предоставляющий его сервер, другой каталог, соответственно, на другой сервер. Но в случае с RD Gateway и Outlook Anywhere есть загвоздка: оба сервиса используют один и тот же виртуальный каталог RPC. Это именно тот случай, что даже TMG нам помочь не может.

Однако, выход всё же есть… При данных ограничениях роль Remote Desktop Gateway можно установить на один сервер с Exchange 2010 CAS. В этом случае TMG будет пересылать запросы на один и тот же каталог RPC. При этом вероятно, что RDG без дополнительного допиливания будет не работать, а бесконечно спрашивать учетные данные пользователя.

Чтобы починить RDG, нужно в консоли IIS включить Windows Authentication для каталога RPC.

Но этого не достаточно, так как службы Exchange переодически возвращают директорию RPC к первоначальной конфигурации. Поэтому для стабильного приведения Remote Desktop Gateway в чувства требуется выполнить следующую команду из Exchange Management Shell:

Set-OutlookAnywhere -Identity "SERVER-NAME\Rpc (Default Web Site)" -IISAuthenticationMethods Basic,NTLM

Более подробоное описание команды Set-OutlookAnywhere в TechNet

В своё время статья Assigning Telephone Numbers to Lync Enterprise Voice Users открыла мне глаза на то, как правильно назначать телефонные номера пользователям Lync.

Вкратце основные выводы:

• Телефонный номер всегда должен быть в формате E.164 и глобально достижим, так как телефонные номера публикуются в адресных книгах и передаются партнёрам по федерации в Lync. Если пользователь не имеет прямого публичного номера, глобально достижимый номер должен содержать как общий телефонный номер компании, так внутренний номер.

Пример: tel:+14999269000;ext=1193

• Даже прямой публичный телефонный номер должен иметь соответствующий ему внутренний номер (extension) в компании. Причин для этого несколько:
  • Полный номер в формате E.164 человек в здравом уме вводить вручную откажется, поэтому в Lync нужно настроить правила нормализации, превращающие короткие номера в полный вид E.164.
  • Extension нужно вводить для авторизации при подключении к Lync Dial-in конференциям.
  • Автоответчик Exchange UM понимает только внутренние номера, телефонные номера в формате E.164 выше его понимания.

Пример: tel:+14999269193;ext=9193

Хотя пользователь имеет прямой публичный номер, ему присвоен внутренний номер, повторяющий последние 4 цифры публичного номера.

Итак, мы убедились, что назначать пользователям Lync номера в глобально достижимом формате с расширением — нужно и полезно. Однако, если мы забьём в таком виде (+149992699193;ext=9193) все телефонные номера в свойства учеток AD, пользователи не одобрят. К счастью, Address Book Service в Lync способен понимать следующий формат:

+1 (499) 926 9193 X9193

Согласитесь, вполне понятно и читаемо, к тому же поддерживается Outlook: код города и внутренний номер занимают положенные им места в карточках контактов.

Address Book Service, следуя своим встроенным правилам нормализации, преобразует номер из +1 (499) 926 9193 X9193 из учетки в AD в понятный Lync формат E.164 tel:+14999269193;ext=9193.

До текущего момента все спокойны и счастливы! Но, внезапно, нам понадобилось использовать российские телефонные номера, которые начинаются на +7.

Как оказалось, Lync по-разному отображает номера, относящиеся к США (код +1) и всему остальному миру.

Было создано два пользователя с различиями только в коде страны в номерах телефона:

Теперь взглянем на карточки контактов в Lync у данных пользователей…

Что же мы видим:

• Телефонные номера Alice приобрели скобочки для кода региона и дефисы-разделители, которых изначально не было.
• Телефонные номера Bob потеряли все форматирование (пробелы), и также внутренний рабочий номер. В таком виде не просто неудобно читать, да ещё и полной информации не отображается. Хотя номер остается кликабельным и дозвон осуществляется правильно: не на общий номер, а с учетом внутреннего номера.

Теперь же попробуем позвонить Alice и Bob по их коротким номерам:

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

Вывод из заметки:

На стороне клиента Lync происходит дискриминация по телефонному коду страны. Не зависимо от правил нормализации на стороне сервера Lync и формата записи телефонных номеров в учетке в AD, клиент Lync преобразует эти номера по разным правилам для телефонов с кодом +1 и для всех остальных. Причем «остальным» ничего приятного не достаётся: пропадает читаемость и внутренний номер…

Я искренне надеюсь, что разработчики вскоре исправят этот баг.

• Использование сторонних SSL-сертификатов
• Назначение портов MCX

Использование сторонних SSL-сертификатов

Выполнив все шаги по развертыванию Lync Mobility, которые описаны в неприлично подробном официальном руководстве Microsoft Lync Server 2010 Mobility Guide, пришло время проверить работоспособность системы.

Клиент Lync 2010 на Windows Phone 7.5 при попытке подключении к моей тестовой среде выдавал следующее сообщение:

Unable to sign in.

Can't connect to the server. It might be unavailable. Also please check your network connection, sign-in address, and server addresses.

Не самое информативное сообщение, надо сказать. Хорошо, что в Lync Mobile есть возможность посмотреть журнал процесса подключения, для этого нужно

• в Settings включить Diagnostic Logging
• выполнить попытку подключения
• выслать лог к себе на почту

Реализация последнего действия дважды удивляет: кнопка send diagnostic logs находится на экране About, а сам лог зашивается в картинку, которую нужно отправить себе на почту в качестве вложения. Вот такие костыли, вот такая консьюмеризация ;)

Из полученного лога можно понять следующие важные вещи…

Lync Mobile сначала попробовал постучаться по внутренним именам autodiscover, потерпел неудачу и понял, что находится снаружи:

Info : 499526106 : ConfigurationResolver : Internal autodiscovery requests failed. Trying external.

Получил ответ от autodiscover по протоколу HTTP:

Info : 499526106 : DiscoverySession : Uri for request ExtDisc_http is http://lyncdiscover.lab.argon.pro/?sipuri=nospam@lab.argon.pro.

Info : 440722650 : HttpRequestPump : Completed request ExtDisc_http.

Autodiscover сделал перенаправление на опубликованный по HTTPS Lync Web Services, и клиент пошел по этому пути:

Info : 499526106 : ConfigurationResolver : Redirect to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro requires a trust decision.

Info : 499526106 : TrustManager : Trust of https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro for Autodiscovery is inherited through lab.argon.pro.

TrustManager : Redirection to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro is trusted for Autodiscovery.

Info : 499526106 : ConfigurationResolver : Redirecting discovery query for nospam@lab.argon.pro to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro.

Info : 499526106 : DiscoverySession : Uri for request RedirectDisc is https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro.

Info : 499526106 : ConfigurationResolver : Sending unauthenticated discovery request for nospam@lab.argon.pro to https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro.

И здесь случилась непонятная сетевая ошибка:

Warning : 440722650 : HttpRequestPump : Got a WebException while reading the response for RedirectDisc.

Error : 440722650 : HttpRequestPump : Request RedirectDisc failed due to an unidentified network error.

Error : 440722650 : HttpRequestPump : Calling back RedirectDisc with error ConnectionError [Error, Transport, TransportFramework].

Info : 499526106 : RequestRetryQueue : RedirectDisc ConnectionError [Error, Transport, TransportFramework] retry=True

После нескольких повторных попыток клиент сдался:

Info : 499526106 : InternalExternalSelector : Checking whether to switch from EXTERNAL because of ConnectionError [Error, Transport, TransportFramework]

Info : 499526106 : InternalExternalSelector : Not signed in

Error : 499526106 : ConfigurationResolver : Autodiscovery for nospam@lab.argon.pro failed with status DiscoveryFailedPastRoot [Error, Application, Discovery].

Если из браузера пройти по пути, которую Lync Mobile получает в качестве редиректа:

https://lws.lab.argon.pro:18801/Autodiscover/AutodiscoverService.svc/root?sipuri=nospam@lab.argon.pro

то мы получим ответ сервера, содержащий служебную информацию для Lync Mobile. К счастью, мне уже приходилось развертывать Lync Mobility, и сравнение ответа сервера между работающей и исследуемой средой не выявило проблем. Однако, моя тестовая среда отличалась SSL-сертификатами.

Я использовал бесплатные публичные сертификаты от StartSSL. Данному CA доверяют многие: современные браузеры, клиент Lync на Windows, без проблем работает федерация между моей средой, Microsoft и его партнёрами, проходит тест в Remote Connectivity Analyzer. Но данный CA неспроста отсутствует в списке рекомендуемых поставщиков SSL-сертификатов для Microsoft Unified Communications.

Именно отсутствием доверия к CA StartSSL объясняется «неизвестная сетевая ошибка» в журнале подключения Lync Mobile.

Не беда, Windows Phone 7 позволяет устанавливать свои сертификаты в хранилище доверенных корневых CA. Установка доверенных корневых CA делается следующим user-friendly способом (сравнимым по элегантности с получением логов):

• сохранить в формате .cer сертификат Root CA (в моём случае StartCom Certification Authority)
• отправить сертификат к себе на телефон по электропочте в качестве вложения
• получить на телефоне письмо, открыть вложение, установить сертификат

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

Из данного случая можно сделать следующие выводы:

• В отличие от Windows клиента, мобильный клиент не сообщает об ошибках доверия к сертификату SSL.
• На Windows Phone 7 имеется возможность установить произвольный сертификат корневого CA.
• Если подключенный (по WiFi) во внутреннюю сеть предприятия Lync Mobile не работает, но работает из внешней сети, то происходит это вероятнее всего потому, что внутренние службы Lync Server используют SSL-сертификаты, выпущенные корневым CA предприятия. Чтобы Lync Mobile начал подключаться из внутренней сети, достаточно сотрудникам разослать e-mail с сертификатом корпоративного CA и инструкцией по его установке.

О том, как избежать установки SSL-сертификатов на мобильные клиенты при подключении как из внешней, так и из внутренней сети, читайте мою заметку Доступ к Lync Mobility из внутренних сетей WiFi.

Назначение портов MCX

В документации к развертыванию Lync Mobility есть интересная часть, а именно конфигурирование дополнительных портов следующими командами:

Set-CsWebServer –Identity FQDN –McxSipPrimaryListeningPort 5086
Set-CsWebServer –Identity FQDN –McxSipExternalListeningPort 5087

В интернетах я встречал много вопросов и предположений, зачем они нужны, нужно ли их открывать между front end и edge, либо же на reverse proxy или на внешнем интерфейсе edge…

Исследование данного вопроса показало:

C:\Users\admin>netstat -ano |findstr ":5087"

C:\Users\admin>tasklist |findstr "6312 2876"

Из чего можно сделать вывод, что данные порты используются для взаимодействия служб Lync Server в пределах компьютера. Анализ сетевой активности на внешнем шлюзе подтверждает, что не происходит соединений со внешним миром с участием данных портов.

• Lync Server Edge можно установить я на ту же машину, что и Forefront TMG. Edge использует ту же версию SQL Server 2008 Express, но создаёт свой экземпляр.
• Если сервера TMG работают в составе массива, и для массива включен Win NLB, Lync Edge по-прежнему может работать, используя DNS Load Balancing
• При этом работают Lync Web Services, опубликованные через TMG NLB
• Для служб Lync Edge (Access, Web Conf, A/V) не заявлена поддержка Win NLB. Это неспроста, данные службы через Win NLB не работают, я проверил.
• Даже в лабораторных условиях, логин на выделенные Edge сервера происходит в разы быстрее, чем на совмещенные с TMG.

Если следовать мануалу, то балансировка нагрузки действительно работает. Однако, если запустить на одном из узлов кластера консоль Network Load Balancing Manager, то можно увидеть следующие сообщения в логе:

Loading configuration information from host "AR-S-GW2.lab.argon.pro" for cluster 10.18.252.100

The RPC server is unavailable on the specified computer. Error connecting to "AR-S-GW2.lab.argon.pro"

Поискав в интернетах способы решения этой проблемы, я нашел следующую информацию:

• консоль Network Load Balancing Manager использует DCOM для общения между узлами кластера
• TMG не поддерживает DCOM
• TMG конфигурирует NLB-кластер не через DCOM, поэтому всё работает
• так как всё работает, на ошибки в Network Load Balancing Manager можно забить

Я решил не забивать и разобраться в этой проблемой…

В моей конфигурации все коммуникации между членами массива TMG были разрешены сетевыми правилами. Однако, именно DCOM не работал. Чтобы выяснить, что происходит, я пошел в Troubleshooting → Traffic Simulator и использовал следующий сценарий симуляции:

1. Scenario: Non-Web access
2. Source IP: Node1_Internal_IP, Port: * (RPC, DCOM)
3. Destination IP: Node2_Internal_IP, Port: 135 (RPC, DCOM)
4. Server: Node1

Симуляция выдала следующий ответ:

Allowed Traffic
Rule Name: [System] Allow RPC from Forefront TMG to trusted servers
Rule Order: 22

Additional information
From: Local Host
To: Internal
Network Rule Name: None - Route implied (Local Host traffic)
Network Relationship: Route
Protocol: RPC (all interfaces)
Rule Application Filter: RPC Filter

Увидев упоминание RPC Filter я сразу понял, в чём дело. С RPC-фильтром, а именно с его функцией Enable strict RPC compliance я уже сталкивался, когда не работал Certification Authority Web Enrollment, установленный на машине TMG. В тот раз, отключение опции Enable strict RPC compliance решило проблему.

Однако, в данном случае трафик между членами массива TMG проходит через целый ряд системных правил, которые имеют приоритет выше, чем пользовательские. Неприятным свойством системных правил является то, что в них нет возможности отключить опцию Enable strict RPC compliance. Таким образом, остается два способа отключить фильтрацию трафика RPC между членами массива TMG:

• Отключить все системные правила, под которые подходит трафик RPC. С помощью симулятора трафика таких правил обнаружилось очень много…
• Отключить RPC Filter на уровне всего массива TMG. На первый взгляд, ничего страшного в этом нет…

Мне более симпатичен вариант с отключением RPC Filter на уровне массива. Для этого нужно выполнить следующие настройки:

• Enterprise → Enterprise Add-ins → Application Filters → RPC Filter → Enable this filter on all arrays → Выкл
• Arrays → My Array → System → Application Filters → RPC Filter → Enable this filter → Выкл

После применения данных настроек ошибки подключения в Network Load Balancing Manager припали. А значит, цель достигнута!

Полезные ссылки

• RPC Filter and «Enable strict RPC compliance»

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

Если приходится часто ставить TMG, либо не хочется последовательно накатывать все обновления, а сразу поставить последнюю версию продукта, предлагаю воспользоваться возможностью интегрировать выпущенные обновления в дистрибутив продукта. Такая интеграция на английском зовётся slipstream, и многие дистрибутивы Microsoft (но не все) её поддерживают.

Итак, для интеграции обновлений в дистрибутив TMG 2010 нужно выполнить следующие действия.

1. Положить содержимое дистрибутива TMG 2010 в

d:\TMG\Distrib

2. Скачать последние обновления: Service Pack 1, Software Update 1 for SP1, Service Pack 2

3. Извлечь патчи (.msp файлы) из самораспаковывающихся архивов (.exe) с помощью команд:

TMG-KB2288910-amd64-ENU.exe /t d:\TMG\SP1SU1
TMG-KB2555840-amd64-ENU.exe /t d:\TMG\SP2

4. Перейти в каталог с .msi файлом дистрибутива TMG (d:\TMG\Distrib\FPC) и в правильном порядке применить .msp файлы к дистрибутиву:

msiexec /a MS_FPC_Server.msi /p d:\TMG\SP1\TMG-KB981324-AMD64-ENU.msp
msiexec /a MS_FPC_Server.msi /p d:\TMG\SP1SU1\TMG-KB2288910-amd64-ENU.msp
msiexec /a MS_FPC_Server.msi /p d:\TMG\SP2\TMG-KB2555840-amd64-ENU.msp

В итоге в папке d:\TMG\Distrib будет лежать готовый к установке дистрибутив TMG 2010 SP2.

Ложка дёгтя

В комплекте с дистрибутивом TMG 2010 идёт SQL Server 2008 SP1 Express Edition, который ставиться автоматически при установке TMG. Было бы разумным и этот дистрибутив обновить, так как уже вышел SQL Server 2008 Service Pack 3. К несчастью, в установщике TMG (setup.exe) жестко прописаны параметры установки SQL Server (.\Program Files\Microsoft ISA Server\SQLE\SQLExpress2008SP1.exe). Я попытался подменить данный файл на SQL Server 2008 SP3 Express Edition, но потерпел неудачу: логика работы установщика нарушается. Скорее всего потому, что оригинальный файл SQLExpress2008SP1.exe содержит в себе не просто Express Edition, но и Reporting Services, а доступный для загрузки SQL Server 2008 SP3 Express Edition этих служб не содержит.

Таким образом, собрать дистрибутив TMG 2010 с обновленным SQL Server 2008 мне не удалось, и сразу после установки TMG требуется обновить SQL Server 2008 последним сервис паком (на момент написания — Service Pack 3). Хорошо, что пакеты обновления SQL Server 2008 являются кумулятивными и не требуют последовательной установки…

Хотя в интернете есть статьи, детально и со скриншотами описывающие действия по включению RDP Remote Recording, для вновь установленных ОС в общем случае данных действий не достаточно. В этой заметке я приведу проверенный лично алгоритм включения Remote audio recording на WS2008R2 и Win7.

1. Включить Windows Audio Service. Актуально для WS2008R2, так как по умолчанию данная служба отключена. Для включения достаточно кликнуть правой кнопкой по громкоговорителю в углу экрана и вызвать свойства, далее система сама предложит запустить сервис.

2. Разрешить перенаправление аудио/видео и записи звука в свойствах RDP-сервера.

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

• MMC-оснастке Remote Desktop Session Host Configuration (не доступна в стандартной поставке Windows 7)
• Групповых политиках (доменных, либо локальных — gpedit.msc)

[Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Device and Resource Redirection]

Allow audio and video playback redirection
Allow audio recording redirection


3. Отредактировать реестр. Как выяснилось, даже если в политике нужные функции будут явно разрешены, передача аудио/видео работать начнет, а вот запись звука — нет. Для того, чтобы запись звука по RDP начала работать, нужно задать следующее значение в реестре:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp]

"fDisableAudioCapture"=dword:00000000

После этого в записывающих устройствах (Recording Devices) ОС Windows 7 появится Remote Audio.

4. Установить роль Remote Desktop Session Host на WS2008R2. В режиме Remote Desktop fot Administration, который настраивается при установке системы, перенаправление записи звука не работает.

Установщик роли Remote Desktop Session Host будет настоятельно предлагать установить фичу Desktop Experience, если отметить галочки Audio and video playback, Audio recording redirection. Рекомендую снять эти галочки и поставить роль RDSH без фичи Desktop Experience, так как она для работы записи звука по RDP не требуется, но при этом в систему добавляет много ненужного (полупрозрачные окна, нескучные обои и прочий BolgenOS).

5. Включить в RDP-клиенте функциональность Remote audio playback и Remote audio recording.

Ссылки

• Configure Audio Recording Redirection on an RD Session Host Server
• Enable Audio in Windows 2008 guest machines running on HyperV
• What’s New in Remote Audio for Windows 7?

Причина, по которой мне нужна ОС Windows Server 2008 R2 на ноутбуке — это возможность использовать Hyper-V. Однако, после установки данной роли выключаются столь полезные для ноутбука функции, как сон (sleep) и гибернация (hypernation).

Совместно использовать Hyper-V и функции энергосбережения на текущей версии ядра ОС никак нельзя (хотя, в Windows 8 это уж обещают). Но есть возможность исхитриться! Прописать в реестре «ручной» запуск службы hvboot:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\hvboot] "Start"=dword:00000003

После перезагрузки компьютера все функции энергосбережения начнут работать. Не будут работать лишь виртуальные машины Hyper-V. Когда они понадобиться, достаточно запустить в командной строке с правами администратора:

net start hvboot

Данная команда активирует Hyper-V, но отключит энергосберегающие функции в операционной системе. К сожалению, остановить службу hvboot (со всеми вытекающими) можно только перезагрузкой ОС.

Полезная ссылка: Hyper-V: How to Run Hyper-V on a Laptop

В данной заметке я попытаюсь провести анализ полезности пустых корневых доменов для современной инфраструктуры AD.

Античность: служба каталогов Windows NT 4

Во времена службы каталогов Windows NT 4 существовало вполне достижимое ограничение на максимальное количество объектов в домене. С целью экономии на количестве объектов, предлагались следующие ухищрения:

• создавать разные домены для пользовательских учетные записей и ресурсов (сервера, данные приложений в службе каталогов)
• если и в этом случае лимитов домена NT4 было недостаточно, предлагалось создавать отдельные домены для крупных организационных единиц предприятия.

Средние века: Active Directory на WS 2000 / 2003

С выходом Windows 2000 и обновленной службы каталогов, Active Directory, проблемы с ограничением количества хранимых объектов были решены. Помимо этого, значимым нововведением (в контексте данной заметки) стала возможность создавать леса доменов. Домены в одном лесу:

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

Однако, осадок в виде накопленного с Windows NT 4 опыта остался: по-прежнему можно встретить необоснованные рекомендации по созданию ресурсных и пользовательских доменов, а также дочерних доменов для больших структурных подразделений в организации. Естественно, при создании множества доменов является разумным пользоваться возможностью Active Directory строить иерархию доменов в одном лесу.

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

• Управление ИТ-инфраструктурой предприятия выполняется децентрализовано: местные ИТ-службы крупных орг. подразделений предприятия автономны от центра, полностью управляют и несут ответственность за свою инфраструктуру. Вполне логично использовать отдельные домены для изоляции полномочий администраторов в пределах только своего автономного подразделения.
• Каналы связи между крупными орг. подразделениями настолько узки и ненадежны, что даже трафик репликации вызывает проблемы. При прочих равных, трафик репликации между доменами намного меньше трафика репликации в пределах одного домена.

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

Смутное время

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

Приведу некоторые распространенные суждения:

• Пустой корневой домен необходим для изоляции мастера схемы от возможных покушений на чистоту схемы.
• Только в корневом домене есть группа высшей исполнительной власти — Enterprise Administrators, и её необходимо защитить от посягательств «обычных» Администраторов домена.
• Если требуются разные политики безопасности паролей для пользователей разных категорий, то эта задача может быть реализована только в разных доменах.

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

• Требуется дополнительное оборудование для работы контроллеров корневого домена.
• Требуется дополнительное сопровождение и организация отказоустойчивости для контроллеров корневого домена.
• Общая логическая иерархия AD увеличивается дополнительным уровнем, удлиняя имя домена, цепочку разрешения имён и аутентификации при работе с доверительными отношениями с другими лесами.
• И последнее, самое интересное… Было доказано, что домен в пределах леса на самом деле не является границей безопасности. Иными словами, при наличии административного (физического) доступа к любому контроллеру любого дочернего домена можно получить любые права в корневом домене.

Если требуется реальная граница безопасности между службами каталогов AD, она реализуется только между разными лесами.

Наше время: Active Directory на Windows Server 2008 / R2

За счет нового функционала, переход Active Directory на уровень функционирования Windows Server 2008 (R2) решает многие озвученные ранее проблемы:

• контроллеры домена только для чтения позволяют больше особо не беспокоиться за их безопасность при размещении в подозрительных местах: даже прямой физический доступ к такому контроллеру не угрожает безопасности административных учетных записей
• возможность аппаратного шифрования дисков с помощью BitLocker пишущих и только читающих контроллеров домена
• использование режима Core установки ОС еще сильнее сокращает поверхность для возможных атак
• возможность создавать различные политики безопасности паролей для разных групп пользователей
• ну и… каналы связи со времён Windows 2000 значительно расширились, так что проблема объёма трафика репликации данных AD в пределах домена более не стоит так остро

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

Разумеется, если текущий лес AD достался в наследство уже с пустым корневым доменом, то здесь остаётся либо смириться, либо, собравшись силами, пойти по пути джедая: устроить миграцию…

Годные ссылки

• Multiple Domain Forests: Still a Valid Design Model?

В этой статье я попытаюсь восполнить сей пробел и изложу своё видение и подход к проектированию схем именования: учетных записей пользователей и групп, компьютеров, сетевых устройств и других объектов в Active Directory.

Предложенные варианты схем основаны на личном проектном опыте и в результате анализа достоинств и недостатков в ИТ-инфраструктурах, которые приходилось встречать.

Я приведу аргументы практически для каждого решения, принятого при проектировании предлагаемых ниже схем. Буду рад увидеть альтернативные мнения в комментариях.

Содержание:

• Поиск по неполным данным
• Учетные записи пользователей
• Группы
• Сетевые устройства
• Организационные подразделения
• Другие объекты
• Годные ссылки

Поиск по неполным данным

Одной из замечательных возможностей AD является поиск по неполным данным. Прелесть его в том, что для выбора нужного нам объекта (пользователя, компьютера, группы) можно просто ввести несколько начальных символов из его имени. Если подходящих объектов будет найдено несколько, предоставят возможность выбрать тот объект, который нужен. Поиск по неполным данным может очень сильно облегчить выполнение регулярных задач по администрированию AD… Если атрибуты AD заполнены удобным, стандартизированным и структурированным образом.

Приведенные в этой статье рекомендации по именованию объектов учитывают особенности неполного поиска в AD таким образом, чтобы пользу от него можно было использовать в большинстве случаев.

Учетные записи пользователей

Логины

В среде AD в качестве логина могут использоваться 2 формата:

• User Principal Name (UPN) [userPrincipalName]: upnlogin@argnon.pro
• User logon name (pre-Windows 2000) [sAMAccountName]: argon\samlogin

Имеется возможность для учётки пользователя задать разные значения upnlogin и samlogin, однако это не практично, если того не требуют особые обстоятельства. Далее по тексту под словом «логин» я буду понимать одинаковое значение для атрибутов userPrincipalName и sAMAccountName.

Примечание

В неполном поиске участвует только sAMAccountName.

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

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

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

• только латинские буквы — чтобы избежать проблем со сторонними (например, Linux Samba Server) и не очень (даже Remote Desktop Gateway, входящий в Windows Server 2008 R2 не работает, если встретит не латинские буквы в логине) приложениями, а также с аппаратурой (отсутствие русской раскладки, поддержки кодировки).
• не более 10 букв — для случаев ввода с не очень удобных устройств (мобильников, экранных клавиатур)
• содержать в себе фрагменты имени и фамилии хозяина — для удобства идентификации учётки с конкретным пользователем.

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

• личный — основанный на именах
• обезличенный — основанный на табельных номерах и прочих идентифицирующих данных

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

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

Итак, надеюсь, я показал, почему считаю обезличенную схему именования учёток пользователей неудачной. Далее я приведу свой ход рассуждений по созданию более удачной, «личной» схемы именования.

При формировании логина на основании имени и фамилии пользователя тоже возникают трудности. Ныне популярна такая схема именования:

<Имя>.<Фамилия> [Игорь Романовский → Igor.Romanovsky]

Согласен, выглядит красиво, однако, возникнут проблемы:

• с длинными именами и фамилиями [Иннокентий Петропавловский → Innokenty.Petropavlovsky]
• с трудностями однозначной транслитерации [Евгений Дряхлых → Eugene Dryakhlykh и еще массы вариантов]

Выход — сокращать логин, например, так:

<1я-буква-имени><часть-фамилии> [Евгений Баев → ebaev]

<часть-фамилии><1я-буква-имени> [Алексей Бармин → barmina]

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

Возможный выход из ситуации — как-то разделять фрагменты имени и фамилии, например, точкой:

<1я-буква-имени>.<часть-фамилии> [Игорь Романовский → i.rom]

Этот вариант мне очень нравится, но все же имеет следующие недостатки:

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

На основе приведенных выше размышлений, я предлагаю следующую схему, которая меня полностью устраивает:

<часть-имени><часть-фамилии> [Алексей Волков → alvol, Фёдор Бондарчук → fbond, Феликс Бунин → felixb]

Прелесть схемы в том, что части имени и фамилии выбираются так, чтобы:

• выглядело благовидно
• избежать коллизии
• логин оставался кратким

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

Служебные логины

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

• на предприятии используются несколько обезличенных «ролевых» учетных записей типа Administrator, NetAdmin, WebAdmin, TechSupport…
• ими пользуется куча народа, исполняющего соответствующие роли

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

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

• использовать отдельные личные учетки для выполнении административных задач, с логинами вида a-login, где вместо login — обычный логин данного пользователя
• привилегии на выполнение административных операций всегда назначать на уровне ролевых групп безопасности

Display Name

Значение атрибута displayName учетной записи отображается в заголовке меню Пуск вошедшего в систему пользователя, в контактах адресной книги Exchange, в поле От исходящих почтовых сообщений и во многих других местах, где требуется отобразить «дружественное» имя.

При создании пользователя в Active Directory предлагается заполнить поля имени, инициалов и фамилии. На основе этих данных предлагается значение атрибута Display Name по следующей схеме:

<Firstname> <Initials>. <Lastname>

Примечание

Путем редактирования некоторых параметров в AD эту схему можно изменить (например, на Lastname, Firstname), но на то нет веских причин. Советские времена, когда к людям было принято обращаться тов. Фамилия прошли, в современном деловом обществе принято обращаться по Имя Фамилия.

Для Display Name можно задать произвольное значение, что удобно:

• для служебных учетных записей, которые не имеют имён и фамилий
• если в поле AD «имя» введено Имя Отчество(так как под отчество нет отдельного поля), а отображать нужно в формате Имя Фамилия

Full Name

В момент создания пользователя значение Display Name присваивается другому атрибуту пользователя — cn (Canonical Name, часто он упомиается как Full Name). Значение cn широко используется в Active Directory:

• является частью фундаментального атрибута distinguishedName, который представляет собой путь к объекту в пределах AD (CN=Firstname Lastname,OU=Test Accounts,DC=argon,DC=pro), из него же формируется Canonical Name (argon.pro/Test Accounts/Firstname Lastname)
• именно это имя отображается в поле Full Name в оснастке Active Directory Users and Computers
• по этому параметру выполняется неполный поиск объектов в AD

Стоит обратить внимания на следующие особенности:

• атрибуты Display Name и Full Name напрямую не связаны, и после создания учетки их можно редактировать как угодно
• значение Full Name должно быть уникальным в пределах своего Organization Unit, к Display Name таких требований не предъявляется
• оба значения Display Name и Full Name следует держать согласованными, если нет необходимости в обратном, для чего редактирования первого нужно аналогично отредактировать и второе значение.

Группы

На имена групп нет таких строгих ограничений, как на логины, но есть смысл придерживаться схожих правил:

• избегать нелатинских символов и пробелов
• стремиться к кратким названиям

В дополнение к вышеперечисленному, удобно, чтобы имена групп соответствовали следующим характеристикам:

• чем-то явно отличались от логинов
• отражали назначение группы (например, из имен Техподдержка и Бухгалтерия не понять, что есть группа безопасности, а что — группа рассылки)
• признаки, содержащиеся в имени, следовали в порядке значимости (например, ExchangeAdmins и ExchangeHelpdesk, а не Администраторы Exchange и Техническая поддержка Exchange)

При этом, включать в имя группы признак её области действия (локальная, глобальная, универсальная) нет необходимости по следующим причинам:

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

Итак, я предлагаю следующую схему именования групп:

g<p>-<Name>

где:

• g — признак отличия имени группы от логина
• p — назначение группы, принимает значения:
  • f — функциональная
  • r — ресурсная
  • d — распространения
  • a — административная
• Name — собственно, имя группы; при необходимости, содержит признаки принадлежности к области действия, например:
  • GlobHelpdesk
  • MscPrinters

Пример имён групп:

• gf-Operators
• gr-ProjectDocs
• gd-AllCompany
• ga-Helpdesk

Примечание

Назначение группы определяется ролевой моделью привилегий (также известной как UGLP), в которой:

• пользователи включаются в глобальные группы (функциональные), в соответствии с выполняемыми ролями
• разрешения на ресурсы назначаются локальным группам (ресурсным)
• в состав ресурсных групп включаются ролевые группы
• при необходимости, на более высоком иерархическом уровне используются универсальные группы, в которые включают глобальные группы
• отдельно выделяются административные группы и группы рассылки

Для групп рассылки есть замечательный атрибут Display Name, который позволяет отображать «человеческое» имя в адресной книге, а также произносить ее голосом в Exchange UM, и одновременно с этим не уходить от общей конвенции именования групп.

Сетевые устройства

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

Примеры неудачных имен с попыткой их расшифровать и комментариями:

• SR-PSSRV001 (сервер-принт-сервер-сервер-номер001) — слово «сервер» закодировано 3 раза, порядковый номер 3-разрядный, хотя таких серверов всего 2 штуки
• SR-msExch04 (сервер, почтовый сервер-эксчендж сервер-номер04) — многократно закодировано слово «сервер», но нет данных о его размещении
• W-430400764 (рабочая станция-43регион, офис 04, инвентарный номер 00764) — без таблицы — не найти!
• МАШЕНЬКА-ПК (без комментариев)

Для сетевых устройств (компьютеров, принтеров, роутеров, мобильников…) я предлагаю гибкую схему именования, которая основана на следующих правилах:

• нелатинские символы исключены
• имя должно содержать некие признаки, которые позволяют удобно классифицировать устойства
• классификационные признаки должны следовать в порядке значимости
• имя должно быть достаточно описательным, чтобы свести к минимуму обращения к таблицам для идентификации устройства
• если требуется совместимость с Netbios, длину имени следует ограничить 15 символами

А вот и схема:

<Site>-<Class>-<[Type]Name[Number]>

• Site — признак расположения компьютера (определение сайта в терминологии AD вполне подходит), такие как HQ, NOC, MSC, KZN и прочее.
• Class — класс устройства, например:
  • SR — сервер
  • WS — рабочая станция
  • MB — мобильное устройство
  • DV — другое сетевое устройство
• Type — опциональное дальнейшее уточнение назначения устройства (зависит от класса), например:
  • DC — контроллер домена
  • PR — принтер
  • DT — десктоп
  • LT — ноутбук
• Name — имя устройства, краткое и описательное, например:
  • ExMB — сервер почтовых ящиков Exchange
  • Gate — шлюз
  • Proxy — …
• Number — опциональный номер, если подобных устройств несколько. Разрядность номера следует планировать заранее, но и фиксировать количество разрядов для абсолютно всех устройств не стоит, так большая разрядность уместна в редких случаях, а в большинстве случаев достаточно номера в пределах десятка.

Примеры имен, образованных по такой схеме:

• NOC-SR-DCLAB18 (сайт NOC, сервер, контроллер домена LAB, номер 18)
• MSC-SR-MONITOR (сайт MSC, сервер, занимается мониторингом)
• NOC-CL-HV4 (сайт NOC, кластер Hyper-V, номер 4)
• NOC-CL-HV4-N7 (сайт NOC, кластер Hyper-V номер 4, узел номер 7)
• HQ-SR-EXMB3 (сайт HQ, cервер, Exchange c ролью Mailbox, номер 3)
• KOS-WS-DTFIN06 (сайт KOS, рабочая станция, настольная, финансовый отдел, номер 06)
• EXT-WS-LTIROM (внешний сайт, рабочая станция, ноутбук пользователя с логином irom)
• NOC-DV-ROUTER12 (сайт NOC, устройство, маршрутизатор, номер 12)
• EXT-MD-WMIROM (внешний сайт, мобильное устройство, windows mobile пользователя с логином irom)

Организационные подразделения

Существующих несколько моделей построения структуры OU и делегирования. Здесь я не буду пытаться описать их все, это хорошо сделано в более серьёзной литературе.

Из всех популярных моделей я рекомендую использовать административную модель построения OU, которая призвана обеспечить наибольшее удобство для, как можно догадаться, задач администрирования:

• объединения объектов признакам
• делегирования полномочий
• назначения групповых политик
• эффективного использования возможностей наследования

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

• противоречива и изменчива
• не применима к управлению ИТ-инфраструктурой

Я предлагаю строить структуру OU по следующей концепции:

• Создавать структуру OU исходя в первую очередь из удобства делегирования полномочий.
• Для тонкого назначения групповых политик на пользователей, рабочие станции и сервера использовать ролевую модель, основанную на членстве в группах в безопасности. Не эффективно пытаться строить ролевую модель на OU. Непременно найдутся объекты, которые исполняют несколько ролей, но архитектура AD предусматривает членство объекта только в одном OU.

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

• в именах OU не использовать нелатинских символов и пробелов
• придерживаться принципов краткости и не избыточности
• умеренно использовать иерархию (глубокая вложенность замедляет выполнение некоторых операций)
• активно пользоваться полем Description
• избегать использования встроенных контейнеров Users и Computers для хранения в них объектов, назначения политик
• не создавать своих контейнеров (куда-то вложенных) с именами Users и Computers — могут быть проблемы совместимости

Пример структуры OU, который следует вышеизложенным рекомендациям:

• lab.argon.pro — домен
  • Company – сразу отделяем наше дерево иерархии от встроенных объектов AD
    • Global
    • Kazan
    • Kirov– уровень территориальной принадлежности
      • Services – служебные пользователи и группы, управляет которыми только IT-отдел
      • Comps – компьютеры: сервера и рабочие станции
      • Accounts – учетные записи и группы рядовых пользователей, управление которыми можно делегировать простым пользователям (конечно, через другие группы безопасности, прав на управление которыми у данного пользователя не будет)
    • Moscow

Другие объекты

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

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

[To be continued and edited...]

Годные ссылки

• The 12 Mighty Chores of Active Directory Administration in Depth
• Оптимизация AD: Cтруктура орг. подразделений(OU) служит для делегирования прав и назначения групповых политик
• RFC 2142 — Mailbox Names for Common Services, Roles and Functions

Microsoft iSCSI Software Target отличается от сторонних решений своей простотой, надежностью и теперь уже бесплатностью для поддерживаемых ОС. Не нужен отдельный продукт Windows Storage Server, достаточно Windows Server 2008 R2 в режиме полной инсталляции.

Это замечательное событие открывает так долго ожидаемую возможность создания отказоустойчивых кластеров виртуализации без больших затрат на систему хранения данных. Для небольших решений и в демонстрационных целях — самое то.

• Microsoft iSCSI Software Target 3.3 — страница загрузки
• Документация на TechNet
• Microsoft iSCSI Software Target 3.3 for Windows Server 2008 R2 available for public download — официальный анонс, подробности

Комп ни разу не слабый: 8 гигов памяти, многоядерный процессор. Ничего «лишнего» в системе Windows Server 2008 R2 SP1, кроме музыки, нет.

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

Ни в Опере, ни в Лисе таких эффектных тормозов всей системы не бывало отродясь.

Материалы, рекламирующие Lync, позиционируют его как полную замену традиционным IP АТС. Голосовые меню, очереди и группы вызовов, гибкая маршрутизация и полная интеграция с другими системами — все номинально имеется в наличии. Однако, когда дело доходит до реального применения Lync Server 2010 для выполнения конкретных бизнес-задач, я регулярно:

• наступаю на различные грабли — неприятные, но решаемые чтением мануалов и форумов проблемы
• бьюсь головой о стену — пока не выясняю, что реализовать нужную мне функцию невозможно «by design»
• ищу пути обхода обнаруженных в предыдущем пункте «стен»

Способы навигации по голосовому меню

Lync Server 2010 может похвастаться мощными голосовыми меню, которые поддерживают распознавание речи. Но полезность таких «космических кораблей, бороздящих просторы вселенной», весьма мала по следующим причинам:

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

Поэтому, несмотря на «вау-эффект», производимый распознавателем голоса, в реальном мире (даже в Microsoft) для навигации по интерактивным голосовым меню используется тоновый набор DTMF.

И здесь приходит очередное разочарование: без использования сторонних модулей в Lync Server 2010 нет возможности создавать принимающие DTMF-сигналы голосовые меню. Чтобы таки получить понимающее DTMF голосовое меню, предлагается использовать Auto Attendant из функционала Exchange Server 2010 Unified Messaging.

Лирическое отступление

Принято считать, что внедрение Lync Server 2010 без Exchange UM является бессмысленным. С этим я согласен, Lync без Exchange действительно не раскрывает своего функционала. Но необходимость использования Unified Messaging для организации голосового меню, понимающего DTMF, мне кажется абсурдной.

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

• общая надежность телефонии от появления еще одного звена не повышается
• требуется обеспечение высокой доступности и для Unified Messaging, так как эта роль становится частью критичной для бизнеса системы

Настройка Auto Attendant

Итак, задача: средствами Auto Attendant в Exchange UM настроить традиционное интерактивное голосовое меню, понимающее DTMF. Под традиционным меню понимается такой шаблон: «Добро пожаловать в Компанию! Введите внутренний номер абонента или дождитесь ответа оператора».

Чтобы этого достичь, попытаемся настроить Auto Attendant следующим образом:

• отключить Auto Attendant is speech-enabled — не будет пытаться разобрать голосовые команды и будет работать в режиме DTMF
• отключить Auto Attendant is enabled for directory lookups — не будет запрашивать ввод имени абонента с телефонной клавиатуры, только внутренний номер
• включить Allow caller to transfer to users — разрешит звонить на внутренние номера
• отключить Allow callers to send voice messages — не будет спрашивать, хотите ли вы оставить голосовое сообщение
• включить Allow transfer to operator — на случай, если звонящий не знает внутреннего номера
• настроить Operator extension — очевидно зачем

На выходе имеем следующие: Автоответчик ждет ввода либо внутреннего номера абонента, либо 0 для вызова оператора. Если от звонящего не поступает нужных сигналов — переспрашивает до бесконечности.

Перевод на оператора

Автоматический перевод на оператора по истечении времени не происходит. Такое поведение является недопустимым, так как при следующих стечениях обстоятельств никто не сможет дозвониться в компанию:

• на аппарате абонента нет тонового набора
• провайдер телефонии режет или искажает DTMF сигналы (невероятно, но я с этим встречался)

Для того, чтобы включить перевод на оператора по истечению времени, придется включить Key Mapping и добавить действие Transfer to extension [номер оператора] для события Press no key (time-out). При этом мы получим следующие побочные эффекты:

• так как теперь включено меню Key Mappings, автоответчик ждет от звонящего в первую очередь выбора элементов этого меню, а для ввода внутреннего номера необходимо нажимать решетку
• поскольку функции «перевода на оператора по кнопке 0» и «перевода по истечению времени» оглашаются автоответчиком как разные пункты, это звучит не логично, придется отказаться от стандартных голосовых приветствий Exchange UM и записать свои

Возможность звонка на произвольный номер

При включенных в Auto Attendant возможностях Allow caller to transfer to users и Allow calls to extensions обнаруживается следующие: никакие ограничения к вызываемым номерам не применяются, то есть в качестве внутреннего номера можно ввести что угодно, хоть международный номер. Таким образом, наше голосовое меню потенциально смогут использовать как бесплатный шлюз для звонков в Америку.

Казалось бы, Dialing Restrictions в настройках Auto Attendant для того и созданы, чтобы запретить нежелательные звонки. Но, как выяснилось, эти ограничения не применяются к набираемым «внутренним номерам», а применяются они только к номерам оператора и Key Mappings.

Обновление: Service Pack 2 для Exchange 2010 кардинально решает эту проблему: Auto Attendant теперь может звонить только на те номера, длина которых соответствует настройкам в диалплане.

Вот такой Epic Fail, придется либо смириться с такой недокументированной возможностью, либо настраивать запрет звонков от Auto Attendant на произвольные номера где-то дальше (например в Lync Server Voice Policy):

• Создаем в интерфейсе Lync Control Panel новую Voice Policy, в которой ограничиваем вызовы только локальными маршрутами
• Находим Identity нашего Auto Attendant с помощью Get-CsExUmContact
• Назначаем на Auto Attendant созданную политику:
  

  Grant-CsVoicePolicy -Identity ExUMAAWelcome -PolicyName InternalOnly

Выводы

Похоже, некоторый опыт работы с телефонией на базе Asterisk слишком избаловал меня, и от Lync Server 2010 я требую слишком многого. Общий тон заметки получился печальным: вопросов больше, чем ответов. Я буду рад узнать из комментариев об элегантных решениях описанных выше проблем.

Полезные ссылки

• Managing Unified Messaging Auto Attendant — статья в 4-х частях
• Understanding Unified Messaging Auto Attendants

Рассмотрим следующую ситуацию: имеется сервер Lync c ролью Mediation, к нему подключено два голосовых шлюза

• Asterisk 1.8, через который происходит подключение к городской сети
• Audiocodes Media Pack, который соединяет Lync с унаследованной офисной ATC

Хотя Lync и позиционируется производителем как полная замена старым АТС, без подключения к городской телефонии через Asterisk (или других IP-PBX) в российских реалиях обойтись трудно: Lync Server не может быть SIP-клиентом, не может работать по протоколу UDP…

Без интеграции с существующей офисной АТС представить серьезное внедрение Lync тоже трудно: разом всех пользователей на Lync не переведешь, а также должен быть план отката на предыдущее состояние, если внедрение Lync Server «не пошло», да и на случай программных и аппаратных отказов — тоже.

Маршрутизация вызовов между шлюзами

Итак, настроив интеграцию Lync Server с Asterisk и с Audiocodes, используя имеющиеся в достатке мануалы (на некоторые из которых я приведу ссылки в конце заметки), убедившись, что звонки между любым шлюзом и Lync-ом работают, можно подумать, что дело сделано.

Однако, при дальнейшем тестировании обнаруживается, что звонки по маршруту Audiocodes → Lync → Asterisk не проходят. Как выяснилось, дело в следующем: полная маршрутизация звонков, в соответствии с маршрутами на Lync Server выполняется только для авторизованных пользователей. Видимо, в целях учета лицензий. Пока звонки со шлюзов не авторизованы, их могут принимать только клиенты Lync Server, маршрутизация на другие шлюзы заблокирована.

Конечно, можно прописать прямые маршруты между Asterisk и Audiocodes, минуя Lync. Но зачем тогда нам Lync, в чем тогда будет состоять «Unified Communications»? Поэтому, чтобы звонки со шлюза Audiocodes могли уходить наружу по маршруту Audiocodes → Lync → Asterisk, на Lync-е для шлюза Audiocodes нужно создать учетную запись подобной командой:

New-CsAnalogDevice -LineUri tel:+901 -SipAddress "sip:audiocodes@argon.pro" -DisplayName "Audiocodes Gateway" -RegistrarPool lync.argon.pro -AnalogFax $False -Gateway audiocodes.argon.pro -OU "OU=LyncContacts,DC=argon,DC=pro"

А на шлюзе Audiocodes прописать Caller ID, равный +901 для всех исходящих звонков.

Для прохождения звонков по маршруту Asterisk → Lync → Audiocodes нужно проделать аналогичные действия… Но, здесь возникает проблема. Если в случае Audiocodes мы можем смириться с тем, что Caller ID будет заменен на номер, указанный в учётке AnalogDevice, то для поступающих вызовов из городской сети это может быть не допустимо.

Поэтому, вопрос прохождения вызовов по маршруту Asterisk → Lync → Audiocodes с сохранением оригинального Caller ID остается открытым. Комментарии приветствуются.

Переадресовывая вызовов от Asterisk

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

Пытаться переводить может кто или что угодно: будь то голосовое меню (Lync Server или Exchange Server Unified Messaging), или же живой оператор. Результат не удачен: от возвращения вызова обратно переводящему абоненту с сообщением «Вызов не может быть переведен», до банального обрыва.

Чтобы починить перевод вызовов, в настройках Lync Server нужно отключить Refer Support, который включен по умолчанию, но не поддерживается Asterisk. Для отключения Refer Support нужно выполнить следующее:

1. пройти в Lync Server Control Panel → Voice Routing → Trunk Configuration
2. выбрать New Pool Trunk → шлюз Asterisk
3. в конфигурации созданной записи снять галку Enable Refer Support
4. применить (commit) изменения
5. PROFIT!

Добавление Analog Device в Hunt Group

Продолжая налаживать отношения между Lync Server и унаследованной АТС, я обнаружил еще одну пренеприятнейшую особенность: в группу дозвона (Hunt Group в терминах телефонии, Response Group в терминах Lync) можно добавлять только стандартных пользователей Lync Server. Аналоговые устройства, которыми представлены в Lync-е голосовые шлюзы — в пролёте. Таким образом, еще одно ограничение ставит под сомнение возможность Lync Server полноценно работать совместно с унаследованной АТС и постепенно стать ей полной заменой.

Для обхода этого ограничения, предлагаю использовать всемогущий Asterisk: завести нём специальные номера для групповых вызовов (например, +5900).

1. убедиться, что маршрутизация из Lync на эти номера идёт на шлюз Asterisk
2. настроить в Asterisk (sip.conf) прямой SIP Trunk на Audiocodes
   

   [audiocodes]
type=peer
host=10.0.0.51
transport=tcp
insecure = port,invite

3. сконфигурировать в extensions.conf служебный номер для групповых вызовов
   

   exten => 5900,1,Answer()
exten => 5900,n,Dial(SIP/lync/180 & SIP/audiocodes/900)
exten => 5900,n,Hangup

Полезные ссылки

• Integrating AudioCodes MP-114/MP-118 Media Gateways with Microsoft Unified Communications Products
• Configuring the AudioCodes MP-114 IP gateway for a UM demo
• How to configure interoperability between Microsoft Exchange Server 2010 Unified Messaging and pbxnsip IP PBX version 3.0

Благодарю Александра Донина за помощь в решении описанных в заметке проблем.

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

В документации к Lync Server на TechNet (Certificate Requirements for External User Access, Planning for Certificates) приведены требования, которым должен отвечать публичный сертификат для роли Edge сервера Lync Server 2010. Как можно заметить, сертификат должен содержать несколько альтернативных имен (SAN), удовлетворяющих прихотям нескольких сервисов Lync Server Edge:

• адрес Access Edge (например, чтоугодно1.argon.pro)
• адрес Web Conferencing Edge (например, чтоугодно2.argon.pro)
• адрес SIP Domain для авто-конфигурации клиентов и федерации (только sip.argon.pro)

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

Если все Edge-сервисы расположены на одном публичном IP адресе (на разных портах, естественно), то для обращения к ним можно использовать всего одно доменное имя, и, соответственно, для сертификата — тоже. Из трех перечисленных выше имен только одно является фиксированным: sip.argon.pro, его одного и достаточно для функционирования сервисов Edge.

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

Хоть в интернете и можно найти много различных сервисов, предоставляющих бесплатные публичные SSL-сертификаты, для гарантированной работы Edge во всех конфигурациях (доступ клиентов, федерация, работа с аппаратными клиентами) годятся только поставщики, перечисленные в статье Unified Communications Certificate Partners for Exchange Server and for Communications Server. Среди них есть Comodo, который предлагает бесплатный пробный сертификат на 90 дней.

Именно такой сертификат для домена вида sip.argon.pro я и предлагаю использовать. Для этого нужно:

1. в Certificate Wizard на сервере с ролью Edge генерировать запрос «внешнего» сертификата
2. убедиться, что в запросе присутствует только одно доменное имя вида sip.argon.pro в параметре Subject CN и списке SAN
3. подать полученный запрос через веб-интерфейс к центру сертификации Comodo
4. подтвердить права на домен
5. после получения сертификата, назначить его на Edge-сервер

С последним пунктом могут возникнуть проблемы. Certificate Wizard в упор не признаёт полученный от Comodo сертификат как корректный (valid). Видимо потому, что ожидает увидеть в свойстве сертификата Enhanced Key Usage значение Server Authentication (1.3.6.1.5.5.7.3.1), а в сертификате от Comodo видит следующее:

• Server Authentication (1.3.6.1.5.5.7.3.1)
• Client Authentication (1.3.6.1.5.5.7.3.2)
• Unknown Key Usage (1.3.6.1.4.1.311.10.3.3)
• Unknown Key Usage (2.16.840.1.113730.4.1)

И из-за последних двух неопознанных записей считает сертификат непригодным…

Чтобы через силу прописать на Edge полученный от Comodo сертификат, на помощь приходит следующая команда PowerShell:

Set-CSCertificate -Type AccessEdgeExternal,DataEdgeExternal,AudioVideoAuthentication -Thumbprint 7D7E76B3A4582168992DF09F788D96AA42833A81 -Verbose -Confirm:$false -Report "C:\Argon\CertInstall.html"

Значение Thumbprint можно посмотреть в свойствах выданного сертификата; по адресу, указанному в значении Report будет сформирован отчет об успехах в установке сертификата.

После назначения такого сертификата на роль Lync Server 2010 Edge будут без проблем доступны все его сервисы:

• подключения клиентов
• конференции
• федерация
• работа аппаратных телефонов

Не Edge’ом единым

Хочу напомнить, что для полноценного функционирования всех сервисов Lync Server 2010 через интернет также должны быть опубликованы Lync Web Services, предоставляющие доступ к адресной книге, веб-морде конференции и т. п. Для этого удобно использовать возможности публикации веб сайтов Forefront Threat Management Gateway. Данная тема очень хорошо разобрана на следующих ресурсах:

• Publishing Lync Server 2010 (RC) Simple URLs and Web Components with Forefront TMG 2010
• Remote Conferencing with Lync Web App with Forefront Threat Management Gateway 2010 Reverse Proxy: Part 1

PS: Если схитрить, то и для Lync Web Services можно использовать тот же SSL сертификат, что и на Edge…

Полезные ссылки

• Документация по Lync Server 2010 на TechNet
• Certificate Requirements for External User Access
• Planning for Certificates
• Free SSL Certificates From Comodo
• Миграция на Lync Server 2010: установка роли Edge — Булдаков.ru
• Deploying an Edge Server with Lync — The OCS Guy’s Blog

Не стоит объяснять, что всегда имеет смысл разделять систему и данные по разным логическим дискам. В случае с FPE, возможность указать путь каталога для хранения данных доступна только в момент установки.

К счастью, в статье TechNet Managing incidents (кто бы мог подумать, что там и надо искать) есть параграф Move the incidents database, описывающий шаги, которые нужно выполнить для перемещения каталога данных Forefront Protection for Exchnage в другое расположение.

После свежей установки SharePoint Server 2010 можно заметить такую неприятность: имена пользователей и атрибуты их профилей сохраняются в SharePoint только в момент их первого входа. Дальнейшие изменения в атрибутах пользователя Active Directory (такие как номер телефона, адрес электропочты) никак не синхронизируются с профилями SharePoint.

Дальше — хуже. Со временем можно заметить, что отображаемые имена пользователей на портале видны в двух форматах:

• Имя Фамилия
• domain\Login

Причем заметно, что в перовом формиате отображаются «свежепоступившие» на портал пользователи, а во втором — более «опытные». Хотелось бы видеть отображаемые имена всех пользователей в естественном, первом формате.

Для этого необходима ручная настройка службы User Profile Synchronization Service, так как данный функционал не настраивается в процессе установки SharePoint. Статья TechNet Configure profile synchronization содержит полное описание шагов, которые необходимо выполнить для настройки регулярной синхронизации данных между профилями пользователей SharePoint и Active Directory.

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

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

Полезные ссылки

• Configure profile synchronization
• Updates for SharePoint 2010 Products
• Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization
• User Profile Synchronization Configuration Service cannot connect to SQL Server

Не совсем в тему, но полезно:

• Enable or disable personal and social features for users or groups
• Initial deployment administrative and service accounts
• Configure object cache user accounts
• Service Account Suggestions for SharePoint 2010
• SharePoint 2010 Service Account References for Least-Privileged Installation

Failure creating local group SQLServer2005SQLBrowserUser$SERVER.

Failure creating local group SQLServer2005MSSQLServerADHelperUser$SERVER.

Failure creating local group SQLServer2005MSSQLUser$SERVER$KAV_CS_ADMIN_KIT.

Происходит сие по следующей причине:

• установщик SQL Server пытается создать локальные группы для внутренних нужд
• так как сервер является контроллером домена, локальных групп на нем нет, потому группы создаются в AD
• так как сервер — не просто контроллер домена, а только для чтения, создать жти группы он не может

Для успешного разрешения этой ситуации достаточно вручную создать в AD следующие группы:

• SQLServer2005SQLBrowserUser$SERVER
• SQLServer2005MSSQLServerADHelperUser$SERVER
• SQLServer2005MSSQLUser$SERVER$KAV_CS_ADMIN_KIT

…и смело нажимать retry в окне сообщения об ошибке.

Дальнейших проблем в процессе установки и работы приложения обнаружено не было.

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

Команды разработчиков стремятся оперативно решать возникающие проблемы: находят пути обхода неполадки (workaround), либо выпускают исправления (Hotfix, Update Rollup, Cumulative Update, Software Update). Но так как эти исправления носят точечный характер, никто не спешит сообщать о них всему миру и публиковать в автоматических обновлениях через Windows Update.

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

Жизнь научила меня тому, что:

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

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

Ниже я собрал список блогов разработчиков и групп поддержки продуктов Microsoft (не всех, конечно, а только тех, с которыми регулярно работаю).

Обновление

К 23 февраля 2011 года SP1 стал доступен для загрузки всем желающим.

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

В интернетах полно статей о том, как создавать и развертывать образы ОС из командной строки с помощью ImageX; размечать и форматировать диски с помощью еще более неудобного DiskPart. Лично я не фанат командной строки, поэтому предпочитаю проделывать все эти операции мышкой, используя возможности WDS.

Я, конечно же, уже попробовал Service Pack 1 на своей машине Windows Server 2008 R2. И что хочу отметить, заявленные Dynamic Memory и RemoteFX действительно появились в настройках Hyper-V. Осталось всего лишь научиться правильно пользоваться этими возможностями.

И, наконец, сбылась моя давняя мечта: после установки SP1 из списка установленных в систему обновлений были исключены все установленные ранее обновления, но которые содержит в себе SP1. Например, в Windows Server 2008 без R2 после полутора лет работы и установки всех обновлений (много десятков), после установки SP2 все эти обновления оставались в списке, и это меня дико раздражало. В Windows Server 2008 R2 (и, полагаю, в Windows 7) теперь этой проблемы нет.

Замечание по установке

Разворачивая Service Pack 1 для Windows Server 2008 R2 на машинах в своей инфраструктуре, я заметил, что установка SP на виртуальной машине с 1 гигабайтом памяти занимала более 6 часов. На остальных машинах с 2 и более гигабайтами памяти установка занимала вполне приемлемое время. Как выяснилось, приложение-установщик SP1 может выделять себе до 1 гигабайта памяти, и если таковой не найдется, используется файл подкачки, создавая дикие тормоза и нагрузку на диски.

Даже при наличии достаточного количества памяти, установка SP1 создает колоссальную нагрузку на дисковую систему, максимально загружая её. Из этого следует, что если SP1 устанавливается на одну виртуальную машину, то все остальные виртуальные машины, расположенные на этом же хосте и на том же диске, будут иметь минимальную скорость доступа к дисковой системе. По той же причине, одновременная установка Service Pack 1 на нескольких виртуальных машинах, диски которых расположены на одном физическом носителе, будет длиться намного дольше, чем поочередная.

Замечание о Dynamic Memory

Эта функция работает только если и операционная система хоста (гипервизор), и гостевая система в виртуальной машине обновлены до Windows Server 2008 R2 Service Pack 1. Чего и следовало ожидать…

При включенной функции Dynamic Memory весьма вероятна ситуация, что виртуальным машинам будет выделена вся физическая память, доступная хосту. Это приведет к тому, что сам хост начнет «задыхаться» от недостатка памяти и яростно свопить. Чтобы избежать этой ситуации, нужно настроить резервирование памяти под нужды хоста (Parent Partition) в следующем ключе реестра, в мегабайтах:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization]
"MemoryReserve"=dword:00000500

Полезные ссылки

• KB976932 — статья базы знаний, на момент написания содержит информацию для бета-версии
• Загружаемая документация по сервиспаку, на момент написания только для RC-версии

В неформальной и располагающей к общению обстановке мы поговорили на следующие темы:

• Unified Communications (Lync Server 2010 + Exchange Server 2010 UM + Asterisk). Демонстрация, примеры внедрения, разрешение технических проблем, обсуждение.
• Anywhere Access (Сравнение VPN и DirectAccess, публикация внутренних ресурсов c помощью Forefront TMG). Демонстрация и необходимые для успешного внедрения особенности.

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

Результатом встречи стало общее желание участников начать проводить подобные собрания на регулярной основе.

Ссылки

• Кировский MCP-клуб — главная страница клуба

• Моя изначальная конфигурация
• Автоматическое подключение дополнительных почтовых ящиков к Outlook
• Служба Microsoft Exchange Transport на стартует при запуске системы
• Служба Microsoft Exchange Address Book на стартует при запуске системы
• Ошибки счетчиков производительности
• Возможные конфликты портов
• Предупреждения о HomeMTA
• Полезные ссылки

Моя изначальная конфигурация

• Домен на уровне Windows Server 2008 R2
• Выделенный сервер с ОС Windows Server 2008 R2, на нём
  • Exchange Server 2010 с установленными ролями MBX, CAS и HUB; в течение его жизни ставились все актуальные обновления Update Rollup, а затем Service Pack 1
  • Forefront Protection for Exchange 2010

Автоматическое подключение дополнительных почтовых ящиков к Outlook

Не трудно представить ситуации, когда нужно получить доступ к почтовому ящику другого пользователя. Как известно, для этого совсем не нужно сбрасывать пароль этого пользователя, а достаточно в Exchange Management Console назначить Full Access Permission для этого ящика на свою учетную запись.

До выхода Exchange Server 2010 SP1 следующим шагом нужно было открыть свойства вашей учетки в Outlook-e и добавить в неё дополнительный почтовый ящик. После выхода SP1 этого делать не нужно, все почтовый ящики, на которые вам назначены полные права, при запуске Outlook будут автоматически показаны в списке.

С одной стороны, такой поведение может показаться удобным. С другой… Даже если вручную закрыть дополнительный ящик в настройках учетки Outlook, при следующем запуске он снова будет открыт. Это влечет за собой следующие негативные моменты:

• Далеко не всегда нужно постоянно держать открытыми все ящики (которых может быть много), на которые у вас есть полные права, а также синхронизировать из содержимое.
• Если отменить полные права на дополнительный ящик, он по-прежнему будет выводится в Outlook, но при попытке просмотреть его содержимое выдаст ошибку прав доступа.

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

• Включить отображение Advanced Features в консоли Active Directory Users and Computers
• Для каждой учетной записи, ящик которой автоматически подключается к вашей
  • открыть Attribute Editor
  • найти параметр msExchDelegateListLink
  • удалить вашу учетку из этого списка

После перезапуска Outlook ящики обработанных таким образом пользователей отображаться не будут.

Подробнее об описанной функции можно почитать в статье Auto-mapping shared mailboxes in Exchange 2010 SP1 with Outlook 2010.

Служба Microsoft Exchange Transport на стартует при запуске системы

После перезагрузки сервера можно обнаружить, что письма через него не ходят. Причиной тому — остановленная служба Microsoft Exchange Transport, которая почему-то не запускается при старте системы, хотя должна. Если службу стартовать вручную, она запускается без проблем.

Если взглянуть в системный журнал, можно обнаружить следующие не очень радостные записи:

The Microsoft Exchange Transport service hung on starting.

Я долго не мог решить эту проблему, пока искал неисправности в самой операционной системе и компонентах Exchange. Как выяснилось, моя система и не была в чем-то виновата, а причиной стала неполная совместимость RTM-версии Forefront Protection for Exchange 2010 с Exchange Server 2010 SP1. Эта и другие проблемы была решены в выпуске Hotfix Rollup 2 для Forefront Protection for Exchange 2010 и описаны в статье KB2420647, всего через 3 месяца после выхода SP1 к Exchange 2010 ;[

Служба Microsoft Exchange Address Book на стартует при запуске системы

А должна бы! Эта служба необходима для полноценной работы Exchange, и если она остановлена, то, например, новый пользователь не сможет подключить свой Outlook к Exchange.

В журнале можно увидеть следующие записи:

Log Name: System
Source: Service Control Manager
Event ID: 7000
Description:
A timeout was reached (30000 milliseconds) while waiting for the Microsoft Exchange Address Book service to connect.

Log Name: System
Source: Service Control Manager
Event ID: 7009
Description:
The Microsoft Exchange Address Book service failed to start due to the following error:
The service did not respond to the start or control request in a timely fashion.

Периодически, то же самое можно увидеть и для служб:

• Net.Tcp Port Sharing Service
• Microsoft Exchange Anti-spam Update
• Microsoft Exchange Mailbox Replication

А также для зависимых служб:

The Net.Tcp Listener Adapter service depends on the Net.Tcp Port Sharing Service service which failed to start because of the following error:
The service did not respond to the start or control request in a timely fashion.

Мне не удалось решить эту проблему осмысленными действиями, но после долгих плясок с бубном стабильный автозапуск этих служб заработал после… Удаления клиента System Center Configuration Manager 2007 R3 и агента System Center Operations Manager 2007 R2. Мне не известно, кто из них был виноват, так как после их повторной установки проблем с запуском служб не возникало.

Ошибки счетчиков производительности

В журнале приложений регулярно появляется пачка подобных записей:

Log Name: Application
Source: MSExchange Common
Event ID: 106
Level: Error
Description:
Performance counter updating error. Counter name is Average MWI Processing Time, category name is MSExchangeUMMessageWaitingIndicator. Optional code: 3. Exception: The exception thrown is : System.InvalidOperationException: The requested Performance Counter is not a custom counter, it has to be initialized as ReadOnly.
...
Performance Counters Layout information: FileMappingNotFoundException for category MSExchangeUMMessageWaitingIndicator : Microsoft.Exchange.Diagnostics.FileMappingNotFoundException: Cound not open File mapping for name : Global\netfxcustomperfcounters.1.0msexchangeummessagewaitingindicator
...

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

add-pssnapin Microsoft.Exchange.Management.PowerShell.Setup

Затем для каждой группы счетчиков (в моём примере это группа MSExchangeUMMessageWaitingIndicator):

new-perfcounters –definitionfilename "c:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\MwiLoadBalancerPerformanceCounters.xml"

Каждой группе потерянных счетчиков в папке c:\Program Files\Microsoft\Exchange Server\V14\Setup\Perf\ соответствует XML-файл, который можно определить либо по имени, либо поиском по содержимому.

Возможные конфликты портов

Некоторые службы Exchange используют динамические порты для входящих соединений RPC. Динамические порты случайно выбираются при каждом запуске соответствующей службы. По счастливому случаю выбор может пасть на зарезервированный порт другой службы, которая еще не успела запуститься и занять свой порт. Тогда мы получим подобный конфликт:

The WinRM service is not listening for HTTP requests because there was a failure binding to the URL (http://+:47001/wsman/) in HTTP.SYS.

No remote requests will be serviced on that URL.

User Action
Please use "netsh http" to check if ACL for URL (http://+:47001/wsman/) is set to Network Service.

Unable to bind to the underlying transport for [::]:47001. The IP Listen-Only list may contain a reference to an interface which may not exist on this machine. The data field contains the error number.

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

netstat -ano | findstr ":47001"
TCP 0.0.0.0:47001 0.0.0.0:0 LISTENING 1412
tasklist |findstr "1412"
Microsoft.Exchange.RpcCli 1412 Services 0 159 036 K

…им оказалась служба Microsoft.Exchange.RpcCli. Чтобы избежать конфликтов, рекомендую настроить привязку к фиксированным портам с помощью следующих записей в реестре (для Exchange 2010 SP1):

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeAB\Parameters]
"RpcTcpPort"="59533"

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeRPC\ParametersSystem]
"TCP/IP Port"=dword:0000e88c

Подробное описание этих настроек можно узнать в статье Configuring Static RPC Ports on an Exchange 2010 Client Access Server.

Предупреждения о HomeMTA

Log Name: Application
Source: MSExchange ADAccess
Event ID: 2937
Level: Warning
Description:
Process powershell.exe (PID=8552). Object [CN=Username,CN=OU,DC=domain,DC=local]. Property [HomeMTA] is set to value [domain.local/Configuration/Deleted Objects/Microsoft MTA DEL:...], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.

Причиной сему — опять же обновление до SP1, в ходе которого почему-то не все пользователи Exchange были должным образом обработаны. Для решения этой проблемы в Exchange Management Shell нужно выполнить:

Get-Mailbox Username | Update-Recipient

Для массового обновления все ящиков пользователей в конкретной базе MDB можно использовать get-mailbox -database "MDB".

Полезные ссылки

• Exchange в вопросах и ответах: Изучаем Exchange Server 2010 SP1
• How to unload/reload performance counters on Exchange 2010
• Overview of Services Installed by Exchange Setup
• Services for Exchange Server 2007 or Exchange Server 2010 cannot start automatically after you install Exchange Server 2007 and Exchange Server 2010 on a global catalog server
• How to manually rebuild Performance Counter Library values
• Event ID 1000 — System Performance Counters Availability
• Backscatter protection: how to do it with Forefront Protection 2010 for Exchange Server

• Forefront Endpoint Protection 2010 может устанавливаться только в инфраструктуру с уже развёрнутым System Center Configuration Manager 2007, R2 или R3. Это достаточно серьезное требование даже для больших организаций.
• В отличае от FCS, установка FEP 2010 очень проста и проходит по принципу Next-Next-Next, не представляет никакой сложности для человека, осилившего установку Configuration Manager-a.
• Клиент (само антивирусное ядро) приобрёл обновленный вид и еще больше похож на своего бесплатного собрата — Microsoft Security Essentials.
• Автоматическое развёртывание клиентов теперь возлагается не на WSUS, а на метод Software Advertisements в Configuration Manager.
• Единый пакет для развертывания клиентской части FEP 2010 содержит в том числе и русскую локализацию интерфейса, поэтому даже при установке английских серверных компонентов FEP 2010 на английский ConfigMgr, клиентский машины с русской версией ОС получат русский интерфейс в клиенте FEP 2010.
• Была расширена функциональность исключений из сканирования антивирусным ядром:
  • можно добавлять типы файлов
  • разрешается использовать переменные для путей к исключаемым папкам, пример: %ExchangeInstallPath%\ExchangeOAB
  • клиент FEP, автоматический устанавливаемый на сервер с Configuration Manager-ом уже содержит преднастроенные исключения
• Обновление антивирусных баз теперь возможно не только через WSUS и Microsoft Update, но и с файловой шары.
• Если запустить развертывание клиента FEP 2010 на компьютере c уже установленным клиентом FCS, все компоненты FCS, в том числе агент MOM, будут предварительно удалены. Также, поддерживается автоматическое удаление других популярных на западе антивирусов.

Продолжение следует…

Полезные ссылки

Документация

• Официальная документация — краткая, но вполне достаточная
• Установка и первоначальная настройка System Center Configuration Manager 2007 R2 — статья на русском, вполне пригодна для первоначального знакомства с ConfigMgr

Пробные версии

• Пробная версия Microsoft Forefront Endpoint Protection 2010
• Пробная версия Microsoft System Center Configuration Manager 2007 R3

Настройка исключений

• File-Level Antivirus Scanning on Exchange 2010
• Guidelines for choosing antivirus software to run on the computers that are running SQL Server
• Recommended file and folder exclusions for Microsoft Forefront Client Security or Forefront Endpoint Protection 2010

Однако, радость после установки русифицированного Unified Messaging длиться до тех пор, пока не начинаешь использовать его возможности всерьёз. Выяснятся, что поиск 30% контактов в глобальной адресной не возможен, а некоторые голосовые команды либо не воспринимаются, либо выполняют совсем не то, что было приказано.

В данной статье я опишу найденные мной недостатки в русифицированном Outlook Voice Access и способы их устранения.

Поиск в адресной книге по имени

Было замечено, что при голосовом поиске контактов в глобальной адресной книге организации («справочник») 30% контактов никак найти не удается. Тётенька на той стороне провода упорно не понимает нас. Причем искомые контакты труднопроизносимыми назвать никак нельзя. Например, мои коллеги Дмитрий Кекин и Мария Волкомурова.

К удивлению, если занести те же имена в личную адресную книгу («личные контакты»), они находятся без проблем. Распознаются и более сложные имена типа «Отдел инфраструктурных решений».

Такое поведение наводит на мысль, что речевой анализатор Unified Messaging способен в принципе воспринимать указанные проблемные имена, но по какой-то причине не делает этого.

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

Результаты работы генератора грамматик хранятся по адресу:

Если заглянуть в файл gal.grxml, то можно обнаружить, что в нём не хватает именно тех имен, которые не может найти в «справочнике» Outlook Voice Access.

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

В получившемся файле журнала видим множество записей подобного вида:

Лог говорит о том, что для текста «Дмитрий Кекин» генератор грамматик находит несколько способов произношения, а допустим только один вариант. Для этого же имени, записанного в личных контактах, анализатор сохраняет все варианты произношения. Объяснение того, почему сделано именно так, дано в этой старой записи блога разработчиков Exchange.

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

А возможность увеличить лимит «похожих» имен все-таки существует. Для этого нужно отредактировать в файле Program Files\Microsoft\Exchange Server\V14\Bin\MSExchangeUM.config параметр GrammarNormalizedFormLimit.

Для того, чтобы анализатор грамматики стал однозначно понимать имя, для учётной записи соответствующего пользователя нужно подобрать значение атрибута PhoneticDisplayName. Экспериментально установлено, что обычно работает простое повторение гласных в ударном слоге. Попробуем сделать Дмитрия Кекина узнаваемым с помощью следующей команды в Exchange Management Shell:

Затем обновим глобальную адресную книгу:

И генерируем новый файл грамматики для неё:

Открыв log2.txt, по-прежнему видим:

Но заглянем в C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\grammars\ru-RU\gal-*.grxml:

А это значит, что Дмитрий Кекин теперь доступен для поиска в «справочнике».

Итак, с поиском по контактам мы разобрались. Продолжим устранять другие неприятности.

Голосовые команды

Общаясь с Outlook Voice Access, можно заметить, что некоторые голосовые команды могут либо не распознаваться вовсе, либо по данной команде будет выполняться совершенно другое действие. Причиной тому — некачественные перевод. Вероятно, тексты для диктора и тексты ожидаемых от пользователя команд переводили разные переводчики. Своё отношение к переведенным на русский язык программным продуктам я давно хочу высказать в отдельной статье.

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

Пример 1. Мы нашли в справочнике контакт Дмитрий Кекин. Дали голосовую команду «воспроизвести подробную информацию». Послушали. Теперь нам предлагают «оставить голосовое сообщение», либо «найти другой контакт». Говорим «найти другой контакт». Система начинает вместо этого записывать голосовое сообщение.

Чтобы исправить эту ошибку, находим файл C:\Program Files\Microsoft\Exchange Server\V14\UnifiedMessaging\grammars\ru-RU\ contacts.grxml. Открываем и видим:

Конфиг указывает на то, что система действительно при произнесении слов «найти другой контакт» выполняет действие recoSendMessage. Чтобы исправить это недоразумение, удаляем ошибочные теги <item> и сохраняем файл грамматики. Для применения изменений нужно выполнить:

Пример 2. Мы нашли в справочнике контакт Дмитрий Кекин. Среди прочих действий нам предлагают «позвонить на рабочий номер» и «позвонить на мобильный». Сколько бы раз мы не повторяли «позвонить на рабочий номер», барышня нас не понимает. Причина банальна:

При таком конфиге речевой анализатор не ждет от нас команды «позвонить на рабочий номер». Ну чтож, добавим тэг с этой командой, сохраним файл и сгенерируем грамматики.

Пример 3. Мы нашли в справочнике контакт Дмитрий Кекин. Среди прочих действий нам предлагают «позвонить на рабочий номер» и «позвонить на мобильный». Говорим «позвонить на мобильный». Если в вашей среде настроена интеграция Exchange UM и Lync Server (OCS) по известным статьям (TechNet и других уважаемых авторов), то звонить на мобильный барышня не станет. Причина этого: по умолчанию Exchange UM не допускает исходящих вызовов. Для их включения нужно в Exchange Menagement Console:

• в разделе Organization Configuration → Unified Messaging открыть свойства текущего диалплана
• на вкладке Dialing Rule Groups создать группу In-Country/Region с произвольным именем, а Number mask и Dilaed number указать равным *
• в разделе Organization Configuration → Unified Messaging открыть свойства UM Mailbox Policy для текущего диалплана
• На вкладке Dialing Restrictions добавить созданное ранее правило in-country/region

Полезные ссылки

• Understanding Automatic Speech Recognition Directory Lookups — на языке оригинала ;)

Не смотря на всю их подробность и наполненность картинками, при настройке интеграции Lync Server 2010 и Asterisk 1.8 я столкнулся с русскими реалиями…

Вроде бы все настроено как надо по мануалу, логично и понятно. В точно такой же конфигурации Asterisk-a OCS 2007 R2 через него на внешнюю линию может звонить полноценно, а Lync только звонит на внутренние номера Asterisk-a и принимает вызовы от него, в том числе с внешней линии.

При попытке позвонить с Lync-а через Asterisk на внешнюю линию, слышим долгое молчание и сообщение об отмене вызова.

При этом на сервере Lync пишет в логи

А на стороне Asterisk-а можно увидеть

После долгих упражнений с бубном, я догадался включить вывод всех сообщений SIP на Asterisk-е командой sip set debug on. Затем сравнил сообщения для успешных случаев подключения OCS 2007 R2 и безуспешных попыток соединения Lync Server 2010.

И тут я увидел разницу

для успешных случаев:

для неудачных:

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

Для исправления этой ошибки, я вручную указал более простое имя вызывающего абонента командой Set в extensions.conf, например, так:

Полезные ссылки

• Step-by-step Microsoft Lync 2010, Asterisk and Skype installation/integration guide — детальное руководство по интеграции Lync Server с Asterisk

Компоненты SharePoint

Рассмотрим топологию компонентов SharePoint 2010:

• Ферма SharePoint
  • База данных конфигурации — единое место, где хранится конфигурация фермы SharePoint, именно здесь содержится информация о других базах данных и серверах приложений. При добавлении нового сервера в ферму SharePoint установщик первым делом спрашивает, к какой базе данных конфигурации подключаться.
  • Базы данных контента — в них хранится содержимое сайтов фермы.
  • Сервера приложений — собственно, это и есть сам SharePoint; состоит из множества служб, одни выполняют обработку HTTP-запросов пользователей, другие — всякие фоновые задания.

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

Перемещение баз данных контента

Базы этого типа можно легко мигрировать между серверами БД, достаточно выбранную базу удалить из конфигурации SharePoint (на странице узла администратора /_admin/CNTDBADM.aspx), а затем добавить в конфигурацию уже по новому адресу. Более подробно этот процесс расписан в статье TechNet Move content databases.

Перемещение всех баз данных SharePoint

Как упоминалось выше, SharePoint использует не только легко переносимые базы данных контента, но и центральную базу конфигурации, которая привязана к имени сервера, а потому так просто не переносится.

Хотя в библиотеке TechNet есть статья с названием Move all databases, действия, описанные в ней, не приводят к чистому изменению всех путей к базам данных… В этих путях по-прежнему фигурирует старое имя сервера, а доступ к новому серверу перенаправляется с помощью Alias-a. Это работает, если старый сервер функционирует, либо DNS имя старого сервера теперь ссылается на новый сервер. Но такие костыли не каждого устроят.

Если поискать в интернете, то можно найти такой способ переноса базы данных конфигурации: предлагают после переноса баз данных на новый сервер выполнить команды:

Но по их выполнению нас ждет разочарование:

И мы получим не работающую конфигурацию, и спасет нас только откат на резервную копию базы SharePoint_Config.

Итак, работающий алгоритм переноса всех баз данных SharePoint с одного сервера Microsoft SQL на другой.

1. Резервное копирование всех относящихся к SharePioint баз данных (можно посмотреть на странице узла администратора /_admin/DatabaseStatus.aspx) на старом сервере.

2. Восстановление БД из сделанных резервных копий на новом сервере.

3. Выполнение команды:

4. Profit.

Этот алгоритм применим только в том случае, если имя нового сервера в конфигурации SharePoint не упоминается (на странице узла администратора /_admin/FarmServers.aspx), то есть на новом сервере:

• нет компонентов сервера приложений SharePoint
• нет других БД SharePoint

Если ваша конфигурация фермы SharePoint не подходит для выполнения приведенного выше алгоритма, её можно привезти к необходимым условиям, выполнив, например,

1. Установку сервера приложений на другом сервере
2. Удаление компонент сервера приложений со старого сервера
3. Чистый перенос баз данных по вышеприведенному алгоритму
4. Если понадобится, вновь установка компонент сервера приложений на старом сервере, но уже с указанием нового сервера в качестве БД.

После развертывания Exchange 2010 SP1 и OCS 2007 R2 в тестовой среде, а затем их интеграции по официальным руководствам, я столкнулся с бедой. При звонке на голосовую почту моих контактов, или же напрямую на номера Subscriber Access или Auto Attendant через Office Communicator 2007 R2, я получал сигнал «занято» и сообщение:

При этом, судя по логам стека SIP со стороны OCS, установка соединения идет нормально, но обрывается после второго Invite ошибкой:

А на стороне Exchange, при включении экспертного журнала для UM видно, что звонки принимаются без намека на ошибки, но сразу завершаются, оставляя сообщения:

Я очень долго бился с этой проблемой, безуспешно привлекал к её решению сторонних специалистов. Пока в конце концов не решился попробовать собрать всю связку Exchange+OCS с нуля, поставив OCS 2007 R2 на ОС Windows Server 2008 без R2.

Только тогда, при обращении из коммуникатора к функциям UM, он стал ругаться следующим сообщением:

По нему я без труда нагуглил эту статью, в которой рассказывается, что по умолчанию Office Communicator 2007 R2 использует несовместимые с Exchange UM настройки шифрования. И исправляется такое поведение:

• использованием в качестве метода обеспечения безопасности Secured для UM Dialplan на стороне Exchnage
• централизованной настройкой коммуникатора через групповую политику, или локально через реестр на каждой машине

Полезные ссылки

Общие руководства

• Deploy Unified Messaging and Communications Server 2007 R2
• Configure Unified Messaging on Microsoft Exchange to Work with Office Communications Server
• Настройка взаимодействия Exchange 2010 SP1 и Communications Server
• Deploying Exchange Server 2007 and Office Communications Server 2007 R2

Решение проблем с голосовой связью

• Checklist: Deploy Office Communications Server 2007 R2 and Exchange 2010 Unified Messaging
• Troubleshooting Reference for Unified Messaging Servers
• Troubleshooting Tools for Enterprise Voice
• White Paper: Fundamentals of Troubleshooting Unified Messaging in Exchange 2007

Мой окончательный выбор почты для домена пал на Гугл, главными критериями выбора стали безопасность и интеграция сервисов. При нынешнем развитии программных средств по прослушке сетей любой школьник, если он окажется на пути трафика от вашей машины к серверу, может невозбранно собирать все явки и пароли к сайтам и почтовым службам, если не используется шифрование (SSL). Я выхожу в интернет из разных мест, и присутствие таких «школьников» на пути моего трафика не исключено.

Однако, используя сервисы Гугла, мне приходится мириться со следующими специфическими для меня неудобствами:

• При работе в английской локализации даты писем отображаются в формате MM\DD\YY, что крайне не приятно для человека русского. Причем изменить этот формат стандартными средствами нельзя. Решено с помощью активации Custom date formats Lab.
• При работе по стандартному протоколу IMAP есть очень милая мне возможность отметить сообщения на удаление, затем подумать, снять отметку с нужных, а затем кнопкой Purge окончательно удалить отмеченные сообщения. При работе с почтой Гугла по протоколу IMAP кнопка Удалить сразу отправляет сообщение в бездну (папку All Mail), полноценный доступ к которой для окончательного удаления или восстановления сообщения возможен лишь через веб-интерфейс. Решено с помощью активации Advanced IMAP Controls Lab.
• Через IMAP я закачал в почту Гугла свои отправленные сообщения за последние 5 лет без каких-либо проблем, но при доступе к списку этих сообщений через веб-интерфейс поле КОМУ ошибочно отображает слово ME вместо реального получателя письма (в почтовом клиенте IMAP все отображается корректно). Также я не нашел способа рассортировать отправленные сообщения по вложенным папкам так, чтобы формат вывода списка этих сообщений не менялся на тип входящих (когда в списке отображается поле ОТ, которое для исходящих интереса не представляет, ведь нужно видеть КОМУ).
• При отправке сообщений через SMTP Гугла, это сообщение автоматически попадает в папку отправленных писем, и это поведение отключить нельзя. Почтовый клиент IMAP делает то же самое по завершению отправки. Таким образом, получается ненужное дублирование.

Также, как и в статье Установка Office Communications Server 2007 R2 на Windows Server 2008 R2, достаточно установить спрятанный в недрах системы пакет Windows Media Format Runtime следующей командой:

Статья пока находится в процессе написания, не удивляйтесь возможным нестыковкам.

Программа сертификации MCP

Старая программа Legacy MCP (до 2007 года)

Ранее MCP — Microsoft Certified Professional являлся статусом сертификации первого уровня, который давался за сдачу одного экзамена.

Для получения сертификационного статуса боле высокого уровня нужно сдать несколько экзаменов уровня MCP, которые входят в список требований к сертификации. Например, на статус MCSA — Microsoft Certified Systems Administrator нужно сдать 4 экзамена: 2 по серверной ОС, 1 по клиентской ОС, 1 экзамен по выбору из списка.

Новая программа New Generation MCP

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

Microsoft Certified Technology Specialist

На смену статусу MCP пришел новый статус первого уровня — MCTS (Microsoft Certified Technology Specialist), который подтверждает знание в рамках конкретной технологии. Состоит из двух частей: общего статуса MCTS и области специализации. Например, MCTS: Windows Server 2008 R2, Desktop Virtualization. Знания на уровне MCTS предполагают понимание возможностей и особенностей продукта в определенной области специализации, но не требуют понимания работы всей системы, в составе которой данная технология работает.

В экзаменах уровня TS основным вопросом является «Как?»: установить продукт, настроить, поддерживать, решать возникающие проблемы. Сложных вопросов, в которых нужно размышлять, практически не встречаются. Обычно требуется вспомнить точное название такой-то галочки в диалоге настройки продукта, или еще хуже, ключа команды PowerShell.

Microsoft Certified IT Professional

Статус сертификации второго уровня носит имя MCITP (Microsoft Certified IT Professional) и подтверждает наличие полного набора навыков, необходимых для выполнения определенной роли. Этот статус базируется на знаниях MCTS (TS экзамены первого уровня), но в дополнение к ним требует один или несколько сданных экзаменов второго уровня (PRO). Эти экзамены проверяют понимание взаимодействия технологий в составе системы и общий кругозор, в том числе представления о технологиях конкурирующих с Microsoft вендоров. Например, для получения статуса MCITP: Enterprise Administrator нужно сдать 4 TS-экзамена первого уровня и 1 PRO-экзамен второго уровня.

В экзаменах уровня PRO вопросы намного сложнее, длиннее по тексту, глубже и интереснее, чем в TS. Проверяют обобщенные, высокоуровневые знания, способность аргументированно ответить на вопрос «Почему?». Не редко для того, чтобы правильно ответить вопрос, может понадобится нарисовать в воображении или на бумаге схему.

Microsoft Certified Master

Существуют и более высокоуровневые сертификации: MCM (Microsoft Certified Master) требует наличия статуса MCITP: EA, прохождения обучения по программе MCM в Редмонде (штаб-квартира Microsoft) у самих разработчиков продукта и сдачи нескольких практических экзаменов по окончанию обучения. Эта сертификация предназначена для признанных лидеров индустрии и для России мало востребована (говорят, что в России пока всего один MCM, и тот является сотрудником Microsoft).

Microsoft Certified Architect

Статус MCA (Microsoft Certified Architect) еще более высок, требует наличия MCM и предоставления на рассмотрение наблюдательному совету выполненных крупномасштабных проектов. По сути, в отличии от технического MCM, проверяются лидерские и презентационные качества кандидата.

Enterprise Administrator — администратор предприятия

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

• Сетевая инфраструктура.
• Службы каталогов, управление идентификацией и аутентификацией.
• Политики безопасности.
• Обеспечение непрерывности бизнеса (аварийное восстановление оборудования и данных).
• Разработка административной структуры отдела ИТ (моделей делегирования).
• Лучшие практики, стандарты и соглашения об уровне обслуживания (SLA).

Администратор предприятия отвечает за проектирование и глобальные изменения в конфигурации ИТ-инфраструктуры. Роль администратора предприятия предполагает 20% операций, 60% разработки и 20% поддержки.

• MCITP: Enterprise Administrator на Microsoft Learning
• Enterprise Administrator Job Role

Enterprise Messaging Administrator — администратор обмена сообщениями предприятия

EMA несут ответственность за среду обмена сообщениями Exchange в корпоративной среде. Являясь старшими администраторами, они выступают как технические руководители в команде администраторов, 3-й уровень поддержки.

EMA отвечают за планирование и развертывание серверов Exchange в корпоративной среде, имеют опыт администрирования, развертывания, управления, мониторинга, модернизации, миграции и проектирования.

• MCITP: Enterprise Messaging Administrator 2010 на Microsoft Learning
• Enterprise Messaging Administrator Job Role

Virtualization Administrator — администратор виртуализации

Сертификация Virtualization Administrator удостоверяет знания и навыки, которые связаны с работой ведущего инженера по решениям виртуализации в организации, в том числе способность проектировать и внедрять решения по виртуализации на основе Windows Server 2008 R2.

• Microsoft Virtualization Certification на Microsoft Learning

Ссылки

• Microsoft Certification Overview
• Обучение и сертификация — раздел на русском сайте Microsoft
• Статистика Microsoft Certified Professionals в России [у меня есть подозрение, что не обновляется]
• Почему выгодно брать на работу сертифицированных специалистов Microsoft?

…развитие клонирования ОС от кустарного секторного через флешку к промышленному файловому по сети…

Для клонирования операционных систем ранее я использовал платные программы Symantec Ghost или Acronis True Image. Они выполняли свои функции и устраивали меня… Пока я не познакомился с Windows Deployment Services — еще более мощным средством от Microsoft для централизованного развертывания ОС, которое доступно как роль в Windows Server начиная с 2008 версии.

В данной статье будут рассмотрены следующие темы:

• Способы клонирования
• Работа с WIM-образами
• Windows Deployment Services
• Загрузочные образы WDS
• Создание загрузочного носителя
• Пример использования WDS для централизованного развертывания ОС
• Полезные ссылки

Способы клонирования

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

Секторный

Традиционный способ, его используют такие программы как Symantec Ghost и Acronis True Image.

Достоинства:

• Универсальность — как правило, при клонировании тип операционной системы не важен, поддерживалась бы файловая система.
• Скорость — секторное копирование намного быстрее файлового (структура файловой системы и фрагментация сильно не влияют на скорость копирования).

Недостатки:

• После создания образа нет возможности как-то его отредактировать в оффлайн-режиме (не развертывая на диск).
• Невозможно развернуть образ на целевой раздел поверх его содержимого (оставив существующие файлы).
• Закрытость формата — как правило, только софт, создавший образ, может с этим образом работать.

Файловый

При данном способе в реализации Microsoft образ ОС снимается на файловом уровне с помощью утилиты ImageX, результирующий файл образа имеет формат WIM.

Преимущества:

• Возможность подключать образ к файловой системе и редактировать его в оффлайн режиме. Можно даже устанавливать обновления и драйвера на поддерживающие эту функцию ОС (начиная с Vista).
• Открытость формата, с ним может работать и сторонний софт.
• Хорошее сжатие, ничего лишнего в процессе снятия образа в него не добавляется. Имеется возможность объединять несколько образов в один файл, при этом дублирующиеся файлы не занимают дополнительного места.

Недостатки:

• Низкая скорость работы (все особенности размещения файлов и фрагментация имеет значения).
• Ограниченная поддержка ОС и файловых систем (только Microsoft, начиная с Windows XP)

Работа с WIM-образами

Для создания, редактирования и развертывания WIM-образов операционных существует несколько стандартных средств, которые дополняют друг друга:

• ImageX — текстовая утилита для создания, редактирования и применения WIM-образов.
• Windows Automated Installation Kit — набор средств создания образов для автоматизированной установкой ОС, содержит Windows PE.
• Windows Deployment Services, о котором будет рассказано ниже.
• Microsoft Deployment Toolkit — продвинутый пакет для тонкой настройки установочных образов (скачать). Функциональность частично пересекается с WDS: работа с сетью ограничена файловой шарой, но шире возможности по настройке действий, выполняемых образами (Task Sequence).
• System Center Configuration Manager — мощнейшее средство для централизованного развертывания ОС без участия пользователя(zero-touch install), объединяет и использует перечисленные выше программы.

Windows Deployment Services

Эта роль доступна в Windows Server начиная с 2008 версии, роль-предшественница в Windows Server 2003 называлась RIS.

WDS позволяет:

• Систематизировано хранить в одном месте подготовленные WIM-образы операционных систем.
• Выполнять загрузку компьютеров по сети с загрузочных образов (Boot Images) при помощи PXE.
• Развертывать ОС семейства Windows (XP, Server 2003, Vista, 7, Server 2008/2008R2) из хранимых установочных образов (Install Images).
• Выполнять параллельное развертывание ОС на несколько компьютеров при помощи многоадресной рассылки.

Служба WDS достаточно проста и дружелюбна к пользователю, а встроенный хелп к ней краток и понятен. После установки WDS в мастере начальной конфигурации рекомендую выбрать Respond to all clients computers на этапе настройки PXE Response Policy. Это избавит нас от предварительного ручного создания объектов в Active Directory для каждого компьютера, загружаемого по сети.

После прохождения мастера начальной конфигурации WDS готова к работе. Начать освоение предлагаю с добавления на сервер стандартного установочного WIM-образа (Install Image) Windows 7, который можно взять с установочного диска по адресу \sources\install.wim. Для загрузки компьютеров по сети и развертывания на них установочных образов необходимо добавить загрузочные образы (Boot Images), о которых я далее расскажу подробнее.

Загрузочные образы WDS

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

Setup Boot Image — устанавливающий загрузочный образ

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

Для добавления Setup Boot Image на сервер WDS достаточно выполнить команду Add Boot Image и в качестве файла-источника указать \sources\boot.win от обычного установочного диска Win7/WS2008R2 нужного языка и разрядности.

Capture Boot Image — захватывающий загрузочный образ

Загрузившись с такого образа будет предоставлен графический интерфейс, позволяющий:

• Выбрать раздел на компьютере, который нужно «захватить» в WIM-образ.
• Задать имя и описание образа.
• Выбрать размещение создаваемого WIM-файла.
• Опционально отправить полученный WIM-образ на сервер WDS по сети.

Чтобы добавить Capture Boot Image на сервер WDS достаточно кликнуть правой кнопкой на уже существующем Setup Boot Image и выбрать в контекстном меню Create Capture Image.

Discover Boot Image — обнаруживающий загрузочный образ

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

Для создания Discover Boot Image нужно кликнуть правой кнопкой на уже существующем Setup Boot Image и выбрать Create Discover Image. Результатом данной операции будет загрузочный WIM-образ. О том, как создавать загрузочные ISO-образы и флешки с WIM-файлами я расскажу далее.

Создание загрузочного носителя

Далеко не всегда есть возможность загружать компьютер по сети с сервера WDS, поэтому может возникнуть необходимость локально загружать Setup и Capture образы с компакта или флешки.

Для создания таких носителей предварительно необходимо установить Windows Automated Installation Kit (WAIK, загрузить можно здесь) и выполнить следующие действия.

1. От имени админа запустить Deployment Tools Command Prompt.

2. Выполнить

где вместо x86 можно выбрать другую разрядность (x86, amd64, ia64).

3. Скопировать в папку c:\Deploy\WinPE_x86\ISO\sources нужный вам загрузочный WIM-образ (Setup, Capture, Discover) и назвать его boot.wim.

4. Теперь по адресу c:\Deploy\WinPE_x86\ISO лежит заготовка для создания загрузочного носителя.

Создание загрузочного ISO-образа

Из Deployment Tools Command Prompt выполнить

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

Создание загрузочной флешки

1. Отформатировать флешку в FAT32, сделать этот раздел активным.

2. Взять утилиту bootsect.exe из папки \boot установочного диска Win7/WS2008R2 нужной разрядности.

3. Выполнить от имен администратора

где e: — буква диска флешки.

4. Скопировать содержимое c:\Deploy\WinPE_x86\ISO в корень флешки.

Загрузочная флешка готова.

Пример использования WDS для централизованного развертывания ОС

1. Добавляем на сервер WDS стандартный установочный образ Windows 7 (из \sources\install.wim установочного диска).
2. Загружаем образцовый компьютер по сети в устанавливающий образ Setup Boot Image, и разворачиваем Windows 7 из стандартного образа.
3. Настраиваем установленную ОС как нам нужно.
4. Готовим ОС для клонирования с помощью SysPrep.
5. Клонируем с помощью Capture Boot Image и загружаем полученный WIM-образ на сервер WDS.
6. Развертываем образцовый WIM на нужные компьютеры по сети с помощью Install Boot Image или с других носителей (флешек, компактов).

Полезные ссылки

• Deployment TechCenter
• Deploying Windows 7 — серия из 29 статей Митча Туллоча, автора многих книг Microsoft Press

Возможности программного RAID в Windows Server

Поддерживаются следующие массивы:

• чередующийся том (striped volume, RAID0)
• зеркальный том (mirrored volume, RAID1)
• том RAID5 (RAID5 volume)
• охватывающий том (spanned volume, один логический том размещается более чем на одном физическом диске)

Динамические диски

Массивы RAID можно создавать только на динамических дисках — особая разметка физических дисков (понятная только Windows), которая обладает следующими особенностями:

• Обычный (базовый) диск можно преобразовать в динамический только целиком.
• Обратное преобразование динамического диска в базовый возможно, но только если с динамического диска удалить все тома.
• Динамический диск представляет собой один большой NTFS раздел, на котором с помощью хитрой служебной информации может размещаться большое количество томов (как простых, так и RAID), имеется возможность изменять размеры простых томов штатными средствами Windows. Однако, насколько оптимально и фрагментировано будут размещаться данные, мне не известно.
• Известные мне программы клонирования, восстановления и изменения размеров дисков не поддерживают динамические диски.
• Динамические диски, содержащие RAID-тома, могут быть перенесены на другой компьютер с Windows Server, так как содержат необходимую информацию для правильной сборки массива.

Невозможно создать тома с разными уровнями RAID

На одной группе физических дисков можно создавать тома RAID только одного типа (уровня). Например, если у нас есть 3 физических диска, и мы создали на них том RAID5, не занимая всего пространства. Мы не сможем в свободном пространстве создавать тома другого уровня RAID (RAID0 и RAID1), а только RAID5 и простые тома.

Одновременная синхронизация томов

Если на одной группе дисков создано несколько томов RAID, то в случае какого-либо сбоя после загрузки компьютера они начинают восстанавливаться одновременно. Это лютый, бешеный EPIC FAIL! Простая ситуация: имеется два физических диска, на них создано два RAID1 тома, один под операционную систему, другой под данные.

Такая схема замечательно работает до первого сбоя (простейшие виды — внезапное отключение питания или синий экран). И тут приходит ужас. Операционная система загружается и в это же время начинает одновременно синхронизировать оба тома RAID1. Таким образом, физические диски получают конкурирующие команды для интенсивных последовательных операций сразу в трех разных физических областях. При этом механика дисков дико изнашивается, кэш бесполезен.

Со стороны такая «отказоустойчивость» выглядит следующим образом: общее быстродействие дисковой подсистемы падает раз в 20, сама ОС загрузится либо после окончания синхронизации одного из томов (минут 15, если он небольшой, гиг на 50), либо минут через 20 и будет бесполезна до конца синхронизации одного из томов.

Вышеописанное поведение я считаю недопустимым архитектурным просчетом со стороны Microsoft и удивлен тем, что эта беда не решена до сих пор со времен появления программного RAID в Windows 2000 Server.

Если вы попали в описанную ситуацию, то не стоит дожидаться загрузки ОС и изнашивания дисков.

1. Отключаете один из физических дисков.
2. Загружаетесь в ОС с нормальной скоростью.
3. Разбиваете зеркало, превратив тома RAID1 в простые.
4. Подключаете обратно второй диск.
5. Создаете только одно зеркало для необходимого вам тома.

RAID5

Опишу сценарий, при котором вы не сможете восстановить деградировавший массив RAID5 до здорового состояния, даже если для этого предоставлены все условия.

1. Имеется массив RAID5 из шести дисков (Диск1-Диск6).
2. Среди них есть один сбойный Диск1 (например, из терабайтного объёма пара мегабайт не читаются), но операционная система об этом еще не знает и как сбойный его не отметила.
3. По каким-либо причинам от массива был отключен исправный Диск2.
4. Следуя логике RAID5, при отказе одного диска работоспособность массива сохраняется, такой массив помечается как деградировавший (degraded), скорость его работы резко падает, требуется синхронизация с новым исправным диском.
5. Исправный Диск2 подключается на место. Система его опознает как сбойный. Чтобы синхронизировать массив, этот сбойный диск нужно удалить из массива RAID5 и определить как пустой.
6. Все готово для синхронизации массива. Запускаем исправление массива (repair) на пустой Диск2.
7. ВНЕЗАПНО синхронизация натыкается на ошибки чтения на действительно неисправном диске Диск1 и останавливается.
8. Весть массив остается деградированным. Диск1 помечен как содержащий ошибки (errors), Диск2 помечен как online, однако из-за прерванной синхронизации не содержит полных корректных данных.
9. В надежде на восстановление подключается совершенно новый исправный Диск7. Запускается восстановление массива на него.
10. В результате исправный Диск2 заменяется на другой исправный Диск7, но синхронизация снова прерывается, найдя ошибку на неисправном диске Диск1.
11. И так далее по циклу.

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

Не желая признавать поражения, я пытался сделать следующие вещи:

• Синхронизировать массив с пропуском ошибок чтения на диске Диск1 (ведь это всего лишь мегабайты их целого терабайта). Но Microsoft не дает такой возможности.
• Посекторно переписать весь сбойный Диск1 на другой здоровый диск с помощью программ для клонирования. Однако, доступные мне программы с динамическими дисками не работали.

Пример грамотной реализации программного RAID

От перечисленных выше недостатков избавлена аппаратно-программная реализация RAID-контроллера, известная как Intel Matrix Storage, и недавно переименованная в Intel Rapid Storage (работает на RAID-версиях чипсетов, таких как ICH9R, ICH10R). Аппаратно-программный RAID от Intel обеспечивает многие преимущества «врослых» RAID-контроллеров:

• возможность определить диски горячей замены
• возможность создавать тома разного уровня RAID на одной группе дисков
• последовательная синхронизация и проверка RAID томов на группе дисков

Основным ее недостатком, в отличии от полностью аппаратных RAID-контроллеров, остается «программность», из которой вытекают:

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

Полезные ссылки

• Что собой представляют динамические диски — Windows IT Pro [довольно старая статья]
• Вся правда о динамических дисках — Хакер [читать осторожно, «вся» правда перемешана с небылицами]

• Общие представления о PKI
• Автоматический запрос сертификатов
• Ручная установка сертификата корневого ЦС
• Проверка отзыва сертификатов
• Веб-службы регистрации сертификатов
• Запрос сертификата с альтернативным именем
• Обобщенные лучшие практики
• Полезные ссылки

Общие представления о PKI

Чем более интегрированной, сложной и защищенной становится инфраструктура на Windows Server, тем больше она полагается в добавок к традиционной Active Directory на PKI (Public Key Infrastructure, переводят как инфраструктура открытого ключа) для обеспечения доверительных отношений и проверки подлинности между компьютерами, пользователями и службами. Active Directory Certificate Services — это реализация PKI от Microsoft, которая состоит из следующих элементов:

• Центр сертификации (ЦС, Certification Authority), корневой и подчиненные
• отношения всеобщего доверия к ЦС
• выдаваемые ЦС сертификаты для компьютеров, пользователей и служб
• различные службы поддержки PKI
  • списки отзывов сертификатов (CRL)
  • сетевой ответчик (Online Responder, более прогрессивная альтернатива CRL)
  • Web Enrollment (средство запроса сертификатов через Web)

Автоматический запрос сертификатов

От центра сертификации нет толку, если клиентские компьютеры в вашей сети не имеют к нему доверия и/или не получают сертификаты. При установке ЦС в домене Active Directory по умолчанию должны создаваться групповые политики, которые прописывают доверие клиентов к корневому ЦС и автоматический запрос сертификатов компьютера у него. Однако, при некоторых сценариях эти политики необходимо настраивать вручную и в этом поможет статья TechNet Configure Computer Certificate Autoenrollment.

Ручная установка сертификата корневого ЦС

Если в среде Active Directory и локальной сети доверие к корневому центру сертификации настраивается автоматически, то для доверия к ЦС со стороны недоменных удаленных компьютеров необходимо установить сертификат ЦС в их хранилище Доверенные корневые центры сертификации. Иначе либо будут выдаваться предупреждения о потенциальной опасности подписанного неизвестно кем сертификата, либо вообще соединения с таким сервером будут отклонятся, как, например, в случае с Remote Desktop Services Gateway будет выдаваться такая ошибка:

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

Через MMC

Открыть MMC с правами администратора » добавить оснастку Сертификаты » выбрать в качестве области Локальный компьютер » импортировать нужный сертификат в хранилище Доверенные корневые центры сертификации. Более подробно в статье TechNet Manage Trusted Root Certificates.

Через свойства сертификата

Запустить командную строку с правами админа » вызвать в ней с:\path\to\cert.crt » откроется окно свойств сертификата » нажать кнопку Установить » отметить галку Показывать физические хранилища » выбрать хранилище для установки сертификата Доверенные корневые центры сертификации » Локальный компьютер.

Через командную строку

Потребуется утилита CertMgr, с помощью нее нужно выполнить следующую команду:

Проверка отзыва сертификатов

Некоторые сетевые службы (удаленные рабочие столы, DirectAccess, L2TP и SSTP VPN), которые используют сертификаты для проверки подлинности сервера, требуют проверки этих сертификатов на легитимность (но отозваны ли они центром сертификации). В окружении локальной сети с такими проверками проблем не возникает, так как списки отзыва сертификатов опубликованы в Active Directory и по локальным адресам центра сертификации.

Ситуация меняется, если легитимность сертификата пытаются проверить из интернета, где, естественно, ни Active Directory, ни локальные адреса центров сертификации не доступны. И самое неприятное в том, что доверие системы к сертификату, выданному доверенным центром, но не проверенному на легитимность, еще ниже, чем к неизвестному или самоподписанному. Например соединение с удаленным рабочим столом отклоняется, выдавая ошибку:

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

• CRL (Certificate Revocation List, список отзыва сертификатов) на веб-сервере, регулярно обновляемый
• Online Responder (сетевой ответчик, доступный начиная с Windows Server 2008 редакции Enterprise), который функционирует примерно также, как и предыдущий вариант, но по более прогрессивному протоколу OCSP (но через HTTP)

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

За инструкциями по настройки ЦС для размещения CRL в интернете обращайтесь к статье TechNet Configuring Certificate Revocation. От себя лишь замечу хитрость: если ваш домен имеет доступное из интернета DNS-имя (то есть argon.com.ru, а не argon.local), а на сервер с корневым ЦС установлена опция Web Enrollment, то ЦС уже настроен на публикацию своих CRL по адресу http://server.argon.com.ru/CertEnroll. Поэтому для полноценной работы CRL достаточно просто опубликовать в интернете порт HTTP по доменному имени server.argon.com.ru.

Настройка и публикация Online Responder немного сложнее, но подробно описана в статьях TechNet Online Responder и Setting Up Online Responder Services in a Network. Тут уже никаких хитростей и настроек по умолчанию нет, честно устанавливаете роль на нужный сервер, конфигурируете эту роль, публикуете HTTP-сайт в интернете и настраиваете ЦС на включение информации об Online Responder’e в публикуемые сертификаты.

Проверить правильность функционирования проверки отзыва (CRL или OCSP) любого сертификата можно с помощью следующей команды:

где name.cer — имя выданного сертификата.

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

Веб-службы регистрации сертификатов

Они же Certificate Enrollment Web Services, если по-английски. Весьма полезная роль, которая позволяет:

• запрашивать сертификаты пользователями без участия администратора
• предоставлять по требованию сертификат корневого ЦС
• выполнять особые уже подготовленные запросы (Custom Request), например для веб-серверов под управлением Linux или других сетевых устройств
• делать это все через интернет
• сам Web Enrollment может работать на отличном от ЦС компьютере, что повышает безопасность корневого ЦС

Установка и настройка Web Enrollment проста и тривиальна за исключением следующих моментов

• в случае установки Web Enrollment на отличный от ЦС компьютер, необходимо обязательно выполнить шаги, описанные в статье TechNet Configuring Delegation Settings for the Certificate Enrollment Web Service Account, иначе служба не будет работать, выдавая следующую ошибку:

• та же ошибка будет выдаваться, если Web Enrollment работает на одном сервере с ISA Server / Forefront TMG, в их системных правилах нужно отключить Enforce strict RPC compliance и разрешить протокол RPC во внутреннюю сеть.
• при публикации Web Enrollment в интернете необходимо включить требование работы через SSL для веб-приложения CertSrv в консоли IIS

Запрос сертификата с альтернативным именем

Насущный вопрос при публикации внутренних служб предприятия в интернете — создание сертификатов со списком альтернативных имен DNS (Subject Alternative Name, SAN).

По умолчанию ЦС на Windows Server не настроен на выдачу сертификатов, содержащих SAN. Чтобы включить эту функцию на компьютере с ЦС нужно выполнить:

Запрос через консоль MMC

Начиная с Windows Server 2008 появилась возможность запросить сертификат с SAN через MMC-консоль Сертификаты, для этого…

• В консоли управления ЦС для шаблона сертификата Веб-сервер назначить права на запрос и чтение для учетки компьютера, запрашивающего сертификат.
• Компьютер, с которого создается запрос, должен входить в домен, в котором опубликован ЦС
• Создать запрос по шаблону веб-сервера → в свойствах запроса указать список альтернативных DNS-имен на вкладке Субъект → Дополнительное имя → DNS.

Запрос через утилиту certreq

Более гибким и универсальным способом запроса сертификатов с SAN является следующий, использующий утилиту certreq. Чтобы создать сертификат нужно действовать по следующему алгоритму:

1. Подготовить текстовый файл request.inf запроса сертификата со следующим содержанием.

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

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

3. Отправить запрос центру сертификации и получить в ответ .cer файл. Для этого можно воспользоваться MMC-конcолью управления Certification Authority (и указать .req файл) либо Web Enrollment (в окно расширенного запроса вставить содержимое .req файла и выбрать шаблон веб-сервера).

4. Выполнить установку полученного сертификата на целевой компьютер следующей командой

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

Обобщенные лучшие практики

Приведу пример рациональной реализации PKI на предприятии для поддержки передовых служб Windows Server 2008 R2

• На контроллере домена развернут корневой центр сертификации
• Если организации велика, то создано несколько подчиненных ЦС, выделенных для определенных целей (по назначению сертификата, по филиалу организации, для распределения нагрузки…)
• В групповых политиках настроено доверие к корневому ЦС и автоматический запрос сертификатов доменный компьютеров
• На пограничном компьютере-члене домена развернуты и опубликованы с помощью Forefront TMG в интернете службы:
  • Web Enrollment для установки сертификата ЦС и запроса личных сертификатов с недоменных компьютеров
  • Online Responder для проверки отзыва сертификатов по протоколу OCSP
• Опубликованы в интернете с использованием сертификатов с SAN следующие сетевые службы, опирающиеся на использование сертификатов и проверку их отзыва:
  • Remote Desktop Gateway
  • Outlook Web Access
  • DirectAccess
  • SharePoint

Полезные ссылки

• PKI предприятия
• How to configure the Windows Server 2008 CA Web Enrollment Proxy
• How to add a Subject Alternative Name to a secure LDAP certificate
• How to Request a Certificate With a Custom Subject Alternative Name
• Устанавливаем Certification Authority — Vadims Podans’s blog
• OCSP (часть 1), OCSP (часть 2) — Vadims Podans’s blog

Встретилось около 5 действительно интересных вопросов, и столько же узколобо-задротских. Остальные: либо шутки, либо отправка в Гугл. Рейтинг «Гуру» льстил бы намного больше, если бы все вопросы были адекватными и серьезными, а шуточные не влияли на рейтинг и задавались отдельно.

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

Решением оказалось остановка службы Windows Firewall, которая по умолчанию запущена, хотя ничего и не блокировала (защита отключена групповыми политиками).

За помощью в устранении других ошибок рекомендую обращаться к статье TechNet Troubleshooting Protection Agent Installation Issues.

После установки обновления KB975354 на Windows Server 2008 R2 компьютер может стать недоступен по сети. Происходит следующая неприятность: локальная сеть начинает определяется как публичная и включается самый ограниченный режим брандмауэра (все входящие соединения блокируются), даже если групповыми политиками фаэрволл настроен или отключен.

Чтобы устранить эту проблему достаточно зайти в настройки брандмауэра и отключить его для публичных и частных сетей. После этого чудесным образом моя локальная сеть начала определяться как доменная.

Предварительные требования

До недавнего времени, установка Office Communications Server 2007 R2 на Windows Server 2008 R2 официально не поддерживалась, но теперь вышла статья KB982021, в которой была заявлена поддержка и описаны шаги, которые необходимо предпринять перед установкой Office Communications Server 2007 R2 на Windows Server 2008 R2.

Предварительные требования к установленным компонентам Windows Server сильно варьируются в зависимости от устанавливаемых компонентов Office Communications Server 2007 R2. Выяснить требуемые компоненты Windows Server можно как методом тыка, реагируя на ругань установщика, так и поискав в документации (при текущей её организации — тяжело и неудобно). Также предварительные требования для различных компонентов OCS 2007 R2 хорошо описаны в этой статье.

Установка

На одном из шагов установки нас попросят установить Windows Media Format Runtime, которого нет по умолчанию в Windows Server 2008 R2. Установщик попытается установить его сам, однако, у него это получаться не будет. Видимо потому, что во время создания этого установщика Windows Server 2008 R2 еще не учитывался. Попытка загрузить Windows Media Format Runtime в интернете и установить его на Windows Server 2008 R2 тоже вряд ли увенчается успехом по той же причине. После долгих поисков я нашел следующие решения этой проблемы:

• в лоб — установить не очень нужный на сервере компонент Desktop Experience
• элегантно — установить только пакет Windows Media Format Runtime из встроенного хранилища системы следующей командой:

Для Windows Server 2008 R2 RTM:

Для Windows Server 2008 R2 SP1:

Ошибки в Web Components Validation Wizard

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

Казалось бы, статьи KB941095, KB941723, KB871179 и KB926642 описывают именно эту проблему, однако предлагаемое в них решение не работает.

И только новая версия статьи KB896861 дает ссылку на решающие проблему действия, описанные в статье KB281308.

Полезные ссылки

• Официальная документация
• Sample Deployment Walkthroughs
• OCS 2007 R2 Installation Walkthrough
• Installing OCS 2007 R2 Prerequisites on Windows Server 2008 R2
• Microsoft Office Communications Server 2007 R2
• Decommissioning Standard Edition Servers and Enterprise Pools — как корректно удалить OCS 2007 R2

Эта статья пошагово расскажет на примере моей инфраструктуры о том, как развернуть IPv6 на предприятии используя стандартные службы DNS и DHCP операционной системы Windows Server 2008 / 2008 R2.

• Адресация IPv6
• Установка и настройка DNS
• Установка и настройка DHCPv6
• Маршрутизация IPv6
• Полезные ссылки

Адресация IPv6

Как известно, в IPv4 стандартизированы диапазоны «серых» адресов для локальных сетей (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), аналогично и в IPv6 для локальных адресов принят диапазон fc00:/7.

Рассмотрим следующую схему адресации IPv6, которая принята для локальных сетей на платформе Windows Server:

• префикс сети (адрес сети в терминологии IPv4):
  fc00:a:b:c::/64, где a, b, c — выбирайте на ваше усмотрение из диапазона 0000-ffff, например fc00:10:18:1::/64
• адрес хоста в сети
  fc00:a:b:c:v:x:y:z, где v, x, y ,z определяют адрес хоста, например
  • fc00:10:18:1:feab:01cc:65de:180a — такой адрес может назначить DHCP-сервер
  • fc00:10:18:1::10 — настроенный вручную более читабельный адрес, например для сервера, который нужно будет указывать руками (:: означает пропуск группы нулей, может использоваться однократно в адресе).

На картинке показан пример настроек сервера, на котором далее будет настроена служба DHCPv6.

Как работает IPv6 совместно с IPv4

IPv6 замечательно работает совместно с уже развернутой инфраструктурой IPv4 следующим образом:

• На Windows Server 2008 / 2008 R2 разворачиваются службы DNS и DHCP, поддерживающие IPv6.
• Клиенты, поддерживающие IPv6 (Windows Vista, Windows 7), получают настройки от DHCP и регистрируют свои имена в DNS.
• Далее при обращении к узлам по DNS-имени в первую очередь идет попытка получить их адреса IPv6 (тип записи AAAA), в случае их отсутствия — IPv4 (тип записи A).
• Клиенты, не поддерживающие IPv6 (Windows Server 2003, Windows XP) продолжают пользоваться старым протоколом IPv4 как раньше.

При выборе префикса создаваемой сети IPv6 рекомендую схитрить: если в этой же физической сети располагается IPv4 сеть 10.18.1.0/24, то можно выбрать префикс fc00:10:18:1::/64 для сети IPv6.

Установка и настройка DNS

Так как адреса IPv6 еще менее человечны, чем в IPv4, то их применение без DNS можно оправдать только с точки зрения садомазохизма. Поэтому в первую очередь необходимо развернуть DNS сервер, поддерживающий IPv6 адреса. Такая поддержка есть в службе DNS начиная с Windows Server 2008.

Все, что нужно сделать — это сконфигурировать статические IPv6 адреса (например fc00:10:18:1::1) на DNS серверах, включить динамическое обновление записей клиентами (в окружении Active Directory — безопасное) и передать эти настройки клиентам локальной сети через DHCP, о чем рассказывается далее.

Установка и настройка DHCPv6

Протокол IPv6 менее приспособлен для ручных настроек, в отличии от IPv4, поэтому предполагает автоматическое конфигурирование параметров узлов сети через DHCP версии 6. Поддержка DHCPv6 появилась начиная с Windows Server 2008 и является частью стандартной роли DHCP сервера.

Перед установкой DHCP-сервера необходимо сконфигурировать статические адреса IPv6 для сетевых адаптеров, с которых сервер DHCPv6 будет обслуживать своих клиентов. Например, fc00:10:18:1::10.

Теперь можно перейти к установке стандартной роли DHCP. Первая опция, относящаяся к IPv6 называется DHCPv6 Stateless Mode. Её нужно включить, тогда на следующей странице у вас запросят адреса IPv6 DNS серверов и DNS-имя родительского домена.

Если DHCPv6 сервер был установлен с отключенным DHCPv6 Stateless Mode, то включить его можно выполнив команду:

и установив опции сервера DHCPv6:

• 00023 DNS Recursive Name Server IPv6 Address ;mdash; адреса IPv6 DNS серверов
• 00024 Domain Search List ;mdash; DNS-имя родительского домена

Теперь нужно создать область, в которой DHCPv6 серверу предстоит выдавать адреса своим клиентам. Особенностью DHCPv6 в Windows Server является то, что можно создать область только для адресов с длиной префикса сети равной 64, например fc00:10:18:1::/64.

На следующей странице предлагается указать область исключений, из которой DHCPv6 сервер не будет выдавать адреса. Так как адреса сервер выдает не по порядку, а псевдослучайным образом (по хитрому алгоритму, основанному на MAC адресе сетевого интерфейса), то область исключений должка включать IPv6 адреса серверов, которые был сконфигурированы вручную (DNS и DHCPv6 сервера). Пример области исключений: 0:0:0:1-0:0:0:99.

Казалось бы, осталось только активировать диапазон и авторизовать DHCPv6 сервер в Active Directory. Вскоре сервер начнет выдавать клиентам IPv6 адреса и настройки DNS. Но здесь начинается самое интересное: хоть клиенты эти настойки исправно получают, общаться между собой они не могут. Причем сие печальное поведение на момент написания этой статьи в официальной документации явно не отражено.

Чтобы исправить ситуацию, вызываем на клиенте

и видим, что клиент не имеет маршрута в сеть fc00:10:18:1::/64.

Вызываем на сервере

и среди прочего видим:

Из этого следует, что маршрут в сеть fc00:10:18:1::/64 на сервере DHCPv6 существует, но не опубликован. Для того, чтобы этот маршрут выдавался клиентам, необходимо включить на сервере объявление маршрутов командой

и опубликовать маршрут командой

где fc00:10:18:1::/64 — ваш префикс IPv6, Local — имя или индекс сетевого интерфейса DHCPv6 сервера.

Маршрутизация IPv6

Встроенная роль Routing and Remote Access начиная с Windows Server 2008 поддерживает маршрутизацию IPv6, однако для того, чтобы она полноценно заработала, необходимо выполнить следующие, не очевидные вещи.

1. В свойствах сервера Routing and Remote Access на вкладке IPv6 включить Enable IPv6 Forwarding и Enable Default Route Advertisement.

2. На сервере-маршрутизаторе IPv6 должно быть как минимум две сетевых карты.

Local (fc00:10:18:1::10/64 в моих примерах), смотрящая в локальную сеть, для которой мы на предыдущих шагах настраивали раздачу IPv6 адресов, префикса сети и других параметров по DHCP.

External (например fc00:10:18:2::10/64), которая по идее должна смотреть в другую сеть (у нас маршрутизатор все-таки), но может смотреть и в ту же, что и Local.

3. Для того, чтобы IPv6 клиенты в сети могли использовать наш маршрутизатор, он должен объявить себя как маршрут по умолчанию (Default Route Advertisement, как шлюз по умолчанию в терминах IPv4).

Для этого в Windows Server 2008 нужно выполнить команду

где fc00:10:18:2::180 — адрес следующего маршрутизатора по умолчанию (next-hop), находящегося в сети External. Не важно, существует он реально или нет. Для объявления маршрута по умолчанию в сеть Local на текущем маршрутизаторе next-hop должен быть указан.

Для Windows Server 2008 R2 всё проще, достаточно выполнить команду

для объявления маршрутизатора в сети Local как Default Route.

Полезные ссылки

• DHCPv6 — Understanding of address configuration in automatic mode and installation of DHCPv6 Server
• The Cable Guy / The DHCPv6 Protocol
• Кабельщик / Протокол DHCPv6
• IPv6 address — Wikipedia
• IPv6 на TechNet
• Introducing IPv6 on Your Network — материал TechNet из раздела WS2003
• IP Version 6 — скудный материал TechNet из раздела WS2008

• топологии синхронизации времени среди участников Active Directory
• оптимальной с моей точки зрения конфигурации сервера времени корневого эмулятора PDC
• полезных командах для настройки и диагностики синхронизации времени
• особенностях, которые нужно учитывать для виртуализированных контроллеров домена

Топология синхронизации времени среди участников Active Directory

Среди компьютеров, участвующих в Active Directory работает следующая схема синхронизация времени.

• Контроллер корневого домена в лесу AD, которому принадлежит FSMО-роль эмулятора PDC (назовем его корневым PDC), является источником времени для всех остальных контроллеров этого домена.
• Контроллеры дочерних доменов синхронизируют время с вышестоящих по топологии AD контроллеров домена.
• Рядовые члены домена (сервера и рабочие станции) синхронизируют свое время с ближайшим к ним доступным контроллером домена, соблюдая топологию AD.

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

Синхронизация клиентов корневого PDC может осуществятся как с его внутренних часов, так и с внешнего источника. В первом случае сервер времени корневого PDC объявляет себя как «надежный» (reliable).

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

Конфигурация NTP-сервера на корневом PDC

Конфигурирование сервера времени (NTP-сервера) может осуществляться как с помощью утилиты командной строки w32tm, так и через реестр. Где возможно, я приведу оба варианта.

Включение синхронизации внутренних часов с внешним источником

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"Type"="NTP"
• w32tm /config /syncfromflags:manual

Подробности — в библиотеке TechNet.

Объявление NTP-сервера в качестве надежного

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"AnnounceFlags"=dword:0000000a
• w32tm /config /reliable:yes

Подробности — в библиотеке TechNet.

Включение NTP-сервера

NTP-сервер по умолчанию включен на всех контроллерах домена, однако его можно включить и на рядовых серверах.

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpServer]
"Enabled"=dword:00000001

Задание списка внешних источников для синхронизации

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters]
"NtpServer"="time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8"
• w32tm /config /manualpeerlist:"time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 ru.pool.ntp.org,0x8"

Флаг 0×8 на конце означает, что синхронизация должна происходить в режиме клиента NTP, через предложенные этим сервером интервалы времени. Для того, чтобы задать свой интервал синхронизации, необходимо использовать флаг 0×1. Все остальные флаги описаны в библиотеке TechNet.

Задание интервала синхронизации с внешним источником

Время в секундах между опросами источника синхронизации, по умолчанию 900с = 15мин. Работает только для источников, помеченных флагом 0×1.

• [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient]
"SpecialPollInterval"=dword:00000384

Установка минимальной положительной и отрицательной коррекции

Максимальная положительная и отрицательная коррекция времени (разница между внутренними часами и источником синхронизации) в секундах, при превышении которой синхронизация не происходит. Рекомендую значение 0xFFFFFFFF, при котором коррекция сможет производиться всегда.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config]
"MaxPosPhaseCorrection"=dword:FFFFFFFF
"MaxNegPhaseCorrection"=dword:FFFFFFFF

Все необходимое одной строкой

w32tm.exe /config /manualpeerlist:"time.nist.gov,0x8 ntp1.imvp.ru,0x8 ntp2.imvp.ru,0x8 time.windows.com,0x8 pool.ntp.org,0x8" /syncfromflags:manual /reliable:yes /update

Полезные команды

• Применение внесенных в конфигурацию службы времени изменений
  w32tm /config /update
• Принудительная синхронизация от источника
  w32tm /resync /rediscover
• Отображение состояния синхронизации контроллеров домена в домене
  w32tm /monitor
• Отображение текущих источников синхронизации и их статуса
  w32tm /query /peers

Особенности виртуализированных контроллеров домена

Контроллеры домена, работающие в виртуализированной среде, требуют к себе особенного отношения.

• Средства синхронизации времени виртуальной машины и хостовой ОС должны быть выключены. Во всех адекватных системах виртуализации (Microsoft, vmWare и т. д.) присутствуют компоненты интеграции гостевой ОС с хостовой, которые значительно повышают производительность и управляемость гостевой системой. Среди этих компонентов всегда есть средство синхронизации времени гостевой ОС с хостовой, которое очень полезно для рядовых машин, но противопоказано для контроллеров домена. Потому как в этом случае весьма вероятен цикл, при котором контроллер домена и хостовая ОС будут синхронизировать друг друга. Последствия печальны.
• Для корневого PDC синхронизация с внешним источником должна быть настроена всегда. В виртуальной среде часы не настолько точны как в физической, потому как виртуальная машина работает с виртуальным процессором и прерываниями, для которых характерно как замедление, так и ускорение относительно «обычной» частоты. Если не настроить синхронизацию виртуализированного корневого PDC с внешним источником, время на всех компьютерах предприятия может убегать/отставать на пару часов в сутки. Не трудно представить неприятности, которые может принести такое поведение.

Источники вдохновения

• How to configure an authoritative time server in Windows Server
• A list of the Simple Network Time Protocol (SNTP) time servers that are available on the Internet
• Deployment Considerations for Virtualized Domain Controllers
• Things to consider when you host Active Directory domain controllers in virtual hosting environments

1. зайти в систему от имени пользователя с правами локального администратора
2. запустить командную строку с правами администратора (начиная с Windows Server 2008 по умолчанию включен UAC, поэтому для полных прав в системе все программы нужно запускать правым кликом → запуск от админа)
3. выполнить остановку службы SQL Server
   net stop MSSQLSERVER
4. выполнить запуск службы SQL Server в однопользовательском режиме
   net start MSSQLSERVER /m
5. подключиться к командному процессору управления SQL Server с правами текущего пользователя
   sqlcmd -E
6. добавить объект безопасности Windows (локального или доменного пользователя или группу) в базу данных пользователей SQL Server
   CREATE LOGIN [builtin\администраторы] FROM WINDOWS;
GO;
7. назначить этому пользователю права администратора SQL Server’a
   EXEC sp_addsrvrolemember 'builtin\администраторы', 'sysadmin';
GO;
8. выйти из sqlcmd ;)
   exit
9. запустить службу SQL Server в обычном режиме
   net start MSSQLSERVER
10. теперь можно подключаться с помощью Management Studio к вашему SQL серверу и выполнять необходимые действия

Проблема кроется во включенном по умолчанию UAC, который не предоставляет нужных привилегий для работы установщика (скорее даже установщик не правильно их запрашивает). И решается эта беда путем запуска msp файла из командной строки, запущенной с правами администратора: cmd → запуск от админа → c:\path-to.msp.

Субъективное мнение о пользе Server Core

Жалобы и предложения

На протяжении всего моего знакомства с режимом Server Core у Windows Server 2008 R2 меня не покидают ощущения искусственности этого продукта. Явно прослеживается желание Server Core быть как Linux, но при этом постоянно натыкаешься на несвойственные для Linux неприятности.

Приведу небольшое сравнение особенностей Server Core и Linux.

Однако, раньше было еще хуже, со времени первой редакции Server Core в Windows Server 2008 есть значительное развитие:

• стала доступна роль веб-сервера IIS
• появился PowerShell
• встроен скрипт начального конфигурирования

Хотелось бы видеть развитие Server Core в следующих направлениях:

• Увеличение числа поддерживаемых стандартных ролей. Любые стандартные серверные роли, даже исходя из названия, не требуют для своей работы графического интерфейса. Видимо, для оставшихся за бортом ролей Microsoft пока не успели сделать адекватное удалённое управление.
• Поддержка дополнительных серверных приложений от Microsoft и сторонних разработчиков (их участие, конечно, тоже потребуется). Таким продуктам, как SQL Server, Exchange, Kerio WinRoute и MailServer (да и любым другим, нормальным серверным) для работы серверной части не нужна графическая оболочка, всё равно управление осуществляется из отдельных консолей.
• Включение в стандартную поставку диалоговых скриптов для автоматизированного конфигурирования основных параметров. В Linux-е же есть такие, здорово облегчают рутину. Чем Microsoft хуже?

Сценарии для адекватного применения Server Core

Реальное применение Server Core я вижу, например, в следующем сценарии. Для исполнения заранее ограниченного числа встроенных в Windows Server ролей, поддерживаемых Server Core, необходим выделенный сервер. Предполагается однократное конфигурирование перед запуском в среду. Дальнейшие административные вмешательства, диагностика, применение дополнительного ПО и возникновение каких-либо проблем — не предполагаются.

Предполагаю следующие варианты адекватного применения Server Core:

• Active Directory DC/RODC + DNS + DHCP в удалённом офисе
• File Server + Print Server + BranchCache Hosted Cache
• IIS + Media Services
• Hyper-V — просто идеально!
• Network Policy and Access Services (RRAS, NAP) + WSUS + Exchange — было бы шикарно, но пока не возможно.

При совместном применении указанных сочетаний ролей, аппаратного шифрования BitLocker, грамотной, нацеленной на безопасность настойки и качественного оборудования может получается довольно надежное и безопасное решение возложенных функций и практически «черный ящик» для нежелательных внешних воздействий.

Hyper-V Server 2008 R2

Hyper-V Server 2008 R2 представляет собой Windows Server 2008 R2 в режиме Server Core с одной единственной предустановленной ролью — Hyper-V. По способу управления они идентичны: командная строка, PowerShell, WinRM, MMC, RDP.

Как я писал выше, именно роль Hyper-V является идеальной для использования Windows Server 2008 R2 в режиме Server Core, и счастье, что Microsoft тоже это понимает. Но особая радость состоит в том, что Hyper-V Server 2008 R2 абсолютно бесплатен и практически не ограничен по функциональности в рамках роли Hyper-V.

Поддерживается 1 терабайт памяти, 64 логических процессора, 386 виртуальных машин, современные серверные хранилища информации, непосредственно подключаемое и сетевые. Сохранена совместимость виртуальных машин с «обычным» Hyper-V, поддерживаются снапшоты, отказоустойчивая кластеризация, Live Migration, управление через System Center Virtual Machine Manager, работает PowerShell.

Это несомненный Epic Win со стороны Microsoft и «Кузькина Мать» для vmWare.

Боевой опыт работы с Server Core

Режим Server Core рассчитан на однократную настройку из консоли, а все дальнейшее управление предполагается удаленно по сети, из различных MMC консолей, WinRM и прочих радостей. Полный набор для удаленного управления Windows Server 2008 R2 (не только Server Core) можно установить на Windows 7. Однако, ограниченно работают и наборы удаленного администрирования серверных ОС и для Windows Vista, и для Windows XP.

Первоначальная настройка

С версии R2 появилась так недостающая ранее утилита автоматизированной первоначальной настройки sconfig. Она позволяет:

• задать имя компьютера, включить его в домен
• добавить локального администратора
• настроить сетевые параметры
• активировать PowerShell
• включить удаленное управление через WinRM, MMC, RDP, Server Manager

Из графических средств остались следующие полезные вещи:

• intl.cpl — элемент панели управления для настройки языковых параметров
• timedate.cpl —элемент панели управления для настройки параметров времени
• taskmgr —диспетчер задач
• notepad никуда не делся
• regedit всё тот же
• msinfo32 — вот уж «необходимая» вещь!
• но самое приятное — работает Total Commander (и, возможно, другой незаменимый софт)!

CoreConfig

Энтузиастами была разработана более продвинутая графическая утилита для конфигурирования Server Core — Core Configurator, настоятельно рекомендую опробовать, так как на позволяет выполнить мышкой почти все действия, описанные ниже. Перед запуском CoreConfig необходимо включить PowerShell в SCONFIG, а саму программу можно закинуть на сервер по сети (\\server\c$) сразу после установки и конфигурации сетевых параметров.

Настройка железа

Несмотря на богатый набор встроенных в стандартную поставку Server Core драйверов для сетевых карт, может понадобиться установить эти драйвера вручную. За работу с драйверами устройств в Server Core отвечает утилита pnputil. Например, для установки драйвера для сетевой карты нужно выполнить следующую команду

pnputil -i -a drivername.inf

Удаленное управление

Как уже упоминалось выше, возможности удаленного управления активируются с помощью программы sconfig, советую включить их все. Затем настроите брандмауэр, используя консоль Windows Firewall with Advanced Security в режиме удаленного управления (mmc → добавить консоль Windows Firewall with Advanced Security → указать адрес управляемого сервера в качестве цели). Возможно, перед этим понадобится разрешить в брандмауэре входящие управляющие соединения, сделать это можно с помощью CoreConfig, либо следующей командой:

Меньше всего проблем с управлением свежеустановленным Server Core возникает, если его ввести в домен. По умолчанию в брандмауэре включится профиль Domain, будет работать прозрачная аутентификация в консолях MMC и WinRM. Ну и, конечно, групповые политики будут применены ко всему, что найдут.

Если ли же вы хотите управлять Server Core без использования доменной аутентификации, для использования альтернативных учетных данных при подключении к управляемому компьютеры выполните следующую команду на управляющем компьютере.

Это здорово облегчит подключение по WinRM и сделает возможным в принципе управление по MMC.

Как настроить WinRM на клиенте и подключиться им к вашему серверу, читайте в моей статье «Выполнение консольных команд на удаленных компьютерах по сети».

Для управления Server Core с помощью консоли Server Manager, нужно открыть его на локальной машине, правый клик на корне Server Manager → Connect To… Будут доступны:

• Task Scheduler
• Event Viewer
• Shared Folders
• Services
• Disk Management (если сначала запустить службу Virtual Disk)

Для доступа к следующим управляющим возможностям нужно запустить MMC, выбрать File → Add Snap-in… и указать в качестве цели адрес управляемого компьютера:

• Group Policy Object Editor
• Windows Firewall with Advanced Security

Device Manager

По умолчанию, управление устройствами не доступно, чтобы включить его (да и то только в режим чтения), в консоли Group Policy Object Editor идём в Computer Configuration → Administrative Templates → System → Device Installation и включаем Allow remote access to the PnP interface. Для вступления изменений в силу нужно перезагрузить компьютер. Для этого можно выполнить команду

winrs -r:servername shutdown /r /t 0

…если у вас все в порядке с учетными записями, в противном случае можно воспользоваться ключами -u:user -p:pass.

Конфигурирование сетевых интерфейсов

В стандартной поставке нет графического элемента панели управления ncpl.cpl, который позволяет настраивать параметры сетевых интерфейсов. Имеется текстовое средство netsh, которое помимо всей своей неудобности не позволяет настраивать привязки сетевых протоколов.

Со мной несколько раз происходила неприятная ситуация: при создании внешних виртуальных сетей в менеджере Hyper-V что-то может пойти не так, и ваша сетевая карта оставалась привязана только к протоколу Microsoft Virtual Network Switch Protocol. Но ни основная ОС, ни виртуальные машины к этому сетевому интерфейсу доступа не имели. А при попытке привязать виртуальную сеть к этому сетевому адаптеру выдавалась ошибка:

В графической среде эта проблема решалась отключением привязки протокола Microsoft Virtual Network Switch Protocol от физического сетевого интерфейса, а затем включением на нем традиционных протоколов (IP, IPv6, Клиент для сети Microsoft).

Однако, в Server Core такая задача была не выполнима стандартными средствами, что вводило в бешенство. Даже Microsoft признали эту проблему и, наконец, выпустили утилиту NVSPBind, которая позволяет настраивать привязку протоколов к сетевым интерфейсам в среде Server Core.

Полезные ссылки

• Официальный блог Server Core — самый лучший источник мудрости на начальном этапе
• Server Core Installation Option Getting Started Guide
• Remote Management with Server Manager
• Таблица поддерживаемых ролей Windows Server 2008 R2 в режиме Server Core
• Таблица поддерживаемых ролей Windows Server 2008 R2 в полной версии
• Официальная Страница Hyper-V Server 2008 R2
• FAQ по Hyper-V Server 2008 R2
• Бесплатная загрузка Hyper-V Server 2008 R2
• Средства удаленного администрирования сервера для Windows 7

Я использую 2 средства удаленного выполнения консольных команд: PsExec и WinRM, у каждого из них есть свои преимущества.

PsExec

Одним из отличных решений поставленной в заголовке задачи является использование программы PsExec от великого Марка Руссиновича.

Программа работает по клиент-серверному принципу: на локальной машине выполняется клиент, который посылает команды серверу на удаленном компьютере. Особенностью этой программы является то, что серверная часть устанавливается автоматически непосредственно перед выполнением команды, а затем удаляется. Таким образом для выполнения команд на удаленных машинах достаточно иметь на них административные права.

Если PsExec запускается от имени администратора, который входит в тот же домен, что и удаленны компьютер, то никаких учетных данных даже вводить не нужно. В противном случае, их можно указать в командной строке, либо PsExec сама их запросит. PsExec работает на ОС начиная с Windows 2000 и заканчивая 64-битным Windows Server 2008 R2.

Очень полезными в PsExec являются следующие возможности:

• Выполнение команды на группе компьютеров. Пример: следующая команда позволяет принудительно применить самые свежие групповые политики:
  psexec @group.txt gpupdate /force
• Выполнение команд от имени системной учетной записи. Пример: следующая команда заставит удаленную систему принудительно проверить обновления:
  psexec \\computer -s wuauclt /detectnow
• Копирование выполняемой программы на удаленный компьютер перед выполнением. Пример: следующая команда позволит обновить членство данного компьютера в группе безопасности Active Directory (токен доступа) без перезагрузки:
  psexec \\computer -c -s klist.exe purge

Трудно переоценить пользу этой программы, если использовать скрипты и возможности консольных команд, встроенных в Windows.

Windows Remote Management

Изначально это была серверная технология для удаленного управления оборудованием, которая появилась в Windows Server 2003 R2 как часть компонента Hardware Management, но недавно Microsoft выпустили пакет Windows Management Framework, который включает в себя PowerShell 2.0 и WinRM 2.0 и устанавливается на клиентские ОС как обновление. Подробности можно прочитать в статье KB968929.

Прелесть WinRM заключается в простоте развертывания в доменной среде через WSUS в качестве факультативного обновления ОС и мощи, которую даёт совместное с PowerShell применение.

Использование WinRM происходит через 2 команды.

winrm.cmd служит для конфигурирования настроек и диагностики клиента и сервера WinRM.

Для того, чтобы сервер WinRM начал принимать команды, должна быть запущена служба Windows Remote Management и произведена её начальная конфигурация. Используйте команду

winrm quickconfig на локальной машине, либо финт ушами
psexec -s \\servername winrm quickconfig по сети, используя PsExec от имени системной учетной записи.

Будет предложено автоматически запускать службу WinRM и разрешить уделенные подключения, соглашайтесь ;)

Чтобы успешно подключаться к WinRM серверу (имеется в виду серверная часть, принимающая команды), не входящему в тот же домен, что и ваш клиентский компьютер, необходимо на клиенте этот целевой сервер добавить в «доверенный список» следующей командой:

winrm set winrm/config/client @{TrustedHosts="servername"}, где вместо servername можно указать IP-адрес, либо * (звёздочку).

Для пользователей Windows Vista и Windows 7, работающим не от имени встроенного администратора (обычно так и бывает), нужно выполнить следующую команду

reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

По умолчанию, установлено ограничение на 5 одновременных соединений WinRM от клиента, для увеличения этого числа выполните команду

winrm s winrm/config/winrs @{MaxShellsPerUser="X"}

winrs.exe — клиент для отправки запросов к серверной части. Пример: следующая команда принудительно перезагрузит удаленную систему…

winrs -r:servername shutdown /r /t 0

В доменной среде при отправке команд используются учетные данные запустившего пользователя. Для посыла команд от имени другого пользователя используются ключи -u:user -p:pass. Пример: следующая команда очистит локальный кэш DNS-имён на удаленной системе

winrs -r:servername -u:user -p:pass ipconfig /flushdns

Будут рассмотрены следующие темы:

• Описание возможностей
• Сильные и слабые стороны продукта
• Установка серверных компонентов Forefront Client Security
• Развертывание клиентских компонентов Forefront Client Security
• Советы и хитрости
• Полезные ссылки

Описание возможностей

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

Client Security состоит из клиентской и северной частей.

Клиентская часть называется Forefront Client Security Agent и состоит из трех легких компонент:

• Antimalware Service — антивирусное ядро
• State Assessment Service — средство проверки текущего состояния безопасности
• Microsoft Operations Manager (MOM) 2005 Agent — агент для связи с сервером управления

Агент Client Security заточен на быстрое развертывание и централизованное управление, поэтому для конечного пользователя предоставляет только необходимый минимум функций, таких как

• сканирование по требованию
• расписание автоматического сканирования
• проверка обновлений
• настройка исключений
• отключение сканирующих модулей

Серверная часть называется Forefront Client Security Management Console, представляет собой панель управления, на которой отображается текущее состояние системы, настраиваются политики безопасности и представлены возможности для формирования разнообразных отчетов. Консоль управления для своей работы использует следующие технологии:

• Active Directory для централизованного распространения настроек (политик безопасности)
• Windows Server Update Services (WSUS) для централизованного распространения программных модулей и обновления антивирусных баз
• Microsoft Operations Manager 2005 (подпиленная версия) для сбора данных о состоянии клиентов
• SQL Server 2005 Database Engine для хранения базы данных
• SQL Server 2005 Reporting Services для формирования отчетов

Сильные и слабые стороны

Сильные стороны продукта:

• Высокая эффективность: авторитетные независимые тесты (Virus Bulletin, AV-Comparatives) неоднократно давали максимальный рейтинг этому антивирусу. Продукт сертифицирован для государственного применения.
• Производительность: антивирусный агент, работающий на клиентах, потребляет сравнительно немного памяти и не содержит ненужных в корпоративной среде модулей, такие как «оптимизаторы» ОС, брандмауэры и т. п.
• Широкая совместимость с платформами: агент поддерживает клиентские и серверные ОС начиная с Windows 2000 и заканчивая Windows 7 / Server 2008 R2.
• Централизованное управление и мониторинг: позволяет централизованно контролировать все настройки антивирусов, в соответствии с гранулярно создаваемыми политиками. Информация о состоянии контролируемых систем централизованно собирается и анализируется.
• Интеграция со службами Microsoft: продукт по полной использует технологии Microsoft, которые позволяет сравнительно легко внедрять его в существующую инфраструктуру. Это очень важно для больших сетей.
• Масштабируемость: одиночный сервер управления может поддерживать работу порядка десяти тысяч клиентов, а сами серверы управления можно централизованно объединить с помощью Client Security Enterprise Manager.
• Низкая стоимость: одна лицензия клиента стоит около 13 зелёных в год. Лицензия на сервер управления — около 2,5 тысяч зелёных в год, что сравнительно недорого, в случае больших инсталляций.

Все слабые стороны относятся к серверным компонентам и вытекают из сильных сторон…

• Специфические требования к инфраструктуре: для серверных компонентов поддерживаются только 32-х разрядные операционные системы, причем официально — только Windows Server 2003. Полная установка продукта довольно сложна, требует выполнения многих предварительных условий в текущей информационной инфраструктуре. Все серверные компоненты Forefront Client Security можно установить на одну ОС, однако чем-либо дополнительным эту систему лучше не нагружать.
• Высокие системные требования: в моей инсталляции на 50 клиентов сервер управления начинает нормально работать с 2 гигабайтами памяти и весьма неслабым двухъядерным процессором, занимая 50 гигабайт места на диске.
• Общая громоздкость системы: так как серверная часть продукта состоит из многих компонентов, которые могут быть распределены по разным компьютерам, общая надежность системы понижается из-за возможности отказов отдельных компонентов.
• Требование платной версии SQL Server 2005: продукт не может использовать БД Windows Internal Database, у которой нет ограничения на размер баз данных.

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

Установка серверных компонентов Forefront Client Security

Процедура развертывания системы описана на русском языке в документации на TechNet, однако она довольно громоздка, уныла и местами устарела… Текст далее призван помочь установить и настроить Forefront Client Security без выкуривания официальных мануалов.

Management Console состоит из нескольких ролей, которые можно разносить по разным серверам:

• Management Server — сервер управления
• Collection Server — сервер сбора данных (MOM)
• Collection Database — база данных (SQL Server 2005 Database Engine)
• Reporting Server and Database — сервер отчетов (SQL Server 2005 Reporting Services)
• Distribution Server — сервер распространения (WSUS)

Требования к этим ролям описаны в документации на TechNet. Следует обратить особое внимание на то, что в качестве платформы для всех ролей официально поддерживается только 32-битная Windows Server 2003. На деле же, WSUS прекрасно работает и на Windows Server 2008 64 bit, также на эту платформу можно установить и 64-битную редакцию SQL Server 2005. Также я успешно устанавливал все серверные компоненты Forefront Client Security на Windows Server 2008 32 bit, особых подводных камней, помимо отмеченных далее, не заметил.

В этой записи я рассмотрю процесс установки всех ролей, кроме WSUS, на 32-битный Windows Server 2003. Сервер должен быть членом домена, на нем должны быть установлены следующие стандартные компоненты: IIS, ASP.NET, .Net Framework 2.0 (для Reporting Services и WSUS). Дополнительно необходим Group Policy Management Console (для Management Console), и желательно обновить .Net Framework до последней версии.

Теперь можно перейти к установке SQL Server 2005. Тут меня ждала огромная неприятность и разочарование: необходима платная редакция SQL Server 2005, не ниже Standard. Казалось бы, в бесплатном SQL Server 2005 Express Edition with Advanced Services имеются все компоненты, заявленные в официальных требованиях (конечно кроме ограничения на объем БД, что, в общем-то, можно обойти созданием нескольких баз). Если следовать такой логике, то в процессе установки серверных компонентов Forefront Client Security обнаруживается, что не хватает компонента Integration Services, который входит в поставку SQL Server 2005, начиная с редакции Standard…

Устанавливая SQL Server 2005 Standard необходимо выбрать компоненты Database Engine, Reporting Services и проклятые Integration Services, необходимость которых мне не ясна. Стандартная версия SQL Server 2005 распространяется на дисках и на текущий момент уже устарела, поэтому сразу после её установки необходимо установить SP3. Чтобы избежать перезагрузки системы, на последней странице диалоговых окон установщика SP3 (где предлагается отравлять отчет об установке в Microsoft) нужно остановить службы SQL Server и SQL Server Reporting Server.

Чтобы проверить, корректно ли установились Reporting Services, пробуем зайти IE (с отключенным режимом Enhanced Security) на адрес http://localhost/Reports/. Если ошибок нет, то продолжаем. Если есть, пишите в комментарии. До начала установки Client Security настраиваем службу SQL Server Agent на запуск автоматически и запускаем (проверяется при установке).

В Active Directory создаём пользователя и наделяем его административными правами (группа Domain Admins) на всех компьютерах, на которых будут работать любые компоненты Forefront Client Security.

Наконец, настало время запустить установку серверных компонентов Forefront Client Security. Нас спросят ввести данные для учетной записи DAS, от имени которой будет работать система на всех компьютерах — это именно тот пользователь, которого мы создавали в AD. Обратите внимание на настройки начальных размеров баз данных! Не изменяйте их в меньшую сторону, иначе скоро у вас начнутся проблемы, подтверждено моим горьким опытом. Если предполагается работа с тысячами агентами, обязательно ознакомьтесь со статьями «Размеры баз данных» и «Влияние на системные ресурсы сервера». Если все предыдущие шаги проделаны правильно, дальнейших проблем возникнуть не должно. Установка долгая, что типично для продуктов Microsoft.

По окончании установки предложат пройти Configuration Wizard (также доступно в меню Action → Configure из консоли Forefront Client Security), делаем это обязательно. Затем в консоли Forefront Client Security переходим на вкладку Policy Management и создаем политику.

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

Развертывание клиентских компонентов Forefront Client Security

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

Все клиентские компоненты и описания вирусов распространяются через WSUS. Если в вашей сети такая служба не развернута, то позор вам, быстрее разворачивайте. На компьютере, на котором установлена последняя версия WSUS (на момент написания статьи 3.0 SP2), запускать установку роли Distribution Server не нужно, так как эта роль была рассчитана на работу с WSUS версии 2.0.

Вместо установки роли Distribution Server проделайте следующие шаги в консоли WSUS:

• в Options → Products and Classifications включить Forefront Client Security, на вкладке Classifications должны быть отмечены как минимум Critical Updates, Definition Updates и Updates
• произвести синхронизацию WSUS
• найти поиском последнюю версию обновления «Client Update for Microsoft Forefront Client Security» и сделать Approve for installation для нужных групп компьютеров.
• создать правило Automatic Approvals для продукта Forefront Client Security с классификацией Definition Updates
• настроить автоматическую синхронизацию минимум пару раз в день

Всё, приведенных действий достаточно для того, чтобы групповая политика распространилась на компьютеры, которые затем по указанию этой политики в ближайшем цикле автообновления запросят клиентские компоненты Forefront Client Security у WSUS и установят их. В процессе установки осуществиться регистрация на сервере MOM, затем загрузятся последние обновления определений вирусов.

Советы и хитрости

Ускорение развёртывания Forefront Client Security

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

gpupdate /force для немедленного применения групповой политики
wuauclt /detectnow для немедленной проверки обновлений

О том, как запускать команды по сети на группе компьютеров, я недавно написал.

В зависимости от настроек Windows Update в вашей групповой политике, клиентские компоненты Forefront Client Security могут установиться мгновенно, могут быть запланированы на установку в определенное время, а могут и просто быть предложены пользователю.

После установки обновления агент MOM регистрируется на сервере MOM и какое-то время висит в его очереди на утверждение, бездействуя. Чтобы ускорить этот процесс, клиентов можно утверждать вручную в Administrator Console сервера MOM, в узле Administration → Computers → Pending Actions.

Объём базы данных Forefront Client Security

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

Чтобы избавиться от причин этих ошибок, увеличьте размеры БД, используя средство SQL Server Management Studio. Рекомендуемые размеры даны в статье «Влияние на системные ресурсы сервера».

Исключения для серверов

Если вы установили антивирус на сервера, в основном нагруженные каким-то определенным сервисом (таким как сервер БД, виртуальные машины, IIS, резервное копирование), то советую добавить исполняемые файлы сервера и/или области действия в файловой системе в исключения антивируса, чтобы не тормозило лишний раз. Более подробно рекомендую почитать в статье KB943556. Менее подробно, но более сжато и понятно — в этой записи блога Алексея Максимова.

Обновление

Для серверных компонентов Forefront Client Security выпущен Service Pack 1 и несколько обновлений. Не забудьте в своём WSUS одобрить эти обновления, либо загрузите их через Microsoft Update.

Развертывание Forefront Client Security на компьютеры рабочей группы (вне домена)

Все, что нужно для корректной установки Forefront Client Security на клиентский компьютер — это сформированные групповой политикой записи в реестре. Если нет возможности распространять настройки на компьютеры через групповую политику, то можно в Management Console сделать Deploy политики в файл. Затем скопировать этот файл и программу cslocalpolicytool.exe из дистрибутива FCS на клиентские компьютеры и выполнить команду

fcslocalpolicytool.exe /f /i имя_файла для применения политики.

После этого клиенты сами запросят и установят агент Forefront Client Security через WSUS. Также можно и просто запустить ClientSetup с диска, но зачем? Без правильного получения обновлений от WSUS вам все равно не получится пользоваться этим программным продуктом полноценно.

Установка Forefront Client Security без сервера управления

Такой вариант тоже возможен, если вы захотели установить агент Forefront Client Security на домашнем компьютере. Достаточно запустить

ClientSetup /NOMOM

Установится локальный агент, затем нужно получить обновления агента с Windows Update, после чего загрузятся обновления антивирусных баз.

Но есть и другой путь! Microsoft недавно выпустила бесплатный антивирус Microsoft Security Essentials, который представляет собой тот же агент Forefront Client Security, только лишенный централизованного управления. Для дома — самое то!

Ручная локальная установка обновлений Forefront Client Security

И такое возможно. Следуйте ссылкам в статье KB935934 для соответствующей разрядности ОС. Для локального обновления антивирусных баз агента Forefront Client Security достаточно просто запустить загруженный файл.

Принудительное обновление антивирусных баз Forefront Client Security

Можно форсировать установку обновлений с WSUS помимо стандартного цикла автообновления следующей командой:

"%ProgramFiles%\Microsoft Forefront\Client Security\Client\Antimalware\MpCmdRun.exe" -SignatureUpdate

Полезные ссылки

• Официальная документация
• Русский ТехЦентр
• Английский FAQ
• Блог разработчиков
• Блог поддержки
• Английский форум
• Русский форум линейки продуктов Forefront
• Error message when you open the Operator Console in Microsoft Operations Manager 2005: «Error connecting to server: localhost»
• Issues that you may experience after you install MOM 2005 on a computer that is running Windows Server 2003 with SP1
• Ознакомительная версия (120 дней) Forefront Client Security

Надежные источники сообщают, что новая версия продукта, которая будет называться Forefront Endpoint Protection 2010, запланирована к выпуску во второй половине 2010 года и будет основана на System Center Configuration Manager.

Статья планировалась как сборник советов по избеганию «подводных камней» при установке и развертыванию продукта, но от желания превратить получившиеся в связный текст получился вот такой букварь…

PS: Я часто использую полное название Forefront Client Security не потому, что плохо владею синонимами, а для облегчения поиска роботами. Слава роботам ;)

Начиная с Windows Server 2008 значительно повышена безопасность подключения к службам терминалов за счет использования двух технологий: SSL и NLA.

SSL

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

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

NLA

Network Level Authentication направлена на защиту терминального сервера от атак на отказ в обслуживании. Эта технология запрашивает авторизацию пользователя средствами самого клиента RDP в самом начале подключения. Если авторизация не проходит, сервер не напрягается рисовать окно входа в систему и выполнять прочие связанные с этим действия. Это особенно актуально, если такой терминальный сервер доступен из интернета.

Совместимость с клиентами

Чтобы успешно подключаться к терминальному серверу, на котором активированы обе технологии, необходим терминальный клиент, поддерживающий протокол RDP 6.1. Этот протокол поддерживается клиентами, идущими в комлекте с ОС начиная с Windows Vista. Для Windows XP необходим установленный SP3 (либо обновление KB952155 для SP2) и кое-какая дополнительная настройка, описанная в статье KB951608.

Для включения поддержки CredSSP (через которую работает NLA) в RDP клиенте Windows XP необходимо внести следующие изменения в реестр:

• в параметре
  HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ Lsa\ Security Packages
  добавить строку со значением
  tspkg
• в параметре
  HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ SecurityProviders\ SecurityProviders
  в строку значений дописать
  credssp.dll

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

В недавно вышедшем Windows Server 2008 R2 протокол RDP обновлен до версии 7.0. Полная его поддержка встроена в Windows 7, для Windows Vista и Windows XP необходима установка обновления KB969084.

Старый контент сайта обрабатывается моим собственным движком на PHP, этот движок предельно оптимизирован (по последним измерениям в 30 раз быстрее WordPress) для минимальной нагрузки на сервер и каналы связи, отвечает всем моим желаниям по представлению и организационной структуре контента. Однако, он совершенно не приспособлен для динамического редактирования  контента, не содержит никакой автоматизации по расстановке ссылок, тегов и прочего…