How the Recipient Update Service applies recipient policies

This article describes how the Recipient Update Service applies recipient policies and stamps e-mail addresses in the proxyAddresses attribute on recipient objects in Active Directory.

There are three ways that the Recipient Update Service searches the directory for objects to update:

• Update only new and modified objects (through regularly scheduled updates or Update Now).
• Update all objects (Rebuild).
• Update objects that correspond to a specific recipient policy (when a policy is modified or applied).

The method that the Recipient Update Service uses to perform any particular search depends on the actions that an Exchange administrator takes in Exchange System Manager.

Updating New and Modified Objects

This is the default behavior that the Recipient Update Service exhibits each time it runs to search for objects to update. This is also the default behavior that the Recipient Update Service exhibits when you use Update Now if you do not select the Rebuild option and none of the policies have been modified or applied.

The Recipient Update Service constantly keeps track of the latest change that has occurred on the domain controller that the Recipient Update Service is configured to run against. Based on the schedule that is set on the Recipient Update Service object, the Recipient Update Service periodically checks for objects that have been created or updated since it last checked.

You can click Update Now in Exchange System Manager to make the Recipient Update Service check for changes to objects at any time. The Update Now function sets the msExchReplicateNow attribute to TRUE and causes the Recipient Update Service to temporarily ignore its schedule and immediately query for any new changes and take any appropriate action on those objects. When the Update Now process is finished, msExchReplicateNow is set back to FALSE.

Updating All Objects

To update all objects, in Exchange System Manager you can right-click the Recipient Update Service, and then click Rebuild. When you select this option you set the msExchDoFullReplication attribute on the Recipient Update Service to TRUE. After msExchDoFullReplication is set to TRUE, the next time that the Recipient Update Service is started by the schedule or by the Update Now command, the Recipient Update Service starts at the beginning and looks at every object instead of querying only for new objects. When the Rebuild process is finished, msExchDoFullReplication is set back to FALSE.

Updating Objects for a Specific Policy

You can also modify the filter on a policy (the purportedSearch attribute) to make the Recipient Update Service take action outside its default behavior. When you modify the filter on a policy, the policy can apply to a completely different set of users than it did before. Because of this, if the filter on a policy has been modified, the Recipient Update Service will query for every user who matches both the new filter and the old filter the next time that the Recipient Update Service is started by the schedule or by the Update Now command. The Recipient Update Service runs against all users who match either filter and updates their msExchPoliciesIncluded attribute to reflect the filter that they are now subject to.

However, users who are subject to a different policy will not automatically have their e-mail addresses regenerated. In order for the addresses on those users to be updated to match the policy that is now responsible for them, you must use the Apply Now command to apply that policy.

If you only modify the e-mail addresses on a policy, you do not change the default behavior of the Recipient Update Service. If you have not changed the filter on the policy, the Recipient Update Service does not automatically query for all users who match that policy to update them. Additionally, even if the filter is changed and the Recipient Update Service does query for those users, it will not regenerate their e-mail addresses to match the changed addresses. However, when the e-mail addresses are modified on a policy, the user is prompted with the following message: If the user clicks Yes, the modified address on the policy is applied.

Applying a Policy

You can apply a policy in two ways:

• You can right-click a recipient policy, and then click Apply this policy now.
• You can click Yes when you are prompted with the message that is described in the previous section of this article.

If you click Apply Now, you cause every address on the policy to be applied. If you click Yes at the prompt, only the modified address is applied.

When you apply a policy, the result is quite different from the other options that are described in this article. First, the Exchange System Manager populates the gatewayProxy attribute on the Recipient Update Service objects with each address from the applied policy. The gatewayProxy attribute on a Recipient Update Service object acts as the "to do" list". When you apply a policy, you also modify the filter on the policy (the purportedSearch attribute) by either adding a space or removing a space. This modification causes the Recipient Update Service to query for all objects that match this policy the next time that the Recipient Update Service runs instead of querying only for the new changes. After the Recipient Update Service finishes the update to the recipients, the addresses corresponding to that particular policy are removed from gatewayProxy.

