Recipient Management in Exchange 2007

We all know that Recipient Update service was responsible to stamp exchange recipients with the email address in Exchange 2000 and Exchange 2003.

RUS is the only object in Exchange which was solely responsible for stamping exchange recipients with the exchange specific attributes.

Unlike exchange 2000/03, Exchange 2007 does not use RUS to stamp recipients with the email address.

No No ... This doesn’t mean that RUS does not exist in Exchange 2007!!!

RUS is still part of Exchange 2007 and will continue to work under System Attendant service as it has always done. However, there are no such RUS objects in the directory under configuration partition.

The role of stamping objects with email address is taken by the Exchange server 2007 running Mailbox server role.

Previously, RUS used to automatically query the Active Directory Domain controller and get the list of new or modified objects from AD and process those objects with exchange specific attributes.

But now, RUS instead sits idle and will only work when triggered. One way to trigger RUS is to trigger the task “create-mailbox”.

The RUS in exchange 2007 has been redeveloped and rewritten into an Application Programming Interface (API) which is termed as RUS API.

The RUS API is broken into two parts, a server and a client:

Server RUS API– Runs on every Exchange Server 2007 Mailbox Server.
Client RUS API – Available to component that uses the AD Provider (i.e. create-mailbox task goes to the AD Provider to find a DC).

Question here.????
In which scenarios are the RUS API's used?

The following tasks uses the RUS API:

- Move-mailbox
- new-mailbox
- set-mailbox
- reconnect-mailbox
- Enable-CasMailbox
- Set-CasMailbox
- Enable-UMmailbox
- Set-UMMailbox
- new-mailuser
- set-mailuser
- new-mailcontact
- set-mailcontact
- new-DistributionList
- set-DistributionList
- new-DynamicDistributionList
- set-DynamicDistributionList
- new-addresslist
- update-addresslist
- new-globaladdresslist
- update-globaladdresslist
- new-emailaddresspolicy
- update-emailaddresspolicy

How is the Mailbox Server selected for this role?
In exchange 2003, we had a RUS object created in Active Directory.

This object always holds the information of:

1. The Exchange server name responsible to stamp users with email address.
2. The domain controller name to which the exchange server queries for new or modified objects. And,
3. Finally, Domain name for which the RUS is responsible.

But, now in Exchange 2007, we’ll not have the RUS object created in Active Directory.

There would be no such RUS object in Active directory unless we have got Exchange 2007 installed in an existing ORG with Exchange 2000 or Exchange 2003.

So some question which pops up are:

1. If there is no such RUS object in AD, then how do we set the properties of RUS?
2. Which mailbox server will be solely responsible for stamping objects with the exchange attributes?
3. Which domain controller will be queried for the list of objects for further processing?

The answers for the above questions are:

1. Since no RUS object exists in the AD, the properties cannot be set.
2. There is no such mailbox server which is predefined and preconfigured to do the activity.
3. Also there is no such pre-defined or pre-configured domain controller. The process of selecting the Domain Controller and the Mailbox server actually starts from the Exchange management interface such as Exchange Management shell (EMS) or Exchange Management Console (EMC).

When you actually trigger the task such as Create-Mailbox with the switch –DomainController “DC Name”, the mailbox server which is nearest to that domain controller’s site is selected.

If you run the Create-Mailbox task without the –DomainController switch, then the mailbox server closest to the site from where the task was triggered will be selected.

If you have multiple mailbox servers running in the same site, then anyone mailbox server which is best reachable will be selected.

This process of selection will continue until all the listed Mailbox servers are contacted with no replies from them.

Finally, if no mailbox servers are available, the create-mailbox task will fail with the “server is down” or “Access denied” error.


The objects used in the process

There are some AD objects which are used in the process of stamping objects with the exchange attributes.

The first object used is Email Address Policy (EAP). 
The EAP in Exchange 2007 is exactly as similar to Recipient policy in Exchange 2000/03.

Active Directory will store the EAP within its database as what it did for the Recipient policies.
Since the recipient policies in Exchange 2003 and the Email Address Policy (EAP) in exchange 2007 are one and the same, they’ll provide the same functionality.

The EAP will provide RUS API a format to stamp users with email address/es. It would act like a skeleton of the body to the mail/mailbox enabled objects in AD.

The only difference in EAP and Recipient policy is that the EAP will not work dynamically as Recipient policy did in Exchange 2000/03. This is because the RUS in Exchange 2007 does not work dynamically and is dependent on task such as Create-Mailbox.

The second object used is Address List (AL).
Address list is nothing but a dynamic list of all the exchange objects in the active Directory.
It can be defined by the attributes like description, country, city, street, etc. Since the Address List in Exchange 2000/03 and Exchange 2007 are one and the same, they’ll provide the same functionality.
The only change in Address List in Exchange 2007 is that it does not get created/modified dynamically as what it did in Exchange 2000/03
The simple reason is because the RUS in Exchange 2007 does not work dynamically and is triggered with task such as Create-Mailbox, etc.


The Process of stamping objects with Mail Attributes

In Exchange Server 2007, the operations of stamping objects with exchange attributes occur little differently.

As mentioned above, Exchange Server 2007 does not proactively schedule any operations. Instead, the RUS API sits idle until a task, such as create-mailbox, has been initiated. The RUS API also has an Internal Filter Evaluator.
This Internal Filter Evaluator existed in Exchange 2003 also but now it is enhanced in Exchange 2007.
This feature allows filters to be evaluated without querying the Active Directory and hence reducing the queries made to Active Directory.

The internal filter Evaluator was also used with the recipient policy in Exchange 2003.
It used the MsExchPurportedSearchUI attribute on the Recipient policy to find the object and if this attribute was modified by the administrator, then RUS queries the Active Directory using the filter in the MsExchPurportedSearchUI attribute.

Now let’s discuss the process of an object getting exchange attributes:

1. The Exchange Administrator will always use either EMC or EMS to create a mailbox.
2. Everytime, create new mailbox process happens, in the background, the create-mailbox task is triggered.
3. This task, in the background, tries to find the Active Directory domain controller to talk to. This task is performed by the client side of the RUS API.
4. On the other hand, the server side of the RUS, queries the Active Directory domain controller for the new or updated EAP and the AL objects which are stored in the AD. The RUS API queries AD every 5 minutes (by default) for this information. This information is cached on the local Exchange Mailbox server.
5. Once the connections is established with the domain controller as mentioned in step 3, the task then connects to the server side of RUS API and gets the list of EAP and the AL.
6. Basis on the EAP and the AL available and the information provided in the create-mailbox task, a virtual user is created by the RUS API.
7. Finally the uniqueness of the virtual server is checked by the RUS API and a complete user with the mail attributes is created in the Active Directory.


I hope this article helped you a little bit in understanding the process of getting mail attributes in Exchange 2007.