Link to home
Start Free TrialLog in
Avatar of LockDown32
LockDown32Flag for United States of America

asked on

SBS 2011, OA and Outlook 2013

I am having fits. I have a customer running a SBS 2011 Server and trying to connect via RPC/https from his home computer running Outlook 2013. I can connect to it the very first time. It will sync and everything looks fine until I close Outlook at which point it will never connect again.

The second time I open Outlook I get a SSL Cert warning about remote.domain.com followed but the same SSL Cert warning about autodiscover.domain.com. It will never connect a second time. I have a feeling it is Outlook 2013 but can't figure it out. Why is it checking remote and autodiscover certs? Any ideas what I need to do to get this working?
ASKER CERTIFIED SOLUTION
Avatar of Dejan Vasiljevic
Dejan Vasiljevic

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Avatar of David Atkin
David Atkin
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of LockDown32

ASKER

The Microsoft Analyzer works just fine. As mentioned above I can connect to it the first time and it sync's fine. What I have noticed though is that after the first time I connect to it, it sets a lot of SSL settings in the Exchange Proxy Settings in Outlook.  If I turn off a lot of the things it sets it seems to connect and work so...

I am going to go back to the original thought that it is the SSL Certs for the remote and autodiscovery. I really couldn't tell you if the self signed ones have been installed. Can you point me to a link to get them installed?
Browse to your OWA url in IE on the client your working on.  Do you get a page saying that there 'There is a problem with this websites security certificate'?

Do you have an autodiscover record setup in external DNS?

Also, do you have the Exchange SP3 installed?
I am going to take these one at a time. OWA does not give me a cert error. I purchased a cert for mail.domain.com and that appears to be the only cert that OWA uses. The cert errors seem to be for remote and autodiscover which OWA doesn't use but OA does. So .... do I or don't I need to install the self signed certs for remote and autodiscover?
No you do not need to install the self signed cert if you're using a trusted one.

Do you have an autodiscover srv record setup in your external DNS?

Also, what addresses are specified in your trusted cert?
There is only one address in the cert. mail.domain.com That is what OWA uses hence no cert error. Back to OA.... the cert errors that pop up in Outlook 2013 are for remote.domain.com and autodiscover.domain.com. So why is Outlook 2013 even looking at the certs for remote.domain.com and autodiscover.domain.com?

There is no Autodiscover record set up in the external DNS.
Do you have a remote. record setup at all?

I believe that auto discover will check these records when it opens so that may be why you are getting the error.  If the remote. record is setup then it may try and connect with that and give you the cert error.

Can you add remote.domain.com into your host file and point it at 127.0.0.1.  Then open outlook and let us know if you get the same error.
To my knowledge neither the remote or autodiscover has been set up. I would be happy to set both up if you think that is what is needed.
Can you add them both to the clients local host file first and point them at 127.0.0.1 - I'm just curious if this stops the prompt.
Sounds like things are not properly setup for Outlook Anywhere.  By default, SBS 2011 is setup to run EVERYTHING from one SSL certificate.  However, it also expects that certificate to be linked to remote.company.com.  Now, from what you are saying, your SSL is registered to mail.company.com, correct?

The recommended procedure is to get a single UCC-SSL with several Subject Alternate Names (SANs) as follows:
1)   remote.company.com
2)   company.com
3)   fqdn.server.local
4)   servername (no extension, i.e. netbios name)
5)   autodiscover.company.com

Such a certificate is available pretty cheap from places like godaddy and covers ALL connection scenarios right out of the box so that everything just works. I just checked with godaddy for you and they are currently $140USD per year.  So, if you have this in the budget, you'll save some time by getting the right certificate.

If a new certificate is not an option, we can work with your existing one via redirects on your IIS server.  Please post back if that's the option you'd like to go with.  It's a little involved, but can definitely be done.
Just out of interest, what ended up being the problem?  I know you accepted this as solved, but really all 3 of us just gave you troubleshooting tips, so I'm interested in knowing what ended up working.  Thanks :-)
Actually it was never resolved. In the Proxy Setting on the Outlook client I un-checked the use SSL settings and when Outlook starts I still get the SSL warnings but it works.

One of these days I'll find out how and where to set the autodiscover and remote entries but it works so I am not going to rock the boat.
That's almost certainly caused by your server using the mail.company.com certificate also for autodiscover.company.com and remote.company.com but the certificate does not list SANs for those subdomains.  Therefore, you get an SSL failure.  By unchecking the box, you are saying 'don't tell me about errors!'.  That's why it's working.  My earlier comment would resolve the situation but involve a new/different certificate.  As I mentioned after that comment, there is a way around it using IIS redirection.  If you'd like to go that route, I'd suggest posting a new question and linking it here, I'd be happy to help.

Glad you worked around the issue for now!
I thought something similar to this.  Pointing the the remote and autodiscover to the local PC should have stopped the error as well - Obviously not a fix but it would have proven the problem.