Hi there, My Windows Clients keep asking for the login information to connect to their Exchange Server. We're using Exchange Server 2010 in a single domain environment, with mixed Outlook 2007 and 2010 Clients. What I've got to say is that a colleague messed with the IIS Virtual Folders in order to publish RPC and OWA over Forefront TMG 2010. Due to Server issues, we had to rollback and now my Outlook Clients are asking for the login information. Results in: ...settings could not be obtained. (Sorry if it's slightly different, because I'm translating atm.) All our Clients are in the same Domain and when I run the Autodiscover Test in Outlook, it Prompts me the login Window. My Settings in IIS are (and unfortunately nobody here knows the clean, basic configuration): Autodiscover - Auth.Settings: Anonymous, Basic and Windows ECP - Auth.Settings: Anonymous and Basic EWS - Auth.Settings: Anonymous and Windows OWA - Auth.Settings: Basic RPC - Auth.Settings: Basic and Windows RPC+Cert - Auth.Settings: Basic and Windows What we did is: Recreated the OWA virtualdir, Recreated the Autodiscover-dir, Turned off HTTP-Connecting in Outlook Where we want to go with it: 1. Clients in our domain should never need to provide their Username and Password, neither at the office, nor at home via Outlook Anywhere. 2. We'd like to have it Forefront-Ready, but that would take another thread, I guess... Kind Regards, Kay

How did you re-create the virtual directories? http://technet.microsoft.com/en-us/library/ff629372.aspx Check the value of AutodiscoverServiceInternalURI in get-clientaccessserver and ensure that is resolves correctly to your Exchange server. Are you using a commercial SSL certificate? Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Hi Simon, I used the cmdlet in Exchange PS: Remove-OwaVirtualDirectory and New-OwaVirtualDirectory. get-clientaccessserver says the correct internal URL. When I try to connect to it wit a Browser, it prompts me a login window and when I provided my credentials it gives me the XML with the following "<ErrorCode>600</ErrorCode>" Seems correct for me. Another thing is: our internal domain name is contoso.local, while our external mail domain is contoso.de. My suspicion is, that because our address policy is set to default to my.name@contoso.de and added the addresses with contoso.local, that Autodiscovery first tries to connect over the external URI which is known for our environment not to work properly. About the SSL Certificate, yes, we do. It's a wildcard certificate for *.contoso.com and we made sure that the SAN of our internal hostname is included as well: myexchange.contoso.local Regards, Kay [Edit:] Regarding the article you provided, it's for Exchange Server 2010 SP, which is not our exact Version, so we can not reset via EMC. Our version is (via Get-ExchangeServer |fl AdminDisplayVersion,ExchangeVersion): AdminDisplayVersion : Version 14.0 (Build 639.21) ExchangeVersion : 0.1 (8.0.535.0) - which is, according to my knowledge 2010 SP1 - if relevant in this case. [Edit2:] We solved one of our Problems by setting the AutoDiscoverServiceInternalUri from https://mail.contoso.com/autodiscover/autodiscover.xml to: https://myechangeserver.contoso.local/autodiscover/autodiscover.xml Maybe it changed during the reset. I'm running more tests atm, to check for other problems due to the rollback. After all, maybe this can be markes as solved in a few. Regards, Kay

Hi, here's the thing: I misunderstood the first part and checked "Get-AutodiscoverVirtualDirectory" which was correct. AutodiscoverServiceInternalURI in get-clientaccessserver was set wrong though. Regards, Kay

The URLs on AutodiscoverVirtual Directory are not used by Exchange. The fact that your external address is different doesn't matter - UNLESS the clients are NOT members of the domain. If they are members of the domain then they will query or attempt to query the domain first. Only if that query fails will they fall back to autodiscover DNS records, which is what happens externally. Most of the articles for Exchange 2010 have SP2 on them. However if you are not already on Exchange 2010 SP2 then I would encourage you to do so, as it may well resolve the issues. Simon. Simon Butler, Exchange MVP Blog | Exchange Resources | In the UK? Hire Me.

Hi, Installing service pack would be a method to repaire virtual directory. You may have a try. Besides, please ensure that you have the correct windows credential to login the machine and then run test e-mail autoconfiguration. For internal user, it will try to retrive SCP from AD to get the autodiscover url. Please post the result of test e-mailautoconfiguration here. By the way, can you access mailbox after you enter user name and password?Xiu Zhang TechNet Community Support

