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

    Requires Free Membership to View

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!


This was first published in September 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.