Despite reaching end of mainstream support back in 2009, there still seems to be a good amount of Exchange 2003 out there. This also means with each Exchange 2003 migration, you’re dealing with as much as 10 years of management and mismanagement of that environment.
One area of potential mismanagement that can quickly become a mess during a migration is in how Exchange 2003 handled Recipient Policies.
Background
Recipient Policies in Exchange 2003 were pretty lightly enforced. In addition to being able to create or modify a Recipient Policy without applying it, you could also modify email addresses for users to make them “non-compliant” with the Recipient Policy that is associated to the user.
As an example, an administrator could open up Active Directory Users & Computers, change a user’s primary email address from Robert.Smith@contoso.com to Bob.Smith@contoso.com and leave the “Automatically update e-mail addresses based on email address policy” box checked. So now you have the email address that is “applied” saying the address should be Robert.Smith but the user’s address is configured as Bob.Smith.
No one would be the wiser until the day came when an admin applied the Recipient Policy and as a result forced the addresses to be “compliant” for a few, few hundred or few thousand users. While the change from Robert.Smith@contoso.com to Bob.Smith@contoso.com may not seem like a catastrophic change, it can become a large concern in a shared environment with multiple SMTP domains where the primary SMTP address could end up changed to another company’s SMTP domain.
Relevance
When Exchange 2007 was released, these “gaps” were closed and the new Email Address Policies were in fact “policy”. The Microsoft Exchange Team warned us of this way back in January 2007 in the blog post “Yes, Exchange 2007 really enforces Email Address Policies“. Where you may have first seen this occur was in moving mailboxes from Exchange 2003 to Exchange 2007 as that move caused the Email Address Policies to be reevaluated and potentially forced a change in emails. The scenario is still relevant in moves from Exchange 2003 to Exchange 2010.
Office 365 adds its own wrinkle to the situation. During an Office 365 hybrid deployment, the Hybrid Configuration Wizard (HCW) updates your Exchange 2003 Recipient Policies and then applies them. So while running the HCW should be a fairly non-intrusive change, the state of your Exchange 2003 environment could create risk of unwanted changes.
Solution
The difficulty is in determining in advance what users might have their addresses changed as a result of being “non-compliant”. This means determining what Recipient Policy / Email Address Policy is associated to the user and evaluating their email addresses for compliance. If you have the single Default Policy, this isn’t too difficult of a task. In a larger environment with multiple policies with multiple filters, a script is needed.
The assigned policy for a mailbox is stored in the “PoliciesIncluded” attribute on the mailbox; the values you find there will be the GUIDs for various policies associated to that mailbox.
First you’ll want to grab the GUIDs for your policies using the following command:
Get-EmailAddressPolicy | FT Name, Guid –AutoSize
As you can see below, I have four different policies in my environment.
Looking at my test mailboxes, you can see compare the GUIDs and see which policy from the above list is associated to each mailbox:
From here, it’s a matter of checking the user’s primary SMTP address against what is specified in the associated policy. Proxy addresses are less relevant as a change in policy will not remove proxy addresses from a user (although the change could add more).
The attached script (Get-NonCompliantAddresses.ps1) attempts to do the following:
- Query the Email Address Policies in the environment
- Query the policy associated to each mailbox in the environment
- Calculate the primary SMTP address defined in the associated policy
- Determine if the primary SMTP address is compliant with the associated policy
- Output a CSV with a list of mailboxes with non-compliant primary SMTP addresses
In the example on the left, the user’s primary SMTP address was set to Joseph.Palarchio@iwitl.com as defined in the “G.S” policy (%g.%s@iwitl.com). The primary SMTP address was later changed in the example on the right to Joe.Palarchio@iwitl.com without unchecking the “Automatically update e-mail addresses based on email address policy” box. The user account is no longer compliant with the email address policy.
 |
 |
Running the script identifies one non-compliant mailbox:
The corresponding CSV output contains the non-compliant mailbox along with the associated details such as primary SMTP address and assigned email address policy:
The script for this post can be found in the Microsoft Script Center at the following link: Get-NonCompliantAddresses.ps1
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
