locked
Autodiscover servcie not working - Exchange 2010 - 401 error RRS feed

  • Question

  • 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.

     

     

     

     

    Friday, October 26, 2012 12:09 AM

Answers

  • Solution found:

    When I started thinking about the change to the DC, the search criteria led me to some other potential solutions that I had not tried before

    For those that might stumble across this thread as a solution, let me provide the configuration.

    Current Environment:

    • Exchange 2010 with SP2 running on Server 2008 R2
    • DC running Server 2008 R2
    • Clients Running Win 7 SP1, joined to domain
    • Outlook 2007 SP3 & Outlook 2010
    • Clients & Servers are up-to-date via Windows Update

    Exchange 2007 was installed when the DC (only DC) was Server 2003.

    Exchange was upgraded to 2010 from Exchange 2007 via an in-place upgrade.

    A new DC was promoted running on Server 2008 R2

    The old DC was then demoted- but the domain and forest functional levels were not raised (still 2003)

                                                                                                                             

    The following solution might not be Microsoft recommended or supported. 

    Please read the rest of the thread below before tying this fix.  There are many other more common fixes to the problem that should be tried before the fix presented here.

    I found this solution on a third party web site.  The site claimed that it only affected exchange 2007- and prior to SP2.  It should not affect Exchange 2010, but in my case it worked. I’m guessing in my case, the in-place upgrade had something to do with it, and I think the problem didn’t appear until the DC was changed to 2008.

    In IIS, I changed the ‘Windows Authentication’ to run ‘kernel-mode authentication’

    On the client, I was no longer prompted starting outlook.  Using the test auto-configuration showed it found via SCP and http status 200.  Viewing the Outlook diagnostic logs (olkdisc.log) also showed successful authentication negotiation.  Accessing Out-Of-Office failed, as did Free/busy.

    I then turned on kernel-authentication on EWS and OAB (OAB inherits the setting from the Default Web site level).

    Problems with OOF, Free/Busy, downloading OAB all went away for both Outlook 2007 and 2010.  Viewing the Outlook diagnostic logs confirms they are successfully running.  And I no longer get any authentication prompts.

    Thanks for all those who help in troubleshooting the problem and I hope others will find this information useful.

    Alex W



    Tuesday, October 30, 2012 5:59 PM

