Should userPrincipalName in Active Directory match external email domain or the internal AD domain

I've got an active directory domain (2008 level) which predates our email moving to Exchange, so the domain names are different. The AD one is a ".local" created in the days before the best practice was to match external domain names. This means that email addresses (using our external domain) differ from internal identifiers. We now have an on-premise Exchange 2016 server. I've implemented autodiscover which was fine before Outlook 2016 came along as we could always specify the domain name in setting up. Now with Outlook 2016 the option to set this are so hard to discover that I decided to find out why I couldn't login to Outlook with just the external facing email address. It seems to work with setting up Outlook inside the domain, but I've got some external email users who don't have this option.

After much investigation, I found that the AD field userPrincipalName is set to user@internal.local instead of user@external.com and that this governs whether you can login with the external email address on OWA. Here's the link that gave me the clue: https://social.technet.microsoft.com/Forums/en-US/15eef306-69b5-4008-904e-50e0116c223f/setup-outlook-anywhere-to-not-ask-for-domainusername-just-email-address-only?forum=exchange2010

So if I reset the field in the user's record in AD to the external email domain, I can then login with just the email address, and set up new Outlook 2016 profiles again with just the email address. So far this seems to work.

The question is whether this is good practice, or whether I should change my AD to use the external domain name, or some combination perhaps involving having both internal and external domains defined. Are there any gotchas if I simply change the userPrincipalName to match the email address in all cases?

I'm intending to migrate some of our mailboxes to Office 365 in the next month or two, so it would be good if there's a best practice to make this migration easier.
Ian GoodingTechnical Services ManagerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

timgreen7077Exchange EngineerCommented:
No the the UPN doesn't need to match the external email address domain. They can be completely different, but it does make it easier to deal with at times. Also if you plan on setting up a hybrid environment in order to migrate to o365, you will need to remove the .local from the proxy email addresses on the user mailboxes. O365 doesn't allow the .local suffix. You don't have to remove .local from your domain but it can't be a proxy address on the mailbox.
0
timgreen7077Exchange EngineerCommented:
The question is whether this is good practice, or whether I should change my AD to use the external domain name, or some combination perhaps involving having both internal and external domains defined. Are there any gotchas if I simply change the userPrincipalName to match the email address in all cases?

There are no gotchas if you change the UPN to match the external email address suffix. They will then be able to login with that email address which is basically the new UPN. That will work just fine. The only gotcha I can think of is, if there is an internal application created in house or any apps that look at the old UPN specifically that could cause potential issues, but if that is not the case then you will be fine to change the UPN suffix to match the email domain. Also there is no need to remove .local from your AD domain, but when offloading to O365 the .local suffix can't be a proxy address on the mailboxes being moved to O365.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Ian GoodingTechnical Services ManagerAuthor Commented:
Thanks, that's just what I needed to give me confidence. I'm trying it out with a few users and will then build a script to update everyone else.
0
timgreen7077Exchange EngineerCommented:
I would always use test accounts first before making any changes to production users, but you should be good.
0
Ian GoodingTechnical Services ManagerAuthor Commented:
So would I! I tried it first with a test account, which connects fine with OWA and mobile Outlook, so have changed my own AD profile. As I'm probably the most complex user setup this ought to reveal any hidden side effects...
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.