Exchange Server 2013 – варианты запуска удаленных скриптов


Для удаленного выполнения команд на Exchange Server 2013 существует специальный сервис «web powershell». Описано тут и выглядит так:

$UserCredential = Get-Credential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://<FQDN of Exchange 2013 Client Access server>/PowerShell/ -Authentication Kerberos -Credential $UserCredential

Далее варианты:

Invoke-Command -Session $Session -ScriptBlock { Get-MailBox TestUser }

или

Import-PSSession $Session

Get-MailBox TestUser

Первый вариант позволяет оперировать с оригинальными объектами на удаленном сервере без потери типов данных и их структуры. Тем не менее Powershell имеет значительные ограничения и многие конструкции и командлеты не работают (просто отсутствуют). Вы получите сообщения вида:

Script block literals are not allowed in restricted language mode or a Data section

и массу других аналогичных:

… are not allowed in restricted language mode or a Data section

Второй вариант импортирует объекты на локальный компьютер путем сериализации (serialization), т.е. преобразует атрибуты в текст по сути, с потерей типов данных и прочими нарушениями из-за того, что не все атрибуты могут быть преобразованы в строковое значение или преобразование выполняется некорректно. При этом все возможности Powershell сохраняются в полном объеме.

Как же писать скрипт: по первому варианту или по второму? Очевидно, что скрипт не будет переносимым между этими вариантами.

Если операция относительно Exchange простая, например, скрипт создания нового пользователя и его почтового или изменение параметра почтового ящика, то вполне подойдет первый вариант.

Для более навороченного скрипта напрашивается второй вариант. Только скрипт получается уж больно специфическим и медленным по определению.

Можно предположить, что существует третий вариант: открыть удаленную сессию $Session = New-PSSession –ComputerName CAS и запустить в ней RemoteExchange.ps1 …, но проблема в том, что требуется делегирование (credential delegation), т.к. клиент подключается к CAS, а тот в свою очередь к MailBox. Включать делегирование на рабочих серверах это плохая идея.

Есть еще один способ. Заключается в снятии ограничений первого варианта. У Powershell есть параметр PSLanguageMode, который по умолчанию стоит в RestrictedLanguage:

Стоит его изменить на FullLanguage и многое заработает.

Изменения надо делать как на Default Web Site, так и на Exchange Back End. На всех серверах. После изменения параметра требуется iisreset.

В какой-то степени это понижает безопасность. Но скорее всего URl http://CAS/powershell у вас не доступен публично (не опубликован). К тому же всем рядовым пользователям можно выключить Powershell:

Set-User TestUser -RemotePowerShellEnabled $False

PS: Безусловно есть варианты с запуском EMS в RDP сессии или установкой EMS на локальном компьютере, где должен запускаться скрипт.

Реклама

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

%d такие блоггеры, как: