gpedit locally can do it
you can create a reg file that does it

gpedit locally can do it
you can create a reg file that does it

If you import the below reg file, this should allow you to use WSUS without using GPOs:
Code:Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate] "WUServer"="http://SERVERNAME" "WUStatusServer"="http://SERVERNAME" [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU] "NoAutoUpdate"=dword:00000000 "AUOptions"=dword:00000004 "ScheduledInstallDay"=dword:00000000 "ScheduledInstallTime"=dword:0000000a "DetectionFrequencyEnabled"=dword:00000001 "DetectionFrequency"=dword:00000001 "AutoInstallMinorUpdates"=dword:00000001 "IncludeRecommendedUpdates"=dword:00000000 "NoAutoRebootWithLoggedOnUsers"=dword:00000001 "RebootRelaunchTimeoutEnabled"=dword:00000001 "RebootRelaunchTimeout"=dword:00000078 "RescheduleWaitTimeEnabled"=dword:00000001 "RescheduleWaitTime"=dword:0000003c "UseWUServer"=dword:00000001
Davit2005 (21st April 2012), speckytecky (21st April 2012)

In my testing the Microsoft Report Viewer Redistributable 2010 didn't work with WSUS 3 SP2.
I would however recommend the Microsoft Report Viewer Redistributable 2008 SP1 which you can download here

Manage WSUS from a Workstation
Requirements: Windows XP SP3, Windows Vista or Windows 7
Additional requirements: A 2003, 2008 or 2008 R2 server with WSUS 3.0 SP2 already setup/configured.
For your reference, even if you have a 64Bit server running 2008 R2 and a 32Bit Windows 7 workstation, this method will still work. It simply means you're running an x64 version of WSUS on your server and an x86 version of the console on your workstation. There is no difference in the software and/or its options/tools. This may sound obvious, but I have been asked similar questions before!
On your workstation:
Download/install Report Viewer 2008 SP1 here first.
Download/install WSUS 3.0 SP2 here (x86 or x64)
When you run Setup, choose Administration Console only
You can now access Windows Server Updates Services on Administrative Tools. When you run it first time, you'll be prompted for the SERVERNAME and Port.
Enter your SERVERNAME, you don't need the FQDN. If you've installed WSUS using default settings (on your server) leave the port as 80 and leave SSL unticked. Click on Connect and you can now manage WSUS from your workstation. You have access to all tools, just as you would on the server itself.
I've used this method for years, but I thought I'd share as I didn't include it with setting up WSUS guides.
speckytecky (29th April 2012)
Thanks Michael. I did it through the local group policy. It works Awesome.
Cheers,
Dragging this back up again, sorry. I had set up a WSUS server (ran dhcp, ad, etc etc) that worked just fine untill the server itself started playing up so we had a new server to run AD, DHCP ect except WSUS. We had the old server demoted from a domain controller to a plain old PC running Server 2003, now the question is can I still run WSUS on the PC running Server 2003 and have the WSUS group policy manage the clients on the new 2008 R2 server? Trying to fix the original 2003 install at the moment but cant figure out if its truly broken or not possible to run it in this way or not which is why it wont play ball?
It is poss to have WSUS on a completely different server not a DC. It is then possible to setup the basic settings within group policy and get the clients pointing to computer groups. It is also possible to override the client targeting for particular OU's by just changing the targetted group if necessary :-)
On a connected note, Anyone know how to point SCCM to a different WSUS if WSUS has broken? Cheers

You can install WSUS on a DC or Member Server.
You can of course setup GPOs so workstations know where to download updates and when to apply updates, but WSUS by default will place computers in the Unassigned group. To my knowledge, there isn't a GPO to specify which group computers should go into.
All is not lost however. Once computers have reported to WSUS, you can then move them into groups you've created in WSUS, and then target updates accordingly.
Targetting is useful for testing purposes, but also for very large networks with 1000+ workstations. Using a combination of different GPOs, different sets of workstations would/could update at different times. This can be a lot of work initially, but BITS delivers updates intelligently, keeping network traffic as low as possible.

You can apply wsus groups via gpo.
Ben
Well, managed to breathe life in to the WSUS server again and I can confirm now that a WSUS server can be on its own and the clients can be told where it is via our DC server GPO, very happy now! Funny how little things like that keep you going. My main problem was getting the original install uninstalled, had to use the MS cleanup utility to get rid of it then reinstall it. Clients started replying to it fairly quickly as well after it was synchronised. Happy bunny now.

@plexer - Are you referring to the following GPO:
Computer Config > Policies > Admin Templates > Windows Components > Windows Update - Enabled - Enable client-side targetting?
So if I specify a target group, will it actually move the computer object in WSUS to that group, or will it just tell the workstation to read information from that target group? It's not very clear.
Michael (29th April 2012)

Thanks! I'll certainly have to try this out!
There are currently 1 users browsing this thread. (0 members and 1 guests)