Очевидно, що будь-яка заздалегідь сконфигурированная комп'ютерна система, в наслідок вимагає не тільки постійного контролю, але і можливості легкого доступу до функцій управління. Якщо процес впровадження може відбуватися безпосередньо з консолі сервера, то питання адміністрування вкрай незручно вирішувати таким чином. Я думаю, що Новомосковсктель зі мною погодиться, якщо я скажу, що в переважній більшості організацій сервери знаходяться зовсім не там, де сидять їхні адміністратори, тобто не можна просто розгорнути стілець і отримати прямий доступ до консолі сервера. А раз так, то абсолютно обгрунтовано вимога технічного персоналу, мати інструменти, що дозволяють виконувати свої завдання «не встаючи з робочого місця». Тут хтось може сказати, що для цього вже існує віддалений робочий стіл Windows і нічого тут «винаходити велосипед».
Якою мірою це вірно, але використання RDP не завжди зручно і в деяких випадках не прийнятно. Незручно тому, що якщо, у вас досить багато серверів, то підключатися до кожного з них кілька втомлює, набагато простіше відкрити локальну консоль PowerShell і вже мати підключення до всіх з них, або запустити локально встановлену Exchange Management Console і працювати з усіма серверами одночасно, але вже через графічний інтерфейс. А чи не прийнятно, тому, що часто бувають ситуації, коли співробітнику необхідно делегувати одне-два строго визначених дії, отже, пускати його в термінальний сеанс сервера не зовсім правильно з точки зору безпеки, набагато краще, якщо у нього буде тільки довірений набір кнопок в EMC і тільки дозволені командлети в EMS.
віддалене підключення
Рис.1: Віртуальний каталог PowerShell в диспетчері IIS.
підготовка користувача
Перш ніж давати користувачеві можливість віддаленого доступу до організації Exchange, потрібно визначитися зі списком прав, які ви хочете йому делегувати.
RBAC - це окрема тема, вже описана раніше у мене в блозі, тут я лише наведу приклад делегування користувачеві права виконувати операції імпорту / експорту поштових скриньок.
При цьому дана роль пов'язана тільки з групою 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. Створити групу ролей, наприклад RemoteAdmins. включити в неї всі ролі, які планується делегувати співробітникам і додати співробітників вже безпосередньо в групу ролей. Робиться це командою:
New-RoleGroup -Name "Remote Admins" -Roles "Mailbox Import Export" -Members User1
До Командлети New-RoleGroup можна додати такі параметри, як -DisplayName і -Description.
Тепер, якщо ми вирушимо в Active Directory, то побачимо, що у нас утворилася нова група безпеки RemoteAdmins в OU MicrosoftExchangeSecurity. членом якої став User1.
Також членством в групах ролей RBAC легко керувати через ExchangeControlPanel. як показано на малюнку 2.
Рис.2: Управління членством в групах RBAC за допомогою ECP.
Після того, як ви визначилися з тим, які командлети буде виконувати віддалений користувач, можна для нього включати саме віддалене управління. Робиться це присвоєнням параметру RemotePowerShellEnabled, облікового запису користувача, значення True за допомогою команди:
Set-User YourUser -RemotePowerShellEnabled $ True
Активувавши дозвіл на віддалене підключення до PowerShell можна рухатися далі.
Управління через оснащення Exchange Management Console (EMC)
Рис.3: Установка Exchange Management Tools.
Потрібно мати на увазі, що встановити засоби керування Exchange можна тільки на сучасні операційні системи, такі як:
Засоби управління можна встановити і в автоматичному режимі за допомогою команди
Інсталював графічну консоль управління потрібно її відкрити і з'єднатися з віддаленим сервером Exchange за допомогою дії Додати лесExchange .... (Див. Рис. 4).
Рис.4: Підключення до сервера Exchange черeз EMC.
Одним з переваг віддаленого використання Management Tools є те, що ви можете, підключивши в одну консоль відразу кілька серверів, що знаходяться в різних лісах Active Directory, здійснювати переміщення поштових скриньок між лісами, створивши простий запит на переміщення командою NewMoveRequest.
Підключення до Exchange Management Shell (EMS)
Розібравшись з графічної консоллю, підемо далі і подивимося, як же підключитися до сервера за допомогою Exchange Management Shell.
Існує два основні відмінності запуску EMS на віддаленому комп'ютері, і залежать вони від того, встановлені Management Tools на комп'ютер чи ні.
Підключення до EMS при наявності Management Tools
Якщо ви запускаєте EMS з комп'ютера, на якому вже встановлено Засоби управленіяExchange (Management Tools), то відбувається приблизно наступне:
Примітка: Щоб підключитися до іншого серверуExchangeіз вже відкритої сессііEMS, потрібно самостійно запустити функцію Connect-ExchangeServer, вказавши їй параметр -autoдля автоматичного пошуку сервера, або параметром -ServerFQDN для підключення до конкретного сервера.
Підключення до EMS без Management Tools
Якщо на комп'ютері Management Tools не встановлені, то процес підключення буде дещо іншим. Для зручності розділимо його на два етапи:
- · Створення сесії PowerShell;
- · Імпорт створеної серверної сесії в локальну сесію PowerShell.
Для створення нової сесії використовуємо командлет New-PSSession. при цьому, якщо ви хочете підключитися до сервера під тим обліковим записом, з якої працюєте зараз, то облікові дані користувача вказувати не обов'язково, якщо ж потрібно використовувати облікові дані іншого користувача, то їх слід вказувати в параметрі -Credential. попередньо отримавши Командлети Get-Credential. При цьому потрібно знати, що за замовчуванням сервер виробляє аутентифікацію за допомогою Kerberos. Щоб використовувати інший метод аутентифікації, його потрібно вказати в параметрі -Authentication. В результаті команда може виглядати приблизно так:
Рис.5: Створення нової сесії PowerShell.
Примітка. Комп'ютер, з якого відбувається підключення, повинен входити в домен і при цьому на ньому необхідно дозволити виконання завантажених скриптів, підписаних довіреною центром сертифікації, робиться це за допомогою команди Set-ExecutionPolicy RemoteSigned. За замовчуванням стоїть режим Restricted. що забороняє виконання будь-яких скриптів.
Далі потрібно буде імпортувати серверну сесію в локальну сесію PowerShell. Для цього скористаємося Командлети Import-PSSession:
Коли процес завершиться, в розділі ExportedCommands можна побачити список імпортованих командлетів. Також список доступних командлетів можна отримати за допомогою команди Get-Command.
Тепер можна працювати так, як будь-то ви знаходитеся безпосередньо на віддаленому сервері.
Після завершення роботи потрібно не забути розірвати встановлену сесію командою
Автоматизація підключення до сервера 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:
- · Якщо ж Exchange Management Tools є в наявності, то правильніше буде інтегрувати Exchange Management Shell в сесію PowerShell таким же чином, яким вона відкривалася б самостійно при запуску через відповідний ярлик. Для цього потрібно в профіль додати ті дії, мова про які йшла на самому початку цього розділу:
В результаті виконаних маніпуляцій у вас завжди буде під рукою або ярлик створення підключення до командної консолі Exchange, або, запускаючи сесію PowerShell, ви вже будете мати інтегровані в неї командлети Exchange.