none
DirectAccess Server 2012 Configuration cannot be retrieved from domain controller

    Pergunta

  • Hi everyone,

    We are using DirectAccess over Server 2012. There is just one server, no load balancing.

    Everything works fine, all clients can connect successfully and operations status page shows all in green. Nevertheless on the dashboard page in the configuration status section it say “Configuration for server [servername] cannot be retrieved from the domain controller.”

    I found a few hints what could cause this problem:

    In my case, the RAConfigTask, a scheduled task, was not enabled on the affected WS2012 server (DA entry point in a multisite deployment). After just enabling it, the errors has gone." http://blog.gocloud-security.ch/2013/01/11/ws2012-directaccess-and-the-configuration-for-server-server-name-retrieved-from-the-domain-controller-cannot-be-applied-error/

    Group Policy was filtering out my DA server from the GPO object for some reason. To fix, I opened up Group Policy Management on the domain controller and made sure that my DA server was a part of the group."http://www.joedissmeyer.com/2012/12/more-issues-and-solutions-for.html

    Server has no connectivity to the domain in order to update the policies. Run “gpupdate /force” on the server to force policy update. GPO replication might be required in order to retrieve the updated configuration.  This could be because there is no writable domain controller in the Active Directory site of the Remote Access server. http://social.technet.microsoft.com/Forums/en-US/winserverNIS/thread/56fedb17-1274-4e1a-b2d0-fea809f0bc45

    I checked everything. Task is enabled and completed successfully, GPO is not filtered out, run gpupdate without any errors, could connect to domain controller, no errors on domain controller, domain controller is writable.

    So, I have no idea what could cause this error. Any ideas or hints?

    Thanks

    Regards

    Sebastian


    • Editado skrueck quinta-feira, 13 de junho de 2013 13:48
    quinta-feira, 13 de junho de 2013 13:47

Todas as Respostas

  • i have the exact same problem i figured out that there was a problem with the logon as a service

    secpol.msc --> Local Policies --> User Rights Assignement, Logon as a service i have NT Service\All Services

    i can acces the group policy via the cpnsole just fine i have not connectivity issues what so ever.

    i decided to open a call with microsoft, their suggestion .... we dont know reinstall so i did and here we are same problem and no solution. it is getting frustrating...

    quarta-feira, 30 de abril de 2014 08:08
  • Exact  same problems here. Anyone find a solution please post.

    Ken

    terça-feira, 10 de junho de 2014 14:14
  • G'day,

    I had the same issue, I literally waited 15 minutes and then clicked refresh and it was all good.

    Hope that helps someone

    quinta-feira, 21 de agosto de 2014 11:19
  • Hi All - i have seen this where sites and services have not been configured in AD and also when replication of GPO's between Domain Controllers has an issue - perhaps just check all is well with the DC's.

    John Davies

    sexta-feira, 22 de agosto de 2014 10:32
  • I have a similar issue that says that I dont have access to the GPO. The Direct Access itself still works, but all of the sudden I cannot access the wizard to make changes or see the configuration. I have done the same troubleshooting you listed above and found no answer thus far. I have a ticket open with Microsoft on the issue. If/when I get a resolution I will share it.  
    segunda-feira, 25 de agosto de 2014 19:27
  • I have a similar problem. The GPO is downloaded to the server, but the scheduled task that applies the setting fails with code "0x1" but no where can one see what the code does, or whats going wrong. Elsewhere its suggested that certificates on the hidden interfaces are whats causing the problem, but why hide all the interfcaes....
    quarta-feira, 10 de setembro de 2014 10:28
  • I wonder if there is a RODC in play here. RODC's don't allow you to access GPO settings.

    I'm getting the same error and I think it's because the server is on the same subnet/site as the RODC we have in our DMZ. I'm thinking if there is a way to force the logon to only go to specific domain controllers, then I can skip the RODC for AD queries and tasks.

    quinta-feira, 11 de junho de 2015 19:03
  • Hi,

    Using DirectAccess with RODC is not supported : https://technet.microsoft.com/en-us/library/dn464274.aspx?f=255&MSPPError=-2147217396#bkmk_rodc

    You can try to use the Windows Firewall of your DirectAccess server to deny connexions to the RODC's IP Address.

    Check also this article, it's for Windows 7 but it may help you: http://www.windowsnetworking.com/kbase/WindowsTips/Windows7/AdminTips/ActiveDirectory/Hardcodingthelogondomaincontroller.html

    Gerald

    quinta-feira, 11 de junho de 2015 20:18
  • You should check if the DC that DirectAccess communicates with is still available. Each entrypoint will pick a domain controller to communicate and it will get/write the policy only against that DC.

    for this you should use the get-daentrypointdc command

    • Sugerido como Resposta pat-man terça-feira, 2 de agosto de 2016 21:38
    • Não Sugerido como Resposta pat-man terça-feira, 2 de agosto de 2016 21:39
    • Sugerido como Resposta pat-man terça-feira, 2 de agosto de 2016 21:39
    sexta-feira, 17 de julho de 2015 06:33
  • Hi,

    We also have this problem in a new deployment.  I have added the server subnet to sites and services and also added the server account to the GPO object and removed authenticated users.  Tried running Set-DAEntryPointDC command but it's not a multi site deployment so doesn't apply.

    Suggestion:  Do 2012 ADMX GPO Templates require installing?    

    Tried a re-install but still no joy.  Anyone else got any suggestions for further troubleshooting steps?  Thanks.


    • Editado MattRW sexta-feira, 24 de julho de 2015 09:37
    • Sugerido como Resposta MattRW sexta-feira, 31 de julho de 2015 16:34
    sexta-feira, 24 de julho de 2015 09:36
  • Hi,

    Managed to crack this, redeployed a fresh version of Windows 2012.  Patched but did not upgrade .NET, left it as native.  Increased the IPv4 adapter order up so it was higher than IPv6.  Internet / DMZ link added a missing default gateway.  Internal LAN removed default gateway.  DOS - added a static route for the internal LAN.

    • Sugerido como Resposta MattRW sexta-feira, 31 de julho de 2015 16:34
    sexta-feira, 31 de julho de 2015 16:34
  • Check which DC is your operations master, since this is the one that has the config for the Direct Access, and make sure it is online and working.
    domingo, 11 de outubro de 2015 19:32
  • you need to change the public ip address to a fully qualified domain name instead. IP address will not work
    sexta-feira, 25 de março de 2016 12:33
  • FQDN solved all my problems, thanks!
    quinta-feira, 5 de maio de 2016 20:27
  • You should check if the DC that DirectAccess communicates with is still available. Each entrypoint will pick a domain controller to communicate and it will get/write the policy only against that DC.

    for this you should use the get-daentrypointdc command

    All Hail Vlad The Impaler! Pierced right through to my problem, which was that the DCs originally assigned to my multisite entry points had been replaced by new ones; took a bit of fiddling about with the three variants of the 'Set-DAEntryPointDC' command to resolve it but got there eventually. Top tip.

    After all is said and done, a whole lot more is said than done.

    terça-feira, 2 de agosto de 2016 22:04
  • I had some of the symptoms described in this thread (RAConfigTask throwing 0x1 in task scheduler, file not found / unable to retrieve config errors). For me it turned AD SYSVOL replication issues. In a multi DA server deployment some DCs had stale copies of the DA policies so different DA servers ended up with different policies.

    Apparently DirectAccess has problems if your domain is using FRS for your AD replication and this is unsupported.

    The fix for me was to migrate from FRS to DFSR based AD replication.

    DirectAccess is a temperamental beast, great when it works, but it can be frustrating getting it working.

    sexta-feira, 30 de setembro de 2016 14:05
  • My fix was to change the IP4V connection from an IP Address to a FQDN.  That change actually fixed 3 things:

    1)IP-HTTPS and Services now show a Green Checkmark (from Blue Question Mark).

    2)Configuration Status now Green (from unavailable).

    3)Any time I went into Reporting the MMC Console would crash.  Now it opens properly.

    Such a small thing - don't know why the wizard advises you can have a IP Address on the NetworK Topology screen - since that is obviously wrong.

    terça-feira, 15 de agosto de 2017 15:43
  • It sounds like some of you guys had various different problems causing the issue. Here are some of the things I've run across which have caused similar issues, and which reflect some of your experiences, with explanations on why it happens:

    1. DirectAccess is not supported if you are still using FRS. This actually has nothing to do with DirectAccess itself, but rather that FRS sucks and your GPOs could be deleted or tweaked inadvertently when the DA wizard updates them. This can cause issues with the Remote Access console not being able to properly read the GPO, even though you can see it inside GPMC. The only fix for this weird behavior is to move to DFS.

    2. Proper networking configuration is critical to making DA work properly. DA works best in two-NIC mode, and in doing so you need to know how to properly multi-home a server. You can only have one Default Gateway - and it must go on the External NIC. NO Default Gateway on the Internal NIC! Yes this means you need to add static routes to Windows in order to make it communicate with all parts of the network that you want it to. :)

    3. Don't try to make DA run its IP-HTTPS listener on an IP address, always use a public DNS name. I also do not know why it allows you to enter an IP address, but really, who's gonna issue an SSL certificate based on a Subject Name of an IP address? Which makes me wonder if those who were running it with an IP address were using the option for self-signed certificates - this is a big security no-no and you should move to using a DNS name if only because you really should be using a third party SSL cert from a public CA to protect your incoming IP-HTTPS traffic. Never use self-signed certificates.

    Hope this helps someone who may come across this thread in the future!

    sexta-feira, 8 de setembro de 2017 20:03