Winmail.dat attachment

Content-Type: application/ms-tnef; name="winmail.dat"

Winmail.dat attachment – One of my user sending emails from Outlook application and Exchange online office365 complains the recipient is receiving a winmail.dat attachment in every email she sends to one specific recipient domain, however, the same email is received by yahoo and other email domain without any winmail.dat attachment. Sender has tried setting her outlook to ensure ‘only plain text’ is used when composing email but still recipient is getting winmail.dat. So why is this one specific recipient domain getting winmail.dat attachments even when outlook has been set to use only plain text?

Solution:

1. Make sure to get more details if you can about the recipient domain mail system, for me I found out from their website that they recommend ‘plain text’ emails over html or rich text, as their mail system can have problems decoding other mail formats.

2. Check the message email headers of your sender, you can see the content-type showing “winmail.dat” instead of content-type “plain text” :-

Content-type in Message header of email sent that contains winmail.dat:-

Content-Type: application/ms-tnef; name="winmail.dat"

Content-type in Message header of email sent that uses plain text and does not contain winmail.dat:-

Content-Type: text/plain; charset="us-ascii"

3. What is winmail.dat?

Outlook and Exchange uses the Transport Neutral Encapsulation Format (TNEF) format for your emails that contains rich text format (RTF), RTF files offer some formatting features like bold, italic, underline, bullets, different fonts, and text justification. Messaging systems that aren’t based on Microsoft Exchange may be unable to interpret messages that use this rich text format. If the recipient’s messaging system can’t process this format, a file attachment that’s called Winmail.dat is added to the message.

Note: By default, email messages that are sent from Exchange Online in Office 365 use the Transport Neutral Encapsulation Format (TNEF) format

4. If your recipient domain email system cannot decipher TNEF and a winmail.dat is received, then Office 365 admins can use Exchange online PowerShell to change the message format to prevent the Winmail.dat attachment from being sent to those external recipients. To do this:-

Connect to Office365 Exchange Online using Remote PowerShell

  1. Run the following Windows PowerShell commands to configure the message format as plain Text Only for a specific external recipient:
Set-MailContact <ExternalEmailAddress or GUID> -UseMapiRichTextFormat Never
Set-MailContact -Identity <ExternalEmailAddress or GUID> -UsePreferMessageFormat $True 

Run the following Windows PowerShell command to confirm that the message format was applied:-

Get-MailContact | Select <ExternalEmailAddress or GUID> | Select UseMapiRichTextFormat

2. To Change the message format for all messages that are sent to a specific domain
This method requires you to create a remote domain object in Exchange Online to control how messages are sent to external domains. You can also use this method to change the message format for messages that are sent to coexistence domains.

Connect to Office365 Exchange Online using Remote PowerShell

Run the following Windows PowerShell command to create a remote domain for an external domain:

New-RemoteDomain -Name <Name of External Domain> -DomainName 

Run the following Windows PowerShell command to prevent messages from being sent in rich text format:

Set-RemoteDomain -Identity <Name of Domain> -TNEFEnabled $false 

Run the following WindowsPowerShell command to check that the setting was applied:

Get-RemoteDomain -Identity <Name of Domain>| Select TNEFEnabled 

More info on Microsoft docs – https://docs.microsoft.com/en-us/exchange/mail-flow/content-conversion/tnef-conversion?view=exchserver-2019

MailNonUniversalGroup – Distribution List

Happy New year 2020. I wish you more progress this year from where you left off last year. Now let’s dive right to our topic on MailNonUniversalGroup distribution list. So i had a case where users where complaining of not receiving emails sent to a distribution list. After several minutes tracing the messages, it came to a halt with the following interesting details from the trace log:-

——–

Source : ROUTING
EventId : DROP

RecipientStatus : {[{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}]}

——–

Some further digging and here is what i found for the distribution group that was not receiving emails:-

Get-DistributionGroup "nameofmydistributionlist" | fl recipienttypedetails

RecipientTypeDetails : MailNonUniversalGroup

Result shows my distribution group was of type: MailNonUniversalGroup

Further checking on when this group was first created in AD, shows far back as of 2012, and this must have been when it was migrated from previous legacy exchange 2003 to exchange 2010 but was not upgraded to a universal group at that time.

Microsoft recommends to convert all legacy exchange distribution groups to “universal” groups for use on Exchange 2010/2013/2016/2019 especially if you want to have all the features of distribution groups included.

In my case the distribution group members where on office365 and they needed to receive external email sent to the email address of the distribution list.

To solve, change the distribution group from MailNonUniversalGroup to Universal, I did this via exchange powershell:-

Get-DistributionGroup "nameofmydistributionlist" | Set-Group -Universal

wait a few minutes for replication and check again using:-

Get-DistributionGroup "nameofmydistributionlist" | fl recipienttypedetails

RecipientTypeDetails : MailUniversalDistributionGroup

It has now been converted to MailUniversalDistributionGroup

Now we can receive emails sent to the distribution list without any issues.

Tip: To do this in bulk for all your distribution groups that was just migrated over from legacy exchange versions 2003/2007, you can use the following command which will change all mailnonuniversalgroups to universal:-

Get-DistributionGroup -ResultSize unlimited -RecipientTypeDetails mailnonuniversalgroup | Set-Group universal

and then to apply the upgrade :

Get-DistributionGroup -ResultSize unlimited | Set-DistributionGroup -ForceUpgrade

Powershell command to quickly check licenses assigned to an Office365 user – Office365

Today I will share with you my powershell command I use to quickly know what licenses are provisioned for a user in office365. It’s faster and saves the time to do it via the admin panel.

First you will need to have Microsoft Azure Active Directory Module installed for your windows powershell. You only need to do this once if you don’t already have this module installed.

To download this Module for your powershell,  here is the OS requirements:-

  • Windows 10, Windows 8.1, Windows 8 or Windows 7 Service Pack 1 (SP1)
  • Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, or Windows Server 2008 R2 SP1

Follow the steps here to install it:- https://docs.microsoft.com/en-us/office365/enterprise/powershell/connect-to-office-365-powershell

msazurepowershellmodule

Connect to Azure AD for your office365 subscription:-

  1. In your powershell screen enter the below commands:-

$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential

Type your Office 365 Administrator account user name and password, and then click OK. Now you are ready to check user license.

2. Enter the following command:-

(Get-MsolUser -UserPrincipalName myname@company.com).Licenses.ServiceStatus

getuserlicence

You can now see the service plans and licenses assigned to the user.