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(57.599999999999994, 43%, 15%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EAD%3C/text%3E%3C/svg%3E)
Previously, Outlook for Windows clients (M365) worked fine. Exchange mailboxes were set up while srv.company.local was resolvable (either on LAN or connected via VPN). The only nagging issue is that every time Outlook starts, one or two certificate errors came up because the trusted 3rd-party cert (mail.company.com) didn't match the (presumed) server name under which the Outlook account was set up (srv.company.local). The users could bypass the warning (i.e. proceed anyways) and Outlook worked as expected.
After configuring Extended Protection by running the script (ExchangeExtendedProtectionManagement.ps1), Outlook for Windows clients can no longer connect. They get a message:
“There is a problem with the proxy server’s security certificate. The name on the security certificate is invalid or does not match the name of the target site srv.company.local. Outlook is unable to connect to the proxy server. (Error code 10)”
Users can no longer bypass this error message and they can't connect.
While installing EP I had to deal with some prerequisite failures:
After that the EP update script passed prerequisites and reported a successful installation. Outlook for Windows can't connect, Outlook for Mac works fine, most smartphones work fine.
I rolled back the EP update by running ExchangeExtendedProtectionManagement.ps1 -RollbackType "RestoreIISAppConfig" and restarting the server, but Outlook for Windows still can't connect.
I think what might be happening:
Outlook for Windows apparently uses AutoDiscover (and RPC over HTTP). The online connectivity tester https://testconnectivity.microsoft.com/ shows that the AutoDiscover URL is properly found, and it shows the AutoDiscover.xml result that's being returned. The XML has the string "srv.company.local" in 5 places. My guess is the most important location for this discussion is:
X-CalculatedBETarget: srv.company.local
I think what I ultimately want to do is somehow get the XML to return "mail.company.com" at least for X-CalculatedBETarget, and anywhere else it makes sense.
I recognize this may not help with existing Outlook profiles that were originally created pointing to srv.company.local but it's not the end of the world if users need to delete their profiles and re-establish them. My thinking is this would get mail.company.com from AutoDiscover, and when connecting the server certs would work for that server name and the Outlook errors would no longer happen.
As a fallback I might experiment with the SSL offloading, setting external and internal clients to $false which might allow Outlook for Windows users to bypass the warnings as they did previously.
Thanks very much to everyone who made it through all of this, and thanks in advance for insights anyone may have.
![](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(25.6, 67%, 12%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJS%3C/text%3E%3C/svg%3E)
Hi @Al Doman
Looks like the issue is caused by your DNS configuration, you could refer to the DNS related steps introduced in this guide: Exchange Autodiscover – A Guide to Making Exchange Work Properly
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
It's not suggested use server.domain.local as internal DNS name, since we could not add xxx.local SAN in the 3rd party certificate, then it will cause the authentication issue.
Thanks for looking at this, and your reply. The first link is a useful resource. It should be noted that some of the virtual directory settings can be made in ECP; some users may prefer this.
Going through that link, my existing (split) DNS configuration was already exactly correct.
I agree, in a perfect world the server would not have been configured in 2015 with company.local, but we have to live with it.
The Outlook for Windows error seems to describe the issue. When the Outlook profile was created, it used AutoDiscover and was provided the server name srv.company.local. This was (and remains) resolvable so the account was added, albeit with security warnings during initial setup and every time Outlook started ever since.
Basically, Outlook goes to the Exchange server srv.company.local and looks for a cert, but the only trusted 3rd-party cert is for mail.company.com. If an Outlook profile could be made to go to mail.company.com there should be no cert issue and everything should "just work".
Fundamentally I'd like to know more about AutoDiscover.xml: how its entries are determined, and how to change/update them. Knowing very little about it I suspect the X-CalculatedBETarget: entry needs to be changed from srv.company.local to mail.company.com but I don't know how to achieve that.
Update: there's an interesting article at https://acbrownit.com/2014/04/04/exchange-autodiscover-episode-2-attack-of-the-exchange-server/ about modifying and Exchange AD SCP. Not sure if it applies in my scenario but it may be worth a test.
Hi,
What's your current SCP configuration?
Get-ClientAccessService | fl
You could use the command below to modify it:
Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri "https://servername.domain.com/Autodiscover/Autodiscover.xml"
For lurkers, the EMS cmdlet is "Get-ClientAccessServer", not "Get-ClientAccessService".
Selected results of Get-ClientAccessServer | fl:
Name: SRV
Fqdn: SRV.company.local
AutoDiscoverServiceCN: SRV
Identity: SRV
ObjectCategory: company.local/Configuration/Schema/ms-Exch-Exchange-Server
ID: SRV
OriginatingServer: SRV.company.local
I wonder which one(s) need to be updated to make Autodiscover.xml return the value I need (mail.company.com) rather than SRV.company.local.
When I next have a maintenance window I'll experiment with ADSS and/or Set-ClientAccessServer.
For lurkers: it's important to distinguish between Outlook for Windows clients being able to find/reach AutoDiscover, and the contents of the Autodiscover.xml file that gets returned.
In my environment, resolving and reaching AutoDiscover has not been an issue. The issue has been finding out how to update the returned Autodiscover.xml.
Hi,
Yes, sorry for the mistake. For Exchange 2013, the command should be Get-ClientAccessServer.
Like the article you shared above, this should be the correct way for Domain-joined computers to work with. Feel free to share your update here if any!
