Где хранятся лог файлы exchange 2013

Обновлено: 06.07.2024

27.10.2021

Exchange, PowerShell

Один комментарий

После развертывания Exchange вы можете заметить, что свободное место на дисках начинает очень быстро уменьшаться. Помимо роста самых почтовых баз данных, в Exchange очень много место съедают различные логи. Особенно сильно проблема большого размера логов актуальна для версий, начиная с Exchange 2013. Если не использовать механизмы очистки логов, очень часто бывают случаи, когда почтовые базы аварийно отмонтируются и почтовый сервис становится недоступным для пользователей (часто сопровождается ошибкой 4.3.1 Insufficient system resources) из-за того, что логи Exchange заняли все свободное место на диске. В этой статье мы рассмотрим несколько стратегий очистки (усечения) и перемещения лог файлов в Exchange Server 2013/2016/2019.

Транзакционные логи в Exchange

Транзакционные логи баз данных это важный элемент в Exchange Server. При отправке/получении любого письма Exchange сначала вносит информацию в транзакционный лог, и только потом сохраняет элемент непосредственно в базу данных. Транзакционные логи содержат все операции, которые выполняются с базой данных и крайне важны для ее восстановления. Размер одного лог файла 1 Мб. Таких файлов может быть очень много, их количество зависит от активности пользователей в базе данных.

Есть несколько способов очистки транзакционных логов:

Логи базы данных очередей в Exchange 2013/2016/2019

Очистка транспортных логов Exchange

Вы можете проверить включены ли транспортные логи на вашем сервере и пути к ним с помощью следующих команд PowerShell:

Get-TransportService -Identity meskexch1 | fl *logpath*
Get-TransportService -Identity meskexch1| fl *logenabled*

Основные транспортные логи Microsoft Exchange Server по умолчанию хранятся в каталогах:

%ExchangeInstallPath%TransportRoles\Logs\Hub\Connectivity

%ExchangeInstallPath%TransportRoles\Logs\MessageTracking (используется при отслеживании писем через Get-MessageTrackingLog)

%ExchangeInstallPath%Logging\IRMLogs

%ExchangeInstallPath%TransportRoles\Logs\Hub\ActiveUsersStats

%ExchangeInstallPath%TransportRoles\Logs\Hub\ServerStats

%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive

%ExchangeInstallPath%TransportRoles\Logs\Hub\Routing

%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

%ExchangeInstallPath%TransportRoles\Logs\Hub\QueueViewer

%ExchangeInstallPath%TransportRoles\Logs\Hub\AgentLog

Можно изменить каталог для хранения SMTP логов отправки/получения (Protocollogs) через EAC: Servers -> servers -> выберите сервер -> Transport Logs -> Protocol log.

Если нужно изменить каталог хранения логов отслеживания Message Tracking, измените значение в поле Message Tracking log path в EAC.

Останется только изменить путь к каталогу с логами с помощью командлета:

Set-TransportService meskexch1 –ReceiveProtocolLogPath “D:\ReceiveSMTPLosg”

Таким образом вы можете хранить любые другие транспортные логи в сетевой папке на удаленном сервере.

Ротация и удаление IIS логов в Exchange

В логах IIS накапливается информация о подключениях к почтовым ящикам Exchange через OWA и ActiveSync. Со временем логи IIS, генерируемые пользователями при доступе к Exchange, могут занимать довольно много места.

Вы можете автоматически удалять старые логи IIS. Можно сделать автоматическое задание в планировщике Windows, которое запускается каждый день и удаляет логи IIS старше 30 дней:
set-location c:\inetpub\logs\LogFiles\W3SVC1\
foreach ($File in get-childitem) if ($File.LastWriteTime -lt (Get-Date).AddDays(-30)) del $File
>
>

Осталось создать новое задание в планировщике, которое должно запускать ваш PS1 скрипт очистки логов.

Чтобы Windows не блокировало запуск PowerShell скриптов, нужно изменить настройки политики PowerShell Execution, подписать PS1 файл или запускать его в планировщике с аргументами: powershell.exe -NoProfile -NoLogo -NonInteractive -ExecutionPolicy Bypass -File c:\ps\clear_iis_logs.ps1

