top of page

Внедрение Exchange 2010.

          Ниже в подробностях рассматривается установка и управление Exchange Server 2010. Подробности состоят в описании взаимодействия между AD и Exchange, назначения ролей Exchange и управление ими. Если вам всего этого не надо, а главной задачей является простая установка Exchange с описанием основного функционала, вы можете ознакомиться с кратким часовым курсом "Exchange Server 2010: Быстрый старт", которого вполне хватит для базового понимания работы Exchange. К тому же сам процесс установки в своих статьях я не рассматриваю и ссылаюсь на это видео. Поэтому рекомендую посмотреть его прежде, чем приступить к изучению подробных статей. 

          На авторство не претендую. По большему счёту, всё описанное мной, это текстовая трансляция курса, найденного на Youtube.com. Что-то я добавил от себя, но большинство взял оттуда. 

Ссылка на подробный курс https://www.youtube.com/watch?v=fd1exvvTnB0&index=1&list=PLI8lqhYmSpWfvkTnzj8MTtkrulX5TvFGH

Exchange Server 2010: Быстрый старт.

https://www.youtube.com/watch?v=OBEn2wQICM0

Заметки к ролику:

- подготавливайте схему и проводите установку под одной учёткой. После установки, если будете логиниться под другой, будут проблемы с правами. Новую учетку надо добавлять в группы Exchange в AD;

- Configure Client Access server external domain. На этапе установке вас спросят имя, по которому ваши пользователи смогут обращаться к вашему почтовому серверу из сети Интернет (имя сервера Client Access снаружи). Client Access это сервер, к которому подключаются ваши клиенты (неважно, снаружи или изнутри). Снаружи это имя будет другое. Например внутри, Client Access имя будет типа Exchange.adatum.local, а снаружи к нему будут подключаться как к  mail.adatum.ru. Соответственно, если на этапе установки вы знаете по какому имени он будет доступен снаружи (обычно mail.имя_вашего_домена), то можете смело это имя указывать в процессе установки. Если не знаете, можете пропустить этот момент. Разница в том, что когда вы указываете внешнее имя Client Access, то мастер установки пропишет это имя во всех необходимых настройках. Если не указываете, пробегаетесь после установки вручную.

Active Directory.

Файл AD - это файл ntds.dit. Он содержит разделы AD.

На любом КД его можно найти в C:\Windows\NTDS

Файл один, но разделов в нём несколько:

Разделы также могут называться Контекстные именования (Naming Context).

В разделе Domain хранится инфа об объектах конкретного домена, т.е. пользователях, OU и прочее.

Раздел Domain реплицируется или синхронизируется только между контроллерами, которые входят в один домен AD. Т.е. репликация за пределы домена не выходит.

Раздел Configuration хранит конфигурацию AD. В этом разделе можно увидеть: сколько у нас сайтов, какие КД за каким сайтом закреплены, как сайты между собой связываются, сколько у нас доменов в лесу и прочее.

Раздел Configuration един на весь лес. Репликация этого раздела осуществляется между всеми контроллерами леса.

 

Раздел Schema хранит инфу о том, какие объекты AD вы можете создать и как они будут выглядеть. Т.е. на какой бы КД вы не зашли и какой бы объект не создали, объект будет выглядеть одинаково. Т.е. при создании объекта, набор атрибутов будет один и тот же.  Создание объектов происходит согласно схеме.

В лесу один раздел Schema и реплицируется он между всеми КД. 

 

Раздел Application. Их два - Forest DNS и Domain DNS. Когда мы разворачиваем AD и создаем DNS в AD (а не в текстовом файле), в разделе Forest DNS хранится одна зона, в Domain DNS другая.

К Exchange этот раздел отношения не имеет.  

     Посмотреть разделы AD можно

     через ADSIEDIT.msc

     ПКМ на ADSI Edit -> Connect To

В поле Naming Context указываем раздел, который хотим посмотреть:

Default naming context это и есть раздел Domain, раздел Application отсюда не подключается, RootDSE это не раздел.

