Ok, environment is all Outlook 2007 clients, Exchange 2007 Server on a Windows 2003 R2 Server, ISA 2006 also on a Windows 2003 R2 Server. On loading, the Outlook 2007 clients are prompted for their credentials in a domain environment. If they cancel this prompt, or login to it, they are able to receive e-mail (i.e. the prompt is useless and has no bearing on their ability to send/receive emails). I've tested creation of a new profile and unchecked the Outlook Anywhere box to test if OA is to blame, and it has the same result. Auto setup of e-mail works fine (i.e. fresh client automatically configures based on domain credentials, without problems). We are using a wildcard cert for the Exchange web services, but have no issues and no certificate warnings. Any ideas what else to troubleshoot or try to get this narrowed down? Thanks for any pointers.

First - you will not find many that recommend a wildcard certificate for use with Exchange 2007 and higher, because they are not the same as the UC certificate. It can also cause problems with some clients, particularly mobile devices. This is probably related to autodiscover. One of the authentication settings isn't correct, or one of the URLs resolves to somewhere that you aren't expecting. Hold down CTRL while you right click on the Outlook icon in the system tray and choose test email autoconfiguration. Run the test and see what happens. Verify the hosts etc that are mentioned in the test and log resolve to where you think they do. In a LAN environment, Outlook Anywhere shouldn't be used. Doing the same CTRL thing as above, choose Connection Status and you can see whether Outlook is connecting with Outlook Anywhere (protocol HTTPS) or RPC (Protocol TCP). Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Thanks for the quick reply, I'm willing to get an alternate certificate, but it has been working fine with a wildcard up until recently when something appears to have changed. The Connection Status is connected via RPC (TCP/IP) three times to the exchange server and once to the domain controller (total of 4 connections, 2xMAIL,1xPublic Folders, and the Domain Controller is 1x Directory). Autodiscovery Results: Redirect URL: https://webmail.mydomain.com/owa Protocol: Exchange RPC Server: exchange.mydomain.com Login Name: Me Availability Service URL: https://exchange.mydomain.com/EWS/Exchange.asmx OOF URL: https://exchange.mydomain.com/EWS/Exchange.asmx OAB URL: http://exchange.mydomain.com/OAB/crazy-long-numbered-directory/ Unified Message Service URL: https://exchange.mydomain.com/UnifiedMessaging/Service.asmx Auth Package: Unspecified Protocol: Exchange HTTP Server: webmail.mydomain.com Login Name: Me SSL: Yes Mutual Authentication: Yes Auth Package: Basic Certificate Principal Name: msstd:webmail.mydomain.com The Autodiscovery test log displays as this: ++++++++++++++++++++++ AUTODISCOVER GET SETTINGS BEGIN LegacyDN= SMTP=me@mydomain.com Attempting URL https://webmail.mydomain.com/autodiscover/autodiscover.xml found through SCP Autodiscover to https://webmail.mydomain.com/autodiscover/autodiscover.xml starting Autodiscover to https://webmail.mydomain.com/autodiscover/autodiscover.xml FAILED (0x800C8204) Autodiscover URL redirection to https://webmail.mydomain.com/owa Autodiscover request completed with http status code 500 Autodiscover URL redirection to https://webmail.mydomain.com/owa FAILED (0x80004005) Autodiscover to https://autodiscover.mydomain.com/autodiscover/autodiscover.xml starting Autodiscover to https://autodiscover.mydomain.com/autodiscover/autodiscover.xml succeeded (0x00000000) AUTODISCOVER GET SETTINGS END -----------------------

Your autodiscover is not working correctly. It is trying to access a URL, which fails. Does that URL in the first line resolve to the Exchange server? If not, then it should do. It would then appear that a redirection has been put in place as well - which looks wrong. Internally that shouldn't be required, and ideally externally you should be using the autodiscover.example.com URL. If your internal server name is a host name that matches the domain in the wildcard certificate then you could correct the autodiscoverURI on set-clientaccessserver to use the server's name instead. As for the "Its worked for months", that doesn't mean it was correct. That is the equivalent of me saying that I have driven down this country lane on the wrong side of the road every morning for the last two years. That doesn't mean a thing when I hit the removal truck coming down the road one morning. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

I should also note, that Outlook Web Access via ISA, Macintosh Office Outlook 2011 and our Blackberry Enterprise services are all working fine without prompting. It is only Outlook 2007 that suddenly is prompting for credentials while logging in. The prompt also says "webmail.mydomain.com" at the top of it, then followed by the standard username/password (populating the username with domain\username) instead of exchange.mydomain.com, which I thought was interesting. Thanks again.

The URL in the first line resolves to: https://webmail.mydomain.com/CookieAuth.dll?GetLogon?curl=Z2Fowa&reason=0&formdir=1 Which is the login page for the Outlook Web access webpage. Would the redirect be located on the ISA server or the Exchange server? Apologies for basic questions and that "it's worked for months", but I'm cleaning up a mess left by someone else and trying to get it done correctly this time. I appreciate your efforts with assisting me. The internal server name (i.e. exchange.mydomain.com) is a host name that matches the wildcard cert (i.e. *.mydomain.com). So should I update the autodiscoverURI to exchange.mydomain.com via the Set-ClientAccessServer command? Get-ClientAccessServer results in the following: Name : EXCHANGE OutlookAnywhereEnabled : True AutoDiscoverServiceCN : EXCHANGE AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service AutoDiscoverServiceInternalUri : https://webmail.mydomain.com/autodiscover/autodiscover.xml AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596 AutoDiscoverSiteScope : {Default-First-Site-Name} IsValid : True OriginatingServer : REMOTE.mydomain.com ExchangeVersion : 0.1 (8.0.535.0) DistinguishedName : CN=EXCHANGE,CN=Servers,CN=Exchange Administrat ive Group,CN=Administrative Groups,CN=mydomain,CN=Microsoft Exchange,C N=Services,CN=Configuration,DC=mydomain,DC =com Identity : EXCHANGE Guid : 063bb3de-6e1b-473c-96bb-31f9adc44244 ObjectCategory : mydomain.com/Configuration/Schema/ms-Exch-Exchange-Server ObjectClass : {top, server, msExchExchangeServer} WhenChanged : 7/16/2009 3:08:11 PM WhenCreated : 7/16/2009 3:08:11 PM

Where does it resolve to though? Does it resolve to the ISA server or to the Exchange server? If it resolves to the ISA server then that is the problem. Internally the autodiscover URI should resolve to an Exchange server only. Change the AutoDiscoverServiceInternalUri on set-clientaccessserver to the Exchange server's FQDN and then run IISRESET. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

According to DNS records, webmail.mydomain.com is resolving to the ISA server for front end relay of the OWA access. I'll reset to the FQDN of the Exchange server and reset IIS. Does it make a difference that manually typing in: https://EXCHANGE.mydomain.com/autodiscover/autodiscover.xml returns with a credential prompt and (once authenticated) an "Invalid Request Error 600" ? Making changes now - thank you again.

The error when you browse to the page is correct, because your browser isn't Outlook. Simon.Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Worked like a charm, you are the best!