Yes, Exchange 2007 really enforces Email Address Policies

Published Jan 05 2007 06:37 PM 22.1K Views

Exchange 2003 background and behavior

In Exchange 2003, Recipient Policies (now Email Address Policies – EAP) were a bit ineffective in some cases. It was quite possible to create a Recipient Policy designed to manage the email addresses stamped onto your mailboxes, specify the "filter" which defined the mailboxes to be included, and then choose not to "apply" this new Recipient Policy.

When creating the Recipient policy in Exchange 2003, you could just dismiss this dialog and ignore it – never evaluating the full impact of the new policy. Newly created mailboxes which match the policy will get the proper email addresses applied, but any existing mailboxes will remain with their old policy (even though they now match the new policy instead).

Figure 1: "Don't forget to manually apply the new policy" dialog box

The standard, expected behavior is that the policy will be explicitly "applied" shortly after it is created. The wiggle room around not forcing it to be immediately applied when it's created is to allow the administrator to "schedule" the application for an opportune time (an evening, a weekend, etc) to ensure minimal disruption to system performance.

If the policy is applied

If the policy is applied (Right click on the policy -> Apply this policy now...), the behavior is that:

  • All recipient objects are reevaluated to see if they match the new policy
  • Any that do match have their policy membership updated (msExchPoliciesIncluded) to the new policy – remember that a recipient can only be a member of one recipient policy at a time, so becoming part of this new policy means the recipient is necessarily leaving their old policy.
  • No proxy addresses are removed from the recipient, but if the new policy defines a new primary email address (reply address), then the old primary address is demoted to a secondary email address so that the new primary can be set.

Yes, you did read that correctly. The primary email address for these affected users will quite likely be updated/changed, since one of the key reasons for a separate Recipient Policy is to define a different primary (reply) address.

So far, so good. If you apply a new policy that defines a different primary proxy address format, it stands to reason that the users to whom the policy applies will end up with a different primary proxy address.

If the policy is NOT applied

So what happens if you DON'T ever apply the policy? Well, as I alluded before, the recipients who are newly created after the new policy is in effect will all get the address templates of the new recipient policy. And recipients who existed before the new policy will not ever be reevaluated for the new address templates and will retain their original email addresses unchanged.

Whoops. Now you've got a recipient policy defined – a POLICY – that is not explicitly enforced. That's bad, and bypasses the point of having a policy. Might as well just call it a Recipient Suggestion instead!

Further, you now have the looming problem that every day that goes by without applying the new recipient policy means you're another day further along on borrowed time. Sooner or later, someone will probably apply the policy. Following a PSS KB article, or a blog post they've read to solve some other problem related to the RUS, etc. This inevitably happens when you least expect it – while you're on vacation, over the holidays, or 2:30am on a Monday morning.

And then, what's the result? Without warning all of the email addresses for these users under the new (now probably not so "new") recipient policy are updated to match the policy template. Reply addresses are changed, former primary addresses are demoted to secondaries, end-users are confused, etc. As mentioned above, this would happen only on users that were created before the new (now probably not so "new") policy was created and never applied.

Of course, since you defined the recipient policy filter and address templates, none of this should come as a surprise. But it always does – and it's worse the longer it's been since the policy was created, since the surprise of having these addresses changed will only bigger the longer it's been since you made the recipient policy change!

The Exchange 2007 behavior

Ok, enough background. Why this particular blog post? Well, in Exchange 2007 we've finally closed this loophole and made the Email Address Policy (EAP ) work like an actual policy.

Any time you create a new EAP in Exchange 2007 you're given much less wiggle room to get out of applying it (either immediately or as a scheduled action). Any time you write a recipient object in Exchange 2007 (from the GUI console or the PowerShell), the policy membership is synchronously evaluated and reapplied if necessary.

The net effect – Exchange 2007 actions on recipients will make sure that any lagging Exchange 2003 Recipient Policies that have not yet been applied, *WILL* be applied to those recipients.

One area where this may cause some initial confusion is Exchange 2007 mailbox move. Since you need to move the mailboxes to Exchange 2007 mailbox servers using the Exchange 2003 console or PowerShell, this counts as an "Exchange 2007 action"... and will ensure that the correct policies are applied to this mailbox.

This means that if you have a bunch of "unapplied policy" mailboxes on an Exchange 2003 server and you bulk-move them to Exchange 2007 mailbox server, quite possibly you will find that as part of the mailbox move process they all have been configured with new email proxy addresses, perhaps even a different primary SMTP address (all depending on what the new policy defines)! As explained above, this is expected behavior and is by design.

That said, it may also be unexpected and undesirable. Perhaps you really DO want to exclude these mailboxes from all automatic email address policy management, or perhaps you just need to get the mailboxes moved without changing their email address and will eventually fine tune the recipient policy to exclude these particular users. There are a number of reasons why you might want to ensure you can move these mailboxes without applying the new policy as part of the process.

The easiest workaround is to ensure before the mailbox move that you have excluded these mailboxes from "Automatic Update" of their recipient policy information. This can be done fairly easily in Exchange 2003 ADUC (since you've not moved the mailbox to Exchange 2007 yet) or using Exchange 2007 at either the GUI console or with the Windows PowerShell:

Figure 2: Unchecking "Automatically Update" in the GUI console.

PowerShell One-Liner examples:

Get-Mailbox < mailbox ID> | Set-Mailbox –EmailAddressPolicyEnabled:$false

Get-Mailbox –Server SRV1 | Set-Mailbox –EmailAddressPolicyEnabled:$false

Be sure that once you've corrected the email address policy filter or templates, you don't forget to re-enable the policy for these recipients or you will lose out on benefits of managing email addresses through email address policy benefits for the recipient in the future.

- Evan Dodds

Not applicable
Sorry, this comment has nothing to do with the topic above, but maybe you could address it in a formal post.

As an admin for a small-mid-sized-and-growing business on a budget, one thing I really liked with Exchange 2003 is that a license to Outlook 2003 came with every CAL.

This link concerns me.

It seems that purchasing CALs for Exchange 2007 will get you nothing in the way of software to actually *use* the CALs.  Outlook 2007 will have to be purchased for each user, unless my company is enrolled in Software Assurance (which is not cost effective for us).

I find Microsoft licensing very confusing above the simple outright purchase level, so I'd appreciate any light you could shine here, including comments on how licensing upgrades from Exchange 2003 CALs are affected.

Thanks for any info.
Not applicable
I hated the policy in 2003. In a very large organization I don't want the policy to go out and change all the email addresses. Our policy is Since I'm going to have more than one, we would have a, etc. Applying the policy changed them to, etc. What a pain...

I don't want you to EVER touch the email addresses that I've put in.
Not applicable
Totally agree with you Jim. You don't have to be in a very large organization, with a few hundreds accounts that situation is common. Thinking that migration will mess with email addresses gives me a headache.
Not applicable
Slightly off topic, but I had created alternate smtp addresses of the type postmaster@[] where my exact email server IP was in the brackets.  I noticed when I migrated a mailbox over the Exchange 2007 that Exchange 2007 didn't care for this.  Is this a change?
Not applicable

Can you explain a bit more as to what exactly happens? Do you get errors, where and when?
Not applicable
Good information to know, my question as the other response hinted at is when Ex07 joins a large Ex03 ORG when , who will be affected by this change in functionality?  We've informed the AD team of this feature but we may need to audit AD to understand the mailbox accounts who have changed their stamped email address but haven't removed that account from Policy control.
Not applicable

Any change that you make from Exchange 2007 on a recipient that is on E2003 will trigger this. Move mailbox - obviously. But also opening up mailbox properties through Exchange 2007 console and changing something from there; running set-mailbox CMDlet on a E2003 mailbox would do this.
Not applicable
With this new "synchronous" policy behaviour, it's not clear to which recipients a policy apply, due to order and priority.
If we have more than one policy that match the same user(s), usually the stamped addresses (for example for a newly created user) will be those from the FIRST policy (in priority) to which the user match.
BUT if, after a while, we modify a lower priority policy, also matching that user, the user will be stamped with lower priority adresses due to synchronous reapplication? In other terms, what is the criteria to select existing users matching a policy when a policy changes and it's reapplied?
Not applicable
Not applicable
To be more clear:
Suppose that a recipient (es: UserX) match more than one policy (es: policyA, policyB, policyC), and these policies are in the list in this exact order (policyA the higher priority, policyC the lowest).
I expect that UserX always gets its addresses based only on policyA (top priority).
But what's happen when an Exchange admin modify policyB or policyC? Are the addresses stamped on a recipient in some way dependent of policy modifying time or order? I didn't find any clear statement in docs, so I want to be sure that policy application is consistent over time.
Someone could make me sure of that?

Other question:
What does it mean the presence of the column "Applied" in the EAP List? I always applied the policy in Immediate mode but now I see a "False" in that value for two policies (True for the others)???!?!?!?
Not applicable
Alessandro - the policy which will apply to a given recipient is exactly as it was in Exchange 2003 -- the highest priority matching policy will always apply. What's different in Exchange 2007 is that now the recipient is ALWAYS evaluated for its policy, not just upon request. So, while Exchange 2003 would allow a recipient to remain stamped with out-of-policy values when a new policy (or higher priority policy) should be applied, this won't happen in Exchange 2007.
Not applicable
Evan, if you test your last sentence towards exchange 2007 you will discover that it isn't true. The (only?) action that the new (higher) policy, now matching the recipient, guarantee is the stamping of new addresses and the changing of primary address. But ALL previously stamped address (from older policy now out-of-scope) REMAIN stamped to the recipient.
So, for example, in a multi-internet-domain environment like a multi-company group, when a user switch from a company to another (or from a division to another) having different internet domains, he/she maintains old company addresses (stamped by old policy), making the whole organization an "addresses chaos" in a few policy-changes.

The current policy behaviour results unmanageable other than in very simple cases. The stamped addresses are actually unpredictable, due to policy in/out of scope.

In my opinion there are two possible solutions:
1) you move out-of-policy checkbox to address-level granularity, introducing some sort of "added" or "special addresses" to a recipient which they remain unchanged when the recipient changes the matching policy
2) you make more rigorous the application of a policy: if a recipient stay controlled by policies (with the checkbox), it always get exactly the addresses from the higher policy it matches (in other words, you clear and then re-generate all stamped address).
Not applicable
Alessandro - the email address policies in E2k7 (like recipient policies in E2k3) chiefly control the primary proxy addresses. Although you can stamp secondary addresses with the RUS, there can be many of these and the RUS will ignore the extras. You can always add/remove secondary addresses without any effect on the policy or the primaries. When you switch from one policy to another policy, the former primaries are retained as seconday addresses to allow mailflow to continue interrupted to these previously existing addresses. This is intentional and by design. The primary effect of the email address policy change would be to change the "reply-to" address exhibited by the mailbox user, not to remove custom or legacy secondary proxies.

If your goal is to completely flush all non-policy proxy addresses from the mailbox, you will want to script this removal-of-secondary-proxies action as part of the cut-over from one policy to the other. The good news is that in Exchange 2007, the new email address policy will be properly applied (for primary proxies) immediately after making any writes to the mailbox user using the Exchange 2007 tools.
Not applicable
Thanks for your quick response. I like e2k7 approach of immediately stamping proxies. EAP environment is even better for explicit declaration of auth/non-auth domains, no more hidden in recipient policies. But sure I think it's complex to control in environment other than basic. Moreover I (we) will have to re-think administration via powershell to fit our needs, even for basic things like designing addresses templates. Custom filtering by country, office, upn suffix, ..., alias address generation %1g.%s, ...all things we can't do any more in GUI...quite frustrating indeed :(
Not applicable
I have previously listed the progress we've been making in posting ITPro focused Systems Management blog
Not applicable
Also a little off topic, but slightly related to recipient policies nonetheless. In Exchange 2003 you could set, on an SMTP address in a recipient policy, that you wanted Exchange to be responsible for all mail delivered to this domain. If you wanted to share a domain with another mail system you removed this checkbox and could configure Exchange to forward mail with an unresolved recipient to another server. How can you mirror this functionality in Exchange 2007?
Not applicable
Great post Evan however one problem I have noticed is that when disabling the Automatic update for a user not only do the address policies not get applied but Exchange no longer updates AD with the manually entered primary address. This is really bad for applications that rely on the AD email entry to determine addresses. Is this by design and can it be changed? Also it would be great if you could configure an alternate email address policy to use in the event of duplicate addresses, rather than the default of just adding a number (which some people seem to really dislike!)  
Not applicable
For those interested in email address policies based on AD Group membership, its not possible in Exchange 2007 yet.  This is a huge disappointment for me.  But even Microsoft Support could not get it to work and finally just said it wasn't supported and to come up with an alternative solution.  Oh well.  <shrug>
Not applicable

Please see the following:

What you are looking for is called "MemberOfGroup".
Not applicable
I had actually used Evan Dodds' article on MemberOfGroup to create my email address policies, and called Microsoft Support when they weren't working.  

I just noticed that Evan posted a reply to my comment on his blog.  He states that this is a bug and will be fixed in SP1.  Thats great news!
Version history
Last update:
‎Jan 05 2007 06:37 PM
Updated by: