So I've had issues for a long time with out of office, i believe my exchange has been setup incorrectly. When running tests on testexchangeconnectivity it connects to http://mydomain.com/autodiscover and tries http://autodiscover.mydomanin.com unfortunately neither of these have been configured and i only have the DNS set up for owa.mydomain.com
OOF
Whats my best step? mydomain.com points to my web designers server. owa.mydomain points to us and seems to work for remote(sbs2011 thing) and OWA.
sbs2011, exchange2010
Autodiscover is a means to help simplify the configuration of remote Outlook installations and mobile devices to use Exchange. Microsoft's verbose documentation about this feature is here.
The easiest approach to get over the autodiscover hurdle is to create a public DNS A Record for
autodiscover.mydomain.com
that points to your SBS server's IP address. This can also be a CNAME alias, but I prefer the A Record. This can be requested or configured through your domain registrar or whomever manages your public DNS. That's really the bulk of the setup from the DNS side.The other portion is to deal with your SSL certificate. If you browse to your webmail address and examinee the SSL certificate, you'll see what DNS names are configured. You may want to have the autodiscover names on the same cert. Again, a more involved process, but helpful in the long run.
Since this is an SBS, you may only have a single-name certificate. I'd check with the original implementor, but your alternative would be to create a fallback SRV DNS record instead. See this approach from Microsoft and additional notes here.
Even though autodiscover fails for you now, you should still be able to configure your mail manually. have you been able to get that far?
This is how I would configure the whole thing.
Let's say that your email address is [email protected]
If you have port 443 open on your completely unrelated example.com web site, make sure that whatever web server handles your web site returns 404 for the URL /Autodiscover/Autodiscover.xml
This tells the Exchange clients to go away.
Prevents email clients from being hijacked by your web site.
Make sure that you DO NOT have any A or CNAME or whatever DNS records for autodiscover.example.com
This also tells the Exchange clients to go away.
Instead, they will use the proper RFC method of discovering service endpoints, see next bullet.
(I know that this is contrary to other advice offered in this thread; I just wanted to offer you this alternate method of configuring AutoDiscover!)
Create a DNS SRV record for "_autodiscover._tcp.example.com", it should contain "exchange.example.com".
This tells the Exchange clients to connect to https://exchange.example.com/ for autodiscover.
(The reason that we call the hostname exchange and not autodiscover will be apparent in the next bullet.)
Configure your Exchange servers so that all services (address book, email, calendar, whatever) resides on the IIS site and virtual host "exchange.example.com".
This lets you configure everything to run on just a single SSL certificate, instead of having to cash out for SAN certificates.
Create an SSL certificate for https://exchange.example.com/
(Use any certificate authority you like.)
Install the SSL certificate onto the Exchange IIS service.
Make sure that exchange.example.com has an A or CNAME record in DNS that points to the IP address of the Exchange IIS service.
That should just about do it.
It's a bit convoluted, and that is because Exchange clients try a whole lot of hardcoded, dumb places to find the autodiscover service before doing the proper thing and ask for a DNS SRV record. Those holes have to be plugged, or else the client will at some point be inadvertently hijacked by unrelated services such as your website.