Выбираем раздел, жмём Ок. По-умолчанию идёт подключение к КД, на котором запущена оснастка. Можно указать другой сервер.

Зачем я всё это написал выше? 

Затем, что, глядя на схему ниже, можно понять, как Exchange пересекается с AD.

 

 

     Forest. Выше леса в домене ничего нет. В Exchange также существует архитектурная единица, выше которой ничего нет. Называется она Exchange organization (Организация Exchange). Exchange organization это один и более серверов, использующих общую конфигурацию. Общая конфигурация не означает, что у нас несколько серверов зеркально настроены. Это значит, что эти сервера используют параметры, которые применяются для всей организации. Т.е. в Exchange есть ряд параметров, которые применяются либо для всей организации, либо не для кого (наподобие групповой политики, применяющейся для всех или не для кого).  Можно обозвать это набором параметров уровня организации, так называемый Config. В Config входит различная информация, например, какие почтовые домены обслуживает ваша организация. Т.е. если в одной организации у вас этот список общий, то нельзя сказать, что один сервер отправляет почту в microsoft.com, а другой нет.  Есть ряд параметров касательно транспорта на уровне организации, например, какой максимальный размер письма вы можете передать. Итого, Exchange organization это несколько серверов у которых Config общий. В лесу только одна Exchange organization. Хотите ещё одну организацию - вам нужен другой лес AD. 

     Schema. Exchange  модифицирует схему. Зачем? Во-первых, он хранит свой Config в AD, а чтобы хранить Config в AD ему нужно создавать объекты. Создать объекты мы можем только те, которые описаны в схеме. Изначально в AD не описаны объекты, которые нужны Exchange. Пример. По-умолчанию, у пользователя есть набор атрибутов, эти атрибуты отражены в схеме. При установке Exchange использует кучу дополнительной информации. Эти атрибуты, которые он хочет впихнуть в пользователя, отсутствуют в схеме. Поэтому ему и нужно модифицировать схему. Т.е. чтобы можно было создавать новые объекты, а к существующим объектам добавить дополнительные атрибуты.

Exchange  серверы модифицируют схему по разному. Установка 2003 - это одна модификация, 2007 - другая, 2010 - другая. Вплоть до обновления ServicePack. Итого,  обновление схемы должно производится той версией дистрибутива, который вы будете устанавливать Exchange в дальнейшем.

     Configuration. Exchange всё, за исключением содержимого почтовых ящиков, общих папок, текстовых логов и сертификатов, хранит в AD в разделе Configuration. Проще говоря, когда вы устанавливаете организацию Exchange, у вас в разделе Configuration создается отдельная ветка с именем вашей организации, куда Exchange пихает свою конфигурацию. Т.е., по сути, когда у вас падает Exchange, можно просто поднять новый и сказать: "Возьми конфиг из AD". А базы поднимать уже из бэкапа. Итого, открыв раздел Configuration мы увидим всю информацию: сколько серверов, какой сервер за что отвечает, сколько баз данных, какая БД на каком сервере, за какие почтовые домены вы отвечаете и прочее. Т.е. можно не открывать оснастку Exchange, в разделе Configuration всё есть. Только не так удобно для просмотра. 

     Domain. После того как вы установите Exchange и добавите пользователю почтовый ящик, у него в объекте начинает храниться куча дополнительной инфы. Например, на каком сервере хранится его почтовый ящик, электронные адреса пользователя, параметры ПЯ (например, размер квот). Итого, куча инфы, которая относится к конкретному почтовому ящику, храниться не в разделе Configuration (какой смысл гонять инфу?), а хранится вместе с пользователем. Т.е. после создания ПЯ у пользователя появляется набор атрибутов, хранящих Exchange инфу. Ящика нет - атрибутов нет, ящик появился - есть.

Для примера посмотрите разделы AD.

     Domain. Для примера возьмем учетку Administrator, для которого уже создан почтовый ящик. На скриншоте видно, что у юзера появились дополнительные атрибуты для Exchange.

