I had not seen this issue for a long time. However, I received an email from a client recently telling me that his recipients using Apple Macs could not open his attachments, as they were received as WINMAIL.DAT files.
This is due to Office365 setting the default attachment format to TNEF. This format causes issues with mail clients that are unable to read this attachment format, thus creating the WINMAIL.DAT issue.
The solution is to use PowerShell to make changes to the Office365 account. Refer to my previous post here on how to set up PowerShell for Office365.
- $Cred = Get-Credential
- Connect-msolservice -credential $Cred
- Type in your Office365 admin user credentials
- $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Cred -Authentication Basic -AllowRedirection
- Import-PSSession $Session
- Set-RemoteDomain Default -TNEFEnabled $false
- Remove-PSSession $Session
That should do the trick. The Microsoft help article documenting this can be found here – http://help.outlook.com/140/gg263346.aspx
[Edit 11 May 2015: Changed commands for connecting to Office365]
11 thoughts on “Fixing the WINMAIL.DAT attachment problem in Office365”
Thanks for the assist, this was exactly what I was looking for. No more winmail.dat files, thank goodness.
I wish I could be impressed with Microsoft developers just once. But stupid (very stupid) stuff like this always leaves me shaking my head at their nincompoop programmers. I won’t even call them “Engineers”, which are an entirely different class of skill than what Microsoft seems to employ.
Come on! This is basic stuff, yet M$ seems to consistently get it wrong.
Actually guys Microsoft is just fine on this one, I think you are misunderstanding this.
The default setting is $null, which means that the server defers to each sender. You setting TNEF to disabled actually prevents any of your users from using this feature if they so choose. That might be fine in a tiny organization but Microsoft is completely correct with their default setting.
The fix documented in this approach is a “sledgehammer” fix, most organizations are going to want to keep the TNEF setting at the default.
This may be the case but it’s not that useful or practical. So what would you do to solve this problem when changing settings in the sender’s Outlook doesn’t work and your clients have to install software just to look at your emails?
Doesnt works error in command with godaddy office 365
The commands for connecting to the Office365 portal have changed. I have updated the post.
Can you help me a bit? I saw a video on youtube from 2012:
It said you can just use the native powershell on win 7? (I had followed your link to your other doc but the link to download the online service module was a broken link… as is the link above about the microsoft help article).
I had sent a PDF to my outside domain webmail before this and got the windata.dat. then I used your commands above with the native win 7 powershell.
is there some time to wait for it to take effect? Reboot the desktop? Open / close outlook? I sent another PDF a few minutes later and it still only had the winmail.dat.
Any thoughts on where I screwed up?
Thanks for taking the time to blog!!
I reran the process and for the command:
PS C:\Windows\system32> Set-RemoteDomain Default -TNEFEnabled $false
I got this:
WARNING: The command completed successfully but no settings of ‘Default’ have been modified.
Would you think that’s because I already made that change?
And 5 minutes later, now it’s working. THANKS! Do I dare admit – this was my first dealings with PowerShell! Thanks for the hand holding!
This is exactly what I was looking for. Thank you….
This can be resolved through the Office 365 GUI by editing your exchange settings and disabling Rich Text format for the * domain (all).