Troubleshooting the Windows Update Client CHAPTER 23
1103
4.
If you can reach the WSUS server, verify that the client is configured correctly. If you
are using Group Policy settings to configure Windows Update, use the Resultant Set of
Policy (RSOP) tool (Rsop.msc) to check the computer’s effective configuration. Within
RSOP, browse to the Computer Configuration\Administrative Templates\Windows
Components\Windows Update node and verify the configuration settings. Figure 23-5
shows the RSOP snap-in.
FIGURE 23-5
Use the RSOP snap-in to verify Windows Update configuration.
5.
If you think WSUS is not configured correctly, verify the IIS configuration. WSUS uses
IIS to update most client computers automatically to the WSUS-compatible Automatic
Updates. To accomplish this, WSUS Setup creates a virtual directory named /Selfupdate
under the Web site running on port 80 of the computer on which you install WSUS. This
virtual directory, called the self-update tree, holds the latest WSUS client. For this reason,
a Web site must be running on port 80, even if you put the WSUS Web site on a custom
port. The Web site on port 80 does not have to be dedicated to WSUS. In fact, WSUS
uses the site on port 80 only to host the self-update tree. To ensure that the self-update
tree is working properly, first make sure a Web site is set up on port 80 of the WSUS
server. Next, type the following at the command prompt of the WSUS server.
cscript <WSUSInstallationDrive>:\program files\microsoft windows server
update services\setup\InstallSelfupdateOnPort80.vbs
MoRe inFo
For more information about troubleshooting WSUS, visit
/>If you identify a problem and make a configuration change that you hope will resolve it,
restart the Windows Update service on the client computer to make the change take effect
and begin another update cycle. You can do this using the Services console or by running the
following two commands.
net stop wuauserv

deploying updates is one of the first decisions that you and your company’s management
will make. Even before staffing can begin, however, you need to identify the team roles,
or areas of expertise, required for update management. Microsoft suggests using the
Microsoft Solutions Framework (MSF) team model, which is based on six interdependent,
multidisciplinary roles: product management, program management, development, testing,
user experience, and release management. This model applies equally well to both Microsoft
and non-Microsoft software.
n
Program management The program management team’s goal is to deliver updates
within project constraints. Program management is responsible for managing the
update schedule and budget, reporting status, managing project-related risk factors
(such as staff illnesses), and managing the design of the update process.
n
Development The development team builds the update infrastructure according to
specification. The team’s responsibilities include specifying the features of the update
infrastructure, estimating the time and effort required to deploy the update infrastruc-
ture, and preparing the infrastructure for deployment.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
The Process of Updating Network Software CHAPTER 23
1105
n
Testing The testing team ensures that updates are released into the production en-
vironment only after all quality issues are identified and resolved. The team’s responsi-
bilities include developing the testing strategy, designing and building the update lab,
developing the test plan, and conducting tests.
n
User experience The user experience team ensures that the update process meets
the users’ needs. The team gathers, analyzes, and prioritizes user requirements and
complaints.
n

whether it is a mobile computer that might connect to networks at other locations.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 23 Managing Software Updates
1106
n
Existing countermeasures Firewalls and virus checkers might already protect a
computer against a particular vulnerability, making the update unnecessary. For fire-
walls, document the firewall configuration, including which ports are open.
n
Site If your organization has multiple sites, you can choose to deploy updates to
computers from a server located at each site to optimize bandwidth usage. Knowing at
which site a computer or piece of network equipment is located allows you to deploy
the updates efficiently.
n
Bandwidth Computers connected across low-bandwidth links have special require-
ments. You can choose to transfer large updates during nonbusiness hours. For dial-up
users, it might be more efficient to bypass the network link and transfer updates on
removable media, such as CD-ROMs.
n
Administrator responsibility You must understand who is responsible for deploy-
ing updates to a particular device and who will fix a problem if the device fails during
the update process. If others are responsible for individual applications or services,
make note of that as well.
n
Uptime requirements Understand any service-level agreements or service-level
guarantees that apply to a particular device and whether scheduled downtime counts
against the total uptime. This will enable you to prioritize devices when troubleshoot-
ing and testing updates.
n
Scheduling dependencies Applying updates requires planning systems to be

simply check the Microsoft Web site to ensure that the bulletin is officially listed.
In addition, use non-Microsoft sources to receive an objective opinion of vulnerabilities.
The following sources provide security alert information:
n
Security alert lists, especially SecurityFocus ()
n
Security Web sites, such as and
n
Alerts from antivirus software vendors
Evaluating Updates
After you learn of a security update, you need to evaluate the update to determine which
computers at your organization, if any, should have the update applied. Read the information
that accompanies the security bulletin and refer to the associated Knowledge Base article
after it is released.
Next, look at the various parts of your environment to determine whether the vulnerability
affects the computers on your network. You might not be using the software that is being
updated, or you might be protected from the vulnerability by other means, such as a fire-
wall. For example, if Microsoft releases a security update for Microsoft SQL Server and your
company doesn’t use SQL Server (and it’s not a requirement for other installed applications),
you don’t need to act. If Microsoft releases a security update for the Server service but you
have blocked the vulnerable ports by using Windows Firewall, you don’t necessarily need to
apply the update (although applying the update will provide an important additional layer
of protection). As an alternative, you might decide that applying the update is not the best
countermeasure for a security vulnerability. Instead, you might choose to add a firewall or
adjust firewall filtering rules to limit the vulnerability’s exposure.
Determining whether an update should be applied is not as straightforward as you might
think. Microsoft updates are free downloads, but applying an update does have a cost: You
will need to dedicate time to testing, packaging, and deploying the update. In larger orga-
nizations, applying a software update to a server requires that many hours be dedicated to
justifying the update and scheduling the associated downtime with the groups who use the

networking groups, and internal audit teams to play an active role—their experience and
expertise can be an asset in determining risk. Depending on your needs, the committee can
discuss each update as it is released, or it can meet on a weekly or biweekly basis.
If the committee determines that an update needs to be deployed, you then need to de-
termine the urgency. In the event of an active attack, you must make every effort to apply the
update immediately before your system is infected. If the attack is severe enough, it might even
warrant removing vulnerable computers from the network until the update can be applied.
Speeding the Update Process
I
f it usually takes your organization more than a few days to deploy an update, cre-
ate an accelerated process for critical updates. Use this process to speed or bypass
time-consuming testing and approval processes. If a vulnerability is currently being
exploited by a quickly spreading worm or virus, deploying the update immediately
could save hundreds of hours of recovery time.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
The Process of Updating Network Software CHAPTER 23
1109
Retrieving Updates
After you decide to test and/or deploy an update, you must retrieve it from Microsoft. If
you are using WSUS as your deployment mechanism, WSUS can download the update
automatically. If you are deploying updates by using another mechanism, download the
update from a trusted Microsoft server.
Testing Updates
After applying an update or group of updates to your test computers, test all applications
and functionality. The amount of time and expense that you dedicate to testing the update
should be determined by the potential damage that can be caused by a problematic update
deployment. There are two primary ways you can test an update: in a test environment and
in a pilot deployment. A test environment consists of a test lab or labs and includes test plans,
which detail what you will test, and test cases, which describe how you will test each feature.
Organizations that have the resources to test updates in a test environment should always

in your organization, connect them to a private network. You will also need to connect test
versions of your update infrastructure computers. For example, if you plan to deploy updates
by using WSUS, connect a WSUS server to the lab network.
Load every application that users will use onto the lab computers and develop a procedure
to test the functionality of each application. For example, to test the functionality of Internet
Explorer, you can visit both the Microsoft Web site and an intranet Web site. Later, when test-
ing updates, you will repeat this test. If one of the applications fails the test, the update you
are currently testing might have caused a problem.
note
If you will be testing a large number of applications, identify ways to automate the
testing of updates by using scripting.
In addition to testing your implementation of an update, conducting a pilot deployment
provides an opportunity to test your deployment plan and the deployment processes. It helps
you to determine how much time is required to install the update as well as the personnel
and tools needed to do so. It also provides an opportunity to train support staff and to gauge
user reaction to the update process. For example, if a particular update takes an hour for a
dial-up user to download, you might have to identify an alternative method for delivering the
update to the user.
note
The more significant the update, the more important it is to use a pilot program.
Service packs, in particular, require extensive testing both in and out of the lab.
Besides testing the update yourself, subscribe to mailing lists and visit newsgroups fre-
quented by your peers. People tend to report problems with updates to these forums before
an official announcement is made by Microsoft. If you do discover a problem, report it to
Microsoft. Historically, Microsoft has fixed and re-released security updates that have caused
serious problems. On the other hand, Microsoft support might be able to suggest an alterna-
tive method for reducing or eliminating the vulnerability.
Installing Updates
After you are satisfied that you have sufficiently tested an update, you can deploy it to your
production environment. During the installation process, be sure to have sufficient support

essary provisions are in place for reverting your critical computers back to their original states
in the unlikely event that a security update deployment causes a computer to fail. These pro-
visions might include having spare computers and data backup mechanisms in place so that a
failed computer can be rebuilt quickly.
Auditing Updates
After you deploy an update, it is important to audit your work. Ideally, someone who is
not responsible for deploying the update should perform the actual audit. This reduces
the possibility that the person or group responsible for deploying the update would
unintentionally overlook the same set of computers during both update deployment and
auditing; it would also reduce the likelihood of someone deliberately covering up oversights
or mistakes.
Auditing an update that resolves a security vulnerability can be done in one of two ways.
The simplest way to audit is to use a tool, such as MBSA, to check for the presence of the
update. This can also be done by checking the version of updated files and verifying that the
version matches the version of the file included with the update.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 23 Managing Software Updates
1112
Quarantine Control for Computers That Haven’t Been
Updated
Y
ou should require updates for remote computers connecting via dial-up and
VPN solutions because they might miss your update and auditing. Windows 7
and Windows Server 2008 both support NAP, which you can use to restrict access
to computers that do not meet specific security requirements, such as having the
latest updates, and to distribute the updates to the client computer so that they can
safely join the intranet. For more information about Network Access Protection,
refer to Chapter 25. You can use NAP with a Windows Server 2008 infrastructure as
described in Windows Server 2008 Networking and Network Access Protection (NAP)
(Microsoft Press, 2008).

the maximum risk posed by the vulnerability that the update fixes. This severity level
can be Low, Moderate, Important, or Critical. The MSRC judges the severity of a vulner-
ability on behalf of the entire Microsoft customer base. The impact a vulnerability has
on your organization might be more or less serious than this severity rating.
n
Executive summary An overview of the individual vulnerabilities discussed in the
security bulletin and their severity ratings. One security bulletin might address multiple,
related vulnerabilities that are fixed with a single update.
n
Frequently asked questions Discusses updates that are replaced, whether you can
audit the presence of the update using MBSA or Configuration Manager 2007 R2, life-
cycle information, and other relevant information.
n
Vulnerability details The technical details of the vulnerabilities, a list of mitigating
factors that might protect you from the vulnerability, and alternative workarounds that
you can use to limit the risk if you cannot install the update immediately. One of the
most important pieces of information in this section is whether there are known, active
exploits that attackers can use to compromise computers that haven’t been updated. If
you are unable to install the update immediately, you should read this section carefully
to understand the risk of managing a computer that hasn’t been updated.
n
Security update information Instructions on how to install the update and what
files and configuration settings will be updated. Refer to this section if you need to
deploy updated files manually or if you are configuring custom auditing to verify that
the update has been applied to a computer.
MoRe inFo
If you are not familiar with the format of security bulletins, take some time
to read current bulletins. You can browse and search bulletins at
/technet/security/current.aspx.
In addition to security bulletins, Microsoft also creates Knowledge Base articles about

The chief difference between service packs and other types of updates is that service
packs are strategic deliveries, whereas updates are tactical. That is, service packs are carefully
planned and managed—the goal is to deliver a well-tested, comprehensive set of fixes that is
suitable for use on any computer. In contrast, security updates are developed on an as-needed
basis to combat specific problems that require an immediate response.
note
Service packs undergo extensive regression testing that Microsoft does not per-
form for other types of updates. However, because they can make significant changes to
the operating system and add new features, they still require extensive testing within your
environment.
Microsoft does not release a service pack until it meets the same quality standards as the
product itself. Service packs are constantly tested as they are built, undergoing weeks or months
of rigorous final testing that includes testing in conjunction with hundreds or thousands of non-
Microsoft products. Service packs also undergo a beta phase, during which customers participate
in the testing. If the testing reveals bugs, Microsoft will delay the release of the service pack.
Even though Microsoft tests service packs extensively, they frequently have known ap-
plication incompatibilities. However, they are less likely to have unknown application incom-
patibilities. It is critical that you review the service pack release notes to determine how the
service pack might affect your applications.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
How Microsoft Distributes Updates CHAPTER 23
1115
Because service packs can make substantial changes to Windows 7, thorough testing and
a staged deployment are essential. After Microsoft releases a service pack for beta, begin
testing it in your environment. Specifically, test all applications, desktop configurations, and
network connectivity scenarios. If you discover problems, work with Microsoft to identify the
problem further so that Microsoft can resolve the issues before the service pack is released.
After the service pack is released, you need to test the production service pack carefully
before deploying it.
While testing a newly released service pack, stay in touch with the IT community to