Если вам нужны старые логи IIS для анализа и траблшутинга, вы можете перенести их на другой диск:

Также можно изменить путь к логам IIS через PowerShell:

Import-Module WebAdministration
Set-ItemProperty ‘IIS:\Sites\Default Web Site’ -name logfile.directory "F:\IISLogs"

Очистка папки Logging в Exchange

Большое количество логов различных служб хранятся в каталоге Logging (например, в Exchange 2013 это C:\Program Files\Microsoft\Exchange Server\V15\Logging). Со временем все эти логи начинают занимать довольно много места.

Особо стоит отметить логи диагностики и производительности в C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics (при включенной диагностике на высоком уровне они могут занимать десятки гигабайт).

Вы можете автоматически очищать старые логи Exchange в этих папках:
gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-21) | Remove-Item
gci ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging\Diagnostics’ -Directory | gci -Include ‘*.log’,’*.blg’ -Recurse | ? LastWriteTime -lt (Get-Date).AddDays(-5) | Remove-Item

Можно добавить эти команды в задание Task Scheduler.

PowerShell скрипт очистки логов Exchange

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

$days = 15
$dirs=@(
"C:\inetpub\logs\LogFiles\",
"C:\Program Files\Microsoft\Exchange Server\V15\Logging\",
"C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\ETLTraces\",
"C:\Program Files\Microsoft\Exchange Server\V15\Bin\Search\Ceres\Diagnostics\Logs\",
"C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\"
)
Get-ChildItem $dirs -Recurse -File | Where-Object < $_.Name -like "*.log" -or $_.Name -like "*.blg" -or $_.Name -like "*.etl" >| Where-Object LastWriteTime -lt (Get-Date).AddDays(-$days) | Remove-Item -ErrorAction "SilentlyContinue"

Я рассчитываю, что в этом вам поможет данная статья, а также некоторые другие на аналогичную тематику (см. тег Exchange 2013 transport).

Это вторая статья из серии, посвященной управлению логированием служб транспортного конвейера Exchange 2013, а вот полный список:

А также статьи о принципе работы этих служб:

Не забывайте об официальной документации.

Логи Exchange 2013 Transport

Если говорить более конкретно, то речь пойдет о службе:

Транспортная служба на серверах почтовых ящиков (Отображаемое имя — Microsoft Exchange Transport, сокращенное — MSExchangeTransport);

За управление отвечают два командлета:

1. Убедимся, что все пути лог-файлов определены и ведение журналов активировано. Сделать это можно с помощью командлета Get-TransportService в Exchange Management Shell:

Посмотрим какие компоненты имеют отдельный параметр для включения логов:

Get-TransportService -Identity exch02 | fl * logenabled *

Итак, по умолчанию практически все логи активированы. Это хорошо.

В PowerShell это можно сделать одной командой для каждого типа соединителей сразу всех ролей:

Get-ReceiveConnector | Set -ReceiveConnector -ProtocolLoggingLevel "Verbose" Get-SendConnector | Set -SendConnector -ProtocolLoggingLevel "Verbose"

Команды выполняются без какого-либо дополнительного вывода:

Если хотите отслеживать данные только конкретных соединителей, укажите в явном виде их имена.

Set -TransportService -Identity exch02 -IntraOrgConnectorProtocolLoggingLevel "Verbose"

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

Для отслеживания потока почты самые полезные логи хранятся в каталогах:

%ExchangeInstallPath%TransportRoles\Logs\MessageTracking
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpReceive
%ExchangeInstallPath%TransportRoles\Logs\Hub\ProtocolLog\SmtpSend

На этом статья завершается. К сожалению, за один раз я не смогу охватить и процесс анализа логов, но вы всегда сможете узнать эту информацию из официальной документации 4 5 6 .

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

