X500 and the importance of proxy
A common question I get is "Do we need to keep these X500 addresses?" Often the answer is that it will depend so the best way to find the answer to that question is to provide a clear understanding of what X500 addresses do and how they were created. X500 addresses are a function of Exchange hybrid configurations. The purpose of the X500 Proxy addresses are to mitigate a method that exchange has used for a long time. In earlier versions of Exchange, the absolute static AD attribute of legacyExchangeDN has been used to identity users because of how Exchange was integrated into AD. This value becomes embedded in things like calendar invites, internal emails, and autocomplete cache entries. Because the legacyExchangeDN needs to be unique within an exchange organization and hybrid environment, the X500 was created to be used as a proxy address to mitigate NDR's . When an organization is put into a hybrid, AD objects need to by synced with AzureAD. Mailbox objects still on-premises will automatically have contact objects created in Office 365. As part of this, X500 addresses are automatically created to maintain the mailflow connection between both objects. In this diagram, we are syncing a user mailbox using Azure AD Connect while in an exchange hybrid. Because the mailbox exists on-prem, the contact is created in the cloud. That triggers the creation of X500 addresses on both the mailbox and the contact based on the other object's legacyExchangeDN
If we were to remove the mailbox from the Azure AD Connect sync, the contact would not be required and the creation of X500 addresses is not triggered
To prevent the automatic creation of X500 addresses, the object needs to be removed from the Azure AD Connect sync Troubleshooting Methodology To demonstrate how the X500 address is added automatically created I replicated a scenario when a mailbox is going to be decommissioned.
1. Started with an account with an on-premises mailbox
2. Drilling into the object attributes, we see that the account has a X500 proxy address pointing at the cloud based contact object
3. Because the object is currently in an OU that is being synced with Azure AD, I will need to move the object to another OU with is not being synced. In this example, the OU is called DONOTSYNC
4. Now that the object is no longer being synced, the process to trigger the automatic creation of the X500 will not happen so we can remove the X500 address
5. We force a sync with Azure AD to ensure the correct information is synchronized
6. Checking 24 hours after the change was made, we see that the X500 has not been created as desired
We now see why and how these addresses are managed and the importance of them.