Если у юзера нет разделов, связанных с Exchange, значит Exchange не установлен. Если атрибуты есть, но значение атрибутов не установлено, значит ПЯ для юзера не создан.

Configuration. Здесь можно посмотреть на конфиг Exchange. 

Например, можно узнать сколько у нас БД. В свойствах каждой БД можно узнать, где она расположена.

     Schema. Тут особо смотреть нечего. Просто важно понимать, что если классы и объекты типа CN=ms-Exch-..... отсутствуют, значит схема не обновлялась.

     Global Catalog. GC обязательно должен быть доступен для Exchange сервера, т.к. Exchange активно его использует. Пример, Вася написал письмо Пете. Exchange должен понять, существует ли Петя в нашей организации или это внешний пользователь. Если существует, то где? Где находится его ПЯ, на каком Exchange сервере, и где, на каком сайте, находится этот Exchange сервер. Взять всю эту инфу можно только в AD. Если просто пойти на КД, эта инфа будет неполной, т.к. КД знает инфу только о своем домене. Т.к. Exchange устанавливается на всю организацию, т.е. на весь лес, то надо опрашивать либо каждый КД (вернее по одному КД в каждом домене), либо идти на GC, который знает всё. Поэтому Exchange в большинстве случаев идёт на КД, обладающий ролью GC. Если GC недоступен, все службы отвалятся и почта работать не будет.  

Требования к установке Exchange 2010.

     Exchange 2010 требует, чтобы режим работы леса и домена был не ниже Win Server 2003. Т.е. у вас на КД не должно быть ОС моложе Win Server 2003 SP2.

     В обязательном порядке проверяйте, что режим работы леса и домена подходящий. Как это проверить здесь.

Требования к DNS.

Если вы будете осуществлять переписку только внутри вашей организации, никаких особых настроек DNS не требуется.

Если вы планируете отправлять и получать почту снаружи, нужно настраивать DNS.

Настройка DNS записей.

     Правка внешней зоны (если у вас внутренний домен adatum.local и внешний adatum.ru, вы правите adatum.ru, т.е. тот, который доступен снаружи).

     Итак, мы купили доменное имя. Первое, что нужно добавить - это запись типа A. Например, mail.itshnosti.ru, которая разрешается в ваш внешний IP-адрес. С этого внешнего IP, 25 порт должен попадать на ваш Exchange.  

Затем добавляем MX-запись и указываем, что эта запись MX расшифровывается в запись типа A, которую мы создали ранее. 

MX-запись во внешней зоне говорит другим серверам, куда нужно отправлять почту для определенного домена.

Пример: я почтовый сервер и мой пользователь прислал мне письмо, которое предназначается для ящика в домене specialist.ru. Я обращаюсь к DNS серверу, чтобы тот вернул мне MX-запись для домена specialist.ru. DNS сервер пытается найти эту MX-запись и возвращает мне её. Я запрашиваю разрешение имени хоста, который указывается в MX-записи, в IP-адрес. Мне разрешается и по этому IP я устанавливаю соединение.  

     Конкретный пример: через командную строку выполняем nslookup. Указываем set q=mx (т.е. возвращать только mx-записи).  И указываем домен specialist.ru. DNS возвращает 4 записи.

  Эти 4 записи означают, что если кто-то попытается доставить почту в домен specialist.ru, он сделает это путем установки соединения с одним из перечисленных серверов, у которого меньше метрика (preference). Но таких три. К какому из них будет обращение? В DNS есть технология Round Robin: когда есть несколько записей на одно имя, DNS первому клиенту возвращает записи в одном

порядке, а второму в другом. Т.е. меняется порядок записей. Для примера создадим в DNS две записи с одинаковым именем test и двумя разными IP 1.1.1.1 и 2.2.2.2. 

А затем через nslookup просим разрешить запись test. 

Видите? IP в записях меняются местами.

