Password Prompt for Exchange Connected Outlook 2007 client using Outlook Anywhere off the domain

I've finished setting up Exchange 2007 and everthing works great with one exception.  I'm having a problem with Outlook 2007 clients specifically on computers that are not members of the domain.  It conistently prompts to enter the password everytime Outlook is opened.  I have Outlook 2003 clients that this is not a problem with once I do the registry hack to change "Incompatibilitylevel" to 3.  However, this doesn't help with Outlook '07.  I've tried every combination of security settings between Outlook and IIS and Exchange Management Console to no avail for both NTLM and Basic.  I've confirmed that settings were consistent across all applications but I can't shake this.  I do not have an ISA server and it isn't a firewall problem because my Outlook '03 clients work fine.
Who is Participating?
On the advanced tab in user accounts in the control panel you can assign credentials for specific severs.
Personally I don't see this as a problem. If the clients are not members of the domain then they need to authenticate. Outlook usually relies on the workstation to provide the security and access, but on a workgroup machine that isn't possible. If you are allowing your users to save the password then you are more trusting than I am!

I woulnt save the password personally... But it is a fix if his users are not security minded. I am sure everyone here has had problems explaining security to people.. they want it but dont want to go through the motions.
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

cdrichlaAuthor Commented:
These users are are outside sales reps that are never connected to the domain except for access to Exchange.  Their Windows logins are secured with complex passwords and locked down pretty well.  Their Windows credentials match their Exchange "Domain" accounts, so they would essentially be logging in with the same credentials twice.  That raises a question though about hosted Exchange.  How do all these hosted Exchange SPs integrate with companies that have systems that are part of a different domain than the hosted Exchange AD domain?  Same situation right?

BTW... the first suggestion worked just fine.  Thanks...
cdrichlaAuthor Commented:
I actually found the solution.  You can add permanent login credentials to the user account in Windows within the XP or Vista user account maintenance.
Force accepted.
EE Moderator
Greetings, I hope my comment after-the-fact is of some use and helps a few folks 'not' re-invent the wheel, LOL...

The complete solution I found for the issue of 'continuous password prompt' was an assembly of each of the following steps in their entirety and in the sequence below. Like many others, I had dinked with IIS authentication settings with different combinations of Windows Authentication and Basic Authentication on the various Virtual Directories used by Exchange 2007 after enabling Outlook Anywhere on the server-side and began testing. This process was the only one that has worked successfully, with consistent/desired results. One desired result was the elimination of the periodic password prompt when launching Outlook 2007 configured with Outlook Anywhere, externally. The first attempt to address this was by changing authentication on only the RPC Virtual Directory, which resulted in locally connected (domain member) Outlook clients getting prompted for password. Growing weary of an evening, I made the error of changing too many authentication settings in IIS without notes in which to back-track on my changes. This resulted in a connectivity MESS.

The Outlook Anywhere 'enable' dialog in the Exchange Management Console offers only NTLM 'or' Basic Authentication (not both) and I believe it is this fact alone that was causing the seemingly mixed results I was getting with password prompting, both with local Outlook clients and external clients that were configured with Outlook Anywhere. I should not that the end-user 'not' being prompted for password on non-domain member machines is of little consequence in my judgement because this is also typical of a home user with a POP3 account configured with settings that are inherently saved in the first place. Is is this type of user that Outlook Anywhere/RPC over HTTP is aimed at anyway, right? When a computer is stolen, for example, it might be prudent to change passwords anyway, rendering the account in question inaccessible, etc etc...

A valid SSL UCC/SAN certificate with a common name of SMTP.INTERNETDOMAIN.COM is properly enabled on our Exchange server - for all services (IIS, SMTP, IMAP, POP3, UM) and includes SAN records for:


LOCALSERVER1 is our solitary Exchange 2007 SP1 server running on Server 2008 x64 Standard Edition. was recommended by GoDaddy support that one should have a SAN record for BOTH the Exchange server's machine-name AND its FQDN - onto which the certificate is being applied, to avoid documented issues with Unified Communications and more. Useful tidbit. Also note that you MUST use a SAN of AUTODISCOVER - as I found out the hard way when I had initially configured my domain A Host record of AUTODISCOVERY, instead. After editing the host record I had to obtain a re-keyed/re-issued certificate with the correct entries and go through the process of re-applying it.

The first step is to DISABLE the Outlook Anywhere feature in the Exchange Management Console, in Server Configuration/Client Access. Allow a few minutes for the changes to take place in IIS and possiblly - restart the IIS Admin service after a few minutes, too.

The second step needed is to begin straightening out IIS authentication and subsequently getting it all to work is to reset the default settings for ALL Exchange-related Virtual Directories in IIS back to their rock-stock default settings. The following document was key and should be followed to the letter. In my case, one machine serves as both the Client Access Server and Mailbox Server role.

This document was followed literally with close attention paid to the combination of authentication settings specified in the table, be it anonymous, basic, integrated - in the right combinations - They must all be set exactly as written:

After restoring the proper authentication settings for each of the Exchange IIS Virtual Directories, re-enable the Outlook Anywhere feature, select your external FQDN when prompted by the wizard, and select NTLM authentication.

Next, open the Exchange Management Shell and execute the following CMDLet to note the ClientAuthenticationMethod and IISAuthenticationMethods values:

get-outlookanywhere | fl

IISAuthentication method can be observed set to NTLM authentication.

Next, execute the following command to set BOTH Basic and NTLM authentication for IIS:

get-outlookanywhere | set-outlookanywhere -IISauthentication basic,Ntlm

Now, execute the following command again to observe BOTH Basic and NTLM authentication enabled for IIS:

get-outlookanywhere | fl

Both locally connected Outlook clients and external clients configured with Outlook Anywhere should no longer prompt for authentication following their initial setup.

Note that both external and internal URL's must be configured properly for each element of Exchange in the first place, including the Public folder, OWA, OAB, etc.

Configuration settings that were generated with Outlook 2007 can be used to setup Outlook 2003 clients without Autodiscover (manual configuration of RPC over HTTP) by observing the account settings for your Outlook 2007 mail profile in the control panel and using them for your Outlook 2003 clients to avoid pitfalls with the older version.

I work as IT system consultant and have many Exhange using companies as my customers. A few of them had this problem. Seeing through all the suggestions here, some of them are correct for their problem. But i wanted to post here to explain something very important.

I solved this issue where i had checked everything stated here, pluss more. From the symptoms i always thought it was some autodiscover issue, and that it had to be related to authentication.

Here is a worklist of what you need to check if you have this issue. See abowe post for more details on each step.

1. Make sure that your SSL certificate is working. Test Outlook Web Mail. If SSL is working as intended go to step 2.

2. Check all internal and external URL. Also the SCP (Get-ClientAccessServer | fl)

3. Verify if you get a result from  (swap with your AutoDiscoverServiceInternalUri - see step 2.).

4. Dobbel check that you got Windows authentication = enabled, on the Autodiscover site in IIS. Also the main fix for my issue was to ensure that under advanced settings of Windows Authentication you have kernel mode authentication enabled!!! On my customers server it was off. And it was standard install with no modifications in IIS.

Hope this helps those that still struggle with this issue.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.