Trials over the weekend of the Outlook Anywhere didn't yield the results we had hoped.  Now internal OLK 2010 clients are getting a Proxy Error Code 10 when the OLK client is started, and the clients cant connect to their mailboxes.  I suspect this is to do with our configuring Exchange 2013 then returning to the original config.

The Error

Title : Microsoft Outlook

Detail : There is a problem with the proxy server's security certificate.  The name on the certificate is invalid or does not match the name of the targe site "servername.domain.local"  Outlook is unable to connect to the proxy server. (Error Code 10)

What did I do : in Exch2013 - Server - OLK Anywhere - there are 3 fields and a check box

1. External host name - was blank prior to testing, added external domain name during testing mail.ourdomainname.com.au then cleared the field when testing was complete.
2. Internal hostname - was unchanged from servername.doman.local.
3. Authentication method - was unchanged, but I admit I may not have noticed if it did change due to the FQDN being added in the 1st field.
4. Allow SSL Offloading - was checked and still is

My suspicion is that by configuring this feature as a test, that parts of Exch2013 may also need to be reset that aren't visible via the EAC.  As an FYI the external OurDomainName.com.au is current, and the SSL Cert is current, however the SSL only covers the external domain name Mail.OurDomainName.com.au

Not knowing much about your environment, this is almost impossible to answer.  But the error means that the certificate on the Exchange server does not match what Outlook is trying to connect to.  Typically this does not prevent connectivity though.  Do you have a proxy server in your environment?

No, no proxy server.   It seems to only affect the client.  I have resorted to using OWA internally which hasn't gone down too well understandably.  I am not game enough to cange the internal hostname in case it make matters worse

Are all mailboxes on Exchange 2013?

Did they previously connect to the OA URL mail.ourdomainname.com.au, or servername.ourdomainname.com.au?

Is the certificate 3rd party or self-signed?

Yes, 1 single Exchange 2013 server

The clients are all internal workstations, connection to Exchange 2013 by whatever the default is (when you start OLK and it self configures) to servername.localdomain.local.

SSL cert is Go-Daddy std SSL, is for the url mail.externaldomain.com.au

Well there's your problem :)

If the cert is for mail.externaldomain.com.au, and the client connects to servername.localdomain.local, it does not match so will prompt.

Exchange 2013 only supports HTTP connections, so certificates are required for secure HTTP.

Easiest way to fix would be to add the servername.domain.local to your certificate, but unfortunately most CAs are not supporting this anymore since they cannot identify who you are - and even if you get one to do it now, it will be much harder in the future when your certificate expires.

You will likely have to do some DNS zone magic here, adding a zone that matches your external domain and certificate, along with the accompanying dns records (mail., autodiscover., etc).  

You will then also need to update your URLs for the other HTTP services (OWA/ECP/EAS/EWS/Autodiscover) to prevent more issues.

I see where you are coming from and I did wonder about the SSL URL, but Outlook barks when connecting to  Exchange 2010 and 2013 whether there is an SSL in the process or not.

We'd certainly receive the "warning will robinson, your SSL cert domain name doesn't match the server name you are connecting to so proceed at huge risk to your life" especially since we can no longer get the cert for internal URL's.  Users just click thru it and it allows connectivity.

I am puzzled why it would suddenly stop.

I am also starting to wonder if the Spamfilter function on Exchange 2013 has something to do with it.  We enabled it last week.

spam filtering is transport and has nothing to do with client connectivity.

So you also have 2010 in the environment? Are they connecting via OA through the 2013 CAS? Or are they still connecting to the 2010 CAS via RPC/TCP?

Either way, Outlook still uses HTTP for other things, such as Autodiscover and EWS.  Although, as you mentioned, it would just warn you about the certificate.

It really sounds like you have a proxy, or something between the client and server that is preventing connectivity. Do the IIS or HTTPProxy logs on the 2013 server show clients attempting to connect with OA? You can also capture a concurrent netmon from client and server to see if packets are getting there.

Sorry to confuse, no Exchange 2010, no Proxy, and the only reason I am suspecting the OLK Anywhere is it was the last change made on the server and Spam Filter preceded it.

Will have a look at the logs again and traffic to see what I can find.

Hi,

Please check whether the certificate with external domain name Mail.OurDomainName.com.au is assigned with IIS service. Some Exchange services for Outlook Anywhere such as Autodisocover, Exchange Web Service, OWA, OAB etc. should be authenticated with certificate which is assigned with IIS service.

Personal suggestion, please change the internal host name and internal URLs to match the new SSL certificate with Mail.OurDomainName.com.au. Then check whether the issue persists

http://support.microsoft.com/kb/940726

Re

Hi Winnie,

Sorry for the delay, had to put everything on hold to attend to another matter.

So that I don't miss anything or mess anything up, where and what do I edit for this.  We are happy to not go ahead with OLK Anywhere

I have had to wait for testing out of business hours revealed the following results.

Exchange ECP

Certificates - the SSL cert for our mail.ourdomain.com.au is installed and valid

IIS

SSL cert for mail.ourdoamin.com.au issued by Go-Daddy is installed.  Am I missing something here because Internal and external users are accessing the server via OWA fine and the SSL is used by these, however both are using the url https://mail.ourdomain.com.au/owa

External SSL Test

Used Digicerts SSl checker, shows the cert is valid when accessing our mail server.  The server also hosts a helpdesk app that uses the same SSL cert which is fine too.

This morning I started the "Outlook Connectivity Guided Walkthrough" fired up Outlook to make sure we still had the problem, and started it with the RPCDiag switch - and of course it connected to the exchange server and the mailbox. Grrrr - should have become a fireman.

What have I done

I've slept on it.  For now I'll wait and see if by chance this is resolved

• Edited by MBKITMGR 16 hours 17 minutes ago

I have had to wait for testing out of business hours revealed the following results.

Exchange ECP

Certificates - the SSL cert for our mail.ourdomain.com.au is installed and valid

IIS

SSL cert for mail.ourdoamin.com.au issued by Go-Daddy is installed.  Am I missing something here because Internal and external users are accessing the server via OWA fine and the SSL is used by these, however both are using the url https://mail.ourdomain.com.au/owa

External SSL Test

Used Digicerts SSl checker, shows the cert is valid when accessing our mail server.  The server also hosts a helpdesk app that uses the same SSL cert which is fine too.

This morning I started the "Outlook Connectivity Guided Walkthrough" fired up Outlook to make sure we still had the problem, and started it with the RPCDiag switch - and of course it connected to the exchange server and the mailbox. Grrrr - should have become a fireman.

What have I done

I've slept on it.  For now I'll wait and see if by chance this is resolved

• Edited by MBKITMGR Wednesday, March 04, 2015 11:18 PM

Hi,

Any updates? Has the issue been resolved?

Regards,

I think it has resolved itself.

Have had a few episodes were I am being asked to supply credentials, but this has settled too.