One item you’ve probably learned by now if you’re an Exchange admin working on a 2007 deployment is that Microsoft has changed the behavior of the recipient update policy. Most of you won’t care about this and that’s just fine. You shouldn’t. I would dare say that if your Exchange environment is engineered well and planned out the way Microsoft probably expects it to be, you should have almost no issues whatsoever.
Consider, however, if you’ve deployed Exchange with some type of “non-standard” approach. Yes, please picture air quotes around that. We’re trying to be politically correct here. What if your Exchange deployment wasn’t, for instance, master of all mail within your TLD?
Let’s say you have a TLD of contoso.com. Now let’s say you set up an Exchange service forest called services.contoso.com (see my earlier post about why an Exchange service forest is a Bad Idea). Now let’s say that because there are many other businesses and entities within contoso.com that route their own mail, the decision is made that Exchange cannot be authoritative for all mail coming in to contoso.com. You need to forward it up to some traffic directors at the top level to determine where the traffic goes. Now you have Exchange installed in a service forest and you’re not authoritative for contoso.com. So let’s say you decide to become authoritative for mail.contoso.com.
Now your recipient policy probably says that when new users are created, give them a service.contoso.com and a mail.contoso.com SMTP address. What about the contoso.com address? Well, since you’re handling that elsewhere, a third party process has to come in and manually assign that address. Fine.
Now in 2003, once the user object is created and the addresses are stamped, RUS will never touch the object again and muck with it unless you forcibly tell it to do so. Believe me though, it’s rare in this setup that you’ll be running this manually.
When you begin to roll out Exchange 2007, you get a new issue. If you’re configured in this manner and make any changes to the user object… say… moving a mailbox or anything of that nature… then you’ll notice that RUS will take your user object and mangle it up according to what it thinks the SMTP addresses should be. It’ll reset the primary address. Fun. Now your users start to complain that their mailing list memberships are failing, their business cards are incorrect, yadda yadda. Yes, the behavior of RUS changed in 2007 from 2003. Take note of it, because if you’re set up in a wonky way that prevents you from being authoritative in your domain, this is going to bite you once for every user you have.