Good bye RUS
Published Oct 02 2006 03:41 PM 21.3K Views

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

15 Comments
Not applicable
Good article.  We do use MIIS to provision users.  We generally put in 3 critical attributes and let the RUS populate the rest.  I'm assuming that your article means none of those would be populated any longer if, for instance, we we e-mail enabling someone who had no had it before?  Any idea if the MIIS folks are releasing anything to fill this gap?  Or will we be custom coding again?
Not applicable
Good post. Only one question left: in E2003 the RUS also generates Address Lists - how is this done in E2007? Christian
Not applicable
Can you please clarify the co-existence part... it sounds like until the last Ex2k3 server is removed, the RUS is needed in the organization.  But, is it only used for new users on 2003 servers?  Or does it indeed still stamp even a new 2007 user...

Thanks!
Not applicable
As a SQL Server DBA and part time Exchange admin, I'm happy to see a more simplified Exchange and hopefully it will be mostly self managing / self tuning in the future.
Not applicable
Lee - not totally clear on your question. As I mention in the last part of the blog post, you can "kick" these user accounts into being fully provisioned by using the cmdlets. MIIS will probably update at some point to use the new Exchange provisioning model, but I don't know their schedule.
Not applicable
Christian - The Address List generation is very similar to the Email-Proxy generation. The only thing that is gone from 2003 to 2007 is the asynchronous service part of the RUS. So the API to do the Address List calculation is still in place (and called by the cmdlets directly).
Not applicable
Brian - The E2k7 server will do its own proxy address and address list calculations without requiring an E2k3 RUS "service". However, E2k3 doesn't understand a world where each domain is not covered by an E2k3 RUS. Ensuring that you have a RUS for each domain during E2k3/E2k7 interop is really about meeting the E2k3 requirement, not because E2k7 needs this service to be running for anything.
Not applicable
How do you fire the cmdlets from a non-MSFT provisioning platform?

One of the nice things about the RUS was that you could use simple LDAP calls to provision which is available from just about every platform out there be it mainframe or VAXes or *nix or Windows. CmdLets will not have that same availability and scope. Will there be an easy click this to have the cmdlets run every x minutes on a given Exchange Server capability or will folks each be inventing their own mechanisms until some vendor comes up with a solution?

Overall, it is a little sad, IMO, to use an open directory standard but proprietary provisioning mechanisms.

  joe
Not applicable
Joe - I am not aware of any way to call these cmdlets from a non-MSFT provisioning platform. As described in the post, however, you can schedule (with "AT", for instance) the cmdlets needed to simulate the provisioning function of the legacy RUS.
Not applicable
Good post,
Per KB 318774, multiple domains, latency in replication and Enterprise RUS and Domain RUS pointing to different DCs can cause RUS to create duplicate addresses.

Is there any possibility in Exchange 2007 too to have two or more directory objects to have same addresses stamped?
Not applicable
mandeepU - the "dueling admin" case is still possible (ie - point one admin console at DC1 and a second admin console at DC2, make simultanous changes in each). Not having the RUS (and possible multiple RUS) out there doing asynchronous provisioning will cut down on these conflicts happening outside of this case, however.
Not applicable
Thanks Evan, I tried everything to repro event 9514 (duplicate proxy addresses) on my Beta2 build, but was not successful.

I'll try it the way you suggested and hopefully be successful this time.

Thanks.
Not applicable
Evan, thanks for the information which is really useful. I've been playing with Beta 2 and overall think it's awesome (without even firing Outlook 2007 up as yet).

I do think though that there was some elegance to creating a user with mailbox from AD Users & Computers, even with the associated problems and penalties. What springs to mind in particular is that within the same app, you created that user with mailbox, and then were easily able to add them to groups or set other attributes. Not to mention that you were fully in control of the OU in which the user was created.

Yes, I see that we can select an existing user, and that's cool. But it means two applications. I don't know about you, but I like to keep things as quick and easy as possible for my help desk staff.

On top of which I'm really not enthused about the need to manually associate Managed Folder Mailbox Policies and ActiveSync policies to each user. That plainly and simply sucks- you'll happily apply new email address policies to all users, but it seems nothing else.

I'm sorry - I'm very enthusiastic about Exchange 2007 and I think there's a lot there that's a huge step in the right direction. But please think about your customers and pay attention to the little things too. Simple things like (for example) new integration to AD Users & Computers to fix my first gripe (or alternatively, expand the capabilities of recipient configuration), and consistency in the application of policy to users. After all, you have filters there for things like Company - you could expand the filters a little incidentally - so why not use them to their best extent, an engine that automatically applies the policy to existing users and then by default to new ones. It couldn't cost much in development time, surely.

Perhaps if I were speaking from the perspective of someone with MIIS or other software, I'd be more relaxed about the first issue - sure, it sounds reasonable to me to schedule a periodic script (not too far different from RUS after all). But I'm not, and neither would a significant number of customers. And the policy stuff is just plain stupid; after all, what if I ever dare to think of changing it ...

Anyway, thanks for your time. Again, I'm enthusiastic about 2007, it really is fantastic - but take care of the fine detail!!!!
Not applicable

Policies in Exchange are designed to enable flexible administration of large numbers of Exchange objects....
Not applicable
I have previously listed the progress we've been making in posting ITPro focused Systems Management blog
Version history
Last update:
‎Jul 01 2019 03:18 PM
Updated by: