Идея написания статьи из серии «что нового» на любую тему, связанную с Microsoft Exchange Server 2010, может показаться немного странной, учитывая, что продукт существует уже почти два года. Действительно, многие аспекты Exchange 2010 были освещены очень подробно. Тем не менее изменения в командной консоли Exchange (EMS) не были описаны в деталях. Эти изменения важны, поскольку консоль EMS лежит в основе процессов управления и взаимодействует с механизмами Exchange на каждом уровне. Все графические интерфейсы, используемые в системе Exchange, построены на основе консоли EMS, и работоспособность всех функций, доступных из консоли управления Exchange (EMC), из командной строки или из панели управления Exchange (ECP), в конечном счете зависит от корректной работы механизмов EMS. При написании данной статьи я предполагал, что читатели немного знакомы с консолью EMS по работе, либо с системой Exchange 2010, либо с Exchange 2007. В статье рассматриваются новые возможности системы Exchange 2010, так что, если вы никогда не сталкивались с оболочкой PowerShell, для вас может быть полезно ознакомиться с материалами сайта windowsitpro.ru.

Архитектура PowerShell

Первый взгляд на символьный интерфейс PowerShell вряд ли позволит понять, что перед нами на самом деле очень сложный продукт инженерной мысли. Его разработчики хотели заменить традиционный интерфейс командной строки (CLI) Windows чем-то более удобным: тем, что сочетало бы в себе эффективность предыдущих реализаций CLI, таких как DEC VMS — великолепный инструмент формирования оболочек UNIX, — с возможностью управления объектами, описывающими элементы системы. Такую возможность простое отображение текста на экране предоставить не может.

Чтобы решить эту задачу, команда разработчиков PowerShell построила интерпретатор языка, среду выполнения и набор интерфейсов, которые позволяют командам PowerShell вызывать встроенные службы Windows. Помимо этого, был разработан широкий набор команд специально для системы Exchange, позволяющих напрямую взаимодействовать с модулями Exchange и управлять ими. На рисунке изображена многоуровневая архитектура консоли.

 

Архитектура EMS
Рисунок. Архитектура EMS

В системе Exchange Server 2007 команды консоли EMS выполняются локально. В Exchange 2010 они выполняются удаленно по сети. Это стало возможным благодаря новому компоненту, известному как Windows Remote Management (WinRM). WinRM представляет собой реализацию протокола управления сетями связи от Microsoft, известного как Web Services for Management (WS-MAN). Для получения информации о других сопутствующих стандартах зайдите на сайт Distributed Management Task Force по адресу www.dmtf.org/standarts. Компания Microsoft реализовала поддержку WinRM в Windows Vista, Windows Server 2008 и более поздних операционных системах, а также добавила среду выполнения, доступную для загрузки из других версий Windows. Если вы имели дело с инструментарием управления Windows (WMI), то концепция WinRM покажется вам знакомой: она разработана с целью предоставления сетевого слоя управления, который могут использовать собственные средства управления Microsoft для запроса и изменения различных параметров системы по сети. Разница в следующем: из-за того что протокол WinRM основан на WS-MAN, а не на собственных запатентованных стандартах Microsoft, он предлагает более высокую степень совместимости. Оболочка PowerShell использует WinRM для удаленной отправки команд на другие серверы Exchange в сети. Существующая реализация консоли EMS в Exchange 2010 отправляет команды от локального интерпретатора PowerShell через WinRM, даже когда они выполняются на локальной машине.

При открытии окна консоли EMS вы фактически создаете пространство выполнения PowerShell, в которое загружается набор команд консоли EMS. Локальное пространство выполнения является основой окна консоли EMS, которое вы видите на экране. На сервере Exchange Server, с которым вы взаимодействуете, также есть соответствующее пространство выполнения. Даже если вы используете консоль EMS на самом сервере Exchange, вы все равно будете задействовать два пространства выполнения. Объект, который связывает два пространства выполнения, называется сессией. Если вы имеете представление о сессиях Telnet или Secure Shell (SSH), вы знаете, что такое сеанс PowerShell, но есть отличительная черта: сессии Telnet и SSH передают в обоих направлениях простой текст; сессия PowerShell передает туда и обратно двоичные блоки данных, которые представляют собой системные объекты. Сессия PowerShell фактически передается по сети с помощью механизмов IIS.

