I'm sorry to post another Autodiscovery problem, but I have scoured all the boards and tried most the solutions to no avail. Sorry the post is long, but I want provide as much detail in the origional post as possible. Configuration: This is a server used for internal training. The server does not have internet connectivity so I am not worried about exposing servernames or ip addresses. Server Exchange (Exchange 2010 SP2, no rollups- because problem appeared after rollup 4.2 on Server 2008 R2 SP1). Clients use Windows 7 64-bit wiht outlook 2007 x86 and 2010 x86, problem consistent on both versions. Server and clients are on same LAN segment, no firewalls, proxies between server and client. Firewall is OFF on the Exchange server for troubleshooting reasons. Because the Exchange Server is not internet accessible- using the ExRCA is not an option. Client IE autoconfiguration of Proxy is not checked- and nh.local has been added to local instranet sites in IE. I just completed a reinstall of the CAS server role. I removed CAS via setup.com /m:uninstall /r:CA. Then I deleted the Client Access folder from the exchange program directory. I deleted the Default web site in IIS. I looked at the application.config file for anything left from exchange, and deleted the contents of wwwroot. I recreated the Default Web Site in IIS, then bound the Exchange certificate to HTTPS. I then installed CAS via setup.com /m:install /r:CA. No errors were reported. The problem below persisted from before the reinstall Problem: Autoconfiguration does not work- which causes OOF, Free/Busy, etc not to work. True for both domain member workstations as well as workgroup workstations. Currently troubleshooting domain computers. Clients periodically are prompted to authenticate to exchange.nh.local & autodiscovery.nh.local (obviously because of authentication failures to the Autodiscover web service) Output of 'Test email autoconfiguration': We can see that the correct URL is found- via SCP. There is a DNS record to autodiscover.nh.local, but is not important in the scenario. To verify it is not a Certificate error and that the URL is accessible, here is client connecting via IE9: The Red arrow shows the certificate is trusted. The internal Root CA is deployed to clients via GP, or for workstations it is installed manually prior to deployment of the image. The server certificate uses Subject Alternative names, without the use of a wildcard. The following names are exchange.nh.local, nh.local, autodiscover.nh.local, exchange. I have in troubleshooting reqested and installed another certificate on the server, but no change. I enabled diagnostic logging on Outlook, and took the authentication request from the olkdisk.log file: 2732 0x025EAABC 10/25/12 18:57:55 AUTODISCOVER GET SETTINGS BEGIN 2732 0x025EAABC 10/25/12 18:57:55 SMTP=nh\student95@nh.local 2732 0x025EAACB 10/25/12 18:57:55 Attempting URL https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml found through SCP 2732 0x025EAACB 10/25/12 18:57:55 Autodiscover to https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml starting 2732 0x025EB028 10/25/12 18:57:56 GetLastError=0; httpStatus=401. 2732 0x025EB028 10/25/12 18:57:56 AutoDiscover supported auth schemes: 2732 0x025EB028 10/25/12 18:57:56 Negotiate 2732 0x025EB028 10/25/12 18:57:56 NTLM 2732 0x025EB028 10/25/12 18:57:56 Basic 2732 0x025EB028 10/25/12 18:57:56 AutoDiscover attempting Auto-Negotiate with Desktop Credentials. 2732 0x025EB028 10/25/12 18:57:56 AutoDiscover USING pcreds->dwAuthScheme: 2732 0x025EB038 10/25/12 18:57:56 Negotiate 2732 0x025EB038 10/25/12 18:57:56 GetLastError=0; httpStatus=401. 2732 0x025EB038 10/25/12 18:57:56 AutoDiscover attempting NTLM with Desktop Credentials. 2732 0x025EB038 10/25/12 18:57:56 AutoDiscover USING pcreds->dwAuthScheme: 2732 0x025EB038 10/25/12 18:57:56 NTLM 2732 0x025EB047 10/25/12 18:57:56 GetLastError=0; httpStatus=401. 2732 0x025EB047 10/25/12 18:57:56 AutoDiscover attempting supplied Credentials. 2732 0x025EB047 10/25/12 18:57:56 nh\student95@nh.local 2732 0x025EB047 10/25/12 18:57:56 AutoDiscover USING pcreds->dwAuthScheme: 2732 0x025EB047 10/25/12 18:57:56 Negotiate 2732 0x025EB066 10/25/12 18:57:56 GetLastError=0; httpStatus=401. 2732 0x025EB066 10/25/12 18:57:56 AutoDiscover attempting Basic auth with the Supplied Credentials. 2732 0x025EB066 10/25/12 18:57:56 nh\student95@nh.local 2732 0x025EB066 10/25/12 18:57:56 AutoDiscover USING pcreds->dwAuthScheme: 2732 0x025EB076 10/25/12 18:57:56 Basic 2732 0x025EB076 10/25/12 18:57:56 GetLastError=0; httpStatus=401. 2732 0x025EB076 10/25/12 18:57:56 AutoDiscover prompting for AutoDiscover credentials. 2732 0x025EB076 10/25/12 18:57:56 Autodiscover to https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml FAILED (0x80040413) You can see the client tries to authenticate using Negotiate, NTLM and Basic. I enabled the Diagnostic logging on the Exchange server for MSExchange Autodiscover: core, provider, and Web to Expert level. However, no entries are generated in the Event logs. The IIS logs show an HTTP status 401, sub-status 0. To my knowledge, there is no HTTP error 401.0: 2012-10-25 23:37:34 192.168.10.43 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 0 2012-10-25 23:37:34 192.168.10.43 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /Autodiscover/Autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 64 15 2012-10-25 23:37:34 192.168.10.43 POST /autodiscover/autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /autodiscover/autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /autodiscover/autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /autodiscover/autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 15 2012-10-25 23:37:34 192.168.10.43 POST /autodiscover/autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 0 2012-10-25 23:37:34 192.168.10.43 POST /autodiscover/autodiscover.xml - 443 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 64 15 2012-10-25 23:37:34 192.168.10.43 GET /autodiscover/autodiscover.xml - 80 - 192.168.10.62 Microsoft+Office/12.0+(Windows+NT+6.1;+Microsoft+Office+Outlook+12.0.6662;+Pro) 401 0 0 203 I enabled IIS tracing on the Autodiscover virtual directory: Url https://exchange.nh.local:443/Autodiscover/Autodiscover.xml App Pool MSExchangeAutodiscoverAppPool Authentication anonymous User from token NT AUTHORITY\IUSR Activity ID {00000000-0000-0000-4B00-0080000000E9} Site 1 Process 5260 Failure Reason STATUS_CODE Trigger Status 401 Final Status 401 Time Taken 3922 msec In the Trace, under 'Errors and Warnings' is: No. Severity Event Module Name 145. view trace Warning -MODULE_SET_RESPONSE_ERROR_STATUS ModuleName ManagedPipelineHandler Notification 128 HttpStatus 401 HttpReason Unauthorized HttpSubStatus 0 ErrorCode 0 ConfigExceptionInfo Notification EXECUTE_REQUEST_HANDLER ErrorCode The operation completed successfully. (0x0) ManagedPipelineHandler And on Compact view of the trace (to include the request): GENERAL_REQUEST_ENTITY: Buffer="<?xml version="1.0" encoding="utf-8"?><Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>Student95@nh.local</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>" AspNetHttpHandlerLeave: MODULE_SET_REPONSE_ERROR_STATUS (Warning): ModuleName="ManagedPipelineHandler", Notification="EXECUTE_REQUEST_HANDLER", HttpStatus="401", HttpReason="Unauthorized", HttpSubStatus="0", ErrorCode="The operation completed successfully. (0x0)", ConfigExceptionInfo="" NOTIFY_MODULE_END: ModuleName="ManagedPipelineHandler", Notification="EXECUTE_REQUEST_HANDLER", fIsPostNotificationEvent="false", NotificationStatus="NOTIFICATION_CONTINUE" The security event log shows 'successfully logged on' entries for the accounts running outlook, so there are not any username/password problems. Same username/passwords were verified to access the autodiscover directory via IE9 above. NTFS permissions on Autodiscover folder (and autodiscover.xlm file) are set to: Authenticate Users - Read & Execute; System - Full Control; Administrators - Full Control Autodiscover Virtual Directory in IIS has the following authentication methods enabled: Anonymous - (using the IUSR account); Basic - (no default domain or relm); Windows Authentication - (providers in order: NTLM, negotiate) Autodiscovery virtual directory 'require SSL' setting has been tried both ways- no change to client errors. Results of the Get-AutodiscoveryVirtualDirectory | FL *: Name : Autodiscover (Default Web Site) InternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} ExternalAuthenticationMethods : {Basic, Ntlm, WindowsIntegrated, WSSecurity} LiveIdSpNegoAuthentication : False WSSecurityAuthentication : True LiveIdBasicAuthentication : False BasicAuthentication : True DigestAuthentication : False WindowsAuthentication : True MetabasePath : IIS://EXCHANGE.nh.local/W3SVC/1/ROOT/Autodiscover Path : C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Autodiscover ExtendedProtectionTokenChecking : None ExtendedProtectionFlags : {} ExtendedProtectionSPNList : {} Server : EXCHANGE InternalUrl : ExternalUrl : AdminDisplayName : ExchangeVersion : 0.10 (14.0.100.0) DistinguishedName : CN=Autodiscover (Default Web Site),CN=HTTP,CN=Protocols,CN=EXCHANGE,CN=Servers,CN=Exc hange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=NH Classroom ,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=nh,DC=local Identity : EXCHANGE\Autodiscover (Default Web Site) Guid : 40f27feb-14a2-4b56-a413-2ec0bef3b984 ObjectCategory : nh.local/Configuration/Schema/ms-Exch-Auto-Discover-Virtual-Directory ObjectClass : {top, msExchVirtualDirectory, msExchAutoDiscoverVirtualDirectory} WhenChanged : 10/24/2012 7:33:39 PM WhenCreated : 10/24/2012 7:33:39 PM WhenChangedUTC : 10/24/2012 11:33:39 PM WhenCreatedUTC : 10/24/2012 11:33:39 PM OrganizationId : OriginatingServer : KNX1.nh.local IsValid : True I have tried configuring the InternalURL on autodiscover, but again no change on the client results. OWA works fine. Email functions fine. Only processes that rely on Autodiscover are failing. I am at my wits end on how to resolve the problem. I have tried to use the information in prior posts and other web searches. I am out of ideas on how to solve the problem. Thank you for your time and consideration.

Ok, Your SCP Finds: https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml However in the screen shot of IE, you show a different URL. Note that theu autodiscover virtual directory is not what we want to see at this point and the URLs there should be blank. The SCP is defined for the clientaccessserver. If you do a Get-ClientAccessServer | Fl What is set for : AutoDiscoverServiceInternalUri According to that output it should be https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml and that is what you need to make sure you can connect to. ( or set it to the URL you want users to connect to)

Yes- I guess I goofed on the IE screenshot. The error 600 response (with trusted certificate) works for https://exchange.nh.local/autodiscover/autodiscover.xml, as well as for https://autodiscover.nh.local/.... and https://nh.local/autodiscover/autodiscover.xml. As for CAS server setting: PS C:\Users\aadmin> Get-ClientAccessServer | fl * Name : EXCHANGE Fqdn : EXCHANGE.nh.local OutlookAnywhereEnabled : False AutoDiscoverServiceCN : EXCHANGE AutoDiscoverServiceClassName : ms-Exchange-AutoDiscover-Service AutoDiscoverServiceInternalUri : https://exchange.nh.local/Autodiscover/Autodiscover.xml AutoDiscoverServiceGuid : 77378f46-2c66-4aa9-a6a6-3e7a48b19596 AutoDiscoverSiteScope : {Default-First-Site-Name} AlternateServiceAccountConfiguration :

