Would there be a obvious reason why users can access OWA to receive email but they get a disconnect error on their Outlook client?

Things I've done:

Restarted/Checked all Microsoft Exchange Services. No errors

Rolled back new update- Rollup 6 for Exchange 2010 SP3

Checked Event View logs

Ran Microsoft Remote Connectivity Analyzer

Possible Solution:


However Outlook Client is disconnected from Exchange 2010 SP3 Server, where OWA link works great and allows client to send and receive email Any suggestions on what I can do to troubleshoot this further?

OS:Windows 2008 R2 Exchange 2010 SP3

closed as off-topic by Massimo, Ward, MichelZ, Mathias R. Jessen, mdpc Jul 15 '14 at 20:05

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions must demonstrate a minimal understanding of the problem being solved. Try including attempted solutions, why they didn't work, and the expected results. See How can I ask better questions on Server Fault? for further guidance." – Massimo, Ward, MichelZ, Mathias R. Jessen
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Your MX record isn't going to affect how Outlook clients connect. What version of Outlook? – DanBig Jul 14 '14 at 20:08
  • 1
    1. Your MX records don't have anything to do with email clients connecting to their mailboxes. 2. Blacklists don't have anything to do with email clients connecting to their mailboxes. 3. Rolling back the updates seems a bit extreme considering you don't have any idea what's causing the problem. I wouldn't roll back the updates until I was sure they were the problem. 4. Can you give us some detail on what you mean by they get a disconnect error on their Outlook client? 5. Have you tried the Microsoft Remote Connectivity Analyzer? If not, then do so and post the results back here. – joeqwerty Jul 14 '14 at 20:08
  • 2
    What @joeqwerty said : consult this first. testconnectivity.microsoft.com – mfinni Jul 14 '14 at 20:24
  • 1
    Simple check on the client done via holding CTRL and right clicking the Outlook notification bar Icon and choosing Connection Status and Test Email Autoconfiguration to see what is happening at a quick glance? – TheCleaner Jul 14 '14 at 20:36
  • Have been using Exchange 2010 SP3 rollup 6 just fine. Agreed with the above comments, first step use the Microsoft Connectivity test. Would also triple check Microsoft Exchange RPC Client Access service. – Cold T Jul 14 '14 at 21:44

According to the results from Microsoft's Remote Connectivity Analyzer, there is a problem with your autodiscover service, which is the service used by Outlook to automatically locate your Exchange server.

Autodiscover is a web service running on your Exchange server, and it should be published to the Internet just like OWA and all other Exchange web services (EWS, ECP, OAB, ActiveSync); an Outlook client will try to locate it using three systems:

  • It will look for a web server at the URL https://yoursmtpdomain.com and, if one is found, it will call the web service from this site.
  • If this fails, it will try the same with the URL https://autodiscover.yoursmtpdomain.com.
  • Finally, if this fails too, it will look for a DNS SRV record called _autodiscover._tcp.yoursmtpdomain.com and connect to the web server pointed to by that record, whatever its actual name is.

Neither of these solutions seem to be in place in your environment, thus the autodiscover process fails, and Outlook doesn't know where it should connect to. There actually is a web server answering at the URL https://jonesstuckey.com, but:

  1. It's not your Exchange server
  2. It doesn't have a valid certificate, because the site name doesn't match the certificate name.

I took the liberty to do a quick probe to your Exchange server, which I (correctly) guessed is located at https://mail.jonesstuckey.com. The certificate you're using contains the names mail.jonesstuckey.com and www.mail.jonesstuckey.com (which looks useless), so, unless you want to replace it with another certificate containing also autodiscover.jonesstuckey.com (which would be the correct solution), you can only successfully use the third autodiscover method, i.e. create a DNS SRV record called _autodiscover._tcp.jonesstuckey.com and point it to mail.jonesstuckey.com on TCP port 443.

This should fix your autodiscover problem; if then your Outlook clients still can't connect, post another question and we'll see if we can help you further.

  • I will try this. But why would a client be able to access OWA fine, but not be connected to the Exchange Server via Outlook Client? – Benjamin Jones Jul 15 '14 at 1:15
  • Because OWA is a web application running on your Exchange server, while Outlook talks to different web services (Outlook Anywhere, autodiscover, and a couple more) running on the same server but in a completely different way. – Massimo Jul 15 '14 at 1:16
  • Also, you should configure the URLs for the various Exchange web services, and enable Outlook Anywhere (which is by default disabled). Have a look on MSDN. Exchange is quite a complex product, and it's not meant to work out-of-the-box, it needs proper configuration. – Massimo Jul 15 '14 at 1:21
  • My solution had nothing to do with certificates . – Benjamin Jones Jul 15 '14 at 3:37
  • Well, good for you. But from the data you posted, the error was in the autodiscover service not working; the Remote Connectivity Analyzer didn't even get to try to connect to the RPC Client Access Service, because it wasn't even able to find it. – Massimo Jul 15 '14 at 12:28

What worked was the link I provided above: http://support.microsoft.com/kb/2006508

I ran their resolution with no luck. In fact it mention that the resolution was not applied to the RPC Client Access. I thought to my self...hmmm...maybe check to make sure the RPC Client Access Service is running? Turns out it was disable! Enabled it and started it! Connection restored to Outlook Clients!

  • That service should never be disabled. Maybe stopped if it crashed for some reason (which is unlikely), but definitely not disabled... – Massimo Jul 15 '14 at 12:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.