Exchange Management Shell: возможно все!

Powershell как инструмент администрирования Microsoft Exchange Server впервые появился в версии продукта 2007, уже 5 лет назад. С тех пор сфера его применения в Exchange Server становится только шире, а введение Powershell remoting открыло совершенно новые возможности для администраторов.

Сисадмины осваивают этот скриптовый язык, но положение, в котором они находятся, совсем не одинаковое. Кто-то мигрирует свой сервер с 2003 на 2010 и для них Powershell — настоящий вызов. Администраторы 2007 и 2010, как минимум, открывали Exchange Management Shell (EMS) и экспериментировали с ним. Например, в таких рутинных задачах как сбор сведений о конфигурации или изменении свойств почтового ящика. Некоторые после этих попыток сбегают обратно в комфорт Exchange Management Console (EMC).
Те, кто его не используют, или используют недостаточно, лишают себя великолепной возможности исследовать и использовать на практике постоянно пополняющийся мир скриптов, выполняя на своих серверах такие задачи, которые ранее выполнить было просто невозможно.
Не секрет, что Powershell способен существенно улучшить некоторые аспекты управления серверами, заполняя белые пятна, оставленные Microsoft.
Примеров использования Powershell для выполнения крайне важных с точки зрения администрирования задач очень много –
Например, когда я ранее работал в большом американском провайдере серьезной проблемой была высокая RPC Latency на CAS серверах, возникавшая из-за проблем с определенными версиями iOS. Проверка нагрузки CAS серверов путем мониторинга числа активных подключений, определение клиента, используемого при подключении, экспорт нужной информации и компиляция html репортов – все это выполнялось на Powershell и оказывало колоссальную помощь.
Powershell, наверное, не самый простой язык. В Exchange Server 2010 SP1 – более полутысячи командлетов и на их изучение уйдет время. Несмотря на это, преимущества его использования в будущем – совершенно точно окупятся.

В статье я рассмотрю несколько ценных для системного администратора сценариев использования Exchange Management Shell. Подчеркну, что цель статьи – не осветить все (да это и невозможно!), а показать – что Powershell для нас, фанатов Microsoft Exchange Server, действительно все.

1. Создание отчетов и их экспорт

Когда приходится администрировать большую Exchange организацию (или хостинг, например), то часто сталкиваешься с необходимостью создания репортов/отчетов в пригодном для последующего редактирования виде. Иногда они могут требоваться по запросу клиентов, чаще – для внутренних аудиторских целей. Exchange Management Shell обладает способностью создавать высоко детализированные отчеты, что для администраторов – несомненное благо. Командлетов, начинающихся с Get-* более чем достаточно в связке Windows PowerShell и Exchange Management Shell, что предоставляет поистине безграничные возможности кастомизации отчетов. Стандартно экспорт производится либо в .txt, либо в .csv формат – оба крайне удобные для любых последующих манипуляций с данными.
Как правило, для экспорта в текстовый или CSV файл используется командлет Out-File (для CSV – Export-CSV). Скажем, у нас есть задача произвести экспорт в текстовый файл список всех почтовых ящиков организации, использовав для фильтрации отображения результата колонки Name и WhenCreated:

Get-Mailbox | Select-Object Name,WhenCreated | Out-File c:\xfer\report.txt



Надо сказать, что наряду с «правильным» для Powershell командлетом Out-File также действует и олдскульный –

[PS] C:\Windows\system32>Get-Mailbox | Select-Object Name,WhenCreated > c:\xfer\report.txt

2. Массовое создание пользователей из CSV файла

Еще один типичный сценарий администрирования Exchange – массовое создание пользователей из CSV файла.Может использоваться при миграции пользователей из другого окружения, при слияниях компаний или просто большом найме новых сотрудников. Для этого сценария типично использование CSV файлов. Для начала нужно подготовить CSV файл. Если администратор имеет желание облегчить себе задачу по последующему изменению атрибутов пользователей, то логично предусмотреть все заранее. При миграции или переезде пользователей с ActiveDirectory-based окружения, экспортирование нужных AD атрибутов пользователей позволит быстро их создать на новом месте, в новой ActiveDirectory.

Экспортируем через get-user, производим выборку по нужным атрибутам и передаем полученный результат в CSV файл.

Теперь у нас есть полностью готовый к последующему импорту CSV файл. В большинстве случаев хватает такого набора информации в CSV файле:

Lastname,Firstname,Name,UserPrincipalName,Password
Наш файл, готовый к импорту в ActiveDirectory, импортируем туда такой командой, меняя под себя требуемые переменные —

Import-CSV c:\xfer\our_import.csv | ForEach-Object { New-Mailbox -Lastname $_.”LastName” -Name $_."Name" -FirstName $_.”FirstName” -Organization Our Organization -Database DB1 -UserPrincipalName $_.”UserPrincipalName” -Password (ConvertTo-SecureString $_.password -AsPlainText -Force)}

