This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(249.60000000000002, 45%, 34%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ET%3C/text%3E%3C/svg%3E)
We had a single exchange 2016 server. Our internal domain is a .local while email is a .com. We setup internal DNS with .com having the autodiscover and mail DNS. We had no issues, with the user being internal on the office network or external on the internet. We brought up a 2nd exchange server and all seemingly went well. We imported the UCC SSL certificate, applied it to the services and updated all the internal and external URLs to the same as the first server. All URLs are either autodiscover.xxxxxxxxx.com or exch.xxxxxxxxxx.com We updated DNS to use round-robin selection. The issue we have is people on the internal network, when they start Outlook, get a security prompt. The prompt is the server server2.xxxxxxxxx.local has an invalid certificate. If you look at the certificate, it is for the correct exch.xxxxxxxxxx.com I can even see in the Outlook connection status, it is reaching out for the .local server name. But the MAPI URLs are exch.xxxxxxxx.com
If you accept, everything works, if you say no, it eventually fails over to the .com address.
I'm not 100% sure what Mailbox1@Piepel .com is. Mailbox1 is the name of the 1st exchange server's database. mailbox1.edb I tried searching for a mailbox1 account or mailbox but have had no luck. I can send an email to mailbox1@X .com but no idea where it went. Maybe its a public folder, which we have, but the email didn't appear there.
I want to continue with a DAG setup, but this worries me.
More information. I double checked our DNS settings and they appear correct. I can run an NSLookup and get the correct IPs back.
I made a new account and hosted the mailbox on the 2nd exchange server. Everything seems to come up fine. I haven't been able to yet get a certificate error, or come up looking at vpc-swt-exch16. I'll keep trying.
One thing I did notice is that this email profile comes up with 'Public Folders' instead of 'mailbox1'. I used the same computer that gets this error, but logged into Windows with the test account. Could it be email profile, user profile or user registry related?
Can you run the Email Auto Config:
https://support.intermedia.com/app/articles/detail/a_id/10189/type/KB
then look at the XML and see what URLs are being returned by each directory?
Did you ensure the AutoDiscover URI is set correctly and matched Server 1?
Get-ClientAccessService | Format-Table Name, AutoDiscoverServiceInternalUri
It looks to be 100% profile related and has to do with this section of the registry
Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Outlook\Profiles\Outlook
If I replace this section on another computer with the information on the machine having the issue, the issue occurs on the new machine. If I setup a new profile on a different machine and then copy this sections registry to a machine with the issue, problem solved.
So best I can tell it has to do with the Public Folders showing up as mailbox1, the new server, and all existing profiles. I don't know what to look for in this section of the registry as it's all binary. I guess I can try systematically testing by loading the bad profile, deleting a subkey, test and repeat on a non-working config and a working config. Maybe then I can isolate and import it.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(246.4, 22%, 33%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EKY%3C/text%3E%3C/svg%3E)
This registry key Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Outlook\Profiles\Outlook refers to the default Outlook profile.
If you create a new Outlook profile, it would create a separate key.
The path is like Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Outlook\Profiles\<new profile name>.
Thus there is no need to copy this key (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Outlook\Profiles\Outlook) to other machines.
You can simply create a new Outlook profile on the affected machines.
New profiles for everyone isn't a good option for us. We don't have a limit on the Exchange server storage and having Outlook download 50 GB of emails to an ost and then have windows re-index everything for searching would be a rather large impact on users. Especially on remote users where bi-directional access tops out at 40 mbps. On an issue Outlook profile I went digging though the registry and found three keys that have hex values that translate to mailbox1@xxxxxxxxxxxxx .com and vpc-swt-exch16.xxxx.com. I'm going to copy these hex values from a new profile and replace them in a bad profile and see if that resolves the issue.
I copied Outlook profiles, to see if it was an Outlook profile issue, or a Windows Profile issue. By doing that I was able to determine it was an Outlook profile issue.
I was able to fix the issue on one system. Going through the registry at [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\15.0\Outlook\Profiles\Outlook], since we just used the default profile name for all PCs, I found 8 occurrences of a binary value 001f6652 which contains https://vpc-swt-exch16.xxxx.local/mapi/emsmdb/?mailboxId=....... inside the value. Each of these keys also had in the same key, another binary value 001f6653 with https://exch.xxxx.com/mapi/emsmdb/?mailboxId=..... . Simply finding and deleting the binary value with the vpc-swt-exch16 in it subkey where its matching partner exists resolves the issue.
I did check the registry again after launching outlook, and in some sections of the registry, 001f6652 was recreated, but it was done with the correct server name.
I assume the binary values will be different on other machines, but I should be able to identify the hex data to find the pair of entries and make repairs on others with the issue.
FYI, machines with Outlook 2016, 2019 or M365 do not appear to have this issue. Machines with outlook 2013 and a new profile also don't have this issue.
Thanks for the update and sharing on this issue.
Hi @tolcheen
Did this issue occur after you install the second Exchange server?
And do you see Mailbox1@keyman .com appearing in connection status on every affected client?
Since this issue seems to only affect internal users, if they are all domain-joined, you can add the following value to registry on client device and see if it makes any difference:
Path: HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\x.0\Outlook\AutoDiscover
(x.0 in this registry path corresponds to the Outlook version (16.0 = Outlook 2016, 15.0 = Outlook 2013, 14.0 = Outlook 2010, 12.0 = Outlook 2007).)
(If the Autodiscover key doesn't exist, you can manually create it.)
Add a DWORD value named ExcludeScpLookup and set its value to 1.
If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
The issue occurred after we brought online the 2nd Exchange server and the certificate error is always for the 2nd server.
From the XML data, MAILBOX1 is the Public Folders and it appears from the connection status it is ALWAYS mailbox1 that it tries to connect to the 2nd exchange server local name. The second Exchange server does not and has not hosted the public folders or any mailboxes.
Every machine is domain joined. I applied the registry change and I still get the same error. We already have excludeexplicito365endpoint and excludehttpsrootdomain set to 1. Could the latter be the issue?
I'm going to try changing the latter, excludehttpsrootdomain, back to 0 and I'll try separately to make a new mailbox on the 2nd Exchange server to see what happens.
]