Exchange 2010: Exchange Management Shell

Exchange Management Shell, EMS — это мощный инструмент с командным интерфейсом, основанный на Windows PowerShell v2, что позволяет вам администрировать любую часть Microsoft Exchange Server 2010. Будь вы администратором, выполняющему повседневные операции управления почтовыми ящиками, или разработчиком, занимающимся автоматизацией управления с помощью разнообразных инструментов — в любом случае, командный интерфейс позволит вам выполнять многие задачи быстрее.

Командная консоль лежит в основе модели администрирования Exchange 2010. И Exchange Management Console (EMC) и web-интерфейс Exchange 2010 используют консоль для исполнения команд. Когда вы просматриваете почтовые ящики, создаете группу рассылки или монтируете базу данных, EMC и web-интерфейс выполняют команду консоли для воспроизведения требуемых действий. В командной консоли можно выполнять все, что и в EMC или web-интерфейсе, и даже больше. Дальше в статье, вы сможете неоднократно убедиться в преимуществах ее многогранности, и узнать новое о консоли.

Несколько базовых концепций

Для начала, давайте рассмотрим несклько основных концепций о командной консоли.

  • Подлежащий в основе EMS PowerShell – Windows PowerShell v2 является мощнейшим и чрезвычайно гибким командным интерфейсом, основанным на Microsoft .NET Framework. Он комбинирует в себе несколько командных консолей, плюс многие новые великолепные возможности. Наряду с Windows PowerShell, Exchange 2010 использует Windows Remote Management (WinRM 2.0.). EMS всегда подключается к серверу Exchange 2010 через виртуальную директорию Internet Information Server (IIS), независимо от того, находитесь ли вы локально на самом сервере, или на другом конце страны. WinRM является соединяющим механизмом, между вашей сессией EMS и сервером Exchange 2010.
  • Командлеты (CMDlet) – это малые составляющие части функциональности Exchange Management Shell. командлеты, с именами “говорящими” о выполняемых действиях, отвечают одноименные встроенные команды из всех консолей, например команда Dir происходит из cmd.exe. командлеты управляют объектами, которые являются коллекциями свойств, представляющих собой различные части Exchange. Среди них объекты серверов, почтовых ящиков, транспортных правил и тому подобное. Каждый экземпляр чего-либо, например почтового ящика, представляет собой объект.
  • Параметры – используются для ввода данных в командлеты, и соотносятся с одним или несколькими свойствами объекта. Параметры могут сообщать какой именно объект создать, или уточнять какие свойства объекта и как должны быть изменены.
  • Идентификатор (-Identity) – это специальный параметр, использующийся в каждом командлете, позволяющем вам запрашивать, изменять или удалять объекты. Он обеспечивает вас уникальным определителем, ссылающимся на конкретный объект в Exchange 2010, который вы собираетесь просмотреть, отредактировать или удалить.

    Параметр -Identity также является позиционным, это означает, что вы можете указывать значение параметра даже не упоминая само название. Так, например, команды
    Get-Mailbox -Identity "JohnE" и Get-Mailbox "JohnE" — являются эквивалентными в Exchange.

  • Склеивание (Pipelining) команд Shell — означает возможность предоставления результатов одного cmdlet другому, для выполнения дальнейших операций. Pipelining можно применять к двум или более командам. Например, одним командлетом можно собрать данные, передать их другому командлету для отфильтровывания результатов в набор, а затем третьему для выполнения действий только к полученному набору.

Role Based Access Control

Контроль доступа на основе ролей, Role Based Access Control (RBAC) — это модель административных разрешений в Exchange 2010. RBAC использует роли управления для определения прав пользователей. Например, пользователю, с ролью RecipientManagement разрешено управлять почтовыми ящиками, контактами, группами рассылки и прочими типами получателей. Роли управления позволяют назначить пользователям права на определенных получателей или сервера Exchange 2010 в организации. Если целевой набор почтовых ящиков относится к пользователям Сиэттла, можно назначить администратора для почтовых ящиков Сиэттла только.

