Friday, July 9, 2010

Exchange 20xx: Autodiscover and availability Issues




You receive the message: Allow this website to configure server settings?
You test e-mail autoconfiguration and it fails for no apparent reason.












The reason you receive the above error message is because the autodiscover website has been configured to redirect to a different website. For example, you might want to use https://webmail.domain.com/autodiscover/autodiscover.xml as your autodiscover URL. In this case you would redirect http://autodiscover.domain.com/ to that URL.

You may also receive this message if your autodiscover SSL website is not working correctly and fails. In this case, it will try http:// instead of https://. If you happen to have http:// redirected to https:// then you will also receive this message as this counts as a redirect.

You should be able to click the "Dont ask me about this website again" to make the message disappear for good.

Troubleshooting autodiscover messages:

  • Use testexchangeconnectivity.com. It is there to help you find out if problems exist in Exchange client access from the Internet.
  • If the user's primary email address is @domain1.com then is there an autodiscover record configured for this domain (either via an autodiscover website, redirection website, or a SRV record)
  • Check the version of Outlook being used. If it is Outlook 2007 SP1 or RTM then the first thing to do is to update to Outlook 2007 SP2. This can fix a number of issues and also fixes an issue where the e-mail autoconfiguration autodiscover test errors out with 0x8004005 immediately after a line where it appears to succeed (returns a 500 response).
  • Check whether the workstation is joined to the domain. This can determine the status of password storage and determine how you go about troubleshooting this issue.
  • Check the user account credentials stored in the Windows profile. If credentials are stored for Exchange and yet the password has been updated since, you may get a series of password prompts and possibly autodiscover prompts appearing. In Windows XP you can access this by typing UserControl2 into the Start-->Run dialog box.

Using multiple email domains can affect autodiscover
Another issue that can occur with autodiscover is if your organisation uses different email domains. If autodiscover is configured on http://domain.com/ and the email address for the user is @anotherdomain.com then autodiscover will not be resolved. You might want to create SRV records for these domains to redirect users to the autodiscover website.

Authentication on web services and autodiscover virtual directories can affect autodiscover

Another issue that may occur if autodiscover is receiving errors (0x8004005) and Out of Office is returning an error "the server is unavailable". This may be because Windows Authentication may not be enabled on the web services:

get-webservicesvirtualdirectory | Set-WebServicesVirtualDirectory -WindowsAuthentication:$true

How Autodiscover works

A client attempts to connect to the SCP to get an autodiscover URL. If the client is not domain-connected then this will fail.

A client attempts to connect to domain.com and autodiscover.domain.com based on the user's primary SMTP address. It tries https first and then http.

See http://technet.microsoft.com/en-us/library/bb124251.aspx for a more detailed description.

Basic troubleshooting steps

When auto-discover stops working, you may find that your Out-Of-Office and Free/Busy (availability) stop working too.

Start the Outlook client. Hold CTRL and right click the OL icon in the system tray. Select Test Email Auto-configuration. Enter the email address and password. Select "Use Autodiscover" but deselect all the Guessmart checkboxes. Click Test. On the XML tab, ensure it is connecting to the correct autodiscover URL. You may receive one of the following errors as defined by Microsoft.

0x80072EE7 – ERROR_INTERNET_NAME_NOT_RESOLVED
This error is usually caused by a missing host record for the Autodiscover service in the Domain Naming service.

0X80072F17 – ERROR_INTERNET_SEC_CERT_ERRORS
This error is usually caused by an incorrect certificate configuration on the Exchange 2007 computer that has the Client Access server role installed.

0X80072EFD – ERROR_INTERNET_CANNOT_CONNECT
This error is usually caused by issues that are related to Domain Naming service.

0X800C820A – E_AC_NO_SUPPORTED_SCHEMES
This error is usually caused by incorrect security settings in Outlook 2007.

- If this is a workstation connected to the domain and able to reach Active Directory, ensure it gets a URL from the SCP in Active Directory and is able to connect to it. If it retrieves a URL but fails in using it, check that the URL can be accessed by pasting it into an Internet Explorer window. It may be that TMG or the proxy is blocking access to that server. The resolution in this case may be to add the URL to the proxy exceptions list.

- If this is a workstation that is not domain-connected, check that the correct URL is returned. If not, it has not been configured correctly as the external URL on the internet facing CAS server(s). If the URL is correct then try to paste the auto-discover URL into Internet Explorer and see if the autodiscover XML pops up.

- If you have an issue with seeing free/busy data for other users then try to enable logging in Outlook 2007 > Tools > Options > Other > Advanced Options > Select Enable logging (troubleshooting) > OK > Restart Outlook > Try to view free / busy information for another user > Go to the %temp% folder and open olkdisc.log file and locate the files in the olkas directory. These files can often provide information about which service is not functioning correctly.






- If you have an issue with seeing free/busy data for other users then review the event log for event id's: 4001, 4003, 4005, and 4011. Possible solutions for these errors are contained at http://technet.microsoft.com/en-us/library/bb397225(EXCHG.80).aspx

- Use the test-OutlookWebServices cmdlet to troubleshoot the availability service. For example, Test-OutlookWebServices -id:user1@mydomain.com -TargetAddress: user2@mydomain.com

- If you have an issue with seeing free/busy data for other users then check if there are any cross-forest timeout issues. Details are contained in the URL http://technet.microsoft.com/en-us/library/bb397225(EXCHG.80).aspx

- Check the SCP point in Active Directory Sites and Services by enabling the "View Services Node" option. It is under Services > Microsoft Exchange > Org Name > Administrative Groups > Admin Group Name > Servers > Server Name > Protocols > Autodiscover. These SCP points can be administered using the Set-ClientAccessServer cmdlet.

- If the issue is with external users, then use the website http://www.testexchangeconnectivity.com/ to check that your configuration is correct.

- If you have issues and you are using multiple SMTP namespaces then you will want to check out http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/exchange-autodiscover.html

- Check that IIS is started on all servers

- Check that the OWA application pool, OAB application pool, and EWS application pool are all running and started with no errors.

- If you receive an authentication error (such as 500 service not availabile or 400 login time-out) then you may need to rebuild the virtual directories.

Verify Configuration
Ensure you have configured the following: -
- Configure your internal URLs for all virtual directories. These should be automatically configured as the server name. Configure external URLS only on your Internet facing CAS servers. See http://technet.microsoft.com/en-us/library/bb691323(EXCHG.80).aspx for details on how to do this. The external URL will either be the name of a CAS server or an NLB that is sitting in front of a number of CAS servers.
- Configure certificates on each Exchange servers and TMG servers as required. These should be trusted by clients.
- Add all Exchange CAS servers to a proxy exceptions list - generally either using WPAD or Group Policy.

2 comments: