A Word about Working with GPOs and Terminal Servers
A word about working with Group Policy Objects (GPOs) and Terminal Servers
Recently I had a long conversation with one of my clients about the proper way for using GPOs. I think my readers could benefit from the stuff that was said there. Naturally, the client’s name and details are not an issue and are not disclosed, what matters is the essence of the conversation.
The client wanted to have a GPO for locking users’ settings on some Terminal Servers machines. He wanted to have the settings apply to any user that logs on to the TS, while the Administrators group should not receive the same settings.
I had suggested that he create an OU for the TS servers and place them inside:
Then, create an OU for the users, and place them inside:
Now comes the tricky part – creating the right GPO for the users, and configuring it to apply to the TS servers.
A GPO has two parts – the Computer Settings part and the Users Settings part, as you can see from the following screenshot:
Some of the settings that control the user’s ability to perform actions such as shutting down the server, accessing a floppy, getting access to the Control Panel, the Run command and others are all part of the User Settings half of the GPO. Whenever a user logs on to a computer that is in the same OU as the user object then both parts of the GPO are applied to the Computer/User combination.
If you create and link a GPO to the users’ “home” OU, then the User Settings half of the GPO will apply to the user no matter where he logs on to. But in most cases these settings should only be applied when the users log on to the TS machines, and not when they log on to a “regular” workstation. So you cannot configure the GPO restrictions on the user’s “home” OU, and will need to configure it to be linked to the TS OU instead.
Problem: However, and here lies the problem, in case of Terminal Servers, usually the TS machines are in one OU and the User objects are in a different OU, and since the TS machine does not apply the User Settings half of the GPO you will find out that all of the settings that are part of the user’s “home” OU-linked GPO will not be applied to the TS session.
Solution: The solution is to create a User Settings GPO for the TS OU and NOT to the user’s “home” OU (unless of course you want these restrictions to apply to the users no matter where they log on to). You should then configure the Loopback Processing Mode of that GPO to “Replace”, rather than “Merge” (which is the default):
The setting can be found in the following path:
Computer Settings > Administrative Templates > System > Group Policy > User Group Policy Loopback Processing Mode – Set to “Enabled” and configure it to the “Replace” setting.
That way, the users’ “home” OU-linked GPO will apply when the users log on to any workstation other than the TS servers themselves.
The next issue was to configure these GPO restrictions not to apply on the Administrators group. In order to do that we need to configure GPO Filtering.
The strange thing with GPOs (Group Policy Objects) for those that are new to the stuff is that GPOs do NOT have any effect on groups! If you want a GPO to be applied to a user you must have the user account moved to the OU where the GPO is linked to. Same goes for a computer. You must move the computer account to the OU where the GPO is linked to. You cannot make the user a member of a group, put the group in an OU, and link a GPO to that OU and expect it to apply to the group’s members. It doesn’t work that way.
However, as said earlier, you could use GPO Filtering to control who does NOT get the GPO applied to it. You can use groups for that, but not INSTEAD of moving the users to the right OU.
So for example, if you have 100 users in an OU and a GPO linked to it, all 100 users will get the GPO. If you create a group and put an X number of users into that group, and put the group in the delegation advanced button and give it a “Deny GPO” permission, then 100-X users will be affected by the GPO, and the X users won’t.
For example, let’s create a group called “GPO Settings do not apply to me” (strange name, but it’ll pass my point clearly):
Make the Administrator (or any other user object) a member of that group. Note that neither the group nor the specified user account need to physically be in that OU. The group and the user account(s) can be in ANY OU.
Next, configure the GPO Filtering of the TS GPO (the one that you do NOT wish to have an effect on these specific users) in such a way that it will deny applying the GPO for that group:
In GPMC browse to find the GPO link, click on the Delegation tab, then on the Advanced button.
Then add the group (the one called “GPO Settings do not apply to me”), and then click Deny on the Apply Group Policy permission:
An important note about GPO Filtering: You’re not supposed to use the filtering option as your MAIN method of choosing who’s going to get a GPO and who’s not. You’re supposed to work with OUs and use the natural effect of inheritance to determine who’s getting the GPO and who’s not. Filtering, although very useful, can turn out into an administrative headache, so do NOT rely on it, except when needed, such as when you need to filter out one or two single users from 1000 users, and these 2 users cannot be moved from that OU because of other reasons.
More in Active Directory
Microsoft Releases Out-Of-Band Patches to Fix Windows AD Authentication Issues
May 20, 2022 | Rabia Noureen
Cloud Conversations – Ståle Hansen on Digital Wellbeing and Viva Explorers
May 19, 2022 | Laurent Giret
How to Access Active Directory
May 17, 2022 | Michael Reinders
Microsoft Rolls Out Azure AD Verifiable Credentials Service to More Customers
May 11, 2022 | Rabia Noureen
Active Directory vs. Azure AD (and Other Identity Providers)
May 9, 2022 | Michael Taschler
Apple Finally Discontinues Support for macOS Server App
Apr 25, 2022 | Rabia Noureen
Most popular on petri