DirectAccess Connectivity Assistant is not properly configured RRS feed

  • Question

  • I am trying to reconfigure our DirectAccess Connectivity Assistant and am having a horrlbe time troubeshooting this problem. The previous IT person left no documentation. After weeks of reading through forums and the admin guide, I hope someone can help me resolve this issue.  Let me preface by saying that I'm pretty sure our DirectAccess died at the same time our CA did. After figuring that out and reconfiguring our settings, there was a problem with Group Policy which has been corrected.  Oddly, MS Outlook is still able to send and receive messages eventhough not all network resources are available in it's current state. Here is my command line output:


    netsh dns show state

    Name Resolution Policy Table Options

    Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                            if the name does not exist in DNS or
                                            if the DNS servers are unreachable
                                            when on a private network

    Query Resolution Behavior             : Resolve only IPv6 addresses for names

    Network Location Behavior             : Let Network ID determine when Direct
                                            Access settings are to be used

    Machine Location                      : Outside corporate network

    Direct Access Settings                : Configured and Enabled

    DNSSEC Settings                       : Not Configured


    netsh int httpstunnel show int

    Interface IPHTTPSInterface (Group Policy)  Parameters
    Role                       : client
    URL                        :
    Last Error Code            : 0x80092013
    Interface Status           : failed to connect to the IPHTTPS server. Waiting to


    • Edited by RT29406 Tuesday, August 16, 2011 7:20 PM corrected typos
    Tuesday, August 16, 2011 6:49 PM

All replies

  • Hi,

    It looks like you have a problem with the IPHTTPS certificate (Error code 0x80092013).
    Does that cerficate come from your internal CA or is it bought from an external services?

    If it is from your internal CA, can external clients verify the CRL?


    A good blogpost on how to start troubleshooting/verifying the CRL's


    Error codes: 


    The text related to your errorcode:
    "The revocation function was unable to check revocation because the revocation server was offline."

    //Jonas Blom

    • Proposed as answer by Kai Wilke Thursday, August 18, 2011 8:32 AM
    • Unproposed as answer by RT29406 Thursday, August 18, 2011 11:54 AM
    • Proposed as answer by John Moeller Thursday, October 18, 2012 4:37 PM
    Wednesday, August 17, 2011 5:52 AM
  • Does that cerficate come from your internal CA or is it bought from an external services?

    If it is from your internal CA, can external clients verify the CRL? 

    Yes, the certificate comes from our internal CA which is up and running properly unlike the old CA that died.

    It would seem our CRL distribution point needs to be reconfigured since it is now on a different CA.  I found an article on how to configure CRL Distribution Point Certificates ( but cannot complete  the virtual directory creation due to the following error:

         There was an error while performing this operation. 
         Details: Filename: \\?\UNC\dfs-share1\SharedConfig$\applicationHost.config
         Error: Cannot write configuration file.

    I'm researching and trying to figure out how to get past this. If you can provide any help, it would greatly be appreciated.



    Thursday, August 18, 2011 2:23 PM
  • Hi again,

    Two things,

    Your current IPHTTPS certificate already has CRL Distribution points defined.
    (You can check what they are by opening up the certificate and look on the Details pane, the field is called "CRL Distribution Points")

    This is the URL's that your DirectAccess clients will try to reach to verify the certificate.

    If you want to change the paths you will have to issue a new certificate and replace the current one.


    The other part,

    Regarding the errormessage you get, are you trying to create the virtual directory on a fileshare on another server than where you try to setup your IIS?

    Ie, do you get the errormessage when you follow the steps outlined below  "To create a Web-based CRL distribution point"  in your link?

    A suggestion, create the folder locally on the server where you want your CRL's to be published.

    And make sure that clients can reach the CRL both from inside and outside your network.


    //Jonas Blom


    Thursday, August 18, 2011 2:44 PM
  • Jonas has you on the right track to recovery, but also keep in mind that your troubles would be much less if you considered moving to an SSL certificate provided by a public CA for IP-HTTPS. This would be a cheap answer to all of your problems :) When purchasing a certificate, you let the public CA deal with CRLs and making sure that they are highly available. Even if/when you do get your CRL published, it will still be a single point of failure unless you dive even deeper into your PKI infrastructure and make everything redundant.

    Thursday, August 18, 2011 7:27 PM
  • Good morning,

    I feel as though I'm not explaiing properly and for that I apologize. The site was previously created by my predecessor and was working until the old CA's CRL expired. I have created a new CA since I was unable to fix the old one. I have also created a new certificate. The problem I am having is reconfiguring the virtual directory on the existing fileshare so that I can publish the CRLs.

    Yes, I am receiving the error message when I follow the steps outline below "To create a Web-based CRL distribution point." Editing the existing one is causing errors so I figured try again with a new one but I am still getting errors.

    I hope my explanation helps.

    Thank you for all of your help thus far.


    Friday, August 19, 2011 2:40 PM
  • Hi again,


    If the problem is to configure the virtual directory in IIS, configure the fileshare to be a local folder instead? (for example: C:\crls\)

    The important part when publishing CRL is that the certificate that you have issued contains something that the clients can reach from external.
    (Ie, a HTTP based url that you have published externally)
    Then how those files are accessed by the IIS and/or transfered from the CA to the webserver, that has no real impact on how the external users verify the CRL.

    I normally have the following setup configured in my CA's for getting the CRL's
    \\srv\crl$ for publishing the files from the CA server directly to the webserver

    But this is often during PoC's, during real deployment it is always simpler to do as Jordan says and use an externally issued certificate for the IPHTTPs certificate.

    Hope these commments helps you to get to a working setup.

    Best wishes,
    Jonas Blom

    Monday, August 22, 2011 3:29 PM
  • You can check out this BaseConfig document which includes step-by-step inscrutions on how to configure the CRL with an HTTP distribution point.  It might help you figure out how to publish your internal CA's CRL externally.

    But you may also find it easier to just get a 3rd party certificate to use on the IP-HTTPS site.

    This might help too.

    MrShannon | Concurrency Blogs | UAG SP1 DirectAccess Configuration Guide
    • Proposed as answer by MrShannon Thursday, August 25, 2011 1:52 PM
    • Unproposed as answer by RT29406 Thursday, August 25, 2011 1:52 PM
    Thursday, August 25, 2011 1:52 PM
  • My CRL distribution point has been fixed and can be accessed externally. Thanks for providing that documentation but it would seem that is only part of my configuration's problem.

    I'm now running into a different issue and forgot to post about it yesterday. I'm getting a 0x2afc error when I run the netsh int httpstunnel show interfaces command on the client. I am also getting a "Internet Explorer cannot display the webpage" when I try to access the IPHTTPS site while connected to an external ISP and while connected to the LAN, I receive an HTTP 403 error.

    When I try to confirm connectivity to our DNS server and domain controller using the nltest /dsgetdc: command, I receive "Getting DC name failed: Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN.

    I'm still reading researching and will follow up if I figure it out in hopes this will help someone else who is having the same issues.


    Thursday, August 25, 2011 2:08 PM
  • If you punch in your IP-HTTPS URL exactly: and do not get the 403 from outside your network, then I would focus on that. First make sure that your DNS entry for "" is pointing to the correct place, the primary public IP address on your UAG server. If it is, then try reactivating the UAG configuration so that it attempts to restart the IP-HTTPS settings and services. You should get the 403 when browsing to that exact site address.
    • Marked as answer by Erez Benari Friday, August 26, 2011 10:13 PM
    • Unmarked as answer by RT29406 Friday, August 26, 2011 11:30 PM
    Thursday, August 25, 2011 8:05 PM
  • I'll pick this up on Monday. Please don't mark as an answer yet. Thanks.
    Friday, August 26, 2011 11:33 PM
  • I just wanted to add to this thread that although I had working, web-accessible CRL, my test DirectAccess clients would fail to connect after a day or two. This was because my CRL was not an exception in my NRBT, causing a chicken and egg problem. I'm hoping that adding my web-based CRL to the NRBT exception list solves my issue.

    This thread was very helpful to me.
    Thursday, October 18, 2012 4:37 PM