Recipient Policies and pure Exchange 2000/2003 sites

Published Apr 20 2005 02:21 PM 6,525 Views

Once a site has no Exchange 5.5 servers in it, that old "Highest Priority" policy based on legacyExchangeDN isn't needed anymore. As people decommission their 5.5 servers and move to pure Exchange 2000 and 2003 sites, the question on how to get rid of the old site recipient policies often arises. This is not as complicated as people often think, but it does require some thought, depending on what exactly you want to achieve.

The logic of the RUS is fairly simple, but often misunderstood. The details of the decision-making process are documented in article 328738, and all you really need to know about throwing out your old policies is contained in that article. The basic idea is this:

- In the Recipient Policies container, you have a set of recipient policies.
- Each policy has a priority and a filter.
- The policy for each user is the policy with the highest priority (the lower the number, the higher the priority) with a filter that matches the user.
- The recipient policy only really matters in two situations. 1) The user is new and has no proxy addresses. 2) The policy has been "applied", as described in article 328738. In these two cases, the RUS stamps addresses on people. The RUS does not normally generate new address for recipients that already have them.


Let me restate - the normal behavior of the RUS is to leave a user's email addresses alone, regardless of whether those addresses match the policy. It is not the normal behavior for the RUS to regenerate recipient addresses to force them to match the policy. The regeneration of proxy addresses only occurs when the policy is in an "applied" state. Update Now doesn't do it, nor does a Rebuild. These two options only control the scope of users that the RUS looks at - they do not affect the decision-making process that occurs for each user. You can Update Now and Rebuild all day long, and the RUS will never change anyone's address unless you have a policy in the "applied" state. This is why article 328738 is divided into two sections - one on the type of query, and another on the decision-making process.

This means that as long as none of your policies are currently applied, reconfiguring your recipient policies has no impact. Before you start making changes that will cause users to fall under different policies, though, it's a good idea to be 100% sure that no policies are applied. To do this, use ADSI Edit or LDP.EXE to go to your Recipient Update Services container and view the properties on each Recipient Update Service. Make sure that the gatewayProxy attribute on these objects is clear. This process is described in article 821743. Also, don't confuse gatewayProxy on the RUS objects with gatewayProxy on the Recipient Policies themselves. They serve two different purposes.

GatewayProxy on the RUS should only be populated for a limited amount of time. It is populated when the policy is applied, and the RUS begins processing all the users who match the filter on the applied policy. If the RUS finishes processing these users successfully, it will clear the corresponding entries from gatewayProxy to take the policy back out of the applied state. However, for the reasons described in article 821743, this doesn't always happen, and a policy may be left in the applied state indefinitely. There was also a bug in Exchange 2000, described in article 835156, where the policy would continue applying even after gatewayProxy was cleared, until the System Attendant service was restarted. This fix was included in the latest rollup for Exchange 2000.

As long as gatewayProxy is empty on all your RUS objects, and you have the article 835156 or a later fix, the RUS will not be making changes to any addresses just because a user's addresses don't match his current policy.

If you're still nervous about making these changes, consider getting an export of everyone's email addresses before you start. This is easy to do with ldifde, using syntax like:

Ldifde -d "DC=domain,DC=com" -r "(&(mailnickname=*))" -l proxyAddresses -f proxies.txt

This command line will export the proxyAddresses attribute for every mail-enabled object in the specified domain, and you can also add any other attributes you like to the -l parameter. You can use a simple script to reformat this file as an import and put all the proxy addresses back in their previous state if something goes wrong.

Creating the new policies

This is the part that takes some thought, and the solution will vary from one organization to another. If all your users should have a single addressing scheme, just configure the Default Recipient Policy accordingly and you're done. If you need several different addressing schemes, determining the appropriate filters for your new policies may take some planning. You'll need to identify an attribute on the users that distinguishes one group of people from another. Are your email addresses based on location? How about a filter based on city (the "l" attribute), or state (the "st" attribute). Are your email addresses based on department? Then maybe a filter based on that (the "department" attribute) would work. If none of the existing attributes on the users will work for you, you can always use one of the extension attributes, such as extensionAttribute1. The ADModify tool can be handy when you need to populate an arbitrary attribute on a large number of users. Once you know what attribute you want, building a basic filter using that attribute is easy:


This filter matches any mail-enabled object which has the corresponding attribute value you've specified. For simple filters like this, you may find it easier to just choose Custom Search, click the Advanced tab, and type the filter in manually, instead of trying to choose all the appropriate checkboxes to do what you want.

Once you have configured your new policy, click OK, but beware! At this point, if you have changed the e-mail addresses that were specified on the policy by default, ESM will prompt you asking if you want to apply the policy. Clicking Yes will populate gatewayProxy and could cause the regeneration of email addresses on anyone who falls under this policy. It is best to choose No unless you want the RUS to go around changing addresses on people.

Deleting the mixed-site policies

Once you have your new policies done, simply use Exchange System Manager to delete the unwanted 5.5 site policies. Of course, you can do this step first if you like. Unless you've already created other policies that will match the users in those sites, they will now fall under the Default Policy. But this doesn't matter - since the Default Policy is not in the applied state (you know this because you checked gatewayProxy), their addresses will not be regenerated to match it.


After your old legacyExchangeDN-based policy is deleted and your new policies are configured, you're done. If you want to verify your policy configuration, you can run a Rebuild. As the RUS processes each user, it will update their msExchPoliciesIncluded to reflect the objectGUID of the policy they fall under (though, again, it will not update their proxyAddresses to match this policy as long as you have not applied the policy). You can look at the GUIDs stamped in msExchPoliciesIncluded to verify that the users are getting the policies you intended. However, keep in mind that a Rebuild can take hours or even days in the largest environments, so carefully consider this before running a Rebuild. Another option is to just make changes to a few select users. Change their Description, Zip, or anything you like. The RUS will evaluate them and stamp the new msExchPoliciesIncluded value.

As a general rule, it is not a good idea to have users fall under a policy that their addresses don't match. Someday, someone is going to apply your policies if only by accident or as a troubleshooting measure. If you want to manually configure email addresses on users and never have them be affected by applying a policy, it's best to go to the Email Addresses tab and clear the "Automatically update e-mail addresses based on recipient policy" checkbox. Once you do this, the RUS won't touch that user's email addresses even if you apply the policy. This is another operation that can be automated for a large number of users by using ADModify.

- Bill Long

Not applicable
Superb Article, Impeccable Attention to Detail! 31337 ;)
Not applicable
I've been had several heated discussions about the 'Rebuild' option within the RUS. It's great to finally have this blog and KB article to point people to!

