Share via

Content Conversion Tracing

  • Article

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Content conversion tracing captures failures in the content conversion that's performed by the store driver on inbound and outbound messages on a computer running Microsoft Exchange Server 2010 that has the Hub Transport server role installed.

The categorizer on a Hub Transport server is responsible for the content conversion of all messages sent to external recipients. However, the store driver on a Hub Transport server is responsible for the content conversion of messages sent to and from mailbox recipients. Specifically, the store driver must convert outbound messages from mailbox users from MAPI to MIME. The store driver must also convert inbound messages for mailbox users from MIME to MAPI. Content conversion tracing is responsible for capturing these MAPI conversion failures. Content conversion tracing doesn't capture any content conversion failures that the categorizer encounters as it converts messages sent to external recipients.

Contents

Configuring Content Conversion Tracing

How Content Conversion Tracing Works

Considerations for Content Conversion Tracing

Configuring Content Conversion Tracing

Content conversion tracing is controlled by the following parameters in the Set-TransportServer cmdlet in the Exchange Management Shell:

  • ContentConversionTracingEnabled   This parameter enables or disables content conversion. Valid values for this parameter are $True and $False. The default value is $False. If the Exchange organization contains multiple Hub Transport servers, you must enable content conversion tracing on each Hub Transport server responsible for delivery of messages to Mailbox servers.

  • PipelineTracingPath   Although this parameter is associated with pipeline tracing, it also specifies the root location of the content conversion tracing files. By default, the value of the PipelineTracingPath parameter is C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing. The path must be local to the Exchange 2010 computer.

Content conversion creates a folder named ContentConversionTracing inside the path specified by the PipelineTracingPath parameter. Inside the ContentConversionTracing folder, content conversion creates two subfolders: InboundFailures and OutboundFailures. The InboundFailures folder contains the information from inbound message content conversion failures. The OutboundFailures folder contains the information from outbound message content conversion failures.

The maximum size for all the files in the InboundFailures folder is 128 megabytes (MB). The maximum size for all the files in the OutboundFailures folder is 128 MB. The content conversion tracing directories don't use circular logging to remove old files, depending on the age or size of the files. As soon as the maximum size for a folder is reached, content conversion tracing stops writing information to the folder. If you want to make sure that the maximum folder size limits aren't exceeded, you can create a scheduled task that periodically moves the content conversion tracing files to a different location.

The permissions required on the folders and subfolders used in content conversion tracing are as follows:

  • Administrators: Full Control

  • Network Service: Full Control

  • System: Full Control

Warning

Content conversion tracing copies the complete contents of e-mail messages. To avoid unwanted exposure of confidential information, you must set appropriate security permissions on the location of the content conversion tracing files.

Return to top

How Content Conversion Tracing Works

When the content conversion of an inbound message fails, a delivery status notification (DSN) that has the status code 5.6.0 is sent to the message sender. If content conversion tracing is enabled, the failure information is recorded at the time that the 5.6.0 DSN message is generated. Each content conversion error generates two separate files.

A content conversion error that occurs when an inbound message is converted from MIME to MAPI generates the following two files in the InboundFailures folder:

  • <GUID>.eml   This file contains the failed message in text format.

  • <GUID>.txt   This file contains the exception description, conversion results, conversion options, and message size limits imposed on all messages by the store driver.

A content conversion error that occurs when an outbound message is converted from MAPI to MIME generates the following two files in the OutboundFailures folder:

  • <GUID>.msg   This file contains the failed message in the Microsoft Outlook message format.

  • <GUID>.txt   This file contains the exception description, conversion results, conversion options, and message size limits imposed on all messages by the store driver.

The placeholder <GUID> is the same in both file names. Each content conversion error generates a different GUID that's used in the file names of the corresponding message and text files. An example of a GUID that's used in the file names is 038b930e-61fd-4bfd-b9b4-0374c18b73f7.

Return to top

Considerations for Content Conversion Tracing

You can leave content conversion tracing enabled for proactive monitoring. Or, you can enable content conversion tracing to troubleshoot a specific failure event. You can usually reproduce inbound content conversion failures by asking the recipient of the 5.6.0 DSN message to resend the original message.

Inbound content conversion failures are the most common. Some of the reasons for inbound content conversion errors include the following:

  • Violations of message size limits These message size limits are imposed by the store driver to help prevent denial of service attacks (DoS). These message limits are listed in the <GUID>.txt file. These message limits include the following:

    • MaxMimeTextHeaderLength   This limit specifies the maximum number of text characters that can be used in a MIME header. The value is 2000.

    • MaxMimeSubjectLength   This limit specifies the maximum number of text characters that can be used in the subject line. The value is 255.

    • MSize   This limit specifies the maximum message size. The value is 2147483647 bytes.

    • MaxMimeRecipients   This limit specifies the total number of recipients allowed in the To, Cc, and Bcc fields. The value is 12288.

    • MaxRecipientPropertyLength   This limit specifies the maximum number of text characters that can be used in a recipient description. The value is 1000.

    • MaxBodyPartsTotal   This limit specifies the maximum number of message parts that can be used in a MIME multipart message. The value is 250.

    • MaxEmbeddedMessageDepth   This limit specifies the maximum number of forwarded messages that can exist in a message. The value is 30.

    For more information about configurable message size limits used in Hub Transport servers or Edge Transport servers, see Understanding Message Size Limits.

  • Failure to convert an inbound iCalendar message to a meeting request   RFC 2445 defines iCalendar as a standard for calendar data exchange. Specific causes of the conversion failure include the following:

    • Incorrect use of iCalendar by the sending agent.

    • Constructs of iCalendar that can't be supported by the Outlook or Exchange calendar schema.

    Conversion failures of iCalendar don't result in the sender receiving a 5.6.0 DSN message. Instead, the message is delivered with an attached .ics file that contains the iCalendar message body.

  • Failures caused by badly formatted MIME messages   Unsolicited commercial e-mail or spam messages may have formatting errors in the message header, such as unmatched quotation marks in recipient descriptions. A much smaller number of failures caused by badly formatted MIME messages are considered bugs.

Outbound content conversion failures are much less common than inbound failures. When outbound failures occur, they are usually caused by Exchange code bugs or corrupted message content.

Return to top

 © 2010 Microsoft Corporation. All rights reserved.