I've been working on getting autodiscover to work through ISA 2006 without much luck. I'll try to give the most details I can with my setup:ISA 2006 SP1 on Server 2003 SP2- Web listener configured to use HTML Authentication with the autodiscover rule using NTLM authenticationCAS Server/Exchange 2007 on Server 2008Both are using SAN cert created from Server 2008 Certificate Server with www.occemail.com as CN of the cert with all the other SAN entries neededI have Outlook 2007 installed on a laptop (XP). Internally autodiscover is able to run when running the "test e-mail configuration" and I am able to open up the mailbox. However, when connected to the outside world, the test configuration fails with "HTTP Status Code 500" and 0x80004005. I can browse to https://autodiscover.domainname.com/autodiscover/autodiscover.xml just fine, it brings up the ISA form, I enter the credentials, and I am able to view the XML file. I have NTLM enabled on all the virtual directories. To me it sounds like a problem on the ISA server, but no combination of authentication methods has yielded a working environment.Also, Outlook continually prompts for password, even when entering the correct one. I realize both of these errors are quite common, but I have searched and searched forums, blogs, and technet with no solution found (and having an Outlook deployment deadline doesn't help either!). So here I am, appealing to the masses with that little fix that got them working. If you need any logs or other information posted, please ask and I'll post the results. Thank you in advance.Jeff

Have you seen this article?Publishing Exchange 2007 Autodisover in ISA 2006http://www.shudnow.net/2007/07/15/publishing-exchange-2007-autodisover-in-isa-2006/How is ISA configured? Dual Nic or single nic?SF - MCITP:EMA, MCTS

Thanks for the article.I have gone through it before with no luck. I went through it again and double-checked my settings. The only difference is that my internalurl fields are the same as my externalurls as we are running a split-DNS.Autodiscover works fine when connected inside the network. It fails when on an outside connection.I thought I had ran into the answer with this article:http://technet.microsoft.com/en-us/library/bb123889.aspxmostly in regards to disabling kernel-mode authentication. No such luck.This is a single NIC ISA box. We currently have a dual-nic on the way, but this is what we had to make due at the time. Any thoughts on this?Let me know if you need anymore info. Thanks.Edit:I'm not sure which change I've made recently has done this, but the password prompt is less frequent now. However, it goes through saying "trying to connect to microsoft exchange" before it shows discconnected. Sometimes, though, it still prompts. Autodiscover still fails with http status code 500.

Check info: 1. Please describe the full exchange topology, single box with all exchange server roles? (Mailbox, CAS and HUB), and also the version of Service Pack and Rollup of exchange 2. So, you can get the expect error 600 by browsing autodiscover.xml externally, right? 3. Please run the test configuration again, and post the output of Result and Log tab at here 4. The Remote Connectivity Analyzer will be extremely helpful for troubleshooting the outlook anywhere from the Internet. We can use it and see if it will offer any valuable info 5. After reproduced the issue, please check the IIS log on the CAS server in that period, see if the autodiscover request has been proxyed from ISA to CAS server We can narrow down the log per site: In the IIS 7->expand CAS server name->click Sites, in the middle-pane, find the ID of the site that contains the AutoDiscover virtual directory->Now go to LogFiles folder and get the log in the folder W3SVCID, like W3SVC1 or W3SVC2 Resources: Autodiscover Service Returns Unexpected Values for Outlook Anywhere Proxy Settings Outlook Anywhere Client Connectivity Issue Because of TCP/IPv6

OK, I keep messing this up, let me try this again:1. Topology:1 ISA 2006 SP1 server in the dmz; proxies activesync, owa, rpc over http (for outlook 2003 users), and eventually outlook anywhere/autodiscover1 mailbox server1 cas/hub server1 edge serverWe are on Rollup 7 for SP12. Yes. I am prompted with the ISA form box to authenticate due to the web listener having html form authentication turned on3. Funny enough, it works now. I have to enter in the user password, but autodiscover starting working this morning. Here are the results: 4. I am unable to run the remote connectivity analyzer has our public DNS does not have the correct IP addresses as of right now. I am getting around this by using entries in my host file.5. As far as I can tell, stuff is being proxied. Is there something specific I can search for in the log files?I have followed both articles and did what they both said. Right now autodiscover works when entering a password, but outlook is still unable to connect.

So basically my problem right now is autodiscover prompts for a password when not connected to the network, but it does indeed work. It does not prompt for a password when connected to the network. We use a split-DNS, so this means it is hitting the CAS server directly instead of routing through ISA.Outlook will sometimes prompt for a password, sometimes not, but it never connects. It will cycle through trying to connect but never does.

When I setup our environment I utilized the SRV record for autodiscover http://support.microsoft.com/kb/940881This allowed us to use a single certificate for all CAS features.You cannot have forms based authentication or windows integrated authentication enabled on the virtual directories.

I do have a single SAN cert with all possible names included.I added the SRV record to our public DNS (enom central). However, when trying to add it internally, I don't have an option for _autodiscover service.Can you elaborate on your virtual directory security? From the research I have seen, most people fixed the issue of providing a username/password by enabling integrated/windows authenication on their virtual directories. Thanks.