1116
You have to stay reasonably current on updates to continue to receive Microsoft support
because Microsoft provides support only for the current service pack and the one that im-
mediately precedes it. This support policy allows you to receive existing hotfixes or to request
new hotfixes for the currently shipping service pack, the service pack immediately preceding
the current one, or both during the mainstream phase.
Summary
Networks and the Internet are constantly changing. In particular, network security threats
continue to evolve, and new threats are introduced daily. Therefore, all software must change
constantly to maintain high levels of security and reliability.
Microsoft provides tools for managing Windows 7 software updates for home users, small
organizations, and large enterprises. Regardless of the organization, the Windows Update
client in Windows 7 is responsible for downloading, sharing, and installing updates. Small
organizations can download updates directly from Microsoft to a Windows 7 computer, which
will then share the update with other computers on the same LAN. Larger organizations, as
well as organizations that must test updates prior to installation, can use WSUS to identify,
test, and distribute updates. Combined with AD DS Group Policy settings, you can manage
updates centrally for an entire organization.
Additional Resources
These resources contain additional information and tools related to this chapter.
Related Information
n
The Microsoft Update Management Web site at
/updatemanagement.
n
See the MBSA 2.1 Web site at for more information
and to download MBSA.
n
“MBSA 2.0 Scripting Samples” at
/details.aspx?familyid=3B64AC19-3C9E-480E-B0B3-6B87F2EE9042 includes

1119
CHAPTER 24
Managing Client Protection
n
Understanding the Risk of Malware 1119
n
User Account Control 1121
n
AppLocker 1142
n
Using Windows Defender 1149
n
Network Access Protection 1159
n
Forefront 1160
n
Summary 1162
n
Additional Resources 1162
N
etworked client computers are constantly under attack. In the past, repairing
computers compromised by malware was a significant cost to IT departments.
The Windows 7 operating system strives to reduce this cost by using a combination of
technologies—including User Account Control (UAC), Windows AppLocker, and Windows
Defender. Additionally, Microsoft offers Microsoft Forefront separately from Windows 7
to provide better manageability of client security.
Understanding the Risk of Malware
Malware (as described in Chapter 2, “Security in Windows 7”) is commonly spread in
several different ways:
n

social engineering, read “Behavioral Modeling of Social Engineering–Based Malicious
Software” at
/details.aspx?FamilyID=e0f27260-58da-40db-8785-689cf6a05c73.
note
Windows XP Service Pack 2 (SP2), Windows Vista, and Windows 7 support
using Group Policy settings to configure attachment behavior. The relevant Group
Policy settings are located in User Configuration\Administrative Templates
\Windows Components\Attachment Manager.
n
Exploiting browser vulnerabilities Some malware has been known to install itself
without the user’s knowledge or consent when the user visits a Web site. To accomplish
this, the malware needs to exploit a security vulnerability in the browser or a browser
add-on to start a process with the user’s or system’s privileges, and then use those
privileges to install the malware. The risk of this type of exploit is significantly reduced
by Windows Internet Explorer Protected Mode in Windows Vista and Windows 7. Ad-
ditionally, the new Internet Explorer 8 feature, SmartScreen, can warn users before they
visit a malicious site. For more information about Internet Explorer, read Chapter 20,
“Managing Windows Internet Explorer.”
n
Exploiting operating system vulnerabilities Some malware might install itself by
exploiting operating system vulnerabilities. For example, many worms infect computers
by exploiting a network service to start a process on the computer and then install the
malware. The risks of this type of exploit are reduced by UAC, explained in this chapter,
and Windows Service Hardening, described in Chapter 26, “Configuring Windows
Firewall and IPsec.”
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
User Account Control CHAPTER 24
1121
User Account Control
Most administrators know that users should log on to their computers using accounts that

user for administrator credentials For example, if a standard user attempts to
open the Computer Management console, a User Account Control dialog box ap-
pears and prompts for administrator credentials, as shown in Figure 24-1. If the current
account has administrator credentials, the dialog box prompts to confirm the action
before granting the process administrative privileges.
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 24 Managing Client Protection
1122
FIGURE 24-1
UAC prompts standard users for administrator credentials when necessary.
n
Users no longer require administrative privileges for common tasks Windows
Vista and Windows 7 have been improved so that users can make common types of
configuration changes without administrator credentials. For example, in earlier versions
of Windows, users needed administrator credentials to change the time zone. In
Windows Vista and Windows 7, any user can change the time zone, which is important
for users who travel. Changing the system time, which has the potential to be malicious,
still requires administrator credentials, however.
n
Operating system features display an icon when administrator credentials are
required In earlier versions of Windows, users were often surprised when an aspect
of the operating system required more privileges than they had. For example, users
might attempt to adjust the date and time, only to see a dialog box informing them
that they lack necessary privileges. In Windows Vista and Windows 7, any user can
open the Date And Time properties dialog box. However, users need to click a but-
ton to change the time (which requires administrative privileges), and that button has
a shield icon indicating that administrative privileges are required. Users will come to
recognize this visual cue and not be surprised when they are prompted for credentials.
n
If you log on with administrative privileges, Windows Vista and Windows 7