AutoDiscover Configuration for Exchange 2007 and 2010:
Overview
The AutoDiscover feature in Exchange 2007/2010 is often overlooked during setup but is an important factor in ensuring smooth day to day running of your Exchange environment. Its main function is to provide the mail client with all the configuration options it needs, from only the user's email address and password. This is particularly useful for remote users and smartphone users, who no longer have to enter advanced settings like server names and domains. It is also vital for the correct functioning of features such as Out Of Office and the Offline Address Book in Outlook.
Comprehensive Configuration & Change ManagementSolarWinds Network Configuration Manager (NCM) delivers affordable, easy-to-use network configuration management through a full featured, rich web-based console that offers point-and-click simplicity and easy access to configuration data.
Learn More or Download a FREE, Fully-Functional 30-day Trial
SolarWinds NCM simplifies managing network configuration files in multi-vendor network environments by continuously monitoring device configurations and providing immediate notification of configuration changes to help resolve problems before they impact users. Start backing up and tracking your network configs in less than an hour!AutoDiscover simplifies email client configuration for remote and mobile users; you may not have noticed it but most email clients nowadays will simply ask for your email address and password first, e.g. the Android email setup screen:
What actually happens after you have entered your details is that the client looks for autodiscover.yourdomain.com and attempts to retrieve the rest of the server configuration details from there. If you've set that up properly then no more information is required, making the setup process very simple for non IT-literate users and saving you from having to deal with support calls.
The second main function of AutoDiscover in Exchange is linked to the Offline Address Book and "Out of Office" settings, as Outlook uses part of Outlook Web Access for them, rather than the MAPI based connections used for mailbox access. The Outlook client actually uses the AutoDiscover address to retrieve the Exchange Server details for these, so if it is incorrectly configured you may find these features don't work, even though everything else does.
Why is AutoDiscover Important?
The Exchange setup process doesn't mention AutoDiscover, and the official Microsoft documentation doesn't really stress the importance of it either, so it can easily pass you by. As part of the general OWA setup the Exchange installer creates an AutoDiscover folder and adds the internal URL to the Exchange configuration, so if your network consists of a single site with local desktops then it should work fine for you.
However, if you want easy email setup for mobile and remote users, or if your users are unable to set Out of Office via Outlook but it works in OWA, then you may well need to check your AutoDiscover configuration.
How to Check Your AutoDiscover Configuration
There are two tests you need to run to check that you have your AutoDiscover configuration correct, one from outside your network and one from inside. The outside test is probably the easiest so let's do that first. Open www.testexchangeconnectivity.com in your browser. By the way, if you haven't encountered this website before then add it to your Bookmarks; it's an exceptionally useful tool for various Exchange diagnostics. It's provided by Microsoft so it should be safe to trust with confidential information, but make sure you check the site's SSL certificate first to make sure you are at the correct one!
You will notice that there are two AutoDiscover tests listed, one for ActiveSync and one for Outlook, but in fact for this test we are only really interested in the AutoDiscover part which is the same for both. All the same, you may as well select the one which is more relevant for you now and click Next, then on the next page fill out the information requested. You don't have to enter a valid user account and credentials but if you do then it can test the process all the way through, so I would recommend it. You will also see there is a check box for Ignore Trust for SSL; for the moment it's easiest to tick this, we'll cover certificates later. Once you have done that and worked out the validation code you can click Perform Test and wait for the results page.
Chances are you will see a results page like the one above, which doesn't tell you much, so click on Expand All for more details. You will see that it has run a whole bunch of DNS lookups and tests, no doubt most of them have failed but don't worry about it too much for now as we will go through how to configure it shortly.
To test your AutoDiscover from inside your network the easiest way is to use a copy of Outlook 2007 or 2010 that is already setup and connected to your Exchange Server. Look down in the SysTray by the clock and locate the Outlook icon there, then hold down the Ctrl key and right-click it for the extended menu -- you will see that Test Outlook AutoConfiguration is an option so click that.
In the window that opens, your email address should already be entered so just add your password and make sure that only the Use AutoDiscover box is ticked, then click Test. The Results box should fill up with a bunch of text, look closer and you will see that it is split into two sections: Exchange RPC and Exchange HTTP, each with URLs for things like OOF (Out Of Office) and OAB (Offline Address Book). It should go without saying that these URLs should be resolvable from your internal network clients, or else you will have a problem!
Dealing with Common AutoDiscover Problems
There are usually just two common causes for AutoDiscover to not work, and the tests above will show clearly if you are suffering from one of them. The first problem is DNS resolution; either you do not have a DNS A record setup for autodiscover.yourdomain.com or it is resolving to the wrong address. Note that there are two different DNS resolutions involved here: the public DNS for external clients and the internal DNS for your network clients. If the Microsoft Remote Connectivity Analyzer website is showing a DNS resolution failure then it is referring to your public domain DNS record, which you probably have hosted at the same provider as you purchased your domain from, or another third party DNS service. The easiest way to check the public DNS record is using a website such as www.kloth.net/services/nslookup.php -- here I am checking for the Petri.co.il A record:
If you have completely forgotten where your domain DNS is hosted then you can also use this site to find out -- just put in your domain name by itself and select "NS (Nameservers)" as your query:
The nameserver query will tell you the domain name of the DNS hosting service, and from that you should be able to get access to your DNS management with a little effort. Different DNS services have variations in their management interfaces but the basic principles are the same; you will need to create or edit the A record for autodiscover.yourdomain.com so that it points to the public IP address of your Exchange Server. You may need to wait a few hours for the change to propagate but then when you run the MS Connectivity test again it should report a successful resolution of the AutoDiscover address.
For your internal network clients fixing the DNS resolution should be even easier, as you will have your own internal DNS server, so you just need to open up the management console for that and add in the appropriate A record to resolve to the internal address of your Exchange Server. Once you have changed it you can try the Outlook Email AutoConfiguration test again, however make sure the DNS cache on your local machine is updated first, either by simply rebooting it or running ipconfig /flushdns from a command prompt.
The remaining two problems you may encounter will only affect external clients, but usually those are the ones you want to make things easiest for, as you won't be there to assist them most of the time. You need to make sure that your Exchange Server is accessible for https on port 443 by configuring your firewall appropriately, although if you already have Outlook Web Access working for external users then you will have done this step already.
The next error you may encounter from the MS RCA website is common enough that it deserves its own section.
Solving Problems with Your SSL Certificate
Often the main problem with your SSL certificate is that the name does not match. This usually occurs if you are using a self-generated certificate, or have purchased a basic single name certificate for OWA access, which might have a name like webmail.yourdomain.com. Now you can decide to just ignore this, if you only have a few users to worry about then you may well feel that the additional expense of a new certificate is not worth it. However an increasing number of mobile devices and mail clients will refuse to accept an unverified certificate nowadays, which is a sensible security measure, however it means you have to install your CA (Certification Authority) server certificate manually which can be a pain and defeats the purpose of AutoDiscover in the first place. The solution Microsoft recommends is to purchase a SAN (Subject Alternative Name) certificate, which allows you to register several DNS names on one certificate. Nowadays there are some certificate vendors who offer very cheap or even free certificates, but personally I prefer to stick with the well known trusted CAs like Digicert, who also have useful installation guides and utilities on their website.
For internal network clients, provided they are domain members, the SSL certificate should not be an issue as they will automatically trust your internal CA if you have self-signed. The only occasion it may be an issue is if you have installed a certificate for your public domain name (e.g. yourdomain.com) but you have a different internal domain name (e.g. yourdomain.local). In this situation the easiest solution is to change the internal AutoDiscover URLs to match your public domain name, and ensure you have the correct A records in your internal DNS -- resolving to the internal IP of your Exchange Server. In Exchange 2007 this requires a few PowerShell commands, rather than repeat them all here, the process has been well described in this MSExchange.org article. In Exchange 2010 the process is a little different but again has been covered in another MSExchange.org article.
Completing Your AutoDiscover Configuration
Once you have worked your way through the above steps you should be able to successfully test your AutoDiscover configuration both externally and internally. If you had experienced problems with your Offline Address Book in Outlook before, or users could only set their Out of Office by using OWA then you should find that these problems have been solved as well. The best part though is how easy it becomes to set up new mail clients and smartphones, in fact most users should be able to do it themselves now without having to seek your assistance!
(Via Petri IT Knowledgebase)
1 comment:
It's really informative resource about SSL certificate in concern of Configuration for Exchange 2007 and 2010.
Thank you so much for sharing this article.
WildCard SSL | EV SSL | Code Signing Certificate
Post a Comment