In this post I'll talk a bit about the legacy Recipient Update Service (RUS) and explain the changes made to it for Exchange Server 2007.
Recipient Update Service
The Recipient Update Service was introduced in Exchange 2000 to discover and provision recipient objects. Recipients created through the Active Directory Users and Computers (ADUC ) snap-in are "partially provisioned" - that is, they have a few key properties set immediately by the console, but the rest of the properties are back-filled asynchronously by the RUS once it notices the new recipient exists.
The RUS is typically thought of as the process that looks for these new recipients, but there are actually two key functional parts to the recipient provisioning part of the RUS:
- An API to calculate the appropriate properties on recipient objects
- A subservice in System Attendant (MAD) which discovers the recipients that need updating and stamps them with the calculated properties
Changes in Exchange 2007
The key change to the RUS for Exchange 2007 is that the 2nd part (the subservice) is removed. In Exchange 2007, recipients are fully provisioned as they are created in the console GUI or in the shell, so there's no longer any need for an asynchronous service to discover these partially-provisioned recipients and finish the provisioning work. The API to calculate the properties required still exists in Exchange 2007 and is now used directly by the recipient management cmdlets to provision these recipient objects.
Note that since Exchange 2007 doesn't include the "service" part of the Recipient Update Service, configuring an Exchange 2007 server as the "Exchange Server" for a particular Recipient Update Service in Exchange 2003 system manager console will cause that RUS to stop working.
In addition to calculating and stamping email addresses and address list membership, the legacy RUS also did a few other tasks in the directory, as detailed by KB.253770. Here's a table of these other tasks and their equivalent behavior in Exchange 2007:
|
Exchange 2003 |
Exchange 2007 |
|
Setting permissions required for DL membership hiding |
Hidden DL membership is deprecated in Exchange 2007 |
|
Maintaining Exchange Enterprise Server group membership |
These groups are deprecated in Exchange 2007 |
|
Sets ACLs on Microsoft Exchange System Objects container in AD to handle delegation cases |
These ACLs are now set by the Exchange 2007 forestprep and are not altered during delegation, due to changed delegation mechanism in Exchange 2007. |
Why remove the RUS?
The RUS has always been a bit of a black box for administrators. When it works, it's great. But if it ever stops working as expected, it is quite difficult to figure out what's wrong. Worse, since the subservice processes recipients asynchronously, it is difficult to determine whether the subservice is "not working", or simply "working slowly".
The advantage of bringing the stamping of recipient objects into the cmdlets as a synchronous operation extends beyond troubleshooting, however. Even in the case where the RUS is working as expected, moving this functionality into a synchronous cmdlet execution allows for "instant on" recipient provisioning and faster service.
With Exchange 2007, you can immediately use a mailbox once the mailbox is created. No need to wait 5 minutes for the RUS to stamp the object!
RUS and Exchange 2003 Co-existence
If you are running Exchange 2003 and Exchange 2007 in an "co-existence" (you might also catch us calling it "interop") environment (both versions of Exchange in the same Exchange organization), you will need to continue to use the Exchange 2003 system management console to provision a RUS for each domain that has Exchange recipients . Note that this also includes domains with only Exchange 2007 servers and users present. That all domains which have been "domain-prepped" have a RUS is an Exchange 2000/2003 requirement which is unchanged for the co-existence scenario.
Workarounds for asynchronous provisioning
Some tools - such as Microsoft Identity Integration Server (MIIS) or custom external provisioning tools - might still create "partially provisioned" recipient objects and expect the RUS to finish out the provisioning. Although there is no longer a RUS watching for this sort of object automatically, it's still possible to support this sort of provisioning model with Exchange 2007.
To ensure these recipients are provisioned successfully, you will need to periodically run the Update-EmailAddressPolicy and Update-AddressList cmdlets. These cmdlets will detect any recipient objects that need to be updated and will stamp the EmailAddressPolicy or AddressList accordingly.
Running Update-EmailAddressPolicy and Update-AddressList is made much simplier by combining with Get-EmailAddressPolicy and Get-AddressList:
Get-EmailAddressPolicy | Update-EmailAddressPolicy
Get-AddressList | Update-AddressList
You should run the CMDlets in that order so users are fixed before the address lists are updated. Additionally, to update the Global Address List, you can run:
Get-GlobalAddressList | Update-GlobalAddressList
- Evan Dodds
