Find AD Objects with an Incorrect TargetAddress

When you have a hybrid environment setup with Exchange Online, you’ll notice a new Accepted Domain in the Exchange Online portal.

<domain>.mail.onmicrosoft.com

This domain is used by Exchange on-premises to route mail to a mailbox that has been migrated from Exchange on-premises to Exchange Online. After a mailbox is migrated from Exchange on-premises to Exchange Online, the remaining on-premises object will have its targetAddress Active Directory attribute populated. Typically the new targetAddress attribute will look something like user@domain.mail.onmicrosoft.com. When an on-premises mailbox sends mail to this user, the targetAddress is used to route the mail to the Exchange Online mailbox.

A quick way to view an objects Active Directory targetAddress attribute is through the Active Directory Users and Computers panel. In AD Users and Computers, ensure that Advanced Features has been enabled under the View menu.

Then right click an object, select properties, and you’ll find the Attribute Editor tab present. This tab won’t be present if you haven’t enabled Advanced Features.

This is only one way to view this attribute. You can also use ADSIEdit or Active Directory Administrative Center.

I recently worked with a customer that found the targetAddress attribute in Active Directory was incorrect for a few mailboxes that had been migrated to Exchange Online. We fixed those few mailboxes, but we wanted to be proactive by looking to see if any other on-premises objects had incorrect targetAddress attributes.

The following PowerShell can be run against on-premises Active Directory and will display any AD user that does not have a targetAddress that ends in mail.onmicrosoft.com.

 Get-aduser -filter {targetAddress -notlike “*.mail.onmicrosoft.com”} -properties * | Select-Object Name,targetAddress

This query will not return objects that do not have a targetAddress attribute set. It will only return objects that have a targetAddress that does not end in mail.onmicrosoft.com. For this particular customer that I was working with, there ended up being a few more that were incorrect. We weren’t able to determine why they were wrong, but we were able to correct them. High five!!

Comments

• Anonymous
  May 20, 2017
  My friend thank you very much, it was very useful.Regards, Renan
• Anonymous
  May 23, 2017
  We need to be keep an eye on the RecipientTypeDetails - It should be RemoteUserMailbox or RemoteSharedMailbox only for the targetAddress to be ".mail.onmicrosoft.com".As there can be actual MailUsers without mailboxes and emails actually pointing to their personal\external IDs. Which is fine.(Third party admins)#Below cmdlet should allow to identify thatGet-Recipient peter@wrong.com | select Name,Ext,RecipientType*