Проверка на вирусы в exchange

Применимо к: Exchange Server 2013 Applies to: Exchange Server 2013

В Microsoft Exchange Server 2013 можно отключить или обойти фильтрацию вредоносных программ всех сообщений электронной почты, проходящих через сервер. Это необходимо сделать на сервере почтовых ящиков. In Microsoft Exchange Server 2013, you can disable or bypass malware filtering of all email messages in transit on a server. This must be done on a Mailbox server.

Можно отключить фильтрацию вредоносных программ Exchange 2013, если вы используете другой продукт для фильтрации вредоносных программ. При отключении фильтрации вредоносных программ агент Exchange отключается и не запускается, а ядро не обновляется. You may want to disable Exchange 2013 malware filtering if you are using another product for malware filtering. When malware filtering is disabled, the Exchange malware agent is unhooked and not running, and engine updates are not kept up-to-date.

Обход фильтрации вредоносных программ следует выполнять только при устранении неполадок. Bypassing malware filtering should only be done when troubleshooting a problem. При обходе фильтрации вредоносных программ агент Exchange агент остается подключен и ядро обновляется. When malware filtering is bypassed, the Exchange malware agent remains hooked, and engine updates are kept up-to-date. Однако фильтрация вредоносных программ пропускается при попытке решить любые проблемы, которые у вас возникают. However, malware filtering is skipped while you attempt to resolve whatever problems you are encountering. После завершения устранения неполадок следует восстановить фильтрацию вредоносных программ. After you have finished troubleshooting, you should restore malware filtering.

Что нужно знать перед началом работы What do you need to know before you begin?

Предполагаемое время для завершения каждой процедуры: 15 минут. Estimated time to complete each procedure: 15 minutes

Для выполнения этой процедуры можно использовать только командную консоль. You can only use the Shell to perform this procedure.

Отключение и включение фильтрации вредоносных программ вызывает перезапуск службы транспорта Microsoft Exchange на сервере. Это может временно прервать поток почты в организации. Disabling or enabling malware filtering restarts the Microsoft Exchange Transport service on the server. This may temporarily disrupt mail flow in your organization.

Обход или восстановление фильтрации вредоносных программ не требует перезапуска служб. Однако на вступление изменений в силу может уйти до 10 минут. Bypassing or restoring malware filtering doesn't require you to restart any services. However, changes to the setting may take up to 10 minutes to take effect.

При наличии нескольких серверов Exchange Server с фильтрацией вредоносных программ эти действия следует выполнить на каждом сервере. If you have multiple Exchange servers performing malware filtering, you must perform these steps on each server.

Сочетания клавиш для процедур, описанных в этой статье, приведены в статье Сочетания клавиш в Центре администрирования Exchange. For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.

Возникли проблемы? Having problems? Обратитесь за помощью к участникам форумов Exchange. Ask for help in the Exchange forums. Посетите форумы на сервере Exchange Server. Visit the forums at Exchange Server.

Использование командной консоли для отключения фильтрации вредоносных программ на сервере Exchange Server Use the Shell to disable malware filtering on a specific Exchange server

Чтобы отключить фильтрацию, выполните следующую команду: To disable malware filtering, run the following command:

Для повторного включения фильтрации вредоносных программ Enable-Antimalwarescanning.ps1 используйте вместо Disable-Antimalwarescanning.ps1 . To re-enable malware filtering, use Enable-Antimalwarescanning.ps1 instead of Disable-Antimalwarescanning.ps1 .

Как убедиться, что все получилось? How do you know this step worked?

Чтобы убедиться, что фильтрация отключена, выполните следующую команду и убедитесь, что она возвращает значение False: To verify that malware filtering is disabled, run the following command and confirm that it returns a value of False:

Использование командной консоли для временного обхода фильтрации вредоносных программ на сервере Exchange Server Use the Shell to temporarily bypass malware filtering on a specific Exchange server

Обход фильтрации вредоносных программ следует выполнять только при устранении неполадок. Bypassing malware filtering should only be done when troubleshooting a problem. Следует восстановить фильтрацию вредоносных программ после завершения устранения неполадок. You should restore malware filtering after you have finished troubleshooting.

Чтобы временно обойти фильтрацию, выполните следующую команду: To temporarily bypass malware filtering, run the following command:

Чтобы восстановить фильтрацию, выполните следующую команду: To restore malware filtering, run the following command:

Как убедиться, что все получилось? How do you know this step worked?

