I want to change the group policy setting that applies the value of the Windows Update WSUS server location HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer and HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer.

Changing them directly in the registry will not overwrite what has been set in the group policy, so I would like to know, what commands can I use to change the group policy input of these values instead?


Mark Russinovich has an excellent article on circumventing Group Policy changes.

Group policy settings are an integral part of any Windows-based IT environment. If you’re a network administrator you use them to enforce corporate security and desktop management policy, and if you’re a user you’ve almost certainly been frustrated by the limitations imposed by those policies. Regardless of which you are, you should be aware that if the users in your network belong to the local administrator’s group they can get around policies any time they want.

There are two steps to circumventing a group policy setting: identifying the setting’s location and preventing the setting from being applied. There are many group policy references available, but since machine group policy settings store in the HKEY_LOCAL_MACHINE branch of the Registry and per-user group policy settings store in HKEY_CURRENT_USER, if you don’t know the location of the setting that’s preventing you from doing something you want you can use Regmon to find it.

The number of desktop lockdown settings available to group policy administrators is enormous. They can prevent you from doing anything from changing your desktop appearance and start menu to running certain applications. Two commonly applied settings include a pre-configured screen saver program so that users don’t waste resources on frivolous screen savers, and a screen saver timeout so that systems aren’t left indefinitely accessible when a user steps away. When these settings are in effect Windows omits the screen saver tab of display properties control panel applet or doesn’t let you modify the screen saver or its timeout. I’m going to show you how to use the power of being a local administrator and Regmon to track down these settings and override them on your own system.

While it goes into the Registry Monitor, Process Monitor also exists these days which combines several monitoring tools into one. It allows you to find the registry keys that are being modified. Just jump to the relevant registry keys and change their permissions such that they can't be updated anymore...

Check out what you can do with the reg command; you can verify access with accesschk.


Group policy for the local machine is stored in the registry.

The lame approach for modifying it, is via the Command Prompt using the reg command. This is less than practical because it requires absolute knowledge of each and every local policy registry setting, and errors here may be quite disastrous.

The tool to use instead is PowerShell, Microsoft's successor to the Command Prompt.

Some articles that can start you on the way to using PowerShell cmdlets for local policy changes are :

Use Windows PowerShell to Manage Group Policy
Windows PowerShell Cmdlets for Group Policy
Group Policy management for IT pros
Group Policy
Group Policy Settings Reference for Windows and Windows Server

  • 1
    As appealing as the PowerShell GroupPolicy cmdlet seems, apparently (and surprisingly) it cannot be used in the simplest case, namely, to manage local machine or user policies on a non-domain joined machine. Indeed your first link states that the cmdlet requires AD, but before noticing this, I struggled to get the GP cmdlet working using on a standalone Windows 10 Pro client and latest PowerShell. I was encouraged at first that RSAT (a prerequisite of the GP cmdlet) installed successfully, but in the end, the cmdlet was never satisfied with the strength of the local Administrator credentials. – Glenn Slayden Oct 29 '16 at 6:39
  • @GlennSlayden, could you please tell more about your tensions? You installed RSAT but anyway failed because you machine wasn't in the domain, because of weakness of your password? Why? – Suncatcher Jun 20 '18 at 15:08
  • @Suncatcher My best guess is that it was because it’s a standalone machine with no domain. As I mentioned, I originally either did not notice this requirement (or perhaps didn’t believe it would be a showstopper). – Glenn Slayden Jun 20 '18 at 20:26

The following tool, from Microsoft TechNet, allows management of Group Policy via the command line, and thus scripting as well:

Local Group Policy Object Utility, v1.0


Alternatively you can run gpedit.msc. As in Start - r gpedit.msc Enter.


You can choose an alternative WSUS for installation of update by using the /use_wsus option of the command line tool WuInstall, which changes exactly those values - however, after execution of WuInstall the values are changed back to the old value

  • 1
    I didn't specify, but this is an enterprise environment and dependencies are not acceptable (i.e. non-inclusive tools). – Mechaflash Jan 23 '12 at 15:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.