Exchange's Recipient Update Service was important in Exchange 2000 or 2003 in order to complete the provisioning or updating of mailboxes created from an out-of-band process or from an Active Directory User. In Exchange 2007, full provisioning is automatic, but the functionality can replaced by Powershell scripting if it is required.  

Exchange 2000 and Exchange 2003 included a component known as the Recipient Update Service or RUS.  The RUS runs as a sub-process of the System Attendant, and is responsible for discovering partially provisioned mailboxes and fully provisioning them.  The RUS is required because when user accounts are configured to have a mailbox using Active Directory Users and Computers (ADUC), they only have a few key attributes assigned.  When the RUS discovers these partially configured accounts they are stamped with the remaining required attributes and a mailbox will subsequently be created in the appropriate Exchange database when the mailbox is either logged onto or receives a message.

Many Exchange administrators who have worked with Exchange 2000 or 2003 will have experienced times when the RUS hasn’t worked at all or has worked slowly, and as a result have had problems with mailbox provisioning or updates.

In Exchange 2007 the RUS is no longer present because when a mailbox is provisioned in either of the Exchange management tools it is automatically fully provisioned straight away.  This is great if mailboxes are only ever provisioned using the Exchange 2007 tools, but if you use an out-of-band process to provision mailboxes you will run into trouble as those mailboxes will never be picked up and fully provisioned by Exchange 2007. 

For example, in Exchange 2003 it’s possible to cause a mailbox to be provisioned simply by setting the LegacyExchangeDN, Mailnickname, and homeMDB attributes on a user object.  The RUS will find the user account and will finish provisioning the mailbox.  If you try this with Exchange 2007 you won’t get a usable mailbox

Fortunately, there is a way to emulate the Exchange 2000/2003 RUS on Exchange 2007 using two Exchange 2007 PowerShell cmdlets, Update-EmailAddressPolicy which will apply an email address policy to mailboxes, and Update-AddressList which will update address list memberships. 

The easiest way to run the “update” cmdlets is to pipe input to them from the “get” cmdlets.  These commands will update all email address policies and address lists:

After running these commands the mailbox will be provisioned and will appear in the Exchange address lists, but it will appear in the Exchange Management Console as a “Legacy Mailbox”.  A legacy mailbox will still function for sending and receiving email, but it’s not possible to enable or disable Exchange 2007 features such as Messaging Records Management or Unified Messaging.  Legacy mailboxes can be converted to Exchange 2007 mailboxes using the Set-Mailbox cmdlet with the -ApplyMandatoryProperties parameter.

If your Exchange environment has only Exchange 2007 servers this command will update all legacy mailboxes to Exchange 2007 mailboxes:

If you have mailboxes hosted on legacy versions of Exchange and on Exchange 2007 you will need to filter the command to only touch those hosted on Exchange 2007.  This command will do that by first getting only the Exchange 2007 servers then finding all the legacy mailboxes on those servers:

The same problem exists for changes made to users outside of the Exchange Management tools.  Any changes made within the Exchange 2007 tools are instantly reflected in the user’s email addresses and address list membership, but changes which would impact email address polices and address list memberships that are made using out-of-band tools such as ADUC, ADSIEdit, or other tools for directly editing Active Directory will not show up in the Exchange 2007 mailbox properties until the same “update” commands are run.

For example, if there is an email address policy which applies email addresses in the format firstname.lastname, and the last name of a user is changed using an Exchange 2007 tool the user will instantly get a new email address with the new last name.  If the same change is made using an out-of-band tool or process then the name change will not be reflected in the user’s Exchange email addresses.

This problem can also be solved by running the Update-EmailAddressPolicy and Update-AddressList cmdlets.

So, if your environment requires out-of-band mailbox provisioning or user updates then the simplest solution is to put these three commands into a PowerShell script and schedule it to run as often as needed (don’t forget that if you still have mailboxes hosted on legacy Exchange servers you need to change the last command to the filtered version shown above):

To run the Update-EmailAddressPolicy cmdlet you need to be delegated the Exchange Server Administrator role and have local Administrators rights for the Exchange server. To run Update-AddressList you need to be delegated the Exchange Organization Administrator role.  To run the Set-Mailbox cmdlet you need to be delegated the Exchange Recipient Administrator role.

More Information on the cmdlets can be found on the Microsoft TechNet website:

• Update-EmailAddressPolicy – http://technet.microsoft.com/en-us/library/aa996869.aspx
• Update-AddressList – http://technet.microsoft.com/en-us/library/aa997982.aspx
• Set-Mailbox – http://technet.microsoft.com/en-us/library/bb123981.aspx