Тоже самое будет и с предыдущим запросом к specialist.ru. Записи будут постоянно перетасовываться.

     Подводим итог. MX-запись нужна, чтобы до вас могли достучаться снаружи. MX-запись не отменяет того, что у вас должен быть открыт 25 порт, который будет пробрасываться на ваш Exchange-сервер. Т.е. без MX-записи просто неизвестно, куда нужно идти. 

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

     PTR-запись. Это реверс запись, когда IP разрешается в имя. Эта запись нужна, чтобы без проблем почту принимали от вас. Одна из проверок на антиспам - это просмотр обратной записи, точнее её наличие.

Итого, вы знаете свое имя (к примеру mail.adatum.ru), вы знаете свой внешний IP. Вам нужно добавить запись, которая ваш внешний IP разрешит в ваше имя. Для этого идём к провайдеру, который предоставляет вам доступ в интернет (т.к. IP зарегистрирован на него, соответственно у него обратная зона).

     SPF-запись. В почтовой системе есть проблема - любой желающий может отправить письмо от имени любого домена. В рамках интернета никакой аутентификации у почты нет, поэтому как представился, так тебя и приняли. Если вы не хотите, чтобы кто-то представлялся вашим именем, нужно как минимум добавить SPF-запись. SPF-запись добавляется в свою внешнюю зону. Эта запись говорит о том, какие сервера имеют право отправлять почту от имени вашего домена. Т.е. если SPF-запись находится в зоне adatum.ru, следовательно она содержит инфу о том, кто имеет право рассылать почту от имени adatum.ru. Если кто-то попытается отправить почту от вашего имени, проверяющая сторона полезет в DNS, запросит SPF-запись, возьмет её и проверит. Если в записи есть разночтения с тем, кто отправляет почту с вашего домена, отправитель будет послан.   

Требования к AD.

     При установке Exchange подготовка AD идёт в автоматическом режиме. Но можно подготовить AD вручную. Т.е. мы не устанавливаем Exchange сразу , а с помощью дистрибутива Exchange выполняем все подготовительные процедуры. А уже после устанавливаем  Exchange. Зачем это? Дело в том, что в случае каких-то проблем, будет проблематично откатить схему AD. Поэтому лучше подготавливать схему отдельно от установки. В самом верху страницы есть ссылка на видео по подготовке и установке Exchange. 

     Для проверки успешной подготовки схемы ознакомьтесь со статьей "Подробное рассмотрение подготовки Active Directory для Exchange 2007" (Легко гуглится).

Роли Exchange.

     Mailbox Server Role. Отвечает за обеспечение работы баз данных Exchange. В Exchange есть БД двух видов: БД, где хранятся почтовые ящики и БД, где хранятся общие папки. Mailbox Server Role отвечает за обслуживание баз данных конкретного сервера. Задача Mailbox Server Role сделать так, чтобы эти БД были смонтированы, чтобы они работали, чтобы они принимали подключения. Также в задачи Mailbox Server Role входит обслуживание БД. Т.е. если вы тушите Mailbox сервер, у вас ни одна БД не доступна. Соответственно подключаться не к чему. И принять письмо некуда, и зайти некуда (почтовый ящик), и написать некуда.

