When Microsoft shipped Windows 8 & Windows Server 2012, they added a new feature in GPMC, that allows you to perform remote Group Policy Updates on OUs of computers. I covered this feature in my previous roundup of Windows 8.1 Group Policy features. This feature is shown in the figure below:
Performing a remote Group Policy Update in GPMC
As I was exploring this feature, I got to wondering how you might delegate the rights to perform such an operation. Surely you wouldn’t want anyone willy-nilly triggering remote GP updates against masses of computers. I wondered this because I was testing the feature in my lab and found that the Group Policy Update option was grayed out when I right-clicked certain OUs. At that point I surmised that, like RSOP Logging and RSOP Planning, there might be a “Group Policy Update” permission that needed to be granted on an OU to allow someone to have access to the feature. I found no such right, but on the OU where it was grayed out, I did notice that I had, at some point in the past, set a Deny ACE on the RSOP Logging permission for my user account. Curious, I removed that Deny ACE and, voila! The Group Policy Update option came back for me when I right-clicked the OU.
So, it appears that you need to at least have the permission to Read Group Policy Results Data on a given OU in order to get access to the “Group Policy Update” option. This permission can be granted easily to an OU in GPMC, as shown below:
Granting the RSOP Logging right in GPMC
Note that you can also grant this permission on an OU using Active Directory Users and Computers and the ACL editor. The right there is called “Generate Resultant Set of Policy (Logging)”.
So, you have the RSOP Logging permission and you’re ready to start sending out remote GP Updates…right? Well, not quite. The way remote GP Update works in GPMC is that it makes a remote WMI connection to the target machine(s) and then creates Scheduled Tasks on the target to run the gpupdate /force sometime within 10 minutes after triggering. By default, the only ones who can make this remote call and create those scheduled tasks, are members the local Administrators group on a given remote system. So “regular”, non-administrative users may be able to trigger the Group Policy Update if the have the RSOP Logging permission, but it will inevitably fail with an “Access Denied” error if they don’t have administrative rights to remotely connect to WMI and create Scheduled Tasks on that remote system.
I hope this helps some of you out there make sense of this feature and the odd overloading of the RSOP Logging permission to the “Group Policy Update” function. Maybe by Windows 10 we’ll see a separate “Allow Group Policy Update” permission 🙂
Darren