Recipient policies come in two flavors. The first generates email addresses. With Mailbox Manager settings, the second is used to report on or purge items in a mailbox that meets certain parameters. It's typically used to flush items past a certain age in folders like Deleted Items.
The primary consideration here is the recipient policy used to generate email addresses. The default recipient policy creates two email addresses: a default SMTP address and an X.400 address.
Deleting email address rules in the default recipient policy: Rules in the default recipient policy can be modified to accomplish tasks like generating email addresses for an SMTP address space for your public/registered DNS domain. These rules should not be deleted, and the recipient policy GUI actually prevents you from doing so.
However, if any of these are deleted using a tool like ADSIEdit, which the Exchange System Manager GUI has no control over, it will prevent critical services like the information store service and MTA Stacks service from starting. This will result in an outage.
Recipient policies based on organizational units (OU): Another misconception and a frequently asked question in many forums is how one can apply a recipient policy to recipients in a particular OU, or apply the policy to an OU so it gets applied to all recipients in that OU.
The answer is, you can't. Recipient policies are applied to recipients filtered on recipient attributes, such as department, location, city, or country. They can be used to apply the policy irrespective of the recipient's location in the Active Directory hierarchy of containers and OUs.
If you need to apply the policy to all OU recipients, you can either use the common attributes or one of the extension attributes -- perhaps by populating one of them with the name or the distinguishedName of the OU, or some other string.
Keep in mind that this will add another task to the process of managing recipients. When users are created or moved to or from the OU, you have to make sure that the particular attribute you decide to use is populated or removed.
If the recipient policy is being used to assign an SMTP address from a different address space, you can generate different UPN suffixes for those domains. This is typically done in a hosting scenario where multiple customers with different SMTP/DNS domains are hosted in a single AD forest.
Recipient Update Service (RUS) in a multi-domain forest: If your forest has multiple domains where recipients reside, you will need to run DomainPrep in those domains. DomainPrep needs to be run in any domain that has recipients, Exchange servers, or global catalogs. Additionally, a Recipient Update Service (RUS) needs to be created that points to a domain controller in that domain.
Multiple RUS objects for a single domain: By default, Exchange Server creates two RUS objects -- one for the enterprise, which processes Exchange system objects, and the other for the domain in which the Exchange server resides.
It is generally not recommended to create more than one RUS pointing to domain controllers (DCs) in the same domain. However, if you have DCs in the same domain, spread across remote sites with slow WAN links and the resulting latency, you can create additional RUS objects pointing to DCs in the remote sites. This ensures that recipients created in those remote sites are processed faster by RUS.
BEST PRACTICES GUIDE: THE 10 MOST COMMON EXCHANGE SERVER ISSUES
Home: Introduction
Issue #1: Exchange Server storage sizing and location
Issue #2: SMTP virtual server and connector configuration
Issue #3: Exchange recipient policies and Recipient Update Service
Issue #4: Exchange Server messaging hygiene
Issue #5: Exchange Server and DNS
Issue #6: Front-end/back-end Exchange Server topology issues
Issue #7: Exchange Server information stores and mailbox sizes
Issue #8: Moving or removing Exchange servers
Issue #9: Exchange Server backups and disaster recovery
Issue #10: Exchange Server monitoring -- or lack thereof
| ABOUT THE AUTHOR: |
|
Bharat Suneja, Microsoft Exchange MVP
Bharat Suneja is a Microsoft Certified Trainer (MCT), Exchange MVP, and Principal Exchange Architect for Zenprise, Inc., maker of real-time troubleshooting and diagnostics software for Exchange. Bharat Suneja has over 10 years of experience in IT, architecting and managing Exchange Server and Active Directory environments, ranging from small and mid-sized businesses and e-commerce companies to large ISPs and ASPs. An active writer and contributing editor for international IT publications such as PC Quest, Bharat was also a technical reviewer for Exchange Server 2003 24 Seven by Jim McBee. Visit Bharat Suneja's blog at www.exchangepedia.com/blog.
|
|