Well, the test e-mail autoconfiguration is back to failing, not sure why.I haven't made much changes today as I've been working on other projects.Here are the current results the Log tab:Autodiscover to https://domainwebmail.com/autodiscover/autodiscover.xml startingAutodiscover to https://domainwebmail.com/autodiscover/autodiscover.xmlFAILED (0x80040413)Autodiscover to https://autodiscover.domainwebmail.com/autodiscover/autodiscover.xml startingAutodiscover to https://autodiscover.domainwebmail.com/autodiscover/autodiscover.xmlFAILED (0x80040413)Local autodiscover for domainwebmail.com startingLocal autodiscover for domainwebmail.com FAILED (0x8004010F)Redirect check to http://autodiscover.domainwebmail.com/autodiscover/autodiscover.xml startingAutodiscover URL redirection to https://domainwebmail.com/autodiscover/autodiscover.xmlAutodiscover to https://domainwebmail.com/autodiscover/autodiscover.xmlFAILED (0x80040413)Redirect check to http://autodiscover.domainwebmail.com/autodiscover/autodiscover.xml FAILED (0x80040413)Srv Record lookup for domainwebmail.com startingAutodiscover URL redirection to https://domainwebmail.com/autodiscover/autodiscover.xmlAutodiscover URL redirection to https://domainwebmail.com/autodiscover/autodiscover.xmlAutodiscover to https://domainwebmail.com/autodiscover/autodiscover.xmlFAILED (0x80040413)Srv Record lookup for domainwebmail.com FAILED (0x80040413)Funny thing is, I close outlook, reopen it, it is still unable to connect, but when I rerun the test configuration, it pops up the username/password box, enter password, and it works. I don't know what makes it switch back and forth between halfway working and not really working.Looking for any ideas. Not looking to be spoon-fed, but I'm running out of ideas. It's inconsistent results, but anything that might point me in the right direction would be helpful. Thanks again.

1. Please use the cmdlet below to check the value of the CerPrincipalName and Server, ensure they are empty Get-OutlookProvider EXPR | fl 2. Please use the cmdlet below to check the value of the ExternalHostname, ensure it matches to Certificate Principal Name in the result of test autoconfiguration Get-OutlookAnywhere 3. Please run Test-OutlookWebService on the CAS server, and check the output 4. Please update the outlook into latest version and service pack, and then check the issue again 5. After reproduced the issue externally, check the IIS log in that accurate time on the CAS server with users alias, see if CAS server get the requests from external outlook client

1. They are both empty 2. ExternalHostname matches the same web address that is the CN on my certificate 3. When running Test-OutlookWebService on the CAS server, I get this: Test-OutlookWebServices -Identity:X98 | fl ID: 1003Type: InformationMessage: ABout to test autodisocver with the email address J.Blow2@mydomain.com Id: 1013Type: ErrorMessage: When contacting https://autodiscover.mydomain.com/autodiscover/autodiscover.xml received the error The remote server returned an error: (401) Unauthorized Id: 1006Type: ErrorMessage: The autodiscover service could not be contacted However, when I run the same command on my mailbox server (separate server) it runs just fine. The only hiccup is an information message that the OAB is not configured for this user. 4. I'm in the process of updating the laptop right now, will check back with any different results after doing so. 5. Here's what I'm seeing in the logs:<CAS IP Address> POST /autodiscover/autodiscover.xml - 443 mydomain\username <Primary IP Address of ISA Server> Microsoft+Office/12.0+ etc. Is this sufficient? Would you like me to search for more?Thanks again for your help James. Hopefully we can get this figured out.

I updated our external DNS to point autodiscover.mydomain.com to the correct IP address that I'm currently using. I also ran the Exchange Remote Connectivity Analyzer. I won't paste the entire results, but the only thing that failed was testing the SSL certificate for validity and certificate chain could not be built. We are using a cert from our internal trusted certificate authority, so this tool just doesn't trust it but our clients will, so I don't see that as being a major problem.Also updated outlook to SP2, no change.The Test E-mail AutoConfiguration works just fine (about 95% of the time). However, outlook continues to prompt for a password and never connects.

Can anyone comment on the registry changes made here?http://social.technet.microsoft.com/Forums/en-US/exchangesvrdeploy/thread/c8a2179c-39f3-4859-aca2-b1f6b529098bWhat is the correct value for the "NSPI interface protocol sequences" key they added to the domain controllers?Thanks.

Bump.Anybody? I've run out of ideas.

What are the IIS logs showing for errors on the CAS? When you monitor the ISA server, do you see the traffic coming thru as 'Allowed'?

There are no errors that I can find in the IIS logs on the CAS server. I searched the file with the user account that I am using to test and could see where it is hitting the OAB/{GUID} folder and the autodiscover.xml file. I also ran the monitoring query on the ISA server and saw "Allowed Connections" on my autodiscover rule. I'm stumped.Outlook continues to prompt for a password.

when prompted for the password, you should hit cancel. then in the iis logs you should see a corresponding 401 (unauthorized error). this 401 entry should have the requested url that is prompting for the password.

The 401 errors I'm seeing are:RPC_OUT_DATA /rpc/rpcproxy.dll server.mydomain.local:6001 443 - 204.87.70.107 MSRPC 401 1 2148074254 140andRPC_IN_DATA /rpc/rpcproxy.dll server.mydomain.local:6001 443 - 204.87.70.107 MSRPC 401 1 2148074254 171and this one was alittle earlier today:POST /autodiscover/autodiscover.xml - 443 - 204.87.70.107 Microsoft+Office/12.0+(Windows+NT+5.1;+Microsoft+Office+Outlook+12.0.6425;+Pro) 401 2 5 15I misinterpreted these and forgot about the http status codes tacked on at the end. the 204.87.70.107 is the primary IP address of the ISA Server. The "server.mydomain.local" is our old Exchange 2003 back end server. The only thing on that server that this user should be trying to connect to is the public folders. The OAB has been migrated to the new exchange 2007 server, and so has this particular user's mailbox. Hope this helps, please ask for anymore info if needed.