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

Итак, нам известно следующее:

  1. Последние версии Exchange Server, Lync Server, SharePoint Server, Office были представлены публике в рамках одной маркетинговой кампании. Вся линейка продуктов была названа в кулуарах (?) Office Wave 15. Судя по Exchange Server 2013, не все команды были готовы к такому шагу. Последний, по крайней мере, был выпущен явно раньше срока и сейчас судорожно допиливается.
  2. Чуть позже было объявлено, что команда Exchange Server 2013 переходит на новую форму выпуска обновлений – ежеквартальные накопительные обновления (Cumulative Updates). Команда Lync Server использует эту схему уже давно, с одним исключением – накопительные обновления для Lync Server не являются самостоятельными дистрибутивами.
  3. На проходившей Lync Conference 2013, упомянутой выше, было объявлено, что, после выпуска четырёх квартальных накопительных обновлений будет выпущена следующая версия Lync Server 2014.

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

Все продукты Office Wave выпускались (и я думаю, что будут выпускаться) одновременно, в рамках одной кампании. Поэтому можно сделать предположение, что Exchange Server и SharePoint (и до кучи, клиентский Office) будут так же обновлены на новую версию примерно через год и получат номер 2014, как указанный в п.3 Lync Server.

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

Так же держим в уме, что Microsoft имеет курочку, несущую золотые яйца – Office365, который по сути, представляет собой полный комплект продуктов Office Wave. Причём разворачивать его не нужно, держать дорогих администраторов, занимающихся поддержкой и развитием сервиса тоже не надо.

Итого, получаем следующее. Знания по линейке Office Wave устаревают за год-полтора. После этого необходимо вкладывать усилия в изучение новой версии. Это удорожает содержание и так недешёвых администраторов, занимающихся поддержкой и развитием существующих систем продуктов Office Wave. Добро пожаловать в Office365.

Just business, nothing personal.

С проблемой озвученной в заголовке столкнулся в процессе поиска решения проблемы с регистрациями рабочих станций во внутренней DNS-зоне домена. При вводе сервера в домен всё проходило штатно. Через некоторое время сервер переставал пинговаться, а его имя разрешаться в ip-адрес. При просмотре DNS имя сервера не находилось, хотя оно там должно было бы быть. Неприятная ситуация.

Теперь немного теории. Начиная с Windows Server 2003 доступны три варианта репликации DNS-зон с Active Directory:

  • “To all DNS servers in the AD forest”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы леса. Сам объект зоны с записями будет располагаться в разделе ForestDnsZones (полное имя – CN=MicrosoftDNS,DC=ForestDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках всего леса.
  • “To all DNS servers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все DNS-серверы домена. Сам объект зоны с записями будет располагаться в разделе DomainDnsZones (полное имя – CN=MicrosoftDNS,DC=DomainDNSZones,DC=domain,DC=com). Репликация зоны будет происходить в рамках домена.
  • “To all domain controllers in the AD domain”. DNS-зона при таком выборе будет реплицироваться на все контроллеры домена в домене. Сам объект зоны с записями будет располагаться в разделе Default Naming Context (полное имя – CN=MicrosoftDNS,CN=System,DC=domain,DC=com). Репликация зоны будет происходить между контроллерами конкретного домена. Этот вариант используется в домене, в котором присутствуют контроллеры домена на базе Windows 2000 Server. Последние не знают о наличии разделов ForestDnsZones/DomainDnsZones, соответственно не могут с ними работать.

Возникает вопрос – а что будет, если некоторая интегрированная с AD DNS-зона будет присутствовать в нескольких разделах приложений? Возможно ли такое вообще? Теоретически возможно:

  • У нас имеется домен на базе Windows 2000 Server (которые не знают о наличии разделов ForestDnsZones/DomainDnsZones). При вводе нового контроллера домена на базе Windows Server 2003 мы можем указать для DNS-зоны тип репликации, который не поддерживается старыми контроллерами домена.
  • При создании зоны вручную, мы можем выбрать любой из первых двух вариантов репликации. Затем, на другом контроллере домене, не дождавшись пока эта DNS-зона отреплицируется, создать её тоже вручную.
  • При вводе нового контроллера домена, автоматически может ставиться роль DNS-сервера. При этом, существующие зоны, находящиеся в разделах ForestDnsZones/DomainDnsZones, будут среплицированы на новый контроллер домена. Ничто не мешает нам, не дождавшись завершения такой репликации, вручную создать эти зоны.

Стоит заметить, что все эти варианты возникают из-за человеческого фактора и они более чем возможны. Таким образом мы можем относительно легко задублировать зоны, что как раз приведёт к эффекту пропадания записей в задублированной зоне. В ADSI Edit выглядеть задублированная зона будет примерно следующим образом:

Capture

Записи, начинающиеся с ..InProgress-[GUID], указывают на зоны, репликация которых не смогла завершиться успешно из-за наличия дубликатов с другим номером USN. Записи, содержащие CNF:[GUID], указывают на зоны, содержащие дупликаты в базе AD.

Что с этим делать? Дупликаты необходимо удалить. Проще всего это сделать через ADSI Edit, удалив записи, которые содержат ..InProgress-[GUID] и CNF:[GUID].

Подсмотрено здесь.

apple-devilВ очередной раз (внезапно!) Apple устроил холокост для своих верных поклонников, которые используют Exchange в качестве корпоративной почтовой системы. В кратце – при обработке запросов на организацию встреч (meeting requests) с устройства Apple с новой прошивкой можно организовать зацикливание. Это может привести к резкому росту логов транзакций, и в случае, если не уследить за дисковым пространством, на котором хранятся логи, то можно легко положить серверы почтовых ящиков.

Рекомендации:

  • Не ставить пока прошивку iOS 6.1
  • Заблокировать устройства, которые уже обновились

Ну а для начала имеет смысл понять кто успел обновиться. Информацию по устройствам, с которых пользователь подключался к почтовому ящику даёт комадлет Get-ActivesyncDeviceStatistics. Имеет смысл отправлять в него только почтовые ящики, к которым уже подключались через мобильные устройства. У них параметр HasActivesyncDevicePartnership имеет значение true. Полный скрипт получается примерно следующий:

$Mbx = Get-CASMailbox -Filter {HasActivesyncDevicePartnership -eq $True}
-ResultSize unlimited;
$Mbx | %{$Name = $_.Name;
$Device = Get-ActiveSyncDeviceStatistics -Mailbox $_.Identity |
?{$_.DeviceUserAgent -like "Apple*1002*"} |
%{Write-Host $Name, $_.DeviceModel, $_.DeviceUserAgent, $_.DeviceId,
$_.FirstSyncTime, $_.LastSuccessSync}}

Исходный скрипт взят отсюда. Спасибо Олегу Крылову и Сергею Мариничеву за внесённые правки.

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