0

I've configured a fresh Exchange 2013 server on a 2012 box. It's all working correctly aside from that internal computers will not run the autodiscover wizard.

I have attempted multiple troubleshooting steps and none have been successful. It does autodiscover externally. Also the Microsoft Test Connectivity passes successfully (aside from the SSL identity, which is fine as I'm deploying the self-signed cert with a GPO.).

The error I'm receiving on the client is:

The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.

If I set the connection settings manually with HTTP etc. it does connect, however then there are still problems moving emails between folders. Plus, I cannot afford to go around every machine doing this manually.

Falcon Momot
  • 24,975
  • 13
  • 61
  • 92
GRitchie
  • 1
  • 2

2 Answers2

1

How did you setup your internal URLs and URI for autodiscover? What DNS names are you using internally? Did you create an autodiscover DNS record(s) to point to the internal Exchange 2013 server? After starting Outlook, right click the outlook icon in the taskbar tray while holding CTRL and choose "Test email autoconfiguration" and then press the "Test" button. What are the results?

Erik
  • 174
  • 7
  • I've created the Forward Lookup Zone and pointed autodiscover.publicdomain.co.uk to the servers internal IP address. I also tried using SRV records? When I run the test, it all returns back as I would expect. Finds the autodiscover files etc. – GRitchie Sep 08 '15 at 08:13
  • How about your virtual directories? How is the InternalURL configured? Did you configure OutlookAnywhere correctly? I have found this article pretty helpful in configuring our own Exchange 2013 environment. This is actually a migration from exchange 2010 to 2013 article, but it still contains a lot of useful configuration information regarding Exchange 2013: http://exchangeserverpro.com/exchange-server-2010-2013-migration-preparing-co-existence/ Did you try to recreate an outlook profile from scratch? If you ping the internal server from the client do you get a reply from the internal ip? – Erik Sep 08 '15 at 08:45
  • I read online that I should set all the virtual-directory internal URLs to the same as the external. As of that, my Outlook Anywhere URL is mail.publicdomain.co.uk. I **can** ping the server internally. I've tried recreating the profile from scratch on multiple machines. – GRitchie Sep 08 '15 at 08:51
  • How about the outlook provider? What is the output if you run 'Get-OutlookProvider' in EMC ? – Erik Sep 08 '15 at 09:11
  • Shows NAME (EXCH, EXPR, WEB) then nothing listed next to 'server'. – GRitchie Sep 08 '15 at 09:36
  • and below CertPrincipalName? – Erik Sep 08 '15 at 09:39
  • Once again, nothing. TTL is all 1 – GRitchie Sep 08 '15 at 09:43
  • Aside from the ExtenalClientAuthenticationMethod that all looks the same (under server, outlook anywhere?) – GRitchie Sep 08 '15 at 09:49
  • using `set-outlookprovider` we have set the `CertPrincipalName` to `msstd:*.publicdomain.com`; we are using a wildcard certificate. Using `Set-OutlookAnywhere` we have set `ExternalHostname` to `webmail.publicdomain.com`, `InternalHostname` to `webmail.publicdomain.com`, `ExternalClientsRequireSsl` to `True`, `InternalClientsRequireSsl` to `True`, `ExternalClientAuthenticationMethod` to `Ntlm`. Is webmail working from the internal clients? – Erik Sep 08 '15 at 10:03
  • OWA for internal clients works fine yes – GRitchie Sep 08 '15 at 10:38
  • did you try setting the outlookanywhere and outlookprovider as mentioned? I don't know how big your environment is, but outlookprovider can take a while to replicate through the network/active directory. – Erik Sep 08 '15 at 11:28
  • I've made the changes to CertPrincipalName so they are all now `msstd:*.publicdomain.co.uk`. I've got the `ExternalClientAuthenticationMethod` within `OutlookAnywhere` set to `Negotiate` as that is working for us. Do I need to change to NTLM? – GRitchie Sep 08 '15 at 12:28
  • **Update:** after changing the `CertPrincipalName` it runs the wizard, but it doesn't populate the fields automatically. After entering manually, it completes. When 'loading profile' it eventually errors with the same original error. – GRitchie Sep 08 '15 at 12:36
  • are you using a wildcard certificate? `*.publicdomain.co.uk` if not change `msstd:*.publicdomain.co.uk` to `msstd:certname.publicdomain.co.uk`. Furthermore what are the results if you run `Get-ClientAccessServer | FL AutoDiscoverServiceInternalUri` ? And next to `autodiscover.publicdomain.co.uk` did you also add `mail.publicdomain.co.uk` to your internal DNS pointing to the internal ip of your mail server? – Erik Sep 08 '15 at 13:12
  • I don't think I'm using a wildcard certificate. So literally change it to `msstd:certname.mydomainhere.co.uk` or do I need to change the word `certname` to something else? The return for that command is `https://local-server/Autodiscover/Autodiscover.xml`. I have also pointed mail.publicdomain.co.u to my internal server IP. – GRitchie Sep 08 '15 at 13:38
  • you need to replace certname with the dns name that is in your certificate, which is I guess `mail.publicdomain.co.uk` ? Maybe the AutoDiscoverServiceInternalUri isn't correct, try using `Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://autodiscover.publicdomain.co.uk/Autodiscover/Autodiscover.xml` make sure changes have replicated and try configuring outlook again. – Erik Sep 08 '15 at 14:03
  • All changed, still no luck! – GRitchie Sep 08 '15 at 14:13
  • I am starting to run out of options here... how about that outlookanywhere are the `InternalClientsRequireSsl` and `ExternalClientsRequireSsl` set to true? – Erik Sep 08 '15 at 14:36
  • Yes, both set to true. Tell me about it, I've been stuck for days! – GRitchie Sep 08 '15 at 14:46
  • This is really a clean install of exchange 2013? No previous Exchange or other brand mail servers? Clients are on the same network as the Exchange server? Firewall is turned off? And with setting the outlook provider the config of outlook did go a bit further than before, maybe need to fiddle around with those settings a little more? And the SRV records, are those still in place? – Erik Sep 08 '15 at 15:27
  • It's a complete clean install. From what I'm aware there has never been an exchange server here. Clients **are** on the same network. The client firewalls are off, the server is on (with appropriate ports open). SRV records are no longer in place - when I found it didn't fix it, I removed them as not to cause other problems. – GRitchie Sep 09 '15 at 07:03
  • for testing sake, can you completely turn off the firewall on the server for a while? – Erik Sep 09 '15 at 07:52
  • Attempted again with the firewalls off, still nothing. – GRitchie Sep 09 '15 at 09:53
  • Did you come across this one already? [kb3032395](https://support.microsoft.com/en-us/kb/3032395) – Erik Sep 09 '15 at 10:17
  • or this hotfix [kb2597011](https://support.microsoft.com/en-us/kb/2597011)? (Got there via [msexchange.org](http://www.msexchange.org/blogs/bhargavs/exchange-server/outlook-must-be-online-or-connected.html)). Or this one [kb2264398](https://support.microsoft.com/en-us/kb/2264398) – Erik Sep 09 '15 at 10:23
1

Couple of things for you to configure:

  1. Virtual Directories.

  2. Review your certificate and DNS configuration. You need to implement something called split DNS. You need to create and configure the external zone the is used in your external DNS for Exchange, inside your internal DNS server. You need to make sure that your certificate lists the internal name for the Exchange that you want to use. Since Autodiscover works properly externally, as you indicated, there's no need to deploy and configure certificate using GPO, once the proper configuration is used.

  3. As for the cert, make sure you're deploying a proper 3-rd party SAN or wildcard SSL.

Community
  • 1
Vick Vega
  • 2,398
  • 16
  • 22
  • I'm using a self-signed cert (I know it's advised against, but it does still work). I've configured a forward lookup zone for the public domain (within my local AD/DC DNS). Pointing autodiscover.publicdomain.co.uk to the internal server's IP. I've also tried using SRV records for _autodiscover with _tcp. – GRitchie Sep 08 '15 at 08:17
  • Did you configure the virtual directories? – Vick Vega Sep 08 '15 at 18:49