
По време на проекти и обучения много често ми се случва да получавам въпроса дали е възможно да използваме 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)

Димитър е старши консултант и трейнър с над 15 години опит в консултирането на някои от най-големите компании в региона в областта на оркестрация и автоматизация на ИТ услуги, облачни решения и ИТ сигурност. Той е трейнинг мениджър в ITCE и отговаря за постоянното подобрение на трейнинг процесите и удовлетвореността.