How do I verify if Recipient Update Service (RUS) has run against a mailbox/mailenabled object?
Exchange Migrator 1.x
Exchange Migrator 2.x
For a mail-enabled recipient, there is a minimum set of attributes that is required to make all Exchange components work properly. For example, a mail-enabled entry (user, contact, group, public-folder, and so on) needs to have at least these attributes: mailNickname , legacyExchangeDN , and displayName . Without the mailNickname attribute, an object is not considered mail-enabled. After you have a mailNickname attribute, the other two attributes must be set.
Mail-Enabled Recipient Policy
If the Recipient Update Service identifies that a new entry was added or modified that does have the mailNickname attribute, but that does not have the legacyExchangeDN or displayName attributes, it tries to create those attributes.
The displayName attribute is copied from the mailNickname attribute as is, and the legacyExchangeDN attribute goes through an algorithm that identifies the organization and administration group for this entry, and then creates a value in the following format:
Mailbox-Enabled User PolicyFor a Mailbox-Enabled User, two attributes need to be present. The first is the mailNickname attribute, and second is one of the following three attributes:
- If the msExchHomeServerName attribute is not present, it will be created based on the homeMDB or homeMTA attribute, depending which one is present. If it cannot be created, the process stops.
- After the msExchHomeServerName attribute is set, the homeMDB and homeMTA attributes are populated if either is missing. If you have multiple messaging databases (MDBs) or message transfer agents (MTAs) on your server, it picks the first one that it finds doing an Active Directory search, so it can be considered a random choice.
- To create the legacyExchangeDN and displayName attributes, it follows the same steps that are used for a Mail-Enabled Recipient.
- Finally, if the msExchMailboxGuid attribute is not present, it will be created by generating a random globally unique identifier (GUID).
To verify that the Recipient Update service is operating properly:
- Using the Ldp.exe tool or Adsiedit, retrieve the properties for a known user, and check if it has the following attribute:
If this attribute is present, the Recipient Update service has correctly populated the information in Active Directory, and there is another issue that prevents the user from appearing in the global address list.
- Using Ldp or Adsiedit, verify that the USNChanged value for this user is greater than the msExchServer1HighestUSN attribute in the Recipient Update service object that is responsible for this user. The entry can be found under:
- CN=Recipient Update services,CN=Address Lists Container,CN= <Your organization> ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC= <Your domain>
Note : You must get the properties of the Recipient Update service object for your domain.
- If the USNChanged value is greater than the msExchServer1HighestUSN value, this means that the user has not been updated by the Recipient Update service, but will be updated during the next Recipient Update service cycle (if the Recipient Update service is running). If you see this situation, you may want to manually run the Recipient Update service by right-clicking on the Recipient Update service for the domain from within Exchange System Manager and select the Update Now option. Otherwise, it means that the user could not be updated, either because of a server misconfiguration, because of another failure.