Recipient Policies and pure Exchange 2000/2003 sites

re: Recipient Policies and pure Exchange 2000/2003 sites

Zach — Wed, 20 Apr 2005 19:59:28 GMT

Superb Article, Impeccable Attention to Detail! 31337 ;)

re: Recipient Policies and pure Exchange 2000/2003 sites

Teo Gomez — Wed, 20 Apr 2005 22:32:05 GMT

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!

Teo

re: Recipient Policies and pure Exchange 2000/2003 sites

Adam — Wed, 20 Apr 2005 23:20:14 GMT

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?

re: Recipient Policies and pure Exchange 2000/2003 sites

Bill Long — Thu, 21 Apr 2005 00:06:42 GMT

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.

Exchange, Windows, SQL, Misc.

Windows Server Clustering — Thu, 21 Apr 2005 00:54:10 GMT

re: Recipient Policies and pure Exchange 2000/2003 sites

Steven Presley — Thu, 21 Apr 2005 16:15:47 GMT

Awesome article...thanks Bill!

re: Recipient Policies and pure Exchange 2000/2003 sites

Ben N — Thu, 21 Apr 2005 17:57:06 GMT

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!

re: Recipient Policies and pure Exchange 2000/2003 sites

Christian Schindler — Wed, 27 Apr 2005 10:29:21 GMT

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...

re: Recipient Policies and pure Exchange 2000/2003 sites

Bill Long — Wed, 27 Apr 2005 18:22:00 GMT

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.

re: Recipient Policies and pure Exchange 2000/2003 sites

Igor — Wed, 11 May 2005 09:52:26 GMT

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>@domain.com
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>@domain.com. Those users whose SMTP address is already in the format <user_AD_account>@domain.com 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.
Thanks

re: Recipient Policies and pure Exchange 2000/2003 sites

Bill Long — Wed, 11 May 2005 19:02:46 GMT

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 %g%1s@domain.com ... that would be given name followed by first letter of surname - see Q285683), or uncheck "Automatically update email addresses" on the users.

re: Recipient Policies and pure Exchange 2000/2003 sites

igor — Wed, 11 May 2005 20:01:41 GMT

Bill, thanks for your reply.
There is no values stuck in gatewayProxy.
The SMTP Generation rule defined as *@domain.com in each recipient policy and I just expect RUS will do nothing with user SMTP address if user already have smtp address like <something>@domain.com (even with discrepancy between user AD account name and first part of their SMTP address).
We cannot use %g%1s@domain.com 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

Exchange, Windows, SQL, Misc.

Windows Server Clustering — Thu, 12 May 2005 04:38:24 GMT

re: Recipient Policies and pure Exchange 2000/2003 sites

Dan — Fri, 13 May 2005 23:53:40 GMT

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.

re: Recipient Policies and pure Exchange 2000/2003 sites

Bill Long — Tue, 17 May 2005 06:12:03 GMT

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:

{23668AD4-4FA1-4EE8-B2BB-F94640E8FBA0},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}

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.

re: Recipient Policies and pure Exchange 2000/2003 sites

Dan — Wed, 18 May 2005 04:29:55 GMT

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