The "to do" list (the populated gatewayProxy attribute) forces the proxy addresses on a recipient to match the corresponding policy. The Recipient Update Service regenerates existing addresses or removes existing addresses on a recipient only when the "to do" list has been populated with those address types.

When you apply a policy, the gatewayProxy attribute on your Recipient Update Service objects is populated with a list of values similar to the following list: These values contain the objectGUID attribute of the policy followed by the addresses on the policy. Notice that three of the address types are in uppercase text. This means these three are primary proxy addresses. The one address type that is in lowercase text is a secondary proxy address.

Also notice that there is an entry for a Microsoft Mail (MSMail) address that has no actual address following it. There are two ways to cause this type of entry to be added to the gatewayProxy attribute:

• You can remove an address from a recipient policy and then click Yes at the prompt.
• You can click Apply Now when you have a primary address on the policy that has the check box next to the address cleared. This address type is then removed from any users under this applied policy.

Note that when you click to clear the check box next to a primary address on a policy, Exchange System Manager does not prompt you to apply the policy. This is the only change in a recipient policy that does not prompt the administrator to apply the policy. However, if you apply the policy at a later date, any primary addresses that are not selected are added to gatewayProxy as described in this article.

The other three gatewayProxy entries that are listed are for addresses that have the check box checked. The list contains a Simple Mail Transfer Protocol (SMTP) address and an X400 address type that are in uppercase text, and another SMTP address type in lowercase text. The uppercase address types indicate the primary addresses of that type on the policy. Any secondary addresses on the policy are displayed in lowercase text.

When the gatewayProxy attribute is populated as described in this article, the primary X400 and SMTP addresses for users under this policy are regenerated if the addresses do not match the policy. The old primary addresses become secondary proxy addresses. Additionally, a secondary SMTP address that matches the one shown in gatewayProxy is added for any recipients that do not already have a secondary SMTP address that matches the one shown in gatewayProxy. This process is discussed in more detail later in this article.

When you use the Apply Now command, you affect all proxy addresses on the policy. The Recipient Update Service performs a search based on the filter on the policy (the purportedSearch attribute) of all objects that are associated with this policy. When the Recipient Update Service finds all objects that must be updated by the policy, the Recipient Update Service adds or removes proxies as detailed by the "to do" list (the populated gatewayProxy attribute) either during the next scheduled update interval or when you start the Recipient Update Service with the Update Now command.

Determining What Action to Take on a Specific Object

When the Recipient Update Service is started by its schedule or by Update Now, the way it decides what to do on any particular object is exactly the same:

1. First, the Recipient Update Service determines which recipient policy to apply to the object. To do so, the Recipient Update Service sorts the list of policies and selects the policy with the highest priority that has a filter which applies to this object and that is not present in the msExchPoliciesExcluded attribute on the user. In other words, the Recipient Update Service selects the highest-priority non-excluded policy that applies to the user. When the choice is made, the Recipient Update Service stamps the objectGUID attribute of that policy into the msExchPoliciesIncluded attribute on the recipient.
2. Second, the Recipient Update Service determines whether the recipient is new. If the recipient has no proxy addresses, then it is considered to be new and the Recipient Update Service stamps the recipient with all the checked addresses on the policy. The "to do" list does not play any role in the stamping of new recipients.
   
   If the recipient is not new, the Recipient Update Service consults the "to do" list:
   1. If any of the primary addresses for this policy are populated in the gatewayProxy attribute of the Recipient Update Service and the addresses that are currently on the object do not match the policy, the Recipient Update Service regenerates those primary addresses. The previous primary address becomes a secondary address.
   2. If any secondary addresses that are listed in gatewayProxy do not already exist on the recipient, the Recipient Update Service adds those secondary addresses to the recipient.
   3. If any address type is set for removal in the "to do" list, the Recipient Update Service removes all addresses of that type from the recipient.
   When all steps in the "to do" list are complete, the Recipient Update Service continues with the next step.
   
   Note In Exchange Server 2003 Service Pack (SP1), a new GUID was added that will cause the Recipient Update Service to act as if the policy is applied for a specific recipient. If the MSExchPoliciesIncluded attribute on the recipient contains the value {23668AD4-4FA1-4EE8-B2BB-F94640E8FBA0},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}, the Recipient Update Service will perform steps 2a and 2b just as if the gatewayProxy attribute were populated with the proxy addresses from the policy that matches the recipient.
   
   For more information, click the following article number to view the article in the Microsoft Knowledge Base:
   820381 The secondary SMTP proxy e-mail address is not stamped on migrated objects
3. If the recipient has no addresses of an address type that is selected on the policy, the Recipient Update Service adds the selected primary address of that type. The Recipient Update Service does not add any secondary addresses in this step and does not evaluate whether or not the address of a type matches the format of the address specified on the policy. The Recipient Update Service checks only to see if an address of that type exists.

From this information you can draw the following conclusions:

• The Recipient Update Service regenerates primary addresses on a recipient to match their policy only if the policy has been applied and gatewayProxy is populated. Otherwise, the Recipient Update Service never verifies that the addresses on a recipient match the policy on that recipient.
• The Recipient Update Service adds secondary addresses only when the recipient is new or when the policy has already been applied. If an administrator adds a new secondary proxy to an existing policy, the new address is not added to existing users until the policy is applied.
• If you clear the check box for a primary address on a policy, all addresses of that type are removed when you apply the policy. When you click to clear the address on the policy, the Recipient Update Service does not prompt you to apply the policy, and the addresses are not removed. However, if you apply the policy at a later date, the addresses are removed. This also applies if you remove the address type from the policy.
  
  If you remove the address type and do not apply the policy, the addresses of that type are not removed from the recipients. If you apply the policy at a later date, the address type is not removed because the gatewayProxy attribute is not populated with the instruction to delete the address type. If you want to remove these addresses, you must add an address of that type back to the policy, click to clear the check box for that address, and then apply the policy.

Examples

For example, assume there is a recipient policy that has the following addresses checked:

• SMTP:@litwareinc.com
• smtp:@cpandl.com
• X400:c=us;a= ;p=Organization;o=Exchange;
• CCMAIL:at SITE

The check box for following address is cleared on the policy:

• MSMAIL:COMPANY/SITE

A recipient has the following e-mail addresses:

• SMTP:user1@northwindtraders.com
• X400:c=us;a= ;p=Organization;o=Exchange;s=last;g=first;
• MSMAIL:COMPANY/SITE/USER1

If the policy has not been applied (in other words, the gatewayProxy attribute is not populated), the Recipient Update Service takes the following steps based on the steps that are described earlier in this article:

1. Determine which policy applies to this recipient. In this example, the same policy applies that was applied before, so msExchPoliciesIncluded already contains the corresponding policy GUID.
2. Because the recipient already has e-mail addresses the recipient is not new and the Recipient Update Service proceeds to step 3 (because gatewayProxy is empty, steps 2a through 2c are skipped).
3. Although CCMAIL is checked on the policy, the recipient has no addresses of the type CCMAIL, so the Recipient Update Service adds the primary CCMAIL address to the recipient.

In this example, the only action taken is to add the missing primary CCMAIL address.

However, if the policy is applied and gatewayProxy is populated, the process is a little different:

1. Determine which policy to apply (the same policy as before).
2. The recipient is not new.
   1. Regenerate the primary SMTP address because it does not match the primary address in the policy. Demote the current SMTP primary address to a secondary address.
   2. Add the secondary SMTP address, because the recipient does not already have a secondary SMTP address that matches this policy.
   3. The check box for the MSMAIL address is cleared in the policy. Therefore, because the policy has been applied, that address type is removed.
3. Add the CCMAIL address.

In this example, after the process is complete the recipient's e-mail addresses look similar to the following list: Only the X400 address was unchanged. The other addresses were all changed.