Главная Exchange/UC, Без рубрики, Новое Удаленное управление Exchange 2010 может быть комфортным и продуктивным
  • Удаленное управление Exchange 2010 может быть комфортным и продуктивным

    Картинка 24 из 7665Очевидно, что любая заранее сконфигурированная компьютерная система, в последствие требует не только постоянного контроля, но и возможности легкого доступа к функциям управления. Если процесс внедрения может происходить непосредственно с консоли сервера, то вопросы администрирования крайне неудобно решать таким образом. Я думаю, что читатель со мной согласится, если я скажу, что в подавляющем большинстве организаций сервера находятся совсем не там, где сидят их администраторы, т.е. нельзя просто развернуть стул и получить прямой доступ к консоли сервера. А раз так, то абсолютно обосновано требование технического персонала, иметь инструменты, позволяющие выполнять свои задачи «не вставая с рабочего места». Здесь кто-то может сказать, что для этого уже существует удаленный рабочий стол Windows и нечего тут «изобретать велосипед».

    В какой степени это верно, но использование RDP не всегда удобно и в некоторых случаях не приемлемо. Неудобно потому, что если, у вас достаточно много серверов, то подключаться к каждому из них несколько утомительно, гораздо проще открыть локальную консоль PowerShell и уже иметь подключение ко всем из них, либо запустить локально установленную Exchange Management Console и работать со всеми серверами одновременно, но уже через графический интерфейс. А не приемлемо, потому, что часто бывают ситуации, когда сотруднику необходимо делегировать одно-два строго определенных действия, следовательно, пускать его в терминальный сеанс сервера не совсем правильно с точки зрения безопасности, гораздо лучше, если у него будет только доверенный набор кнопок в EMC и только разрешенные командлеты в EMS.

    Что касается стандартных служб Windows Server, то Microsoft дает нам набор утилит удаленного администрирования RSAT (Remote Server Administration Tools), которые мы всегда можем скачать, установить на рабочую станцию и использовать оснастки служб Windows так, как будто мы находимся непосредственно на сервере. RSAT – это хорошо, но в этом случае мы получаем доступ только к службам самого сервера, а как быть с ПО, установленном на нем, например с сервером Exchange 2010? Здесь разработчики Microsoft тоже не оставили системных администраторов без поддержки и дали им возможность полноценного удаленного управления, как через стандартную графическую оболочку Exchange Management Console (EMC), так и через командную консоль Exchange Management Shell (EMS).

    Удаленное подключение

    Для того чтобы управлять сервером удаленно, логично, что к нему необходимо как-то подключиться. Так вот, в случае с Exchange Server 2010, любые удаленные подключения происходят через виртуальный каталог IIS (Internet Information Services), который носит название PowerShell (рис.1).

    img1

    Рис.1: Виртуальный каталог PowerShell в диспетчере IIS.

    При этом подключение осуществляется по протоколу HTTP, а при аутентификации по умолчанию используется Kerberos, само же взаимодействие происходит при помощи WinRM и новой функции Remote PowerShell. Раз речь зашла о Remote PowerShell, то на клиенте должен быть установлен Windows Management Framework, в который входят Windows PowerShell 2.0 и WinRM. Подробнее о Windows Management Framework можно почитать в библиотеке TechNet (http://technet.microsoft.com/ru-ru/library/dd335147.aspx).

    Так как клиенты подключаются к виртуальному каталогу по протоколу HTTP на 80-й порт, то это дает нам возможность с легкостью опубликовать данный веб-сервер в сеть Интернет и работать удаленно уже в прямом смысле этого слова, из любой точки, где есть выход в сеть Интернет. Публикацию каталога PowerShell можно осуществить любыми доступными средствами, например, при помощи корпоративного шлюза на базе TMG или ISA сервера, при этом можно настроить HTTPS-переадресацию для HTTP-соединения и в результате получить защищенный шифрованный канал между клиентом и шлюзом, что усилит безопасность работы.

    Нужно заметить, что подключаться удаленно к Exchange 2010 по протоколу HTTP могут клиенты только с доменных компьютеров, если вы хотите работать с компьютера, который не входит в домен организации Exchange, то вам для подключения в любом случае придется использовать HTTPS-соединение.

    Подготовка пользователя

    Прежде чем давать пользователю возможность удаленного доступа к организации Exchange, нужно определиться со списком прав, которые вы хотите ему делегировать.

    Для управления правами пользователей, в Exchange 2010 введена новая модель управления доступом – Role Based Access Control (RBAC), которая пришла на смену спискам контроля доступа (ACL). Основное отличие в данном случае состоит в том, что разрешения ассоциируются не с объектами AD, такими как серверы и почтовые ящики, а с задачами, при этом в RBAC пользователю присваивается объединение всех ролей и прав, которые для него назначены.

    В процессе аутентификации сервер Exchange 2010 выполняет проверку RBAC и получает список ролей, назначенных пользователю. В каждой роли управления есть список командлетов и их параметров, которые могут быть использованы. Таким образом, при создании среды пользователя, в нее добавляются только те командлеты и параметры, к которым есть доступ.

    RBAC – это отдельная тема, уже описанная ранее у меня в блоге, здесь я лишь приведу пример делегирования пользователю права выполнять операции импорта/экспорта почтовых ящиков.

    Импорт/экспорт почтовых ящиков выполняется при помощи командлетов Import-Mailbox и Export-Mailbox (в Exchange 2010 SP1 для этой цели введен ряд новых командлетов, например New-MailboxImportRequest и New-MailboxExportRequest, они позволяют более гибко использовать операцию импорта/экспорта), данные командлеты включены в роль Mailbox Import Export, о чем свидетельствует команда

    Get-ManagementRoleEntry “*\Import-Mailbox”

    При этом данная роль связана только с группой Organization Management, у которой есть право лишь делегирования. Выяснили мы это при помощи команды:

    Get-ManagementRoleAssignment -Role "Mailbox Import Export" | fl Identity

    В результате, подключившись к серверу Exchange из под учетной записи, входящей в группу ролей Organization Management, мы можем делегировать выполнение необходимых командлетов по крайней мере двумя способами:

    1. Связать пользователя непосредственно с ролью Mailbox Import Export, тем самым дав ему право выполнять командлеты, находящиеся в этой роли:

    New-RoleAssignement -Role "Mailbox Import Export" -User User1

    Как вы понимаете, это не совсем правильный подход к делегированию полномочий, т.к. со временем накопится столько связей, что вы в них попросту не разберетесь. Гораздо правильнее использовать другой подход:

    2. Создать группу ролей, например Remote Admins, включить в неё все роли, которые планируется делегировать сотрудникам и добавить сотрудников уже непосредственно в группу ролей. Делается это командой:

    New-RoleGroup -Name "Remote Admins" -Roles "Mailbox Import Export" -Members User1

    К командлету New-RoleGroup можно добавить такие параметры, как –DisplayName и –Description.

    Теперь, если мы отправимся в Active Directory, то увидим, что у нас образовалась новая группа безопасности Remote Admins в OU Microsoft Exchange Security, членом которой стал User1.

    Также членством в группах ролей RBAC легко управлять через Exchange Control Panel, как показано на рисунке 2.

    img2

    Рис.2: Управление членством в группах RBAC при помощи ECP.

    После того, как вы определились с тем, какие командлеты будет выполнять удаленный пользователь, можно для него включать само удаленное управление. Делается это присвоением параметру RemotePowerShellEnabled, учетной записи пользователя, значения True при помощи команды:

    Set-User YourUser -RemotePowerShellEnabled $True

    Активировав разрешение на удаленное подключение к PowerShell можно двигаться далее.

    Управление через оснастку Exchange Management Console (EMC)

    Начнем с простого, а именно с подключения к серверу Exchange через EMC. Наверняка каждый, кто хоть раз устанавливал сервер Exchange 2010, замечал, что в процессе выбора ролей можно выбрать для установки отдельно компонент Management Tools (Средства управления) (рис.3), собственно эта возможность и служит для того, чтобы инсталлировать оснастку управления Exchange на отдельный сервер или рабочую станцию.

    img3

    Рис.3: Установка Exchange Management Tools.

    Нужно иметь ввиду, что установить средства управления Exchange можно только на современные операционные системы, такие как:

    • · Windows 7
    • · Windows Vista с пакетом обновления 2 (SP2)
    • · Windows Server 2008 с пакетом обновления 2 (SP2)
    • · Windows Server 2008 R2

    При этом ОС обязательно должна быть 64-х битной, т.к. сам Exchange 2010 существует только в 64-х битной редакции.

    Средства управления можно установить и в автоматическом режиме при помощи команды

    Setup.com /R:MT

    Инсталлировав графическую консоль управления нужно её открыть и подключиться к удаленному серверу Exchange при помощи действия Добавить лес Exchange…, (см. рис. 4).

    img4

    Рис.4: Подключение к серверу Exchange черeз EMC.

    В поле адреса указываем либо имя сервера, либо URL расположения виртуального каталога PowerShell, на котором запущен Remote PowerShell и нажимаем кнопку ОК. В результате будет предпринята попытка подключиться по протоколу HTTP на 80-й порт указанного сервера, с использованием проверки подлинности на основе Kerberos.

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

    Одним из преимуществ удаленного использования Management Tools является то, что вы можете, подключив в одну консоль сразу несколько серверов, находящихся в разных лесах Active Directory, осуществлять перемещение почтовых ящиков между лесами, создав простой запрос на перемещение командой New Move Request.

    Подключение к Exchange Management Shell (EMS)

    Разобравшись с графической консолью, пойдем дальше и посмотрим, как же подключиться к серверу при помощи Exchange Management Shell.

    Что касается EMS, то тут нужно знать, что командная консоль сервера Exchange 2010 всегда подключается к нему через виртуальный каталог IIS (http://YourMailServer/PowerShell), независимо от того, локально вы работаете, или удаленно.

    Существует два основных различия запуска EMS на удаленном компьютере, и зависят они от того, установлены Management Tools на компьютер или нет.

    Подключение к EMS при наличии Management Tools

    Если вы запускаете EMS с компьютера, на котором уже установлены Средства управления Exchange (Management Tools), то происходит примерно следующее:

    • · Загружается оснастка Microsoft.Exchange.Management.PowerSell.E2010.
    • · Выполняется скрипт RemoteExchange.ps1, который импортирует некоторые специфичные функции Exchange.
    • · Выполняется функция Connect-ExchangeServer, которая инициирует удаленное подключение к сессии PowerShell на локальном сервере, если локально сервер Exchange найден не будет, то будет предпринята попытка подключиться сначала к CAS серверу в том же сайте, затем к серверу с ролью Mailbox, потом к HUB и только в последнюю очередь к UM.
    • · После подключения к серверу Exchange, в PowerShell сессию импортируются доступные командлеты и параметры.

    Примечание: Чтобы подключиться к другому серверу Exchange из уже открытой сессии EMS, нужно самостоятельно запустить функцию Connect-ExchangeServer, указав ей параметр –auto для автоматического поиска сервера, либо параметром –ServerFQDN для подключения к конкретному серверу.

    Подключение к EMS без Management Tools

    Если на компьютере Management Tools не установлены, то процесс подключения будет несколько другим. Для удобства разделим его на два этапа:

    • · Создание сессии PowerShell;
    • · Импорт созданной серверной сессии в локальную сессию PowerShell.

    Для создания новой сессии используем командлет New-PSSession, при этом, если вы хотите подключиться к серверу под той учетной записью, с которой работаете сейчас, то учетные данные пользователя указывать не обязательно, если же нужно использовать учетные данные другого пользователя, то их следует указывать в параметре Credential, предварительно получив командлетом Get-Credential. При этом нужно знать, что по умолчанию сервер производит аутентификацию при помощи Kerberos. Чтобы использовать другой метод аутентификации, его нужно указать в параметре Authentication. В результате команда может выглядеть примерно следующим образом:

    $session=New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://YourMailServer/powershell -Credential (Get-Credential)

    img5

    Рис.5: Создание новой сессии PowerShell.

    Примечание: Компьютер, с которого происходит подключение, должен входить в домен и при этом на нем необходимо разрешить выполнение загруженных скриптов, подписанных доверенным центром сертификации, делается это при помощи команды Set-ExecutionPolicy RemoteSigned. По умолчанию стоит режим Restricted, запрещающий выполнение любых скриптов.

    Далее нужно будет импортировать серверную сессию в локальную сессию PowerShell. Для этого воспользуемся командлетом Import-PSSession:

    Import-PSSession $session

    Во время импорта сессии произойдет копирование доступных пользователю командлетов и параметров (см. рис.6)

    img6

    Рис.6: Импорт сессии и копирование командлетов.

    Когда процесс завершится, в разделе ExportedCommands можно увидеть список импортированных командлетов. Также список доступных командлетов можно получить при помощи команды Get-Command.

    Теперь можно работать так, как будь-то вы находитесь непосредственно на удаленном сервере.

    После завершения работы нужно не забыть разорвать установленную сессию командой

    Remove-PSSession $session

    Автоматизация подключения к серверу Exchange через PowerShell

    Если вы работаете на компьютере с установленными средствами управления Exchange, то беспокоиться вам особо не о чем, у вас есть уже готовый ярлык подключения к EMS, но если средства управления у вас не установлены, то постоянно создавать сессию подключения к серверу дело весьма хлопотное. Давайте посмотрим, как можно облегчить данную процедуру.

    Я вижу, по крайней мере, два пути решения этой задачи:

    1. Сохранить в виде скрипта (например, c:\EMS.ps1) описанные выше команды создания сессии PowerShell и импорта её к себе в локальную сессию и запускать этот скрипт каждый раз, когда нужно подключиться к серверу Exchange. При этом при запуске скрипта нужно использовать ярлык, в котором будет указана следующая команда:

    powershell.exe -NoExit -command c:\EMS.ps1

    Примечание: Параметр –NoExit необходим, чтобы окно PowerShell не закрывалось после выполнения скрипта.

    2. Либо импортировать запуск Exchange Management Shell прямо в профиль PowerShell пользователя, таким образом, чтобы каждый раз при запуске PowerShell у вас происходило автоматическое подключение к Exchange. Делается это следующим образом:

    Если профиль PowerShell у вас ещё не создан, то создать его нужно командой

    New-Item -Path $profile -ItemType file -force

    В результате будет создан файл Microsoft.PowerShell_Profile.ps1, в который можно будет добавить необходимые команды. Отредактировать файл профиля проще всего в блокноте, выполнив команду notepad $profile.

    Далее опять есть два пути добавления Exchange Management Shell в профиль и зависят они снова от наличия Management Tools:

    • · Если Management Tools не установлены, то просто добавим ранее описанные команды создания удаленной сессии PowerShell и её импорта в локальную сессию в профиль PowerShell:

    $session=New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://YourMailServer/powershell -Credential (Get-Credential)

    Import-PSSession $session

    • · Если же Exchange Management Tools есть в наличии, то правильнее будет интегрировать Exchange Management Shell в сессию PowerShell таким же образом, каким она открывалась бы самостоятельно при запуске через соответствующий ярлык. Для этого нужно в профиль добавить те действия, речь о которых шла в самом начале этого раздела:

    Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010

    . $env:ExchangeInstallPath\bin\RemoteExchange.ps1

    Connect-ExchangeServer -auto

    В результате проделанных манипуляций у вас всегда будет под рукой либо ярлык создания подключения к командной консоли Exchange, либо, запуская сессию PowerShell, вы уже будете иметь интегрированные в неё командлеты Exchange.

    Заключение

    Итак, мы рассмотрели вопросы удаленного подключения, как к графической, так и к командной консоли управления сервером Exchange 2010. Надеюсь, теперь ваша работа с Exchange Server 2010 станет ещё комфортнее и продуктивнее.

    Алексей Богомолов (Alexx)
    http://alexxhost.ru

    Статья опубликована в журнале
    “Системный администратор” (Октябрь, 2010)

Комментарии

  1. огорчает что для EMC нужно x64 OS

  2. В конце 2010 года огорчает?

  3. Илья, как сказал мне один мой знакомый – “Как хорошо что у меня не x64 OS на сервере терминалов, а то какая-нибудь “плохая” софтина могла бы сожрать всю память” :-)))
    Илья, я использую X32. И пока не поставлю себе 4Гб RAM буду использовать x32, ибо не вижу необходимостия в x64 (я знаю про более защищенность, но всё же). в x32 есть NTVDM 🙂 (про виртуализацию я тоже знаю, но всё же).

  4. Я даже на домашнем уже года два-три живу с 8 Гб памяти, про рабочие и сервера вообще отдельная история. Да и на ноуте где 2 Гб также стоит X64 ибо смысл ставить устаревшую платформу, которая свое дожила.

  5. Вобщем то да, огорчает отсутствие x86 – консоли.
    За Илью могу только порадоваться, к сожалению немогу в компании ставить всем x64 из за специфичефического говно-софта.

  6. Как то странно, что у администратора на его раб. машине стоит “специфический говнософт” что мешает ему использовать х64 платформы. Уж если администраторы в компании сидят на устаревших платформах, пусть даже аппаратных, то тут как сапожник без сапог.

    Статья хорошая, автору большое спасибо за полезный в практике материал

  7. Коллеги, а через веб-морду нельзя что ли создать пользователя?