Maintaining Security by Implementing, Managing, and Troubleshooting Service Packs and Security Updates

This chapter is from the book

MCSA/MCSE Implementing and Administering Security in a Windows 2000 Network Exam Cram 2 (Exam Cram 70-214)

Learn More Buy

This chapter is from the book

This chapter is from the book 

MCSA/MCSE Implementing and Administering Security in a Windows 2000 Network Exam Cram 2 (Exam Cram 70-214)

Learn More Buy

Installing Service Packs and Updates

There are several options for manually applying service packs and hotfixes. You can install service packs in the following ways:

• Through group policy

• By using Microsoft SMS

• By slipstreaming content to a network installation share of the I386 folder

• During a RIS installation

• Via custom scripts

You can also apply hotfixes by using most of these methods.

Using Group Policy to Install a Service Pack

Group policy software can be used to push service pack installations to existing client computers. An update.msi file is necessary for this. It was necessary to download the update.msi file for Service Pack 1; this file can be found in an expanded Service Pack 2 or Service Pack 3 executable. To expand the service pack, you use the following command:

win2kspx –x

In this command, x should be replaced by the number 2 or 3, to indicate Service Pack 2 or Service Pack 3, respectively.

To create the group policy, you follow these steps:

1. Expand the service pack into a folder and share this folder.

2. In the Active Directory Users and Computers console, right-click the organizational unit (OU) where you want to create the group policy, and then click Properties.

3. Make a new group policy object (GPO) and edit it.

4. Select Computer Configuration, Software Settings, Software Installation and make a new package.

5. Browse to the update.msi file in your shared distribution folder. If the shared folder is on the domain controller, don't browse to the local path. Make sure you locate it through its network path. (If you use a local path on the domain controller, the workstation will not be able to find it.)

6. Modify the default method to enable the option Uninstall This Application when It Falls Out of the Scope of Management. This allows the uninstallation of the service pack by moving the computer from this OU.

Using SMS for Service Pack Installation

The creation of an SMS package to allow the installation of service packs is beyond the scope of Exam 70-214. However, you need to know that this is possible and that it involves the following steps:

1. Importing the package definition file for the service pack—A package definition file is a specially formatted file that contains the information necessary to create the SMS package. When you import this file, SMS creates the package automatically. The package file can then be modified for the specific installation.

2. Providing the path to the service pack source files—One of the modifications to the package file must be pointing SMS to the location for the intended installation files. Service pack files should be copied to their own network distribution share (for example, using xcopy D:\ e:\w2ksp2.exe /x) and then extracted (using w2ksp2.exe /x).

3. Distributing the SMS package to the distribution point—Distribution points are shared network folders where SMS clients can access the package.

4. Creating the advertisement to notify SMS clients about the service pack—The advertisement is the offer to the clients to let them know that the package is available. SMS allows you to select some or all clients to advertise the package to.

Slipstreaming

Slipstreaming is the process of adding service pack files to the contents of an accessible I386 folder that contains the same contents as the I386 folder from the original Windows installation CD-ROM. The updated I386 folder can reside on the computer's hard disk (this is not recommended) or on a network distribution share, or it can be burned onto a bootable CD-ROM. Windows 2000 computers installed from the updated folder already have the service pack installed, provided that the updates are incorporated into the delivery point.

If the path to the service pack update.exe is D:\I386\update\update.exe (as it might be if you had the Windows 2000 installation CD-ROM in the D: drive) and the installation share is C:\I386, then this is the command you use for slipstreaming:

D:\I386\update\update.exe –S:C:\I386

Installing Hotfixes During Installation

Bringing up machines in a patched state is always desirable. To add Windows hotfixes during the installation process, two techniques are available: using cmdlines.txt and using svcpack.inf.

Using cmdlines.txt to Apply Hotfixes

To apply hotfixes during an unattended installation, you use the cmdlines.txt file. The following steps are necessary:

1. Create a distribution folder.

2. Create the answer file unattend.txt by using the Setup Manager tool. unattend.txt will contain any computer-specific information needed by the commands in the cmdlines.txt file.

3. Create the cmdlines.txt file by using the Setup Manager tool. cmdlines.txt is a file that contains the commands that would run during the GUI installation. These commands can be hotfix installation commands as well.

4. Add the I386 folder from the Windows installation CD-ROM to the distribution folder.

5. Add the unattend.txt and cmdlines.txt files to the \I386\$OEM$ subfolder.

6. Add hotfix executable files to the \I386\$OEM$ subfolder. (Hotfix files are named six-digit-number.exe, where the six-digit number is the number assigned to the hotfix.) Hotfix files can be downloaded from Microsoft's Web site.

7. Add lines to the cmdlines.txt file, which is a file that must be available if a Windows automated installation requires the running of different code (for example, installation of applications or addition of hotfixes) after the operating system is installed. For example, to install the hotfix Q123456.exe, you use this line in the [Commands] section of the cmdlines.txt file:

"Q123456 /q"

Using svcpack.inf to Install Hotfixes

When you use svcpack.inf to install hotfixes during Windows installation, you can use the Windows 2000 integrated (that is, Windows 2000 and service pack) installation CD-ROM to install the post–service pack hotfixes. To do so, you follow these steps:

1. Share the intended distribution drive folder.

2. Create an \I386 folder within this share.

3. Use xcopy to copy files and folders from the integrated Windows 2000/service pack CD-ROM to the I386 folder.

4. Open the I386\dosnet.inf file with Notepad or another text editor.

5. Locate the uniproc line in the [OptionalSRCDirs] section of the dosnet.inf file. After this line, create a new svcpack line. The section should look like this:

[OptionalSRCDirs]
uniproc
svcpack

6. Save the changes and close dosnet.inf.

7. Create an I386\svcpack folder.

8. Copy each hotfix executable to the I386\svcpack folder. You must rename the hotfix files to use the 8.3 naming format (for example, Qxxxxx.exe).

9. Expand each hotfix to a unique temporary location by using the filename –x command. When you're prompted for a folder, enter the name of the hotfix (such as Qxxxxx).

10. Delete from the I386 folder the files that you want to replace with service pack or hotfix files.

11. Copy the sp3.cat catalog file to the network distribution folder if the sp3.cat file is a later version than the one that's already in the distribution folder. You can use the catver.exe tool to determine the version.

12. Copy the hotfix files from the temporary folders to the network distribution folder. (If hotfix files exist in a subfolder, you need to make sure to copy them to a folder of the same name that you have created as a subfolder of the I386 folder.) (Files in the symbols subfolder do not need to be copied, nor do the hotfix.exe, hotfix.inf, or spmsg.dll files.)

13. Repeat steps 11 and 12 for each hotfix.

14. Delete the I386\svcpack.inf file.

15. Create a new svcpack.inf file with a text editor and include the following lines:

[Version]
signature="Windows NT$"
MajorVersion=5
MinorVersion=0
BuildNumber=2195
[SetupData]
CatalogSubDir="I386\svcpack"
[ProductCatalogsToIinstall]
sp3.cat
[SetupHotfixesToRun]

16. For each hotfix, add a new line in the [SetupHotfixesToRun] section of the file, using the following format:

Q##### /q /n /z

Add the following line at the end of the file:

qchain.exe

17. Download the free qchain utility from http://www.microsoft.com/technet/security and copy it to the I386\svcpack folder.

18. Run Windows 2000 Setup.

19. Test the installation. To determine whether hotfixes are installed, look for the hotfixes to appear in the Add/Remove Programs tool in the Control panel and an uninstallation folder to appear for each hotfix in the %SYSTEMROOT% folder. The setupapi.log file should also have entries.

Using RIS

