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

Mail.Que database too large

In this troubleshooting you will learn how to safely delete and recreate the Exchange server transport queue database file “mail.que” and get tips to determine the root cause of your growing mail.que. On deletion of the mail.que file, Exchange will auto create a new mail.que file once you restart the Microsoft Exchange transport service. This applies to Exchange 2010,2013,2016,2019

Below solution will help you avoid messaging downtime, if your mail.que file is getting too large or consuming a lot of space on your disk drive at a critical stage which can cause major impact to mail flow or even Exchange auto shutting down its services, however, be sure to later properly investigate the root cause of the mail.que file growth as it can reoccur. Some known causes of mail.que file growth can be due to organization wide Exchange transport configurations such as the maxdumpstertime(exchange 2010), safetynetholdtime, pipeline tracing value, etc – For me, the safetynetholdtime value on Exchange 2016 was set to 7 days, which resulted in the growth of mail.que as it holds copies of successfully submitted messages for 7 days, another thing was that my day to day mail flow to my Exchange infra had increase from what it used to be several months ago , so i decided to schedule maintenance and expand the disk space where my mail.que resides from 250GB to 500GB , and ever since i no longer have mail.queue space issues. It might also be good to go back to your Exchange Server Role Requirements Calculator to help you determine where you are lacking in terms of disk space requirements, number of inbound messages to your infra etc. and from there you can make adjustments.

By default  your mail.que file location should be at :-  %ExchangeInstallPath%TransportRoles\data\Queue

screenshot-20190116165503-667x215

First, using Exchange powershell we can check the existing size in GB of mail.que, so open up your EMS on the affected Exchange server and run the following:-

Get-ChildItem "D:\Exchange Server\TransportRoles\data\Queue\mail.que" |select name,@{Label="size";Expression={"{0:N0}" -F ($_.Length/1GB)}}

screenshot-20190116161259-906x110

To Solve:-

  1. Put your Exchange server in maintenance mode, if you have SCOM etc, or schedule out-of- office hour maintenance before you proceed to perform these actions.
  2. Suspend Microsoft Exchange Transport service, (NOT STOP). This will drain and allow the current messages in the queue to be processed before it stops accepting new messages to the queue. To do this, on EMS run:- Suspend-service -name "Microsoft Exchange Transport"
  3. Run :- Get-queue  – to check and ensure messages in queues are empty (0).
  4.  Do not worry about shadow redundancy queues, these are fine if it has queues.
  5. Next, stop the MS Exchange transport service, :- Stop-service -name "Microsoft Exchange Transport". Once it has stopped give an extra 5 minutes for everything to settle in.
  6. Open the mail.que location ( %ExchangeInstallPath%TransportRoles\data\Queue) , select all files inside the folder and delete it, optionally you can move it to an external drive with enough space, you can rename it to something like mail.que.old as a backup.
  7. Now, After you have completed above steps. on Exchange management shell enter:- Start-service -name "Microsoft Exchange Transport"
  8. You will see a new mail.que file is auto created by Exchange, and your drive space released and back to normal.
  9. Run on EMS, Get-queue  – to check and monitor and ensure mail flow is back to normal. Above actions will save you from exchange running out of space and shutting down services automatically, and also gives you more time to investigate further on the root-cause of the growth, check event logs, google, technet articles, for more troubleshooting. Good luck.

Tip: use a tool such as Treesize free to get a detailed view of files and the size in your drive. It can come in handy when you want to check the size of files in your exchange server data path.

P.S: Watch out for my next article where I will show you how to change the default directory for your mail.que database, for me I prefer to put it on D:\ or another drive, which is separate from Exchange installation path on C:\ and OS. This is a very good recommendation because you can focus on troubleshooting and increasing the disk space for the mail.que on D:\ without touching your System/Exchange on C:\ drive, also allowing it to be stored on a separate drive from C:\ allows it to make use of the resources on that drive alone.

Managing MailContacts created in Exchange 2007 in our Exchange 2013

Hello,

Today, I will show you how to manage MailContacts in an exchange 2007 / exchange 2013 co-existence scenario and also how to easily migrate your bulk mail contacts from Exchange 2007 to Exchange 2013 , this can also be applied to Exchange version 2010 where you plan to move up to 2013/2016 or when you have co-existence and have to toggle managing MailContacts between the higher and lower Exchange version.

Always Note:-

You cannot use a lower version of Exchange server to modify an Exchange object that was created/upgraded in a higher version of Exchange, and likewise, from a higher version of Exchange you will be first asked to upgrade that Exchange object to a higher version before you can modify it.

Common errors you will face:-

Exchange 2007

Screenshot-20181018122532-446x509

Or via powershell:-

Screenshot-20181018122705-1106x228

From Exchange 2013 powershell when modifying a mailcontact originally created in Exchange 2007 you will get this warning:-

Screenshot-20181018115734-984x220

 

TIP:-  Always check the Exchange version of the object that you need to modify or migrate, this will make things easier..

In powershell you can run:-

Get-recipient mytest@contoso.de | fl exchangeversion, name, externalemailaddress

This outputs the Exchange version – Exchange 2013  0.20 {15.0.0.0} for the external mailcontact menothappy@contoso.de

Screenshot-20181018122425-698x131

You can check the different Exchange versions on Microsoft technet link here  – https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx

To upgrade/migrate/modify a mailcontact that was created in Exchange 2007, we want to manage this mailcontact in our Exchange 2013 :-

Created in 2007:-

Screenshot-20181018115043-635x567

In Exchange 2013:-

Screenshot-20181018115236-754x338

 

We can run the following commands in Exchange Management Shell in Exchange 2013 to upgrade the mailcontact :-

  1. Get-MailContact ‘Happy, Me’ | fl ExchangeVersion,ExternalEmailAddress
  2. Get-mailcontact ‘Happy, Me’| Set-mailcontact -ExternalEmailAddress ‘mytest@contoso.de‘ -Force:$true
  3. Get-recipient ‘Happy, Me’ -ReadFromDomainController:$true| fl ExchangeVersion,ExternalEmailAddress

 

To do it from ECP Exchange 2013 (read and accept the warning message):-

Screenshot-20181018115401-621x505

Once completed you can now easily manage the mailcontact in 2013. Lets try to change the SMTP email address from mytest@contoso.de to menothappy@contoso.de :-

Screenshot-20181018120854-891x97

We can do it easily, no more warnings no more errors and in future we can easily change/modify/delete the mailcontact from Exchange 2013.

For Migrating mailcontacts in bulk, you can first use the commands I have provided above to gather information for their ExternalEmailAddress , displayname, put them all in a CSV, name the columns ExternalEmailAddress, DisplayName, then add your mailcontacts external emailaddress and their display names.

You can modify the powershell command above to something like:-

Import-CSV “D:\mycontactsbulk.csv” | foreach {Set-MailContact $_.DisplayName -ExternalEmailAddress $_.ExternalEmailAddress -Force:$true}

First test it with 1 contact and get the results and then you can do it in bulk.

Add domains to Internal Relay on Exchange 2010

Here is a quick step to add new domains to your internal relay on Exchange.

If you are not familiar with what internal relay means and what are its impact, you can head over to Microsoft technet and read more:- https://technet.microsoft.com/en-us/library/bb124423(v=exchg.150).aspx#Anchor_2

internaldomains

 

  1.  open up the EMC console and under Organization Configuration >> Hub Transport >> Accepted domains, in the actions menu, select New Accepted domain
  2.  Enter the display name, you can use a different name than the actual accepted domain or for me I prefer to keep it the same.
  3.  Select internal relay domain and save.

Via powershell command:-

new-AcceptedDomain -Name ‘contoso.com’ -DomainName ‘testdomain.com’ -DomainType ‘InternalRelay’

4. To verify that the new accepted domain is working, I usually like to test by sending a test message and then see the results, you can do this via powershell as follows:-

Send-MailMessage -From noreply@newcontoso.com -To “administrator@contoso.com” -Subject “Test internal relay ” -Body “Test only. Do not reply” -SmtpServer “name of your hub server”

View the result from message tracking log:-

Get-MessageTrackingLog -ResultSize unlimited -Start “08/06/2018 9:00AM” -Recipients “administrator@contoso.com” -sender noreply@newcontoso.com -Server”name of your hub server”

This will help you to know immediately if something was wrong with your configuration and you can go back and follow the steps again.

Cannot set the security descriptor of mailbox

You may come across this error in powershell – Cannot set the security descriptor of mailbox…. For me it was occurring in the beginning when we were doing a small number of mailbox migrations from Exchange 2010 to Exchange 2016 and assigning mailbox permissions.

Screenshot_1

“Cannot set the security descriptor of mailbox…….. in exchange mailbox database ……..”

Error appeared when I used below exchange powershell command to grant full access permission to userB on userA mailbox:-

Add-MailboxPermission -Identity "userA" -User "userB" -AccessRights FullAccess -InheritanceType All

Cause:-

Changes in user attributes in AD after migrating user from Exchange 2010 to Exchange 2016.

Powershell is throwing this error because the mailbox that you are trying to add the full access permission is now hosted in a higher version of exchange than the server you are running the powershell command from.

In my case, it means i should be running the Add-MailboxPermission command above in Exchange 2016 exchange management shell where the mailbox of userA is now hosted after it was migrated from Exchange 2010.

Solution:-

  1. Check which database the mailbox is currently on, and which version of Exchange server.

Get-Mailbox -Identity UserA | fl database,exchangeversion

2. Use Exchange powershell on a higher version of  exchange where the mailbox now resides after migration. If mailbox was migrated from Exchange 2010 to Exchange 2016, so you will have to run the command from Exchange 2016 management shell to add the permissions successfully.

Add-MailboxPermission -Identity "userA" -User "userB" -AccessRights FullAccess -InheritanceType All

You can always refer to this Microsoft technet link to know your versions of Exchange from the exchangeversion result you get 🙂 

https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx

Leave a comment and let me know if it worked for you.

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.

Create a New SendConnector – Exchange 2010

Today we will create a new send connector for our Exchange 2010 server.

Its always good to have your information ready and written down :-

  • Name of send connector to be created
  • SMTP address space – e.g *.mail.contoso.com
  • Smart hosts IP address – IP address of SMTP smarthost servers you want to associate this new connector with
  • Source servers that will route your emails – your Exchange hub transport servers

Once ready, you can run below Exchange powershell command, replace it with your own information:-

new-SendConnector -Name “MYSENDCONNECTORNAME” -Usage Custom -AddressSpaces “SMTP:*.mail.contoso.com;1” -IsScopedConnector $true -DNSRoutingEnabled $false -SmartHosts “[192.168.11.12]”,”[192.168.11.13]” -SmartHostAuthMechanism None -UseExternalDNSServersEnabled $false -SourceTransportServers “LAB-HCP01″,”LAB-HCP02″,”LAB2-HCP01″,”LAB2-HCP02”

You can refer to MS article below for a full detail information about each important attribute to be configured on your send connector such as:-

Usage type:- For Send connectors, the usage type is basically a descriptive label that identifies what the Send connector is used for. All usage type values receive the same permissions.

Network settings:–  Configure how the Send connector routes mail: by using DNS or by automatically forward all mail to a smart host.

Address spaces :- Configure the destination domains that the Send connector is responsible for.

Scope :- Configures the visibility of the Send connector to other Exchange servers in the organization.

Source servers:– Configure the Exchange servers where the Send connector is hosted. Mail that needs to be delivered by using the Send connector is routed to one of the source servers.

(https://msdn.microsoft.com/en-us/library/aa998662(v=exchg.160).aspx)

NOTE:-  You can specify SMTP address spaces or non-SMTP address spaces on Send connectors that are configured on Hub Transport servers. You can only specify SMTP address spaces on Send connectors that are configured on Edge Transport servers.