Go Premium for a chance to win a PS4. Enter to Win


RUS is not updating addresses after a name change

Posted on 2008-10-19
Medium Priority
Last Modified: 2012-05-05
Several users in my organisation have had their surnames changed & want their email addresses also changed. Our Recipient Update policy specifies the primary address should be:

I change the name using the "rename" option in AD Users & Computers. I change the surname, the display name & both the login names. I expect the RUS to add new email addresses based on the new surname, but it fails to happen.
If I create a new user, email addresses are added correctly.

The RUS lists two Services - an ENTERPRISE CONFIGURATION and a COMPANY configuration (COMPANY = AD domain name). Both are set to "Always Run". Both use the same domain Controller and Exchange Server & these are valid.

I am fairly sure this used to work, but it has stopped. I would like to get the RUS correctly adding the new email addresses, rather than manually doing it.
Any thoughts?

Question by:dreadman2k
  • 4
  • 2
LVL 33

Expert Comment

ID: 22755429
This is how RUS should work::

"Determining What Action to Take on a Specific Object
When the Recipient Update Service is started by its schedule or by Update Now, the way it decides what to do on any particular object is exactly the same:

 First, the Recipient Update Service determines which recipient policy to apply to the object. To do so, the Recipient Update Service sorts the list of policies and selects the policy with the highest priority that has a filter which applies to this object and that is not present in the msExchPoliciesExcluded attribute on the user. In other words, the Recipient Update Service selects the highest-priority non-excluded policy that applies to the user. When the choice is made, the Recipient Update Service stamps the objectGUID attribute of that policy into the msExchPoliciesIncluded attribute on the recipient.
 Second, the Recipient Update Service determines whether the recipient is new. If the recipient has no proxy addresses, then it is considered to be new and the Recipient Update Service stamps the recipient with all the checked addresses on the policy. The "to do" list does not play any role in the stamping of new recipients.

If the recipient is not new, the Recipient Update Service consults the "to do" list:

 If any of the primary addresses for this policy are populated in the gatewayProxy attribute of the Recipient Update Service and the addresses that are currently on the object do not match the policy, the Recipient Update Service regenerates those primary addresses. The previous primary address becomes a secondary address.
 If any secondary addresses that are listed in gatewayProxy do not already exist on the recipient, the Recipient Update Service adds those secondary addresses to the recipient.
 If any address type is set for removal in the "to do" list, the Recipient Update Service removes all addresses of that type from the recipient.

When all steps in the "to do" list are complete, the Recipient Update Service continues with the next step.

Note In Exchange Server 2003 Service Pack (SP1), a new GUID was added that will cause the Recipient Update Service to act as if the policy is applied for a specific recipient. If the MSExchPoliciesIncluded attribute on the recipient contains the value {23668AD4-4FA1-4EE8-B2BB-F94640E8FBA0},{26491CFC-9E50-4857-861B-0CB8DF22B5D7}, the Recipient Update Service will perform steps 2a and 2b just as if the gatewayProxy attribute were populated with the proxy addresses from the policy that matches the recipient."


Author Comment

ID: 22763664
Thanks, Computer_Geek

OK, the problem I have falls into category 2a in your list.  I checked the gatewayProxy attribute for the policy in question & it has "SMTP:%g.%s@company.com", so it should notice that the user's SMTP address no longer matches that pattern & update the primary SMTP address.

I went through the steps of creating a new user in our testing environment (seperate forest) & got exactly the same issue - When I altered the surname, the email addresses would not update. I did an "UpdateNow" on the RUS and a "Rebuild" on the RUS with no effect. I also did a re-apply to the specific policy - no effect.

it seems like the change in the user's surname is not getting flagged & the RUS is happily passing over it.
What else can I check?

Author Comment

ID: 22763739
Sorry, that should have been "Exchange_Geek" above!
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.


Author Comment

ID: 22764504
UPDATE: The "rebuild" option does update the email addresses in the manner it is supposed to.
However, my live environment has several thousand users & I can't run Rebuild there too often.
Still looking for why it doesn't notice the change in surname.
LVL 33

Accepted Solution

Exchange_Geek earned 2000 total points
ID: 22764832
" If any of the primary addresses for this policy are populated in the gatewayProxy attribute of the Recipient Update Service and the addresses that are currently on the object do not match the policy, the Recipient Update Service regenerates those primary addresses. The previous primary address becomes a secondary address"

Why not un-check the box "Automatically update...." on email address tab of the user properties. remove the smtp addresses stamped (that is if the user only wants the new ones and are least bothered with old ones) - once done, check the box once more - update RUS. That should stamp with new email address as per filter.

Since, you are changing the surname, this might not have affect on update - since the update option would undergo to check if the primary SMTP address matches as per filter, some times this is over looked.

What you could do, is to increase the diagnostic logging as per KB - 246127 and check why this user is NOT being selected by RUS in application logs.

Author Closing Comment

ID: 31507724
Thanks for your assistance, Exchange Geek. Sorry for the long delay in accepting. I have been run around & this problem has been bumped in priority. Since I won't be coming back to it any time soon, you at least deserve the points , as the fault for lack of resolution is mine.

Featured Post

Learn Veeam advantages over legacy backup

Every day, more and more legacy backup customers switch to Veeam. Technologies designed for the client-server era cannot restore any IT service running in the hybrid cloud within seconds. Learn top Veeam advantages over legacy backup and get Veeam for the price of your renewal

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

How to effectively resolve the number one email related issue received by helpdesks.
In this post, I will showcase the steps for how to create groups in Office 365. Office 365 groups allow for ease of flexibility and collaboration between staff members.
This video demonstrates how to sync Microsoft Exchange Public Folders with smartphones using CodeTwo Exchange Sync and Exchange ActiveSync. To learn more about CodeTwo Exchange Sync and download the free trial, go to: http://www.codetwo.com/excha…
This video shows how to quickly and easily deploy an email signature for all users in Office 365 and prevent it from being added to replies and forwards. (the resulting signature is applied on the server level in Exchange Online) The email signat…
Suggested Courses

783 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question