Продление (обновление) tls/ssl сертификата в exchange

Рекомендации по сертификатам Exchange

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

  • Используйте как можно меньше сертификатов. Очень вероятно, что это означает использование сертификатов SAN или сертификатов подпольных карт. С точки зрения связи с Exchange оба функционально эквивалентны. Решение о том, следует ли использовать сертификат SAN против сертификата под диктовки, больше о ключевых возможностях или ограничениях (реальные или воспринимаемые) для каждого типа сертификата, как описано в обзоре цифровых сертификатов

    Например, если все общие имена будут находиться на одном уровне contoso.com, не имеет значения, какой сертификат использовать (SAN или групповой). Но для autodiscover.contoso.com, autodiscover.fabrikam.com и autodiscover.northamerica.contoso.com необходимо использовать сертификат SAN.

  • Используйте сертификаты из коммерческого ЦС для клиентских и внешних подключений к серверу. Хотя большинство клиентов могут доверять любому эмитенту сертификата или сертификата, гораздо проще использовать сертификат из коммерческого ЦС для клиентских подключений к Exchange серверам. Клиенту не требуется конфигурация, чтобы доверять сертификату, выданным коммерческим ЦС. Многие коммерческие CAs предлагают сертификаты, настроенные специально для Exchange. Вы можете использовать EAC или Exchange для создания запросов сертификатов, которые работают с большинством коммерческих ЦС.

  • Выберите правильный коммерческий центр сертификации: сравните цены и функции сертификатов между ЦС. Например:

    • Убедитесь, что центру сертификации доверяют клиенты (операционные системы, браузеры и мобильные устройства), которые подключаются к серверам Exchange.

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

    • Узнайте, предоставляет ли ЦС льготный период, в течение которого в сертификаты SAN можно бесплатно добавлять дополнительные общие имена.

    • Убедитесь, что лицензия позволяет использовать сертификат на нужном количестве серверов. Некоторые ЦС позволяют использовать сертификат только на одном сервере.

  • Используйте мастер Exchange сертификата. Распространенная ошибка при создании сертификатов — забыть одно или несколько распространенных имен, необходимых для служб, которые вы хотите использовать. Мастер сертификатов в центре администрирования Exchange поможет включить правильный список общих имен в запрос сертификата. Мастер позволяет указать службы, которые будут использовать сертификат, и включает общие имена, необходимые для этих служб. Запустите мастер сертификатов при развертывании исходного набора серверов Exchange 2016 или Exchange 2019 г. и определите, какие имена хостов будут использовать для различных служб для развертывания.

  • Используйте как можно меньше имен хостов. Минимизация числа имен хостов в сертификатах SAN снижает сложность управления сертификатами. Не чувствуйте себя обязанными включать имена отдельных серверов Exchange в сертификаты SAN, если это не требуется для использования для сертификата. Как правило, необходимо включать имена DNS, которые представлены внутренним клиентам, внешним клиентам или внешним серверам, которые используют сертификат для подключения к Exchange.

    Для простой Exchange Server организации с именем Contoso это гипотетический пример минимальных имен хостов, которые потребуются:

    • mail.contoso.com. Это имя хост охватывает большинство подключений к Exchange, включая Outlook, Outlook в Интернете, рассылку OAB, Exchange веб-службы, Exchange центр администрирования и Exchange ActiveSync.

    • autodiscover.contoso.com. Это конкретное имя хост-сайта требуется клиентам, которые поддерживают автонаруже, включая Outlook, Exchange ActiveSync и Exchange веб-службы. Дополнительные сведения см. в службе автооткрытия.

Сертификаты, создаваемые инфраструктурой открытых ключей Windows

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

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

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

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

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

Сертификаты в Exchange

При установке Exchange 2016 или Exchange 2019 года на сервере с помощью Exchange. Третий самозаверяется сертификат, созданный и установленный корпорацией Майкрософт Windows для службы управления веб-службы IIS (IIS). Эти сертификаты видны в Центре администрирования Exchange (EAC) и командной консоли Exchange и описаны в таблице ниже.

Имя Comments
Microsoft Exchange Этому самозаверяющему сертификату Exchange присущи следующие возможности:
  • Сертификату автоматически доверяют все другие Exchange серверы организации. Это включает в себя все серверы edge Transport, которые подписаны на Exchange организации.
  • Сертификат автоматически включается для всех служб Exchange, кроме единой системы обмена сообщениями, и используется для шифрования внутренней связи между серверами Exchange, службами Exchange на одном компьютере и клиентскими подключениями, которые передаются из служб клиентского доступа на серверы почтовых ящиков. (Примечание: um не доступен Exchange 2019.)
  • Сертификат автоматически активируется для входящих подключений с внешних серверов обмена сообщениями SMTP и исходящих подключений к внешним серверам обмена сообщениями SMTP. Эта конфигурация по умолчанию Exchange предоставлять оппортунистические TLS на всех входящие и исходящие соединения SMTP. Exchange пытается зашифровать сеанс SMTP на внешнем сервере обмена сообщениями, но если внешний сервер не поддерживает шифрование TLS, сеанс не шифруется.
  • Сертификат не обеспечивает шифрованную связь с внутренними или внешними клиентами. Клиенты и серверы не доверяют самозаверяющему сертификату Exchange, так как сертификат не определен в их хранилищах доверенных корневых сертификатов.
Сертификат проверки подлинности Microsoft Exchange Server Этот Exchange самозаверяемого сертификата используется для проверки подлинности и интеграции от сервера к серверу с помощью OAuth. Дополнительные сведения см. в Exchange Server plan SharePoint и Skype для бизнеса.
WMSVC Этот самозаверяющий сертификат Windows используется службой веб-управления IIS для удаленного управления веб-сервером и связанными с ним веб-сайтами и приложениями.

Если вы удалите этот сертификат и не выберете действительный сертификат, служба веб-управления не запустится. Наличие службы в этом состоянии может помешать установке Exchange обновлений или Exchange с сервера. Инструкции по исправлению этой проблемы см. в выпуске Event ID 1007 — служба веб-управления IIS проверки подлинности.

Свойства этих самозаверяющих сертификатов описаны в разделе .

Ниже описано, что нужно учитывать при управлении сертификатами в Exchange.

  • Для шифрования сетевого трафика между серверами Exchange и службами в вашей организации не нужно заменять самозаверяющий сертификат Microsoft Exchange.

  • Дополнительные сертификаты необходимы для шифрования подключений к серверам Exchange с помощью внутренних и внешних клиентов.

  • Дополнительные сертификаты необходимы для принудительного шифрования SMTP-подключений между серверами Exchange и внешними серверами обмена сообщениями.

Следующие элементы планирования и развертывания для Exchange Server важны для требований к сертификату:

  • Балансировка нагрузки. Планируете ли вы завершить зашифрованный канал на балансировке нагрузки или обратном прокси-сервере, использовать балансиры нагрузки Layer 4 или Layer 7, а также использовать сродство сеансов или отсутствие сродства сеанса? Дополнительные сведения см. в см. в Exchange 2016 г.

  • Планирование пространства имен. Какие версии Exchange присутствуют, используете ли вы связанную или неограниченную модель пространства имен и используете DNS с разделенным мозгом (настройка различных IP-адресов для одного и того же хоста на основе внутреннего и внешнего доступа)? Дополнительные сведения см. в Exchange Namespace Planning in 2016.

  • Подключение клиентов: какие службы будут использовать ваши клиенты (веб-службы, POP, IMAP и т.д.) и какие версии Exchange вовлечены? Дополнительную информацию см. в следующих статьях:

Powershell

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

Синтаксис:

Get-Queue <Параметры запроса>

Пример:

Get-Queue | fl

Примеры использования

Отобразить очереди, в которых более 50-и писем.

Get-Queue -Filter { MessageCount -gt 50 }

Посмотреть сообщения для конкретной очереди:

Get-Queue -Identity mx\615820 | Get-Message

* где mx\615820 — идентификатор очереди, который мы смотрим командой Get-Queue.

Посмотреть все очереди на всех транспортных серверах:

Get-TransportServer | ForEach { Get-Queue -Server $_.Name }

Подробная информация об очереди:

Get-Queue -Identity mx\615820 | Format-List

* где mx\615820 — идентификатор очереди, который мы смотрим командой Get-Queue.

Подробная информация о письмах в очереди от определенного отправителя:

Get-Message -Filter { FromAddress -like «[email protected]» } | Format-List

Список отправителей для определенной очереди:

Get-Queue mx\726931 | Get-Message -ResultSize Unlimited | Select FromAddress

Список получателей:

Get-Queue mx\726931 | Get-Message -ResultSize Unlimited -IncludeRecipientInfo | Select Recipients

Очистить очередь

Удалить сообщения в очереди:

Get-Queue -Identity mx\Poison | Get-Message -ResultSize unlimited | Remove-Message -WithNDR $False

* где mx\Poison — название очереди.

Удалить все сообщения:

Get-Queue | Get-Message -ResultSize unlimited | Remove-Message -WithNDR $False

Удалить сообщение по фильтру:

Get-Queue | Get-Message -ResultSize unlimited | Where {$_.Subject -eq «Тема письма»} | Remove-Message -WithNDR $False

Повторная отправка очереди

Выполняется с помощью командлета Retry-Queue:

Retry-Queue -Filter {Status -eq «Retry»}

* данная команда принудительно повторит отправку всех сообщений, у которых активен статус «Повторить».

Для повторной отправки из очереди подозрительных сообщений, сначала смотрим письма:

Get-Message -Queue Poison

И повторяем попытку отправки с использованием идентификатора письма:

Resume-Message mx\Poison\162514

* где mx\Poison\162514 — полный идентификатор сообщения (mx — сервер, Poison — очередь, 162514 — id письма).

Приостановка очереди

Выполняется командлетом Suspend-Queue:

Suspend-Queue mx\173625

Остановить отправку сообщений, которые находятся в очереди с более чем 500 писем:

Suspend-Queue -Filter {MessageCount -ge 500 -and Status -eq «Retry»}

Настройка разгрузки SSL для Outlook Anywhere

По умолчанию разгрузка SSL для мобильного Outlook включена. Клиенты мобильного Outlook могут получать сообщения электронной почты из частной или общедоступной сети. По умолчанию, чтобы разрешить подключение внутренним клиентам Outlook, используется имя внутреннего узла или полное доменное имя сервера. Но если мобильный Outlook не используется во внутренней среде, необходимо удалить имя внутреннего узла. Чтобы разрешить внутренний и внешний доступ для клиентов Outlook, требуется настроить имена внутреннего и внешнего узла, задать для них способ проверки подлинности и настроить внутренние и внешние клиенты так, чтобы они требовали использование SSL. Способ проверки подлинности внешних клиентов можно настроить с помощью EAC или командной консоли Exchange, но для внутренних клиентов необходимо использовать командную консоль:

  • Шаг 1. Вы можете использовать EAC или Shell, если вы не добавили внешнее имя хоста для Outlook в любом месте:

    • В EAC откройте раздел Серверы, выберите имя сервера клиентского доступа, а затем нажмите кнопку Изменить. В окне Exchange Server щелкните Outlook Anywhere и в поле Укажите имя внешнего узла (например, contoso.com), с помощью которого пользователи будут подключаться к вашей организации введите имя внешнего узла. Убедитесь, что флажок Разрешить разгрузку SSL установлен, и нажмите кнопку Сохранить.

    • В командной консоли Exchange нажмите Пуск и в меню Пуск щелкните Командная консоль Exchange. В открывшемся окне введите следующую команду и нажмите клавишу ВВОД:

  • Шаг 2. По умолчанию включена разгрузка SSL. Но вы можете использовать EAC или командную консоль Exchange, если разгрузка SSL была отключена и вам требуется ее включить:

    • В EAC откройте раздел Серверы, выберите имя сервера клиентского доступа, а затем нажмите кнопку Изменить. В окне Exchange Server нажмите кнопку Outlook в любом месте , нажмите кнопку Разрешить разгрузку SSL, а затем нажмите кнопку Сохранить.

    • В командной консоли введите следующую команду и нажмите клавишу ВВОД:

  • Шаг 3. По умолчанию в виртуальном каталоге RPC не выбрано значение Require SSL, но если вы хотите убедиться, что SSL отключен, можно использовать диспетчер службы IIS IIS.

    В диспетчере служб IIS разверните узел Сайты > Веб-сайт по умолчанию и выберите виртуальный каталог Rpc. В области результатов в разделе IIS дважды щелкните пункт Параметры SSL. В области результатов Параметры SSL убедитесь, что флажок Требовать SSL снят, и нажмите кнопку Применить в области действий.

  • Шаг 4. Необходимо повторно использовать правильный пул приложений или перезапустить службы IIS с помощью одного из следующих методов:

    • Using a command line: Go to Start > Run, type cmd, and then press Enter. In the Command Prompt window, type the following and then press Enter.

    • Введите следующую команду Windows PowerShell и нажмите клавишу ВВОД:

    • Using a command line: Go to Start > Run, type cmd, and then press Enter. In the Command Prompt window, type the following and then press Enter.

    • Использование диспетчера служб IIS. В диспетчере служб IIS в области действий щелкните Перезапустить.

Важно!

Необходимо дождаться того, что процесс узла службы применит все изменения из Active Directory в службах IIS (что происходит каждые 15 минут), даже если вы перезапустите службы IIS на сервере клиентского доступа.

Создать самозаверяющий сертификат Exchange с помощью Центра администрирования Exchange

  1. В Центре администрирования Exchange последовательно выберите пункты Серверы > Сертификаты.

  2. В списке Выберите сервер выберите сервер Exchange, на котором необходимо установить сертификат, а затем нажмите кнопку Добавить Добавить. .

  3. Запустится мастер Создание сертификата Exchange. На странице Этот мастер создаст новый сертификат или файл запроса на сертификат выберите Создать самозаверяющий сертификат и нажмите кнопку Далее.

    Примечание: Чтобы создать новый запрос сертификата для органа сертификации, см. в Exchange Server запрос сертификата для органа сертификации.

  4. На странице Понятное имя для этого сертификата введите понятное имя сертификата и нажмите кнопку Далее.

  5. В «Укажите серверы, которые необходимо применить этот сертификат к странице», нажмите кнопку Добавить значок Добавить.

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

    По завершении нажмите кнопку Далее.

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

    • Outlook в Интернете

    • Формирование автономной адресной книги (OAB)

    • веб-службы Exchange

    • Exchange ActiveSync

    • Автообнаружение

    • POP

    • IMAP

    • Мобильный Outlook

      Если вы введете значения для каждой службы на основе расположения (внутренней или внешней), мастер определит необходимые имена узлов, и они отобразятся на следующей странице. Чтобы изменить значение для службы, нажмите кнопку Изменить (Изменить значок. ) и введите значение имени хост, которое вы хотите использовать (или удалить значение). По завершении нажмите кнопку Далее.

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

  7. В соответствии с вашими выборами на странице сертификата будут включены следующие домены, в которых перечислены имена хостов, которые будут включены в самозаверяемый сертификат. The host name that’s used in the certificate’s Subject field is bold, which can be hard to see if that host name is selected. You can verify the host name entries that are required in the certificate based on the selections that you made on the previous page. Or, you can ignore the values from the last page and add, edit, or remove host name values.

    • Если требуется сертификат SAN, укажите в поле Subject одно общее имя (CN). Чтобы выбрать имя узла для поля Subject сертификата, выберите значение и установите флажок Задать как общее имя. После этого значение должно быть выделено полужирным шрифтом.

    • Если вам нужен сертификат для одного имени хоста, выберите другие значения по одному и нажмите кнопку Удалить значок. ).

      Когда вы закончите работу на этой странице, нажмите кнопку Готово.

      Примечания.

    • Имя узла, выделенное полужирным шрифтом, будет использоваться для поля Subject сертификата, и его невозможно удалить. Сначала необходимо выбрать или добавить другое имя узла, а затем установить флажок Задать как общее имя.

    • Если нажать кнопку Назад, изменения, внесенные на этой странице, могут быть потеряны.

Обновление сертификата, выданного центром сертификации

Процедуры одинаковы для сертификатов, выданных внутренним (например, службами сертификации Active Directory) и коммерческим ЦС.

Чтобы обновить сертификат, выданный ЦС, создайте запрос на обновление сертификата и отправьте его в ЦС. Затем ЦС отправляет вам фактический файл сертификата, который необходимо установить на Exchange сервере. Почти аналогично выполняется запрос нового сертификата. Инструкции см. в справке Complete a pending Exchange Server сертификата.

  1. В Центре администрирования Exchange последовательно выберите пункты Серверы > Сертификаты.

  2. В списке Выберите сервер выберите сервер Exchange с сертификатом, который требуется обновить.

  3. В области сведений всех действительных сертификатов есть ссылка Обновить, которая отображается при выборе сертификата из списка. Выберите сертификат, который требуется обновить, и нажмите Обновить в области сведений.

  4. На открывшейся странице Обновление сертификата Exchange в поле Сохранить запрос сертификата в следующий файл введите UNC-путь и имя файла нового запроса на обновление сертификата. Например, . После этого нажмите кнопку ОК.

После этого запрос сертификата появится в списке сертификатов Exchange со статусом Ожидает.

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

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

В этом примере создается запрос на обновление сертификата со следующими свойствами:

  • Сертификат для обновления:

  • RequestFile:

Примечания.

  • Параметр RequestFile принимает локальный путь или путь UNC.

  • Мы не использовали переключатель BinaryEncoded, поэтому запрос закодирован в Base64. Данные, отображаемые на экране, также записываются в файл, а содержимое файла это то, что нам нужно отправить в ЦС. Если бы мы использовали переключатель BinaryEncoded, запрос был бы закодирован DER, а сам файл запроса сертификата должен был бы отправляться в ЦС.

  • Мы не использовали параметр KeySize, поэтому запрос сертификата имеет общедоступный ключ RSA 2048 бита.

  • Дополнительные сведения см. в сведениях Get-ExchangeCertificate и New-ExchangeCertificate.

Как проверить, что все получилось?

Чтобы убедиться, что вы успешно создали запрос на обновление сертификата для центра сертификации, выполните любое из следующих действий:

  • В Центре администрирования Exchange выберите Серверы > Сертификаты, убедитесь, что выбран сервер, на котором хранится запрос сертификата. Запрос должен быть в списке сертификатов и иметь статус Ожидающий запрос.

  • В командной консоли Exchange на сервере, где хранится запрос сертификата, выполните следующую команду:

Windows сертификаты инфраструктуры общедоступных ключей

Второй тип сертификата — это сертификат Windows PKI. PKI — это система цифровых сертификатов, органов сертификации и органов регистрации (RAS), которые проверяют и проверяют подлинность каждой стороны, которая участвует в электронной транзакции с помощью криптографии общедоступных ключей. При реализации PKI в организации, использующей Active Directory, вы предоставляете инфраструктуру для управления жизненным циклом сертификатов, обновления, управления доверием и отзыва сертификатов. Однако при развертывании серверов и инфраструктуры для создания и управления сертификатами, созданными Windows PKI, существуют дополнительные затраты.

Службы сертификатов необходимы для развертывания Windows PKI и могут быть установлены с помощью add or Remove Programs in Control Panel. Службы сертификации можно установить на любом сервере в домене.

Если вы получите сертификаты из Windows ca, вы можете с помощью ЦС запрашивать или подписывать сертификаты для выдачи на собственные серверы или компьютеры в сети. Это позволяет использовать PKI, похожий на сторонного поставщика сертификатов, но менее дорогостоящий. Эти сертификаты PKI не могут быть развернуты публично, как и другие типы сертификатов. Однако, когда ЦБ PKI подписывает сертификат запросителя с помощью закрытого ключа, запросчик проверяется. Общедоступный ключ этого ЦС является частью сертификата. Сервер, который имеет этот сертификат в хранилище надежных корневых сертификатов, может использовать этот общедоступный ключ для расшифровки сертификата запросителя и проверки подлинности запросителя.

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

A Windows PKI позволяет организациям публиковать собственные сертификаты. Клиенты могут запрашивать и получать сертификаты Windows PKI во внутренней сети. Сертификаты Windows PKI можно обновить или отоискить.

Дополнительная информация

Типы очередей

Существуют следую очереди:

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

Где хранятся очереди Exchange

Очереди хранятся в базе данных ESE, которая находится в папке «%ExchangeInstallPath%TransportRoles\data\Queue»:

* mail.que — основной файл с базой очередей; tmp.edb — временный файл для проверки схемы самой базы; trn.chk — контрольные точки для отслеживания записи в логах.

Со временем, файл mail.que может разрастись и занимать много места. Для полной чистки базы ее можно просто создать заново. Для этого открываем службы Windows — останавливаем Microsoft Exchange Transport (перестанет работать почта) — переименовываем папку Queue, в которой находятся файлы базы и снова запускаем службу транспорта. Папка и база очереди создастся снова.

Смена пути хранения очереди

Открываем на редактирование файл %ExchangeInstallPath%\Bin\EdgeTransport.exe.config (C:\Program Files\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config) и меняем значения ключей QueueDatabasePath и QueueDatabaseLoggingPath, например:

    <add key=»QueueDatabasePath» value=»D:\Queue» />
    <add key=»QueueDatabaseLoggingPath» value=»D:\Queue» />

* где QueueDatabasePath — папка хранения файлов очереди; QueueDatabaseLoggingPath — папка хранения файлов журналов очереди.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Ваша ОС
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: