Workstation Secure Lockout Policy Deployment

We are to deploy Workstation Lockout Policy in our whole organisation.
This will be done with Group Policy (GPO) located at:
User configuration\Administrative Templates\Control Panel\Display\...

We are to exclude certain workstations or machines from this policy so that  
they do not lockout after a period of inactivity because they are monitoring
machines and their screens need to be displayed clearly at all times.

I have checked and it is done on the User Configuration of the GP Editor
and not on the Computer Configuration as I expected it to be?

When the user gets the GPO update and leaves their machine unattended for
15 mins or more, they will be prompted to login when they next attempt to
access the machine. This is actually the screen saver that does this. The
workstations/machines are mostly Windows XP ones.

The question is, since this is applied on the User Configuration\ container
how do I apply this so that the monitoring machines are excluded but all
other workstations get this GPO update?

I have a list of machines that need to be excluded plus a few user accounts.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Being that it's based on user accounts, I'm guessing that these 'monitoring' machines also need to be logged on to the domain...

If that's so, do you use a 'special' account for these monitoring machines? If so, then you could just exclude that user account from the policy, which therefore would not lock the monitoring machines out.

You can do this by either created a nested OU with the 'special' user accounts in, and block GPO inheritance to that OU, or there is another less proven method - If you're interested in knowing, I'll explain, however it would be 'cleaner' to create the nested OU...
You can benefit from using the loopback function in group policy to use user settings on computers and not users.
Search for it on and you can read about it.

Then you can have a group which computers belong to that should recieve the policy and then filter the GPO on that.
netimpactAuthor Commented:

You are right they are logged in as special user accounts of the domain. an yo please elaborate on your less proven method? thx

I will read a bit more about loopback. But do you think that will be a solution for my problem. Will like to know, thx
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Ok, one way to exclude either an individual user or group from a GPO is to -

Open the Group Policy Management Console. Navigate to the GPOs section (as in the 'Example' pic below), where all your GPOs are listed. Select the GPO you want to exclude the users from, and select the 'Delegation Tab' (as in the 'Delegation Tab' pic below). Click Advanced at the bottom, and you will see a screen that looks just like the normal Security perms on any file or folder.

Now, if it's 1 user, continue, but if it's more than 1 user, you'll want to create a security group with all those 'special' user accounts as members.

Then click 'Add' and add either the group or individual user you want to exclude from the GPO. Once added, you simply need to 'DENY' them the 'Apply Group Policy' and 'Read' permissions.

This will stop that GPO from being able to apply to those users or groups.

When I say this method is not proven, all I mean is that it definitely works, but it may result in errors in the event log, reporting that the GPO was not able to apply to certain object due to a permissions problem. It might do this, it might not!

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
netimpactAuthor Commented:
I resume this should apply to the computer account also i.e. I can DENY the machines the permissions for this to work? Since Computer Configuartion take precedence over User Confuiguration this will work also?
To be perfectly honest, I don't know - It would be very easy to find out, as if you can Add a computer object instead of a User or Group object, I would say yes it will work!

However if it will only let you add users and groups in that section, it's fair to say you'd have hit a brick wall... :)

If not, there's always the option of moving the computer objects for those monitoring PCs into a nested OU, and block GPO inheritance to that OU...

There's no doubt other ways of doing it, I just stick to ones I know that's all! :)
netimpactAuthor Commented:
I know I am going in a circle but one more go to clarify this please.
Will "block GPO inheritance to that OU" mean that even though they are computer accounts
they will not be affected by the Workstaion Lockout Policy created in the User Configuration?? thx
HeHe, it can get a little confusing!

It's a case of keeping clear in your head WHERE you're applying the OU, and WHAT you're applying it to.

Blocking inheritance to an OU blocks ALL GPOs that are not linked directly to that OU (so it will block any GPOs that the OU would inherit from the domain or from a parent OU), regardless of whether that OU contains user objects, computer objects, or both.

However if you have a GPO which applies to user objects in a different OU, but effects the computers that these users are logged on to, that GPO would still apply.

But for clarification in your specific scenario, you may want to speak again to pHpp, as I've never used this 'loopback' functionality - You may be able to figure it out if you read the article he posted, and correlate the info with what i've said...

Apologies if i'm not being clear enough! I've never been particularly good at explaining things... :)
netimpactAuthor Commented:
ok leaving the office now in a rush, will update this later. thx
netimpactAuthor Commented:
ok I think I might have a way forward. I want to clarify a few things if its ok by you?

One other issue is the screen saver executable name which will reside on the users machine in
%systemroot%\system32\*.scr. I am thinking that, if that file is not on the users machine
then the policy will be ignored for that user or machine.

Is there a better way to manage this file, like in the NETLOGON,  Share or SYSVOL folders
rather than the local machine and how best should I do this, so everyone has access. Hope this question is clear, thx
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Microsoft Server OS

From novice to tech pro — start learning today.