Hello, I experience an issue with some users in my Exchange 2007 organization. In fact, some users told me that they've got the credential prompt when they open their Outlook Application (OK on OWA). I did ask the user to reset the pwd and also recreate a new Outlook profile. However, nothing has changed and those users still have the prompt popping-up. On the client interface side, I check the Connection Satus and notice that those users were not using TCP/IP connection but Https (interface: Wireless Network Connection - Conn: Https). However, if this would be the problem I could not figure out how to change the https tpo TCP/IP connection. It regards a desktop and configuration is the same as another user who DO not face the issue (Basic authentication). On the server side: I checked the Internal/external URL from the OAB InternalUrl : https://autodiscover.company.com/OAB InternalAuthenticationMethods : {WindowsIntegrated} ExternalUrl : https://autodiscover.company.com/OAB Get-ClientAccessServer | fl AutoDiscoverServiceInternalUri : https://autodiscover.company.com/Autodiscover/Autodiscover.xml [PS] C:\>get-AutodiscoverVirtualDirectory -Server HUBCAS01 | fl Name : Autodiscover (Site Web par défaut) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated} BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True MetabasePath : IIS://HUBCAS01.company.intra/W3SVC/1/ROOT/Autodiscover Path : C:\Program Files\Microsoft\Exchange Server\ClientAccess\Autodiscover Server : HUBCAS01 InternalUrl : ExternalUrl : AdminDisplayName : ExchangeVersion : 0.1 (8.0.535.0) DistinguishedName : CN=Autodiscover (Site Web par défaut),CN=HTTP,CN=Protocols,CN=HUBCAS01,CN=Servers,CN=Exchange Adm inistrative Group (FDOHFPDT),CN=Administrative Groups,CN=company,CN=Microsoft Exchange,CN= Services,CN=Configuration,DC=company,DC=intra Identity : HUBCAS01\Autodiscover (Site Web par défaut) Guid : 37193-6ca6-417-8c70-88a55f73920 ObjectCategory : company.intra/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory} WhenChanged : 10/11/2009 11:52:37 WhenCreated : 26/03/2008 11:21:56 OriginatingServer : DOMCONTROLER03.company.intra IsValid : True From the above I don't see anything wrong... (except maybe that Internal & external Url fields are empty on the AutodiscoverVirtualDirectory ). Should I try to run URL on the user's PC? Could you please give me some clues in order to troubleshoot that issue?? I am getting pretty lost as only few users are impacted. many thanks, Graig

if you users is on the company network, is he still getting the prompt? is outlook anywhere enabled on the cas server? Thiyagu | MCTS/MCITP - Exchange 2007 | MCSE 2003[Messaging] | http://www.myExchangeWorld.com. This posting is provided "AS IS" with no warranties, and confers no rights.

Yes the users are on the company network and yes the OA is enabled. The connection status is set to "https" and should appear as TCP/IP... Don't know why though. Regards, Graig

I have a very similar issue, but with Exchange 2010. I have an Exchange 2010 SP1 system (installed from scratch -- not an upgrade) running on Windows Server 2008R2. Everything seems to work *except* Autodiscover from non-local subnets. In other words, the Internal access that queries the service connection point (as detailed here: http://technet.microsoft.com/en-us/library/bb124251.aspx) works fine, but the External access that hits the Autodiscover URL fails with repeated requests for credentials. I've used the credentials of actual mailbox owners as well as those of an Administrator, with no change. Setup: In the external DNS, I have an SRV record for _autodiscover._tcp.<mydomain>; that returns the name mail.<mydomain>, which has a valid A record. Clients can resolve those records successfully. On the Client Access servers, I've enabled all services for SSLOffloading as described here: http://social.technet.microsoft.com/wiki/contents/articles/how-to-configure-ssl-offloading-in-exchange-2010.aspx Following this article (http://technet.microsoft.com/en-us/library/bb201695.aspx) I have configured Outlook Anywhere to have an ExternalHostName of "mail.<mydomain>", OAB to have an externalurl of "https://mail.<mydomain>/OAB", and EWS to have an externalurl of "https://mail.<mydomain>/ews/exchange.asmx" I have a load balancer with the correct certificates performing SSL Offload. When clients attempt to connect to the Autodiscover URL, they hit the load balancer and the connections are decrypted and passed on to the Client Access server(s) on port 80. Taking a look at the unencrypted traffic on the server, I see this: POST /autodiscover/autodiscover.xml HTTP/1.1 Cache-Control: no-cache Connection: Keep-Alive Pragma: no-cache Content-Type: text/xml Cookie: OutlookSession="{02775E30-8337-4040-9DEB-CE14F4170CD9}" User-Agent: Microsoft Office/14.0 (Windows NT 6.1; Microsoft Outlook 14.0.4760; Pro) Depth: 0 Content-Length: 360 Host: mail.<mydomain> Authorization: Negotiate TlRMTVNTUAAD[...snipped for brevity...]kCmXCPDYN6gT8lM5xw== <?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>username@domain</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover> HTTP/1.1 401 Unauthorized Content-Type: text/html Server: Microsoft-IIS/7.5 WWW-Authenticate: Negotiate WWW-Authenticate: NTLM WWW-Authenticate: Basic realm="mail.<mydomain>" X-Powered-By: ASP.NET Date: Mon, 07 Mar 2011 19:26:37 GMT Content-Length: 58 You do not have permission to view this directory or page. ["username@domain" is actually the correct account information for any given mailbox, of course] I set a similar system up in another domain as a test and get the same results. What have I missed or what's wrong with my configuration? I've seen a few other reports of similar behavior (repeated auth attempts with no success) elsewhere online but haven't seen a definitive fix or one that seems to apply to my scenario. FYI, I've also tried without doing SSL Offloading, simply forwarding the connections without modifying them. Still doesn't work... Help!

Outlook can connect over HTTP rather than TCP when inside the network if you have the following settings in Outlook Anywhere Settings In outlook. On fast networks, connect using HTTP first, then connect using TCP On slow networks, connect using HTTP first, then connect using TCP I typically just uncheck both. As far as why autodiscover is not working externally, please run the autodiscover test on testexchangeconnectivity.com and post the diagnostic report.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Hi This problem occurs if the following Service Principal Names are registered on the Exchange server and if the Exchange server is not a global catalog server: exchangeAB/ExchangeServerName exchangeAB/ExchangeServerName.example.com A Service Principal Name (SPN) is a unique name that identifies an instance of a service and is associated with the logon account under which the service instance runs. Kerberos authentication is not possible for Exchange services without correctly configured SPNs. This article is about exchange 2003/2007 solution. http://support.microsoft.com/kb/927612/en-us If the article can’t solve your problem, you can read similar issue http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/b3a7309d-6f7e-48cb-aa4a-f30bc08b9267 (very very long)

I have run a test with an end user facing the issue I described above and told the user to type the https://autodiscover.company.com/autodiscover/autodiscover.xml URL in his Internet Browser. I also ran that test and got: <?xml version="1.0" encoding="utf-8" ?> - <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> - <Response> etc.... However, the user got a credential prompt ISA server 2006. After investigating the issue, I noticed that the entire agency was hosting our public DNS and the autodiscover URL was resolved with our public IP which explains why the users had to type their password each time they opened Outlook. The workaround would be to modify the host file but it would then won't work with Outlook Anywhere... For users that faced that issue and had no problem opening the URL, I unticked the 2 below options: On fast networks, connect using HTTP first, then connect using TCP On slow networks, connect using HTTP first, then connect using TCP Thanks to all for your input :-) Graig