If a user has just changed his or her password using a down-level client, the change was made on the PDC emulator. The PDC emulator will replicate that change to a replication partner in the same site within a 15 seconds. If there is no replication partner in the same site, the password replication will not occur until the next schedule intersite replication.

Вроде бы странное утверждение. Давайте смотреть как у нас происходит распространение изменений. Всего существует три типа распространения изменений объектов AD в зависимости от типа изменения:

• Обычная репликация. Изменения большинства объектов происходит следующим образом: на контроллере домена происходит изменение объекта, контроллер домена ждёт 15 секунд (если он на базе Windows 2000, то 300 секунд), затем пытается уведомлять ближайшего партнёра по репликации в сайте об изменении объекта. Затем с интервалом в 3 секунды ((если он на базе Windows 2000, то 30 секунд)) уведомляются остальные контроллеры домена в сайте. Изменения на другие сайты доходят через сервера-плацдармы в соответствии с расписанием, указанным в настройках межсайтового коннектора.
• Срочная репликация. Происходит при осуществлении изменений следующих типов: блокировка учётной записи в результате превышения числа разрешённых попыток ввода пароля, изменение политик блокировки учётных записей, изменение доменных политик паролей, изменение пароля компьютерного объекта контроллера домена, изменение ключа LSA, смена владельца роли FSMO RID Master. Как следует из названия, репликация таких изменений внутри сайта происходит сразу же после их появления. Между сайтами репликация происходит сразу же только в случае включения уведомления об изменениях между сайтами (по умолчанию выключено на межсайтовом коннекторе). Иначе по расписанию.
• Репликация изменения пароля. При изменении пароля, контроллер домена, на котором произошло изменение, сразу же пересылает его на контроллер домена с FSMO ролью PDC Emulator. Дальнейшее распространение изменения происходит через обычную репликацию. Почему не происходит распространения изменений дальше через срочную репликацию? Дело в том, что при попытке аутентификации с помощью нового пароля на контроллере домена, содержащем старую реплику пароля, он обратится к PDC Emulator’у и тот подтвердит актуальность вводимых пользователем данных. То есть пользователь сможет аутентифицироваться, даже если ближайший контроллер домена не содержит актуальную реплику пароля.

Интересные ссылки:
How the Active Directory Replication Model Works

• Полная поддержка всех последних версий Outlook (напомню, что раньше для Outlook 2010 был доступен только облегченный клиент, который не позволял менять настройки политик хранения).
• Больше не будет разделения на полную и облегчённую версию дистрибутива. Дистрибутив будет один (для каждого языка). А функциональность, доступная для клиента (полный/облегченный), будет регулироваться на уровне политик рабочего стола.
• Плагин теперь работает с сервером исключительно по HTTP/HTTPS.

На этом, пожалуй, всё.

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

Следует так же помнить, что значение tombstoneLifetime наследуется при обновлении операционных систем контроллеров доменов. Это значит, что если лес создавался на базе Windows 2000/2003 (без SP1)/2003 R2, затем контроллеры домена менялись на серверы на базе следующих версий Windows, то срок хранения удалённых объектов будет 60 дней. Если же лес создавался на базе Windows 2003 SP1/2008/2008 R2, то 180 дней, даже после обновления на следующие версии Windows.

Ещё один небольшой штрих. При установке на Windows Server 2003 SP1 версии R2 значение аттрибута менялось на 60 дней, но это поведение считается ошибкой и исправляется установкой SP2, о чём говорится в статье ниже.

Интересные ссылки:
Information about lingering objects in a Windows Server Active Directory forest
New Active Directory features in Windows Server 2003 with Service Pack 1 (SP1)
The default tombstone lifetime (TSL) value remains at 60 days instead of increasing to 180 days in Windows Server 2003 R2
Scenario Overview for Restoring Deleted Active Directory Objects

