В этой статье мы продолжим разговор о новых возможностях сервера Exchange 2010, а если конкретнее, то речь пойдет о новой функции автоматического распределения почтовых ящиков по базам данных.
Ранее, при создании почтовых ящиков администратор был обязан указывать базу данных, в которой должен быть размещен ящик, и если вы забывали это сделать, то немедленно получали соответствующую ошибку. Сейчас, если вы являетесь администратором серверов Exchange 2010, то не указав базу данных для создаваемого ящика, ни какой ошибки вы не получите, сервер Exchange 2010 сам решит где лучше его разместить.
Принцип работы автораспределения
Функция автораспределения активируется только тогда, когда вы в явном виде не указаваете целевую базу данных при создании, либо перемещении почтовых ящиков, т.е. упускаете параметр –Database или -TargetDatabase во время использования командлетов New-Mailbox, Enable-Mailbox или New-MoveRequest (операции с использованием графической консоли управления также учитываются, т.к. они оперируют этими же командлетами).
Самое важное, что нужно знать администратору про автораспределение баз данных по почтовым ящикам – это то, что они распределяются рандомно, т.е. абсолютно случайным образом! Да действиетльно, сервер MS Exchange 2010 не учитывает в этом процессе ни загруженность действующих баз данных, ни количество свободного места на диске (хотя, я считаю, что это несколько странное поведение). Единственное на что он обращает внимание – это на то, что база должна быть смонтирована, и должна находится в исправном состоянии, а также сервер почтовых ящиков должен находиться в текущем сайте Active Directory.
Ещё один момент, который должны знать администраторы почтовых серверов заключается в том, что механизм авто распределения реализован на базе новой функции Exchange 2010, которая называется Агенты расширения командлетов (Cmdlet Extension Agent).
Агенты расширения командлетов – это компоненты Microsoft Exchange Server 2010, которые активируются в момент выполнения определенного командлета. Т.е. при выполнении вышеуказанных командлетов автоматически запускается специальный агент, который проверяет параметры запуска используемого командлета, и в случае, если упущен параметр, указывающий целевую базу данных, то агент выполняет определенный сценарий, который и реализует процесс распределения почтовых ящиков по базам данных.
Здесь нужно заметить, что агенты расширения командлетов представляют из себя набор агентов, предназначенных для выполнения различных сценариев обслуживания сервера. В данном случае используется агент под названием Mailbox Resources Management Agent. Если вы не желаете, чтобы сервер Exchange выполнял автоматическое, но при этом случайное распределения почтовых ящиков по базам данных, то вы можете просто отключить данного агента, делается это командой:
Disable-CmdletExtentionAgent "Mailbox Resources Management Agent"
Примечание: В будущих статьях мы подробно поговорим и о других агентах расширения.
Настройка исключений при авто распределении
Авто распределение почтовых ящиков по базам данных в текущем сайте Active Directory это хорошая функция, но ей не хватает гибкости. Действительно, случайное распределение нельзя считать правильным подходом. На сегодняшний день, единственным механизмом управления работой агента Mailbox Resources Management является возможность исключить часть баз данных из его обработки, на совсем или же временно.
Для реализации временного или постоянного исключения базы данных из поля зрения агента Mailbox Resources Management необходимо воспользоваться двумя свойствами самой базы:
- IsExcludedFromProvisioning – навсегда исключает базу данных из автоматического распределения;
- IsSuspendedFromProvisioning – временно исключает базу данных из автоматического распределения.
Включаются либо отключаются эти свойства переводом их значения в True либо False соответственно, командлетом Set-MailboxDatabase:
Set-MailboxDatabase <Your_Mailbox_Database> IsExcludedFromProvisioning $True
Как не трудно догадаться, по умолчанию данные параметры имеют значение False.
Примечание: Исключение базы данных из автоматического распределения не означает, что вы вручную не сможете разместить в ней почтовый ящик.
Exchange 2010 SP1
Как я уже много раз говорил, первый сервис пак для сервера Exchange 2010 принес с собой дополнительно очень много новых функций. Что касается автоматического распределения почтовых ящиков по базам данных, то здесь тоже произошли некоторые изменения.
В SP1 появилась возможность применить механизм управления ролями (RBAC) по отношению к функции автораспределения. Если конкретнее, то можно указать область действия для роли и в эту область действия включить только нужные базы данных.
Области управления базами данных представляют собой дополнительный уровень контроля процедуры автоматического распределения почтовых ящиков, который был добавлен в пакет обновления 1 (SP1) Microsoft Exchange Server 2010. Если база данных почтовых ящиков подключена к сети и работоспособна, находится на локальном сайте Active Directory и не исключена из автоматического распределения почтовых ящиков, Exchange 2010 с пакетом обновления 1 (SP1) проверяет вхождение этой базы данных в область баз данных, назначенную администратору, который запустил данный командлет. Если она входит в эту область баз данных, база данных включается в список баз данных, доступных для данного администратора.
По умолчанию все администраторы в организации Exchange 2010 с пакетом обновления 1 (SP1) могут просматривать все базы данных почтовых ящиков в организации. О том, как ограничить число доступных для просмотра баз данных вы можете подробнее прочитать в библиотеке TechNet`a.
Заключение
На этом все, что я хотел рассказать про автоматическое распределение почтовых ящиков по базам данных. Уверен, что этот функционал будет весьма полезен администраторам средних и больших организаций, в ситуации, когда приходится не просто управлять достаточно большим количеством баз, но и делегировать создание почтовых ящиков пользователей другим своим коллегам.
11 комментариев:
Спасибо за информацию.
Нет ли ссылок на оф. источники?
Конечно есть - http://technet.microsoft.com/en-gb/library/ff477621.aspx
Алексей, не подскажите как мне делешировать ServiceDesk-у создание почтовых ящиков в Exchange 2010 SP1? Все контроллеры под управлением 2008R2 SP1.
Для делегирования прав есть новый механизм под названием RBAC. Если хотите знать о нем больше, то читайте цикл статей - http://www.alexxhost.ru/2010/04/role-based-access-control-rbac-exchange.html (особенно интересно для вас Часть 3)
Если знать больше не хотите, то просто добавьте ServiceDesk в группу Recipient Management (группа находится в OU Microsoft Exchange Security Groups.
Спасибо! А группа Recipient Management не избыточная для ServiceDesk? Точнее это не слишком много прав для ServiceDesk? Я хочу чтобы они только могли создавть ящики и удалять. И возможно редактировать списки рассылки...
>Я хочу чтобы они только могли ...
Тогда вам точно нужно прочитать указанный выше цикл статей ;)
Ещё раз Спасибо! Уже начал ;)
Алексей, а что посоветуете в такой ситуации:
ориентировочное кол-во пользовтелей 3000+. Размеры дисков под БД изначально были 2Тб, сейчас после подводного камня с логами хочется соптимизировать ситуацию - думали на счёт 500Гб - чего по тому что пишут в интернете оказалось много всё равно.
Вроде как оптимально 50-100-макс.200Гб. Конечно всё зависит от оборудования, но даже с EVA когда БД была заняты сама бд - 100Гб, и логов на 1900гб была не обслуживаема.
Если в нашем случае делать БД по 100Гб - то их будет очень много, а как Вы пишете автораспределение рабоает сугубо рендомно (т.е. по сути может постоянно пихать в одну и ту же даже)
как быть?)
Спасибо
"автораспределение рабоает сугубо рендомно" не знаю как насчет сугубо рандомно, но не предсказуемо, это точно.
По поводу логов - если у вас DAG и 3 копии, то можно включать циклическое логирование и не париться по поводу логов.
В противном случае нормально настраивать алерты по не удачно прошедшим бэкапам и вовремя их чинить, чтобы не разрастались логи.
Мне кажется, что под логи выдавать столько столько места - это неоправданное расточительство. ИМХО, у вас запас должен быть на 2, максимум 3 бэкапа, которые теоретически могут обломаться в будущем.
А вообще, пользуйтесь Mailbox requirement калькулятором, он вам сам луны по базу и логи посчитает исходя из рекомендаций МС.
А почему после того как я делаю в ручную local move request, он выдает ошибку completed with warning? проверяю у пользователя почта все как работает так и продолжает работать . Не сташен ли данный факт ?
Отправить комментарий