Ok, thought it was just an alias, but wanted to make sure. One thing: NTFS permissions on Autodiscover folder (and autodiscover.xlm file) are set to: Authenticate Users - Read & Execute You should also see Read and List Folder Contents for authenticated users.

Hi, Can you access https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml from your client side? Judge from your Test-Email Autoconfiguration result, your client have issue to access https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml. I suggest you go to make sure you can access https://EXCHANGE.nh.local/Autodiscover/Autodiscover.xml from your client side, then run Test Email AutoConfiguration again. Thanks, Evan Liu TechNet Subscriber Support in forum If you have any feedback on our support, please contact tnmff@microsoft.com Evan Liu TechNet Community Support

Hi Andy- Thanks again for the response. Thats the tough thing with the 2 image limit on posts. I can't always incude screenshots of actual output, and I know from troubleshooting its tough to always trust just what somebody says in the post. Here are the permissions on the folder & file. Of course Read and execute on a folder implies list. Also, I know other posts say to make sure the Ignore client certificates is configured on the autodiscover (and other) virtual directories. Since I forgot that in the origonal posts, whated to incude that here that all directories are set to ignore client certificates. Thanks! Alex W

Hi Evan, Thanks for the reply- I realize the first screenshot had the incorrect URL in the picture to show the client can access the autodiscover.xml file via a browser. Here is a new screenshot- using IE8 so the full URL is visible. It was authenticated with the same account that is shown on the 'Test-Email Autoconfiguration' output shown above (student95@nh.local). Again you can see the certificate is trusted and the URL is accessible and returning the results expected, error 600. I should also note here that the user accounts I am using also have their UPN settings in AD the same as their email address. In this case - student95@nh.local. I have also tested other accounts, different comptuers, etc. Thanks! Alex W

It was authenticated with the same account that is shown on the 'Test-Email Autoconfiguration' output shown above (student95@nh.local). Does that mean that you are getting promoted for authentication? You shouldn't be since you have added nh.local to the Local Intranet Zone in IE, so I am a bit curious if that is also the case if you go to /EWS/Exchange.asmx or /OAB/<guid>/oab.xml Those VDirs is also configured with Windows Authentication...Martina Miskovic

Martina- That was a very good catch. I hadn't thought about it, but the actual environment I am currently troubleshooting has the computers joined to the domain- same domain and forest as exchange (named nh.local). The computers auto-logon with a different account than the mailbox- the login account doesn't have a mailbox at all, but has 'send as' and 'full mailbox' permissions to the mailbox. I didn't think about the different accounts because previously autodiscover worked- and the user was not prompted for the password when they launched Outook. Also- the setting for nh.local being in the local intranet zone was not consistent. So to answer your question, yes- before I was getting prompted authentication- because the computer I tested did not have nh.local in the zone. So on 1 machine- I put nh.local manually in the intranet zone. Then I logged in as Student95. Testing autodiscover, EWS, and OAB via https://exchange.nh.local/.... in IE does not prompt me for credentials, and shows the expected pages of successful authentication. When I launched Outlook 97 (no profile on computer), the Wizard did determine the email address of the account-i.e. I didn't have to do manual profile setup. But all the same tell-tell signs that Autodiscover is not working is there: Out of Office doesnt work, no free/busy, can't download OAB. The output of the 'Test autoconfiguration' is the same: 401 error. As soon as I run it I am prompted for password for exchange.nh.local 3 times, then autodiscover.nh.local 3 times. Using NH\Student95, student95, or student95@nh.local as the username has no effect, all 3 fail to authenticate. Also with Outlook logging enabled, the output is the same as the first post in the olkdisc.log file- you can see it trying and failing on all the different authentication methods. Thanks! Alex W

So many moving parts. One minutes Im leaning towards account issues or incorrectly cached creds, the other Im leaning somewhere else. By the way, Have you run ExBpa for helath and permissions against this server Also if list the SPNs for the server , what do they show? setspn -l <server> They should show : http://technet.microsoft.com/en-us/library/aa996905(v=exchg.80).aspx

if this is not fixed then I can take a look if you can give me remote. Regards, Prabhat Nigam XHG and AD Architect and DR Expert Website: msexchangeguru.com VBC: https://www.mcpvirtualbusinesscard.com/VBCServer/wizkid/card