Deploying SUS or WSUS in non-AD Environments

Although an Active Directory environment makes it much easier to deploy SUS or WSUS, it is not necessary to have AD to get client computers on an update schedule. Clients only need one thing in order to talk to a SUS or WSUS server, and it is this branch of the registry:

- - - - -

Windows Registry Editor Version 5.00



"WUStatusServer"=" your_sus_server "









- - - - -

The values above are for a daily 4:00 a.m. install time and a forced reboot if required. Consult the appropriate deployment guides for other options.

From here, it becomes a matter of how to get the registry values onto machines without AD Group Policy. Here are a couple of options:

1. Modify your login script to push the registry entries. Here is a snippet of VB code that can be used:

- - - - -

Set oshell = CreateObject("WScript.Shell")

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUServer", "http://your_SUS_server", "REG_SZ"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer", "http://your_SUS_server", "REG_SZ"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoRebootWithLoggedOnUsers", 0, "REG_DWORD"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\NoAutoUpdate", 0, "REG_DWORD"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\Options", 4, "REG_DWORD"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\ScheduledInstallDay", 0, "REG_DWORD"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\ScheduledInstallTime", 4, "REG_DWORD"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\UseWUServer", 1, "REG_DWORD"

oshell.RegWrite "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU\RescheduleWaitTime", 5, "REG_DWORD"

Set oshell = Nothing

- - - - -

2. In some environments, it is a even a challenge get the registry settings pushed via login script. It can also be difficult to keep the settings from getting on machines (like servers) where SUS or WSUS is not wanted. This is where SysInternalÂ’s PsExec tool can be very useful. The first requirement is a list of all workstations on the network. Once this list is brought into a .txt file, the following can be used via command prompt to push the registry settings:

- - - - -

Psexec –u context\username @file /i /s “\\server\share\settings.reg”

- - - - -

Here are the meanings of the switches:

[-u] This instructs PsExec to run in a user context

[Context] This can be an NT4 domain (or an AD domain, but then you wouldn’t need PsExec in the first place to do the push), or the “context” switch can be left off

[Username] If you simply use “administrator”, then PsExec will run as the local machine administrator. You will then, of course, need a common local administrator password to perform the push efficiently.

[@file] This directs PsExec to run on all the machines listed in the specified file. Ex: “@C:\WSUS\clients.txt” This would be the C:\ drive of the computer from which PsExec is being executed.

[/i /s] This instructs the registry entry to made silently and without user intervention

Consult SysInternalÂ’s website for more information on the use of PsExec.

Note that you must place PsExec.exe somewhere on your drive where your path statement can find it. Also note that seeing “error code 0” when you execute PsExec means that the command completed successfully.