In this post, I’ll be going over how to add additional and/or alternative UPN suffixes to your Active Directory. I’ll also be going over why you may require this inside of your environment.
This is also a follow up post to the article here: https://www.stephenwagner.com/2016/09/23/outlook-2016-exchange-2013-password-prompts-upn-and-samaccountname-troubles/ as Microsoft has deleted the KB 243629 article which contained the original instructions.
Why
There is a number of reasons why you may want to do this:
- You’re migrating to a newer version of Microsoft Outlook 2016, and require the users UPN to match the users e-mail address for auto-configure to function.
- Your internal domain is is a “domain.local” domain, however you want users to log in with a “domain.com” domain.
- You are implementing a line of business application or other piece of software that requires user’s UPNs to match their e-mail addresses.
- You’re performing a migration.
How
Let’s get to it! Here’s how to add an alternative UPN suffix to an Active Directory domain:
- Log on to your domain controller.
- Open “Active Directory Domains and Trusts”
- On the left hand side of the new window, right click on “Active Directory Domains and Trusts”, and select “Properties” (as shown below).
Active Directory Domains and Trusts Window
- Type in your new domain suffix in to the “Alternative UPN suffixes” box, and then click “Add”. As shown below.
Add Alternative UPN suffix
- Click “Apply” and then close out of the windows.
The new UPN suffix should be available via “Active Directory Users and Computers” and you should be able to set it to users.
You can also configure the user accounts via the Exchange Administration Center (EAC). See below for an example:
Exchange Administration Center UPN Suffix
[…] First we have to add the UPN suffix (which is the actual e-mail address domain name) to the Active Directory Domain and Trusts. Instructions are available here: https://support.microsoft.com/en-us/kb/243629 (please note Microsoft has since deleted the original knowledge base article) https://www.stephenwagner.com/2018/10/16/how-to-add-an-alternative-upn-suffix-to-an-active-directory…. […]
Hi Stephen,
Thanks a lot for so prompt update!
The guide itself is great but appears that there are few more steps to do because when provided login [email protected] – certificate error began to appear “The name on security cerificate is invalid..” It was still trying to connect to mydomain.local
The solution was to change Server -> Outlook Anywhere settings from mydomain.local to mycompany.com
But now pop-up for my delegated mailboxes started to came out – I can see name of the delegated mailbox on the password pop-up. It is not asking about password for the main account anymore.
Authetication is set to NTLM, SSL offloading unticked, and my FQDN domain set internally and externally as stated before.
Do you have any idea what can it be?
Many thanks,
Daniel
Hi Daniel,
It sounds like you might have a few issues going on (in addition to what’s discussed in the two blog posts).
First, let’s get in to the UPN change. I’m assuming you’ve done it for one user, you should do this for all users to prep for the migration to Outlook 2016. If you mailbox has access to others, you should have the UPN changed on those as well. Additionally, you may have to remove and re-add them to Outlook.
As for your comment regarding the hostname for Outlook Anywhere. I would highly recommend configuring a single DNS namespace for your Exchange configuration. I would also recommend that you use an external domain name, that is resolving properly both externally and internally.
You can have split DNS configured, and have different DNS namespaces on the internal and external, but I find this is harder to manage, and can cause more issues (like the one you experienced with Outlook Anywhere).
I think your next step would be to consider the above (regarding a single DNS namespace), and also verify that all your virtual directory URLs (internal hostname, and external hostname) are correct.
Even if you’re still using .local for the AD domain, you should try to have Exchange using the external .com domain for everything mail related.
I hope I explained this clearly (it’s a lot to take in).
Cheers,
Stephen
Hi Stephen,
Strange Microsoft removed the KB article.
I wanted to understand why Microsoft remvoed it and then i found a related Microsoft doc. Same solution with Microsofts new cloud focus in mind: prepare AD for an Azure Ad synchronisation to setup Office 365
https://docs.microsoft.com/en-us/office365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization
Thanks for bringing this to my attention!
I’ve been noticing in the last 3 or 4 years that Microsoft has been killing tons of KBs and other documents that are essential for IT professionals like us…
I believe it’s in an effort to force migration to their cloud products, which is really upsetting.
There’s those of us that see the value of owning equipment, keeping data on-prem and protected, as well as the cost savings of an on-prem IT strategy VS cloud (in most common scenarios for the SMB market).
It’s truly a shame…
I think it would be great if you addressed a situation if your on-prem domain does not match your azure verified domain.
Example: My domain is company.local. My public domain (and email domain used in O365 and thus Azure AD) is mycompanyinc.com. Doesn’t seem like this could be addressed by simply creating a suffix.
Hello, I was wondering if just adding the additional UPN suffix has any affect on the current users and computers, I have a situation where we are attempting to access a share on a domain computer using and alternate name with a diffrent domain name from the one in our active directory and we are getting access denied. As this is a production environment I don’t want to cause any issues when adding the alternate UPN.
Hi Douglas,
Adding the UPN suffix should have no change or effect if you haven’t changed it on user accounts afterwards.
However, I’m not sure I’m following exactly what you’re trying to do. Do you have two separate domains in a single AD forest, or what’s going on exactly?
Stephen
No we don’t have two domains, but we want to connect to a share on a server using a different name and domain name or Cname. We are able to connect fine using an alternate server name with the native domain name, example:
actual server name fileserver01
Alternate server name fileserver11
Native domain name domain-name.pri
Alternate domain name domain.st.gov
Added the alternate server name in dns, in the forward lookup zone domain.st.gov
Also added alternate server name in native domain forward lookup zone.
Able to connect to share on server using fileserver11.domain-name.pri, no credentials pop up, share displays fine.
When connection using alternate name with alternate domain name fileserver11.domain.st.gov I get a credential pop up and access denied.
So just to confirm, you have two separate non-connected domain names? And you’re trying to use a computer on domain 1, to connect to a file share on domain 2 that it’s not connected to?
If this is the case, you ABSOLUTELY DO NOT want to add an alternative UPN… This is not supported, and could potentially break things, cause issues with DNS, etc… It’ll also probably cause issues with logins (as the systems might attempt to login to one domain, when they should be using the other).
If this is the setup you have, you should log in to the share’s on the foreign domain using the proper format. Example: Use format “[email protected]”, or “DOMAIN\UserName”.
No, the server is joined to the native domain, we are logging on using domain account but we want to use a cname or alternate name with different domain name to connect to a share on that server. The alternate domain doe snot exist in the environment as an active directory domain, we just want to use the alternate domain name in the host name, we own the alternate domain name so we are not going to conflict with another AD, we are just wanting to connect to a share on a domain joined server useing cname or alternate name is all.
I see! Thanks for explaining!
You’re going to need to incorporate future planning. But, if you technically want simple/quick forget about the alternative UPN suffix as these are used for User Principal Names for user accounts. Just create a new domain on your internal DNS server, and add a host or a cname entry…
If you do ever light up a new domain (either under the same forest, or a new forest), you’ll need to delete this domain beforehand and undo everything you did.
That is already done, we have the alternate domain name in our DNS as a forward lookup zone and the host name records exist in both native and alternate domain name zones, still get access denied when trying to connect to share using alternate host and domain name.
I just have concerns with creating the DNS entries, as well as adding an additional UPN suffix…
Technically if the DNS domain exists, or records exist, AD will query the domain for Auth and domain info, technically possibly ignoring the additional UPN because they are conflicting (or vice versa).
Technically if you want logins and computers in a different domain, I’m assuming the best practice would be to create another domain in the forest.
Thanks, that is very helpful
HI. Have a question regarding how Exchange and S4B handles the UPN suffixes. Have trouble with some meetingrooms where we are using SRS. We have established three UPN’s, but when users from two of the UPN’s are trying to add a skype meeting from their clients on the rooms we do not see the meeting as a skype meeting, just a ordinary meeting. Between ordinary clients in all UPN’s it works ok. So i wonder what can cause this. It seems to me it is either Exchange or a S4B problem. Any tips where to look
Hi,
Is adding UPN Suffixes require another Micorsoft License?
[…] to comply with the customer procedures. This is for example the case when you need to add a custom user Principal Name (uPN) suffix to a user. Normally you would add the suffix on domain level in Active Directory Domains and […]
Alternative upn Suffix user cannot connect trough outlook. Any one with same problem?
I get error: there is something wrong….
Hi Dogan,
Using the alternative UPN is usually designed to correct login problems with Outlook. The only time it would actually cause a problem is if it’s misconfigured, your autodiscover is misconfigured, DNS is misconfigured, or the alternative UPN suffix is misconfigured.
I’d recommend rechecking your configuration and try again.
Cheers,
Stephen
HI Stephen,
Just wondering about UPN have a customer that has a .local for years and had pop3 for their .org emails for years and is moving the .org to their exchange server. So from an order of operation you it be best to add the UPN , change the accepting domain , then edge sync subscription. Is there anything here I am missing. really having trouble on finding information on doing this.
Hi Keith,
That is correct, except I’m not sure what you mean by your third step.
You don’t need to do it in any particular order, but you just need to add the accepting domain to Exchange, configure a UPN on your AD, and then change the users UPNs to match their e-mail address (and also make sure the exchange e-mail matches).
Cheers,
Stephen
Hi Stephan,
I’ve been googeling for 2 days now because of an issue with profile creation on first run with Outlook 2016. It’s driving me crazy !
I think your solution could fix my issue but I’m not sure, so I would like to ask for your opinion first if you don’t mind.
Here is our configuration/infrastructure :
Exchange 2013 server.
Our users are on the MS AD domain domain1.something.com.
Our users UPNs do not match the email address ([email protected]).
Here is our issue :
With Outlook 2010/2013, first time run goes well until the end, without any user action but cliking next next…
With Outlook 2016, on first run, the mailbow is found, but on the second step, password is required. The logon displayed is [email protected]. When we enter the user password it does not work. When we choose another authentification method and enter credentials as domain1\user + user password, it works.
So, I guess it relates to the UPN missmatch and will be solved by adding UPN suffix domain1.something.com on the AD configuration.
Do you agree ?
Cheers
Philippe
Hi Philippe,
I believe that this will correct your issue. Auto-discover functions differently in Outlook 2016 and later and you should have your UPN matching your e-mail address for it to work.
There’s a small chance it could be something else, but I feel that it is the UPNs that are causing the issue in your environment.
Hope that helps!
Cheers,
Stephen
Recently converted our organization to Azure AD. Then the boss desired additional offices, and decided to remove our city from the domain name…but wanted to keep the old email address for those users that had it, so if a client decided to email to the old account, it would go thru. 2 years later, we now migrated to On Prem AD, with Azure AD (hybrid), so we could add DFS and create a forest for server mirroring. Well, then we decided it was too much to keep up with AD and AAD, so we added Azure connect. Then all the old emails stopped working. Took a day to figure it out, but then the users were livid.
Looked around to no avail. Then lo and behold…the answer.
For an alias you should be able to just add the secondary account in AD – via AD Users and Computers. Right click on an OU and make sure Advanced Features (under View) is selected. Double click on the User and go to the Attribute Editor tab and scroll down to proxy address. The main email address should be added as SMTP: [email protected] and any additional as smtp: [email protected].
And we back!
Thank you for this. After recently upgrading to exchange 2019 from SBS 2011 (had to migrate to 2016 first of course) I was having odd authentication issues. Everything was mostly working, but not 100%
Going through 2 versions of SBS of course everything was set to .local domains. I didn’t like it back then, but like you said that was the suggested way to do things.
Hi Chris,
Glad to hear the post helped!
Cheers,
Stephen
Will this make any impact on DFS access ?? as we are transitioning from .local to .com !
This doesn’t actually change your domain, it just provides you with an alternative UPN that you can use to log on to Active Directory. It should not have an impact on DFS.