The entire software update process can break at many
different points. Multiple components coordinate their efforts to make
the process hum along normally; however, when something goes wrong, the
first step is identifying which component is having issues. Depending
on the exact failure point, you can review a variety of log files for
error messages.
It is also important to track and report on the status of software
updates to “the powers that be” or the “senior partners,” whichever you
are subject to. The next sections discuss how to monitor software
updates as well as those areas that typically have issues and how to
diagnose and (hopefully) fix them.
Monitoring Software Updates
There
are two primary ways to monitor your software update status in
ConfigMgr. The first and traditional way is to use reporting. As of
ConfigMgr 2007 R2, there are 34 reports out of the box specific to
tracking various aspects of Software Updates, including client scan
states, update applicability, deployment progress, and compliance. Like
all ConfigMgr reports, you can copy and customize these to fit your
exact needs.
The second way to monitor
Software Updates is using the Software Updates home page, accessible by
directly selecting the Software Updates node in the ConfigMgr admin
console tree (Site Database -> Computer Management -> Software
Updates). This page provides a dashboard for finding summary
information concerning your Software Updates stance. Figure 1 displays an example of this home page.
You
can select a subset of updates from the update repository by defining
filter criteria for the Vendor, Month and Year, and Classification.
This populates the list box on the left with updates matching the
specified filter criteria. For Microsoft Updates, the listed Article
IDs are actually hyperlinks that take you directly to the TechNet
knowledge base article describing the update. The % Compliant column
also contains hyperlinks that launch the specific
software update states report, which details the count and percentage
of computers in each compliance state for the specified software
update. In addition to the list of updates on the left, a pie chart
summarizing the compliance state of updates selected in the list is
displayed on the right. You can select multiple updates in the usual
way to update the pie chart with aggregate data from all the updates
selected.
Links at the bottom of the page
take you to other nodes in the admin console, significant reports, and
applicable help documentation.
WSUS and SUP
The
first component in Software Updates is WSUS. WSUS is significant
because it acquires all information about available updates and
distributes that catalog of updates to clients. Luckily, ConfigMgr
takes over control of WSUS using an SUP and creates detailed log files
of the WSUS operation. Here are the three main log files for WSUS and
an SUP, located in <ConfigMgrInstallPath>\Logs:
WCM.log—
Provides information about the software update point configuration and
connecting to the WSUS server for subscribed update categories,
classifications, and languages.
WSUSCtrl.log— This log file provides information about the configuration, database connectivity, and health of the WSUS server for the site.
wsyncmgr.log— Provides information about the software updates synchronization process.
Most
errors experienced with WSUS are configuration errors, including not
matching the ports configured during installation of WSUS and then
configured in the SUP (Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Site Systems -> ConfigMgr software update point).
Also
common are Internet connectivity issues due to firewalls, proxy
servers, or other mitigating factors. Always confirm that the system
running WSUS has Internet connectivity if you are downloading the
update catalog directly from Microsoft, and ensure that you have
properly configured the proxy account if one is required (Site
Management -> <Site Code> <Site Name> -> Site Settings -> Component Configuration -> Software Update Point Component).
Downloading Updates
It
is possible for the update downloads from Microsoft to fail. Recall
that WSUS does not download the updates in ConfigMgr; you must manually
initiate download of all updates. This is an interactive process; the
ConfigMgr console connects to the Microsoft download servers using the
credentials of the user currently logged in to the console. You can
easily test connectivity for the current user by opening Internet
Explorer and navigating to http://www.microsoft.com/downloads.
(If a proxy server is required to connect to the Internet, configure
the settings in Internet Explorer.) If the logged-in user does not have
permission to perform the action, the download will not take place.
The
PatchDownloader.log file logs download activity for updates. This log
contains information about every patch the console attempts to
download. The file is located in one of two places:
%ProgramFiles%\Microsoft Configuration Manager\Logs— If you are running the console on the site server
%ProgramFiles%\Microsoft Configuration Manager Console\AdminUI\AdminUILog— If you are running the console remotely
Client Update Scanning and Deployment
WUA
on the local system handles the process of scanning a client for
applicable updates. The ConfigMgr agent initiates the scanning
according to the defined schedules or any on-demand requests; the WUA
will in turn report back to the ConfigMgr agent. The following
client-side log files, located in the %SystemRoot%\System32\CCM\logs folder on 32-bit clients and %SystemRoot%\SysWOW64\CCM\logs on 64-bit clients, can help when investigating failures:
ScanAgent.log—
Provides information about the scan requests for software updates, the
tool requested for the scan, the WSUS location, and so on
UpdatesDeployment.log— Provides information about the deployment on the client. This includes software update activation, evaluation, and enforcement
UpdatesHandler.log—
Provides information about software update compliance scanning as well
as download and installation of software updates on the client
UpdatesStore.log— Provides information about the compliance status for software updates assessed during the compliance scan cycle
WUAHandler.log— Provides information regarding when the Windows Update Agent on the client searches for software updates
One
of the main issues that can affect the scanning process is having a
domain-based GPO override the Windows Updates settings. The
WUAHandler.log file will clearly indicate if this issue exists in your
environment.