Например, если письмо получено на немецком языке, а в настройках сервера стоит русский, то NDR/DSN будет сформирован на русском языке (если на сервер не установлен немецкий язык). Проблемы нет, если компания работает на территории одной страны. Однако, если компания работает на территории нескольких стран и имеет разветвлённую почтовую инфраструктуру, то может случиться ситуация, когда немецкий клиент получит сообщение NDR/DSN на русском языке, что может его поставить в тупик. Чтобы это исправить необходимо изменить поведение транспортной подсистемы почтовой организации, которое отвечает за выбор языка для сообщений NDR/DSN. За это отвечают два параметра настроек транспортной подсистемы — ExternalDsnLanguageDetectionEnabled и ExternalDsnDefaultLanguage. По умолчанию они выглядят следующим образом:

[PS] C:\Windows\system32>Get-TransportConfig | fl externalds*lang*

ExternalDsnDefaultLanguage          :
ExternalDsnLanguageDetectionEnabled : True

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

Set-TransportConfig -ExternalDsnDefaultLanguage en-us
-ExternalDsnLanguageDetectionEnabled $false

То есть выключаем автоопределение и включаем в качестве языка для NDR/DSN английский. В Exchange 2007 эти настройки хранятся в параметрах транспортного сервера (доступны через Get/Set-TransportServer).

Буду отвечать на вопросы про кошек и Exchange!

После установки ARR в окне просмотра функций нашего IIS сервера (в оснастке Internet Information Services Manager) появится «URL Rewrite», а в дереве сайтов — пункт «Server Farms»:

На базе модуля «URL Rewrite» и можно построить Reverse Proxy-сервер. Важно помнить, что «URL Rewrite» доступен как на уровне всего сервера, так и на уровне отдельных сайтов и приложений, расположенных в этих сайтах. Поэтому Reverse Proxy на базе IIS сервера можно очень гибко настраивать.

Фермы

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

Затем надо будет указать имя фермы и добавить имена серверов. Из интересного — в дополнительных настройках серверов можно указать какие порты будут слушать HTTP/HTTPS-трафик, а так же вес сервера:

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

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

Правила

По завершении создания фермы можно посмотреть на только что созданное правило. Оно будет находиться на уровне сервера IIS в «URL Rewrite» и называться «ARR_FarmName_loadbalance». Правило пересылает все запросы, приходящие на сервер IIS и подходящие под шаблон «*», на нашу новую ферму и по завершении останавливает выполнение других правил:

Остановимся подробнее на правилах. Правила состоят из четырёх компонентов:

• Match URL — фильтр URL, который выбирает только те запросы для обработки правилом, которые подходят под шаблон, указанный в фильтре
• Conditions - условия, которые определяют дополнительную логику работы правила с теми запросами, которые прошли фильтр URL
• Action — действия, которые выполняются с запросами, которые прошли фильтр URL и удовлетворяют условиям, указанным в Conditions

Запросы, проходящие через наш Reverse Proxy-сервер, содержат URL сервера, к которому обращается клиент. В общем случае он выглядит следующим образом:

http(s)://<host>:<port>/<path>?<querystring>

Match URL работает с <path> из части запроса URL. Части <host>, <port> и <querystring> доступны в Conditions через переменные «HTTP_HOST», «SERVER_PORT» и «QUERY_STRING». Так же в Conditions доступны переменные «SERVER_PORT_SECURE» и «HTTPS» для обработки HTTP-запросов.

Подробнее о компонентах.

Match URL

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

Conditions

Для использования дополнительных условий фильтрации доступны переменные, указанные выше. Можно требовать одновременного выполнения всех условий, либо любого условия из списка (Match All или Match Any). Например, на картинке ниже, мы указали, чтобы в фильтр попадали все запросы, в которых содержится URL с доменным именем «cwapp.domain.com» и доступ осуществлялся по HTTPS:

Помимо стандартных переменных, список которых я указал выше, можно использовать любые переменные, находящиеся в HTTP-запросе, который проходит через Reverese Proxy. Имя такой новой переменной собирается следующим образом:

• Все знаки «-» заменяются на знаки «_»
• Все буквы заменяются на заглавные
• Спереди дописывается приставка «HTTP_»

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

Action

В Action указывается действие, которому подвергается HTTP-запрос, удовлетворяющий Match URL и Conditions. Доступны следующие действия:

• Rewrite - Заменяется URL входящего запроса на тот, который мы укажем. Следует помнить, что в случае использования абсолютного URL-пути запрос будет выполняться по всем правилам, то есть за пределами сервера, реализуя тем самым полноценный Reverse Proxy.
• Redirect - Клиент получает ответ о перенаправлении HTTP-запроса на URL, который мы укажем, клиенту при этом возвращается статус 301, 302, 303 или 307. Указываемый в URL путь может быть абсолютным (http://cwapp.domain.com/default.aspx) или относительным (test/index.htm)
• Route to Server Farm - Доступен только при наличии фермы и только на глобальном уровне (на уровне сайта или приложения не доступен). Запрос перенаправляется на ферму.
• CustomResponse - Клиенту возвращается указанный статус и причина возвращения запроса.
• AbortRequest - Отбрасывается клиентский запрос.
• None - Никаких действий не производится.

Возвращаемся к Reverse Proxy. Предположим, нам необходимо перенаправлять запросы, идущие к «http://cwapp.domain.com», на сервер переднего плана Lync. Для этого укажем по какому IP-адресу будет отвечать наш сайт, отвечающий за Reverse Proxy. В DNS необходимо будет прописать хост «cwapp.domain.com» с IP-адресом, который мы закрепили за Web-сайтом. Затем, на уровне сайта заходим в URL Rewrite и добавляем правило (Add Rule(s)…), указываем тип правила — «Reverse Proxy»:

Затем вводим, на какой сервер перенаправлять запросы:

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

Используя новые знания, можно попробовать настроить более хитрое обратное Proxy’рование запросов, приходящих на наш сайт IIS (и не только на него).

Попробуем настроить перенаправление клиентских запросов к «https://meet.domain.com». Для этого на уровне сервера IIS заходим в «URL Rewrite» и создаём новое правило:

Далее нужно будет указать название для правила, а так же шаблон для запросов, попадающих под его действие (можно использовать подстановку «*»):

В дополнительных условиях указываем имя хоста (meet.domain.com) и использование в запросе HTTPS-протокола:

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

Таким образом, решение на базе сервера IIS и дополнительного компонента «Application Request Routing» вполне может заменить, в некоторых случаях, более тяжёлые решения на базе «Microsoft Threat Management Gateway» или аппаратных балансировщиков нагрузки.

Особая благодарность выражается Александру Станкевичу за помощь в написании данной статьи. Если вас заинтересовала данная тема, можете посмотреть его видео-демонстрацию по установке и настройке «Application Request Routing» в контексте использования для «Lync Mobility».

Obtained a certificate that’s trusted by the Lync Server 2010 server and the Client Access server and is issued by the same authority. The certificate must have the Client Access server namespace as the subject on the Subject line. The namespace may be the name of a particular Client Access server, or it may be a DNS name that’s used for load balancing across multiple Client Access servers.

Вроде бы достаточно чётко указано, что в поле Subject в CN должно быть указано DNS-имя либо сервера клиентского доступа, либо балансировщика нагрузки. Возникает вопрос — а что будет, если в нашем сертификате в CN имён ни сервера клиентского доступа ни балансировщика нет и никогда не было? Что делать?

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

Более того, если запускать логгирование на Lync Server, то появится примерно следующая ошибка:

LogType: connection
Severity: error
Text: The peer is not a configured server on this network interface
Peer-IP: xx.xx.xx.xx:15365
Transport: TLS
Result-Code: 0xc3e93d6a SIPPROXY_E_CONNECTION_UNKNOWN_SERVER
Data: fqdn="domain.com"
$$end_record

Где domain.com — это то, что находится у нас в поле Subject сертификата на сервере клиентского доступа. Фактически ошибка эта говорит о том, что сервер переднего плана не может найти у себя в конфигурации объект для domain.com и поэтому рвёт связь с сервером клиентского доступа. Это и приводит к появлению картинки, которая указана выше.

Чтобы такой объект появился — необходимо его создать через командлет New-CsTrustedApplicationPool:

New-CsTrustedApplicationPool -Identity "domain.com" -Registrar "FE-server"
-Site "siteId" -RequiresReplication $false

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

New-CsTrustedApplication -ApplicationId ExchangeOWA
-TrustedApplicationPoolFqdn "domain.com"  -Port <some available port>

Не забываем обновить топологию.

Небольшой довесок. Пул приложений мы создаём в определённом сайте (его идентификатор указывается при создании пула). Если у нас имеется несколько AD-сайтов, каждый из которых имеет свои CAS-сервера, которые при этом используют один сертификат, то создавать в каждом сайте Lync пула приложений под свои CAS-сервера не нужно (Lync Server это и не даст сделать, так как имя пула не может дублироваться в нескольких сайтах). Все удалённые CAS-сервера будут без особых проблем пользоваться пулом приложений созданным только в одном сайте, хотя в их настройках необходимо будет указывать в качестве InstantMessagingServerName имя ближайшего сервера переднего плана.

Полезные ссылки:
Configure Outlook Web App and Lync Server 2010 Integration
What FQDN to use when Setting Up OWA/Lync Integration?
Troubleshooting Lync-Exchange OWA Integration

Особая благодарность Александру Станкевичу за предоставление полезных ссылок.

• Адресная книга
• Служба автообнаружения
• Группа сервисов, связанных с организацией конференц-связи
• Служба доступа для мобильных клиентов (Mobility Service)
• Служба групп ответа (Response Groups)
• Так же веб-службы отвечают за разворачивание групп рассылок

Внутренние веб-службы помимо этого предоставляют доступ к:

• Панели управления Lync
• Службе, предоставляющей доступ к информации о расположении клиента
• Службе для удалённого подключения с помощью PowerShell

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

Dns-имя для внешних веб-служб задаётся при создании сервера переднего плана в Topology Builder:

Позднее оно может быть исправлено через свойства сервера переднего плана:

Либо через командлет Set-CsWebServer, но делать это надо осторожно, так как предупреждения о неправильных настройках при использовании командлета не будет. В то время как Topology Builder будет предупреждать об ошибках:

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

• В свойствах серверов переднего плана необходимо указывать существующее внешнее dns-имя. Оно должно быть разным для каждого сервера переднего плана/пула серверов переднего плана.
• Это внешнее dns-имя должно существовать в виде a-записи во внешней dns-зоне и указывать на ip-адрес сервера, выполняющего роль обратного прокси-сервера.
• На обратном прокси-сервере под каждый сервер переднего плана/пул серверов переднего плана должно быть отдельное правило типа «внешнее dns-имя веб-службы → внутреннее dns-имя сервера переднего плана»
• Все внешние dns-имена веб-служб должны содержаться в поле SAN сертификата используемого на сервере, выполняющем роль обратного прокси-сервера.

Ссылки по теме:
Request and Configure a Certificate for Your Reverse HTTP Proxy
DNS Requirements for Front End Pools
Set-CsWebServer
Change the Web Services URL

Спасибо Александру Станкевичу за помощь в освещении данной темы.

Import-Module ActiveDirectory

foreach ($User in (Get-ADGroupMember "Group Name")) {Grant-CsConferencingPolicy
-Identity "$($User.distinguishedName)" -PolicyName "Policy Name"}

Архитектура утилиты выглядит следующим образом:

Утилита состоит из следующих компонентов:

• Серверная часть (Central Service)
• Консоль администратора (PST Importer Console)
• Агенты, установленные на компьютеры пользователей (PST Agent)

Процесс сбора происходит в два этапа:

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

Скачать утилиту можно отсюда. Документация доступна здесь.