Wednesday, September 30, 2009

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.

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):

TTL: 1

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

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, 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 “”

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


  1. There are many good tools on the Earth. But unfortunately many of them didn't assist me. Luckily for me some days before I could dug up the one, which determined my old troubles with MS Outlook and what is more it would be helpful in such situation on my view - outlook pst file recovery software.

  2. Having same issue with my Window XP/Office 2007 clients connecting to Exchange 2013... keeps prompting for password and not taking it.

    I've tried setting the EXPR CPN to exchange.domain.local (the issued to common name on both exchange servers SSL certificates) but it still prompts me every time i connect

    1. Hi,

      Apologies for the delay in replying to you. Can you please confirm you are using Outlook 2007 SP 3 with the Outlook 2007 November 2012 update? Have you tried with an Outlook 2010 or 2013 client?
      I am assuming you already check that the accounts are not locked, password not expired, etc...?


  3. wonderful , resolved my issue with outlook 2010. no more prompts .