<

Make GPOs work timebound

Published on
11,649 Points
3,049 Views
6 Endorsements
Last Modified:
Approved
Not many admins are aware that GPOs can be activated and deactivated time-based. Time to change that :)

Let me start and show why one would not want to have certain GPOs to be active all the time, continuously. There are several reasons, for example:


-restrictions that should be in place for the morning shift should not be applied to the night shift

-settings suitable for the weekend should not apply the rest of the week

-settings suitable in 2016 should not be applied in 2017 (and we want that change automated)


What ways do we have to make time a component that decides whether a policy is applied or not?


First, there is a difference between GPOs and the GPO subset GPPs (group policy preferences). With GPPs, we have quite easy filtering by using "item level targeting". There's date match or time match, see this for the complete story. So we can say, apply this GPP item only on May the 1st, or every Tuesday, or on the first Wednesday of the month, or only between 9 am and 5 pm. Pretty good.


With GPOs, it is not that easy. There, we could use a WMI time filter that is based on the class Win32_UTCTime (or Win32_Local_Time/Current_Time).

This is easy for people that are familiar with the WMI syntax and will match some needs like being able to say "apply this GPO every Friday morning between 8 and 9 AM (local time) during the year 2001". But what can you do if you are not keen to fondle with WMI filters, if the syntax just bothers you, or if you find that there are limits to what you can do with it?


There's a 3rd way, relatively unknown I guess. It relies on the fact that we can link/unlink GPO using PowerShell.

Starting with server 2008 R2, we may use PowerShell 3.0, it knows the command Set-GPLink.

For example I have a policy for the night and one for the day, so during the daytime, I'd simply unlink the night policy and link the day policy and reverse that at night. Code example following:

Set-GPLink -guid 814977B4-1CD8-4E0D-837C-B88E5416772A -target "ou=Clients,dc=contoso,dc=de" -linkenabled no
Set-GPLink -guid 4BAA51F1-E869-424F-9B48-2BF832E92B70 -target "ou=Clients,dc=contoso,dc=de" -linkenabled yes

To get that running, you'd have to read out the policies GUIDs of the GPOs from the properties, first. In properties, they are called "unique name".

Now to get real value and flexibility, the question is "who would run that command?" -- surely we would not want someone to do that manually at 8 PM. So we can use task scheduler at the DC (or any computer win7 or higher) and setup time triggers. That gives us a maximum of flexibility as you can see in the screenshot.


Untitled.pngSo now that we have scheduler setup and the command for scheduler setup, the last thing is to choose an account for that task. On DCs, the system account is allowed to change the link status, so system is what I recommend to use. If you want another account, for example when you don't even have PowerShell 3.0 on your DC and therefore you must do this from a remote machine, you have to make sure that the account that you use has the appropriate permission of all GPOs that are being linked/unlinked. The permission is named "Write GPLink" and can be found on the security tab (advanced) in the properties of the parent OU of that policy in ADUC. Note: on workstations the set-gpLink command is only available if you have RSAT installed, because you need the module active directory.


Lastly, we may want to these settings to apply sharp, on the hour. The clients don't care if the policy is unlinked at exactly 8:00 pm, they still have it applied until the next GPO background refresh which might be (depending on the refresh interval) quite some time later. So it is advisable to deploy a task to the clients as well, that, following our example here, enforces a GPupdate in the morning at 8 and again in the evening at 8.


We'd deploy a task to all clients with the command

gpupdate /force

and as executor set the locally logged on user (for user based settings) or the system account (for machine-wide settings aka computer policies) as the executor.


Result: exactly at the times we want, the policies change to what we set.


That's all folks!

6
Comment
Author:McKnife
0 Comments

Featured Post

The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

Join & Write a Comment

Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …
This video shows how to use Hyena, from SystemTools Software, to update 100 user accounts from an external text file. View in 1080p for best video quality.

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month