|
You can divide the actual software update process in ConfigMgr 2007 into four separate steps:
1. | Catalog synchronization—The
first step when applying patches is to define which patches are
available for installation. Thankfully, Microsoft provides a catalog of
all available updates for Microsoft products; it specifies how to
detect whether a patch is applicable to a system. WSUS and its
integration into ConfigMgr as an SUP handles the catalog-download
process. Microsoft and other third-party documentation may also refer to the update catalog as update metadata.
| 2. | Compliance scanning—After
the update catalog is downloaded and imported into ConfigMgr, a new
ConfigMgr machine policy is created, informing each managed system that
a new update catalog is available. Managed systems retrieve the policy
according to their policy download cycle (by default every 60 minutes).
After receiving the new policy, clients randomly schedule an update
scan to occur within the next 2 hours, clear the previous scan history,
and configure the local policy to point the WUA at the WSUS server.
At the randomly scheduled time, the ConfigMgr Client agent invokes the
local WUA to initiate a compliance scan. The WUA contacts WSUS to
retrieve the catalog and scan for the updates it needs. Every 5
minutes, information about required updates is cached and forwarded en
masse to the site’s management point with state messages; these state
messages are subsequently inserted into the ConfigMgr database. This
process ensures that update compliance information is available in a
timely manner.
Note: WUA Version
A
common cause of scan compliance failures is the absence of the correct
version of the WUA on clients; these are listed as “unknowns” in the
console. Because the WUA is automatically updated by Microsoft Windows
Update and WSUS, if you are moving clients from this type of
environment your clients should all be updated to the latest version of
the WUA (version 7.2.6001.788 as of May 2009 as described in KB article
949104 at http://support.microsoft.com/kb/949104).
To
verify the current version of the WUA on all clients, run the Scan 1 –
Last scan states by collection or Scan 2 – Last scan states by site
report, use the Resource Explorer, or create a query containing the
following syntax:
SELECT v_R_System.Netbios_Name0, v_GS_WINDOWSUPDATEAGENTVERSIO.Version0
FROM v_GS_WINDOWSUPDATEAGENTVERSIO
INNER JOIN v_R_System ON v_GS_WINDOWSUPDATEAGENTVERSIO.ResourceID =
v_R_System.ResourceID
WHERE v_GS_WINDOWSUPDATEAGENTVERSIO.Version0 <> 'ISNULL'
ORDER BY v_GS_WINDOWSUPDATEAGENTVERSIO.Version0
To
distribute the latest WUA to all clients, download the installation
package from KB article 949104 referenced above, and create a Software
Distribution package to deploy it. For the program information, specify
the following command-line text:
WindowsUpdateAgent30-<platform>.exe /quiet /norestart /wuforce
Table 1. Update Compliance State| State | Description |
|---|
| Required | Specifies
the software update is applicable and required on the client. Any of
the following four conditions can be true when the software update
state is Required: The software update is not deployed to the client computer.
The
software update was installed on the client computer, but the most
recent state message is not inserted into the site server database. The
client computer will rescan for the update after installation
completes—there can be a delay of up to 2 minutes before the client
sends the updated state to the management point, which forwards it to
the site server.
The software update
was installed on the client computer, but the installation requires a
computer reboot before the update is complete.
The software update was deployed to the client computer but not yet installed. | | Not Required | Specifies the software update is not applicable on the client computer, so the update is not required. | | Installed | Specifies the software update is applicable on the client computer and the client computer already has the update installed. | | Unknown | Specifies the site server has not received a state message from the client computer, typically for one of the following reasons:
The client computer did not successfully scan for software updates compliance.
Although
the scan completed successfully on the client computer, the state
message has not been processed yet on the site server, possibly due to
a backlog of state messages.
Although the scan completed successfully on the client computer, the state message has not been received from the child site.
The scan completed successfully on the client computer, but the state
message file was corrupted in some way and could not be processed. |
|
Compliance
scans are initiated as either forced or unforced. Forced scans always
happen; unforced scans may be deemed unnecessary and do not occur if
the last compliance scan time, referred to as the time to live (TTL) of
the last scan, is less than 24 hours old.
Additionally, clients perform compliance scans in one of two ways—online or offline:
In an online scan, the full update catalog is retrieved by the client; this is typically an expensive operation network-wise. An offline scan uses the locally cached catalog on the client.
If
not forced to use an online scan, clients choose between an online and
offline scan based on the version of the update catalog currently
cached. If the cached version is the same as that on the SUP or the SUP
cannot be contacted, an offline scan is performed using the currently
cached copy. If the version on the SUP is newer, the client downloads
the new catalog and then performs the scan.
Table 2 summarizes both the scan initiation types and the scan compliance types.
Table 2. Scan Initiation| Initiated By | Initiation Type | Scan Type |
|---|
| Client Agent Properties, general scan schedule | Forced | Online | | Client Agent Properties, deployment reevaluation schedule | Unforced | Based on catalog version | | Deployment, activation time | Unforced | Based on scan TTL and catalog version | | Deployment, deadline time | Forced | Online | | ConfigMgr Control Panel Applet, deployment reevaluation schedule | Forced | Online | | ConfigMgr Control Panel Applet, software update deployment evaluation | Forced | Based on catalog version |
|
| 3. | Update preparation—In
this manual step, you must determine which updates to deploy to your
managed systems. ConfigMgr helps significantly by identifying how many
systems are requesting specific patches, but the final determination of
which updates to deploy is up to you.
After deciding what to
deploy, download the updates into update packages and create
deployments to direct managed systems to install the updates. These two
steps are analogous to the normal software distribution process using
software distribution packages and assignments.
| 4. | Update distribution—This
“rubber hits the road” step is automatically handled by ConfigMgr,
similar to the way it handles software distribution. Here are some key
points:
When a managed system
receives a deployment policy, it immediately initiates another update
compliance scan using the WUA to ensure the state of the system has not
changed. After the scan, the systems
immediately download applicable updates for mandatory deployments and
schedule installation according to their maintenance windows. If there
are no maintenance windows, installation occurs immediately. Updates for optional deployments are not downloaded until they are manually initiated. The
client only downloads individual updates identified as necessary by the
compliance scan—complete update packages are not downloaded.
State messages communicate back to the site to ensure the update status
in the database is accurate, eliminating the need to perform another
compliance scan. This allows ConfigMgr to have current information
about the exact patch status of a system in a short period of time
rather than waiting for the next compliance scan, which may not take
place until the next day or perhaps next week. Full compliance scans
needlessly strain the system while obtaining the same information that
simple status messages makes available.
|
Figure 1 depicts this four-step process:
1. | The update catalog is downloaded from Microsoft and imported into the WSUS database.
The update catalog is synchronized from the WSUS database to the ConfigMgr database.
| 2. | The
site creates a policy informing clients of the availability of a new
update catalog; the management point downloads this policy and makes it
available for retrieval by clients.
Clients download the new policy from the management point.
Clients retrieve the update catalog from WSUS and perform a compliance scan.
Clients report their compliance status to the management point.
Client compliance states are sent to the database.
| 3. | Search
folders, update lists, deployments, and deployment packages are created
according to the steps outlined in the next few sections.
| 4. | Updates,
based on defined deployments, are downloaded from distribution points
and installed. New client compliance information status is sent to the
distribution point immediately and then to the ConfigMgr database.
|
ConfigMgr
provides five distinct objects for you to control the deployment of
updates in your environment. A subnode under Software Updates in the
ConfigMgr console tree represents each of these objects:
Update Repository Update Lists Deployment Templates Deployment Management Deployment Packages
The
like-named sections of the chapter discuss these objects in detail, but
first let’s look at a step-by-step sample configuration to help get you
up and running quickly.
|
