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.


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 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

Get-aduser -filter {targetAddress -notlike “*”} -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 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 (2)

  1. My friend thank you very much, it was very useful.
    Regards, Renan

  2. Satyajit321 says:

    We need to be keep an eye on the RecipientTypeDetails – It should be RemoteUserMailbox or RemoteSharedMailbox only for the targetAddress to be “*”.

    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 that
    Get-Recipient | select Name,Ext*,RecipientType*

Skip to main content