Policies don't work

[paleogryph]

GP newbie here, just bought Marks book. Great book, but I can't seem to get any policies I create to actually take effect.

W2K3 Server with MMC 2.0.

1. Log into PDC, Create a new OU, "move" a Citrix PS 4.0 server into the new OU.
2. Create a new GPO, set it to disable access to run command and also control panel.
3. Right click the new GPO, make sure is ENFORCED and LINK ENABLED.
4. Set Scope for "Authenticated Users", which should mean anyone who logs on.
5. Connect to Citrix vi rdp and ica, with two different accounts, one admin, one not. Both can still access run and control panel.
6. Gpupdate /force with same results.
7. Delete the GPO and the OU.
8. Recreate the OU and the GPO, re-link and enforce, etc;
9. Same results...

What am I missing?

[AdamV]

I assume you mean Jeremy's book (with a foreword by Mark Minasi)?

Anyway, it sounds like you have applied a policy to a computer but it only has user settings in it which it will quite happily ignore. You need to read the chunks about using loopback processing, as this is the usual way to apply policies for users when they log on to certain machines (such as TS servers or internet kiosks) without affecting them at their normal workstations.

[paleogryph]

Yes, Jeremy's book.
I apologize for the gaff...

Thanks for the tip on loopback processing.
I haven't gotten to chapter 3 yet, but I will jump ahead to fix this issue.

Many thanks!

[paleogryph]

The loopback replace works great on getting GPO to work on my Citrix server. However I have a question about the two Object Filtering Approaches outlined in the book.

#1 Leverage Security Filtering
This is the "preferred" method, however it doesn't seem to work. When I create a new group with the users I want, move that group into the OU that has the policy linked to it, remove "Authenticated Users" and add the group I just created into the scope, then refresh the policy on the server, nothing happens. I wait a while with same results.

It appears that if I use Authenticated Users in the scope, it always works, and then I can just deny the policy to whatever group I want.

Why is it better to use approach #1 than #2?

[AdamV]

A few things

It does not matter where in the AD the group object is stored, it does not do anything in itself, anf the policy is not aplied to the group.

So you create a new group, say "Sales" in the security filter and allow it read and apply permissions (having removed auth users). When you refresh the policy on the client using gpupdate (on 2003 or XP, gprefresh for 2000) it will go and apply the policy if the user is in the group. BUT if you only just added the user to the group, and have not logged off and on again, their security token will not include this group so it does not know they are a member and the policy is not applied.

The main reason this is generally the preferred approach (I think) is simply that the group "sales" is usually easier to define and check than the inverse group "not sales". Also "deny" is notorious even with simple things like NTFS permissions, because it trumps everything else.

I tend to use a mix of approaches, since some policies are designed to apply only to one set of users, whereas others are designed to apply to everyone but I later find some exceptions to the requirement.

As a rule, I would suggest using groups for GP filtering which are only used for that, and highlight this with a prefix eg "GP_HasMSVisio" group. This group might then contain users, or simply other general purpose group(s) such as "NetworkAdmins" and "FacilitiesTeam" or "HVACDesigners".

Having said all of that I tend to try and avoid needing any filtering by designing AD / OU structure with GP as my main driver. Filtering adds complexity (and a little bit of processing time too). Design it out if at all possible.