Discover Autodiscover!

One of the most frequent mistakes that we see developers who are using Exchange Web Services make is the hard-coding of the URL for the ExchangeServiceBinding to a specific location. Hard-coding the URL is not recommended, especially given that Exchange Web Services provides a mechanism for avoiding this: Autodiscover. Autodiscover ensures that your client is always returned the most efficient URL to use for a given mailbox. Are you wondering why we don’t recommend hard-coding the URL? Let me count the ways!

1. The hard-coded URL might point to the URL of a Client Access server that is in a different site from the user’s mailbox. Accessing a Client Access server in a different site from a user’s mailbox results in poorer performance and greater complexity than accessing a Client Access server in the same site as the mailbox. The only way to ensure that you are accessing a Client Access server in a particular user’s site is to use Autodiscover.

2. We may change the URL for various Web services as we consolidate them, or break them up for better architecture between roles, which will complicate migration to later versions of Microsoft Exchange Server.

3. The corporate address could change namespaces (this doesn’t happen often, but we have occasionally changed our namespace at Microsoft). For example, https://mail.contoso.com could become https://portal.contoso.com.

Let me explain a little more about why accessing a Client Access server in a different site from a user’s mailbox is not a good idea. If your enterprise has multiple Active Directory sites (i.e. branch offices that are running Exchange Server 2007), Exchange Web Services in the initial release version of Exchange 2007 will be making cross-site remote procedure calls (RPCs) from the Client Access server that you are accessing to the mailbox in the site where a user is located. Cross-site RPCs are not recommended because RPC traffic is very chatty and high latency networks between sites will degrade the performance of Exchange Web Services significantly. In Exchange 2007 Service Pack 1 (SP1), we have gone the route of Outlook Web Access and ActiveSync and disabled cross-site RPC functionality. Now cross-site calls will fail unless an Exchange 2007 SP1 Client Access server is in the same site as the user mailbox that is set up for EWS proxy. EWS proxy makes these requests more efficient by sending a single HTTP request rather than multiple RPC requests. However, relying on EWS proxy to do the work of getting your request to the right site is also not an ideal solution because it puts unnecessary load on the proxying Client Access server. You can avoid this unnecessary load by making the request to the appropriate Client Access server yourself.

We have some good resources about using Autodiscover. For a sample application that includes downloadable source code that implements an Autodiscover client for you, see Autodiscover Sample Application. For information about the structure of an Autodiscover request, see Autodiscover Request.

One thing to note: Autodiscover is not a SOAP-based Web service. It just uses plain old XML (POX).

Look for more information that describes Autodiscover in more depth soon. Until then, use the examples referenced earlier and always Autodiscover.

Comments

• Anonymous
  December 15, 2007
  PingBack from http://www.ditii.com/2007/12/15/exchange-server-2007-autodiscover-url/

• Anonymous
  December 15, 2007
  Exchange Admin 101: Exchange 2003 and Exchange 2007 admin privileges Troubleshooting Exchange Global

• Anonymous
  February 12, 2011
  With Exchange Server 2010, Auto Discover service is being supported as POX or SOAP service. However Exchange Server supports only POX service. How do we identify which service (POX or SOAP) should be used for auto discovery of Exchange Server settings. Is there a way to find the version of Exchange Server or API applicable for email address? Your help is greatly appreciated.