MSExchangeTransport 17020

Letztes Änderungsdatum des Themas: 2011-03-19

Dieser Artikel bietet eine Erläuterung und mögliche Lösungen für ein bestimmtes Exchange-Ereignis. Wenn Sie hier das Gesuchte nicht finden können, durchsuchen Sie die Exchange 2010-Hilfe.

Details

Explanation

This Error event indicates that the Microsoft Exchange Transport service experienced an unrecoverable error during message processing on a Hub Transport server or on an Edge Transport server.

Starting with Microsoft Exchange Server 2007, the Microsoft Exchange Transport service uses an Extensible Storage Engine (ESE) database for mail queue storage. This design change improves read and write performance with respect to messaging queues and also lets the messaging queues be backed up. The message queue database and the Content Filtering database use circular logging. Therefore, you can't use the transaction logs for data recovery. Additionally, the transaction logs are re-created automatically during the startup of the Microsoft Exchange Transport service if they are missing. By default, the Microsoft Exchange Server 2010 Transport database files are located in the following directory:

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

The Transport database consists of the following files:

• Mail.que: The ESE database
• Tmp.edb: The temporary workspace for processing transactions
• Trn.log: The current transaction log file
• Trntmp.log: The temporary transaction log file
• Trn.chk: The database checkpoint file
• Trnres00001.jrs: The first transaction reserve file
• Trnres00002.jrs: The second transaction reserve file

When a message is received in the Transport pipeline, the page that requires updating is read into memory and the changes are recorded in the ESE cache. The version store component tracks the uncommitted changes. This operation is then recorded in a transaction log file on the hard disk. When the log file becomes full, a new log file is created. Finally, the page is committed to the mail.que file and the checkpoint is advanced to record the committed transaction.

If these files become damaged or if the Microsoft Exchange Transport service cannot access them, the Microsoft Exchange Transport service shuts down.

Because of this, the Microsoft Exchange Transport service includes a "self healing" feature that is designed to enable Exchange to recover from most of the issues that could cause the Transport database to fail. These include the following issues:

• Logical database corruption: When the Microsoft Exchange Transport service detects a "JET permanent exception" error that specifies database corruption, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.
• File(s) not available: When the Microsoft Exchange Transport service detects a "JET permanent exception" error that specifies missing or locked database files, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.
• Insufficient disk space: When the Microsoft Exchange Transport service detects a "JET permanent exception" error that specifies insufficient disk space, the service does not perform any recovery actions. For example, the error might specify that the database cannot be extended or that a log file cannot be created. In this scenario, the service shuts down.
• Database upgrade: When the Microsoft Exchange Transport service experiences a database version error, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.
• Failed server disk replaced: When the Microsoft Exchange Transport service first starts after a failed hard disk has been replaced, the service detects a "JET permanent exception" error that specifies physical database corruption. In this scenario, the service performs recovery actions. These actions either delete or move the database queue file, log files, or system directories. After the recovery actions are completed, the service creates a new database instance to continue message processing.

The recovery actions may be modified by changing the value of the following key in the %ProgramFiles%\Microsoft\Exchange Server\V14\Bin\EdgeTransport.exe.config file:

<add key="QueueDatabaseRecoveryAction" value="<action>" />

The following action values are available:

• None: When this action is specified, the Microsoft Exchange Transport service does not try to recover. The service logs the database exception to the Application log and remains stopped until the Transport database is either repaired or deleted and the service restarted.
• Delete: When this action is specified, the Microsoft Exchange Transport service deletes the existing mail.que database and associated log files. Then, when the Microsoft Exchange Transport service starts, it creates new database and transaction log files.
  Note   With this action, any messages that are stuck in the messaging queues are lost.
• Move: When this action is specified, the Microsoft Exchange Transport service moves the existing transport database and log files to a directory named %ProgramFiles%\Microsoft\Exchange Server\V14\TransportRoles\Queue\Queue.old. When the Microsoft Exchange Transport service starts, it creates new database and transaction log files.

This Error event may occur when one of the following conditions are true:

• The Microsoft Exchange Transport service cannot process a particular message. This may be a damaged message or a very large message, such as a message that is 100 MB or 1 GB large.
• The Transport database has become corrupted. This issue may occur when a file-level antivirus program does not have exclusions configured for the Exchange-related files.

For more information, see Grundlegendes zu Transportwarteschlangen.

User Action

To troubleshoot this issue, do one or more of the following:

• Überprüfen Sie das Anwendungsprotokoll und das Systemprotokoll auf den Exchange 2010-Servern auf verwandte Ereignisse. Ereignisse, die unmittelbar vor oder nach diesem Ereignis auftreten, können z. B. weitere Informationen zur eigentlichen Ursache dieses Fehlers zur Verfügung stellen.
• If a file-level antivirus scanner is running, verify that antivirus exclusions are configured appropriately. For more information, see Antivirenscans auf Dateiebene für Exchange 2010.
• You may want to increase diagnostics logging to log the components in the transport pipeline. To increase diagnostics logging for the Transport components, follow these steps:
  1. In the Exchange Server 2010 Management Console, expand Server Configuration, and then click Hub Transport.
     Note   For an 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, and then click Expert, then click Configure for each component:
  • Smtpreceive
  • Smtpsend
  • DSN
  • Components
  • Remote Delivery
  • Categorizer
• 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.
  4. Try to repair the Transport database to recover any queued messages. For more information, see Working with the Queue Database on Transport Servers.
• Examine the Application log for backpressure-related events. These events may indicate that the Microsoft Exchange Transport service is trying to process a very large message. To troubleshoot this issue, follow these steps:
  1. Start the Microsoft Exchange Transport service, and then pause the service. This action causes the Microsoft Exchange Transport service to stop accepting new messages for processing.
  2. Use the Queue Viewer tool in the Toolbox node of the Exchange Management Console or from the Exchange Management shell to suspend the queues. For more information, see Anhalten von Warteschlangen.
  3. Export the messages from the queues. To do this, run the following command from the Exchange Management Shell:
     Get-Message -Queue "Queue Identity" |export-message -path "<drive>:\<folderName>"
  4. Stop the Microsoft Exchange Transport service.
  5. Rename the Queue folder located in the %ProgramFiles%\Microsoft\Exchange Server\V14\TransportRoles\data directory, and then create a new Queue folder.
  6. Start the Microsoft Exchange Transport service.
• Use the ExLogAnalyzer tool to parse the Exchange Message Tracking log files to determine whether one or more users are sending messages that are larger than the maximum allowed size in Exchange. For example, mail clients that are earlier than Microsoft Outlook 2003 SP3 do not recognize maximum message limits in Exchange 2010. For more information about how to obtain the ExLogAnalyzer tool, see Making sense of Exchange Logs using ExLogAnalyzer.
  If a message in a queue is larger than the maximum message size, use the steps in the previous step to pause the Microsoft Exchange Transport service, export the queues, and then create a new Queue folder.
• If the large stuck message is a non-delivery report to a sender, follow these steps:
  1. Disable the user's mailbox.
  2. Stop the Microsoft Exchange Transport service.
  3. Rename the Queue folder.
  4. Start the Microsoft Exchange Transport service, and then re-enable the mailbox.
• If the issue occurs again after you clear the queues and create a new Queue database folder, a large message may be stuck in submission from a particular user. To troubleshoot this issue, follow these steps:
  1. Follow the steps listed to pause the Microsoft Exchange Transport service, clear the queues, and create a new Queue folder.
  2. Start the Microsoft Exchange Transport service and pause the Submission queue. If the issue no longer occurs, the issue is likely caused by a large message submission.
  3. Use the ExLogAnalyzer tool to examine the message tracking logs to determine which user's mailbox submitted the message.
  4. Disable the user's mailbox, and then un-pause the Submission queue.
  5. Examine the contents of the user's mailbox to determine whether a large message is stuck in the Outbox folder.
• Lösen Sie Ihr Problem über die Optionen zur Selbsthilfe, die Optionen für technischen Support und andere Ressourcen. Sie können auf diese Ressourcen über das Exchange Server Solutions Center (möglicherweise in englischer Sprache) zugreifen. Klicken Sie auf dieser Seite im Navigationsbereich auf Optionen zur Selbsthilfe, um die Optionen zur Selbsthilfe zu verwenden. Zu den Optionen zur Selbsthilfe gehört das Durchsuchen der Microsoft Knowledge Base, das Stellen einer Frage in den Exchange Server-Foren und andere Methoden. Alternativ können Sie im Navigationsbereich auf Optionen für technischen Support klicken, um Kontakt mit einem Microsoft-Supportspezialisten aufzunehmen. Da es in Ihrer Organisation ein bestimmtes Verfahren für den direkten Kontakt mit dem Microsoft-Produktsupport geben kann, sollten Sie zuerst die Richtlinien Ihrer Organisation prüfen.

For more information about the transport pipeline in Exchange 2010, see Grundlegendes zur Transportpipeline.

To obtain transport architecture diagrams, see the Exchange Server Team blog article, Exchange 2010 Transport Architecture Diagrams Available for Download.

Der Inhalt jedes Blogs und die dazugehörige URL kann ohne vorherige Ankündigung geändert werden. Der Inhalt jedes Blogs wird "WIE BESEHEN" ohne Gewährleistungen bereitgestellt und überträgt keine Rechte. Die Verwendung der enthaltenen Skriptbeispiele unterliegt den in den Nutzungsbestimmungen angegebenen Bedingungen.