[БЕЗПЛАТЕН Уебинар] Embracing Agility: Roadmap to Scaling Your Agile Transformation

Подсигурете успеха на своята Agile трансформация с насоки за нейното скалиране на организационно ниво и сформиране на персонален бленд от модерни подходи и системи. Научете повече ТУК.

Мога ли да използвам 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-PSSessionConfigurationName Microsoft.ExchangeConnectionUri http://<Exchange_FQDN>/PowerShell/Authentication KerberosCredential $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-PSSessionConfigurationName Microsoft.ExchangeConnectionUri https://outlook.office365.com/powershell-liveid/Credential $UserCredentialAuthentication Basic -AllowRedirection

Import-PSSession $Session

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

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

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

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

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close