1

We use the autodiscover option for IE. Our Outlook 2016 clients connecting to Office 365 are getting an chronic ssl name mismatch for autodiscover.ourdomain.onmicrosoft.com. My team has spent weeks playing with this, and it only happens when the proxy is set to use our wpad file.

Effectively what is happening is that the site above doesn't respond over https, but our proxy still builds a connection between the workstation and the firewall, which result in an error.

I've updated the wpad file with the following which helps with Office 2010. Is there some limitation in the Outlook 2016 implementation that I'm missing to result in this behavior?

function FindProxyForURL(url, host) {
    if (
        ....
        shExpMatch( url, "*/autodiscover.xml") ||
        shExpMatch(host, "*outlook.office365.com") ||
        shExpMatch(host, "*ourdomain.mail.onmicrosoft.com") ||
        shExpMatch(host, "autodiscover.ourdomain.mail.onmicrosoft.com") ||
         ....
         )
        return "DIRECT";

     return "PROXY firewall:8080;";  
}

EDIT: I also have tried importing the URLs created from the script from the technet blog Office 365 PAC file post without success.

Tim Brigham
  • 15,465
  • 7
  • 72
  • 113
  • I presume all connections must go out through the firewall. So the "DIRECT" connection that the first proxy is using is still going through the firewall but with NAT? You're sure the firewall isn't intercepting and doing https inspection on this? – Adrien Aug 08 '16 at 10:32

1 Answers1

0

Outlook doesn't normalize the URL or Host variables before parsing the WPAD script. If you have an uppercase character in any of your URLs then there will be no match and the traffic will be sent to the proxy.

If this is true in your scenario then you will need to add this to the top of your FindProxy function:

host=host.toLowerCase();
url=url.toLowerCase();
blacklight
  • 1,369
  • 1
  • 10
  • 19