none
Exchange 2013 Autodiscover 401 after WSUS removal RRS feed

  • Question

  • Hi

    I'm fighting with non functioning autodiscover in Exchange 2013.

    This is an old Server 2012 box, running Exchange 2013 CU23. It had WSUS installed on the same machine, which got removed and resulted in HTTP 500 "Internal Server Error" on an Exchange virtual directory. After a bit of digging, I found a blog post relevant to the situation with ISS: 

    This was caused by the removal of the WSUS role on the server which removed almost all the files installed by the Windows Update Services but not the configuration written in the ApplicationHost.config file. The Applicationhost.config file tries to call the .dll installed by the WSUS Server but no longer exists on the system.

    From the Applicationhost.config file:

    <scheme name=”xpress” doStaticCompression=”false” doDynamicCompression=”true” dll=”C:\Windows\system32\inetsrv\suscomp.dll” staticCompressionLevel=”10″ dynamicCompressionLevel=”0″ />
    <scheme name=”xpress” doStaticCompression=”false” doDynamicCompression=”true” dll=”C:\Program Files\Update Services\Webservices\suscomp.dll” staticCompressionLevel=”10″ dynamicCompressionLevel=”0″ />

    Running the following command will remove all references to the module installed by WSUS.

    %windir%\system32\inetsrv\appcmd.exe set config -section:system.webServer/httpCompression /-[name='xpress']


    The command listed in that article got things back up and running again apart from autodiscover.

    If I try to go to https://autodiscover.domain.com/autodiscover/autodiscover.xml, I get a password prompt. Literally no combination off username or password will get me past it. 

    Test-OutlookWebServices -Identity "user@externaldomain.com" -MailboxCredential(Get-Credential ADdomain\username) | Fl yields:

    [2019-09-10 22:53:23Z] Autodiscover response:
    System.Net.WebException: The remote server returned an error: (401) Unauthorized.

    Which tallies with not being able to auth if I go to the autodiscover URL.

    I've checked that the autodiscover URL is set correctly, auth methods are correct on the VD, reset the VD, and read just about every article I can find relating to that error and I'm still stuck. 

    Outlook prompts for a password at autodiscovery stage and also fails no matter what credentials I try to feed it. Setting up a profile manually (in old Outlook versions) works fine, as does mail flow, OWA and Activesync. 

    Any pointers much appreciated

    Many thanks!


    Tuesday, September 10, 2019 11:13 PM

