Dear all, We have 1 Exchange 2007 and 1 CAS server running and a Terminal Server. All Outlook 2007 clients are connecting using HTTPS/RPC internally and external. Now our problem is that when we try to configure an outlook client 2007 from the outside, that the "Online Search for your server settings" fails. We constantly get the credentials (u/p) prompt which is provided the correct credentials but are not accepted. From inside (for example on the Terminal Server) everything works fine (incl. OAB, OOF, etc). So this should be something with login to autodiscover. Conclusion:When we try to connect to: https://externaladdress.domain.net/autodiscover/autodiscover.xml (from the CAS server) we can logon with every valid credential. Now when we try to connect to the above mentioned address from ANY other internal server, or external address, we are not able to login and are constantly prompted with the UserName and Password window. Does anybody have a clue what's wrong here? Regards, David.

Can you try this 1. https://www.testexchangeconnectivity.com/2. Check Test Email Auto configuration (press ctrl key and right click on outlook icon on the system tray).Raj

The MS Exchange Team has a great article:Exchange 2007 Autodiscover and certificates http://msexchangeteam.com/archive/2007/04/30/438249.aspxA thought, have you tried to configure the external configuration to autodiscover.domain.com? ;)Internally it will work fine since the CAS server will register it self in AD.The reason for constant credentials could have to do with firewall rules or a trust issue with the site. SF - MCITP:EMA, MCTS: MOSS 2007, OCS 2007, Exchange 2007 -- http://www.scottfeltmann.com/

Hi Scott and Rajnish, Thanks for your response. We do not use a firewall to be honest (at this moment). I forgot to mention that we also use a url autodiscover.domain.net as a redirect to webmail.domain.net (our CAS server). Redirect seems to work fine, as I tried to connect to: autodiscover.domain.net/autodiscover/autodiscover.xml and I'm prompted with username and password window (which also does not authenticate). The The report from the url: https://www.testexchangeconnectivity.com/ Testing RPC/HTTP connectivity RPC/HTTP test failed Test Steps Attempting to test Autodiscover for EMAIL REMOVED Testing Autodiscover failed Test Steps Attempting each method of contacting the AutoDiscover Service Failed to contact the AutoDiscover service successfully by any method Test Steps Attempting to test potential AutoDiscover URL https://domain.net/AutoDiscover/AutoDiscover.xml Failed testing this potential AutoDiscover URL Test Steps Attempting to test potential AutoDiscover URL https://autodiscover.domain.net/AutoDiscover/AutoDiscover.xml Failed testing this potential AutoDiscover URL Test Steps Attempting to contact the AutoDiscover service using the HTTP redirect method. Failed to contact AutoDiscover using the HTTP Redirect method Test Steps Attempting to resolve the host name autodiscover.domain.net in DNS. Host successfully resolved Additional Details Testing TCP Port 80 on host autodiscover.domain.net to ensure it is listening and open. The port was opened successfully. Checking Host autodiscover.domain.net for an HTTP redirect to AutoDiscover Received Redirect (HTTP 301/302) Response successfully. Additional Details Attempting to test potential AutoDiscover URL https://webmail.otherdomain.net/Autodiscover/Autodiscover.xml Failed testing this potential AutoDiscover URL Test Steps Attempting to resolve the host name webmail.otherdomain.net in DNS. Host successfully resolved Additional Details Testing TCP Port 443 on host webmail.otherdomain.net to ensure it is listening and open. The port was opened successfully. Testing SSL Certificate for validity. The certificate passed all validation requirements. Test Steps Attempting to send AutoDiscover POST request to potential autodiscover URLs. Failed to obtain AutoDiscover settings when sending AutoDiscover POST request. Test Steps Attempting to Retrieve XML AutoDiscover Response from url https://webmail.otherdomain.net/Autodiscover/Autodiscover.xml for user EMAIL REMOVED Failed to obtain AutoDiscover XML response. Additional Details A Web Exception occurred because an HTTP 401 - Unauthorized response was received from Unknown Further I've spend more than 1 week to find a solution, and read a lot of articles, including the one Scott mentioned in his post. I hope that we can resolve this :-( Regards, David.

Can you do a Test-OutlookWebServices and post the result?More info: http://technet.microsoft.com/en-us/library/bb124509.aspx SF - MCITP:EMA, MCTS: MOSS 2007, OCS 2007, Exchange 2007 -- http://www.scottfeltmann.com

Its failing at the last test on autodiscover.xmlLooks like the URLs are not properly not set or not set properly. Attempting to test potential AutoDiscover URL https://webmail.otherdomain.net/Autodiscover/Autodiscover.xml Failed testing this potential AutoDiscover URL Attempting to test potential AutoDiscover URL https://webmail.otherdomain.net/Autodiscover/Autodiscover.xml Failed testing this potential AutoDiscover URL Attempting to test potential AutoDiscover URL https://webmail.otherdomain.net/Autodiscover/Autodiscover.xml Failed testing this potential AutoDiscover URL Attempting to test potential AutoDiscover URL https://webmail.otherdomain.net/Autodiscover/Autodiscover.xml Failed testing this potential AutoDiscover URL As Scott, please post the result for Test-Outlookwebservices.Raj

Hi Scott and Rajnish, Here are the results of test-outlookwebservices CmdLet: Type Message ---- ------- Information About to test AutoDiscover with the e-mail address EMAIL REMOVED. Information Testing server Myinternal-EXCH01-CAS.otherdomain.LOCAL with the published name https://webmail.otherdomain.net/EWS/Exchange.asmx & . Information Found a valid AutoDiscover service connection point. The AutoDiscover URL on this object is https://webmail.otherdomain.net/autodiscover/autodiscover.xml. Information The Autodiscover service was contacted at https://webmail.otherdomain.net/autodiscover/autodiscover.xml. Success [EXCH]-Successfully contacted the AS service at https://webmail.otherdomain.net/EWS/Exchange.asmx. The elapsed time was 968 milliseconds. Success [EXCH]-Successfully contacted the OAB service at https://webmail.otherdomain.net/EWS/Exchange.asmx. The elapsed time was 0 milliseconds. Success [EXCH]-Successfully contacted the UM service at https://Myinternal-exch01-cas.otherdomain.local/UnifiedMessaging/Service.asmx. The elapsed time was 218 milliseconds. Information [EXPR]-The AS is not configured for this user. Success [EXPR]-Successfully contacted the OAB service at . The elapsed time was 0 milliseconds. Information [EXPR]-The UM is not configured for this user. Success [EXPR]-Successfully contacted the RPC/HTTP service at https://webmail.otherdomain.net/Rpc. The elapsed time was 109 milliseconds. Success The Autodiscover service was tested successfully. As you can see it (seems) that this is working fine .... regards, David.

So, it is working fin internally.What is access like into your environment? Firewall(s)? reverse Proxy?It could be that your DNS is not pointing to the correct connection point on your firewall, or your firewall is not allowing the traffic inbound correctly. is port 443 allowed inbound for your https://autodiscover.domain.com?I would start looking at firewall logs while running the tests from https://www.testexchangeconnectivity.com/ and see how your firewall is handeling the rules. I'm thinking your communication is being interrupted at some point, either DNS or firewall.SF - MCITP:EMA, MCTS: MOSS 2007, OCS 2007, Exchange 2007 -- http://www.scottfeltmann.com

Hi Scott, There is no firewall in front of the CAS server. And as you can see, https traffic is allowed (see my report from testexchangeconnectivity.com, the certificate is verified and accepted already) I can login at: https://webmail.otherdomain.net/autodiscover/autodiscover.xml from ONLY the CAS server using a webbrowser. Now when I login at the DC and try to login to the same URL it does not work (u/p windows keeps prompting for a username and password) , and I'm then still at the LAN network. The CAS server event logs (Security) reports a failed login at the same moment for the used credentials. I think we have a weird problem here .... :-( Regards, David.

The prompt for user could be the trust level of the web site you're accessing.Have you tried to hit it from a server other then the localhost and the DC?The other thought, what authentication are you using on the CAS server? Forms based, basic, intergrated?Typcially you want to use forms based auth if you don't have a reverse proxy in the middle of it. So, at this point it could be DNS related. are you certain you're hitting the correct server all the way though. SSL Cert appears to be ok. Could be related to IE for OWA access prompting. Could be the authentication you're using or the site is not trusted in IE, check security settings in IE. Also, internal and external URLs are configured correctly on the CAS?The cert is generated from a Private CA or public CA correct?SF - MCITP:EMA, MCTS: MOSS 2007, OCS 2007, Exchange 2007 -- http://www.scottfeltmann.com

Hi Scott, 1. I've added webmail.otherdomain.net to trusted sites and indeed I'm able to login to the autodiscover.xml with result 'invalid request' Error 600 which is fine. This works from any server within the domain (LAN). From the outside it does not work. 2. What kind of information regarding authentication would you like me to provide? (cmdLet to run?) 3. For OWA we use form based authentication, and no proxy in front of it. 4. I'm sure that this cannot be a DNS problem to be honest, as the same records which exists in the internal DNS are also known in the external DNS (those who are related to autodiscover) 5. IE checked and indeed added to trusted sites seems to work. (thanks) 6. Which internal and external urls do you mean? (cmdlet to provide you with the info?) I've, as far as I can see configured that correctly. If you want please let me know what to run, so I can provide you with the proper information. I really appreciate your help! Regards, David. EDIT: Certificate is correct, it's accepted already as you can see.

So i found an interesting ARticle:http://www.photontech.org/dev/2007/02/outlook_2007_password_prompt_a.htmlNot sure if that will work or notThe other thing is check in IIS manager and see what the authentication is on the autodiscover folder. Also if you look in the EMC under servers, CAS you can get the properties of the web sites. Check OWA for internal and external URLs. it is on the first page that is opened up on the properties. Is your SSL Cert signed from a private CA or a public CA?Also found this: http://www.eggheadcafe.com/software/aspnet/32046760/-outlook-2007-promptin.aspxI had an issue similar to this. Win2k3 Ex07. All of my Outlook 2007users were getting prompted over and over for the username andpassword. It wasn't checking the certificate that they had installedvia internet explorer. To fix the problem, I opened IIS on theExchange server and checked the following directories under thedefault website (the root site(default web site), oab, autodiscover).Under the directory security tab, click Edit in the SecureCommunications section. I had the require SSL checked and the 128bitencryption, but under Client Certificates, it was set to ignore. OnceI changed that to Accept for each of the folders, stopped and startedIIS, I stopped being prompted all the time for credentials. Hopefullythis will help someone in the future.W2K8 will be a bit different but the concept would be the same. SF - MCITP:EMA, MCTS: MOSS 2007, OCS 2007, Exchange 2007 -- http://www.scottfeltmann.com

Hi Scott, I'll answer again one by one :-) 1. Article is related to a missing folder on that specific workstation. We have tried this from more than 5 different OS's and workstations all with the same result. 2. Our IIS 7 manager has the following Authentication enabled on the autodiscover folder: Basic, Windows Authentication. Within Windows authentication 'enable kernel mode authentication' is already switched off 3. For OWA the internal URL points to the internal servername.domainname.local and the external url contains: webmail.otherdomain.nl which should be fine. 4. Our SSL certificate is a public CA (and signed by a public CA). We don't have to install any CA on workstations, because this is a trusted authority which is public. 5. We use IIS 7 which has require SSL and Ignore client certificates checked. We do not use IIS 6. Further I can tell you, that I've read a lot articles on the internet for more than 1 week, before I decided to post here. I think I will take a snapshot from the virtual CAS and start all over again from scratch to get it work. What do you think? Regards, David.

Hi Scott, I got an update in the meanwhile: I've switched off Windows Authentication and only allow Basic Authentication on the AutoDiscovery site (using IIS manager 7) and I'am able to login now. The consequence of switching off Windows Authentication is that my Internal Outlook clients are all asking for credentials now, before they continue. Once done, they are able to use everything within outlook (inside users) Now for the External non domain users, they are able to discover there settings and are able to connect. However they are not able to use the Out Of OfficeAssistant, unless I grand (instead of both) only Basic Authentication on the EWS folder using IIS Manager 7. This has no effect on internal clients, they still can use the Out Of Office Assistant. So two issues are left: 1.) I'll need to make sure that internal users do not need to enter their credentials, as they already did this when logging in on the Terminal Server. If Windows authentication is enabled we do not have to enter credentials. 2.) Outside users can not download the offlineaddress Book. If I put Outlook in logging mode, it seems that the correct OAB url is defined, but when I open the url in a browser and try to login, it seems that my credentials are refused again. I've tried to change the OAB folder authentication to BASIC only instead of Basic and Windows Authentication, but without luck. Bumping my head to the wall :-) David.

Hi Scott and others, resolved the OAB download issue also. We can download it, but it takes about 2 minutes (for the first time) to finish. Only issue left is Windows Authentication, which cannot be enabled, or autodiscover does not work anymore. I've already disabled kernel authentication, without luck. If I got this resolved, then my internal clients do not have to enter their credentials anymore :-) Any ideas anyone?

Hi,Please check whether the below article can help you:http://support.microsoft.com/kb/954034ThanksAllen

Hi Allen, I'am sure it will not work, as I have a different Terminal Server, which is not installed on the Outlook AnyWhere machine. At this moment I've managed to get it to work partially. Two things went wrong: SCP record changed to the inside CAS servername and configured Outlook to not use RPC internally. Now the password prompt is gone, but the (inside) users are still not able to download the OAB and use the OOFbecausethey need to enter the credentials first. And as you can guess, the password prompt keeps coming back. Regards, David.

Sorry, been busy,Have you tried to enable both Basic and Windows Auth?Set-AutodiscoverVirtualDirectory -Websitename <websitename> -BasicAuthentication:$true -WindowsAuthentication:$trueSF - MCITP:EMA, MCTS: MOSS 2007, OCS 2007, Exchange 2007 -- http://www.scottfeltmann.com