I'm using an Exchange 2013 SP1 environment with almost no customization. Only 2 servers exists - one holding CAS+MBX, and a second one being an MBX. No DAGs, balancers, etc. Mapi over HTTP is not enabled. The default self-signed certificates are used (no new certificate was installed, nor any self-signed certificate manually installed on any server/client). A mailbox is provisioned on a database located on the first server. Outlook is configured for the corresponding user on a client machine and started. Everything works just fine, with the 'Outlook Connection status' window showing 2 Exchange Directory + 2 Exchange Mail connections. Authentication is NTLM. Ports for all 4 connections are 6001 - which hint that Outlook Anywhere is indeed used.

From time to time, the familiar "Security Alert" comes up warning about the self-signed certificate, but this is usually traced in my experience to the various services Outlook is using, that are running on HTTPS (OAB, EWS, Availability...). 

Here we find that in Exchange 2013 "Outlook Anywhere is enabled by default, because all Outlook connectivity takes place via Outlook Anywhere". Then here it's stated that "Outlook Anywhere won't work with a self-signed certificate on the Client Access server". I remember the latter being true against Exchange 2010 instances, but seems not to be the case in Exchange 2013 anymore. Unless I'm missing something, from the standpoint of a default installation, the 2 articles contradict each other. 

Second issue - even though Outlook is set for "Negotiate" in its Security setting, it looks like the Kerberos preferred option is never chosen. Would it have to do with the self-signed certificate and Outlook Anywhere ?

You'll get certificate warnings when your services are bound to a certificate that the clients don't trust.  A self-signed certificate won't be trusted unless you configure all client machines to trust it.

I totally agree, Ed. But the issue I'm struggling to figure out is why Technet article no 1 says "Outlook Anywhere will work by default with an out-of-the-box Exchange 2013, which is using self signed certificates for its CASes" and Technet article no 2 says "No way Outlook Anywhere will work with a self-signed certificate". Is there a specific nuance hidden somewhere - like "Outlook Anywhere will work with the default self-sign certificates, but only using NTLM as the authentication method; if you want Kerberos, you need to issue those certs from a public PKI or have your internal CA root trusted by all Outlook clients" ?

I can't speak to TechNet articles you didn't specify, sorry.

My mistake - it's the 2 articles linked in my initial post, along with the relevant excerpts. Technet article no 1 is this while Technet article no 2 is this.

I'm not going to read both of those articles completely, but the quotes you provide do not say what you most recently said.  Outlook Anywhere is enabled by default (you said it works by default) and Outlook Anywhere requires a certificate that is trusted by clients, something that has been true since the feature was first included in Exchange.

First article says "[...]In Exchange 2013, Outlook Anywhere is enabled by default, because all Outlook connectivity takes place via Outlook Anywhere.[...]". A simple Exchange 2013 SP1 setup, using defaults - including the built-in self-signed certs - can be reached with no problems with a regular Outlook client. Since RPC over TCP is now defunct, and MAPI over HTTP isn't enabled (it's a regular installation, hence this feature is disabled) it can only be Outlook Anywhere being used by the Outlook client to connect to the vanilla Exchange 2013 SP1 installation. Hence we can conclude that Outlook Anywhere works by default.

Second article comes around and says "[...] Outlook Anywhere won't work with a self-signed certificate on the Client Access server.[...]". Yet this is contrary to what I'm experiencing - since Outlook Anywhere is working (what other method of connecting is left, right ? plus even the connections over :6001 in the Connection Status window hint at this) and there hasn't been any CA-emitted certificate installed on that stock CAS server.

So either the sentence in the second article is flat wrong (ONLY for 2013, Exchange 2010 NEEDS trusted certs), or it's missing a clause. Am I missing something ?

Let me quote your first link completely.

"In Exchange 2013, Outlook Anywhere is enabled by default, because all Outlook connectivity takes place via Outlook Anywhere. The only post-deployment task you must perform to successfully use Outlook Anywhere is to install a valid SSL certificate on your Client Access server. Mailbox servers in your organization only require the default self-signed SSL certificate."  (Bold emphasis is mine.)

If you separate the mailbox role from the client access role, you don't have to install a valid certificate on the mailbox server because clients do not connect to it.  Clients connect to the CAS role.

The test user's mailbox is on the MBX server that's collocated with the single CAS role. An Outlook profile configured against this user works just fine with the default self-signed certificates. Does "The only post-deployment task you must perform to successfully use Outlook Anywhere is to install a valid SSL certificate on your Client Access server." still hold true ? Doesn't seem to be, since I'm already successfully connecting to Outlook Anywhere - powered by the CAS server - using the default self-signed certificates.

I also went ahead and double-checked that there's no CA somehow installed in that environment that might have resulted in a certificate being issued to the CAS server. I've checked the certificates installed - there's 3 of them, all self-signed. One for SMTP (subject is CN=Microsoft Exchange Server Auth Certificate), another for IMAP/POP/IIS/SMTP, and one with no services assigned (subject is CN=WMSvc-<servername>). The one used by Outlook Anywhere must obviously be the IIS one.

Of course it is the IIS one.  It doesn't matter whether Mailbox and CAS are collocated or not.  Clients talk to the CAS server and they must trust the certificate.

Yet the Outlook Anywhere client in my environment talks to the CAS server just fine, without trusting the certificate. Thus violating the 2nd sentence from Technet's article no 1 you've pasted (which mandates installing another certificate in order for Outlook Anywhere to work), as well as Technet article no 2 mentioned above (which states that Outlook Anywhere won't work with a self-signed certificate). Did I mix things up ?

First article says "[...]In Exchange 2013, Outlook Anywhere is enabled by default, because all Outlook connectivity takes place via Outlook Anywhere.[...]". A simple Exchange 2013 SP1 setup, using defaults - including the built-in self-signed certs - can be reached with no problems with a regular Outlook client. Since RPC over TCP is now defunct, and MAPI over HTTP isn't enabled (it's a regular installation, hence this feature is disabled) it can only be Outlook Anywhere being used by the Outlook client to connect to the vanilla Exchange 2013 SP1 installation. Hence we can conclude that Outlook Anywhere works by default.

Second article comes around and says "[...] Outlook Anywhere won't work with a self-signed certificate on the Client Access server.[...]". Yet this is contrary to what I'm experiencing - since Outlook Anywhere is working (what other method of connecting is left, right ? plus even the connections over :6001 in the Connection Status window hint at this) and there hasn't been any CA-emitted certificate installed on that stock CAS server.

So either the sentence in the second article is flat wrong (ONLY for 2013, Exchange 2010 NEEDS trusted certs), or it's missing a clause. Am I missing something ?

Hi,

Yes, Outlook Anywhere is enabled by default. Because all Outlook connectivity from Internal and External are using Outlook Anywhere.

For your second question, "[...] Outlook Anywhere won't work with a self-signed certificate on the Client Access server.[...]".  Based on my knowledge, the Self-signed certificate which is installed with Exchange 2013 installation is not issued by any CA. It is issued by the Exchange server.

Outlook Anywhere won't work with a self-signed certificate on the Client Access server because there would be a certificate untrusted issue on every user's clients. If you don't install the untrusted certificate in your trusted root certificate store on the client computer, the client will be always prompted for the certificate error even through you can work with Exchange services after clicking Yes when the Security Alert asking you Do you want to proceed.

Regards,

Hi Winnie. I totally agree with your first 2 paragraphs. However - in my default Exchange 2013 environment - even though the clients don't trust the self-signed certificate issued by the Exchange server, after starting up, Outlook is displaying "Connected to: Microsoft Exchange". So they are successfully using Outlook Anywhere. Contrast this to Exchange 2007/2010, where you can't connect in the first place using Outlook Anywhere over a self-signed certificate. Starting an Outlook client against an Outlook Anywhere-enabled Exchange 2010 with Basic Authentication will result in endless prompts for the password accompanied by the dreaded message below:

The "Security Alert" below - that also shows up - was traced by me to the EWS requests (using Fiddler).

I'll continue in a new post (looks like there's a limit of 2 images per message).

[continued from post above]

The end result is that the Outlook Anywhere client never makes it to successfully connecting to the server. The configuration of the Outlook client running against Exchange 2010 in my lab is below. Note that I've manually modified the "Connect first" checkboxes so Outlook Anywhere is attempted first. Also the authentication method is set to "Basic" as to match the setting made when enabling Outlook Anywhere. The rest of the settings are picked up obviously from the default Outlook providers. Outlook's configuration is below:

<o:p></o:p>

As soon as the default certificate is installed in the Trusted Root Certification Authorities on the client - everything works nicely and Outlook connects.

Now let's switch over to the Outlook client running against the default Exchange 2013. The certificate is not trusted and still Outlook connects just fine (using the only method available - Outlook Anywhere). The default configuration is below - note that I haven't made any change to this Outlook profile:

<o:p></o:p>

Sure enough - the Security Alert window hits again, since this isn't a trusted certificate by the client, but again I believe this is due to the EWS requests, not Outlook Anywhere itself.<o:p></o:p>

<o:p></o:p>

Albert,

I like you.  You demand a literal understanding of what's happening, and won't settle for the people above reciting the documentation back to you.  You are completely correct that the system seems not to behave as described.  It's easy for someone to just say, "You're supposed to use a valid certificate!"  Duh.  The question is, why does Exchange 2013 seem to work when it's first installed with an untrusted self-signed certificate?

Here is the answer.

In Exchange 2013, Outlook Anywhere is now enabled by default, using a self-signed certificate, but with ExternalClientsRequireSsl and InternalClientsRequireSsl set to False.  When you connect with Outlook, these parameters are included in Autodiscovery, and the client elects not to use SSL.

With RPC over HTTP, if SSL is not used, Outlook will connect to your mailbox through a CAS with an untrusted certificate (although, as you pointed out, you'll still get prompts for when it downloads the OAB or whatever).  If SSL is required, Outlook will not connect at all, and won't give you the option to ignore the error.

In Exchange 2010, SSL is required by default for Outlook Anywhere, and this is pushed out by Autodiscover, which is why Outlook cannot connect via Outlook Anywhere with a self-signed certificate on a new installation.

You can even see it in your screenshots above: Note that "Connect using SSL only" is unchecked in your Outlook client attached to Exchange 2013, but it was checked when you connected to Exchange 2010.  I'll bet if you disable the SSL requirement on your Exchange 2010 server's Outlook Anywhere (you have to do it in IIS, and manually edit the relevant web.config file if you don't have SP1), your Outlook client will connect.  You might have to restart IIS so Autodiscover picks up the new settings, and restart Outlook.

By the way, if you go into EAC on a new Exchange 2013 installation, go to Servers -> Servers, then edit the CAS, and enter an external URL for Outlook Anywhere, the EAC, without telling you, will set both ExternalClientsRequireSsl and InternalClientsRequireSsl to True.  This change is reflected in the Autodiscover parameters, which Outlook promptly picks up.  So, simply doing that will seem to break Outlook that was working just fine on the internal network; you'll notice that, with an untrusted certificate, Outlook will now behave the same as when connecting to an Outlook Anywhere enabled Exchange 2010 CAS with an untrusted certificate.  Even if you try to uncheck "Connect using SSL only", it will just revert back, because the Autodiscover parameters say otherwise.

Jeffrey Fox

• Proposed as answer by Ed CrowleyMVP 1 hour 33 minutes ago
• Unproposed as answer by Ed CrowleyMVP 1 hour 33 minutes ago

Albert,

I like you.  You demand a literal understanding of what's happening, and won't settle for the people above reciting the documentation back to you.  You are completely correct that the system seems not to behave as described.  It's easy for someone to just say, "You're supposed to use a valid certificate!"  Duh.  The question is, why does Exchange 2013 seem to work when it's first installed with an untrusted self-signed certificate?

Here is the answer.

In Exchange 2013, Outlook Anywhere is now enabled by default, using a self-signed certificate, but with ExternalClientsRequireSsl and InternalClientsRequireSsl set to False.  When you connect with Outlook, these parameters are included in Autodiscovery, and the client elects not to use SSL.

With RPC over HTTP, if SSL is not used, Outlook will connect to your mailbox through a CAS with an untrusted certificate (although, as you pointed out, you'll still get prompts for when it downloads the OAB or whatever).  If SSL is required, Outlook will not connect at all, and won't give you the option to ignore the error.

In Exchange 2010, SSL is required by default for Outlook Anywhere, and this is pushed out by Autodiscover, which is why Outlook cannot connect via Outlook Anywhere with a self-signed certificate on a new installation.

You can even see it in your screenshots above: Note that "Connect using SSL only" is unchecked in your Outlook client attached to Exchange 2013, but it was checked when you connected to Exchange 2010.  I'll bet if you disable the SSL requirement on your Exchange 2010 server's Outlook Anywhere (you have to do it in IIS, and manually edit the relevant web.config file if you don't have SP1), your Outlook client will connect.  You might have to restart IIS so Autodiscover picks up the new settings, and restart Outlook.

By the way, if you go into EAC on a new Exchange 2013 installation, go to Servers -> Servers, then edit the CAS, and enter an external URL for Outlook Anywhere, the EAC, without telling you, will set both ExternalClientsRequireSsl and InternalClientsRequireSsl to True.  This change is reflected in the Autodiscover parameters, which Outlook promptly picks up.  So, simply doing that will seem to break Outlook that was working just fine on the internal network; you'll notice that, with an untrusted certificate, Outlook will now behave the same as when connecting to an Outlook Anywhere enabled Exchange 2010 CAS with an untrusted certificate.  Even if you try to uncheck "Connect using SSL only", it will just revert back, because the Autodiscover parameters say otherwise.

Jeffrey Fox

• Proposed as answer by Ed CrowleyMVP Friday, May 15, 2015 5:54 AM
• Unproposed as answer by Ed CrowleyMVP Friday, May 15, 2015 5:55 AM

Albert,

I like you.  You demand a literal understanding of what's happening, and won't settle for the people above reciting the documentation back to you.  You are completely correct that the system seems not to behave as described.  It's easy for someone to just say, "You're supposed to use a valid certificate!"  Duh.  The question is, why does Exchange 2013 seem to work when it's first installed with an untrusted self-signed certificate?

Here is the answer.

In Exchange 2013, Outlook Anywhere is now enabled by default, using a self-signed certificate, but with ExternalClientsRequireSsl and InternalClientsRequireSsl set to False.  When you connect with Outlook, these parameters are included in Autodiscovery, and the client elects not to use SSL.

With RPC over HTTP, if SSL is not used, Outlook will connect to your mailbox through a CAS with an untrusted certificate (although, as you pointed out, you'll still get prompts for when it downloads the OAB or whatever).  If SSL is required, Outlook will not connect at all, and won't give you the option to ignore the error.

In Exchange 2010, SSL is required by default for Outlook Anywhere, and this is pushed out by Autodiscover, which is why Outlook cannot connect via Outlook Anywhere with a self-signed certificate on a new installation.

You can even see it in your screenshots above: Note that "Connect using SSL only" is unchecked in your Outlook client attached to Exchange 2013, but it was checked when you connected to Exchange 2010.  I'll bet if you disable the SSL requirement on your Exchange 2010 server's Outlook Anywhere (you have to do it in IIS, and manually edit the relevant web.config file if you don't have SP1), your Outlook client will connect.  You might have to restart IIS so Autodiscover picks up the new settings, and restart Outlook.

By the way, if you go into EAC on a new Exchange 2013 installation, go to Servers -> Servers, then edit the CAS, and enter an external URL for Outlook Anywhere, the EAC, without telling you, will set both ExternalClientsRequireSsl and InternalClientsRequireSsl to True.  This change is reflected in the Autodiscover parameters, which Outlook promptly picks up.  So, simply doing that will seem to break Outlook that was working just fine on the internal network; you'll notice that, with an untrusted certificate, Outlook will now behave the same as when connecting to an Outlook Anywhere enabled Exchange 2010 CAS with an untrusted certificate.  Even if you try to uncheck "Connect using SSL only", it will just revert back, because the Autodiscover parameters say otherwise.

Jeffrey Fox

• Proposed as answer by Ed CrowleyMVP Friday, May 15, 2015 5:54 AM
• Unproposed as answer by Ed CrowleyMVP Friday, May 15, 2015 5:55 AM
• Marked as answer by Albert Mihai 13 hours 9 minutes ago

Albert,

I like you.  You demand a literal understanding of what's happening, and won't settle for the people above reciting the documentation back to you.  You are completely correct that the system seems not to behave as described.  It's easy for someone to just say, "You're supposed to use a valid certificate!"  Duh.  The question is, why does Exchange 2013 seem to work when it's first installed with an untrusted self-signed certificate?

Here is the answer.

In Exchange 2013, Outlook Anywhere is now enabled by default, using a self-signed certificate, but with ExternalClientsRequireSsl and InternalClientsRequireSsl set to False.  When you connect with Outlook, these parameters are included in Autodiscovery, and the client elects not to use SSL.

With RPC over HTTP, if SSL is not used, Outlook will connect to your mailbox through a CAS with an untrusted certificate (although, as you pointed out, you'll still get prompts for when it downloads the OAB or whatever).  If SSL is required, Outlook will not connect at all, and won't give you the option to ignore the error.

In Exchange 2010, SSL is required by default for Outlook Anywhere, and this is pushed out by Autodiscover, which is why Outlook cannot connect via Outlook Anywhere with a self-signed certificate on a new installation.

You can even see it in your screenshots above: Note that "Connect using SSL only" is unchecked in your Outlook client attached to Exchange 2013, but it was checked when you connected to Exchange 2010.  I'll bet if you disable the SSL requirement on your Exchange 2010 server's Outlook Anywhere (you have to do it in IIS, and manually edit the relevant web.config file if you don't have SP1), your Outlook client will connect.  You might have to restart IIS so Autodiscover picks up the new settings, and restart Outlook.

By the way, if you go into EAC on a new Exchange 2013 installation, go to Servers -> Servers, then edit the CAS, and enter an external URL for Outlook Anywhere, the EAC, without telling you, will set both ExternalClientsRequireSsl and InternalClientsRequireSsl to True.  This change is reflected in the Autodiscover parameters, which Outlook promptly picks up.  So, simply doing that will seem to break Outlook that was working just fine on the internal network; you'll notice that, with an untrusted certificate, Outlook will now behave the same as when connecting to an Outlook Anywhere enabled Exchange 2010 CAS with an untrusted certificate.  Even if you try to uncheck "Connect using SSL only", it will just revert back, because the Autodiscover parameters say otherwise.

Jeffrey Fox

• Proposed as answer by Ed CrowleyMVP Friday, May 15, 2015 5:54 AM
• Unproposed as answer by Ed CrowleyMVP Friday, May 15, 2015 5:55 AM
• Marked as answer by Albert Mihai Saturday, July 18, 2015 6:18 PM

Jeffrey, I have to admit that I didn't make much of your reply at the time. I've simply read it quickly once and the information inside didn't really clicked in my head. Then forgot all about the thread - until today, when I was going by chance over one CAS article (part of a 4-episode series here). In there it was stated:

"The default Exchange 2013 internal Outlook Anywhere settings dont require HTTPS. By not requiring SSL, the client should be able to connect and not get a certificate pop-up for the mail and directory connections. However, you will still have to deploy a certificate that is trusted by the client machine for Exchange Web Services and OAB downloads."

I immediately remembered about this thread, and re-read your reply carefully. I've also went ahead and toggled ExternalClientsRequireSsl and InternalClientsRequireSsl to $true in the original lab. Sure enough, as soon as the settings kicked in and Outlook was restarted, the exact 2010 error hit back and left Outlook in a disconnected state. The Outlook profile had picked up the "Connect using SSL only" from the Exchange providers.

Didn't even realize until now that the solution was actually hidden in my own side-by-side printscreens, to which you very well pointed.

I've also went ahead and tested editing the Outlook Anywhere external hostname via ECP - even on CU9, there's no warning on the 2 aforementioned attributes being set to true, just like you said.

My apologies.