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 that is 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 2007 computer. For more information about pipeline tracing, see Using Pipeline Tracing to Diagnose Transport Agent Problems.
  
  

Content conversion creates a folder named ContentConversionTracing inside the path that is 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 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 that are required on the folders and subfolders that are used in content conversion tracing are as follows:

• Administrators: Full Control
  
  
• Network Service: Full Control
  
  
• System: Full Control
  
  

Caution:
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.

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, and the conversion options and message size limits that are 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 Office Outlook message format.
  
  
• <GUID>.txt   This file contains the exception description, conversion results, and the conversion options and message size limits that are 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 is used in the file names of the corresponding message and text files. An example of a GUID that is used in the file names is 038b930e-61fd-4bfd-b9b4-0374c18b73f7.

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 (DoS) attacks. 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 that are 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 that are used in Hub Transport servers or Edge Transport servers, see Managing 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 do not 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 message   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 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.

For more information, see the following topics:

• Understanding Content Conversion
  
  
• TNEF Conversion Options
  
  
• Message Encoding Options