Outlook Anywhere Repeatedly Prompting for Credentials

Two days ago it came to my attention that some Outlook Anywhere (OA) users were getting prompted for their credentials constantly. Talked to some of them and said that a workaround was to go to the connection settings and unselect the “Only connect to proxy servers that have this principal name in their certificate” box and restart Outlook:




Another problem was that after a while (no one could tell me exactly how much time that was) that box got selected again and the same problem happened.

After some investigation regarding Outlook Anywhere and the Autodiscover service I found what the problem was.
First, some information:


The Autodiscover Service and Outlook Providers
The Autodiscover service makes it easier to configure Outlook 2007. Earlier versions of Exchange and Outlook required you to configure all user profiles manually to access Exchange. The Autodiscover service uses a user's e-mail address or domain account to automatically configure a user's profile. By using this information the Autodiscover service provides the following information to the client:
· The user’s display name;
· Separate connection settings for internal and external connectivity;
· The location of the user’s Mailbox server;
· The URLs for various Outlook features that govern such functionality as free/busy information, Unified Messaging, and the offline address book;
· Outlook Anywhere server settings.

When a user's Exchange information is changed, Outlook automatically reconfigures the user's profile by using the Autodiscover service. For example, if a user's mailbox is moved or the client is unable to connect to the user's mailbox or to available Exchange features, Outlook will contact the Autodiscover service and automatically update the user's profile to have the information that is required to connect to the mailbox and Exchange features.

To allow Autodiscover to function completely there is an important component in Exchange 2007 named Providers. Providers are components that are specifically related to the type of client that is trying to connect and be configured. When the Client Access Server role is installed, by default three providers are created: EXCH, EXPR and WEB.

When creating or refreshing an Outlook 2007 profile a request is placed to the Autodiscover service; the service determines which provider needs to handle the request. The XML request contains the necessary information for this to happen, such as the SMTP address and which client (MAPI client or Outlook Anywhere) made the request so the Autodiscover service can easily identify the provider the request needs to be forwarded to.


By default three Outlook Providers are used to configure settings individually for Exchange RPC protocol or internal clients (EXCH), Outlook Anywhere (EXPR) and WEB.
- The EXCH setting references the Exchange RPC protocol that is used internally. This setting includes port settings and the internal URLs for the Exchange services that you have enabled.
- The EXPR setting references the Exchange HTTP protocol that is used by Outlook Anywhere. This setting includes the external URLs for the Exchange services that you have enabled, which are used by clients that access Exchange from the Internet.
- The WEB setting contains the best URL for Outlook Web Access for the user to use. This setting is not in use.


Resolution
Without going into much detail on how this works, here’s how this was causing the problems:

When issuing the command Get-OutlookProvider EXPR FL I was getting the following information (just displaying the important parts):

CertPrincipalName:
Server:
TTL: 1


Our ExternalHostname, for Outlook Web Access, is owa.letsexchange.com (fake name of course) but the certificate for that website was issued to letsexchange.com

When the CertPrincipalName parameter for OutlookProvider is not configured, Outlook uses the ExternalHostname parameter for OA to populate the server name listed after “msstd:” in the “Only connect to proxy servers that have this principal name in their certificate” profile setting, so it was as msstd:owa.letsexchange.com, which did not match the “Issued To” Name on the certificate, and users were being prompted for credential repeatedly! When users unselected this box, the principal name on the certificate didn’t get checked so Outlook was working fine. Once this box got ticked, it would fail.

So I had two choices, find away to prevent that box from being ticked or to put the correct information on it. At his time, I realized that OA with Autodiscover wasn’t working externally because of this! Users had to manually configure OA, but once it was working, Outlook would eventually download the configuration for it and mess it up.

So, the option was to make it right. How to do this? Issue the correct certificate or simply change the CertPrincipalName to provide the correct information to Outlook. I opted for the second option by issuing the following command:

Set-OutlookProvider EXPR –CertPrincipalName “msstd:letsexchange.com”

Now, Outlook receives the correct information for OA and OA with the Autodiscover service is working perfectly!

Exchange Availability Service

For some Exchange Administrators, the Availability service is still a mystery or, at least, not quite well understood. So, let’s talk more about this new feature on Exchange 2007.

Basically, this service provides free and busy (f/b) information about Outlook 2007 users, used to determine users’ availability when scheduling meetings, in an up-to-date, reliable and secure way. Outlook obtains the URL of the Availability service by using the AutoDiscover service (maybe discussed in a future post!) which is responsible for providing to the client his display name, the location of his mailbox, the Outlook Anywhere server settings and the URLs for f/b information, Unified Messaging and the Offline Address Book (OAB).

Let’s go back a couple of years...In Exchange 2000 and 2003, and with clients older than Outlook 2007, a special public folder is used to store users' calendar f/b information. This folder is named SCHEDULE+ FREE BUSY and contains several subfolders for each administrative group.

Figure 1: The SCHEDULE+ FREE BUSY System Folder on Exchange Server 2003

What Outlook does is periodically publishing the calendar f/b information into this folder which then allows other users to query this information when scheduling a meeting. However, imagine a corruption on the public folder database, or how often the replication can cause a lag between the time a user updates his calendar and when the f/b information becomes available, giving origin to out-of-date f/b information.


Back to the present...
Besides providing Outlook Anywhere, Outlook Web Access, Active Sync and other non-MAPI forms of connectivity, the Client Access Server (CAS) also provides two very important and vital services for an Exchange 2007 infrastructure: the AutoDiscover and the Availability Web Services
With Exchange 2007, the f/b information is now obtained directly from the target mailbox rather than from the SCHEDULE+ FREE BUSY system folder. This is how f/b information is now retrieved in real-time.

Note: since this is a new functionality, Outlook 2007 clients running on Exchange Server 2003 mailboxes will use public folders for the f/b information. The same thing happens with the OAB distribution.


How does it work?
1. By using AutoDiscover, Outlook establishes a connection to the CAS server running the Availability service
2. The CAS server determines on which mailbox server the target mailbox is
3. The CAS server communicates with the mailbox server (via MAPI) and obtain the f/b information
4. The results are then returned back to the user

Scenario 1
In this case, both servers are in the same Active Directory (AD) site. If they were on different ones, the CAS server would make an HTTPS connection to the target CAS server located on the AD site of the target user which would obtain and return the information back to the original CAS server and then to the user.

Scenario 2
If the target user has his mailbox on a Exchange 2003 server, situation very common during migrations, the Availability service will have to obtain the f/b information from the SCHEDULE+ FREE BUSY system folder by making an HTTPS request to the /Public virtual directory on the mailbox server hosting that folder.

Scenario 3
What if the user was running Outlook 2003 for example? Well, in this case it doesn’t matter on which server, 2003 or 2007, the target mailbox is because Outlook 2003 will always attempt to gather and publish the f/b information from/to the SCHEDULE+ FREE BUSY system folder. How could it use the Availability service if it is a new functionality?

Scenario 4
What about when using Outlook Web Access (OWA)? In this situation, OWA works just like Outlook would.


Calendar Information
The Availability service also enables users to share their calendar information in a more granular way. For each target user/group, the user can choose one of four levels of sharing:
· Share nothing
· Share their Free-Busy information
· Share a little more detail including subject, location and timing
· Full calendar details.

Figure 2: Calendar Sharing Properties

Distribution Groups
While on previous versions of Exchange, the expansion of Distribution Groups (DGs) was made by a Global Catalog, now it is made by Exchange 2007. This allows the Availability service to provide consistent behavior for any Availability service user when expanding a DG. On Exchange 2003, for example, if the number of distribution group members was too large, the f/b data for the distribution group members would display as busy when expanded.



Configuring the Availability service
As I said before, it is crucial that the AutoDiscover service be configured for Outlook 2007 clients as it’s this service the responsible for allowing users to locate the Availability service. Most of its configuration is done automatically in a single-forest environment with no external Outlook access configured. However there are three situations where further configuration is necessary:
1. To provide external access to Exchange Web Services, like Outlook Anywhere
2. To access f/b data in a cross-forest topology
3. To access the Availability service when a Network Load Balancing array of CAS servers is in place

Since this post is already getting too big, I’m just going to give a simple example of how to do this when you are using NLB for your CAS servers without going into much detail:

1. In the Exchange Management Shell use the Get-WebServicesVirtualDirectory to check the ExternalURL in use, for example: Get-WebServicesVirtualDirectory –Identity “«CAS_Server»\EWS (Default Web Site)”
2. If necessary, modify this external URL using the Set-WebServicesVirtualDirectory cmdlet, for example: Get-WebServicesVirtualDirectory Set-WebServicesVirtualDirectory –ExternalUrl “https://«fully_qualified_domain_name»/EWS/Exchange.asmx” where «fully_qualified_domain_name» is the externally accessible DNS hostname of the CAS computer

Note that this cmdlet is also used to set the –InternalUrl parameter for a NLB cluster.



Troubleshooting the Availability service
If Outlook 2007 users can’t view calendar information for other Outlook 2007 users the problem might be a failure in either the Availability or the AutoDiscover service. So, my suggestion is to first take a look at the latter.

First, let’s see if the AutoDiscover service is unable to provide information to the clients by using Outlook 2007.
1. In Outlook 2007, log on to the mailbox of the user for whom you want to troubleshoot
2. On the Tools menu, click Options, click the Other tab, and then click Advanced Options
3. On the Advanced Options page, select Enable logging (troubleshooting), and then click OK
4. Restart Outlook and then try to view free/busy information for another user
5. Click Start, Run, and then type %temp%
6. In Windows Explorer, open the olkdisc.log file and locate the files in the olkas directory
7. The information that is contained in this directory can frequently provide information about which service is not functioning correctly

Secondly, let’s use Outlook 2007 to test the AutoConfiguration information that the AutoDiscover service provides. To test this, and while Outlook is running:
1. Hold down the CTRL key, right-click the Outlook icon in the notification area, and then select Test E-mail AutoConfiguration
2. Verify that the correct e-mail address is in the box next to E-mail Address
3. Clear the check boxes next to Use Guessmart and Secure Guessmart Authentication
4. On the Test E-mail AutoConfiguration page, verify that the check box next to Use AutoDiscover is selected, and then click the Test button

Take a look at the Results and Log tabs and check the information there for possible errors.

This was on the client side. On Exchange, there are also two ways to determine whether the Availability service is not functioning correctly.
The first one is by using the Application Event Log on the CAS server to check for events that are generated by the Availability service. For example, the events 4001, 4003, 4005 and 4011 or every event with an event source of “MSExchange Availability”.
The other way is to use the Test-OutlookWebServices cmdlet in the Exchange Management Shell to determine whether the Availability service is functioning correctly.

To diagnose the Availability service issues for an individual user:
Test-OutlookWebServices –Identity n.mota@letsexchange.com

To diagnose the Availability service issues for a CAS server:
Test-OutlookWebServices -ClientAccessServer EXCAS1

To diagnose the Availability service issues across different sites:
Test-OutlookWebServices -Identity n.mota@site1.letsexchange.com -TargetAddress j.smith@site2.microsoft.com

The resulting output will provide error details about the Availability service.

If you’re using the Availability service on a Cross-Forest scenario, please note that this service has a time limit when the it performs an AutoDiscover service request for cross-forest users in the AD directory service. By default, this is 10 seconds. If the AutoDiscover request does not finish in 10 seconds, the Availability service request for the cross-forest user may time out. This might be due to fact that the URL for the user is not cached, the AutoDiscover service is running slowly or it is experiencing network latencies.
If you want to increase this time-out value follow these steps (to increase it to 24 seconds):
1. Locate the Outlook Web Access Web.config file on the CAS server. The default location is in the following directory: C:\Program Files\Microsoft\ExchangeServer\ClientAccess\Owa
2. Make a backup copy of this file
3. Open the original file by using Notepad. Do not use IIS or WordPad to edit it
4. Add the following section directly under the Configuration node after the appSettings section:
5. Save the Web.config file.



If you have client computers running Outlook 2003 and earlier or Microsoft Entourage in your organization, they require a public folder database to support Schedule+ Free Busy functionality. Exchange 2007 is the first version of Exchange that gives you the option to not use public folders. However, until all your client computers are running Outlook 2007, you should continue to use public folders. This is why the Exchange 2007 Server Setup Wizard asks you whether Outlook 2003 or Entourage clients exist in your organization. Let’s see if in Exchange 14 we’ll still be able to work with pre-Outlook 2007 versions that still rely on public folders.