All replies

  • Could you set up the Outlook profile successful in a domain-joined machine? 

    Please read the following thread, ensure that you have completely remove the WSUS.

    How to completely remove WSUS on Windows 2012 R2?

    Besides, please test Outlook Autodiscover in ExRCA website and send the entire result here if the test is not passed.

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Wednesday, September 11, 2019 9:01 AM
    Moderator
  • Hi Manu, thanks for the reply

    Autodiscover doesn't work on domain joined machines using a domain account either. It prompts for credentials in exactly the same way.

    The connectivity tests also fail with the same 401 error:



    The Microsoft Connectivity Analyzer is attempting to test Autodiscover for ianelvar@************.co.uk.
      Testing Autodiscover failed.
     
    Additional Details
     
    Elapsed Time: 11821 ms.
     
    Test Steps
     
    Attempting each method of contacting the Autodiscover service.
      The Autodiscover service couldn't be contacted successfully by any method.
     
    Additional Details
     
    Elapsed Time: 11821 ms.
     
    Test Steps
     
    Attempting to test potential Autodiscover URL https://************.co.uk:443/Autodiscover/Autodiscover.xml
      Testing of this potential Autodiscover URL failed.
     
    Additional Details
     
    Elapsed Time: 8032 ms.
     
    Test Steps
     
    Attempting to resolve the host name ************.co.uk in DNS.
      The host name resolved successfully.
     
    Additional Details
     
    IP addresses returned: 35.189.125.64
    Elapsed Time: 496 ms.
    Testing TCP port 443 on host ************.co.uk to ensure it's listening and open.
      The port was opened successfully.
     
    Additional Details
     
    Elapsed Time: 245 ms.
    Testing the SSL certificate to make sure it's valid.
      The certificate passed all validation requirements.
     
    Additional Details
     
    Elapsed Time: 742 ms.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server ************.co.uk on port 443.
      The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
     
    Additional Details
     
    Remote Certificate Subject: CN=************.co.uk, Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US.
    Elapsed Time: 697 ms.
    Validating the certificate name.
      The certificate name was validated successfully.
     
    Additional Details
     
    Host name ************.co.uk was found in the Certificate Subject Common name.
    Elapsed Time: 0 ms.
    Certificate trust is being validated.
      The certificate is trusted and all certificates are present in the chain.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=************.co.uk.
      One or more certificate chains were constructed successfully.
     
    Additional Details
     
    A total of 1 chains were built. The highest quality chain ends in root certificate CN=DST Root CA X3, O=Digital Signature Trust Co..
    Elapsed Time: 20 ms.
    Analyzing the certificate chains for compatibility problems with versions of Windows.
      Potential compatibility problems were identified with some versions of Windows.
     
    Additional Details
     
    The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
    Elapsed Time: 0 ms.
    Testing the certificate date to confirm the certificate is valid.
      Date validation passed. The certificate hasn't expired.
     
    Additional Details
     
    The certificate is valid. NotBefore = 8/29/2019 12:21:57 PM, NotAfter = 11/27/2019 12:21:57 PM
    Elapsed Time: 0 ms.
    Checking the IIS configuration for client certificate authentication.
      Client certificate authentication wasn't detected.
     
    Additional Details
     
    Accept/Require Client Certificates isn't configured.
    Elapsed Time: 2276 ms.
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
      Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
     
    Additional Details
     
    Elapsed Time: 4270 ms.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://************.co.uk:443/Autodiscover/Autodiscover.xml for user ianelvar@************.co.uk.
      The Autodiscover XML response was successfully retrieved.
     
    Additional Details
     
    An HTTPS redirect was received in response to the Autodiscover request. The redirect URL is https://www.************.co.uk/Autodiscover/Autodiscover.xml.
    HTTP Response Headers:
    Connection: keep-alive
    Keep-Alive: timeout=20
    Content-Length: 178
    Content-Type: text/html
    Date: Wed, 11 Sep 2019 09:30:40 GMT
    Location: https://www.************.co.uk/Autodiscover/Autodiscover.xml
    Server: nginx
    Elapsed Time: 692 ms.
    Attempting to test potential Autodiscover URL https://www.************.co.uk/Autodiscover/Autodiscover.xml
      Testing of this potential Autodiscover URL failed.
     
    Additional Details
     
    Elapsed Time: 3577 ms.
     
    Test Steps
     
    Attempting to resolve the host name www.************.co.uk in DNS.
      The host name resolved successfully.
     
    Additional Details
     
    IP addresses returned: 35.189.125.64
    Elapsed Time: 48 ms.
    Testing TCP port 443 on host www.************.co.uk to ensure it's listening and open.
      The port was opened successfully.
     
    Additional Details
     
    Elapsed Time: 236 ms.
    Testing the SSL certificate to make sure it's valid.
      The certificate passed all validation requirements.
     
    Additional Details
     
    Elapsed Time: 763 ms.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server www.************.co.uk on port 443.
      The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
     
    Additional Details
     
    Remote Certificate Subject: CN=www.************.co.uk, Issuer: CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US.
    Elapsed Time: 712 ms.
    Validating the certificate name.
      The certificate name was validated successfully.
     
    Additional Details
     
    Host name www.************.co.uk was found in the Certificate Subject Common name.
    Elapsed Time: 0 ms.
    Certificate trust is being validated.
      The certificate is trusted and all certificates are present in the chain.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=www.************.co.uk.
      One or more certificate chains were constructed successfully.
     
    Additional Details
     
    A total of 1 chains were built. The highest quality chain ends in root certificate CN=DST Root CA X3, O=Digital Signature Trust Co..
    Elapsed Time: 20 ms.
    Analyzing the certificate chains for compatibility problems with versions of Windows.
      Potential compatibility problems were identified with some versions of Windows.
     
    Additional Details
     
    The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
    Elapsed Time: 0 ms.
    Testing the certificate date to confirm the certificate is valid.
      Date validation passed. The certificate hasn't expired.
     
    Additional Details
     
    The certificate is valid. NotBefore = 8/29/2019 11:24:41 AM, NotAfter = 11/27/2019 11:24:41 AM
    Elapsed Time: 0 ms.
    Checking the IIS configuration for client certificate authentication.
      Client certificate authentication wasn't detected.
     
    Additional Details
     
    Accept/Require Client Certificates isn't configured.
    Elapsed Time: 1143 ms.
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
      Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
     
    Additional Details
     
    Elapsed Time: 1385 ms.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://www.************.co.uk/Autodiscover/Autodiscover.xml for user ianelvar@************.co.uk.
      The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
     
    Additional Details
     
    A Web exception occurred because an HTTP 404 - NotFound response was received from Unknown.
    HTTP Response Headers:
    Transfer-Encoding: chunked
    Connection: keep-alive
    Keep-Alive: timeout=20
    Vary: Accept-Encoding,Accept-Encoding
    Link: <https://www.************.co.uk/wp-json/>; rel="https://api.w.org/"
    Cache-Control: no-cache, must-revalidate, max-age=0
    Content-Type: text/html; charset=UTF-8
    Date: Wed, 11 Sep 2019 09:30:43 GMT
    Expires: Wed, 11 Jan 1984 05:00:00 GMT
    Server: nginx
    Elapsed Time: 1385 ms.
    Attempting to test potential Autodiscover URL https://autodiscover.************.co.uk:443/Autodiscover/Autodiscover.xml
      Testing of this potential Autodiscover URL failed.
     
    Additional Details
     
    Elapsed Time: 3597 ms.
     
    Test Steps
     
    Attempting to resolve the host name autodiscover.************.co.uk in DNS.
      The host name resolved successfully.
     
    Additional Details
     
    IP addresses returned: 5.151.146.41
    Elapsed Time: 369 ms.
    Testing TCP port 443 on host autodiscover.************.co.uk to ensure it's listening and open.
      The port was opened successfully.
     
    Additional Details
     
    Elapsed Time: 187 ms.
    Testing the SSL certificate to make sure it's valid.
      The certificate passed all validation requirements.
     
    Additional Details
     
    Elapsed Time: 649 ms.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server autodiscover.************.co.uk on port 443.
      The Microsoft Connectivity Analyzer successfully obtained the remote SSL certificate.
     
    Additional Details
     
    Remote Certificate Subject: CN=*.************.co.uk, OU=Domain Control Validated, Issuer: CN=Starfield Secure Certificate Authority - G2, OU=http://certs.starfieldtech.com/repository/, O="Starfield Technologies, Inc.", L=Scottsdale, S=Arizona, C=US.
    Elapsed Time: 612 ms.
    Validating the certificate name.
      The certificate name was validated successfully.
     
    Additional Details
     
    The host name that was found, autodiscover.************.co.uk, is a wildcard certificate match for common name *.************.co.uk.
    Elapsed Time: 0 ms.
    Certificate trust is being validated.
      The certificate is trusted and all certificates are present in the chain.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to build certificate chains for certificate CN=*.************.co.uk, OU=Domain Control Validated.
      One or more certificate chains were constructed successfully.
     
    Additional Details
     
    A total of 1 chains were built. The highest quality chain ends in root certificate CN=Starfield Root Certificate Authority - G2, O="Starfield Technologies, Inc.", L=Scottsdale, S=Arizona, C=US.
    Elapsed Time: 15 ms.
    Analyzing the certificate chains for compatibility problems with versions of Windows.
      Potential compatibility problems were identified with some versions of Windows.
     
    Additional Details
     
    The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the "Update Root Certificates" feature isn't enabled.
    Elapsed Time: 0 ms.
    Testing the certificate date to confirm the certificate is valid.
      Date validation passed. The certificate hasn't expired.
     
    Additional Details
     
    The certificate is valid. NotBefore = 8/1/2019 12:04:23 PM, NotAfter = 8/13/2020 10:45:06 AM
    Elapsed Time: 0 ms.
    Checking the IIS configuration for client certificate authentication.
      Client certificate authentication wasn't detected.
     
    Additional Details
     
    Accept/Require Client Certificates isn't configured.
    Elapsed Time: 785 ms.
    Attempting to send an Autodiscover POST request to potential Autodiscover URLs.
      Autodiscover settings weren't obtained when the Autodiscover POST request was sent.
     
    Additional Details
     
    Elapsed Time: 1604 ms.
     
    Test Steps
     
    The Microsoft Connectivity Analyzer is attempting to retrieve an XML Autodiscover response from URL https://autodiscover.************.co.uk:443/Autodiscover/Autodiscover.xml for user ianelvar@************.co.uk.
      The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.
     
    Additional Details
     
    An HTTP 401 Unauthorized response was received from the remote Unknown server. This is usually the result of an incorrect username or password. If you are attempting to log onto an Office 365 service, ensure you are using your full User Principal Name (UPN).
    HTTP Response Headers:
    request-id: d1d497b6-ceb4-4556-9908-426d61521b65
    Set-Cookie: ClientId=HJPTYJEWGUATMFVPBQ; expires=Thu, 10-Sep-2020 09:30:42 GMT; path=/; HttpOnly
    Server: Microsoft-IIS/8.0
    WWW-Authenticate: Negotiate,NTLM,Basic realm="autodiscover.************.co.uk"
    X-Powered-By: ASP.NET
    X-FEServer: EXCHANGE-SERVER
    Date: Wed, 11 Sep 2019 09:30:41 GMT
    Content-Length: 0
    Elapsed Time: 1604 ms.
    Checking if there is an autodiscover CNAME record in DNS for your domain '************.co.uk' for Office 365.
      Failed to validate autodiscover CNAME record in DNS. If your mailbox isn't in Office 365, you can ignore this warning.
      Tell me more about this issue and how to resolve it
     
    Additional Details
     
    There is no Autodiscover CNAME record for your domain '************.co.uk'.
    Elapsed Time: 190 ms.

    I'll run through the instructions again just to check I didn't miss anything.

    Wednesday, September 11, 2019 9:39 AM
  • Doesn't appear to be anything I missed in the article, and re-installing WSUS doesn't fix the problem.

    There's definitely an issue with autodiscover authenticatation but I can't for the life of me figure out where. 

    Any suggestions welcome at this point.

    Wednesday, September 11, 2019 8:12 PM
  • Are the providers still listed under the Windows auth on that vDir ?

    You should have

    Negotiate

    NTLM

    listed in the providers section.


    Cheers,

    Rhoderick

    Microsoft Senior Exchange PFE

    Blog: http://blogs.technet.com/rmilne  Twitter:   LinkedIn:   Facebook:   XING:

    Note: Posts are provided “AS IS” without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.

    Thursday, September 12, 2019 2:12 AM
  • Hi Rhoderick

    Yep, they're still listed. I've been through and checked settings against another Ex2013 setup, and as far as I can see it's all present and correct in IIS manager. My guess at this point is that something has been changed in the IIS global config, but I can't see what. 

    Thursday, September 12, 2019 5:33 PM
  • After removing the autodiscover virtual directory via powershell, adsiedit and metabase explorer, then recreating I can now get it to accept credentials if using firefox and IE, but curiously not chrome. The connectivity test tool still fails with the same error, and Outlook on domain joined machines still fails after prompting for and rejecting credentials in any format.

    Re-installing WSUS made no difference either, so it may, in fact, be unrelated. It's certainly a puzzling one.

    Friday, September 13, 2019 7:36 PM
  • After removing the autodiscover virtual directory via powershell, adsiedit and metabase explorer, then recreating I can now get it to accept credentials if using firefox and IE, but curiously not chrome. The connectivity test tool still fails with the same error, and Outlook on domain joined machines still fails after prompting for and rejecting credentials in any format.

    Re-installing WSUS made no difference either, so it may, in fact, be unrelated. It's certainly a puzzling one.

    If recreating the vDir makes no difference, I would check if all the updates on the server OS have been installed since once WSUS is removed, you may leave your OS an out-of-date version.

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, September 17, 2019 8:49 AM
    Moderator
  • It's fully patched right up to date - I was hoping it would be something simple like that too. 

    Client has agreed to raise a ticket with MS, so I'll update the thread once they've figured out what's going on.

    I even removed and re-installed integrated windows auth from IIS, but no change.

    For further info: enabling digest auth on the autodiscover vdir will let Explorer and Firefox authenticate (but not chrome), giving the correct XML response. Connectivity tools, both online and Test-OutlookWebServices still fail. 

    Wednesday, September 18, 2019 11:47 PM
  • It's fully patched right up to date - I was hoping it would be something simple like that too. 

    Client has agreed to raise a ticket with MS, so I'll update the thread once they've figured out what's going on.

    I even removed and re-installed integrated windows auth from IIS, but no change.

    For further info: enabling digest auth on the autodiscover vdir will let Explorer and Firefox authenticate (but not chrome), giving the correct XML response. Connectivity tools, both online and Test-OutlookWebServices still fail. 

    OK, I would also suggest you open a ticket with MS support if issue here is urgent. 

    We all will keep an eye on your update on this thread and look forward to your good news!

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Thursday, September 19, 2019 2:28 AM
    Moderator
  • Any update on this issue? Did you get some clues from MS support?

    Regards, 

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Monday, September 23, 2019 9:55 AM
    Moderator
  • Hi Manu

    Thanks for checking in. It's been an interesting one. MS confirmed in a lengthy remote session that the VDir's, Exchange install and DC are configured and functioning correctly and that the problem is indeed related to IIS integrated Windows auth failing on the Exchange VDir's. 

    They're in the process of analysing the web.config files for various Exchange VDir's, and in the meantime I did a little more work myself. I found that the Windows Update cache on the DC appeared to be corrupt, as it was claiming the system was fully patched despite recent updates not showing as installed as checked against the update catalog. I'd already verified it was set correctly to get updates direct from MS as WSUS had been removed from the site. Having rebuilt the cache, it found a few fresh updates (it wasn't far out-of-date) which I installed one at a time. None had any effect on the Exchange issue until KB4516055 (2019-09 Monthly Quarterly Rollup for Server 2012) was installed, after which Windows auth started working correctly when using a browser to connect to the autodiscover xml file. Outlook also now works correctly. The Exchange machine is verified as patched fully up-to-date. 

    However, Test-OutlookWebServices still fails with the same 401 error. I still have the case open and will hopefully talk to the MS tech in the morning as I'm mindful there's something still not correct. I'll update the thread as things progress. 

    Best regards

    Thursday, September 26, 2019 8:43 PM
  • Hi Manu

    Thanks for checking in. It's been an interesting one. MS confirmed in a lengthy remote session that the VDir's, Exchange install and DC are configured and functioning correctly and that the problem is indeed related to IIS integrated Windows auth failing on the Exchange VDir's. 

    They're in the process of analysing the web.config files for various Exchange VDir's, and in the meantime I did a little more work myself. I found that the Windows Update cache on the DC appeared to be corrupt, as it was claiming the system was fully patched despite recent updates not showing as installed as checked against the update catalog. I'd already verified it was set correctly to get updates direct from MS as WSUS had been removed from the site. Having rebuilt the cache, it found a few fresh updates (it wasn't far out-of-date) which I installed one at a time. None had any effect on the Exchange issue until KB4516055 (2019-09 Monthly Quarterly Rollup for Server 2012) was installed, after which Windows auth started working correctly when using a browser to connect to the autodiscover xml file. Outlook also now works correctly. The Exchange machine is verified as patched fully up-to-date. 

    However, Test-OutlookWebServices still fails with the same 401 error. I still have the case open and will hopefully talk to the MS tech in the morning as I'm mindful there's something still not correct. I'll update the thread as things progress. 

    Best regards

    Thanks for your update.

    Regards,

    Manu Meng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Monday, September 30, 2019 9:39 AM
    Moderator