Recipient Policies and Exchange 2000 Server and Exchange Server 2003 Sites

Tópico modificado em: 2005-12-09

By Bill Long, Support Escalation Engineer

When a Microsoft® Exchange 2000 Server or Exchange Server 2003 site no longer contains Exchange Server version 5.5 servers, the "Highest Priority" policy based on the legacyExchangeDN attribute isn't needed anymore.

As Exchange Server 5.5 servers are decommissioned and environments move to only Exchange 2000 Server and Exchange Server 2003 sites, the question of how to remove the legacy site recipient policies often arises.

This is not complicated but does require some thought depending on what exactly you want to achieve.

• The Basics
• Preparation
• Creating the New Policies
• Deleting the Mixed-Site Policies
• Verification
• For More Information

The Basics

The logic of the Recipient Update Service is fairly simple, but often misunderstood. The details of the decision-making process are documented in Microsoft Knowledge Base article 328738, "How the Recipient Update Service applies recipient policies," and most of what you need to know about discarding your old policies is contained in that article.

The basics are:

• 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:
  • The user is new and has no proxy addresses.
  • The policy has been "applied," as described in Microsoft Knowledge Base article 328738, "How the Recipient Update Service applies recipient policies." In these two cases, the Recipient Update Service stamps addresses on people. The Recipient Update Service does not normally generate new address for recipients that already have them.

Preparation

To restate: The normal behavior of the Recipient Update Service is to leave a user's e-mail addresses alone, regardless of whether those addresses match the policy. It is not the normal behavior for the Recipient Update Service to regenerate recipient addresses to force them to match the policy. The regeneration of proxy addresses occurs only 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 Recipient Update Service looks at - they do not affect the decision-making process that occurs for each user. You can use Update Now and Rebuild all day long, and the Recipient Update Service will never change anyone's address unless you have a policy in the "applied" state. This is why Microsoft Knowledge Base article 328738, "How the Recipient Update Service applies recipient policies," is divided into two sections - one section on the type of query, and another section on the decision-making process.

As long as none of your policies is currently applied, reconfiguring your recipient policies has no impact. Before making changes that may cause users to fall under different policies, it's a good idea to be 100 percent sure that no policies are applied. To do this, use ADSI Edit (AdsiEdit.msc) or LDP (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 Microsoft Knowledge Base article 821743,"The gatewayProxy attribute on the Recipient Update Service object is not cleared." Also, don't confuse gatewayProxy on the Recipient Update Service objects with gatewayProxy on the Recipient Policies themselves. They serve two different purposes.

GatewayProxy on the Recipient Update Service should only be populated for a limited time. It is populated when the policy is applied, and the Recipient Update Service begins processing all the users who match the filter on the applied policy. If the Recipient Update Service finishes processing these users successfully, it clears the corresponding entries from gatewayProxy to take the policy back out of the applied state. However, for the reasons described in Microsoft Knowledge Base article 821743, "The gatewayProxy attribute on the Recipient Update Service object is not cleared," this doesn't always happen, and a policy may be left in the applied state indefinitely. There was also a bug in Exchange 2000 Server, described in Microsoft Knowledge Base article 835156, "Recipient policy changes are automatically applied to users in Exchange 2000 Server," 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 Server.

As long as gatewayProxy is empty on all your Recipient Update Service objects, and you have the update described in Microsoft Knowledge Base article 835156, "Recipient policy changes are automatically applied to users in Exchange 2000 Server," or a later fix, the Recipient Update Service will not make changes to any addresses just because a user's addresses don't match his or her current policy.

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

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

This command-line command will export the proxyAddresses attribute for every mail-enabled object in the specified domain, and you can also add any other attributes you want 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

Creating the new policies 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 from another. Are your e-mail addresses based on location? How about a filter based on city (the l attribute), or state (the st attribute). Are your e-mail 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 (admodify.net) tool can be handy when you need to populate an arbitrary attribute on a large number of users. After 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 that has the corresponding attribute value you've specified. For simple filters such as this one, you may find it easier to just choose Custom Search, click the Advanced tab, and type the filter in manually, instead of trying to select all the appropriate check boxes to do what you want.

To obtain the ADModify (admodify.net) tool, contact Microsoft Product Support Services. For more information about how to contact Product Support Services, see the Microsoft Support and Help Web site.

You can also obtain the ADModify utility from the GotDotNet Web site. For more information about obtaining this utility, see ADModify.NET: Workspace Home.

Deleting the Mixed-Site Policies

After you have your new policies created, use Exchange System Manager to delete the unwanted Exchange Server 5.5 site policies. Of course, you can do this step first if you want. 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 - because 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 Recipient Update Service processes each user, it updates their msExchPoliciesIncluded attribute to reflect the objectGUID attribute of the policy they fall under (though, again, it will not update their proxyAddresses attribute 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 action before running a Rebuild. Another option is to just make changes to a few select users. Change their Description, Zip, or anything you want. The Recipient Update Service 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 e-mail 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 check box. After you do this, the Recipient Update Service won't touch that user's e-mail addresses even if you apply the policy. This is another operation that can be automated for a large number of users by using ADModify (admodify.net).

For More Information

For more information, see the following Microsoft Knowledge Base articles:

• 328738, "How the Recipient Update Service applies recipient policies"
• 821743, "The gatewayProxy attribute on the Recipient Update Service object is not cleared"
• 835156, "Recipient policy changes are automatically applied to users in Exchange 2000 Server"