Аудит почтовых ящиков является одной из самых важных функций Microsoft Exchange 2013. В почтовых ящиках может содержаться информация различного рода – конфиденциальные данные организации, рабочие документа, а также, персональные данные. Во многих организациях администраторы не включают аудит почтовых ящиков на серверах Exchange. Часто бывает необходимо провести некое «расследование» действий пользователей, но если аудит не включен, то информацию в журналах событий найти невозможно.

AuditOwner – Информация об операциях, проведенных владельцем ящика.
AuditDelegate – Информация об операциях, проведенных сторонними получателями/делегатами в отдельном ящике, включает следующие типы операций: Update, SoftDelete, HardDelete, SendAs, Create.
AuditAdmin – Информация об операциях, проведенных администраторами в отдельном ящике, включает следующие типы операций: Update, Move, MoveToDeletedItems, SoftDelete, HardDelete, FolderBind, SendAs, SendOnBehalf, Create.

По умолчанию аудит почтовых ящиков выключен. После включения журналы аудита событий генерируются и хранятся в папке «Recoverable Items > Audits». Журналы аудита сохраняются всегда, даже при перемещении почтового ящика в новую базу на том же или другом сервере.
Команда, позволяющая проверить, какие уровни аудита включены для отдельного почтового ящика:

Аудит почтовых ящиков включается с помощью команды set-mailbox с параметром AuditEnabled, равным $true:

Аудит на всех почтовых ящиках в организации можно включить с помощью следующего небольшого скрипта PowerShell:

Журналы аудита хранятся по умолчанию в течение 90 дней, этот параметр можно изменить с помощью команды set-mailbox с параметром AuditLogAgeLimit:

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

Мы рекомендуем включать аудит только тех операций, которые необходимо отслеживать в рамках ваших «расследований» или для соблюдения политик и нормативов. Ниже мы привели команду PowerShell, необходимую для включения аудита операции HardDelete для владельца почтового ящика:

Журналы аудита событий генерируются и хранятся в почтовом ящике, в папке «Recoverable Items > Audits», они скрыты от глаз пользователя. После включения аудита вы можете проводить поиск по одному или нескольким почтовым ящикам одновременно. Поиск можно проводить, используя PowerShell или консоль EAC (Exchange Admin Central).

Поиск в журналах событий с использованием PowerShell, приведем несколько примеров:

1. Команда позволяет проводить поиск попыток подключения от имени «Admin» и «Delegate» по всем журналам в интервале времени в ящике пользователя «Krishna.Kumar»

2. Команда позволяет проводить поиск операций «SendAS», выполненных от имени «Admin» и «Delegate» в ящиках пользователей «Krishna.Kumar» and «Rajesh.Kumar»

3. Команда позволяет проводить поиск операций «Hard Delete», выполненных от имени владельца в ящике пользователя «Krishna.Kumar»

Поиск в журналах событий с использованием консоли EAC (Exchange Admin Central):

Вот, по сути, и все, что требуется администратору для расследование инцидентов или контроля действия пользователя на серверах Exchange.

Вы можете задать любые вопросы (и высказать пожелания) в комментариях или в других социальных сетях: facebook, twitter, вконтакте.

Чем мне нравится Linux так это простыми и удобными консольными инструментами. Такими например как tail и grep с помощью которых очень удобно смотреть лог-файлы. Я постоянно пользуюсь именно этими двумя командами для анализа протокола почтового сервера в Linux. К сожалению в Microsoft Exchange эти команды отсутствуют и приходится искать альтернативные инструменты чтобы посмотреть например smtp логи exchange.

О чем речь

Собственно сразу оговорюсь, что речь идет исключительно о просмотре текстовых лог-файлов, в которые данные поступают постоянно построчно. В Linux с помощью команды tail можно вывести например только последние несколько строк либо введя команду tail -f /var/log/имялогфайла выводит на экран непрерывно все поступающие строки в реальном времени. Это очень удобно когда нужно отловить ошибку.

Вторая команда grep в самом примитивном применении (без использования регулярных выражений) позволяет фильтровать вывод той же команды tail, например, только строками содержащими определенный фрагмент. Например:

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

PowerShell для просмотра log файлов

Первым приходит на ум использование команд из PowerShell. Первая же команда заменяет сразу и tail и cat, а имя ей Get-Content. В самом простом применении она выведет все содержимое файла на экран:

Если мы хотим вывести например только несколько последних строк то добавим ключ -tail.

Данная команда выведет 10 последних строк. Если необходимо выводить непрерывно все вновь поступающие данные, то добавим ключ -Wait.

Следующая команда позволяет фильтровать содержимое по части строки почти так же как это делает grep. Имя этой команды Select-String. Выполняется она примерно следующим образом:

Вот пожалуй самые близкие аналоги tail и grep в Windows Power Shell. Преимущество использования этих команд в том, что они уже предустановлены в системе и вам не надо ничего придумывать. Но есть конечно и альтернативные варианты с более удобным функционалом.

Сторонние приложения для просмотра log-файлов в Windows

Смотрим последние SMTP логи Exchange в одном окне

Ну и на последок написал для себя небольшой скрипт запуска wintail, который отображает сразу 2 актуальных лога smtp службы Exchange. Используется на Exchange 2013/2016 но вы можете адаптировать его под свои нужды.

Отредактируйте пути согласно вашим настройкам. Сохраните этот файл с расширением ps1 например на рабочем столе сервера и запускайте просмотр лога smtp службы exchange в пару кликов.

Речь пойдет о несчастных обладателях маленького системного диска, на который по недоразумению еще вкрячили и Exchange наш Server.

Наблюдательный читатель мог заметить, что в 2013 версии это все кануло в Лету, и появилась голодная до свободного дискового пространства папка Logging. Теперь инженеру поддержки не надо ждать, когда вы там соберете логи, он просто попросит вас переслать ему содержимое определенного подкаталога из Logging и пулей решит ваш кейс (в теории).

Еще одна ремарочка: Microsoft не особо озаботился РЕКОМЕНДАЦИЯМИ на счет размера системного тома. В System Requirements наряду с миминмальными требованиями к ОЗУ и разрешением 1024х768 отмечается, что на диске, где будет установлен Exchange надо бы иметь 30 ГБ свободного места, плюс 500 МБ на каждый UM Language Pack, плюс 200 МБ свободного места на системном томе (интересно, парни хотя бы раз ставили обновления ОС при наличии ВСЕГО ЛИШЬ 200 МБ?) и всякую подобную дичь. Окей.

Системные требования для Windows Server (его наимоднейшей версии 2016) тоже не блещут. Пишут вот например: 32 ГБ минимум. Ниже Note яркого цвета: это АБСОЛЮТНЫЙ МИНИМУМ, куда вы сможете разве что поставить сам сервер в Core mode и маленький IIS. То есть установите сервер ради сервера.

Для корректной работы VSS (Volume Shadow Copy Service), например, рекомендуют иметь минимум 1 ГБ свободного места для каждого тома, размером больше 1 ГБ. Если вы обладатель маленького системного диска, и он еще и не твердотельный, то вам необходимо 15% свободного дискового пространства для корректной работы дефрагментатора, а мужчины, занимающиеся всякими инетресными делами с SSD, вообще считают, что 25% свободного места на SSD – это прямо вот правило.

Теперь поставили Exchange. Добавили в требования еще 30 ГБ. И помним, что по умолчанию все, что влияет на включение Back Pressure (когда ваш сервер начинает отпиннывать почту с матами вида Insufficient system resource) находится так же на диске С.

В интернетах довольно много вопросов про «перенос папки Logging» и куча рекомендаций вида «Все отключить и удалить».

Пример раз: все что можно отключить – отключаем, все удаляем, ставим задание на удаление по расписанию и вот нам хорошо. Но. Такое допустимо только в лабах. Серьезные господа себе такого не позволяют.

Что нам рекомендует Microsoft опять же зададимся этим вопросом. Ничего. В своем знаменитом Sizing Guide (для PLA, замечу, т.е. идеально-сферического Exchange в вакууме, к которому БЕЗУСЛОВНО надо стремиться, но вот реалии иногда подножки ставят) они говорят так:

Взяли мы дешманский 2U сервер, напхали в него 24 диска SAS по 4 ТБ, можем себе позволить парочку собрать в RAID1 и туда поставить Exchange и ОС (или в обратном порядке, как нравится).

Ответ тут может быть один (с точки зрения обладателей маленьких системных дисков) «Вас, богатых, не поймешь!»

Ладно, вступление затянулось. Подытожим:

Диск С маленький.
Расширить его нельзя.
Удалять ничего нельзя.
Отключать ничего нельзя.
Надо решить проблему с папкой Logging (сразу отмечу, что параллельно можно решить и проблему с транспортными логами, и с очередями и т.п.)
Перенос либо невозможен, либо не решение.
Копирование по расписанию\руками\еще как-то решением не является.

А теперь решение

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

Вы можете создать junction, который перенаправит вывод из C:\Program Files\Microsoft\Exchange Server\v15\Logging в G:\Logging, а можете примонтировать диск в виде NTFS Folder с именем Logging (путь в этом случае сохранится).

Итак, попробуем реализовать первый вариант решения:

Что для этого нужно сделать?

Найти диск, куда вы положите папку Logging с достаточным количеством свободного места.

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

Второй вариант решения (для тех, кто побогаче и имеет свободный диск под это дело):

- Вставляем дополнительный диск в сервер (или засовываем виртуальный, или презентуем с СХД)
- Освобождаем папку C:\Program Files\Microsoft\Exchange Server\V15\Logging всю. Пусть стоит пустая и ждёт своей участи
- Идем в Disk Management и монтируем новый диск, как NTFS Mount Point в эту самую папку, т.е. в C:\Program Files\Microsoft\Exchange Server\V15\, при этом имя NTFS Mount Point должно совпадать с именем мапируемого каталога. Т.е. если нам нужно изменить вывод для папки Logging, то и Mount Point мы называем Logging. Это имя используется в построении пути к диску, а Exchange в своих бесконечных конфигах имеет множество отсылок на абсолютный путь. Т.е. если вы назовете MountPoint просто Disk1, то пусть построится в итоге C:\Program Files\Microsoft\Exchange Server\V15\Disk1 и никакие логи Exchange туда писать, конечно же, не будет.
- Проверяем работоспособность (оно работает, проверено)
Примечание: можно не пользоваться утилитой Марка, а заюзать старый добрый mklink с ключом /J (что очевидно означает Junction). Команда аналогична:

Удаляется все тоже просто (предварительно надо остановить службы Exchange)

или
просто удаляется каталог в проводнике.

А теперь о прекрасном.

Но я ещё раз хочу заострить ваше внимание на том факте, что по сути это один и тот же механизм, просто второй вариант вынесен в GUI (можно натыкать галок и чудо произойдёт само), а первый нет.

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

Посмотреть можно в PowerShell запросив

В данном случае Path запрашивается в познавательных целях, чтобы показать, что UniqueID и Path для NTFS тома это одно и то же.

Получаете примерно вот такую картинку:

Вот его мы и примонтируем, как NTFS Mount Point с помощью mklink /J. Сразу хочу заметить, что эту команду PowerShell в упор не узнает, поэтому выполнить ее лучше через Command Prompt. Для фанатов же Великого и УжасТного придется разобраться с New-Item -Type Junction бла-бла-бла.

Предварительно нужно сделать три вещи:
- Удалить букву диска
- Удалить каталог Logging, если он был создан
- Удалить каталог C:\Program Files\Microsoft\Exchange Server\V15\Logging, иначе получите ошибку вида:
Говорящую про то, что каталог-то уже есть.

После ставшей уже привычной процедуры включения служб Exchange и перезагрузки сервера мы видим в проводнике вот такую картину:

Каталог Logging находится там, где ему и положено находиться, а его пиктограмма сменилась на пиктограмму MountPoint.

Внутри Exchange тщательно воссоздал структуру каталогов и пишет туда логи ничтоже сумняшеся!

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

Читайте также: