One of the main drawbacks to Windows and SharePoint server security has been the difficulty in keeping servers up-to-date with the latest security fixes. For example, the security fix for the Index Server component of IIS was available for more than a month before the Code Red and Nimbda viruses erupted onto the scene. If the deployed servers had downloaded the patch, they would not have been affected. The main reason that the vast majority of the deployed servers were not updated was that keeping servers and workstations up-to-date with the latest security patches was a manual and time-consuming process. For this reason, a streamlined approach to security patch application was required and realized with the release of Software Update Services (SUS), and the newer Windows Software Update Services (WSUS). Using a dedicated Software Update Services server for SharePoint and other servers is fast becoming a best practice approach to intelligent patch management. Smaller environments can simply utilize the integrated Windows Update client to achieve similar functionality, however. It is best to outline whether SUS is practical in a SharePoint environment. Understanding the Background of SUS: Windows UpdateIn response to the original concerns regarding the difficulty of keeping computers properly patched, Microsoft made available a centralized website called Windows Update to which clients could connect, download security patches, and install them. Invoking the Windows Update web page remotely installed an executable, which ran a test to see which hot fixes had been applied. Those that were not applied were offered up for download, and users could easily install these patches. Windows Update streamlined the security patch verification and installation process, but the major drawback was that it required a manual effort to go up to the server every few days or weeks and check for updates. A more efficient, automated process was required. Deploying the Automatic Updates ClientThe Automatic Updates Client was developed to automate the installation of security fixes and patches and to give users the option to automatically "drizzle" patches across the Internet to the local computer for installation. Drizzling, also known as Background Intelligent Transfer Service (BITS), is a process in which a computer intelligently utilizes unused network bandwidth to download files to the machine. Because only unused bandwidth is used, there is no perceived effect on the network client itself. The Automatic Updates Client was included as a standard feature installed with Windows 2000 Service Pack 3 and Windows XP Service Pack 1. It is also available for download as a separate component. Understanding the Development of Software Update ServicesThe Windows Update website and the associated client provided for the needs of most home users and some small offices. However, large organizations, concerned about the bandwidth effects of downloading many updates over the Internet, often disabled this service or discouraged its use. These organizations often had a serious need for Windows Update's capabilities. This fact led to the development of Software Update Services. SUS is a free download from Microsoft that effectively gives organizations their own, independent version of the Windows Update server. SUS runs on a Windows Server 2003 (or Windows 2000) machine that is running Internet Information Services. Clients connect to a central intranet SUS server for all their security patches and updates. SUS is not considered to be a replacement technology for existing software deployment solutions such as Systems Management Server (SMS), but rather it is envisioned as a solution for mid- to large-size businesses to take control over the fast deployment of security patches as they become available. Service Pack 1 for SUS added additional capabilities and fixed several issues. The following is a list of items addressed and features added in SUS Service Pack 1:
Defining SUS PrerequisitesDeploying SUS on a dedicated server is preferable, but it can also be deployed on a Windows Server 2003 member server, as long as that server is running Internet Information Services. The following list details the minimum levels of hardware on which SUS operates:
In essence, an SUS server can easily be set up on a workstation-class machine, although more enterprise-level organizations may want to build more redundancy into an SUS environment. Installing a Software Update Services ServerThe installation of SUS is straightforward, assuming that IIS is installed and configured ahead of time. The executable for SUS can be downloaded from the SUS website at Microsoft, currently located at the following URL: http://www.microsoft.com/sus To complete the initial installation of SUS, follow these steps:
The administration web page (http://servername/SUSAdmin) is automatically displayed after installation. This page is the main location for all configuration settings for SUS and is the sole administrative console. By default, it can be accessed from any web browser on the local network. All further configuration takes place from the Admin console, as shown in Figure 15.12. Figure 15.12. The SUS Admin console.Setting SUS OptionsAfter installation, SUS does not physically contain any security patches. The first task after installation is configuring all the options available to the server. You can invoke the option page by clicking Set Options in the left pane of the SUS Admin page. Setting Proxy Server OptionsIf using a proxy server on the network, the first set of options in SUS allow the server to utilize a proxy server for downloading updates. If one is not on the network, select Do Not Use a Proxy Server from the options page. NOTE When in doubt, select Automatically Detect Proxy Server Settings. With this setting, if a proxy server does not exist, SUS automatically configures itself not to use a proxy server. SUS Server Name OptionsThe next set of options, shown in Figure 15.13, allows an administrator to specify the server name that clients use to locate the update server. It is recommended to enter the fully qualified domain name (such as server2.companyabc.com) of the server so that clients use DNS as opposed to NetBIOS to locate the server. Figure 15.13. Setting SUS options.Selecting a Content SourceThe Select a Content Source option allows administrators to download SUS updates directly from Microsoft Windows Update servers or from another internal SUS server. In most cases, the former situation applies, although there are large deployment situations in which multiple SUS servers could be deployed and configured to update from each other. Handling Previously Approved UpdatesThe Previously Approved Updates option grants control over whether new versions of updates previously approved by an administrator should be reapproved automatically. Choose the desired option and continue with the configuration. Update Location and Supported Client LanguagesThe final option, addressing the location for updates and supported client languages, is an important one. At this point, SUS can either be deployed as a full-fledged replica of all Microsoft patches or simply configure it to point to a Windows Update server when clients request patches. Most SUS installations choose the former, shown in Figure 15.14, which minimizes client bandwidth concerns to the Internet. If you choose to use Windows Update servers, the clients will be redirected from the SUS server to the Internet Windows Update servers to download the actual security patch. Figure 15.14. Setting more options in SUS.This option also allows you to select the languages in which the security patches will be available. Any languages in use within an organization should be selected here; however, the more languages chosen, the larger the initial and subsequent download will be. Synchronizing an SUS ServerAfter configuring all the options in SUS, particularly the options regarding which security patch languages will be supported, the initial synchronization of the SUS server can take place. To perform the synchronization, follow these steps:
TIP Plan to run the initial synchronization of SUS over a weekend, beginning the download on Friday evening. Given the number of security patches that will need to be downloaded and the overall Internet connection bandwidth consumption used, it is wise to limit the impact that this procedure will have on the user population. Approving SUS Software PatchesAfter the initial synchronization takes place, all the relevant security patches are downloaded and ready for approval. Even though the files are now physically downloaded and in the IIS metadirectory, they cannot be downloaded by the client until the approval process has been run on each update. This allows administrators to thoroughly test each update before it is approved for distribution to SharePoint servers and workstations. To run the approval process, follow these steps:
Depending on the number of updates downloaded, the preceding steps may need to be repeated several times before all updates are approved. NOTE A good approach to testing updates is to download them first on a client with direct access to Windows Update on the Internet. After the test server or workstation is downloaded successfully and all functionality is verified, that particular security patch can be approved in SUS for the rest of the corporate clients. Automatically Configuring SharePoint Servers and Clients to Use SUS Via Group PolicyAs previously mentioned, the Automatic Updates client can be downloaded from Microsoft and deployed on managed nodes in an environment, either manually or through automated measures. Service Pack 3 for Windows 2000 includes the client by default, as well as Service Pack 1 for Windows XP. After the client is installed, it can be configured to point to an SUS server, rather than the default Internet Windows Update location. The configuration of each client can be streamlined by using a Group Policy in an Active Directory environment. Windows Server 2003 domain controllers automatically contain the proper Windows Update Group Policy extension, and a Group Policy can be applied to SharePoint servers and/or clients. Windows 2000 domain controllers can download the necessary SUS template, wuau.adm, from Microsoft. A Group Policy for SUS can be defined by following these steps:
NOTE Organizations that do not use Active Directory or Group Policies have to manually configure each client's settings to include the location of the SUS server. This can be done through a local policy or manually through Registry settings, as defined in the SUS Help. NOTE A useful "trick" for automating the testing of new SUS patches is to deploy two SUS servers and two sets of Group Policies. The first SUS server serves as a Pilot SUS server, and all updates are approved as soon as they become available. A subset of the client population then points to this server through a GPO and installs the patches immediately. After the patch is validated on this pilot group, the "real" SUS server can then be set to approve the patch, deploying the update to the rest of the user population. This model requires more hardware resources but streamlines the SUS update process. Deploying Security Patches with SUSDepending on the settings chosen by the Group Policy or the Registry, the clients managed by SUS will automatically download updates and install them on clients at a specified time. Some computers may be configured to allow for local interaction, scheduling proper times for the installation to take place and prompting for "drizzle" downloading. Clients configured to use SUS are not prompted to configure their Automatic Update settings, and they are grayed out to prevent any changes from occurring. Users without local administrative access cannot make any changes to the installation schedule, although local admin users can postpone forced installs. NOTE Generally, it is good practice to allow SharePoint servers to control the download and installation schedule, but to force clients to do both automatically. Depending on the political climate of an organization, this may or may not be a possibility. |