Рассмотрим ситуацию. У нас есть сервер, на который установлена только роль Mailbox Server Role. Создаем почтовый ящик (это можно сделать, даже если установлена только одна роль Mailbox Server Role) и хотим к нему подключиться. Но архитектура Exchange 2010 такова, что любой вариант подключения к почтовому ящику осуществляется через роль Client Access Server Role. Т.е. как бы пользователь не пытался подключиться к ящику (через телефон, через web access, по MAPI и прочее), он всегда будет коннектиться к серверу с ролью клиентского доступа (Client Access Server Role). 

     Client Access Server Role - роль сервера, которая принимает все клиентские подключения. После приема CAS аутентифицирует клиента и обращается к  Mailbox серверу, где находится почтовый ящик клиента. Т.е. если нет CAS  даже при работающем Mailbox, вы ничего не сделаете.

     Hub Transport Server Role отвечает за маршрутизацию почты. Даже если у вас есть CAS и Mailbox, но нет Hub Transport, письмо вы отправить не сможете. Вы сможете зайти на веб-морду, войти в ящик, увидеть папки и прочее. Но отправлять почту не сможете. По-умолчанию HTS отвечает за маршрутизацию почты внутри организации. При желании, он будет отвечать и за  маршрутизацию почты за пределы организации. Итого, при отсутствии HTS вы не напишите письмо даже самому себе. Так что, любое отправляемое вами письмо проходит как минимум через один HTS сервер. 

     Edge Transport Server Role - эта роль выносится в демилитаризованную зону. Edge это типа такой Frontend, который стоит в dmz. Основные отличия Edge от всех остальных ролей:

1. Он не требует наличия Active Directory. Т.е. его можно поставить на сервер, который не является членом домена.

2. Он не сочетается ни с одной из других ролей. Т.е. если вы ставите на сервер роль Edge, поставить CAS, MBX или Hub вы в принципе не сможете.

Задача Edge простая. Он сидит в DMZ и принимает почту из интернета, фильтруя на спам, вирусы (при наличии антивируса) и прокидывает внутрь организации на  Hub Transport Server. Итого цепочка следующая: Сервер в интернете -> Edge -> Hub -> Mailbox.Соответственно, если мы пишем в интернет, то Mailbox ->  Hub -> Edge ->  Сервер в интернете. Набор портов, который вы будете открывать из dmz во внутреннюю сеть будет минимальным. 25 порт, 53 (разрешение имен) и 50636 (для синхронизации с Hub).

     Unified Messaging Server Role. Это интеграция телефонии и почтовой системы. Вы можете дозвониться до почтового ящика. Он прочитает сколько сообщений не прочитано, также можно прочитать письмо от конкретного пользователя (он вам его зачитает), вы надиктуете ответ и т.д. Также есть интеграция факсов, автоответчиков и прочее.Unified редко используется в РФ, большинство функционала недоступно на русском языке (языковых пакетов нет).

     Итого. Три роли CAS, MBX, Hub - это обязательный функционал. Остальные две роли по желанию.

Роли могут быть совмещены на одном сервере или разнесены по разным серверам. CAS, MBX, Hub и Unified можно поставить на один сервер, Edge всегда будет отдельно.

     Схем организации серверов и ролей на них может быть несколько. Один из хороших подходов - два сервера с ролями CAS и Hub и два сервера с ролью  MBX, работающих в кластере.

Рекомендации к аппаратным требованиям для сервера, сочетающего все роли.

Если сервер Exchange сочетает все роли, то рекомендуемый вариант это 8 ядер. Более важный показатель это память. 8 Gb ОЗУ вы берете только за наличие Exchange и в среднем 5 Mb на каждый почтовый ящик.

Есть такая особенность, что ресурсы будут отдаваться пользователю, а не управлению Exchange. Т.е. вы можете наблюдать нормальную работу пользователя (например через Web access), а в это же время консоль управления  Exchange у вас дико тормозит или вообще висит. Так что не жалейте ресурсов под Exchange. Особенно любят останавливаться службы, когда начинает не хватать памяти. 

Аппаратные требования к серверу, на который будет ставиться Exchange.

Exchange 2010 только 64 битный, поэтому процессоры только 64.  

ОС либо 2008 либо 2008 R2.

Процесс установки Exchange 2010.

Подробно об установке и предварительной подготовке Exchange 2010 посмотрите видео:

https://www.youtube.com/watch?v=OBEn2wQICM0

Очень просто и подробно всё расписано.

Вверху страницы я снабдил это видео своими заметками.

      После установки проверьте работу служб. Через Exchange Management Shell запускаем команду Test-ServiceHealth. Вы получите список ролей, установленных на конкретном сервере, список служб, которые нужны для этих ролей и в каком состоянии они находятся (кратко это описано в видео). Если статус везде True, значит всё хорошо. 

     Для примера возьмем и остановим командой Stop-Service службу MSExchangeFBA и снова проверим работу служб командой Test-ServiceHealth. Как видим статус роли CAS теперь False и это нехорошо.

Запускаем службу командой 

Start-Service, проверяем Test-ServiceHealth. Статус True, всё хорошо.

     Если возникли сбои при установке, в C:\ExchangeSeturLogs есть текстовый файл ExchangeSeturLogs.log, в котором протоколируется вся процедура установки Exchange. Файл большой, поэтому можно просто воспользоваться поиском в блокноте, введя запрос [ERROR].

     После установки, по-умолчанию, создается почтовый ящик для пользователя, под которым вы устанавливали Exchange. Можно посмотреть, есть ли у пользователя ящик с помощью команды Get-Mailbox (например, для учетной записи Administrator вводим Get-Mailbox Administrator). 

     Создать ящик для существующего пользователя можно командой Enable-Mailbox (Enable-Mailbox i.ivanov). Если баз несколько, значит Exchange будет создавать ящик рандомно. При этом распределение будет равномерно между базами, т.е. если есть 2 базы и мы создаем 10 пользователей, Exchange 5 пользователей положит в одну, а 5 в другую (если для БД не стоит параметр "Исключить из распределения". Но это уже отдельная тема для разговора). 

     Итак, ящик у нас есть. Проверим его работу через Outlook Web Application (раньше он назывался Web Access). В браузере набираем https://mail.adatum.com/owa (собственно owa - это сокращение Outlook Web Application). Обязательно указывайте https, т.к. Exchange 2010 шифрует абсолютно все варианты подключений, в том числе и через owa. 

     Почему первое подключение долго происходит?  Так как вы подключаетесь через браузер, используется IIS. В IIS'е всё это выполняется в рамках пула приложений. А пул приложений по-умолчанию остановлен. Т.е. при первом подключении запускается пул приложений. Ещё один момент - рендеринг страницы в aspnet'овских серверах осуществляется в момент первого обращения.

Итак, подключаемся к ящику. Если мы сумели зайти и видим пустой ящик, это говорит о том, что роли CAS и Mailbox работают. Если бы БД, к примеру, была отмонтирована, мы бы зайти не смогли. Работу Hub можно проверить, отправив письмо самому себе.

После установки, если все тесты успешны, переходим в Exchange Management Console.

В зависимости от ваших задач выберите раздел слева. На что повлияют настройки: на всю организацию Exchange целиком, на какой-то сервер или на получателя. Например, вы хотите добавить почтовый домен. Он добавляется для всей организации целиком. Соответственно, делается это на уровне всей организации. Поэтому идём в Organization Configuration. Или, например, вы хотите поменять URL, при работе с owa. Это делается на конкретном сервере, а точнее на CAS сервере. Поэтому идём в Server Configuration. Нужно создать п/я, удалить, переместить между БД - это всё блок Recipient Configuration.

В Toolbox собраны дополнительные оснастки для Exchange. Т.е. это не действия с Exchange, а просто средства дополнительного администрирования. 

     По факту, всё что делается в Exchange Management Console выполняется в PowerShell, а именно в Exchange Management Shell.

Для примера, создайте ящик или контакт. После того как действие осуществилось на экран выводится строчка PS, которая была выполнена (см.рисунок). Вы можете

скопировать этот скрипт,

отредактировать и вставить в EMS.

     Если вы измените у ящика параметр

(например, тыкните какую-нибудь галку

в свойствах), то Exchange вам никакой

скрипт не покажет.

      Но в Exchange 2010 есть командный

лог, который можно посмотреть в меню 

View -> View EMS Command Log. Command

Log (если он не отключен и ведётся)

протоколирует абсолютно все действия, которые осуществляются в процессе работы в оснастке (в рамках текущей сессии).

PowerShell

      Есть PowerShell и отдельно Exchange Management Shell. Разница лишь в том, что в PS зарегистрированы командлеты только для управления ОС, а в EMS зарегистрированы командлеты и для управления ОС и для управления Exchange. Проверить это легко. В EMS наберите команду get-MailContact и вы получите на экран список почтовых контактов, которые у вас есть. Наберите эту же команду в PowerShell и вы получите ошибку, что такого командлета нет. Вообще командлеты можно зарегистрировать, но смысла от этого никакого.

Командлет состоит из двух частей - глагол и существительное, т.е. что мы делаем и с чем мы делаем.

Если мы хотим получить какую-то информацию, мы используем командлет Get. К примеру Get-Mailbox, Get-ExchangeServer и т.д.

Если мы хотим что-то включить, используем Enable. К примеру Enable-Mailbox, т.е. мы включаем п/я для уже существующей учетной записи.

Если мы хотим что-то создать, используем New. Поэтому, к примеру, New-Mailbox создаст и учетную запись и п/я.

Start - запустить что-то, Stop - остановить, Disable - отключить, Remove - удалить.

Set - используется, когда для существующего объекта вы меняете какой-нибудь из параметров.

Чтобы определить нужные вам командлеты, например, для работы с Exchange используем Get-Command *ExchangeServer*. Эта команда выведет на экран командлеты, в которых встречается текст "ExchangeServer". В этом списке мы увидим, например, 

Get-ExchangeServer. Введём ее и получим список Exchange серверов, которые у нас есть.

Поработаем с конкретным сервером. Будем использовать Get-ExchangeServer с дополнительными ключами.

Вводим Get-ExchangeServer -Identity MyExchServ и получаем краткую информацию по нашему серверу с именем MyExchServ.

-Identity это ключ. Информации мало, поэтому вводим Get-ExchangeServer -Identity MyExchServ | Format-List и получаем подробную информацию по серверу MyExchServ. Символ | указывает, что с полученным объектом (в нашем случае мы получили сервер MyExchServ) нужно что-то сделать. Командлет Format-List берет все параметры объекта и выводит их списком.

Можно ввести Get-ExchangeServer | Format-List, который выведет подробную инфу по всем серверам списком. 

Можно ввести Get-ExchangeServer | Format-Table, который выведет подробную инфу по всем серверам таблицей. 

Введем Get-ExchangeServer | Format-Table FQDN -AutoSize и получим только параметр FQDN всех серверов в табличном виде. Т.е. в качестве столбца будет использоваться FQDN, а ключ -AutoSize используется, чтобы таблица не разъезжалась по ширине.

 Через запятую можно указывать несколько параметров. Например, Get-ExchangeServer | Format-Table FQDN,Site -AutoSize, где мы получим FQDN всех серверов и в каком сайте AD они работают.

Для закрепления понимания введите Get-Mailbox i.ivanov | format-list, который выведет вам подробную инфу о ящике Иванова. Можно ввести Get-Mailbox i.ivanov | format-table, но вам выведет только 4 стандартных столбца. Так что можете просто ввести 

Get-Mailbox i.ivanov и получите тоже самое.

Командлет get-help выдает справку по указанному командлету. Например, get-help New-Mailbox.  Удобно использовать get-help New-Mailbox -Examples, где будут выводится примеры использования New-Mailbox. Вместо get-help можно использовать man. Это алиас get-help. Результат вывода будет одинаковый.

Скрипты.

Сделать скрипт можно в обычном блокноте, сохранив его с расширением .ps1. Внимание! При выполнении скрипта нужно через cd зайти в каталог, где лежит скрипт и указать .\имя_скрипта.ps1. Обязательно указывать .\ Без этого работать не будет. Или указывайте полный путь к файлу.

Иногда возникают проблемы при выполнении каких-либо скриптов. PS ругается на цифровую подпись скриптов. Вам необходимо проверить политику Get-ExecutionPolicy. Это политика цифрового подписывания скриптов. При вводе Get-ExecutionPolicy выведет вам текущее значение этой политики:

AllSigned - все скрипты, выполняемые в этой ОС должны иметь цифровую подпись (нет подписи - скрипт работать не будет);

RemoteSigned - вы можете выполнять любые скрипты, за исключением тех, что храняться в интернете. Т.е. если вы полезете на какой-то сайт и выполнить с него скрипт, ничего не сработает;

AnRestricted - без ограничений.

Чтобы установить определенную политику, вводим Get-ExecutionPolicy и параметр. Например, Get-ExecutionPolicy RemoteSigned

Примеры фильтрации в PS.

Например у нас есть вывод команды Get-Mailbox. Мы хотим отфильтровать ящики по серверу, на котором они хранятся. 

Вариант1 использовать ключ -server: Get-Mailbox -server van-ex1.

Вариант2: Get-Mailbox | Where-Object {$_.ServerName -like "van-ex1"}

Where-Object выбирает все объекты, которые соответствуют определенным условиям. Условие заключено в фигурные скобки. В нашем случае проверяется параметр ServerName. Тот п/я, у которого параметр  ServerName равен (-like) van-ex1, будет выводиться на экран. -like - чувствительный регистр. Есть ещё -ilike - нечувствительный регистр.

Вариант1 будет выполняться быстрее. Но Вариант2 более гибок.  Здесь можно использовать различные комбинации: "и", "или" и прочее. 

Различные примеры.

Get-User | Where-Object {$_.distinguishedname -ilike "*ou=sales,dc=contoso,dc=com"} | Enable-Mailbox -database "Mailbox Database 1"

Команда Get-User выводит на экран список пользователей. UserMailbox в выводе означает, что пользователь имеет почтовый ящик, просто user - не имеет.

distinguishedname - это параметр, который отображает имя и расположение объекта в AD. Посмотреть его можно в ADUC.

Обязательно в меню указывайте Advanced Features, т.к. без этого вы не увидите вкладку Attribute Editor у объекта.

Для ускорения поиска параметра отфильтруйте фильтр (показать только те, которые имеют значения).

Кстати, не путайте CN (контейнер) и OU. Это разные вещи. Первый CN это common name (собственно имя объекта), остальные CN это контейнеры. Вместо контейнеров могут быть OU.

Возвращаемся к нашему скрипту. {$_.distinguishedname -ilike "*ou=sales,dc=contoso,dc=com"} говорит, что сортировка Where-Object  будет затрагивать всех, кто находится в OU sales (в том числе во вложенных OU, которые находятся в OU sales (обратите внимание на *)). -like - это равно (только нечувствительный регистр). Далее, для выбранных объектов, будет создавать п/я в базе данных Mailbox Database 1.

Внимание! Этот скрипт может выполниться с ошибкой (или частично с ошибкой), если у юзеров уже есть п/я, т.к. Get-User не проверяет наличие п/я, соответственно на тех, у кого п/я уже есть, она начнет ругаться.

Следующие примеры.

Get-DistributionGroup "RemoteUsers" | Get-DistributionGroupMember | Set-Mailbox -MaxReceiveSize 10Mb

Берем группу рассылки RemoteUsers. Берём всех членов этой группы. Для каждого из членов группы устанавливаем максимальный размер принимаемого письма в 10 Мб. 

Get-Mailbox -server NYC-ex1 | New-MoveRequest -Local -targetDatabase "Mailbox Database 2"

Берем ящики с сервера NYC-ex1 и перемещаем их в базу данных Mailbox Database 2. New-MoveRequest с параметром -Local - это значит перемещение п/я в рамках вашей организации с одной базы на другую.

Get-Message -Filter {FromAddress -like "Tom*"} | Remove-Message

Get-Message - это получить письма в очереди сообщений. Т.е. кто-то написал письмо, оно ещё не отправлено и находится в очереди сообщений. Итак, Tom понаписал письма и они висят в очереди. Этим скриптом можно их удалить.

Переходите к следующей странице: Mailbox Server.

bottom of page