Hi, What I should mention: the msstd: directive gives me an error at "testexchangeconnectivity" because our SAN of our certificate is not mail.contoso.com, but *.contoso.com. As soon as I correct this value in the principal name the test goes 1 hop further. But first, the autoconfig as you asked: <?xml version="1.0" encoding="utf-8"?> <Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006"> <Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"> <User> <DisplayName>My Name</DisplayName> <LegacyDN>/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=My Name</LegacyDN> <DeploymentId>b91025f7-282f-4fcb-b95c-8f7de8c02007</DeploymentId> </User> <Account> <AccountType>email</AccountType> <Action>settings</Action> <Protocol> <Type>EXCH</Type> <Server>internalhostname.contoso.local</Server> <ServerDN>/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=internalhostname</ServerDN> <ServerVersion>7380827F</ServerVersion> <MdbDN>/o=contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=internalhostname/cn=Microsoft Private MDB</MdbDN> <PublicFolderServer>internalhostname.contoso.local</PublicFolderServer> <AD>DC002.contoso.local</AD> <ASUrl>https://internalhostname.contoso.local/ews/exchange.asmx</ASUrl> <EwsUrl>https://internalhostname.contoso.local/ews/exchange.asmx</EwsUrl> <EcpUrl>https://internalhostname.contoso.local/ecp</EcpUrl> <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um> <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr> <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt> <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms> <OOFUrl>https://internalhostname.contoso.local/ews/exchange.asmx</OOFUrl> <UMUrl>https://internalhostname.contoso.local/ews/UM2007Legacy.asmx</UMUrl> <OABUrl>https://internalhostname.contoso.local/oab/e85275d3-af31-4758-9328-b991bdca0c97/</OABUrl> </Protocol> <Protocol> <Type>EXPR</Type> <Server>mail.contoso.de</Server> <SSL>On</SSL> <AuthPackage>Ntlm</AuthPackage> <ASUrl>https://mail.contoso.de/ews/exchange.asmx</ASUrl> <EwsUrl>https://mail.contoso.de/ews/exchange.asmx</EwsUrl> <EcpUrl>https://mail.contoso.de/ecp</EcpUrl> <EcpUrl-um>?p=customize/voicemail.aspx&amp;exsvurl=1</EcpUrl-um> <EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&amp;exsvurl=1</EcpUrl-aggr> <EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&amp;IsOWA=&lt;IsOWA&gt;&amp;MsgID=&lt;MsgID&gt;&amp;Mbx=&lt;Mbx&gt;</EcpUrl-mt> <EcpUrl-sms>?p=sms/textmessaging.slab&amp;exsvurl=1</EcpUrl-sms> <OOFUrl>https://mail.contoso.de/ews/exchange.asmx</OOFUrl> <UMUrl>https://mail.contoso.de/ews/UM2007Legacy.asmx</UMUrl> <OABUrl>https://mail.contoso.de/oab/e85275d3-af31-4758-9328-b991bdca0c97/</OABUrl> <CertPrincipalName>msstd:mail.contoso.de</CertPrincipalName> </Protocol> <Protocol> <Type>WEB</Type> <Internal> <OWAUrl AuthenticationMethod="Basic, Fba">https://internalhostname.contoso.local/owa/</OWAUrl> <Protocol> <Type>EXCH</Type> <ASUrl>https://internalhostname.contoso.local/ews/exchange.asmx</ASUrl> </Protocol> </Internal> <External> <OWAUrl AuthenticationMethod="Fba">https://mail.contoso.de/owa/</OWAUrl> <Protocol> <Type>EXPR</Type> <ASUrl>https://mail.contoso.de/ews/exchange.asmx</ASUrl> </Protocol> </External> </Protocol> </Account> </Response> </Autodiscover> /Kay

Hi, Please post the detail log information here after you run test e-mailautoconfiguration.Xiu Zhang TechNet Community Support

Hi Kay, There could be a number of issues causing the credential prompt. First, check the IIS permissions against the Defaults to see if they differ. http://blogs.technet.com/b/ferris/archive/2010/03/30/default-authentication-settings-exchange-2007-2010-iis-application-virtual-directories.aspx . You could also recreate the virtual directories, as seen here: http://technet.microsoft.com/en-us/library/ff629372.aspx Also, check the value of all Exchange Web Services to make sure they are named correctly OWA, ECP, OAB, EWS, AutoDiscoverServiceInternalUri ... Did I miss any!? When deploying ForeFront TMG in front of Exchange, it is necessary to change the ExternalAuthenticationMethods value on the OWA and ECP to Basic. This is because ForeFront is publishing OWA/ECP, etc. using Forms Based Authentication itself. This is the login screen that you will see when visiting OWA. However, Forms Based Auth cannot be simultaneously enabled on the CAS as well. ForeFront actually sends the credentials back to the CAS using Basic Auth. You can check your current value in the EMC by going to Server Configuration>Client Access>right-click on the OWA and ECP features, choose Properties>Authentication tab. You will need to select "Use one or more standard authentication methods:" and choose Basic. The interesting thing here from a design point of view is that because Basic Auth needs to be set on the OWA/ECP directories, it confines you to being prompted internally for credentials when visiting OWA/ECP internally. There are two ways around this depending on whether or not you have a load balancer. The easiest thing to do is actually create another OWA & ECP VDir on your CAS servers and associate those VDirs with a second IP Address on your CAS NICs. Of course, this means you will need to introduce another Namespace into your certificate. For example, if you are using webmail.company.com as your primary, you could introduce owa.company.com or something similar. These VDirs would have Forms Based Auth enabled and therefore would allow you to have a somewhat normal experience...with another namespace. If you have a load balancer, you could try this setup. Hope that helps!

Hi, not sure about what you mean with detail log of autoconfiguration. I've got results, protocol and XML. Well, I've installed SP2 AND Rollup1 for SP2, just in case... Another thing: My clients don't ask anymore for login credentials. As I realized - they did not ask yesterday, before the SP2, either. I guess I should start another thread for my actual problem, which why I got in here in the first place - Outlook Anywhere... Thanks a lot! Hard to say which one of the steps it did, but I learned a lot. Thank you again, /Kay