13 March 2020

Hiding email address in O365 with hybird on-prem AD sync

So another gotcha when using O365 in hybird mode with on-prem sync is that you can’t hide a user’s email address [from address books and distribution lists] by using the Exhange Admin Portal. This is because the setting are made on-prem, and those defined values are simply pushing to your AAD tenant in Microsoft’s Azure cloud.

We used to be able to, from the Exchange Management Console on the on-prem server, just open the user and check a tick box to hide their address from everything. The work around isn’t much harder, it’s just buried deeper.

Open the user in your on-prem AD, and navigate the “Attribute Editor” tab.

Scroll down until you find the following attribute.

  • msExchHideFromAddressLists

Setting it to “TRUE” will make the email addess hidden.

Setting it to “FALSE” or “<not set>” will make the email address visible.

After you have made the desired change to the value of the attribute, you just need to wait for [or force] your on-prem AD to re-sync with your AAD.

Category: Microsoft, Office | LEAVE A COMMENT
12 March 2020

Alias emails in O365 with hybird on-prem AD sync

If you use O365 in hybird mode, with your tenant sync-ed to your on-prem AD or Exchange server, then you will definitely run into an issue if you try to add an alias email address to a user.

When you attempt to add an alias, or alternate, email in your Exchange Admin Center portal you will see this error message.

To get around this you’ll need to edit the user “local” from your on-prem AD. In AD, right-click and open the users’ properties. Select the tab “Attribute Editor”

You will want to look for and edit the following two attributes.

  • msExchShadowProxyAddresses
  • ProxyAddresses

Add the user’s alias/alternate email address into the above mentioned attributes in the form of: smtp:updatedname@domain.tld

That’s it. Now you just need to let your AD sync back up to the O365 cloud.

WARNING: If you add it in CAPS (SMTP:updatedname@domain.tld) then it will get interpreted as the default address and not as an alias/alternate email. Make sure that “smtp” is lowercase.

Category: Microsoft, Office | LEAVE A COMMENT
24 December 2019

Office 365 – Winmail.dat

After changing over from on-prem Exchange to O365, I had one user where the recipients of their emails would receive any attachment that was sent as the “dreaded” winmail.dat file instead of the .pdf or whatever file the user was actually sending. It was intermittent however, in that some users would get the actual file and some (all external) would get the winmail.dat file.

First thing that I did was check that user was sending their mail as HTML, and not Rich-Text. After changing that value, I check back a week or so later and the user was still experiencing the issue, so it was time to dig a little deeper. After some searching online I was able to find that this was not an uncommon issue.

The issue happens because the receiver’s email client can not interpret the email message that was sent from Outlook in the Rich-Text format. When using Outlook to end an email using the Rich-Text format, a plain text copy of the email is also sent along with an attachment named winmail.dat. This ‘winmail.dat’ attachment is what contains all of the formatting, elements, and other data specific to Rich-Text email messages. This method of sending the email message is called “Transport Neutral Encapsulation Format” or “TNEF” for short.

Unfortunately, many non-Microsoft email programs can not properly open message that are received in TNEF. To fix this, we can use PowerShell to force Exchange Online to convert Rich-text messages to HTML before it sends it off. You can use the commands shown below to set the ‘RemoteDomain’ property “TNEFEnabled” to false on the Default policy.

1) Connect to Exchange Online via Powershell.

2) Get your Default RemoteDomain policy:
Get-RemoteDomain | fl *

3) Set the TNEFEnabled property:
Set-RemoteDomain Default -TNEFenabled $false
Re-run step 2 and you should see that “TNEFEnabled” is set to “False”.

Just in case… Here is how to change it back to a NULL value to undo your change in step 3, and let the Outlook client again decide how it wants to send the message.

4) Set the TNEFEnabled property back to NULL:
Set-RemoteDomain Default -TNEFenabled $nul

Category: Microsoft, Office | LEAVE A COMMENT