You can use RIS to automatically install the Windows 2000 and XP operating systems. If they are appropriately configured, modern PCs can simply boot, locate a DHCP server to obtain an IP address, connect to the network, and contact a boot server to install the operating system.

Adding Service Packs via RIS Installation

To automate the installation of service packs during a RIS installation, you follow these steps:

1. Edit the unattended installation file appropriately for unattended installation of the computer.

NOTE

When RIS is installed, all the default folders are created, as are the files needed for creating RIS installations. Templates are provided for files that you must build. ristndrd.sif is the name of a sample RIS template that could be used to create your own unattended installation file, but your file can have its own name, as long as the syntax is correct and the .sif extension is used. Details of this file can be found in the document "Remote Installation Services (RIS)," at http://www.microsoft.com/technet/prodtechnol/windows200serv/deploy/depopt/remote.asp.

2. Locate the [GuiRunOnce] section of the unattended installation file. Anything you list here is automatically placed in the installed computer's RunOnce registry key. A RIS Windows setup automatically performs an administrative logon after installation, and thus anything in the RunOnce registry key will run.

3. Copy the service pack's update.exe program to an accessible network share. In the example shown in step 4, this program exists in the sp folder beneath the server\share folder.

4. Call update.exe by placing the two commands in the following code in the [GuiRunOnce] section:

net use n: \\server\share password /USER:username /persistent:no
N: \sp\update.exe –u

The –u switch allows the service pack to be installed in unattended mode. No user intervention is necessary; however, status messages will display onscreen.

5. Save the file.

Adding Hotfixes by Using RIS

You might want to evaluate whether the time needed to keep the unattended installation file up-to-date and the RIS server updated with current post–service pack fixes is necessary depending on your current patching strategy. Although it is desirable to have each newly installed computer join the production network thoroughly up-to-date, if your patching process automatically and regularly scans network computers, determines patch status, and applies patches, then this might be sufficient in your environment. You should carefully assess the risk and determine the best security practice for your organization.

To have RIS installations apply hotfixes, you must do the following:

• Ensure that patches reside on an accessible network share.

• Configure RIS to install the appropriate service pack.

• Add script lines to the [GuiRunOnce] section of the unattended installation file. Examples of appropriate lines can be found in the "Using Custom Scripts" section of this chapter.

Using Custom Scripts

In many environments, using existing tools to update computers is not possible. In very small environments, for example, use of SMS or even SUS would be overkill and would incur unwelcome expense. In other environments, where SUS is a welcome tool for patching maintenance, there are still other areas that require help. For example, SUS does not provide a way to patch Microsoft Exchange or to update user files, applications, scheduled jobs, and so on.

The solution, of course, is to script these tasks. Batch files, or scripts, require knowledge of the applicable switches. Switches for the hotfix.exe hotfix installation file, hfnetchk, update.exe, application-specific update programs, and other tools help you build appropriate scripts. In time, you might develop a library of appropriate scripts and batch files to automate their use via the AT utility or the Task Scheduler.

A tutorial on scripting is beyond the scope of Exam 70-214, but knowledge of how to use the hotfix, qchain, and hfnetchk commands is not. Switches and/or their use for the hotfix, qchain, and hfnetchk commands are described in the following sections. Other switches and command syntax are listed in other sections of this chapter where commands and tools are described.

The hotfix Command

The switches for the hotfix command are listed in Table 3.4. In addition to selecting switches appropriate to your needs, you need to remember to make sure you use the hotfix –m (unattended mode) switch in a script because installations might be scheduled to run unattended.

Table 3.4 hotfix Command Switches

The qchain Command

Although you can install multiple hotfixes at once by running a prepared batch file, the probability for inappropriate installations of DLLs is possible. This is because of the way information about necessary files is managed by the update process. If an update that requires a reboot is installed and the system is rebooted before another update is applied, all is well. However, if updates are chained in a batch file with only a final reboot, it is possible that the incorrect versions of files are installed or that required updates will not occur.

