Freigeben über

Exchange Wiki - Post on Free/Busy and AutoDiscover

  • Artikel

Need help troubleshooting Outlook 2007 / Exchange 2007 "AutoDiscover" and free/busy features?

We've started to populate the Exchange Wiki (https://www.exchangeninjas.com/) with some Exchange 2007 related information. 

A PM on my team posted instructions on understanding and debugging Outlook's use of web services in E2k7.  https://www.exchangeninjas.com/AvailabilityServiceFAQ.  Its a good start and has some information that is not in current versions of the "official" documentation.

Some background --

Many moons ago when we began the process for planning Exchange 2007, we had a goal of reducing TCO for Exchange (well, this is really a perpetual goal).  In our investigations, we discovered that the top corporate helpdesk expense -- in supporting Outlook & Exchange -- was helping users to configure their Outlook profiles.  Even I, as a member of the Exchange team, have had to call the helpdesk before in order to configure Outlook Anywhere (RPC over HTTP) -- because I just didn't know the server name.

Out of this was born the idea of creating an "AutoDiscover" service -- a way for Outlook users to get automatically connected without having to manually type in a bunch of server settings.  The approach was chosen of having clients connect to autodiscover.[my email domain].[tld] in order to retreive an XML file containing their profile settings.  All the end user would have to know was their email address and password -- pure simplicity.  In addition to the mailbox server, this mechanism was also used to help Outlook "discover" other new Exchange 2007 services that it could connect to -- including our new free/busy, new OOF assistant, Unified Messaging settings and the Offline Address Book.

While this approach of using  autodiscover.[my email domain].[tld] was reasonable for Outlook clients connecting from the Internet, we soon discovered it wouldn't work from within many corporate environments -- a good percentage of which do not enable Outlook access from the Internet anyway using RPC/HTTP.  Furthermore, there was a poor "out of the box" experience -- if you installed Exchange, and then installed Outlook 2007 -- it didn't "just work" -- you had to fiddle with DNS and certificates instead.  Sometimes, the people configuring Exchange didn't even have access to the corporate DNS to make the necessary changes to create autodiscover.[my email domain].[tld].

We needed a solution that balanced the necessary security when connecting over the Internet with the simple out-of-the-box experience that most locally-connected, domain-joined users should have. 

Exchange had a plan of automatically generating and installing self-signed SSL certificates when it was installed.  Although these certificates cannot be fully 'trusted', the traffic to those servers is then automatically encrypted -- which is certainly better than nothing at all. 

The conflict was -- when connecting over the Internet, we knew that autodiscover. [my email domain].[tld] should require a valid, trusted SSL certificate -- or else it could be spoofed, and you could accidentally try to authenticate against a bad, bad server and get bogus server settings.  Because we had these self-signed certificates, Outlook would not connect at all to Exchange without installing the certificate on the client machine or setting a regkey that would cause Outlook not to use SSL.  While this could be viewed as a security 'feature' when connecting in over the Internet, it was a real pain when you were inside the corporate network and just trying to get your brand new Outlook 2007 client to work properly with Exchange 2007. 

The fix....

Luckily a smart PM lead (not me) dug around and came up with a solution using a capability of the Active Directory (AD) that we hadn't realized existed -- something called a Service Connection Point. (SCP).  This was specifically created to help client applications locate particular services within an AD forest. 

The decision was then made to use this SCP thing to help Outlook find an AutoDiscover server without having to use autodiscover. [my email domain].[tld].   IfOutlook was on a client machine that was part of an AD forest, and it could contact a Domain Controller -- it would do an LDAP query to find an SCP for Exchange AutoDiscover and then use that URL to connect.  In this case, because we definitively know that Outlook is running on the corporate network, Outlook would ignore SSL certificate errors when trying to connect to Exchange web services. 

If Outlook was unable to contact a domain controller, it would fall back to trying to connect directly to autodiscover. [my email domain].[tld] -- the method that does require DNS configuration.  In this case, valid & trusted SSL certificates are required to prevent any sort of server-spoofing on the Internet.

Still having problems?

The scheme described above made it into Exchange 2007 Beta 2 but was too late for Outlook 2007 Beta 2 -- so you won't see a great out-of-the-box experience with Outlook 2007 Beta 2 until the "Technical Refresh" of Beta 2 is published.  But when it is, you should try the two out together and let me know if this seems to fix the issues for you.

And hopefully, some of the information here (https://www.exchangeninjas.com/AvailabilityServiceFAQ) can help you get going in the right direction.

Comments