Exchange 2010 Autodiscovery Issues

Two weeks ago a build my first production cluster. The 2010 web services are causing a lot of to people, and my self not any more.

Well, let us first list the directories that are used in the Exchange web service:

EWS is used for OOF, Scheduling assistance and +busy Lookup.
OAB provides offline address book download services for client.
Autodiscover is used to provide users with autodiscover service.
EAS provides services to based devices.
provides outlook web access for users.
ECP provides Exchange control panel feature for Exchange 2010 users only.

Issues that might be resolved using the troubleshooting steps here:

You cannot set the OOF using outlook client, you receive the not available error.
You cannot view free/busy information for other users.
You cannot use scheduling assistance, also you might receive not free/busy information data retrieved.
You cannot download Offline Address book errors.
You cannot use autodiscover externally.
Certificate mismatch error in autodiscover, users prompted to trust certificate in /2010.

First let us start by settings the right virtual directory configuration required for Exchange 2010 to work correctly:
Configure External and Internal URLs for OWS, ref:

You have to configure the internal URL to be the server name. In case you have multiple cas/hub servers configured in a NLB then can use the nlb cluster name for the internal url. 
External URL will be the URL used by users to access webmail e.g. 

Configure the autodiscover internal URL, ref:

If you cannot use autodiscover. internally (you have a domain name of domain.local and you must use it), you will get a certificate miss match error, you will have to include the internal name in the SAN certificate if you purchase an external SAN certificate. 

You cannot set autodiscover external URL since outlook will try to access, this behavior is by design and cannot be changed.

Best Practice: Use SAN Certificates

Depending on how you configure the service names in your Exchange , your Exchange server may require a certificate that can represent multiple domain names. Although a wildcard certificate, such as one for *, can resolve this problem, many customers are uncomfortable with the security implications of maintaining a certificate that can be used for any sub-domain. A more secure alternative is to list each of the required domains as SANs in the certificate. By default, this approach is used when certificate requests are generated by Exchange.

Best Practice: Use the Exchange Certificate Wizard to Request Certificates

There are many services in Exchange that use certificates. A error when requesting certificates is to make the request without including the correct set of service names. The certificate request wizard in the Exchange Management Console will help you include the correct list of names in the certificate request. The wizard lets you specify which services the certificate has to work with and, based on the services selected, includes the names that you must have in the certificate so that it can be used with those services. Run the certificate wizard when you've deployed your initial set of Exchange 2010 servers and determined which host names to use for the different services for your deployment.

Which Names you must include when you use a third party SAN certificate, ref
External: (If you migrating from 2003 to 2010)
nlbek10.wardvissers.local(Internal NLB CAS/HUB Cluster)
casarray.wardvissers.local(I use this address for the casarray. It has the same ip as the nlbek10)

Leave a Reply

Translate »