top of page

​

Maintaining Exchange Server

​

В данном модуле мы рассмотрим дополнительные средства, утилиты и оснастки, которые существуют для управления Exchange 2010.

 

Начнём с интересного сервиса, который позволяет проверить работоспособность вашего Exchange извне. Например, вы хотите проверить Active Sync или Outlook Anywhere, т.е. вещи, которые требуют подключения снаружи. Зайдите на https://testconnectivity.microsoft.com/

Через этот сервис вы можете проверить входящую и исходящую почту, работу Active Sync, Outlook Anywhere, Autodiscover  и прочее.

​

Проверим работу входящей почты.

Меню изучения Exchange 2010

Выбираем Inbound SMTP Email. Нажимаем Next и на следующей странице указываем свой email. Нажимаем Perform Tets. 

​

Тест прошёл. Разберем принцип его работы.

Сервис обращается к DNS.

1. Был найден MX.

2. MX был разрешен в IP.

3. Тест того, что 25 порт открыт.

Командлеты Test-

Их очень много. Для просмотра командлетов для различных тестов выполните Get-Command test-*

Рассмотрим некоторые из них.

​

Test-OwaConnectivity Проверяет OWA. Он показывает, удается ли подключиться, если нет, то по какой причине. И самое главное, за какой период времени удалось подключиться. Вводим  Test-OwaConnectivity -URL:https://mail.contoso.com/owa -MailboxCredential:(get-credential contoso\kweku), подставив свой URL и домен\логин. В появившемся окне вводим пароль.

Test-MAPIConnectivity Проверяет подключение по MAPI к базам данных. Например, я хочу узнать, какие БД есть на сервере van-ex1 и в каком      

состоянии они находятся. Test-MAPIConnectivity -Server van-ex1 После можете размонтировать одну из баз и снова проверить подключение. Как

видим на скриншоте база Accounting теперь недоступна.

Test-MailFlow Проверяет, проходит ли почта из точки А и точку В. Например, у вас 10 серверов и вы хотите понять, ходит ли почта между двумя конкретными серверами или двумя конкретными адресами и за какое время. Также можно проверить, дойдёт ли почта на какой-то внешний адрес и за какое время. Test-MailFlow van-ex1 -TargetEmailAddress administrator@adatum.com Этой командой мы проверяем прохождение почты с сервера van-ex1 на ящик administrator@adatum.com. Как видим доставка осуществляется за 2 секунды. Самое интересное, что юзеру administrator@adatum.com

действительно придёт письмо "Это тестовое письмо".

Утилита eseutil

Использовать её лучше из командной строки. 

С помощью Eseutil можно выполнить дефрагментацию БД для уменьшения её объема (база росла, вы переместили/удалили юзеров, а объем базы не меняется). Eseutil также позволяет проверять БД на целостность, ремонтировать БД в случае повреждений, проигрывать трансзакционные логи и прочее.

Выполнив команду eseutil, посмотрим справку.

Рассмотрим конкретные примеры.

Проверим БД на целостность. Выполняем eseutil /g "путь к базе". Ключ /g соответствует операции Integrity (Целостность), что видно из справки. Если база у вас активна, вы получите отказ при проверке целостности. Утилита eseutil может работать с БД, только если БД в размонтированном состоянии, т.к. требуется полный доступ к файлу базы. Поэтому работа eseutil и работа пользователей в один момент не совместимы.

Размонтируем БД через EMS и вернемся в командную строку для работы с eseutil.

Запускаем проверку целостности, указав путь к БД. На выходе получаем "Integrity check successful", что говорит нам о том, что целостность базы верна. 

Следующий пример. Предположим БД упала. Попытаемся её восстановить. eseutil /p "Путь к БД"

При старте операции восстановления будет показано предупреждающее сообщение. Дело в том, у eseutil при работе с БД нет понятия "почтовый ящик". Поэтому если есть проблемы с БД и eseutil пытается её восстановить, вполне возможна потеря части ящиков или почты. Поэтому прежде чем пользоваться eseutil, убедитесь, что у вас есть бэкап.

​