Такая реализация обеспечивает множество преимуществ. Например, она делает процесс отправки команд на удаленные машины прозрачным. Данная реализация использует технологию IIS, а это означает, что проверка подлинности и авторизация IIS могут применяться для разграничения прав пользователей, что в свою очередь позволяет задействовать управление доступом на основе ролей (RBAC) — еще одну ключевую функцию Exchange 2010.

Управление доступом на основе ролей

Запускать команды Exchange из консоли EMS вы можете благодаря тому, что при запуске интерпретатора PowerShell автоматически загружается набор команд Exchange. В системе Exchange 2007 загружались все команды Exchange, а это означает, что любой администратор мог выполнить любую команду. Управление доступом на основе ролей предоставляет более точную систему контроля. Вы можете назначать права доступа для отдельных лиц или групп, чтобы они могли выполнять только указанные команды. Фактически можно контролировать, какие параметры этих команд они могут использовать. Например, вы можете позволить группе инженеров службы поддержки использовать команду Set-Mailbox, предоставив доступ лишь к определенному набору параметров.

Это возможно, поскольку заданные разрешения RBAC позволяют следить за тем, какие команды консоли EMS будут загружены. Если пользователь не имеет разрешения для загрузки конкретной команды, он не сможет выполнить ее. Следовательно, пользователь не может задействовать функции консоли EMC или панели ECP, которые зависят от этой команды. И консоль EMC, и панель ECP поддерживают применение RBAC, поэтому они автоматически скрывают функции пользовательского интерфейса, которые пользователь не может выполнить.

Необходимо иметь представление о том, как работают разрешения RBAC, роли, назначения ролей и области, ведь если любой из этих параметров запрещает пользователю доступ к конкретной команде, пользователь не сможет ее запустить. Дополнительные сведения о RBAC можно найти в статье «Управление доступом на основе ролей в Exchange Server 2010», опубликованной в Windows IT Pro/RE № 9 за 2011 год.

Новые функции консоли EMS 2010

В дополнение к измененной архитектуре оболочка консоли EMS 2010 предоставляет ряд новых функций по сравнению с версией Exchange 2007. Некоторые из этих функций включены в пакет SP1, но я буду рассматривать как встроенные возможности, так и функции, входящие в состав SP1.

Новые команды для импорта и экспорта содержимого почтового ящика и файлов PST. В системе Exchange 2007 можно было выполнять некоторые ограниченные действия с содержимым почтового ящика, но для этого требовалась 64-разрядная версия клиента Microsoft Outlook, установленная на сервере. В Exchange 2010 SP1 включены семейства команд *-MailboxExportRequest и *-MailboxImportRequest. Данные команды позволяют создавать запросы на импорт или экспорт почтового ящика — эти запросы аналогичны запросам на перемещение почтового ящика, с которыми вы, возможно, уже знакомы.

При создании запроса на экспорт или импорт содержимого служба репликации почтовых ящиков (MRS) позаботится о планировании и обработке запроса. Для экспорта содержимого используется команда New-MailboxExportRequest, позволяющая указать, из каких почтовых ящиков необходимо экспортировать содержимое, какие элементы должны быть экспортированы, а также задать направление вывода результатов. Соответственно команда New-MailboxImportRequest позволяет управлять механизмом передачи файлов PST в почтовые ящики и механизмом их хранения. Имейте в виду, что вы должны указать местоположение файлов PST, которые необходимо импортировать. В системе Exchange на сегодня отсутствует механизм поиска файлов PST в сети.

Существуют также команды, используемые для получения статуса запросов импорта или экспорта. Инструмент PST Capture компании Microsoft (blogs.technet.com/b/exchange/archive/2011/07/05/coming-soon-pst-capture-tool.aspx) применяет эти команды в своих операциях, и вы можете объединить их с функцией поиска по множеству почтовых ящиков, встроенной в систему Exchange 2010, чтобы найти и заархивировать сообщения, которые вас интересуют.