Примечание: Пока что, обсуждается бета Exchange 2010, и некоторые аспекты функционала и композиции ролей могут быть изменены.

В Exchange 2010 есть несколько встроенных административных ролей, которые можно использовать сразу после инсталляции, для назначения прав администраторам и пользователям. Некоторые роли, такие как OrganizationManagement и RecipientManagement позволяют администраторам управлять пользователями организации. Роли, подобные MyOptions или MyDistributionGroups дают возможность пользователям распоряжаться своими почтовыми ящиками или группами рассылки. В зависимости от того, кому и какие роли вы назначаете, они смогут управлять отдельными компонентами вашей почтовой организации.

RBAC и PowerShell

Так почему же RBAC так важен для PowerShell? Как будет освещено далее, при старте PowerShell – происходит подключение к серверу Exchange 2010 и аутентификация подключающегося. Одной из составляющих аутентификации, в Exchange 2010, является проверка RBAC, для выяснения имеющихся ролей. Каждая роль управления имеет список разрешенных для применения командлетов и параметров. Так что, при открытии Exchange Manangement Shell, активируются только командлеты из разрешенного набора.

Диаграмма ниже, показывает EMC и Exchange Management Shell поделючаются к серверу Exchange 2010. RBAC получает запрос на аутентификацию, определяет роли подключающегося, а также коммандлеты и параметры, разрешенные к применению. В последующих запросах, Windows PowerShell и RBAC получают запросы на исполнения командлетов, сверяются с разрешениями и выполняют команды. Обратите внимание, что упоминается именно Remote PowerShell, и это неспроста; позже вы узнаете почему.


Обзор RBAC и Windows PowerShell

Важно понимать, что в зависимости от ролей управляющего, он может видеть только набор командлетов, разрешенный ему Exchange 2010. Например, роль OrganizationManagement позволяет администрировать все аспекты организации Exchange 2010. А значит, обладатель роли OrganizationManagement имеет доступ практически ко всем командлетам и параметрам, имеющимся в Exchange 2010. Для сравнения, роль DiscoveryManagement разрешает пользователю проводить поиск информации в почтовых ящиках. Роль DiscoveryManagement довольно узкоспецифична, а значит имеет всего несколько командлетов и параметров, разрешенных к использованию. Значит тот, кому назначена роль OrganizationManagement — видит значительно больше параметров и командлетов, чем тот, кому назанчена роль DiscoveryManagement.

Примечание: Однако Справка в Exchange Management Shell и Exchange Management Console всегда доступны всем ролям, и показывают все командлеты и параметры, независимо от назначеных прав.

Назначение собственных разрешений на Exchange
Когда вы назначаете роли пользователям, думайте о выполняемых ими задачах, и назначайте роли максимально соответствующие им. Если необходимо, можно назначить более одной роли любому пользователю, если некая комбинация ролей будет соответствовать его рабочим функциям. Если у вас несколько пользователей, выполняющих одинаковые задачи, подумайте о варианте объединения их в универсальную группу, и назначении соответствующей роли группе. В таком случае вам понадобиться всего лишь добавить или вывести пользователя из группы, чтобы изменить его права.

Однако, несмотря на то, что Exchange 2010 содержит множество встроенных ролей, они могу не совсем точно подходить к задачам ваших сотрудников. В таком случае, вы можете создать собственные особые роли. RBAC позволяет вам скопировать встроенную роль в новую и добавить или удалить командлеты и параметры, для того чтобы новая роль идеально соответствовала бизнес-функциям сотрудников. Например, если необходимо сотрудникам службы технической поддержки разрешить создавать новые почтовые ящики, но при этом исключить возможность выбора базы данных для создания — можно создать новую роль без параметра -Database в New-Mailbox или Enable-Mailbox.

Более подробно RBAC будет рассмотрен отдельной статьей.

Запуск Exchange Management Shell

Как и ранее, Exchange Management Shell является надстройкой Windows PowerShell. При открытии ярлыка Exchange Management Shell, запускается Windows PowerShell и отрабатывает скрипт конфигурации. Скрипт находит наиболее подходящий сервер Exchange 2010 и подключается к нему. Во время процесса подключения, Exchange проверяет разрешения, и если соединение разрешено, Exchange проверяет роли управление RBAC, назначенные вам. После чего создает среду, содержащую только разрешенные вам командлеты, и организует ее для работы.

Почему это может быть важно для вас? Если вы попытаетесь запустить Windows PowerShell без расширения Exchange Management Shell, и выполнить командлет Exchange, например Get-Mailbox — вы получите ошибку. Потому, что командлет Get-Mailbox не входит в основной набор команд Windows PowerShell. Get-Mailbox должен быть активирован Exchange Management Shell, после того, как вы подключитесь к Exchange 2010 и будете аутентифицированы.

Так что, одним из самых простых способов открытия Exchange Management Shell, является использование ярлыка, который, я лично, для удобства, всегда первым делом выношу на рабочий стол.

Примечание:
Среди консолей в меню Start > All Programs > Microsoft Exchange Server 2010 вы можете видеть Exchange Management Shell (Local PowerShell). Локальная версия Exchange Management Shell тоже основывается на Windows PowerShell и поддерживает все командлеты Exchange 2010. Однако она не содержит возможностей удаленной работы Windows PowerShell, и использует ограниченную версию RBAC.

Использование Exchange Management Shell (Local PowerShell) имеет смысл только на Edge Transport серверах. Для запуска Exchange Management Shell на любых других ролях, настоятельно рекомендуется использовать Exchange Management Shell (Remote PowerShell), кроме тех случает когда проблема требует или позволяет решить ее только локально.

Локальная версия Exchange Management Shell будет совсем удалена из будущих выпусков Exchange 2010, для всех ролей, за исключением Edge Transport.

Снимок ниже демонстрирует подключение Exchange Management Shell к серверу Exchange 2010 и импорт командлетов, к которым пользователь имеет разрешения.

Открывается Windows PowerShell, производится подключение к серверу Exchange 2010, загружаются все командлеты и параметры, к которым пользователь имеет доступ, на основании назначенных ролей RBAC. После подключения можно использовать все командлеты в обычном режиме. Командлет Get-Command пригодится, чтобы получить список доступных команд.

Конец части I. Продолжение здесь.

6 thoughts on “Exchange 2010: Exchange Management Shell”

  1. Спасибо за интересные и полезные статьи! Буду ждать продолжения.

  2. Pingback: progg.ru
  3. 2MaxMVP Если не тяжело, осветите пару моментов в Е2010:
    1. Мне врали что появилась возможность custom managed folder жестко пристегивать к mailbox database, т.е. вся папка юзера лежит в MBDB1, а одна из его папок – например old_messages – на MBDB2, которую можно например разместить на медленном девайсе. Так ли это, и если не так, то как?
    2. Очень интерестна возможность e-mail archiving. Читал англицкий блог, так там немножко обо***ли. Т.е. хотелось бы подробно узнать с практической стороны что можно с этим делать.

    1. 1. Это вряд ли. Напишу об этом подробней, отдельным постом.
      2. Personal Archive: это дополнительный почтовый ящик, ассоциированный с основным ящиком пользователя. Размещается рядом с основным пользовательским ящиком в Outlook. В таком случае, пользователь получает доступ к сообщениям в архиве, точно также как в основном ящике. Можно перетаскивать PST файлы в личный архив для постоянного онлайн доступа и возможностей поиска сообщений. Объекты из основного почтового ящика могут автоматически переноситься в личные архивы, с помощью Retention Polices. Проще говоря, Email Archiving это некоторая смесь из классической архивации Outlook и правил MRM, правда видоизмененная.

  4. 2. Я так понял что в веб-интерфейсе архив видно как доп. папку, но эта дополнительная папка хранится обязательно в той же mailbox database, что и остальные? Может можно попросить разработчиков чтобы они втихаря добавили возможность хранить архив в любой другой mailbox database? Это бы сразу выбросило e-mail archiver’ы с рынка.

Leave a Reply

Your email address will not be published.