MSExchangeTransport 12026

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 Error event indicates that message processing is 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.

• Increase diagnostics logging to log the components in the transport pipeline. To do this, follow these steps:

  1. In the Exchange Management Console, expand Server Configuration, and then click Hub Transport.

     Note   For and Edge Transport server, click Edge Transport.

  2. In the Actions pane, click Manage Diagnostic Logging Properties for the appropriate server.

  3. Expand MSExchangeTransport.

  4. Click the following components, click Expert, then click Configure for each component:

  • 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, and then determine whether the issue is resolved.

• If creating a new Transport database resolves the issue, try to repair the damaged Transport database to recover any queued messages. For more information, see Working with the Queue Database on Transport Servers. Specifically, move the Transport database files to a working location, and use the Eseutil tool to perform the following actions against the original Transport database files:

  1. Run the following command to dump the database headers. Then, view the results to determine whether the Mail.que database is in a dirty shutdown state.

     Eseutil /mh mail.que

  2. If the database is in a dirty shutdown state, run the following command to replay any outstanding transaction logs:

     Eseutil /r trn

  3. If MsExchangeTransport Event ID 17011 is logged to indicate that the checkpoint file is damaged, remove the .chk file, and then run the Eseutil /r trn command to replay the transaction log files.

  4. Run the following command to defragment the database:

     Eseutil /d mail.que

  5. Restore the database files to their original location. Use the steps in the Working with the Queue Database on Transport Servers topic to do this. For example:

  • Pause the Microsoft Exchange Transport service.

  • Use the Queue Viewer tool to verify that all Transport queues have emptied or export any messages that have not emptied.

  • Stop the Microsoft Exchange Transport service.

  • Replace the new database files with the original files, and then start the Microsoft Exchange Transport service.

• 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 the issue is resolved.

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

     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.