Hi everyone,

I have the following issue in our Demo environment.

Outlook cannot connect when adding a profile in outlook, even though the Outlook Connectivity Check can reach the environment.
Even though the certificate does not match. Our OWA, Android en iOS connections are working (iOS is giving a cert error)

I tried outlook anywhere but sadly enough, this did not work either.

I have 2DC's and 2EXCH server which are set-up with domain.nl

I have also added a UPN Suffix so we can use domain2.nl in our enviroment.

Please help me out to solve this.

Kind regards
Justin

• Edited by JustinoFTW 17 hours 29 minutes ago

What's the error? 

Also, launch outlook with the /rpcdiag diag switch and take a look at what it's trying to connect to.

Unfortunately Outlook will not connect if the certificate isn't correct. In the past, you would get a cert error and could click "Continue" to get connected but that's no longer the case. You can always use one of the exchange self generated certificates. You would just need to export it from your exchange server and import it on to your test clients.

Unfortunately Outlook will not connect if the certificate isn't correct. In the past, you would get a cert error and could click "Continue" to get connected but that's no longer the case. You can always use one of the exchange self generated certificates. You would just need to export it from your exchange server and import it on to your test clients.

Is this new since Exchange 2013?

I'm not at the office anymore, but it said something like " Could not logon. Check the connection.........." when i'm adding a profile with an account for this new environment. 

• Edited by JustinoFTW 15 hours 14 minutes ago

I noticed the behavior in Outlook 2013. Outlook 2007 didn't behave that way.

Any idea how to solve this?

I have somewhere between 5 ~ 10 domains, so i guess i need a certificate for all of them :s
Do you have any link/page with the information about this new way of how its working?

Kind regards,

Justin

I ran into this issue with multiple domains with Exchange 2007 and 2013. We have 12 email domains that we support. Microsoft's stance is that they don't support "vanity" URL's meaning that the "Best Practice" is to assign a communications domain per datacenter and then setup URL redirects in IIS that redirect autodiscover.domain1.com to autodiscover.CommunicationDomain.com. There are "Exchange Hosting" add-on's that extend the vanity URL support but those can be expensive and overly complicated.

In response to the certificate question, probably the easiest option would be a SAN cert with all your email domain hosts assigned to it. 

We transitioned from Forefront TMG to F5 Big IP and APM.  The F5 gives us the ability to rewrite the autodiscover response XML file and replace the domain URL's so they match the users email domain.  So a user on domain2.com gets all domain2.com URL's in the autodiscover response and domain3.com users get domain3.com URL's.  The F5 option is, of course, expensive as well.

To keep things simple I would probably go the route of SAN Certs and doing the IIS URL redirect.  A good example of this in action would be Comcast business email service.  You might have your email domain as Justino.com but in your account setup in Outlook, your Exchange proxy URL is mail.srv1.Comcast.net.

Here's a link to this scenario for exchange 2010 but the same thing applies to 2013:

http://www.msexchange.org/articles-tutorials/exchange-server-2010/mobility-client-access/using-autodiscover-large-numbers-accepted-domains-part1.html

Did you install latest cumulative updates?  then try again

Regards,

Joby

I ran into this issue with multiple domains with Exchange 2007 and 2013. We have 12 email domains that we support. Microsoft's stance is that they don't support "vanity" URL's meaning that the "Best Practice" is to assign a communications domain per datacenter and then setup URL redirects in IIS that redirect autodiscover.domain1.com to autodiscover.CommunicationDomain.com. There are "Exchange Hosting" add-on's that extend the vanity URL support but those can be expensive and overly complicated.

In response to the certificate question, probably the easiest option would be a SAN cert with all your email domain hosts assigned to it. 

We transitioned from Forefront TMG to F5 Big IP and APM.  The F5 gives us the ability to rewrite the autodiscover response XML file and replace the domain URL's so they match the users email domain.  So a user on domain2.com gets all domain2.com URL's in the autodiscover response and domain3.com users get domain3.com URL's.  The F5 option is, of course, expensive as well.

To keep things simple I would probably go the route of SAN Certs and doing the IIS URL redirect.  A good example of this in action would be Comcast business email service.  You might have your email domain as Justino.com but in your account setup in Outlook, your Exchange proxy URL is mail.srv1.Comcast.net.

Here's a link to this scenario for exchange 2010 but the same thing applies to 2013:

http://www.msexchange.org/articles-tutorials/exchange-server-2010/mobility-client-access/using-autodiscover-large-numbers-accepted-domains-part1.html

Our live environment (exch 2010) is currently running the autodiscover rewrite trick. But i'm receiving a HTTP 500 error when checking the OutlookConnetivity Check. Any idea why this is happening?

Once this issue is resolved we can go into a beta stage before going live.

Thanks for heping so far.

HI,

Actually this the issue is related to MAPIoverHTTP. The user which have been migrated OR new exist on exchange 2013 will get an error when connect to outlook 2010 OR 2013, while the same users could easily be connected to outlook 2007. This is because outlook 2010SP2 ( with 2 updates) & outlook 2013 first try to connect exchange 2013 via MAPIoverHTTP, while outlook 2007 directly connect to exchange 2013 is use RPC over HTTP. I am 100% sure its related to mapiover HTTP