Updating busy information greyed out
Finally, assuming that a valid redirect has been setup to allow the client to reach the Auto Discover/Availability Service (more on this below), a dialog box such as this will eventually appear: If the user hits “Cancel” to dismiss this dialog box, the free/busy info will not appear.
Hitting the “Allow” button will promptly cause free/busy to work for the remainder of that Outlook session.
Once Outlook 2007 retrieves the correct Auto Discover URL and is able to query it, all is well. Ideally, this would be implemented by using a Subject Alternative Name certificate on the CAS roles (front-end client access servers) which provides a valid cert for both blah and blah, then setting up a CNAME entry in DNA to point https://autodiscover./Autodiscover/.
The problem is that it can take a while to get to that point because of the successive times as each mechanism for guessing the Autodiscover URL fails. This approach is described here and would negate the appearance of the dialog box described above since the correct Auto Discover URL would be found on step 3 rather than step 4 (and the process would be slightly faster, since there would be one less timeout involved). Now, when step 4 listed above is attempted by the client, the following sequence of events takes place: 1) DNS resolves to an IP address on our Netscaler load-balancing appliances.
Allthough the diagnostics (Ex RCA etc) say that your configuration is right, vital configuration is not yet effective.
RESOLUTION First step in resolving Free/busy errors is to follow the two steps mentioned in the Introduction to this post (Ex RCA diagnostics and following KB2555008 – see above).
Unfortunately, this is a common situation for many departments in our environment. When the Outlook 2007 client tries to access free/busy info from a workstation that is not bound to the domain, the free/busy fields will remain grayed-out for several minutes as the client tries and fails to invoke multiple paths to get to the data, with each attempt eventually timing out.
5) If each of the previous methods have failed, and if the Outlook 2007 client is equipped with the update rollup described in KB940881, then the client will finally check DNS for an SRV record of the form _autodiscover._tcp..
(In our environment, we have recently put this SRV record in place, although the client never reaches this as long as the redirect is in place).
If that does not work: Doing on your CAS server publishing EWS/Hybrid could fix this issue.
Plan for a very short outage in Exchange services (OWA/EWS etc) and open the command prompt on your Hybrid CAS server.