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

Posted on 2007-11-14
Last Modified: 2011-02-25
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.
Question by:cdrichla
LVL 12

Accepted Solution

bhnmi earned 250 total points
ID: 20284722
On the advanced tab in user accounts in the control panel you can assign credentials for specific severs.
LVL 104

Expert Comment

ID: 20285235
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!

LVL 12

Expert Comment

ID: 20285587
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.
NAS Cloud Backup Strategies

This article explains backup scenarios when using network storage. We review the so-called “3-2-1 strategy” and summarize the methods you can use to send NAS data to the cloud


Author Comment

ID: 20286631
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...

Author Comment

ID: 20561462
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.

Expert Comment

ID: 20588035
Force accepted.
EE Moderator

Expert Comment

ID: 23515810
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.


Expert Comment

ID: 34637838
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.


Featured Post

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This article lists the top 5 free OST to PST Converter Tools. These tools save a lot of time for users when they want to convert OST to PST after their exchange server is no longer available or some other critical issue with exchange server or impor…
This article aims to explain the working of CircularLogArchiver. This tool was designed to solve the buildup of log file in cases where systems do not support circular logging or where circular logging is not enabled
In this Micro Video tutorial you will learn the basics about Database Availability Groups and How to configure one using a live Exchange Server Environment. The video tutorial explains the basics of the Exchange server Database Availability grou…
The basic steps you have just learned will be implemented in this video. The basic steps are shown to configure an Exchange DAG in a live working Exchange Server Environment and manage the same (Exchange Server 2010 Software is used in a Windows Ser…

830 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question