Ведение журнала административного аудита. Обычным запросом (или, скорее, криком души) администратора является выяснение, кто изменил что-либо или в какой момент что-то было изменено. Система Exchange 2010 включает функцию ведения журнала административного аудита, которая выполняет именно такие запросы. Когда эта функция включена, каждая команда в списке аудита проверяется, и результаты сохраняются в скрытом арбитражном почтовом ящике, который вы можете просмотреть при помощи команд Search-AdminAuditLog и New-AdminAuditLogSearch; таким образом, вы можете увидеть, кто запускал команду, когда, где и к каким результатам это привело. Интересно, что добавить в список аудита можно только те команды, которые что-то изменяют (например, из семейства Set-*), — вы можете увидеть, кто изменил параметры, но не сможете узнать, кто просматривал их с помощью команды Get-*. Для получения дополнительной информации о том, как работает журнал аудита и как его использовать, просмотрите статью Microsoft TechNet «Overview of Administrator Audit Logging» по адресу technet.microsoft.com/en-us/library/dd335052.aspx.

Набор команд семейства *-Mailbox-FolderPermissions для управления разрешениями на почтовые ящики и папки почтового ящика. Эти команды обеспечивают довольно простой способ выполнения таких операций, как предоставление разрешений на просмотр календаря каждому пользователю или поиск всех пользователей, обладающих теми или иными правами доступа. В качестве наглядного примера того, как можно написать полезный сценарий с помощью этих команд, просмотрите сценарий Яна Эгиля Ринга Set-CalendarPermissions на сайте gallery.technet.microsoft.com/ScriptCenter/19b98a56-42aa-4695-b07c-335d8322b64e.

Команда Send-MailMessage. Эта команда делает именно то, что заявлено в названии. Вы можете использовать ее, чтобы «заспамить» друзей, но особенно полезна она в качестве средства для отправки статуса или предупреждающих сообщений по электронной почте при автоматическом уведомлении пользователей, чьи пароли скоро закончат действовать, при отправке приветственного сообщения по электронной почте новым пользователям, а также во многих других случаях.

Журнал команд в консоли EMC. С технической точки зрения этот механизм, возможно, и не является функцией консоли EMS, но он очень полезен. Консоль EMC 2010 может вести и отображать журнал всех команд, которые были запущены во время сеанса консоли EMS. Это отличный способ отслеживания действий в процессе решения проблемы, который может стать хорошим подспорьем в автоматизации выполнения часто используемого набора команд. Журнал аудита записывает только команды, которые вносят изменения, в то время как журнал команд сохраняет все действия, выполненные во время сеанса. Чтобы включить журнал, используйте пункт View в панели действий консоли EMS, а затем в окне View выберите параметр Windows PowerShell Command Log. После появления журнала выберите в меню Action пункт Start Command Logging. Все команды, которые были запущены, будут отображаться в окне журнала. Журнал сохраняется только до выхода из консоли EMC, но при этом его можно экспортировать в файл, если вы хотите сохранить содержимое.

Другие функции. В дополнение к другим возможностям были добавлены новые команды для работы с функциями, появившимися в Exchange 2010, в том числе команды для управления федеративным доверием, группами доступности баз данных (DAG), политиками почтовых ящиков Outlook Web App (OWA), списками «разрешить/запретить/карантин» службы Exchange ActiveSync и другими нововведениями системы Exchange 2010. Одно из достоинств PowerShell заключается в том, что если вы имеете представление об имени объекта, то, скорее всего, сможете догадаться, какие команды работают с ним. Например, если вы знаете, что существует такая вещь, как политика почтовых ящиков OWA, вам не потребуется особого воображения, чтобы понять, как создать ее с помощью команды New-OwaMailboxPolicy или удалить с помощью команды Remove-OwaMailboxPolicy.

Office 365