Следующий пример. Дефрагментация базы. eseutil /d "Путь к БД" После операции БД уменьшится в размере.

​

Есть ещё некоторые фишки, например, eseutil /mh "Путь к БД", которая позволяет снять подробную статистику по БД. Например, у БД есть понятие  

State, т.е. состояние. В нашем примере это состояние Clean Shutdown, что означает, что БД была выключена нормально. Также может быть состояние Dirty ShutDown (грязное выключение), что говорит о том, что база была отключена не корректно. В таком случае смонтировать БД вы не сможете. Сначала потребуется её восстановление.

Командлет New-MailboxRepairRequest.

В ранних версиях в командной строке была доступна утилита isinteg. Она дополняла утилиту eseutil. Isinteg помогала в следующих случаях:

- юзер заходит в п/я, видит 10 писем в папке "Входящие", а ему говорится, что там 20 писем;

- юзер видит, что письмо с вложением, но вложения нет.

Утилита isinteg с выходом Exchange 2001 SP1 была упразднена. В командной строке она есть (вероятно для совместимости), но в современных системах не применяется. Вместо неё теперь используется PowerShell командлет New-MailboxRepairRequest. С примерами можно ознакомится на Technet. 

​

В этом примере обнаруживаются и исправляются все представления папок для почтового ящика tony@contoso.com.

New-MailboxRepairRequest -Mailbox tony@contoso.com -CorruptionType FolderView

​

В этом примере выявляются, но не устраняются повреждения типов ProvisionedFolder и SearchFolder в почтовом ящике пользователя "Ayla Kol". Эта команда не выполняет восстановление почтового ящика (Полезно, когда в ящике не работает поиск).

New-MailboxRepairRequest -Mailbox ayla -CorruptionType ProvisionedFolder,SearchFolder -DetectOnly

​

В этом примере выявляются и устраняются повреждения типа AggregateCounts во всех почтовых ящиках в базе данных на сервере MBX-DB01 (AggregateCounts - это счётчики, которые показывают сколько писем в папке. В описании isinteg я упоминал проблему с неверным отображением количества писем. Поэтому если у вас существует такая проблема, можно воспользоваться данным примером).

New-MailboxRepairRequest -Database MBX-DB01 -CorruptionType AggregateCounts

​

В этом примере выявляются и устраняются все типы повреждений в основном и архивном почтовых ящиках пользователя "Ayla Kol".

New-MailboxRepairRequest -Mailbox ayla -CorruptionType ProvisionedFolder,SearchFolder,AggregateCounts,Folderview -Archive

​

Best Practices Analyzer.

У Microsoft существует представление, как должен выглядеть правильно сконфигурированный Exchange. Это представление регулярно обновляется через службу Windows Update. BPA пробегается по вашей конфигурации, сравнивает её с представлением MS и сообщает вам отличия. 

BPA находится в разделе Toolbox. Запустим его.

Запустим новый скан.

Указываем какой КД будет использоваться для получения информации по конфигурации.

Нажимаем "Connect to the AD server". Происходит подключение к КД.

1. Указываем имя проверки (любое).

2. Указываем, какие серверы будут проверяться

3. Указываем тип теста. Health Check (проверка здоровья) - проверка функциональности сервера и его конфигурации согласно рекомендациям.

Смотрим отчет.

В отчете используется три цвета.

Красный - это ошибки, т.е. ситуацию надо исправлять.

Желтый - предупреждение.

Синий - всё нормально, но обратить внимание стоит.

Что пишет Exchange в нашем примере?

В нашей конфигурации AD есть два сайта - сайт по умолчанию и Site2. BPA говорит, что в Site2 нет ни одного КД. Это не нормально, т.к. MS не поддерживает сайты без контроллеров.

BPA говорит, что в БД "Mailbox Database 1" 18 ящиков, но БД не бэкапилась ни разу.

Посмотрим на предупреждения, перейдя на вкладку All issues.

Например, Filter Pack не установлен (Filter Pack используется для посика по вложениям).

Или SSL не включен на корневой директории IIS (с точки зрения безопасности это неправильно).

Сетевой интерфейс имеет древние драйвера.

Размер лога приложения = 1 Мб. MS рекомендует для Exchange-серверов делать как минимум 40.

В сети только один глобал каталог, что является неправильным.

На вкладке Information Items можно посмотреть информацию о вашей конфигурации: сколько памяти, процессоров и прочее.

Помимо проверки Health Check, в BPA можно воспользоваться и другими типами проверки. Например, baseline, который показывает только производительность. Connectivity Test подключается к каждому серверу и смотрит всё ли у него запущено.

​

Message tracking.

Message tracking - это логи, которые позволяют узнать, отправлял ли Петя Васе письмо, когда и чем закончилось.

Message tracking на сегодня доступен только через ECP. Зайдите в Mail Control на вкладку Delivery Reports. Здесь вы можете указать п/я для поиска и кому или от кого он писал/получал почту. Можно искать по теме письма. 

В общем весьма полезная и удобная штука.

Troubleshooting.

Рассмотрим несколько проблем и их решение.

1. БД размонтирована.

Пробуем примонтировать, не получается. Выдает ошибку. По кодам ошибок заниматься проблематично. Поэтому, для начала, выполняем Test-ServiceHealth и проверяем, запущена ли служба, отвечающая за работу баз данных (Microsoft Exchange Information Store, на вкладке Service отображается как MSExchangeIS). Если эта служба остановлена, ни одну БД мы не смонтируем. Предположим, службы запущены. Может быть интересная проблема. Если Exchange у вас виртуальный, может возникнуть проблема с БД, если в виртуалке Startup RAM указан не кратно 1024. Динамическая память при этом работает без проблем. Вполне возможно этот баг уже исправлен, но такой случай имел место быть. Поэтому возьмите на заметку. Здесь можно ознакомиться подробней https://www.youtube.com/watch?v=7CFL6-S7qOs&index=16&list=PLI8lqhYmSpWfvkTnzj8MTtkrulX5TvFGH (c 31:35). Если это не наш случай, смотрим, а есть ли файлы базы данных. Проверяем есть ли место в файлах базы. Посмотреть, доступен ли КД (если AD отвалится, база размонтируется следом). Если всё в порядке, но БД всё равно не монтируется, пора переходить к eseutil. Если не поможет и eseutil, тогда спасет только бэкап.

2. Пользователи Outlook (полноценного) не могут подключиться к системе.

Вероятно проблема с CAS. Проверяйте службы. Проверяйте AD и DNS, возможно что-то с DNS именем CAS.

Есть утилита RPC Ping. В отличии от обычного пинга, посылаются не эхо запросы, а проверяется доступность хоста по RPC портам.  

3. Юзеры жалуются, что почта для внешних получателей либо совсем не доходит, либо очень медленно.

Исходящий канал очень слабый. Exchange не успевает отправлять почту. Канал то упал, то поднялся. Почта начинает копиться в очереди. Что успело - то дошло (хоть и медленно), а что не успело - отвалилось по тайм-ауту (и будет присылаться NDR). Надо понять, вся ли почта так ходит, либо на конкретный домен. Если только на конкретный домен, то:

- у получателей включен gray listing;

- у получателей проблемы с каналом;

- вы засветились в RBL (Realtime Blocking List), а получатель его использует, поэтому вас и рубит.

Реальный случай: вы используете Gray Listing. Отправляете почту наружу на Unix-сервер, на котором стоит интересный антиспам, который не примет почту от вас, пока не обратится к вам и не скажет: "Примите почту на адрес пользователя, которым вы нам представляетесь". Т.е. вы должны сначала подтвердить, что такой юзер у вас есть. Но вы то используете  Gray Listing. Поэтому временно блокируете почтовые сообщения от этого Unix-сервера. В итоге, все друг друга блочат и остаются не у дел.

Итого, при проблемах с доставкой почты наружу вам будут нужны: просмоторщик  очередей, данные NDR'ов, SMTP-лог на отправку (или на получение) и прочее. 

С переходом со старых версий на Exchange 2010 можно ознакомиться здесь.

Новые возможности Exchange Server 2013: https://www.youtube.com/watch?v=hDG5U05GY94

Меню изучения Exchange 2010

bottom of page