MSExchangeTransport 12028

上一次修改主题： 2012-09-19

本文对特定 Exchange 事件进行了说明并提供了可能的解决方案。如果您在此处未找到所需内容，请尝试在 Exchange 2010 帮助中进行搜索。

Details

Explanation

This Warning event indicates that message processing has become stuck or is delayed in one of the transport messaging queues.

Microsoft Exchange Server 2010 uses an ESE database to store messages for routing throughout an Exchange organization. On servers that run the Edge Transport role, the database queues those messages that are received from or are directed to the Internet. On servers that run the Hub Transport role, the database queues those messages that are transferred throughout the Exchange organization. Exchange 2010 includes the following transport queues:

• Submission queue

• Mailbox delivery queue

• Remote delivery queue

• Poison message queue

• Unreachable queue

The Microsoft Exchange Transport service automatically creates these queues on an as-needed basis for temporary message storage.

This event indicates that a performance issue may affect the Microsoft Exchange Transport service (MSExchangeTransport.exe) or that a message or the transport database, Mail.que, may be corrupted. In this scenario, you may experience the following symptoms:

• The EdgeSync service (Microsoft.Exchange.EdgeSyncSvc.exe) uses a lot of CPU resources.

• Mail flow to and from the Internet may stop, and messages may become queued for remote delivery.

The Microsoft Exchange Transport service controls the sending and receiving of messages in Exchange 2010. This issue may occur if the Transport service cannot process a message for local or remote delivery. If the message cannot be processed, it may become stuck in a particular transport queue. For more information about the transport architecture in Exchange 2010, see Understanding Transport Architecture.

User Action

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

• 有关相关事件，请查看 Exchange 2010 服务器上的应用程序日志和系统日志。例如，在此事件之前和之后发生的事件可能会提供有关导致出现此错误的根本原因的详细信息。

• Review the Operations Console in Operations Manager for detailed information about the cause of this problem. For more information, see the "Introduction" section in this article.

• You may have to increase diagnostics logging to log the component startup sequence during the startup process of the Microsoft Exchange Transport service. To increase diagnostics logging for the Transport component, follow these steps:

  1. In Registry Editor, locate the following registry subkey:

     HKEY_LOCAL_MACHINE\SYSTEM\Current Control set\Services\MSExchangeTransport\diagnostics

  2. Set the following REG_DWORD values to 7:

     • Smtpreceive

     • Smtpsend

     • DSN

     • Components

     • Remote Delivery

     • Categorizer

• Examine the Application log to determine whether message processing has become stuck. For example, look for event descriptions that resemble the following:

  System.InvalidOperationException: This kind of next hop solution should not be shadowed. Delivery Type : 'SmtpRelayToTiRg'

• Determine whether the transport database is corrupted. To do this, follow these steps:

  1. Stop the Microsoft Exchange Transport service.

  2. Remove the transport database. To do this, rename the following folder:

     %ProgramFiles%\Microsoft\Exchange Server\V14\TransportRoles\data\Queue

  3. Start the Microsoft Exchange Transport service to determine whether mail flow is restored.

• Determine whether a public folder replication issue could cause the message processing problem. To do this, follow these steps:

  1. In the Exchange Management Shell, run the following command to suspend public folder replication on the affected server:
     Suspend-PublicFolderReplication

  2. Run the following command to disable the Shadow Redundancy feature:
     Set-TransportConfig -ShadowRedundancyEnabled $false

  3. Stop the Microsoft Exchange Transport service.

  4. Rename the folder in which the transport database is located. By default, the transport database is located in the following folder:

     %ProgramFiles%\Microsoft\Exchange Server\V14\TransportRoles\data

  5. Start the Microsoft Exchange Transport service, and determine whether mail flow is restored.

     Note   Re-enable Shadow Redundancy after mail flow has been restored.

• Determine whether the following conditions are true:

  • Legacy mailboxes that have unsupported SMTP addresses exist in the organization.

  • Exchange 2010 message journaling is enabled.

  In this scenario, Exchange 2010 journaling may be unable to process unsupported SMTP addresses that may exist on legacy mailboxes. For example, a message that uses an IP literal SMTP address such as user1@[192.168.0.2]. To resolve this issue, remove the unsupported SMTP addresses.

• Determine whether an invalid public folder replica object exists. To do this, use the Queue Viewer tool in the Exchange 2010 Toolbox to view the Poison queue. Determine whether the Poison queue contains messages sent to a public folder that no longer exists. In this scenario, remove the invalid public folder replica from the Exchange 2010 server. To do this, follow these steps:

  1. Start the Exchange Management Console, and then open the Public Folder Management Console from the Exchange Toolbox.

  2. Locate the public folder, right-click it, and then click Properties.

  3. Click the Replication tab, and then remove any invalid public folder replicas. For example, remove any public folder replicas that represent servers that no longer exist in the organization.

  4. Run public folder replication to propagate the changes among the servers in the organization.

• To determine whether the issue is caused by excessively large e-mail messages that are being processed, follow these steps:

  1. Identify the mailbox or mailboxes from with the messages originate. In this scenario, the messages will be in the process of being submitted. To locate the mailbox or mailboxes, use the Process Tracking log tool (Processtrackinglog.vbs). For more information about how to obtain and run the tool, see Exchange Server 2007 Process Tracking Log Tool and also see the Exchange Server Team blog article, Process Tracking Log tool for Exchange Server 2007.

     Look for entries that resemble the following:

     User1@contoso.com <mailto:User1@contoso.com> submitted a message multiple times that resulted in NDR - Size is 1303445440 bytes and sender is <> (Postmaster for NDR)

  2. Disconnect the mailbox or mailboxes that are stuck in submission, and then determine whether the Microsoft Exchange Transport service starts successfully.

• 使用自助支持选项、协助支持选项及其他资源来解决您的问题。您可以从 Exchange Server 解决方案中心访问这些资源。在该页中，单击导航窗格中的“自助支持选项”可使用自助服务选项。自助服务选项包括搜索 Microsoft 知识库、在 Exchange Server 论坛上发布问题及其他方法。或者，您可以在导航窗格中单击“协助支持选项”来联系 Microsoft 支持专业人员。由于您的组织可能已有直接与 Microsoft 产品支持服务联系的特定流程，因此，请您务必先查看您组织的准则。

For More Information

如果您尚未执行此操作，请考虑运行 Exchange 工具，已创建这些工具以帮助您分析 Exchange 环境并对其进行疑难解答。这些工具可帮助确保您的配置与 Microsoft 最佳实践保持一致。它们还可以帮助您识别和解决性能问题，并改进邮件流。若要运行这些工具，请转到 Exchange 管理控制台的“工具箱”节点。若要了解有关这些工具的详细信息，请参阅管理工具箱中的工具。