Windows Server Update Services (WSUS) 3.0 SP2 is a
comprehensive resource to help you deploy updates to the servers and
clients in your network. This tool is a free download from the Microsoft
website. It is incredibly flexible and can be used in very small to
very large network environments. WSUS is installed on a server or group
of servers in your network and acts as an intranet-based Windows Update
server.
1. Do a Simple WSUS Deployment
In its most basic form, a
WSUS deployment consists of a single server on the local intranet inside
the DMZ and inside the Internet firewall. This server will be used to
connect to Microsoft Update and download available updates in a process
that is called synchronization.
You will synchronize the WSUS server with the Windows Update servers on
a regular basis, and the WSUS server will verify that available updates
have been synchronized to the WSUS server. The initial synchronization
will take an extended period of time if your Internet connection speed
is good and longer if it is not. Subsequent synchronizations will be
faster because the WSUS server is only synchronizing new updates that
have been made available.
WSUS uses standard HTTP ports 80
and 443 to access and download the updates from Microsoft Update. These
ports are likely already open on your firewall; if they are not, you
will need to open them in order to use the WSUS server. It is possible
to change the default communication ports to meet your network's
specific needs.
Depending on the size and
structure of your network, you may choose to add a WSUS server to your
network. These additional servers can be configured to get their updates
from the existing WSUS server. This process is called chaining servers together. As you chain more and more WSUS servers together, the WSUS deployment can become quite complex.
Automatic Updating is
the client-side part of WSUS deployments. The service has to use the
port assigned to the WSUS website in IIS. If there are no websites
running on the server where you install WSUS, you can choose to use the
default website (port 80) or a custom website (ports 8530 or 8531).
1.1. Use Computer Groups
One of the coolest
things about WSUS deployments is the use of computer groups. Computer
groups allow you to target updates to specific groups of computers on
your network. There are two default computer groups called All Computers
and Unassigned Computers. Each computer that is added to WSUS is added
to these two groups. You will create additional groups to allow WSUS to
target updates to specific groups of computers, and you will add
computers to your new groups from the Unassigned Computers group. It is
important to remember that you cannot remove computers from the All
Computers group.
Computer groups allow you
to structure your machines in such a way to make it possible to test
updates on a small group of machines before deploying those same updates
on a broader scale to the rest of your network. If the testing works
well, then broad deployment can be easily accomplished. If there is a
problem in testing, then you have limited the scope of the problem to a
small computer group instead of the whole network.
1.2. Use WSUS Server Hierarchy
As mentioned earlier, it is possible to chain WSUS servers together. There are two ways to build those links:
In autonomous mode,
the upstream server, or the server connected to Microsoft Update,
shares synchronization information with its downstream partner but does
not share its computer group information. This way, the available
updates are passed from WSUS server to WSUS server while maintaining the
integrity of the individual computer groups.
In replica mode,
the upstream server shares its synchronization information and its
computer group information with its down stream partners. The downstream
partners hold the same information and are thus functional replicas of
the upstream WSUS server.
It is recommended that you do
not create hierarchy beyond three levels deep. At that point, the
synchronization lag time introduced to the process becomes prohibitive.
2. Get WSUS Updates on Disconnected Networks
It is sometimes necessary to
operate servers and clients on a network that is not connected to the
Internet or to other networks. Servers and clients operating in
isolation still need updates. WSUS makes it possible to supply updates
to isolated network segments through a simple process:
Connect WSUS to Microsoft Update on a connected network.
Synchronize the available updates to the WSUS server.
Export the updates to media.
Hand carry the media to the isolated network segment.
Import the updates to the isolated WSUS server.
Deploy the updates to the isolated servers and clients.
This method not only
makes it possible to deliver updates to isolated or disconnected
networks but can also be used to limit the bandwidth in traditional
connected WSUS deployments. For example, you might choose to have a
single WSUS server synchronize updates with Microsoft Update and then
export those updates to DVDs; then you can send the DVDs to be imported
to each of your other WSUS servers instead of downloading the same
information and slowing performance on the WAN.
3. Use WSUS with Branch Cache
One of the features of Window
Server 2008 R2 is branch cache. This feature can improve WAN performance
by caching content on branch servers in order to make that content
available to local clients without the need of constant WAN access. If
the branch cache feature is installed on Windows Server 2008 R2, it can
be used to cache the WSUS synchronization and computer group
information. This can really improve the responsiveness of your WSUS
servers that are located in branch-office locations.
4. Choose a Database for WSUS
WSUS requires a database in
order to operate; however, you do not need to purchase a database
product in order to use WSUS. When you install WSUS 3.0 SP2, it will
check for an available database. If it does not find one, it will
install one for you. The database it will install by default is called
the Windows Internal Database. This is a small-scale version of SQL
Server. This version of SQL Server is very simple and does not require
hardly any management. (If you want to install full-version SQL Server
to host the database for WSUS, you are welcome to do so, but it is not
required.) The WSUS database stores the WSUS configuration information, a
metadata description of each update, and information about the client
computers, updates, and interactions.
Although there is a
database that will store information about the updates and the clients
that will use the updates, you will not be managing WSUS through the
database. There is a built-in management tool called WSUS Manger where
you will manage the WSUS servers, updates, clients, and computer groups.
4.1. Learn Where to Store the Updates
The ideal place to store
the updates from Windows Update is on the local WSUS server. This saves
the network bandwidth of clients accessing the WSUS server only to be
pointed to another network location to download the updates. There is
one caveat here; the updates are going to take up a fair amount of
space. Microsoft recommends that you have at least 20GB of local storage
at a minimum and actually recommends 30GB. Keep in mind that these
numbers are only estimates and could go higher than 30GB depending on
your network needs and particular situation.
It is possible to use WSUS to
approve updates for your network and then store those updates remotely.
The most extreme example of this design would be to use the WSUS server
to approve updates for your local clients and then point them to the
Internet-based Windows Update servers for the updates. This effectively
eliminates the requirement to store updates locally while still allowing
you to test and approve the updates coming in to your network.
WSUS uses the
Background Intelligent Transfer Service 2.0 (BITS 2.0) protocol for all
of its file transfer needs. Each time files are downloaded from servers
to clients, they are moved using "spare" bandwidth. This technology also
makes it possible to continue downloads, even if the computer is shut
down in the middle of a download, once the computer is restarted.
5. Learn the WSUS Requirements
To run WSUS, your servers must meet the following minimum requirements:
CPU: 1GHz minimum. 1.5GHz or better is recommended.
Graphics card: 16MB hardware accelerated or better is recommended.
RAM: 1GB minimum; 2GB or better is recommended.
Page file: At least 1.5 times the physical memory is recommended.
I/O: Fast ATA/IDE 100 hard disk or equivalent SCSI drives are recommended.
Network adapter: 10MB minimum; 100MB or better is recommended.
The system partition and the install partition for WSUS must be formatted with the NTFS file system.
1GB minimum free space on the system partition is recommended.
2GB minimum free space on the volume on which the database files will be stored is recommended.
20GB minimum free space on the volume where the content will be stored; 30GB is recommended.
WSUS cannot be installed on compressed drives.
The current hardware
requirements for WSUS should be easily met if you are running Windows
Server 2008 R2. If you are not running Windows Server 2008 R2 as your
WSUS machine, it is possible to use Windows Server 2003 SP2 or later as
your WSUS server and install WSUS 3.0 SP2.
6. Get More Information on WSUS
WSUS is a great tool for
controlling the update process in your network. To understand its true
potential and the details associated with deploying and using WSUS, you
will want to get the WSUS 3.0 SP2 deployment guide, as well as the WSUS
step-by-step guides, available at http://technet.microsoft.com/en-us/wsus/default.aspx.
The information provided there will provide a strong base for using WSUS in your network.
