MSExchangeTransport 2019

Последнее изменение раздела: 2011-03-19

В этой статье приводится объяснение и возможные варианты устранения неполадок, связанных с определенными событиями Exchange. Если вам не удалось найти ответ на свой вопрос, используйте поиск по Справке Exchange 2010.

Details

Explanation

This Warning event indicates that a problem occurred when attempting to validate an internal transport certificate (also referred to as a direct trust certificate) on this computer. In Microsoft Exchange Server 2010, direct trust is the authentication functionality for which the presence of the certificate in the Служба каталогов Active Directory directory service or Служба каталогов Active Directory Lightweight Directory Service (AD LDS) validates the certificate. Служба каталогов Active Directory is considered a trusted storage mechanism.

By default, Exchange uses a self-signed certificate installed by Exchange server instead of using a third-party custom certificate. However, you can use a custom certificate for direct trust.

This problem is caused by one or more of the following conditions:

• The SMTP service is not enabled on the certificate. By default, self-signed internal transport certificates have the SMTP service enabled. Therefore, it is more likely that the SMTP service may not be enabled if a custom certificate that is being used for direct trust is installed.

• The Network Service account may not have the correct permissions on the machine keys.

• The host name query in the certificate selection process may fail because of incorrect DNS or machine name configuration.

• The Hub Transport server role is configured to use Network Load Balancing (NLB). The Hub Transport server role is not supported in a cluster or NLB configuration for the purposes of Exchange Server authentication for scenarios such as communication between Hub Transport servers. Using NLB may cause the host name query to fail during certificate validation.

User Action

To resolve this warning, do one or more of the following:

• Make sure that the SMTP service is enabled on the certificate.

  Run the following Exchange Management Shell command: Get-ExchangeCertificate | fl

  The output will show details of all certificates that are installed on the computer.

  • If the value of the IsSelfSign attribute is True, this is the self-signed certificate installed by Exchange. You can have more than one self-signed certificate installed on the server. However, only the most recent timestamp would be considered.

  • If the value of the IsSelfSign attribute is False, the certificate is a third-party or custom certificate.

  If the Services attribute does not include the value SMTP, run the following Exchange Management Shell command:

  Enable-ExchangeCertificate -Thumbprint <insert_certificate_thumbprint> -Services:SMTP

  Note   This command will append SMTP to any services already enabled on the certificate. It will not remove any existing services.

• Determine whether the Network Service account has the correct permissions. Make sure that the Network Service has Read permissions on all the keys in the following directory: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys, where C:\ is the directory to which Exchange 2010 was installed.

  Note   Filemon can also be used to determine whether this is a permissions issue.

  Start Filemon and capture the occurrence of the error. Review the resulting log file for any access denied events. Verify that the parameters configured in DNS machine configuration match the criteria being used in the internal transport certificate validation process. The DNS machine configuration should be checked against the self-signed certificate installed by Exchange server as this is the certificate we expect to use for direct trust purposes.

• If the Exchange server is running in an NLB environment, an unexpected FQDN may be added during the certificate validation process. If you notice an unexpected domain, check the NLB configuration to see whether the unexpected domain is configured there. If the NLB configuration contains the unexpected FQDN, modify the NLB configuration so that it does not cause the certificate validation to fail.

For more information, see the following topics:

• Общие сведения о сертификатах TLS

• Устранение ошибок при проверке сертификатов

For More Information

Если вы еще не сделали этого, используйте средства Exchange, созданные специально для анализа и устранения неполадок в среде Exchange. Они позволят проверить, соответствует ли конфигурация организации рекомендациям корпорации Майкрософт. Они также помогут найти и устранить проблемы с производительностью и улучшить организацию потока обработки почты. Чтобы запустить эти средства, перейдите на узел Инструменты в консоли управления Exchange. Дополнительные сведения об этих инструментах см. в разделе Управление средствами в меню «Инструменты».