Как известно, объекты AD удаляются не сразу. Вместо них создаются объекты-захоронения (tombstone objects) имеющие лишь незначительную часть аттрибутов первоначального объекта. Помимо этого параметр isDeleted такого объекта равен true. В связи с этим имеется интересный вопрос – как долго такие объекты хранятся? Время хранения определяется свойством tombstoneLifetime объекта CN=Configuration,DC=ForestRootDomainName, CN=Services,CN=Windows NT,CN=Directory Service.

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

Первый контроллер домена в лесу Значение tombstoneLifetime
Windows 2000 60 days
Windows Server 2003 60 days
Windows Server 2003 with Service Pack 1 180 days
Windows Server 2003 R2 60 days
Windows Server 2003 with Service Pack 2 180 days
Windows Server 2008 180 days
Windows Server 2008 R2 180 days

Следует так же помнить, что значение 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

По умолчанию Exchange 2010 язык сообщений NDR (Non Delivery Report) и DSN (Delivery Status Notification) пытается выбрать исходя из языка получаемого сообщения (в ответ на которое генерируются NDR/DSN). Если это сделать не получается, то выбирается язык, указанный в региональных настройках сервера, на котором развёрнута роль Hub Transport, на котором генерируются сообщения DNR/DSN.

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

[PS] C:Windowssystem32>Get-TransportConfig | fl externalds*lang*

ExternalDsnDefaultLanguage          :
ExternalDsnLanguageDetectionEnabled : True

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

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

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

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

Данный пост появился в результате демонстрации, проведённой для меня Александром Станкевичем. О возможности организовать Reverse Proxy-сервер на базе IIS я до этого не знал. В стандартном комплекте IIS этой возможности нет — нужно установить специальный компонент IIS, который называется Application Request Routing.

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

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