winmail.dat attachment being created on email inbound action in Production instance

Mikolz
Kilo Contributor

All,

 

We recently upgraded to Calgary a few weeks ago (All 3 instances). We have noticed that that on inbound email actions, a winmail.dat attachment is being created each time. This is only happening in our Production instance making it difficult to pinpoint the exact issue. Our email is handled via Office 365 (in the cloud). I have taken a look at the Headers for an email pre-upgrade and post-upgrade to compare. Everything is same except for the attributes on the ContentType. They are as follows...

 

Good - Pre-Upgrade

 

MultipartContentTypes:text/plain; charset="us-ascii";application/ms-tnef; name="winmail.dat";

 

Bad - Post-Upgrade

 

MultipartContentTypes:text/plain; charset="utf-8";application/ms-tnef; name="winmail.dat";

 

Only thing that appears to be different is the charset. I am not even sure if this is the cause for the issue, but its the only difference that I can locate. I know there is a knowledge article on HI that states to change a setting on the Microsoft Exchange Servers, but being on a cloud solution -   this is a bit of a problem. And this doesn't explain why it is working fine in our development and quality instances. Any thoughts would be much appreciated.

 

Thanks

1 ACCEPTED SOLUTION

Hi Mikolz,


We also faced a similler issue.


Please find below link which will be very helpful to bresolve your issue.


ServiceNow Customer Service Systemhttps://hi.service-now.com/kb_view.do?sysparm_article=KB0529478&sysparm_search=winmail.dat


Configure the local Outlook client or Exchange server to not send Rich Text formatted (RTF) data to ServiceNow instances.
To prevent Windows email from containing a winmail.dat file, see Microsoft   KB 278061 for information on configuring Outlook or Microsoft KB 138053 for information on configuring Exchange.


PLease find attachment to change the setting in Outlook properties.



Cause:


Microsoft Outlook sometimes sends e-mails in the Transport Neutral Encapsulation Format (TNEF). ServiceNow does not understand TNEF. This only happens when a contact for your ServiceNow instance's email address exists in Exchange, and has been configured to use MAPI rich text format.



Resolution:


To prevent this, you need to configure the Exchange server to not send Rich Text formatted (RTF) data to ServiceNow instances.


  1. Log in to your Exchange Server 2010 by opening the Exchange Management Console (EMC).
  2. Expand Microsoft Exchange On-Premise…
  3. Expand Recipient Configuration.
  4. Select Mail Contact.
  5. Find the contact that represents your ServiceNow instance email (e.g., the one that sends emails to <instancename>@service-now.com).
  6. In our example, we will assume the contact is named Marketing Requests (yours will be named differently).
  7. Open Marketing Requests Properties.
  8. Select the General tab.
  9. In the Use MAPI rich text format field, select Never.
  10. Click OK

View solution in original post

4 REPLIES 4

Sharon Gaudino
Tera Contributor

We just ran into this same issue. In searching for a resolution, I found a knowledge article in the HI knowledge base that addresses this issue. If you log into HI and search the knowledge base for "winmail.dat" you will find it.



If you don't have access to HI, here's the info:



Cause:


Microsoft Outlook sometimes sends e-mails in the Transport Neutral Encapsulation Format (TNEF). ServiceNow does not understand TNEF. This only happens when a contact for your ServiceNow instance's email address exists in Exchange, and has been configured to use MAPI rich text format.



Resolution:


To prevent this, you need to configure the Exchange server to not send Rich Text formatted (RTF) data to ServiceNow instances.


  1. Log in to your Exchange Server 2010 by opening the Exchange Management Console (EMC).
  2. Expand Microsoft Exchange On-Premise…
  3. Expand Recipient Configuration.
  4. Select Mail Contact.
  5. Find the contact that represents your ServiceNow instance email (e.g., the one that sends emails to <instancename>@service-now.com).
  6. In our example, we will assume the contact is named Marketing Requests (yours will be named differently).
  7. Open Marketing Requests Properties.
  8. Select the General tab.
  9. In the Use MAPI rich text format field, select Never.
  10. Click OK

Hi Mikolz,


We also faced a similler issue.


Please find below link which will be very helpful to bresolve your issue.


ServiceNow Customer Service Systemhttps://hi.service-now.com/kb_view.do?sysparm_article=KB0529478&sysparm_search=winmail.dat


Configure the local Outlook client or Exchange server to not send Rich Text formatted (RTF) data to ServiceNow instances.
To prevent Windows email from containing a winmail.dat file, see Microsoft   KB 278061 for information on configuring Outlook or Microsoft KB 138053 for information on configuring Exchange.


PLease find attachment to change the setting in Outlook properties.



Cause:


Microsoft Outlook sometimes sends e-mails in the Transport Neutral Encapsulation Format (TNEF). ServiceNow does not understand TNEF. This only happens when a contact for your ServiceNow instance's email address exists in Exchange, and has been configured to use MAPI rich text format.



Resolution:


To prevent this, you need to configure the Exchange server to not send Rich Text formatted (RTF) data to ServiceNow instances.


  1. Log in to your Exchange Server 2010 by opening the Exchange Management Console (EMC).
  2. Expand Microsoft Exchange On-Premise…
  3. Expand Recipient Configuration.
  4. Select Mail Contact.
  5. Find the contact that represents your ServiceNow instance email (e.g., the one that sends emails to <instancename>@service-now.com).
  6. In our example, we will assume the contact is named Marketing Requests (yours will be named differently).
  7. Open Marketing Requests Properties.
  8. Select the General tab.
  9. In the Use MAPI rich text format field, select Never.
  10. Click OK

This worked perfectly for us.



Thank you.



RV


Mikolz
Kilo Contributor

Thank you for your time and responses. We entered a support ticket with Microsoft, and although the knowledge article did not apply to our environment 100% correctly, Microsoft was able to determine a solution to the problem.