[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1724
  • Last Modified:

Exchange 2010 Recipient Update Service

I'm  testing a migration from Exchange 2003 to Exchange 2010 and have a lab setup to mirror my prod environment.  I have a recipeint updated policy in my Exchange 2003 environment that marks the accounts with a username@mydomain.com.  When I create a new user in the domain the policy runs and tags the user account with the generic smtp alias.   I then manually edit the address since I have 4 business divisions with different external email aliases.  

When I migrated all of the accounts in my test environment to my Exchange 2010 the RUS in the 2010 environment has run again and rebranded all of my accounts with the username@mydomain.com alias and marked that as the default.  It seems I'm missing something, and I can't move forward in production if all of my user accounts are going to be rebranded.  Is there a way to prevent the RUS from running again once the account has been migrated?

When I try to edit the RUS on the Exchange 2010 server it tells me I have to edit it on the 2003 server.

0
shanemccutch
Asked:
shanemccutch
  • 3
  • 2
1 Solution
 
KSK2000Commented:
Pls uncheck “Automatically update e-mail addresses based on recipient policy.” Click “OK.”  for the user mailboxes for which you do not want the RUS stamping the proxy address.
0
 
ckeshavCommented:
For editing the Exchange 2003 Recipient Update Policy from Exchange 2010 console you need to first upgrade to 2010

Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients

Open in new window


Note1: You don't need to edit the email address policy for each and every user account to change the primary e-mail address.
Ex: if you have username@mydomain.com and you need to change the primary SMTP address to firstname.lastname@mydomain.com you can change that in the email address policy itself.

Note2: In case you want to have different email address policy for 4 divisions, then you can create email address policies based on Department name or any other attribute specific to that division instead of manually editing on each account. The technet document below should help you understand this concept

http://technet.microsoft.com/en-us/library/bb125137.aspx

0
 
shanemccutchAuthor Commented:
I have thought of unchecking the “Automatically update e-mail addresses based on recipient policy" on the migrated user accounts, my real question is why is the 2010 environment restamping the accounts post migration.  Should I delete the policy while I'm migrating and recreate after?  I'm concerned once I migrate and the policy run's I'll have to fix all the user accounts with either a new policy or manually.  
0
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.

 
ckeshavCommented:
I'm not sure by mistake you have run the policy because I have seen that happens when you just try to view the policy from Exchange Console.
Also the mailboxes which are do not required this policy need to be removed with this setting "Automatically update e-mail addresses based on recipient policy"
I would suggest following my previous comment you first upgrade the policy to 2010 and then make the required changes.

Deleting the default policy is not suggested, you can just disable it, right-click and disable the policy from console.
0
 
shanemccutchAuthor Commented:
Since, I can't really explain why the policy again I'm going to remove the  "Automatically update e-mail addresses based on recipient policy" from the user accounts pre migration.  I'll also upgrade the policy to 2010 prior to migration and spot test with a few users to confirm their addresses do not get updated.

Thanks for your help.
0
 
shanemccutchAuthor Commented:
I see other administrators are experiencing this issue.  It seems like a bug in 2010 to me, why would I want to re-run the policy durin an intra-org migration?  

Here is a Technet forum link:

http://social.technet.microsoft.com/Forums/en-US/exchangesvrmigration/thread/12913ea7-965f-4944-af2d-490779fcfbdb
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now