To resolve this issue and allow multiple updates to be installed, Microsoft supplies the qchain utility. The following is an example of a qchain batch file:

qxxxxx_w2k_sp2_x86_en.exe –z –m –q
qxxxxx_w2k_sp2_x86_en.exe –z –m -q
qxxxxx_w2k_sp2_x86_en.exe –z –m –q
qchain \\name\logs\%computername%_qchainlog_0x.txt
shutdown /l /r

The qchain command includes the network location of a logfile in which to log qchain results and includes a unique computer name (the computer name of the computer on which the updates occur). Thus, a centralized location for logs of updated systems can be managed. In the qchain statement, name indicates the name of the central computer, and logs indicates a share on that computer.

The shutdown command shown in this example is from the Windows 2000 Server Resource Kit, and the provided switches include -l (logoff) and -r (clean shutdown and restart).

Using SUS

SUS is a new, free tool provided by Microsoft to assist in patch management. It is targeted at the environments that have 50–500 computers.

Using Windows Update services on corporate computers is not a valid option for most businesses. Users would require administrative privileges, or administrators would have to spend extra maintenance time with user desktops. In addition, there is no built-in way to approve some updates while disallowing others. There's no centralized control, and there is no way to pretest before updating. Windows SUS is designed to solve these problems.

SUS is installed on a server on the local network, and it downloads critical updates to a repository on the server. After administrator approval, the updates can be delivered to the user systems. User systems can be pointed to the SUS server, instead of to Windows Update, for updating.

Benefits of SUS include the following:

• Administrator-controlled synchronization service on the local network—You have a choice of manual or scheduled synchronization with Microsoft.

• Intranet-hosted update server—Multiple SUS servers can be used and can synchronize with intranet servers or a Microsoft server.

• Administrator control over updates—Until downloaded updates are approved on the SUS server, they are not available to users.

• Email notification service—The administrator is advised of new updates.

• Statistics published to a log—Statistics on updates that have been downloaded and whether they have been installed can be published to a preferred Web server (a server other than the SUS server) log.

• Automatic updates—You can automatically check for updates published on Microsoft's server. You can do this locally on a configured schedule.

• Multiple SUS servers—A SUS server can be pointed to another SUS server instead of to Windows Update.

• Actual update downloads or client downloads of approved updates from the Internet—Large networks with geographical spread might enjoy using Internet downloads, whereas systems on isolated networks might benefit from using downloads placed on the SUS server.

• Administration via HTTP or HTTPS—A browser can be used to administer SUS remotely. To improve security, the IIS can be appropriately configured for HTTPS.

• Automated client updates—Automated client updates can be done without administrative intervention on the client, or they can be set to require administrative intervention on the client.

SUS Requirements

In order to use SUS, both client and server software must be installed. Server and client software can be downloaded from Microsoft. Client software is a part of updated service packs.

In order to run SUS, a server must meet the following requirements:

• The server must be running Windows 2000 with Service Pack 2 or later.

• IIS must be enabled on the server.

• Internet Explorer 5.5 or later must be installed on the server.

• IIS should only host SUS because the security tool URLScan is used to lock down the server. Only the World Wide Web portion of IIS and its dependencies should be running. FrontPage Server extensions are not required. WebDAV, Internet printing, and the indexing service are turned off. Session state is disabled. Active Server Pages (ASPs) cannot create a session for each user who accesses an ASP program, and ASP scripts cannot store information in the session object or use the session_onstart or session_onend events.

• The server cannot be running Active Directory services or Microsoft Small Business Server (SBS).

• The server should be running most updated patches before SUS is installed.

• The minimum server requirements are Pentium III 733MHz with 512MB of RAM, a network adapter, and an NTFS partition with at least 100MB available for installing SUS and at least 6GB storage for the update if updates are to be stored locally. (This configuration can support 15,000 client machines.)

