I am doing a lot of work in higher education where it is a rather common requirement to reconfigure a number of Windows domain members (e.g. PCs in a classroom) for the duration of a specific course or event and have this configuration undone afterwards.
As most of the configuration changes we are requested to do can be done through Group Policy Objects and those changes automatically get reversed when the GPO is unlinked or deactivated at the OU level, this is a very comfortable route to take.
The only downside is that repeated manual linking and un-linking of GPOs on OUs needs a lot of reminders and IT staff on duty before the courses start and after they end - something the operations team cannot guarantee at all times.
Is there a way to specify a time frame for the validity of a specific GPO?
This can be done by the means of WMI filtering. The group policy client would execute the WQL query from an attached WMI filter and only apply the GPO if the query would return a non-zero number of rows. So by creating a WMI filter checking if the current system time is within a given time interval and linking this WMI filter to the GPO you want to timebomb you get exactly what you wanted.
The win32_operatingsystem WMI class has a localdatetime attribute which can be compared to a given string date in the format 'yyyymmdd hh:nn:ss' so using the WQL string like
in the
root\CIMv2
namespace would make sure that the GPO only would be applied to systems where the local time is between Feb, 20 2015 00:00:00 and Feb, 23 2015 15:00:00:Make sure you have linked the WMI filter to the desired GPO:
Things to keep in mind:
the group policy client will check for GPO changes and re-apply them rather infrequently by default:
So the default settings will only allow for a precision of +2 hours. The update interval can be changed by (another) group policy setting, if needed.
your policy needs to be able to revert all changes when no longer applied. This is the case by default for all managed Administrative Templates. Group Policy Preferences settings might need to be explicitly set up to "remove this item when no longer applied":