Чтобы проверить, что обход фильтрации вредоносных программ включен, выполните следующую команду и убедитесь, что она возвращает значение True: To verify that malware filtering is being bypassed, run the following command and confirm that it returns a value of True:

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

Проверка событий резервного копирования.
Проверка системных журналов событий.
Проверка дисковой системы.
Проверка обновлений антивирусных баз.
Проверка очередей.
Проверка квитанций о недоставке (NDR).
Проверка оборудования.

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

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

Чтобы убедиться в пригодности резервной копии, проверять надо процедуры резервирования для каждой установленной системы Exchange. Обычно резервное копирование на файловом уровне выполняется, когда сохраняемые файлы не используются. В случае с системой Exchange файлы баз данных свободны только тогда, когда система остановлена. К счастью, Exchange предоставляет API, который позволяет программам резервного копирования работать в тандеме с модулем Extensible Storage Engine (ESE) и выполнять копирование, когда базы данных используются.

Во время резервного копирования ESE читает базы данных и передает информацию программе резервирования, которая, в свою очередь, сохраняет эту информацию на резервном носителе данных. Поскольку два компонента (т. е. ESE и программа резервирования) работают с данными во время резервирования, важно убедиться, что каждый компонент сохраняет данные без ошибок. Табл. 1 можно использовать для интерпретации системного журнала Application. Она включает события, связанные с работой ESE и NTBackup — штатной программы резервного копирования Windows 2000. ID событий от программы резервирования зависят от используемого программного обеспечения, а ID от ESE будут оставаться неизменными.

Интерпретировать события в системном журнале очень просто. Например, посмотрим на окно с журналом Application, показанное на экране 1. События с ID 8000 и 8001 показывают время начала и завершения резервного копирования со стороны NTBackup. События с ID 210 и 213 показывают время начала и завершения полного резервного копирования со стороны ESE. Другие виды резервирования, такие как инкрементальное и дифференциальное, будут отличаться соответствующими ID.

События NTBackup с ID 8008 и 8009 показывают начало и завершение процесса верификации. Во время процесса верификации NTBackup читает данные и соответствующие контрольные суммы с носителя резервной копии для подтверждения пригодности сохраненных данных. Если возникает аппаратная ошибка или сбой носителя, то NTBackup сообщает об ошибке. Поскольку процесс верификации завершается после сообщения ESE об успешном завершении резервного копирования, для уверенности в нормальном сохранении данных Exchange необходимо убедиться в отсутствии сообщений об ошибках от программного обеспечения, выполняющего резервное копирование. Поэтому только после сообщений об успешном завершении резервного копирования от всех источников можно считать, что получена работоспособная копия данных.

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

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

По умолчанию Exchange записывает большое количество данных в системные журналы. Определив базовое состояние, можно сэкономить время, поскольку уже будет известно, на какие именно сообщения следует обратить внимание. Одни информационные сообщения, такие как были описаны выше (о выполнении резервного копирования), критичны для регулярного контроля, другие — нет. Например, событие с ID 1221 сообщает об освобождении свободного пространства в хранилище. Когда пользователи удаляют свои сообщения из почтовых ящиков, Exchange не уменьшает размер хранилища почтовых ящиков, а вместо этого устанавливает флаг, означающий, что данные удалены. Такой тип информации поможет сэкономить дисковое пространство. В табл. 2 приведен список событий, на которые обычно можно не обращать внимания при ежедневном осмотре.

При определении базового состояния следует сосредоточиться на сообщениях об ошибках и предупреждениях. При изучении таких событий необходимо понять, что есть причина, а что следствие. Например, в журнале обнаружено событие с ID 2090, показанное на экране 2. Если разбираться с этим сообщением, то надо отыскать в свойствах сервера Exchange закладку Directory Access (она появилась в Exchange 2000 Service Pack 2) для определения ситуации с контроллером домена (DC) или сервером глобального каталога (GC), к которому необходим доступ, но в данный момент он недоступен. Из всех перечисленных DC и GC оставить надо только те, которые необходимо, так как сбой может быть следствием того, что Exchange и текущий сервер GC находятся на разных территориях и между ними — медленный канал связи.

Экран 2. Событие, вызванное недосягаемостью контроллера домена

Если в сети много серверов Exchange, просмотр системных журналов становится нелегкой задачей. Для ее решения можно задействовать автоматизированные средства мониторинга, такие как Microsoft Operations Manager (MOM), Aelita Software EventAdmin, NetIQ AppManager Suite (AppManager) или Hewlett-Packard HP OpenView. Эти продукты предоставляют механизмы, позволяющие фильтровать события, которые нет необходимости отслеживать. Кроме того, эти продукты предоставляют дополнительные возможности по уведомлениям в случае возникновения важных событий.

Серверы Exchange могут останавливаться из-за недостаточного количества свободного места на диске, что является серьезной проблемой для многих администраторов. Обычно на серверах Exchange имеются отдельные диски для операционной системы, для журналов транзакций и для хранилища. На некоторых серверах также могут быть отдельные диски для других компонентов, таких как журналы отслеживания сообщений, очереди коннекторов SMTP, карантины для перехваченных антивирусным программным обеспечением файлов. Важно проверять свободное дисковое пространство на каждом диске каждый день, чтобы быть уверенным в том, что система не остановится из-за нехватки свободного места. Достаточное количество свободного пространства на дисках зависит от таких факторов, как объем передаваемой информации через почтовую систему в день и требования стандартных процедур Exchange по работе с журналами, файлами карантина и другими файлами. Для выполнения соответствующих проверок свободного дискового пространства необходимо следующее.

Убедиться, что Exchange чистит журналы транзакций. Перед выполнением полного резервного копирования всех баз данных в рамках группы хранения (SG) можно увидеть журналы транзакций со времени последнего выполнения такого резервного копирования. Exchange чистит журналы транзакций только при успешном завершении резервирования всех баз данных в SG. Если вы увидите старые журналы, это означает, что Exchange не очищал их, и это косвенно говорит о том, что базы данных не были успешно скопированы.
Проверить размер антивирусных карантинов и отчетов. Некоторые поставщики антивирусных программ заявляют, что производительность их продуктов может падать при большом увеличении файлов в зоне карантина. Это, вероятно, происходит потому, что программное обеспечение записывает файлы на диск последовательно и со временем их может скопиться очень много. Но эта проблема не является реально опасной в промышленной среде. В большинстве случаев отчеты и файлы карантина хранятся от 15 до 30 дней, в зависимости от организации и принятых в ней порядков. Такой период времени позволяет восстановить файл в случае ошибочного попадания в карантин.
Проверить размер каталога журналов SMTP и очистить в случае необходимости. Несмотря на то что Exchange позволяет управлять файлами журналов, они все равно последовательно заполняются и старые журналы автоматически не удаляются. Нельзя позволять журналам накапливаться бесконтрольно, это может привести к сбою. Если каталог с журналами находится на системном диске по умолчанию, то Windows может дать сбой при заполнении всего дискового пространства. Если каталог с журналами находится на диске с каталогами виртуального сервера SMTP, то этот сервер SMTP может остановить обработку писем, пока не освободится дисковое пространство. Журналы имеет смысл хранить от 21 до 30 дней. В случае возникновения проблем этого срока вполне достаточно, чтобы разобраться в причинах.
Удалить устаревшие архивные сообщения. Если используются возможности архивирования протокола SMTP, следует убедиться в том, что архивные сообщения удалены или перемещены в другой каталог, прежде чем заканчивается срок хранения сообщений для данного каталога, установленный исходя из здравого смысла. Компании архивируют сообщения по разным причинам - от выявления неполадок до контроля содержимого переписки. Но если не слишком активно заниматься управлением архивом сообщений и удалением лишнего, все доступное дисковое пространство будет быстро заполняться.

Когда в систему попадет очередной вирус, неизвестно. Лучшей защитой от вирусов является регулярное обновление баз установленного антивирусного программного обеспечения. Проверять наличие обновлений антивирусных баз необходимо не реже чем один раз в день. Обычно антивирусное программное обеспечение, обработав и установив новые базы, делает соответствующую запись в системный журнал Windows. Если антивирусная программа не вносит записи в журнал событий, то, возможно, она записывает информацию в собственный журнал. Например, Sybari Software Antigen записывает информацию об обновлениях в файл programlog.txt, а Trend Micro ScanMail for Microsoft Exchange записывает свои события в update.log. Проверяя журнал Windows или собственный журнал антивирусной программы, необходимо убедиться, что обновления баз были успешно получены и корректно установлены.

Можно считать это неинтеллектуальной задачей, но в некоторых случаях могут возникать серьезные проблемы. Например, одна компания отключила соединение с Internet, когда появился вирус Nimda. Поскольку антивирусное программное обеспечение не могло получить доступ к сайту разработчика для загрузки обновлений, администратор Exchange использовал коммутируемое соединение для загрузки обновлений и записи их на компакт-диск. Когда администратор скопировал обновления с компакт-диска на сервер, он оставил у файлов атрибут read-only. Позднее, когда компания восстановила соединение с Internet, процесс автоматического обновления завершился со сбоем, поскольку новые файлы антивирусных баз не могли перезаписать старые файлы.

Для того чтобы оценить критичность ситуации, необходимо определить базовое состояние, по которому решать — нормальное положение или нет. Для табличного отображения очередей можно задействовать утилиту MailQ из Microsoft Exchange Server Resource Kit. Если по очередям будет видно наличие проблемы, исследовать ее причины можно с помощью Exchange System Manager (ESM).

NDR приходят всегда. Основные причины появления NDR — неверное написание имени получателя или отказ сервера получателя принять сообщение. Серверы посылают NDR отправителю сообщения, но систему можно настроить так, чтобы копии отчетов шли в назначенный администратором почтовый ящик. Эта возможность настраивается в ESM в диалоговом окне свойств для каждого виртуального сервера SMTP. На закладке Messages следует ввести соответствующий адрес в формате SMTP в поле Send copy of non-delivery reports to. После внесения такого изменения в настройках надо остановить и снова запустить виртуальный сервер.

Пробовать определять и корректировать информацию для каждого NDR — это задача не на каждый день. Вместо этого достаточно будет сравнивать количество NDR с выбранным базовым состоянием. Для определения такого базового состояния надо выбрать среднее значение отправленных или принятых NDR в течение недели. Их количество может варьироваться. Например, в понедельник может приходить 25 NDR каждые 10 минут, а в пятницу — 25 NDR в час.

Резкий скачок в количестве NDR обычно говорит о проблеме, такой как атака DoS или зацикливание в отправке почты. Зацикливание в отправке почты может возникнуть, когда у пользователя настроено правило для пересылки на личный почтовый ящик у провайдера Internet. Пользователи могут настраивать такую конфигурацию, несмотря на то что корпоративная почтовая система может не иметь выхода в Internet. Теоретически такие настройки не являются серьезной ошибкой. Однако можно ошибиться в имени личного почтового ящика у провайдера, этот почтовый ящик может переполниться или возникнет другой сбой, и сервер провайдера услуг Internet будет отсылать NDR, а пользовательское правило будет успешно их пересылать обратно на тот же адрес, который в данный момент недоступен. В результате возникает цикл NDR.

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

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

Какой тип событий сервер Exchange обычно записывает в системный журнал? Как много сообщений обычно находится в очереди? Сколько NDR отправляется и принимается каждый день? Важно знать ответы на такие вопросы. Если не принимать во внимание типичное состояние системы, сложно вовремя заметить критическую для сервера ситуацию. Помочь в данном случае могут ежедневные проверки и определение на их основе базовых состояний, а также профилактический контроль состояния системы Exchange.

Любой администратор электронной почты знает, что нужно защищать от вирусов и спама сообщения, пересылаемые Microsoft Exchange Server. Но не всегда почтовый антивирус защищает операционную систему Windows, под управлением которой работает Exchange Server. Примером может служить антивирус Forefront Protection for Exchange [FPE], проверяющий исключительно поток почты. Поэтому возникает вопрос, а нужно ли устанавливать дополнительно файловый антивирус на Exchange Server, чтобы защитить сервер от файловых вирусов и троянов?

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

This topic describes the effects of file-level antivirus programs on computers that are running Microsoft Exchange Server 2010. If you implement the recommendations described in this topic, you can help enhance the security and health of your Exchange organization.

Существует множество причин, по которым, все же не стоит устанавливать файловый антивирус на Exchange Server. Перечислим лишь некоторые из них.

Антивирус всегда служил основным генератором проблем в Exchange Server, что подтверждают жалобы пользователей на форумах TechNet. Пропадание писем, переполненные очереди сообщений, задержки при доставке сообщений, зависание серверов – вот лишь не полный перечень проблем, вызываемых некорректной работой антивирусов.
Даже если антивирус корректно написан и настроен, то обновление антивируса может вызвать проблемы.
Антивирус будет дополнительно потреблять память и процессорное время сервера, что обязательно скажется на производительности сервера в худшую сторону.

Если внимательно подумать, то откуда взяться вирусам на Microsoft Exchange Server?

На сервере нет никакого программного обеспечения, кроме Microsoft. Никакие сторонние файлы на него не переписываются.
Администраторы управляют Exchange Server удаленно, через PowerShell, изредка заходя через RDP, устанавливая обновления.
У каждого администратора есть две учетные записи – пользовательская и администраторская. Администраторская запись используется редко, исключительно для управления серверами.
На всех рабочих станциях установлен локальный антивирус, даже если какой-нибудь файл будет записан на сервер, то его обязательно проверит локальный антивирус.
Выхода в Интернет с серверов нет, серверы защищены файерволами.

Поэтому ответ на вопрос будет такой.

Файловый антивирус можно устанавливать на Exchange Server, но лучше этого не делать, т.к. вреда будет больше, чем пользы.

Почтовый сервер совмещает другие роли – например файлового сервера. К серверу имеют доступ много разных администраторов или сервер находится на удаленной площадке и к нему есть доступ у местных администраторов. Требования аудиторов или стандартов компании. Не всегда они разумны.

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

Понравилась публикация? Хотите получать новые прямо в свой почтовый ящик? Нет ничего проще, подпишитесь на рассылку прямо сейчас.

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

*Правило делали, так как FPE не срабатывал на половину вирусов и пропускал файлы. А пользователи очень любят открывать invoice.PDF.exe из архивов 🙂

Полностью с тобой согласен, но лично мне как-то, вот не комфортно от осознания факта того что на сервере нет антивируса, даже не то что бы антивируса а возможности хотя бы раз в месяц запустить проверку, и я бы наверное поступил следующим образом, такой случай даже описан в курсах Лаборатории Касперского. В антивирусном сервере создать отдельную группу серверов, к группе привязать политику в которой будет указано что файловый антивирус выключен, создать задачу проверки на вирусы с некими разумными параметрами и я так думаю что с исключением проверки баз Exchange ну и к примеру 1 раз в неделю\месяц эту задачу запускать …

MS пишет же, что использование файлового антивируса увеличит безопасность, поэтому можно. У меня серверов штук 11 наверное, лишний софт — лишние проблемы 🙂

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

Серег, в моем случае вреда больше, чем пользы.

Тем более никто не написал, что у меня установлен такой-то файловый антивирус и он отлично работает лет 5 с Exchange Server.

Пишу, просто для статистики: всё время существования у нас exchange (пока что 3 года) с установленным на нём сначала FEP, а теперь SCEP и прописанными по статьям микрософта исключениями — ни разу проблем не было.

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

я тож хачу danilandrosov@mail.ru

Антивирус нужен обязательно, но действительно не каждый антивирус корректно работает в Exchange, что выражается в зависании сервера. Проверенно без проблем работает Eset File Security, после инсталляции он сам анализирует и добавляет все, что касается Exchange в исключения.

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

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

Роль сервера почтовых ящиков

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

Файлы групповых метрик. По умолчанию они находятся в папке %ExchangeInstallPath%\GroupMetrics.

Файлы общих журналов, например файлы журнала отслеживания сообщений и восстановления календаря. По умолчанию они находятся в подпапках в папках %ExchangeInstallPath%\TransportRoles\Logs и %ExchangeInstallPath%\Logging. Чтобы определить используемые пути к журналам, выполните следующую команду в командной консоли Exchange: Get-MailboxServer | format-list *path*

Файлы автономной адресной книги. По умолчанию они находятся в подпапках в папке %ExchangeInstallPath%\ExchangeOAB.

Системные файлы IIS в папке %SystemRoot%\System32\Inetsrv.

Временная папка, которая используется автономными программами обслуживания, такими как Eseutil.exe. По умолчанию это папка, из которой запускается EXE-файл программы. Тем не менее, можно настроить папку для выполнения этой операции при запуске служебной программы.

Временная папка базы данных почтовых ящиков: %ExchangeInstallPath%\Mailbox\MDBTEMP

Все папки антивирусных программ, поддерживающих Exchange.

Сервер почтовых ящиков, являющийся участником группы доступности базы данных

Все папки, перечисленные для роли сервера почтовых ящиков, а также следующие:

Следящий сервер

Роль транспортного сервера-концентратора

Папки каталогов сообщений о раскладке и преобразовании. По умолчанию эти папки расположены в папке %ExchangeInstallPath%\TransportRoles. Чтобы определить используемые пути, выполните следующую команду в командной консоли Exchange: Get-TransportServer | fl *dir*path*

Файлы базы данных очереди роли транспортного сервера, контрольных точек и журнала. По умолчанию они расположены в папке %ExchangeInstallPath%\TransportRoles\Data\Queue. Дополнительные сведения см. в разделе Управление транспортными очередями.

Файлы базы данных репутации отправителя роли транспортного сервера, контрольных точек и журнала. По умолчанию они расположены в папке %ExchangeInstallPath%\TransportRoles\Data\SenderReputation.

Файлы базы данных IP-фильтра роли транспортного сервера, контрольных точек и журнала. По умолчанию они расположены в папке %ExchangeInstallPath%\TransportRoles\Data\IpFilter.

Временные папки, которые используются для выполнения преобразований:

По умолчанию преобразования OLE выполняются в папке %ExchangeInstallPath%\Working\OleConvertor.

Все папки антивирусных программ, поддерживающих Exchange.

Роль пограничного транспортного сервера

Файлы общих журналов, например файлы журнала отслеживания сообщений. По умолчанию эти файлы находятся в подпапках в папке %ExchangeInstallPath%\TransportRoles\Logs. Чтобы определить используемые пути к журналам, выполните в командной консоли Exchange следующую команду: Get-TransportServer | format-list *logpath*,*tracingpath*

Папки сообщений раскладки и преобразования. По умолчанию они расположены в папке %ExchangeInstallPath%\TransportRoles. Чтобы определить используемые пути к журналам, выполните следующую команду в командной консоли Exchange: Get-TransportServer | format-list *dir*path*

Файлы базы данных очереди роли транспортного сервера, контрольных точек и журнала. По умолчанию они расположены в папке %ExchangeInstallPath%\TransportRoles\Data\Queue. Дополнительные сведения об очередях на транспортном сервере см. в разделе Управление транспортными очередями.

Временные папки, которые используются для выполнения преобразований:

По умолчанию преобразования OLE выполняются в папке %ExchangeInstallPath%\Working\OleConvertor.

Все папки антивирусных программ, поддерживающих Exchange.

Роль сервера клиентского доступа

Для серверов, на которых используются службы IIS 6.0, папка сжатия, используемая вместе с Microsoft Outlook Web App. По умолчанию папка сжатия для IIS 6.0 имеет следующий путь: %systemroot%\IIS Temporary Compressed Files. Дополнительные сведения о возможных ошибках, возникающих при сканировании папки сжатия IIS, см. в статье 817442 базы знаний Microsoft При включенном сжатии на сервере с запущенными службами IIS может быть возвращен файл размером 0 байт.

Системные файлы IIS в папке %SystemRoot%\System32\Inetsrv.

Файлы, связанные с Интернетом, которые хранятся в подпапках папки %ExchangeInstallPath%\ClientAccess.

Для серверов, на которых включен вход в систему по протоколам POP3 или IMAP4, следующие папки:

Папка IMAP4: %ExchangeInstallPath%\Logging\IMAP4

Временные папки, которые используются для выполнения преобразований:

По умолчанию преобразования OLE выполняются в папке %ExchangeInstallPath%\Working\OleConvertor.

Роль сервера единой системы обмена сообщениями

Файлы голосовых приглашений, приветствий и информационных сообщений. По умолчанию они хранятся в подпапках папки %ExchangeInstallPath%\UnifiedMessaging\Prompts

Файлы голосовой почты, которые временно хранятся в папке %ExchangeInstallPath%\UnifiedMessaging\voicemail.

Временные файлы, создаваемые единой системой обмена сообщениями. По умолчанию они хранятся в папке %ExchangeInstallPath%\UnifiedMessaging\temp.

Microsoft Forefront Protection для Exchange

Любые архивные сообщения. По умолчанию они хранятся в папке %Program Files (x86)%\Microsoft Forefront Protection for Exchange Server\Data\Archive.

Любые помещенные на карантин файлы. По умолчанию они хранятся в папке %Program Files (x86)%\Microsoft Forefront Protection for Exchange Server\Data\Quarantine.

Файлы антивирусного ядра. По умолчанию они хранятся во вложенных папках %Program Files (x86)%\Microsoft Forefront Protection for Exchange Server\Data\Engines\x86 или %Program Files (x86)%\Microsoft Forefront Protection for Exchange Server\Data\Engines\amd64.

Файлы конфигурации. По умолчанию они хранятся в папке %Program Files (x86)%\Microsoft Forefront Protection for Exchange Server\Data.

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

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