Мога ли да използвам Windows PowerShell Integrated Scripting Environment (ISE) за управление на Exchange Server?

По време на проекти и обучения много често ми се случва да получавам въпроса дали е възможно да използваме Windows PowerShell Integrated Scripting Environment (ISE) като по-удобен Host Interface на PowerShell за да управляваме Exchange Server (тук основно засягаме Exchange 2010, Exchange 2013 и Exchange Online (Office 365)).

Краткият отговор е – „Да, може!“

В следващите няколко реда ще разгледаме как да го направим, а тези от вас, които вече знаят, че може – вероятно ще разберат някои детайли.

Windows PowerShell Integrated Scripting Environment (ISE) представлява много удобен host interface за PowerShell – особено когато работим или създаваме по-големи изрази и скриптове.

Потребителите на Office 365 с Exchange Online вероятно вече са използвали ISE, за да администрират своя абонамент като подходът за свързване към Exchange Online слабо се различава от този при on-premises Exchange 2010;2013.

Аз използвам следния израз за свързване на ISE към Exchange on-premises:

$Session = New-PSSession -ConfigurationName Microsoft.Exchange –ConnectionUri http://<Exchange_FQDN>/PowerShell/ -Authentication Kerberos

import-pssession $session

add-pssnapin microsoft.exchange*

За мен, той е удобен, т.к. често се свързвам към различни сървъри и затова не го подобрявам. Ще обърна внимание на по-важните компоненти:

ConnectionUri

Тук трябва да изпишете пълното име на вашия Exchange сървър (или един от тях). Важно е името, което изписвате да присъства в сертификата използван от сървъра – т.к. в зависимост от настройките на средата ви може да получите грешка свързана с цифровия сертификат.

Authentication

Тук трябва да опишете метод за автентикация. При мен много често се случва да управлявам Exchange организации с повече сървъри и те обикновено си имат специалиализиран сървър за управление. Ако потребителя, с който сте се логнали и стартирали ISE има административни права това е добре като конфигурация. Ако искате да се свържете от ваша работна станция, на която потребителя няма права към Exchange трябва да смените метода за автентикация и изрично да подадете потребителско име и парола по подобен начин:

$cred = Get-Credential

$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri http://<Exchange_FQDN>/PowerShell/ –Authentication Kerberos –Credential $cred

import-pssession $session

add-pssnapin microsoft.exchange*

Важно е да обърнете внимание на метода за автентикация. Той трябва да бъде позволен на сървъра.

Ако много ви хареса използването на ISE за управление на Exchange е добре да отбележим, че можете да запишете този код като PowerShell startup script и дори да напишете Custom Menu Option for ISE. Тези теми ще оставя за отделна статия.

Добре е да отделим няколко реда за това какво се случва зад описаните PowerShell команди:

• Извършваме PowerShell Implicit Remoting към Exchange Server, който е зададен със статичен адрес (FQDN);
• Зареждаме Exchange Span-in и командите за управление.

Важно предимство на този подход е, че използваме WS-Man протокол за достъп. Той се поддържа от WinRM услугата. Има редица предимства, ето по-важните:

• Използваме HTTP(S) протокол
• Не е нужно да отваряме врати за RPC
• Използваме съвременни криптиране и автентикация
• Използваме фиксиран порт и можем да използваме връзката при латентни мрежи

Подобен израз можем да използваме за свързване към Exchange Online:

$UserCredential = Get-Credential

$Session = New-PSSession –ConfigurationName Microsoft.Exchange –ConnectionUri https://outlook.office365.com/powershell-liveid/ –Credential $UserCredential –Authentication Basic -AllowRedirection

Import-PSSession $Session

Този израз вече е универсален поради спецификата на работа при Exchange Online като облачна услуга.

Какви често срещани проблеми можем да изпитаме:

• Трябва да сте сигурни, че Exchange сървърът е включен и работи (следващите ще са по-сериозни);
• Внимавайте с въвеждането на парола. Дефинирането на променлива с потребителско име и парола не проверява реално паролата;
• По подразбиране можете да направите до три едновременни сесии;
• Трябва да сте наясно с PowerShell Script Execution Policy на работната ви станция, т.к. PowerShell има нужда да изпълни скрипт отдалечено. Добра опция е „remote signed”. Конфигурира се с „Set-ExecutionPolicy RemoteSigned“
• Името, по което се обръщате към сървъра трябва да фигурира в цифровия сертификат (SAN name)

---