Оснастка exchange 2010 для windows 10

Применимо к: Exchange Server 2010 SP1

Последнее изменение раздела: 2010-07-29

С помощью средств управления Microsoft Exchange Server 2010
можно настраивать и управлять организацией Exchange удаленным
образом. В этом разделе описывается, как можно использовать
программу установки Setup.exe или режим автоматической установки
средств управления Exchange 2010.

Средства управления Exchange 2010 можно установить в следующих
операционных системах Windows.

• Windows 7
• Windows Vista с пакетом обновления 2 (SP2)
• Windows Server 2008 с пакетом обновления 2 (SP2)
• Windows Server 2008 R2

Дополнительные сведения об управлении Exchange 2010 см. в
разделах Консоль
управления Exchange и Командная консоль
Exchange.

Предварительные условия

Использование режима
автоматической установки для установки средств управления Exchange
2010

Недавняя презентация Windows 10 (хоть и привью версию, но все же…, кстати скоро будет представлена очередная сборка http://news.softodrom.ru/ap/b20718.shtml), заставила меня наконец завершить  многолетнюю эксплуатацию, стабильного, знакомого со всех сторон, Windows XP. Реальность бытия диктует свои условия…

Но сейчас не об этом…

Вчера на работе, мы приступили к «обкатке» полноценного корпоративного шаблона в связке Windows8.1+Office365. Такие вещи мы всегда начинаем обкатывать со своих компов, наконец вчера «пристрелил» у себя на компе Windows XP и теперь полноценно эксплуатирую Windows8.1, админы стали на те же рельсы. Здесь не буду распространяться о Windows 8.1 (ранее я уже высказывал свое мнение по этому вопросу). Вчера практически все накатилось  без проблем, доменная GPO «накатилась как по маслу»  и весь набор необходимых в работе утилит и программ встал без труда, за исключением одной .

Порой приходится посещать почтовый сервак ( в нашем случае это Exchange 2010SP3) соответственно чтоб упростить задачу (перь винда это полноценно позволяет), решили «прикрутить» себе в MMC все необходимые оснастки, одной из таких является   Exchange 2010 Management Tools, с ней собственно и возникли проблемы, о них подробнее…

Сама установка и требования вроде не замысловаты:

Перед установкой необходимо в компонентах Windows добавить:

• Microsoft .NET Framework 3.5.1;
• Службы IIS -> Средства управления веб-сайтом -> Совместимость управления IIS 6 -> Консоль управления IIS 6.

Открываем консоль PowerShell / cmd, находим дистрибутив и выполняем команду:

Setup.com /R:MT

Вроде далее должно быть вот так:

Но в моем случае, что-то пошло не так, повались ошибка установки и все на этом также благополучно завершилось, решил еще раз ознакомиться с последовательностью установки, прочитать о ней можно, например здесь:

http://www.petri.com/install-exchange-2010-management-tools-windows-8.htm

С виду все правильно, но вот такой «кулак дружбы» по прежнему не пропадал

Обсуждение проблемы можно почитать здесь:

https://social.technet.microsoft.com/forums/windows/en-US/c19af6ae-c9cb-4e59-9e2f-21f33715c267/exchange-management-console-tools-compatibility

или здесь

https://social.technet.microsoft.com/Forums/exchange/en-US/aeeedf06-9d9f-4186-9ba9-28c2a2fbaa88/exchange-2010-sp3-installing-on-windows-81server-2012r2?forum=exchange2010

снова «пляски с бубном».

В итоге после некоторых изысканий сделал следующее:

— Удаляем Microsoft .NET Framework 3.5

— Перезагружаем комп

— Устанавливаем Microsoft .NET Framework 3.5 снова.

— Накатываем обновления в том числе NET Framework 3.5, снова перезагружаем комп.

— Вновь следуем выше приведенной инструкции и все благополучно устанавливается, проблемы с NET Framework различных версий достаточно распространены.

Более никаких проблем с адаптацией Windows 8.1 пока не замечены…

Всем хорошей работы !!!

16.10.2014 —

Posted by |
ms windows 8/8.1

Powershell как инструмент администрирования Microsoft Exchange Server впервые появился в версии продукта 2007, уже 5 лет назад. С тех пор сфера его применения в Exchange Server становится только шире, а введение Powershell remoting открыло совершенно новые возможности для администраторов.

Сисадмины осваивают этот скриптовый язык, но положение, в котором они находятся, совсем не одинаковое. Кто-то мигрирует свой сервер с 2003 на 2010 и для них Powershell — настоящий вызов. Администраторы 2007 и 2010, как минимум, открывали Exchange Management Shell (EMS) и экспериментировали с ним. Например, в таких рутинных задачах как сбор сведений о конфигурации или изменении свойств почтового ящика. Некоторые после этих попыток сбегают обратно в комфорт Exchange Management Console (EMC).
Те, кто его не используют, или используют недостаточно, лишают себя великолепной возможности исследовать и использовать на практике постоянно пополняющийся мир скриптов, выполняя на своих серверах такие задачи, которые ранее выполнить было просто невозможно.
Не секрет, что Powershell способен существенно улучшить некоторые аспекты управления серверами, заполняя белые пятна, оставленные Microsoft.
Примеров использования Powershell для выполнения крайне важных с точки зрения администрирования задач очень много –
Например, когда я ранее работал в большом американском провайдере серьезной проблемой была высокая RPC Latency на CAS серверах, возникавшая из-за проблем с определенными версиями iOS. Проверка нагрузки CAS серверов путем мониторинга числа активных подключений, определение клиента, используемого при подключении, экспорт нужной информации и компиляция html репортов – все это выполнялось на Powershell и оказывало колоссальную помощь.
Powershell, наверное, не самый простой язык. В Exchange Server 2010 SP1 – более полутысячи командлетов и на их изучение уйдет время. Несмотря на это, преимущества его использования в будущем – совершенно точно окупятся.

В статье я рассмотрю несколько ценных для системного администратора сценариев использования Exchange Management Shell. Подчеркну, что цель статьи – не осветить все (да это и невозможно!), а показать – что Powershell для нас, фанатов Microsoft Exchange Server, действительно все.

1. Создание отчетов и их экспорт

Когда приходится администрировать большую Exchange организацию (или хостинг, например), то часто сталкиваешься с необходимостью создания репортов/отчетов в пригодном для последующего редактирования виде. Иногда они могут требоваться по запросу клиентов, чаще – для внутренних аудиторских целей. Exchange Management Shell обладает способностью создавать высоко детализированные отчеты, что для администраторов – несомненное благо. Командлетов, начинающихся с Get-* более чем достаточно в связке Windows PowerShell и Exchange Management Shell, что предоставляет поистине безграничные возможности кастомизации отчетов. Стандартно экспорт производится либо в .txt, либо в .csv формат – оба крайне удобные для любых последующих манипуляций с данными.
Как правило, для экспорта в текстовый или CSV файл используется командлет Out-File (для CSV – Export-CSV). Скажем, у нас есть задача произвести экспорт в текстовый файл список всех почтовых ящиков организации, использовав для фильтрации отображения результата колонки Name и WhenCreated:

Get-Mailbox | Select-Object Name,WhenCreated | Out-File c:xferreport.txt

Надо сказать, что наряду с «правильным» для Powershell командлетом Out-File также действует и олдскульный –

[PS] C:Windowssystem32>Get-Mailbox | Select-Object Name,WhenCreated > c:xferreport.txt

2. Массовое создание пользователей из CSV файла

Еще один типичный сценарий администрирования Exchange – массовое создание пользователей из CSV файла.Может использоваться при миграции пользователей из другого окружения, при слияниях компаний или просто большом найме новых сотрудников. Для этого сценария типично использование CSV файлов. Для начала нужно подготовить CSV файл. Если администратор имеет желание облегчить себе задачу по последующему изменению атрибутов пользователей, то логично предусмотреть все заранее. При миграции или переезде пользователей с ActiveDirectory-based окружения, экспортирование нужных AD атрибутов пользователей позволит быстро их создать на новом месте, в новой ActiveDirectory.

Экспортируем через get-user, производим выборку по нужным атрибутам и передаем полученный результат в CSV файл.

Теперь у нас есть полностью готовый к последующему импорту CSV файл. В большинстве случаев хватает такого набора информации в CSV файле:

Lastname,Firstname,Name,UserPrincipalName,Password
Наш файл, готовый к импорту в ActiveDirectory, импортируем туда такой командой, меняя под себя требуемые переменные —

Import-CSV c:xferour_import.csv | ForEach-Object { New-Mailbox -Lastname $_.”LastName” -Name $_."Name" -FirstName $_.”FirstName” -Organization Our Organization -Database DB1 -UserPrincipalName $_.”UserPrincipalName” -Password (ConvertTo-SecureString $_.password -AsPlainText -Force)}

Введя в конструкцию –ResetPasswordOnNextLogon установленный в $true мы заставим пользователей поменять пароль при первом заходе в систему.
Используя указанный метод можно создавать сотни почтовых ящиков за минуты, очень существенно экономя время. Аналогичным образом Powershell позволяет работать и со списками рассылки, и с контактами.

3. Как удалить «плохое» сообщение из всех почтовых ящиков сразу?

Когда-то в своей практике я столкнулся с интересным (и крайне срочным!) запросом пользователя, который требовал удалить из почтовых ящиков всех сотрудников организации (более 200) одно письмо с крайне чувствительной для компании информацией, которое послал на общий список рассылки уволенный ранее сотрудник.
Приведенный ниже командлет позволяет реализовать поиск по ящикам требуемого аккаунта и убрать нежелательное сообщение. В сценарии ниже для примера задана тема письма, почтовый ящик куда мы складываем «плохое» сообщение и целевая папка.

get-mailbox -OrganizationalUnit Needed_OU -ResultSize unlimited | Search-Mailbox -SearchQuery Subject:'Very bad message' -TargetMailbox mailbox@mailbox.com -TargetFolder Inbox –DeleteContent

4. Проверяем размер почтовых баз

По сравнению с Exchange 2007 в последней версии Exchange сервера эта операция осуществляется существенно удобнее. Обновленный командлет Get-MailboxDatabase позволяет получить практически любую информацию.
Получаем базы с именем, сервером, статусом монтирования и размерами:

Get-MailboxDatabase -Status | select-object Name,Server,DatabaseSize,Mounted

5. Почтовый клиент и почтовые ящики

Exchange 2010 позволяет оперировать клиентским доступом к почтовым ящикам на основе версии клиента Outlook и метода доступа в почтовый ящик.
Существует несколько возможностей ограничить доступ по различным критериям. Например, мы хотим не давать возможность соединения по RPC over HTTPS —

Set-CASMailbox -Identity mailbox@mailbox.com -MAPIBlockOutlookRpcHttp $true

Такой командлет не даст возможность работы с почтовым ящиком клиенту, настроенному не в режиме кэширования —
Set-CASMailbox -Identity mailbox@mailbox.com -MAPIBlockOutlookNonCachedMode $true

А таким мы не дадим использовать пользователям версии Outlook старее, чем 2003.

Get-CASMailbox -Resultsize Unlimited | Set-CASMailbox -MAPIBlockOutlookVersions '-5.9.9;7.0.0-10.9.9'

Вот так можно получить красивую информацию по почтовым ящикам с заданного аккаунта и экспортировать ее в Excel:

Get-Mailbox -OrganizationalUnit groza -Resultsize unlimited | Get-MailboxStatistics | Sort-Object TotalItemSize -Descending | Select-Object DisplayName,@{Name="TotalItemSize(KB)";Expression={$_.TotalItemSize.Value.ToKB()}},ItemCount,lastlogontime,lastlogofftime,lastloggedonuseraccount | Export-Csv c:xfergroza.csv | foreach {$_.length=($_.length)/1024/1024/1024; $_}

А так информацию о свободном месте на жестких дисках нужного сервера:
Get-WmiObject -Class Win32_Logicaldisk -computername | select deviceid,volumename,freespace

6. Клиентский доступ

В Exchange Management Shell имеется достаточное количество командлетов, которые системные администраторы могут использовать для траблшутинга наиболее типичных проблем, которые могут возникнуть в процессе эксплуатации продакшен среды.

При трудностях с залогиниванием в почтовый ящик на выручку придет командлет Test-MapiConnectivity, который можно использовать с различными параметрами.

Проверим возможность логина в определенную базу — Test-MAPIConnectivity -Database DB1

Или в определенный почтовый ящик —

Test-MAPIConnectivity –Identity Vorobyaninov@RK.downtime.ru

Или на определенном сервере —

Test-MAPIConnectivity -Server MBX1

Проблемы с RPC соединениями диагностируется с использованием командлета Test-OutlookConnectivity. Главным отличием от предыдущего командлета является необходимость указания пароля тестируемого пользователя.
Поскольку серверная роль CAS в Exchange 2010 предоставляет доступ по большому количеству протоколов, то вполне естественно, что создатели Microsoft Exchange Server 2010 позаботились о том, чтобы недостатка в нужных командлетах не было:

Test-ActiveSyncConnectivity — тестирует ActiveSync протокол;
Test-CalendarConnectivity – тестирование доступности календаря;
Test-EcpConnectivity – валидация виртуальной директории ECP на выбранном CAS сервере
Test-ImapConnectivity – проверка статуса сервиса IMAP и возможности клиентского подключения по данному протоколу
Test-OutlookWebServices – проверка корректности информации, выдаваемой пользователю сервисом AutoDiscover
Test-OwaConnectivity – валидация виртуальной директории OWA на указанном CAS сервере
Test-WebServicesConnectivity – проверка Exchange Web Services, которые используются, например, Outlook for Mac, Mac Mail и еще некоторыми клиентами.
Таковы всего несколько сценариев, в которых может использоваться Exchange Management Shell, реальная работа с ним и работа с Exchange 2010 открывают двери в этот мир гораздо шире. И чем больше системный администратор узнает о нем, тем больше он опирается на него в своей повседневной работе – сложно не оценить потрясающие возможности скриптования и автоматизации операций, которые несет этот язык.

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

Я думаю, что читатель со мной согласится, если я скажу, что в подавляющем большинстве организаций сервера находятся совсем не там, где сидят их администраторы, т.е. нельзя просто развернуть стул и получить прямой доступ к консоли сервера. А раз так, то абсолютно обосновано требование технического персонала, иметь инструменты, позволяющие выполнять свои задачи «не вставая с рабочего места». Здесь кто-то может сказать, что для этого уже существует удаленный рабочий стол Windows и нечего тут «изобретать велосипед». В какой степени это верно, но использование RDP не всегда удобно и в некоторых случаях не приемлемо. Неудобно потому, что если, у вас достаточно много серверов, то подключаться к каждому из них несколько утомительно, гораздо проще открыть локальную консоль PowerShell и уже иметь подключение ко всем из них, либо запустить локально установленную Exchange Management Console и работать со всеми серверами одновременно, но уже через графический интерфейс. А не приемлемо, потому, что часто бывают ситуации, когда сотруднику необходимо делегировать одно-два строго определенных действия, следовательно, пускать его в терминальный сеанс сервера не совсем правильно с точки зрения безопасности, гораздо лучше, если у него будет только доверенный набор кнопок в EMC и только разрешенные командлеты в EMS.

Что касается стандартных служб Windows Server, то Microsoft дает нам набор утилит удаленного администрирования RSAT (Remote Server Administration Tools), которые мы всегда можем скачать, установить на рабочую станцию и использовать оснастки служб Windows так, как будто мы находимся непосредственно на сервере. RSAT – это хорошо, но в этом случае мы получаем доступ только к службам самого сервера, а как быть с ПО, установленном на нем, например с сервером Exchange 2010? Здесь разработчики Microsoft тоже не оставили системных администраторов без поддержки и дали им возможность полноценного удаленного управления, как через стандартную графическую оболочку Exchange Management Console (EMC), так и через командную консоль Exchange Management Shell (EMS).

Удаленное подключение

Для того чтобы управлять сервером удаленно, логично, что к нему необходимо как-то подключиться. Так вот, в случае с Exchange Server 2010, любые удаленные подключения происходят через виртуальный каталог IIS (Internet Information Services), который носит название PowerShell (рис.1).

Рис.1: Виртуальный каталог PowerShell в диспетчере IIS.

При этом подключение осуществляется по протоколу HTTP, а при аутентификации по умолчанию используется Kerberos, само же взаимодействие происходит при помощи WinRM и новой функции Remote PowerShell. Раз речь зашла о Remote PowerShell, то на клиенте должен быть установлен Windows Management Framework, в который входят Windows PowerShell 2.0 и WinRM. Подробнее о Windows Management Framework можно почитать в библиотеке TechNet (http://technet.microsoft.com/ru-ru/library/dd335147.aspx).

Так как клиенты подключаются к виртуальному каталогу по протоколу HTTP на 80-й порт, то это дает нам возможность с легкостью опубликовать данный веб-сервер в сеть Интернет и работать удаленно уже в прямом смысле этого слова, из любой точки, где есть выход в сеть Интернет. Публикацию каталога PowerShell можно осуществить любыми доступными средствами, например, при помощи корпоративного шлюза на базе TMG или ISA сервера, при этом можно настроить HTTPS-переадресацию для HTTP-соединения и в результате получить защищенный шифрованный канал между клиентом и шлюзом, что усилит безопасность работы.

Нужно заметить, что подключаться удаленно к Exchange 2010 по протоколу HTTP могут клиенты только с доменных компьютеров, если вы хотите работать с компьютера, который не входит в домен организации Exchange, то вам для подключения в любом случае придется использовать HTTPS-соединение.

Подготовка пользователя

Прежде чем давать пользователю возможность удаленного доступа к организации Exchange, нужно определиться со списком прав, которые вы хотите ему делегировать.

Для управления правами пользователей, в Exchange 2010 введена новая модель управления доступом — Role Based Access Control (RBAC), которая пришла на смену спискам контроля доступа (ACL). Основное отличие в данном случае состоит в том, что разрешения ассоциируются не с объектами AD, такими как серверы и почтовые ящики, а с задачами, при этом в RBAC пользователю присваивается объединение всех ролей и прав, которые для него назначены.

В процессе аутентификации сервер Exchange 2010 выполняет проверку RBAC и получает список ролей, назначенных пользователю. В каждой роли управления есть список командлетов и их параметров, которые могут быть использованы. Таким образом, при создании среды пользователя, в нее добавляются только те командлеты и параметры, к которым есть доступ.

RBAC – это отдельная тема, уже описанная ранее в одном из циклов статей (http://www.alexxhost.ru/2010/04/role-based-access-control-rbac-exchange.html), здесь я лишь приведу пример делегирования пользователю права выполнять операции импорта/экспорта почтовых ящиков.

Импорт/экспорт почтовых ящиков выполняется при помощи командлетов Import-Mailbox и Export-Mailbox (в Exchange 2010 SP1 для этой цели введен ряд новых командлетов, например New-MailboxImportRequest и New-MailboxExportRequest, они позволяют более гибко использовать операцию импорта/экспорта), данные командлеты включены в роль Mailbox Import Export, о чем свидетельствует команда

Get-ManagementRoleEntry “*Import-Mailbox”

При этом данная роль связана только с группой Organization Management, у которой есть право лишь делегирования. Выяснили мы это при помощи команды:

Get-ManagementRoleAssignment -Role «Mailbox Import Export» | fl Identity

В результате, подключившись к серверу Exchange из под учетной записи, входящей в группу ролей Organization Management, мы можем делегировать выполнение необходимых командлетов по крайней мере двумя способами:

• Связать пользователя непосредственно с ролью Mailbox Import Export, тем самым дав ему право выполнять командлеты, находящиеся в этой роли:

New-RoleAssignement -Role «Mailbox Import Export» -User User1

Как вы понимаете, это не совсем правильный подход к делегированию полномочий, т.к. со временем накопится столько связей, что вы в них попросту не разберетесь. Гораздо правильнее использовать другой подход:

• Создать группу ролей, например Remote Admins, включить в неё все роли, которые планируется делегировать сотрудникам и добавить сотрудников уже непосредственно в группу ролей. Делается это командой:

New-RoleGroup -Name «Remote Admins» -Roles «Mailbox Import Export» -Members User1

К командлету New-RoleGroup можно добавить такие параметры, как –DisplayName и –Description.

Теперь, если мы отправимся в Active Directory, то увидим, что у нас образовалась новая группа безопасности Remote Admins в OU Microsoft Exchange Security, членом которой стал User1.

Также членством в группах ролей RBAC легко управлять через Exchange Control Panel, как показано на рисунке 2.

Рис.2: Управление членством в группах RBAC при помощи ECP.

После того, как вы определились с тем, какие командлеты будет выполнять удаленный пользователь, можно для него включать само удаленное управление. Делается это присвоением параметру RemotePowerShellEnabled, учетной записи пользователя, значения True при помощи команды:

Set-User YourUser -RemotePowerShellEnabled $True

Активировав разрешение на удаленное подключение к PowerShell можно двигаться далее.

Управление через оснастку Exchange Management Console (EMC)

Начнем с простого, а именно с подключения к серверу Exchange через EMC. Наверняка каждый, кто хоть раз устанавливал сервер Exchange 2010, замечал, что в процессе выбора ролей можно выбрать для установки отдельно компонент Management Tools (Средства управления) (рис.3), собственно эта возможность и служит для того, чтобы инсталлировать оснастку управления Exchange на отдельный сервер или рабочую станцию.

Рис.3: Установка Exchange Management Tools.

Нужно иметь ввиду, что установить средства управления Exchange можно только на современные операционные системы, такие как:

• Windows 7
• Windows Vista с пакетом обновления 2 (SP2)
• Windows Server 2008 с пакетом обновления 2 (SP2)
• Windows Server 2008 R2

При этом ОС обязательно должна быть 64-х битной, т.к. сам Exchange 2010 существует только в 64-х битной редакции.

Средства управления можно установить и в автоматическом режиме при помощи команды

Setup.com /R:MT

Инсталлировав графическую консоль управления нужно её открыть и подключиться к удаленному серверу Exchange при помощи действия Добавить лес Exchange…, (см. рис. 4).

Рис.4: Подключение к серверу Exchange черeз EMC.

В поле адреса указываем либо имя сервера, либо URL расположения виртуального каталога PowerShell, на котором запущен Remote PowerShell и нажимаем кнопку ОК. В результате будет предпринята попытка подключиться по протоколу HTTP на 80-й порт указанного сервера, с использованием проверки подлинности на основе Kerberos.

После успешного подключения мы увидим классическую консоль управления сервером Exchange, точно такую же, какую можно запустить на самом сервере. При этом нужно понимать, что интерфейс будет меняться в зависимости от того, какой учетной записью вы пользуетесь для подключения, и соответственно в какие группы ролей RBAC входит эта учетная запись.

Одним из преимуществ удаленного использования Management Tools является то, что вы можете, подключив в одну консоль сразу несколько серверов, находящихся в разных лесах Active Directory, осуществлять перемещение почтовых ящиков между лесами, создав простой запрос на перемещение командой New Move Request.

На этом тему графической консоли управления закончим и далее поговорим про командную консоль (EMS) во второй части.

В этой статье мы покажем, как установить инструментарий управления Exchange Server 2016 Management Tools на компьютере с операционной системой Windows 10.

В Exchange Server 2016 по-умолчанию отсутствует установленная консоль управления EMS. EMS была заменена на веб-консоль EAC (Exchange Administration Center). Но так как многие задачи Exchange невозможно выполнить при помощи EAC, для полноценного управления сервером Exchange и ящиками через PowerShell нужно установить Exchange Management Tools.

Для того, чтобы все инструменты работали в операционной системе Microsoft Windows 10, необходимо предварительно установить несколько компонентов IIS. Быстрее всего это сделать при помощи PowerShell.

Запустите консоль PowerShell в Windows 10 с правами администратора и выполните такую команду:

Enable-WindowsOptionalFeature -Online -FeatureName "IIS-ManagementConsole", "IIS-LegacySnapIn", "IIS-IIS6ManagementCompatibility",IIS-Metabase" –All

После того, как команда выполниться необходимо перезагрузить компьютер.

После перезагрузки смонтируйте iso образ установочного диска с Exchange Server 2016 и запустите файл Setup.exe.

В списке устанавливаемых компонентов Exchange выберите единственную доступную опцию Management Tools.

Измените (если нужно) каталог установки модулей Exchange.

Запустится процесс установки.

После окончания установки можно запустить Exchange Management Shell (EMS) из стартового меню.

После этого на экране появиться консоль Exchange Management Shell. Теперь вы можете управлять серверами Exchange со своей рабочей станции.