none
Required domain/forest level for some group policy settings?

    Question

  • I've been beating my head against some group policy settings that just are NOT working on a 2012 R2 RDS server, but work fine on another one at a different location.

    But I just remembered that the problematic site, while we have a 2012 R2 DC, is still stuck at a 2003 domain/forest level since we're still waiting for their software developers for this program of theirs to migrate them off of that 2003 domain controller where  it was initially installed, and onto a new server we recently put into play.

    So the only thing that is different between where these settings work, and where they don't, is really the forest and domain level.  Where it worked as expected, it's native 2012 R2 levels for everything.  Where it fails, we have that last 2003 domain controller still in play.

    Is there some place I can find out what level those need to be for things to work, such as folder redirection for Start Menu, and similar things?  I've been googling my rear end off, but haven't found anything yet that helps me find the required domain and forest level for these settings.

    Thanks

    John


    John



    • Edited by jdthird Friday, July 08, 2016 7:27 PM
    Friday, July 08, 2016 7:25 PM

Answers

  • Solved it. 

    Since the software developer is still working on their software, I was applying things only to a specific remote desktop users group that my test accounts were in.  So the security filtering showed that, as opposed to the default "authenticated users" entry so I wouldn't interfere.

    But that then apparently was enough to prevent this from actually applying to the terminal server, despite the group policy modeling and results showing these objects applying to this terminal server anyway.

    So once I explicitly added the terminal server computer object under security filtering, everything applied.

    I really wish the modeling and results would accurately reflect this, instead of showing the whole time that the policies should apply to the computer with the user in question done with the modeling...


    John

    • Marked as answer by jdthird Monday, July 11, 2016 3:11 PM
    Monday, July 11, 2016 3:11 PM

All replies

  • Hi John.

    Thanks for your post.

    For forest functional level, it depends on the least version of operate system of DC in your Active Directory forest.

    For domain functional level, you need set it to less than or equal to the least version of operate system of DC in your Active Directory domain.

    For example, if there is Windows Server 2003 in you forest, but it is not member of sub-domain. There are only Windows Server 2012 DCs in your sub-domain.

    You need set forest functional level to Windows 2003 or lower, and you could set domain functional level for sub-domain to Windows Server 2012.

    Here is an article below about Active Directory Functional Levels for your reference.

    What Are Active Directory Functional Levels?

    https://technet.microsoft.com/en-us/library/cc787290(v=ws.10).aspx

    Best Regards,

    Jay


    Please remember to mark the replies as answers if they help and un-mark them if they provide no help. If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, July 11, 2016 2:36 AM
    Moderator
  • > I've been beating my head against some group policy settings that just
    > are NOT working on a 2012 R2 RDS server, but work fine on another one at
    > a different location.
     
    Group Policy has no requirements for DFL/FFL in any way - it only
    requires some schema versions (for WLAN and wired settings e.g.)
     
    You might be more specific what exactly is not working, what is recorded
    in the GPO eventlog and so on :-)
     
    Monday, July 11, 2016 9:40 AM
  • It's the start menu redirection.  Trying to have a single simplified list of programs available for the users on this RDS system.  I wasn't sure if having that 2003 DC still stuck until their software vendor moves their stuff off of it onto a newer one could be part of the issue.  GP modeling and GP results show everything as I'd expect - and the one in question is shown as being applied.  Not a single GP error in the event logs on the DC's or on the 2012R2 RDS server, nor any other errors. 

    It's the exact same setting we've got going on multiple other terminal servers without issues.

    And the redirected path works great from start/run, user is not set for exclusive rights, etc...  And on the other terminals we have, it works flawlessly.  Here, that start menu never gets redirected.

    I've backed up the settings from another DC for this one policy and then imported it here, changing the settings for the different group and server name and path, obviously, no joy.  Deleted it utterly, recreated a new one from scratch with the same settings, and nothing I do has this one redirecting the start menu.

    I've denied inheritance and removed the other terminal ones we had so only this redirection would apply, and still nothing. 

    I've never had one just fail like this with no errors, but I also don't have any other networks with a 2003 DC still in play, which is why I figured I'd see if there was some way to find out if that may be interfering.  But I really couldn't see why, since the schema was expanded with the introduction of the newer servers, so the settings should be there, but since this is all ADMX, I didn't know if when the 2003 DC was the one doing the authentication, if that would make a difference.  I'm using a central repository and the GP objects all show using the central repository. Group policy modeling and results both show things as I would expect, even when I specify the 2003 DC vs the 2012R2 DC in the first step. 

    At least when I first started doing this with terminals, if I had bad security settings or something, I'd see the error about permissions in the event logs, would see GP errors, but I have no errors.  So it's a bit confusing...

    There has got to be something that I'm just missing, forest for tree kind of thing then, but so far I'm not finding it.


    John

    Monday, July 11, 2016 1:41 PM
  • Solved it. 

    Since the software developer is still working on their software, I was applying things only to a specific remote desktop users group that my test accounts were in.  So the security filtering showed that, as opposed to the default "authenticated users" entry so I wouldn't interfere.

    But that then apparently was enough to prevent this from actually applying to the terminal server, despite the group policy modeling and results showing these objects applying to this terminal server anyway.

    So once I explicitly added the terminal server computer object under security filtering, everything applied.

    I really wish the modeling and results would accurately reflect this, instead of showing the whole time that the policies should apply to the computer with the user in question done with the modeling...


    John

    • Marked as answer by jdthird Monday, July 11, 2016 3:11 PM
    Monday, July 11, 2016 3:11 PM
  • > But that then apparently was enough to prevent this from actually
    > applying to the terminal server, despite the group policy modeling and
    > results showing these objects applying to this terminal server anyway.
     
    MS16-072...
     
    Wednesday, July 13, 2016 4:50 PM