2.5 The LegacyExchangeDN attribute

---

The original Exchange architecture allocated a fixed distinguished name to every object in the directory and used this value as the primary key for the object in the directory. Exchange composed distinguished names from the names of the containers along the path to an object in the directory. Primary keys are difficult to change and this implementation led to some problems in terms of flexibility. You could not change the name of an Exchange 5.5 site or move users between containers because these operations required the object to be deleted and then recreated with a new distinguished name that reflected the new location of the object within the directory.

Exchange now uses the AD as its directory, and, during the transition, the developers were careful to avoid the same issue. While the AD still uses distinguished names to reference objects, the distinguished name is no longer the primary key. Instead, when it creates a new object, the AD allocates a GUID (Global Unique Identifier) to it. You can move objects around the directory between containers as much as you want, which results in multiple changes to their distinguished names, but their GUIDs remain constant. Unlike previous versions of Exchange, no correlation exists between a user's distinguished name and a site or other administrative, security, or routing boundary.

You can view the distinguished name for an object using the ADSIEDIT utility. Select the object and then look at the value of the "distinguished name" attribute. The format is:

cn=Name, ou=Organizational Unit, dc=domain name, dc=domain name

Therefore, the distinguished name for my Windows account might look like:

CN=Redmond\, Tony,OU=Consulting,OU=Users,OU=Accounts,DC=emea,DC=cpqcorp, DC=net

There is no correlation between distinguished names and email addresses.The change in distinguished name format occurs automatically as accounts are migrated, and Exchange hides the change from users in distinguished name format. However, many different pieces of the messaging puzzle store the old Exchange format distinguished name (such as the headers of old messages and MAPI profiles) to ensure backward compatibility.

Because two different formats are in use, some method is needed to ensure that the older addresses stored within the infrastructure are still valid. The AD accomplishes this goal by maintaining a separate attribute for every Exchange object, called the LegacyExchangeDN, which it populates via ADC synchronization with the distinguished name in the old format. You can think of LegacyExchangeDN as the "old" name for an Exchange object-something to ensure backward compatibility by always having something that an older version of Exchange or a utility built for an older version of Exchange can recognize and use. Figure 2.17 shows ADSIEDIT viewing the LegacyExchangeDN value for a user object (left) and an administrative group (right). The data for the administrative group comes from the Exchange container in the AD configuration naming context.

Figure 2.17: LegacyExchangeDN values for a user and an administrative group.

The AD indexes the LegacyExchangeDN attribute to enable fast lookup and automatically searches the index if a client attempts to search the AD using a distinguished name in the old format. Thus, MAPI profiles continue to work and clients can continue to reply to messages using old addresses, because the AD responds to the search executed by the SMTP Routing Engine when it attempts to resolve the address.

---