Без преувеличения могу сказать, что я в курсе почти всех изменений, которые вносят в свой продукт разработчики Exchange. Но все же время от времени и мне приходится сталкиваться с неожиданными новшествами. Сегодня речь пойдет о составной команде Set-MailboxDatabase и о двух компактных, тонких и, я думаю, важных обновлениях системы Exchange 2013, о которых вам следует знать.

Даже те, кто работает с программным обеспечением долгие годы, не отрицают, что в совершенстве овладеть всеми тонкостями того или иного продукта попросту невозможно — особенно если речь идет о такой сложной системе, как Exchange 2013. И это возвращает меня к мысли о том, чтобы рассказать вам о двух не очень крупных, но, на мой взгляд, интересных модификациях, которые были сделаны в последнее время. Я говорю «в последнее время», потому что у меня нет точных данных относительно даты их реализации, но в наши дни, когда обновления выпускаются весьма часто, это вряд ли имеет такое уж большое значение.

Первая модификация — это новый параметр команды Set-MailboxDatabase. Речь идет о параметре AutoDagExcludeFromMonitoring, его описание следует ниже:

«Параметр AutoDagExcludedFromMonitoring замещает механизм, реализованный в версии Exchange 2010, с целью исключения базы данных почтовых ящиков из сценария Database One Copy Alert, который извещает администратора в случаях, когда имеется лишь одна исправная копия реплицируемой базы данных. Если определенному свойству некоторой базы данных не присвоено значение True и имеется всего лишь одна копия этой базы данных, будут сгенерированы тревожные оповещения».

В сообщении EHLO (blogs.technet.com/b/exchange/archive/2010/05/20/3409984.aspx) описывается сценарий Exchange 2010 Database One Copy, используемый для оповещения о событии 4114, если база данных, являющая «собственностью» группы доступности базы данных Database Availability Group (DAG), не считается избыточной, поскольку существует всего лишь одна ее копия. Сценарий, применявшийся в Exchange 2010, был заменен в версии Exchange 2013 RTM кодом, выполняющимся в службе репликации Microsoft Exchange. Я думаю, что сотрудники сайта TechNet неправы, когда утверждают, что оповещения создаются для «реплицированных» баз данных. Экран 1 с данными, связанными с событием 4113, иллюстрирует ситуацию в базе данных, входящей в группу доступности баз данных, причем эта база данных представлена всего лишь одной копией и пока что не была реплицирована.

 

Сообщение об отсутствии избыточных копий
Экран 1. Сообщение об отсутствии избыточных копий

Существует целый ряд причин, объясняющих, почему в состав группы доступности баз данных может входить база данных, представленная всего лишь одной копией. Возможно, эта база применяется для целей тестирования, или для переноса информации из более старой версии системы обработки электронной почты, или используется приложениями, которым нужно создавать и отправлять сообщения, но не требуется сохранять их копии. Но как бы то ни было, служба репликации выискивает не имеющие второй копии базы данных и при обнаружении таковых генерирует соответствующие сообщения. Эта служба не располагает информацией о том, как именно используется соответствующая база данных. Ей известно лишь, что упомянутая база данных представлена только одной копией, а этого недостаточно, когда речь идет о группе обеспечения доступности баз данных. Используем для иллюстрации команду (результат показан на экране 2):

Set-MailboxDatabase -Identity «VIP» -AutoDagExcludeFromMonitoring $True

 

Странности с ключом AutoDagExcludeFromMonitoring
Экран 2. Странности с ключом AutoDagExcludeFromMonitoring

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

Мне нравится возможность подстраивать описанным образом средства для подготовки отчетов. Точнее, она нравилась мне раньше, до тех пор, пока я не обнаружил, что соответствующая настройка не работает. Я мог присваивать параметру значение $True, но уже через 15 минут параметр вновь получал значение $False, и поток оповещений возобновлялся. Странное дело! Во всяком случае, об этой ошибке известили специалистов Microsoft, и они сейчас изучают вопрос, надеясь устранить проблему в одном из накопительных пакетов обновления. Надеюсь, это произойдет скоро, так как эта функция явно полезна.

Второе обновление недавно стало объектом всеобщего внимания, когда обладатель сертификата MVP Яап Весселиус — один из кандидатов на выступление на конференции Exchange Connections, которая состоится в сентябре 2014 года, - сообщил, что, согласно заявлению, опубликованному на сайте TechNet, параметр MaintenanceSchedule команды Set-MailboxDatabase отменяется.

С одной стороны, это меня не слишком удивило, потому что для организации обслуживания разработчики Exchange 2013 используют модель рабочего цикла. Таким образом, фоновое обслуживание структур базы данных Information Store и содержимого осуществляется все время, а темп его возрастает при низком пользовательском спросе на системные ресурсы и снижается при росте пользовательского спроса. Поэтому нет особого смысла выделять для графика обслуживания отдельное свойство базы данных.

Но даже в версии 2013 CU5 EAC охотно позволяет администраторам устанавливать по собственному усмотрению график обслуживания базы данных (запустите ведение журнала команд для EAC, и вы увидите код, который EAC выполняет для формирования графика). Здесь надо признать, что когда пользователь сохраняет новый график, EAC генерирует предупреждение о том, что данная функция отменена, но тем не менее график сохраняется. То же самое происходит, когда вы определяете новый график, запуская команду Set-MailboxDatabase в консоли EMS. Так что специалисты TechNet неправы, когда утверждают, будто этот параметр больше не работает. Какая-то работа выполняется, хотя она, возможно, и не дает эффекта.

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