Client systems can run any of the following:

• Windows 2000 Professional Service Pack 2 or later.

• Windows XP Professional or Windows XP Home; Windows XP systems must update to Service Pack 1 in order to use automatic updates with SUS.

• Windows 2000 Server Service Pack 2 or later, Windows 2000 Advanced Server Service Pack 2 or later, or Windows 2000 Datacenter Server Service Pack 2 or later.

The SUS Setup Process

Installation of SUS on the server and configuration of clients to use it are straightforward. The following presetup process should be followed for the server installation:

1. Physically disconnect the server from the network.

2. Install Windows 2000. Do not install antivirus software, or make sure it is turned off during the installation of service packs, hotfixes, and SUS.

3. Install IIS. Also, run the IIS Lockdown tool before you reconnect the client to the network. IIS Lockdown helps to protect IIS by removing vulnerabilities.

4. Install the latest service packs, security rollup, and any security-related patches. There is no need to install the Microsoft Security toolkit because it is installed during SUS installation.

A local administrator can configure SUS. Configuration consists of setting the following:

• Whether update files are hosted on the SUS server or downloaded from the public Windows Update (Microsoft's) servers

• Proxy server information

• Options for handling approved content

• A list of client languages to support

In addition, if updates are not automatically synchronized, you should subscribe to the update alert service so that new updates can be manually downloaded. Finally, regular maintenance (which is restricted to local administrator access) includes the following:

• If synchronization is manual, maintenance should include downloading new updates as they are announced.

• Before updates can be made available for clients, an administrator must determine and approve the content to be published to computers running automatic updates.

• The server status and logs should be monitored.

The client software must also be installed (or obtained by installing the appropriate service pack: Windows 2000 Service Pack 3 or Windows XP Service Pack 1) on each client computer. Client installation and configuration consists of the following:

1. Installing the client. If Service Pack 3 has been loaded, the client is already available.

2. Restarting the computer.

3. Configuring the client to use SUS. Instructions for performing this step are detailed later in this chapter, in the section "Configuring Update Policies in SUS."

How SUS Works

When updates are available, the following technology comes into play with SUS:

• SUS checks for a digital signature on files.

• Each client is scanned to determine the applicability of the update.

• The background intelligent transfer service (BITS) is used for background download. BITS, which is included with Windows XP, uses only idle bandwidth. The automatic update installer (or Service Pack 3) installs BITS for Windows 2000 systems.

• Windows Update technologies automatically batch updates so that if restarts are necessary, only one restart is required.

• The process can be configured via group policy, logon scripts, and registry keys.

Server processes include reliance on back-end technology used by the Microsoft Public Windows Update since mid-1998. In addition, the synchronization process validates the digital certificates; if the package is not from Microsoft, it is deleted. At all times, updates must be approved before they are made available for download by clients.

The following steps occur in the server synchronization process:

1. The SUS server connects to public Windows Update service and downloads content update metadata (that is, information on updates that are available for download).

2. SUS validates the metadata package for digital certificate.

3. SUS opens the metadata package.

4. SUS compares the metadata package information with its local copy and identifies new and duplicate files. The following actions are performed, depending on the differences found:

• If a previous available update has been removed from public Windows Update service, it is revoked from the SUS server. Client machines are no longer offered the previously offered update.

• If a previously available update has had files updated, files are automatically updated on the server. (Note that this type of update may be auto-approved or unapproved, depending on settings set by the administrator.)

• If the server includes synchronization of update files (versus just metadata), new files are downloaded to a prespecified location.

• If a previously downloaded file is missing from the intranet location, a new copy is downloaded.

• If a file specified in the metadata cannot be downloaded, the associated metadata is removed from the list of xxx that can be approved for client downloads.

5. When changes are complete, if SUS is configured for manual synchronization, the success or failure is logged to a synchronization log.

6. If SUS is configured for automatic, scheduled synchronization and it fails, an attempt to resynchronize is made 30 minutes later. SUS tries three times by default. Administrators can configure the number of retries. Successful synchronization is logged.

7. Updates need to be approved before they are made available to computers running the automatic update client. If a fix is dependent on the installation of a previous fix, these dependencies are displayed, and all must be approved together, or none are available.

The synchronization logfile is always updated during synchronization, and all events are recorded. The following are some possible events:

• Unable to connect—The client can't connect to the update service.

• Install ready—no recurring schedule—Downloaded updates are listed. To install them, the administrator needs to log on and use the notification area.

• Install ready—recurring schedule—The download time and the date and time of projected installations are listed.

• Install success—Successfully installed updates are listed.

• Install failure—Updates that did not install are listed.

• Restart required—no recurring schedule—To complete the installation, the computer must be restarted.

• Restart required—recurring schedule—The computer will be restarted within 5 minutes. New downloads cannot be searched for until the system reboots.

Configuring SSL to Secure SUS

Because administration on SUS can be performed via a browser, it's important to consider securing the communication between the administrator's browser and the SUS server. You can do so by configuring SUS to use SSL. The details for performing the actions listed here are described in Chapter 5, "Configuring and Troubleshooting Authentication for LANs, Internets, and Intranets," and in Chapter 7.

Configuring Update Policies in SUS

An automatic update policy can be written to perform a scheduled installation at a certain time every day. Automatic updates for servers are often scheduled for the weekend. Three possible responses can occur:

• If a local administrator is logged on, an update notice is displayed and they either allow the update or delay the update (which is then automatically rescheduled for the next day). The local administrator cannot deselect any updates; he or she can only delay them. The local administrator can delay the installation or resume the process at any time.

• If a user who is not an administrator is logged on, or if the computer is running but no one is logged on, the update is automatically installed. If a restart is necessary, a five-minute warning is given to allow a user to save files and log off.

• If the computer is turned off, the update is not installed.

The group policy settings for automatic updates are provided with the SUS installation package in the policy template file, wuau.adm. When the wuau.adm template file is added to the Group Policy Editor, settings are found under Computer Configuration, Administrative Templates, Windows Components, Windows Update. The installation behavior that can be specified is the same as that in the manual, computer-by-computer settings. In a non–Active Directory environment, the local group policy can be configured or registry settings can be set to configure automatic updates.

Using the SMS 2.0 SUS Feature Pack

Just as SMS can be used to deploy a service pack or install software, the SUS Feature Pack can be used to audit, distribute, track, and manage patching of Windows systems. The Feature Pack requires SMS 2.0 (Service Pack 4 is recommended, but the SMS SUS Feature Pack also supports Service Pack 3).

SMS provides computer and software inventory and scheduling of the deployment of updates. It also monitors the update process and targets updates according to system inventory (that is, in Active Directory or in manually created computer groups). Feature Pack tools, including the following, add software management features:

• Security Update Inventory Installer—This tool creates an inventory of applicable and installed security updates for client computers. It has three main components:

• A Security Update Inventory Installer that builds the package, collection, and advertisement necessary to deploy

• The Security Update Inventory tool, which uses MBSA and the Security Patch Bulletin catalog (mssecure.xml) to scan clients

• A Security Update Synchronization tool that checks the Microsoft downloads site, looking for the new update bulletin catalog, and sends the latest version of the catalog to client computers

• Office Update Inventory Tool—This tool performs similar tasks (scans clients to determine necessary changes) for Office.

• Distribute Software Updates Wizard Installer—This tool performs software update distribution tasks such as analyzing update status for clients, providing a method for reviewing and authorizing updates, downloading updates, building packages and advertisements, distributing update advertisements, and deploying the Software Updates Installation Agent to clients. The Software Updates Installation Agent evaluates updates against missing and previously installed updates on clients.