Edit Windows Update GPO Via Command Line

Question

I am trying to find a way to edit the group policy for Windows Updates programmatically. I have a local WSUS server to which I want to point new installs of windows. Ideally, I just want to have a script I can run which does this, rather than going into gpedit.msc > administrative tools > windows update > set intranet server.

I looked into editing the registry as an alternative, but i ran into a wall. First, the entries are different across different operating systems, which is not a showstopper but it is annoying. The main issue, though, is that on older OS configurations (like, windows XP) the server address would show up in a whole bunch of strange, unique places for each computer. For example:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy Objects\{2975F3DE-F18A-9CE1-A731-5E6723AC64FD}Machine\Software\Policies\Microsoft\Windows\WindowsUpdate

Near as I can tell, there isn't a way to identify what the registry key name will be prior to installing, so i can't set the keys correctly. I'm also leery in general of doing this over the registry, because I'm not 100% confident this is the only change being made in the GPO (is there anything else going on behind the scenes?)

Update in response to comments

@Ben - I know this isn't the ideal way to use GPO, I'm more limited by the fact that I can't see any other way to specify my WSUS server without the registry issues, rather than a desire to use GPO. There isn't an active directory currently set up, so as far as I know I can't set a global GPO which everyone inherits, and I don't want to set one up if I can avoid it.

@Jason - There are two problems, first that this is only setting registry values, which I can already do in cmd, and second that I'm not 100% sure if all the computers we're using will have powershell installed. And, at that point, its a chicken and egg problem - older copy of XP needs WSUS, WSUS is where it gets Powershell, which it needs to set WSUS.

@Ryan - I don't think those are the only registry settings changed. At least in a Windows 7 Account, it changes the entries you noted in both HKLM and HKEY_USERS, afaict. But, setting just those values on a windows XP box didn't allow the computer to connect to the WSUS server, it just error'd out. I will retry, however. Second edit: Just tried this on a blank XP SP3 machine, and it couldn't connect to the server by only setting the following:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate /v "WUServer" /t REG_SZ /d http://myserver

reg add HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate /v "WUStatusServer" /t REG_SZ /d http://myserver

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU /v "UseWUServer" /t REG_DWORD /d 1

Solution 1

You could use PowerShell to update group policy. Here's an example:

set-gpregistryvalue -name "WU" -key HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate -ValueName "WUServer", "WUStatusServer" -type String -Value "http://wsus01.internal.local:8530"

And here's where you can read up more on the amazingness that is powershell:

http://technet.microsoft.com/en-us/library/ee461027.aspx

OR AN EVEN BETTER ANSWER:

Step 1: Setup Active Directory
Step 2: Join computers to Active Directory domain
Step 3: Configure group policy to point computers to WSUS server
Step 4: Profit

Solution 2

Most of the Windows Update settings in Group Policy are set at the Computer level, not the User level. Also, there's no need to be leery of doing this directly via the registry. That's the only thing Administrative Templates in Group Policy actually affect.

All of the "Windows Components\Windows Update" settings are stored in these two keys:

HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate
HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU

The "Specify intranet Microsoft update service location" policy in particular sets the following values:

• WUServer (REG_SZ in the root key)
• WUStatusServer (REG_SZ in the root key)
• UseWUServer (REG_DWORD in the AU key)

It's easy enough to see exactly what gets set by manually setting the policies using gpedit and then looking at what changed in the registry. If you're feeling adventurous, you can also crack open the actual administrative template file to see what's going on. On Vista+ it's WindowsUpdate.admx. I don't recall what it is on XP and earlier, but it would be a .adm.

*Edit: Apparently it's not clear whether the OP is trying to script local policy settings or domain policy settings. This answer is specifically for editing local policy settings on a single machine.

Comments

[Ben Pilbrow]

Why, oh why would you not want to use the MMC?

[Jason Berg]

@Ben - because MMC isn't scriptable...If I could live in command line in Windows, I'd be a happy guy...it's getting there, but not quite there yet...maybe I should become a unix admin in the meantime...

[Ben Pilbrow]

@Jason But the whole point of Group Policy is that it's central and you don't have to run scripts on each machine so they are effectively "compliant" with your policies.. it just happens™. GPO's are inherited from the OU the computer object lives in, and change automatically if you move the computer object - there's no need for dicking around with scripts, remembering to run them (on all servers) when policies change and ensuring you have the latest version. Group Policy takes care of all of this for you.

[Jason Berg]

@Ben - I may be misunderstanding him. After re-reading it, looks like he's wanting to edit local group policy on each computer. Now that's just not the smart thing to do. Should use group policy for the AD forest. I was saying he could update THAT policy using a script if he wanted to. But now I'm just confuzzled.

[Ben Pilbrow]

Yes, I'm confuzzled too. @Owen, would you please clarify what it is you're trying to modify - the local policy or domain group policy objects?

[MDMarra]

well, there's only one way to settle this: Owen, what are you trying to do?

[Ben Pilbrow]

Yeah, +1 for the sensible option of setting up AD :-)

[Rob Moir]

+1 for setting up AD. I understand that the OP feels they might not want to do that but that doesn't alter the fact that its the most sensible way of solving this problem