Why you need to fix mis-matched UPNs and SMTP addresses before you migrate to Office 365

So what’s the problem?

When you log on to Office 365 you’re functioning in the ‘big wide world’, and Microsoft wants to know who you are.

This means that logon IDs have to include an externally valid domain (the one you have registered and verified within Office 365) along with a unique username within that domain.

By default, Office 365 uses what’s called the User Principal Name (aka the UPN) to achieve this.

A UPN is constructed very much like a user’s email SMTP address, taking the format:

username@domain

If you take a look at your current on-premises UPN (labelled as the ‘User logon name:’ in the Active Directory Properties View) you’ll see it comprises:

• a username,which could take a number of forms.  For example:
  • John.Smith OR
  • SaraA (this being a format typical of the older pre-Windows 2000 DomainUsername authentication aka samAccountName)
• a UPN ‘suffix’ (i.e. domain) which in this case, is set to HQ.domain.com

So the first thing you need to do when you migrate to Office 365 is to check that you have a UPN suffix that matches in with the external domain you’ll be using for Office 365.  Any internal routing names such as HQ and ‘local’ mean nothing to Office 365.

In this example, HQ.domain.com would become domain.com – something that would be easy to fix with the Active Directory module in PowerShell.

What about what’s to the left of the @ sign?  

As you can see from the examples, you may have a mix of different username formats.  This can depend on when the users were added and the conventions of the current administrator.  You might also synchronise usernames and other attributes in from another application, such as an HR system.

The fact is, any of these username formats are valid as part of a UPN as long as:

1. they don’t contain invalid characters
2. they are unique
3. users know what their UPN is

In our example, Sara would logon as SaraA@domain.com and John would logon as John.Smith@domain.com(which just so happens to be his email address).

But herein lies the problem.  Because the Office 365 UPN is formatted like an email address, and for some, but not all your users, it may actually be their email address, confusion reigns supreme. 

This confusion is compounded by the fact that, for example, the Activation window for Office Pro Plus prompts the user to enter their email address.  Likewise the iOS versions of Office and OneDrive prompt for email address.  In these examples Microsoft and Apple really mean ‘UPN’ and not ’email address’.

The upshot of all of this is that, although your UPN and SMTP email address aren’t necessarily one and the same, when you migrate to Office 365 you are best advised to make UPNs match users’ SMTP addresses.

That way, you’ll save a heck of a lot of support calls.

HOW TO FIX STICKY BIT 1:  Make UPN=SMTP

The tricky element is identifying non-matching UPNs and SMTPs and with organisations expanding every day, the number of occurrences can continue to increase.

There’s some useful articles by Joe Palarchio and Steve Goodman that explain more on this subject.

One final note:  Although it is also possible to set up what’s called an Alternate Login ID to cover for the fact that users will get confused, or that you may have an umbrella Office 365 domain for multiple subsidiaries with different email addresses, or you have legacy applications that mean you cannot change the UPN, there are caveats to using this feature – especially if you have a hybrid environment.