MSExchangeTransport 12028

This article provides an explanation and possible resolutions for a specific Exchange event. If you don't find what you’re looking for here, try searching Exchange 2010 Help.

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:

• Review the Application log and System log on your Exchange 2010 servers for related events. For example, events that occur immediately before and after this event may provide more information about the root cause of this error.

• 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.

• Resolve your issue by using self-support options, assisted support options, and other resources. You can access these resources from the Exchange Server Solutions Center. From this page, click Self-Support Options in the navigation pane to use self-help options. Self-help options include searching the Microsoft Knowledge Base, posting a question at the Exchange Server forums, and other methods. Alternatively, in the navigation pane, you can click Assisted Support Options to contact a Microsoft support professional. Because your organization may have a specific procedure for directly contacting Microsoft Product Support Services, be sure to review your organization's guidelines first.

For More Information

If you are not already doing so, consider running the Exchange tools, which have been created to help you analyze and troubleshoot your Exchange environment. These tools can help make sure that your configuration aligns with Microsoft best practices. They can also help you identify and resolve performance issues and improve mail flow. To run these tools, go to the Toolbox node of the Exchange Management Console. To learn more about these tools, see Managing Tools in the Toolbox.