Last week I introduced that the problem with repliability still exists today after all these years. We discussed the history of the X.500 specification and how it relates to Exchange. Today we are going to address the obstacles with names in Exchange today.
Obstacles with Names in Exchange Today:
Over the years, SMTP has been standardized as the protocol that is used when sending email over the Internet. While this holds true even for Exchange 2013, many assume that SMTP is used to process messages that are sent and received within an Exchange organization. Unfortunately, many have learned the hard way that this is not how Exchange actually works in the real world. When Exchange needs to process and send a message to a user from the same organization, the X.500 address is read from the recipient in Active Directory.
Remember from our history lesson that the X.500 specification was created because information about individuals such as the surname, given name, or address could be easily stored and then retrieved. In this case, Exchange uses the X.500 address, which is stored in the user's legacyExchangeDN Active Directory attribute.
This means all mail objects within Active Directory have an assigned unique X.500 attribute stamped on the account. The legacyExchangeDN value is stamped on the user account when the Exchange mailbox is first created. So if a specific Active Directory users does not have a properly filled out legacyExchangeDN attribute, then Exchange will not be able to deliver email to that user internally.
Microsoft saw an opportunity to speed up the name resolution process to help mail clients obtain the proper name for a recipient. To help Microsoft Outlook speed up the resolution of previously used X.500 addresses, a caching file was created. Starting with Outlook 2003, this cache file (OutlookProfileName.nk2) builds a list of names based on actual user activity. This AutoComplete functionality within Microsoft Outlook will then suggest previously used names and email addresses when sending mail based on the first couple of characters you enter in the To: field. Unfortunately, Microsoft Outlook does not provide a native method to edit the nk2 file. So once a recipient’s X.500 address is saved in the *.nk2 file there is not an easy way to remove it.
Cross-forest mailbox migrations typically present numerous obstacles with the “replyability” of existing messages in the user mailbox. During a cross-forest migration, a new mailbox for each user is created in the target forest. This means that a new and unique legacyExchangeDN value is stamped on the user account in the target forest when the Exchange mailbox is first created. The new legacyExchangeDN value in the target forest will not match the existing legacyExchangeDN value for the user in the source forest. This means that replying to old emails in a users’ inbox will produce an NDR, as the message cannot be routed correctly. The old legacyExchangeDN value does not exist in the target forest so Exchange cannot route internally. This is like trying to resolve a DNS name when the zone does not contain the appropriate A record.
During cross-forest migrations there are several methods that can be used to help Exchange in the target forest understand the legacyExchangeDN values from the source forest.
1. Use the CSVDE command to dump the alias and legacyExchangeDN values from the source forest and import them into the target forest.
2. Utilize the manual prepare mailbox scripts from Microsoft so the native move method can be used.
3. Utilize third-party tools to stamp the legacyExchangeDN value from the source forest on the user located in the target forest.
Next, I am going to examine the different ways to verify what the legacyExchangeDN Active Directory attributes for all our mailboxes actually are.
The good news is that there are a lot of different methods and tools to accomplish this!