All replies

  • 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)
    Friday, October 26, 2012 12:28 AM
  • 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 :

    Friday, October 26, 2012 12:47 AM
  • 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.

    Friday, October 26, 2012 1:15 AM
  • 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

    Friday, October 26, 2012 9:24 AM
    Moderator
  • 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

    Friday, October 26, 2012 6:25 PM
  • 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

    Friday, October 26, 2012 6:38 PM
  • 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

    Friday, October 26, 2012 7:35 PM
  • 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

    Friday, October 26, 2012 10:18 PM
  • 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

    • Proposed as answer by Nonnopinolo Tuesday, February 18, 2014 11:18 PM
    • Unproposed as answer by Nonnopinolo Tuesday, February 18, 2014 11:18 PM
    Friday, October 26, 2012 11:30 PM
  • 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

    Saturday, October 27, 2012 5:58 AM
  • Hi Andy-

    Back to work today- and now I have my other work obligations squared away I can look at this again.

    I got excited when I saw the mention of SPNs being incorrect, since I had not seen that as an answer in any other thread on problems with Autodiscover.  However, the SPNs seem to be correct according to the article:

    Here is the health check:

    This server has a single drive with almost zero load- so I'm not worried about the file path optimization or the driver. 

    The OAB directory in IIS is of course in the Application pool of the default web site.  Because I recreated the Default web site from scratch, I think its just complaining about the name of the application pool.

    A Permission check ran with no errors (I'm out of screen shots for this post).  I then ran a permission check with the 'check user permissions' checked, and it also came up with all informatinal items.

    Right now I'm thinking the authentication breakdown is by the modules in the autodiscover application in some way.  IE seems to imply IIS authentication is fine.

    Also the Credential manager/cached credentials is empty.  For the test with Student95- that account had never logged onto the workstation.

    Thanks!

    Alex W.




    Monday, October 29, 2012 7:32 PM
  • Prabhat,

    Thanks for your interest and offer.  This is an isolated environment, so I'm do think I'll go through all the infrastructure changes that would be needed to make it remotely accessible.

    Thanks!

    Alex W.

    Monday, October 29, 2012 7:34 PM
  • Update:

    A couple of things I double-checked:

    Windows time is successfully synchronizing with the Domain Controller, and times are within 5 minutes.

    I enabled NTFS auditing and audited the autoconfiguration.xml file.  When accessing from client with IE, I could see where the system account (exchange$) successfully read the xml file.  I would have thought it would have been the IUSR account, since the folder has anonymous access enabled.

    I created another user from scratch, placed in the Users container to make sure no GPO stuff is effecting the user. (remember autodiscover used to work the other accounts). logged onto a system (domain member, Outlook 2007 SP3), created a profile.  Same results as above- autodiscover doesn't work, but can access mailbox fine.

    I checked group membership of the exchange computer account in AD.  compared that against a production server that autodiscover is working fine- didn't see anything unusual.

    Monday, October 29, 2012 8:31 PM
  • Update 2:

    One other item came to mind last night.  The Domain Controller was recently upgraded, and could have been the trigger for when autodiscover stopped working.

    The DC was not an in-place upgrade. The old server was 2003.  A new 2008 R2 server was promoted as a second DC, all the FSMO roles were moved to the new server. The old server was demoted via dcpromo and removed from the network.  Then the new server's IP and name were changed to match the old server.  The domain and forest functional levels are still 2003.

    Are there any default security settings on a 2008 DC that might prevent the authentication modules from the autodiscover directory from working that anybody can think of?

    Tuesday, October 30, 2012 1:46 PM
  • Solution found:

    When I started thinking about the change to the DC, the search criteria led me to some other potential solutions that I had not tried before

    For those that might stumble across this thread as a solution, let me provide the configuration.

    Current Environment:

    • Exchange 2010 with SP2 running on Server 2008 R2
    • DC running Server 2008 R2
    • Clients Running Win 7 SP1, joined to domain
    • Outlook 2007 SP3 & Outlook 2010
    • Clients & Servers are up-to-date via Windows Update

    Exchange 2007 was installed when the DC (only DC) was Server 2003.

    Exchange was upgraded to 2010 from Exchange 2007 via an in-place upgrade.

    A new DC was promoted running on Server 2008 R2

    The old DC was then demoted- but the domain and forest functional levels were not raised (still 2003)

                                                                                                                             

    The following solution might not be Microsoft recommended or supported. 

    Please read the rest of the thread below before tying this fix.  There are many other more common fixes to the problem that should be tried before the fix presented here.

    I found this solution on a third party web site.  The site claimed that it only affected exchange 2007- and prior to SP2.  It should not affect Exchange 2010, but in my case it worked. I’m guessing in my case, the in-place upgrade had something to do with it, and I think the problem didn’t appear until the DC was changed to 2008.

    In IIS, I changed the ‘Windows Authentication’ to run ‘kernel-mode authentication’

    On the client, I was no longer prompted starting outlook.  Using the test auto-configuration showed it found via SCP and http status 200.  Viewing the Outlook diagnostic logs (olkdisc.log) also showed successful authentication negotiation.  Accessing Out-Of-Office failed, as did Free/busy.

    I then turned on kernel-authentication on EWS and OAB (OAB inherits the setting from the Default Web site level).

    Problems with OOF, Free/Busy, downloading OAB all went away for both Outlook 2007 and 2010.  Viewing the Outlook diagnostic logs confirms they are successfully running.  And I no longer get any authentication prompts.

    Thanks for all those who help in troubleshooting the problem and I hope others will find this information useful.

    Alex W



    Tuesday, October 30, 2012 5:59 PM
  • Good one  for sure. 

    Another fact is, very rarely do the in place upgrade from 2007 to 2010


    Regards, Prabhat Nigam XHG and AD Architect and DR Expert Website: msexchangeguru.com VBC: https://www.mcpvirtualbusinesscard.com/VBCServer/wizkid/card

    Tuesday, October 30, 2012 6:06 PM
  • I have read the whole thread and would say, So Kernel mode authentication supersedes windows authentication and thus issue was resolved.

    Tuesday, September 13, 2016 2:07 AM