We help IT Professionals succeed at work.

Exchange 2010 - Clients prompted for password when disconnected

We are currently running Exchange 2010 SP1 in coexistence mode with Exchange 2003. There are 2 internet facing sites, 1 in US, and 1 in EU with multiple non-internet facing sites.

Each internet facing site has been configured for internet access with a UCC cert on the CAS servers (only 1 CAS at each site that also shares the HT role).

So we have:
mail.contoso.com -------- points to US site.
mail-eu.contoso.com ---- points to EU site.

External services are configured correctly and working, including OWA, ActiveSync, ECP, and Legacy access to the exchange 2003 front-end.

The US site has Autodiscover configured correctly, and everything functions as planned.
 Outlook Anywhere has also been turned on and configured. OA works just fine for the US site and mailboxes on that site’s 2010 MB server. If the CAS (in the US) is rebooted or unavailable, Outlook 2010 clients automatically reconnect to Exchange once it’s available without prompting for a password. Works great.

The EU site also has Autodiscover and OA configured the exact same way, however, we're having some very strange side effects regarding the CAS in EU if it is rebooted/unavailable.
If the CAS at the EU site is rebooted, all Outlook 2010/2007 clients at the same site are disconnected and immediately prompted for a username/password to reconnect to Exchange.

If I’m an EU user at the US site using Outlook 2010, I am not prompted for a password, and Outlook 2010 automatically reconnects to the server as soon as it’s back online.

If I’m an EU user at the US site using Outlook 2007, I am immediately prompted for a password, and Outlook 2007 does not automatically reconnects to the server.

Both CAS servers have been configured for NTLM authentication in Outlook Anywhere, and the Autodiscover directory in IIS has been configured for Anonymous, Basic and Windows authentication. I only mention this because every other topic I have seen where the client is prompted for a password has been related to NTLM authentication being configured incorrectly for OA.

We’re on the verge of beginning the mailbox moves over to 2010 from 2003, but this last piece of functionality is stopping the show. We really need the EU clients to auto-connect back to Exchange if it temporarily becomes available, the same way everything works in the US.
The really confusing part to me is the fact that EU users at the US site running Outlook 2010 are not prompted for passwords, while EU users who are local to the CAS are prompted for a password.

Any ideas?
Watch Question

Interesting ... if both CAS are configured the same, please check your EU router/firewall (like Baracuda) to let NTLM to pass through
Also :
A user connecting for the 1s time with OA will be always asked for credential and normally those credentials will be saved in the Windows Credential Manager . This way, using NTLM  will let the users connect without a prompt


Firewall rules for both sites are the same on separate PIX515s. Plus, EU users are prompted for their credentials when they're inside the EU firewall at the local site, inside the firewalls at the remote (US) site connected via site-to-site VPN, and from outside the firewalls using only OA.

Get-OutlookProvider > please check if servers for EXCH EXPR are $null
Also when you run test AutoConfiguration (log tab) from an EU client what SCP is returned first?
You can use Site Affinity to improve things:


Results for Get-OutlookProvider:   'Server' is blank for both US and EU servers. 'CertPrincipalName' is set to 'None' for EXPR on both US and EU servers.

When I test autoconfiguration from Outlook 2010 with an EU User:
1) From a US site:
Attempting URL https://SERVERNAME.US.CONTOSO.com/Autodiscover/Autodiscover.xml found through SCP
Autodiscover to https://SERVERNAME.US.CONTOSO.com/Autodiscover/Autodiscover.xml starting
Autodiscover to https://SERVERNAME.US.CONTOSO.com/Autodiscover/Autodiscover.xml Succeeded (0x00000000)

2) From an EU site:
Attempting URL https://SERVERNAME.EU.CONTOSO.com/Autodiscover/Autodiscover.xml found through SCP
Autodiscover to https://SERVERNAME.EU.CONTOSO.com/Autodiscover/Autodiscover.xml starting
GetLastError=12029; httpStatus=0
Autodiscover to https://SERVERNAME.EU.CONTOSO.com/Autodiscover/Autodiscover.xml Failed (0x800C8203)
Autodiscover to https://CONTOSO.com/Autodiscover/Autodiscover.xml starting
GetLastError=12175; httpStatus=0
Autodiscover to https://CONTOSO.com/Autodiscover/Autodiscover.xml Failed (0x800C8203)
Autodiscover to https://autodiscover.CONTOSO.com/Autodiscover/Autodiscover.xml starting
GetLastError=0; httpStatus=200
Autodiscover to https://autodiscover.CONTOSO.com/Autodiscover/Autodiscover.xml Succeeded (0x00000000)

I get the same situation with a user from the US: successful autodiscover in the US site, and failures at the EU site until it finally hits autodiscover.contoso.com.


Site Affinity has been configured for all of our sites, thanks.
So it is obvious what is going on...
Eu clients are trying to retrieve the https://SERVERNAME.EU.CONTOSO.com/Autodiscover/Autodiscover.xml 
[PS] C:\>Get-ClientAccessServer | fl *uri
but they fail and Outlook fall back to  Outlook Anywhere and succed with the external A record for autodiscover.domain.com > therefore the prompt
Please try to enter in your browser from EU machine: https://SERVERNAME.EU.CONTOSO.com/Autodiscover/Autodiscover.xml 
After a credential prompt you should get and xml file with error 600


Thanks for the help sirakov, you are correct.

If I go to the address above in the browser from an EU machine, I get nothing but an "Internet Explorer cannot display the webpage" page.

If I go to the autodiscover address for the US site, I get exactly what you said: login prompt followed by error 600 in XML.

So I assume this means the autodiscover settings are not working correctly on the EU side of things?  

If you dont have a proxy set with proper exceptions then please ensure that you can resolve
SERVERNAME.EU.CONTOSO.com. Check your internal DNS for A record pointing to your cas, nslookup,ping ...
Or just pick a name in your SAN certificated that resolves you EU CAS internally and set the AutoDiscoverServiceInternalUri
For example:
Open the exchange power shell and run :
[PS] C:\>Get-ExchangeCertificate |ft *domains, services
#note the the cert where services >IIS
#under "CertificateDomains" copy one of the domains > your.domain.com
#hopefully you can reach your.domain.com from a client machine
Then run the follwing commands :
[PS] C:\>Get-ClientAccessServer -Identity "EuCasServerName" | Set-ClientAccessServer -AutoDiscoverServiceInternalUri "https://your.domain.com/autodiscover/autodiscover.xml "
Also do not forget to change the internal urls of the following v'dirs if they cannot be resolved too
[PS] C:\>Get-WebServicesVirtualDirectory -Identity "EuCasServerName" | Set-WebServicesVirtualDirectory -InternalUrl "https://your.domain.com/ews/exchange.asmx"

[PS] C:\>Get-OabVirtualDirectory -Identity "EuCasServerName" | Set-OabVirtualDirectory -InternalUrl "http://your.domain.com/oab"

[PS] C:\>iisreset

Hope it helps


DNS resolves just fine for SERVERNAME.EU.CONTOSO.com from all sites, and that is one of the alternative names on the certificate installed on the EU CAS.

So, my engineer at the EU site made a small change yesterday evening on the EU CAS for ECP authentication. When I resumed testing this morning, I could successfully navigate to https://SERVERNAME.EU.CONTOSO.com/Autodiscover/Autodiscover.xml 
and received the correct prompt/response (error 600).

I'm wondering if IIS on the EU CAS just wasn't accepting traffic correctly, since after IISRESET was run, testing autodiscover settings at the EU site was successful for the local CAS instead of being forced to use the OA settings.

Now, if the EU CAS is rebooted, Windows 7 clients with Outlook 2010 are automatically reconnected once the server is back online. However, Windows XP clients with Outlook 2010 installed are still prompted for user credentials.

Windows XP clients running Outlook 2007 were still being prompted for a password until I found this Microsoft KB: http://support.microsoft.com/kb/956531/en-us

After applying that fix to Outlook 2007 clients, they are now functioning correctly and reconnecting automatically. Progress!!

At this point, everything is working correctly with the exception of Windows XP running Outlook 2010 at the EU sites. I wish I could find a hotfix for Outlook 2010 like the one above for Outlook 2007, but I haven't found anything that resolves that issue yet.

Currently investigating the problem with Windows XP and UCC certificates, depending on who they were issued to:
First article:  http://www.agileit.com/Blog/Lists/Posts/Post.aspx?Id=278

Second article:  

You can try this :
Remove the stored credentials on the client computer by going to Start > Run > Control KeyMgr.dll
Changed "Basic" authentication to "Anonymous" on the Default Web Site on Exchange server 2010.
You can also enable to same registry setting for OL2010 following http://support.microsoft.com/kb/956531/en-us on :
The hotfix itself is required for OL2007 but Ol2010 includes it by default.

Your EU engineer did something else because ECP v'dir does not play in our equation :)
Do you have a TMG and/or CASArray ?
Also I was wondering ...
is SERVERNAME.EU.CONTOSO.com a local name or you use the same IntenalUrl as the ExternalUrl with a Split DNS ?


Your EU engineer did something else because ECP v'dir does not play in our equation :)

Exactly my thoughts too, but I'll take luck where I can find it right now.  :-) From the troubleshooting I had done before, IIS just wasn't responding at all on that v directory, so some additional IIS operations were defintely made.

SERVERNAME.EU.CONTOSO.com is an InternalUri. The external Uri would translate to MAIL-EU.CONTOSO.com for the EU site, which stays within the same external namespace for the US (MAIL.CONTOSO.com). Not running TMG or a CAS array (unfortunately), we're just NATing external/internal IP to the CAS through firewalls.

I actually went thorugh and added the registry keys for KB956531 to an Outlook 2010 client, but it didn't make any difference, still got prompted for credentials.

Change "Basic" authentication to "Anonymous" on the Default Web Site on Exchange server 2010.

The Default website on both EU and US CAS servers are already configured for Anonymous authentication (using http redirect to the /exchange directory).

I'll be working on this some more this afternoon (my time) once it's evening at the EU site so I don't affect production, and I'll update the situation.

Honestly it's really strange that the issue is only with OL2010 on XP.
The only thing I know is that XP requires the certificate principal name because it cannot look into SAN domains. That's why we set sometimes the CertPrincipalName manaully with set-outlookprovider. However this is an issue with OA and not with domain joined clients .. hmm.

redirect to the /exchange directory <- you mean /owa right?
you can check if any of the sub virtual directores did not inherite this redirect as well, but I dont think so because nothing would work if true


Agreed. What really makes it strange is that US clients with Windows XP and Outlook 2010 do not experience this issue at all, they are automatically reconnected. EU clients with the same OS and Outlook version at the US site are automatically reconnected as well, it's only XP with Outlook 2010 at the EU sites that are prompted for credentials.

Oops, yes, I meant OWA.

Sub directories definitely inherited the redirect settings, but I've gone back over them and removed that option, so they're worling fine.
That's why we set sometimes the CertPrincipalName manaully with set-outlookprovider.

I tried this option yesterday, and it did not help. CertPrincipalName was configured for msstd:CONTOSO.com (issued to field on the UCC cert) at the EU site. Autosdiscover correctly configured the clients for OA, but they were still prompted for credentials when the EU CAS was rebooted.


Systems are running as good as I can expect them to be at this point. The only issues I'm still having are with Windows XP, and I'm not going to spend anymore time on that since that partticular site will be migrating over to Windows 7 soon enough to make it a non issue.