Why do you need an email address policy for an Office 365 migration?

Email Address Policy Introduction

Migrating to the cloud is now common in most modern enterprise, and many have embarked on the move or are in the process of doing so. Typically, in my experience, the first workload the IT team looks to migrate is email into Exchange Online.

Here are a few reasons why they do this:

1. They’re running a version of Exchange that needs to be upgraded (e.g. 2003, 2007 or 2010)
2. During a Modern Desktop Transformation project
3. They’re running a third-party or hosted mail platform
4. They’re up for license renewal and switched to Office 365 licensing (normally, Microsoft 365 E3)

Regardless of their reasons for migrating, I’ve noticed a few issues in some of my customer’s environments which need to be rectified prior to their Office 365 migration. One of the main misconfigurations I often see in Exchange is the email address policy.

In many cases, I have been surprised by this. You would expect an email address policy would be a priority for large organizations? Especially if they have thousands of users and multiple domain names. However, this isn’t always the case, irrespective of the size of the business or IT team.

Every new starter needs an account with a username and email set up. In many cases, their account might be called one name, and their email address another. For example, username might be ‘akemp’ and email ‘Andrew.Kemp’. Rather than initiating an address policy to assign this automatically, many IT Admins edit the newly created account in the Exchange Admin Centre and disable the option Automatically update email address based on email address policy. Once this has been disabled, the admin will add a new default SMTP address, and will often leave the old addresses in there too.

In this article, I’m going to explore mail address policies and their uses when initiating a migration to the cloud.

What is the email address policy?

So, what is the email address policy? Here’s Microsoft’s definition:

“Email address policies define the rules that create email addresses for recipients in your Exchange organization”

Why use an email address policy?

You may have single or multiple domains in your organization, or your users may need to receive their email to different addresses. Through the introduction of an email address policy, you’re able to control this centrally. I’ll explain the importance of this later in this article.

Behind the scenes, all addresses are stored in the Active Directory in the ProxyAddress attribute. These are defined by:

• SMTP: Andrew.kemp@kempylabs.co.uk
• smtp: andrew@kempylabs.co.uk
• smtp: info@kempylabs.co.uk
• smtp: Andrew@akdemolabs.co.uk

The upper-case SMTP indicates that the address is the primary SMTP, which is the default ‘reply to’ address. The standard formats (Andrew.kemp, Andrew, kempa, akemp etc..) are set by various strings which are set out in the address policy. More details about what formats are used can be found here.

When Exchange installs a Default Policy, it creates an email address with the user’s alias and the active directory domain. For example, my AD is ‘kempylabs.local’, and my username is ‘andrew.kemp’, so my email address would be Andrew.kemp@kempylabs.local.

Even though I have witnessed customers who have added their public domain as an accepted domain in Exchange, they haven’t updated the address policy, meaning that when a new user is created with a mailbox, the primary address is the AD domain. In this case, my email address would be Andrew.kemp@kempylabs.local. This is then manually updated to be andrew.kemp@kempylabs.co.uk for example. Consequently, this email address is left as an alias and the option to use the address policy is unchecked. Overall this doesn’t follow best practice and causes problems later down the line.

The email address policy isn’t just there to make the assignment of addresses to your mailboxes more efficient, but to also prevent duplicate addresses being added. The likelihood of duplicates is higher if carried out through manual methods. A key example of where there is a risk of duplicate addresses being added is the attribute editor. For example, if you have two ‘John.Smith’ accounts, Exchange would create one as ‘John.Smith’ and the other as ‘John.Smith2’, as per the email address policy. If you were to execute this manually, this heightens the risk of adding ‘John.Smith’ to the second account, which could, therefore, incur endless mail flow problems.

Why is the address policy important for Office 365?

In my experience, when asking a customer if they have an email address policy, I often get a response like “I’m moving to the cloud, is the email address policy really a big deal?” The answer is yes, it’s a very big deal when moving to the cloud.

Firstly, if you want to initiate a mailbox move, but you have an address policy assigning a non-routable domain name to a user’s mailbox, this will fail because the domain doesn’t and can’t exist in Office 365.

Secondly, when running the Hybrid Configuration Wizard, the address policies are updated for each user adding an additional email address, for example, something like ‘%m@tenant.mail.onmicrosoft.com’. This is important for mail routing, free or busy lookups, and Autodiscover. Similarly, if this doesn’t exist in the mailbox, then the mailbox move will fail.

Do I create new policies or update the existing one?

If you only operate a single domain name for email, edit the existing one. If you have multiple domain names, you will need to create one for each domain.

Assigning these policies can be done in several ways, however, most companies use OU’s to separate business units or subsidiaries within the overall company. So, the easiest and most straight forward way to apply these is via the OU level.

How do I fix this?

Firstly, you’ll need to edit or create email address policies. Then, add in your domains to the policies and remove any unaccepted domain names. For example, the ‘.local’ domain. If you disable this option in the account settings, it will prevent your users from receiving these. Then, in an ideal world, you would run a script to get all users with the option disabled and then enable it, however, there may be accounts that legitimately need it disabled.

Removing a domain from an email address policy will not remove the domain from the accounts it’s been applied to already. So, if you had the ‘.local’ address assigned to 1000 users, and then removed it from the address policy, it wouldn’t remove it from the users who have it, regardless of having the address policy applied or not. The best way to remove this is through a PowerShell script, or by using a third-party tool like ADModify, if you still have a copy kicking around.

Completed Email Migration

I often hear from my customers who have migrated to Exchange Online, “I’ve completed my migration, so I don’t need the Exchange server anymore and therefore don’t need the email address policies” Whilst technically you don’t, because there are ways to create and update accounts using other means such as Attribute Editor and other-third party tools, you do need to have the policies in order to be supported, this is why Microsoft provides with the Hybrid Server license free of charge.

Exceptions to the rule

Some companies have an automated user creation process, which is where there is an exception to the rule. I have dealt with organizations who use services like Workday, which is the main source of the user’s attributes. Here, the details of the new starter are controlled from the third-party service, these services typically have error checking and validation in to omit the risk of creating duplicate aliases or SMTP addresses. If this is the case, the workflows must be updated to support the move to the cloud.

It’s also imperative to add the Remote Routing Address. However, I stress that you’ll still need the Exchange Server running on-premises, even as the management point, to be supported. If you’re synchronizing your Active Directory to Azure AD using Azure AD Connect, you’ll need the Exchange Server to be supported, even if all your mailboxes have been migrated to Exchange Online.

Conclusion

In this blog, I’ve outlined what an email address policy is, how and where to use it, and also the importance of one during an Office 365 migration. If you’d like further information on this topic, check out this guide ‘How to Migrate Exchange to Office 365: Step by Step’ by Practical 365’s Co-Chief Editor, Steve Goodman.