Еще одной «изюминкой» Exchange 2010 PowerShell, с которой многие администраторы пока не сталкивались, является возможность прямого подключения к службе Microsoft Office 365. Если задуматься, эта возможность очевидным образом проистекает из того факта, что системы Office 365 и Exchange 2010 используют одни и те же биты PowerShell. Тем не менее способность управлять гибридной организацией Exchange как единым целым с использованием PowerShell не только очень полезна, но и приятна в техническом отношении.

Все, что вам нужно сделать для решения этой задачи, это создать сеанс PowerShell, который указывает на конкретный адрес URL в службе Office 365. Благодаря тому что консоль EMS использует протокол WinRM, который в свою очередь встраивается в службу Microsoft IIS, вы можете легко установить соединение с помощью нескольких строчек кода, например таких:

$creds = Get-Credential
$s = New-PSSession
   -ConfigurationName Microsoft.Exchange
   -ConnectionUri
      https://ps.outlook.com/powershell
   -Credential $creds
   -Authentication Basic
      -AllowRedirection
$importresults = Import-PSSession $s

Этот код выглядит сложнее, чем есть на самом деле. Первая строка получает учетные данные с правами администратора и надежно хранит их в объекте учетных данных PowerShell. Вторая строка (которая разделена здесь на несколько строк, чтобы ее можно было уместить в ширину колонки) устанавливает новый сеанс PowerShell, который подключается к удаленной конечной точке. Третья строка присоединяет сеанс Office 365 к локальному сеансу PowerShell — она связывает ваш локальный сеанс с удаленным пространством выполнения. Далее вы можете вводить нужные команды, которые будут отправлены на удаленные серверы Office 365, на которых находятся ваши почтовые ящики. Конечно, вы не сможете выполнять все операции, доступные на локальных серверах Exchange: компания Microsoft применила механизм разрешения доступа на основе ролей для настройки ограничений полномочий администраторов и клиентов. Если я не ошибаюсь, руководство с подробным описанием того, какие именно команды для каких ролей включены, так и не увидело свет, поэтому для выяснения может потребоваться несколько экспериментов. Тем не менее вы, вероятно, обнаружите, что большинство команд, к которым у вас есть доступ, относятся к управлению получателями и настройке параметров конфигурации почтовых ящиков. Не стоит ждать, что вам будет предоставлен доступ к командам, контролирующим почтовые серверы, серверы клиентского доступа и другие объекты окружения, принадлежащие поставщику услуг.

Недостаток консоли EMS 2010

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

Простейшим способом решения этой проблемы является сокращение количества этапов конвейера. Вместо передачи вывода одной команды по конвейеру непосредственно другой команде используйте промежуточную переменную для их разделения. Например, вместо передачи результата команды Get-Mailbox непосредственно объекту foreach или объекту where вы можете получить выходные данные команды Get-Mailbox, сохранить их, а затем передать следующим образом:

$mailboxes = Get-Mailbox
$mailboxes | foreach {doSomething}

В этом случае мы сначала собираем все почтовые ящики в один объект, затем распаковываем его и передаем через команду foreach, выполняя действие doSomething над каждым объектом. Такой подход предполагает больший размер кода, но устраняет дополнительный этап конвейера, который вызывает ошибку при совместном доступе.

Движение вперед

Если вы знакомы с консолью EMS в системе Exchange 2007, то вы уже знаете около 90% того, что вам потребуется для эффективного управления системой Exchange 2010. К моменту изучения новых функций Exchange 2010 вы будете уже достаточно компетентны для того, чтобы управлять ими с помощью консоли EMS 2010. Если вы перешли непосредственно на систему Exchange 2010 с более старой версии, то обнаружите, что большая часть материалов, посвященных консоли EMS 2007, все еще полезна для первого знакомства с новой версией. Изучение использования PowerShell — это ключевой аспект, необходимый для эффективной работы с Exchange 2010, и данная тенденция продолжится в будущих продуктах Microsoft, так как вспомогательные решения перенимают практику использования оболочки PowerShell для управления и контроля.

Поль Робишо (getting-started@robichaux.net) — старший системный архитектор компании EntireNet, имеет сертификаты MCSE и MCT