Not applicable
Excellent article defiantly brings the Recipient Update Service to life. Obviously coming from a grand poobah of Exchange. Does the RUS behave any differently went the site becomes only Exchange 2003 servers?
Not applicable
There's no difference in the way the RUS behaves in Exchange 2003 under normal circumstances. The one exception is when you've migrated users using the Exchange 2003 Sp1 Migration Wizard. Sp1 added new functionality where migwiz stamps a special GUID in msExchPoliciesIncluded on migrated users. This GUID signals the RUS to stamp any missing secondary addresses on the user, even if the policy has not been applied.
Not applicable
Awesome article...thanks Bill!
Not applicable
OMG.. this blog post came at the right time.. I was having a serious problem with my RUS the last week or so.. You gave me enough info here to stop it from being on perma-update mode :)
And i didn't know i could delete that legacy recip policy. now this works perfectly like i hae always wanted it to. Thank you!
Not applicable
Excellent Article! Thank you Bill! There's only one question left: Why isn't it possible to build a filter which returns all objects in an Organizational Unit? It is possible with query based DL's...
Not applicable
There are three parts to an LDAP query: 1) the root of the search (the top container where the search will start), 2) the scope of the search (Base, One Level, or Subtree), 3) the filter. When you can specify all three of these, you can build a query for pretty much anything. For instance, to return all users in a single OU, you just specify that OU as the search root, you set your scope to One Level (so that it only returns users in that OU and doesn't traverse subcontainers), and you set the filter to something like (objectClass=user).

Unfortunately, recipient policies do not let you specify all three of these parameters. For recipient policies, the root of the search is always the root of the domain that the RUS points to. The scope of the search is always Subtree, so it traverses every child container. The only thing you get to specify is the filter. It is impossible to distinguish between OU's based on filter alone (unless you populate an attribute on the users that will signify what OU they are in).

You may say, "but every user has a distinguishedName attribute, and that attribute shows what OU they're in." True, but you can not do substring searches on DN-valued attributes in the Active Directory. For instance, (distinguishedName=*,OU=myOU,DC=domain) is not a valid LDAP query.

So now you may say, "Well that's dumb, why doesn't Active Directory support substring searches against DN-valued attributes?" RFC 2251 in section 4.1.9 refers to X.500 for what the matching rules do. A DN-valued attribute follows the distinguishedNameMatch matching rule, defined in X.501 section 12.5.2. This matching rule does matches of whole DNs, which is what AD implements.

The reason this works for query-based DG's is that they allow you to specify the root of the search. They still don't let you specify the scope, which will always be a Subtree search.
Not applicable
Excellent article !
May be you can answer my question about our RUS problem:
Our organization started to migrate from Exchange 5.5 to Exchange 2003.
We have one Exchange organization with nine Exchange 5.5 sites (9 servers) and we plan to consolidate them to into 5 routing groups (5 servers) of exchange 2003 . We have an AD domain in native mode (Win2k DC), and Exchange 2003 SP1 is installed on our Windows 2003 servers. We have more than 900 user mailboxes.

In most of the cases our user SMTP addresses are defined in the format: <firstname><first_letter_of_surname>
The name of an AD User account never equals <firstname><first_letter_of_surname>, and each of our users has only one SMTP address.
In our Exchange 2003 organization the Default recipient policy (with Lowest priority) is and 9 recipients policies from Exchange 5.5 sites (with Highest priority). All the policies are defined to have only one SMTP address.

The problem is:
When the RUS is running (event id 8329), those users with a discrepancy between their AD account name and first part of their SMTP address are automatically given a second SMTP address (as their primary SMTP address) in the format <user_AD_account> Those users whose SMTP address is already in the format <user_AD_account> are not given any additional SMTP address.

This same thing happens also with user X400 addresses and with Distribution Lists X400/SMTP addresses.

We would like to know if the above is normal behavior and if any workaround available.
Currently we have disabled RUS from running.
Not applicable
When you apply a policy, if the recipient address does not match the format specified on the policy, a new primary address is generated and the existing primary is demoted to secondary. This is indeed the normal behavior, assuming that the policy has been applied. If the RUS is doing this constantly, you have values stuck in gatewayProxy as I discussed in the blog.

To stop this behavior, you can clear out gatewayProxy as I described. However, this will happen again the next time you apply the policy. You should either change the primary SMTP address on the policy to match the recipients (in your case it sounds like it should be ... that would be given name followed by first letter of surname - see Q285683), or uncheck "Automatically update email addresses" on the users.
Not applicable
Bill, thanks for your reply.
There is no values stuck in gatewayProxy.
The SMTP Generation rule defined as * in each recipient policy and I just expect RUS will do nothing with user SMTP address if user already have smtp address like <something> (even with discrepancy between user AD account name and first part of their SMTP address).
We cannot use because we have first/last name in Hebrew, so I will use ADModify to uncheck "Automatically update email addresses".
If in native Exchange 2003 mode RUS will works with same behavior ?
Thanks, Igor
Not applicable
Is it possible to have the RUS understand that as an individual person moves from Business unit #1 to Business unit #2, both their own recipient policies keyed on the department field, to have it add the primary address of Business unit #2 and keep the old primary as a secondary?
The way I read things, currently the only way to get the RUS to stamp a new address on an existing mailbox (w/o applying the policy to everyone) is to blank the proxyaddresses field on that mailbox to fool the RUS into thinking it ias new mailbox. This is obviously undesireable.
Basically looking for a solution to have the RUS auto-add new Primary SMTP address as users move between business units w/o affecting the entire populace.

Thanks for the awesome article, it really helped us out well.
Not applicable
Igor, that's odd that it's behaving that way even with nothing in gatewayProxy. Unchecking "Automatically update" will certainly stop it, though. Native mode shouldn't change the behavior at all.

Dan, your understanding is correct. After changing the department to reflect the new business unit, the user's email addresses will remain unchanged unless you "Apply This Policy Now", which will cause the RUS to evaluate everyone under that policy. However, if you are running the RUS on a 2003 Sp1 server, you could use the new GUID that was added for the migration wizard. In answer to an earlier question I said that this GUID signals the RUS to stamp any missing secondaries, but really it triggers a full application of the policy against that particular user - including primary addresses. Populating msExchPoliciesIncluded with the following value should effectively cause the RUS to apply the policy to just that one recipient:


Unfortunately there's no way to do this automatically except through the Migration Wizard right now. However, you could easily write a script or make your own extension for ADU&C that would do this.
Not applicable
That is actually perfect. We were scripting up the process to move users between the business units anyway (a web page request), so simply adding the value to the migrated recipients AD account is perfect.
I would imagine most companies wouldn't need this as most don't host multiple and completely seperate business units each with unique SMTP addresses. This would only be an issue for hosting environments.

Thank you VERY much for providing this valuable resource.

Dan Sheehan
Version history
Last update:
‎Jul 01 2019 03:05 PM
Updated by: