2012 RDP / RDS Remote Desktop Terminal Server incompatible with Windows 2016 Domain Controllers? Access Denied


  • So we have a few 2012 R2 Terminal Servers at my company that were working fine until we started the process of replacing our Domain Controllers with new Windows 2016 Servers.

    Since then our users are getting intermittent "Access Denied" errors when they try to RDP to these terminal servers.

    Generally the "Access Denied" error occurs when a terminal servers starts to use one of the newly added 2016 domain controllers. We can workaround the problem by sending an command telling the terminal server to use one of the older 2012 R2 domain controllers instead. Then things work again.

    So the question:

    Is there a misconfiguration with the new 2016 domain controllers or can an adjustment be made with the 2012 Terminal Servers?

    Is the problem that Windows 2016 Domain Controllers are not compatible with 2012 R2 Remote Desktop Services servers?

    We are having problems finding documentation on this.

    What we do know is that if we decide to start upgrading to new 2016 Terminal Servers we will have to purchase new 2016 RDS Cals (not sure if we are budgeted for that...)

    For those interested, you can find out the domain controller you are using by running the following elevated PowerShell command (this assumes the command is run remotely as you might be locked out due to the RDP access denied error):

    nltest /Server:<your-terminal-server> /DSGETDC:<ad domain>

    to specify the domain controller you want to be on (in our case we want to switch to back to a 2012 R2 domain controller), the command is:

    nltest /Server:<your-terminal-server> /SC_RESET:<ad domain>\<specific domain controller>

    Sunday, July 8, 2018 6:11 AM

All replies

  • Hi,

    In general, different OS version of DC will not causing problem. Main added feature in newer version of DC may provide new GPs. Also, WS 2016 is next version of WS 2012 R2, there should be no compatibility problem between them. 

    Also, RDS has no specific requirement about DC version. 

    As you mentioned that, 2016 RDS CALs can only be installed on WS 2016, and if you want to access 2016 RD SH, then, 2016 RDS CALs are necessary. However, if new WS 2016 is only added as DC, there should no effect on your existing RDS deployment. 

    I am not sure if it is user account authentication failure on new DC and causes such problem. Please check Event on your new DC and there may be helpful information.

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, July 10, 2018 6:23 AM
  • Hi,

    How things are going there on this issue?

    Please let me know if you would like further assistance.

    Best Regards,
    Eve Wang

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Thursday, July 12, 2018 1:50 AM
  • Thanks, I will confer with our DC admin to see what he thinks and will reply back on Monday. Thanks again.
    Friday, July 13, 2018 7:17 AM
  • I've been working with the DC admins but they have not found errors on the new domain controller corresponding to the Access Denied messages that occur on the 2012 R2 Terminal Servers (when the secure channel is pointing to our new WS 2016 DC). The 2012 R2 Terminal Servers also do not show failures corresponding to the Access Denied message in the System, Application or Security log. 

    This is how the Access Denied message looks:

    This access denied message only appears if the secure channel is pointing to the new 2016 domain controller.

    One error that has also manifested recently though it doesn't seem to stop authentications is under the RD Licensing Manager is shows the following under "Review":

    "The system cannot determine if the license server is member of TSLS Group on Active Directory Domain Servers (AD DS) because AD DS cannot be contacted".

    I have verified though that the RDS License server in question is part of the built in Terminal Server License Server (TSLS) group on AD.

    Generally I can get rid of this above error by resetting the secure channel (even if to the same one it is already on).

    I'm not sure if this is a clue to what might be going.?

    Once again this is a 2012 R2 Active Directory Domain comprised at the moment mainly of 2012 R2 domain controllers and one 2016 domain controller that has been put into the mix as we try to slowly upgrade to have all 2016 domain controllers.

    Tuesday, July 17, 2018 4:33 AM
  • Hello Eve,

    I received the following recommendation from a contributor from another forum:

    "We opened a ticket with MS support on this. They had us add this registry on the Windows 2016 DC's and it resolved the issue.

    HKLM\SYSTEM\CurrentControlSet\Control\Lsa add the value RestrictRemoteSamAuditOnlyMode DWORD=1 Reboot the server"

    Monday, July 23, 2018 5:41 AM
  • We encountered this problem yesterday, when we first added a 2016 Domain Controller to a 2012 R2 domain.

    The problem is caused by a new policy: “Network Access: Restrict clients allowed to make remote calls to SAM”, which is documented in this article (

    In our case, the policy was set in our SOE to only allow Administrators (the default for a non-DC server), and when the server was promoted to become a DC, the policy did not get reset to the default for a domain controller. 

    Changing the local security policy on the new DC to allow Everyone access resolved the problem.

    The registry key mentioned above by @mk2002 is also described in the article: "Audit only mode configures the SAMRPC protocol to do the access check against the currently configured security descriptor but will not fail the call if the access check fails."

    • Edited by TallPaulF Thursday, July 26, 2018 12:15 AM Add audit mode info
    • Proposed as answer by TallPaulF Thursday, July 26, 2018 1:39 AM
    Wednesday, July 25, 2018 11:40 PM