<

Learn how to a build a cloud-first strategyRegister Now

x

Make GPOs work timebound

Published on
6,371 Points
2,771 Views
6 Endorsements
Last Modified:
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

Open in new window

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 GPO. 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

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

Join & Write a Comment

This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
If you're a developer or IT admin, you’re probably tasked with managing multiple websites, servers, applications, and levels of security on a daily basis. While this can be extremely time consuming, it can also be frustrating when systems aren't wor…
Suggested Courses

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month