Recipient Policies and pure Exchange 2000/2003 sites
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.
Preparation
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:
(&(mailnickname=*)(myAttribute=myValue))
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.
Verification
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.
[Via You Had Me At EHLO…]