Contributed By: Cliff Hobbs [MVP SMS]
Perhaps one of the key selling points of SUS (other than it’s free), is that it gets away from the ‘norm’ in most companies of relying/ allowing users to connect to the Microsoft Windows Update site in order to check for and download and install new patches which could potentially cause all manner of problems.

The following highlights the key features of SUS:

• SUS Server – This component can be installed on any computer running Windows 2000/ 2003 Server that is located inside your company’s firewall. This server synchronises with the Microsoft Windows Update Servers in order to download any Windows critical updates or Windows security roll-ups that Microsoft make available for Windows 2000 and XP. As of 18th September 2003, SUS can now download and deploy Windows Service Packs starting with Windows XP SP1 and Windows 2000 SP4.
  
  You can decide whether this synchronisation process is performed automatically or whether you want to perform it manually. Once the synchronisation process has completed you can then decide which updates are released to the clients configured to use your SUS server
   
• SUS Client (also known as the "Automatic Updates Client") – This is the component that is installed on any machines running Windows 2000, 2003 and XP that you want to be able to connect to the SUS server in order to receive the updates (this potentially includes the SUS Server itself if you want to keep this up-to-date using SUS). It’s possible to control which clients connect to which SUS server in large scale SUS deployments, and when the clients check for any updates (achieved through Active Directory Group Policy or set manually through the Registry)
   
• SUS Server Hierarchies – In large environments it is probably desirable to be able to have more than one SUS Server but undesirable to have every SUS Server connecting to the Microsoft Windows Update Servers. SUS can support this configuration but it also allows SUS Servers to be arranged in hierarchies.  For example the top-level SUS Server could be the one that connects to the Microsoft Windows Update Servers with second-level SUS Servers connecting to the top-level SUS server in order to obtain any updates and a list of those that have been approved for distribution to clients. Such an approach allows for central control/ management of the SUS solution.
   
• Phased Deployments – Using SUS it is possible to control which updates goto which SUS clients and when. For example, updates could be downloaded from Microsoft and deployed to some pilot clients. Providing the pilot proves successful, the updates can then be released to the rest of the estate (this approach relies on there being more than one SUS Server with the pilot clients reporting to one SUS Server (these could potentially be clients in a test lab) and the other clients reporting to another SUS Server(s))
   
• Disconnected Network Support – In addition to being configured to synchronise with other servers running SUS, it is also possible for SUS servers to synchronise with a manually created content distribution point(s). This approach allows SUS to be installed in environments without network connectivity to the Internet.