Traditionally, Group Policy Objects in Windows are retrieved or refreshed by a workstation running Windows whenever a user logs on and at a predetermined random interval somewhere between 90 minutes and 120 minutes. (The randomness is to keep all the machines in the domain from refreshing their Group Policy at the same time.) If you make changes to a Group Policy and want to see the effects immediately, there are only a few ways to make that happen without actually logging the target computer off and on again. Obviously, if you're trying to see how a given GPO behaves on many machines, this isn't really practical.
Darren Mar-Elia (who bills himself as GPOGuy) has written a command-line tool called RGPrefresh (requires .NET Framework 1.1) that lets an administrator force a Group Policy refresh on a remote computer. The program uses command-line switches to determine which machine to refresh and which options to apply:
/m: <computername>: Defines which computer to perform the refresh on.
<computername> is usually a NetBIOS name, but it can also be an IP address.
/t:Computer | /t:User: If /t:Computer is selected, the program applies a computer-specific policy; if it's /t:User, then the policy for the designated user is applied. If the /t switch is not used at all, then both computer and user policies are applied.
/u: <username> | /p: <password>: These switches let you supply a username and password if you need to use alternate credentials to perform the refresh.
/force: Use this to cause an update to happen even if the GPOs have not been changed.
/logoff: This option forces a logoff after a policy refresh, for policies that might need it. It is only available in Windows XP and 2003.
/boot: This switch forces a reboot after a policy refresh, with the same behavior and restrictions as /logoff.
/sync: Use this option to apply the policies synchronously. This is most important on Windows XP, where policies are applied asynchronously by default.
Note that if you run RGPrefresh with a remote machine as the target and the local credentials are not valid on the remote machine, you'll need to supply a username and password via the appropriate command-line switches.
Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!