Введя в конструкцию –ResetPasswordOnNextLogon установленный в $true мы заставим пользователей поменять пароль при первом заходе в систему.
Используя указанный метод можно создавать сотни почтовых ящиков за минуты, очень существенно экономя время. Аналогичным образом Powershell позволяет работать и со списками рассылки, и с контактами.

3. Как удалить «плохое» сообщение из всех почтовых ящиков сразу?

Когда-то в своей практике я столкнулся с интересным (и крайне срочным!) запросом пользователя, который требовал удалить из почтовых ящиков всех сотрудников организации (более 200) одно письмо с крайне чувствительной для компании информацией, которое послал на общий список рассылки уволенный ранее сотрудник.
Приведенный ниже командлет позволяет реализовать поиск по ящикам требуемого аккаунта и убрать нежелательное сообщение. В сценарии ниже для примера задана тема письма, почтовый ящик куда мы складываем «плохое» сообщение и целевая папка.

get-mailbox -OrganizationalUnit Needed_OU -ResultSize unlimited | Search-Mailbox -SearchQuery Subject:'Very bad message' -TargetMailbox [e-mail] -TargetFolder Inbox –DeleteContent

4. Проверяем размер почтовых баз

По сравнению с Exchange 2007 в последней версии Exchange сервера эта операция осуществляется существенно удобнее. Обновленный командлет Get-MailboxDatabase позволяет получить практически любую информацию.
Получаем базы с именем, сервером, статусом монтирования и размерами:

Get-MailboxDatabase -Status | select-object Name,Server,DatabaseSize,Mounted

5. Почтовый клиент и почтовые ящики

Exchange 2010 позволяет оперировать клиентским доступом к почтовым ящикам на основе версии клиента Outlook и метода доступа в почтовый ящик.
Существует несколько возможностей ограничить доступ по различным критериям. Например, мы хотим не давать возможность соединения по RPC over HTTPS —

Set-CASMailbox -Identity [e-mail] -MAPIBlockOutlookRpcHttp $true

Такой командлет не даст возможность работы с почтовым ящиком клиенту, настроенному не в режиме кэширования —
Set-CASMailbox -Identity [e-mail] -MAPIBlockOutlookNonCachedMode $true

А таким мы не дадим использовать пользователям версии Outlook старее, чем 2003.

Get-CASMailbox -Resultsize Unlimited | Set-CASMailbox -MAPIBlockOutlookVersions '-5.9.9;7.0.0-10.9.9'

Вот так можно получить красивую информацию по почтовым ящикам с заданного аккаунта и экспортировать ее в Excel:

Get-Mailbox -OrganizationalUnit groza -Resultsize unlimited | Get-MailboxStatistics | Sort-Object TotalItemSize -Descending | Select-Object DisplayName,@{Name="TotalItemSize(KB)";Expression={$_.TotalItemSize.Value.ToKB()}},ItemCount,lastlogontime,lastlogofftime,lastloggedonuseraccount | Export-Csv c:\xfer\groza.csv | foreach {$_.length=($_.length)/1024/1024/1024; $_}



А так информацию о свободном месте на жестких дисках нужного сервера:
Get-WmiObject -Class Win32_Logicaldisk -computername | select deviceid,volumename,freespace

6. Клиентский доступ

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

При трудностях с залогиниванием в почтовый ящик на выручку придет командлет Test-MapiConnectivity, который можно использовать с различными параметрами.

Проверим возможность логина в определенную базу — Test-MAPIConnectivity -Database DB1

Или в определенный почтовый ящик —

Test-MAPIConnectivity –Identity [e-mail]



Или на определенном сервере —

Test-MAPIConnectivity -Server MBX1

Проблемы с RPC соединениями диагностируется с использованием командлета Test-OutlookConnectivity. Главным отличием от предыдущего командлета является необходимость указания пароля тестируемого пользователя.
Поскольку серверная роль CAS в Exchange 2010 предоставляет доступ по большому количеству протоколов, то вполне естественно, что создатели Microsoft Exchange Server 2010 позаботились о том, чтобы недостатка в нужных командлетах не было:

Test-ActiveSyncConnectivity — тестирует ActiveSync протокол;
Test-CalendarConnectivity – тестирование доступности календаря;
Test-EcpConnectivity – валидация виртуальной директории ECP на выбранном CAS сервере
Test-ImapConnectivity – проверка статуса сервиса IMAP и возможности клиентского подключения по данному протоколу
Test-OutlookWebServices – проверка корректности информации, выдаваемой пользователю сервисом AutoDiscover
Test-OwaConnectivity – валидация виртуальной директории OWA на указанном CAS сервере
Test-WebServicesConnectivity – проверка Exchange Web Services, которые используются, например, Outlook for Mac, Mac Mail и еще некоторыми клиентами.
Таковы всего несколько сценариев, в которых может использоваться Exchange Management Shell, реальная работа с ним и работа с Exchange 2010 открывают двери в этот мир гораздо шире. И чем больше системный администратор узнает о нем, тем больше он опирается на него в своей повседневной работе – сложно не оценить потрясающие возможности скриптования и автоматизации операций, которые несет этот язык.