
A process called Recipient Update Service (RUS) was responsible for populating the legacyExchangeDN value using the current location in conjunction with the given name (CN). Because it’s dynamic, the distinguishedName will change when you move or rename the object.įor backward compatibility with older versions of Exchange, clients or 3rd party tooling the legacyExchangeDN attribute was introduced which was to provide a unique key for the Exchange object. The distinguishedName is constructed using relative names like the OU and CN, e.g. In AD, while you could refer to object using obj-Dist-Name’s counterpart distinguishedName, objects are primarily identified using their static Global Unique Identifier (GUID). Then came the introduction of Active Directory with the release of Windows Server 2000. o=Contoso/ou=EMEA/cn=Recipients/cn=User. It contained a constructed value using elements like organization, containers and the canonical name to construct the entry, e.g. Exchange utilized its own hierarchical X.500 addressing scheme, and to uniquely identify objects it used an attribute called obj-Dist-Name (similar to distinguishedName nowadays). In the early days of Exchange, the NT world was flat. After some recent Exchange troubleshooting I decided to do a small write-up on an attribute most people working with Exchange know about, the infamous exchangeLegacyDN.
