3. Synchronization Process
An
installed SUP can download the Windows Update catalog and associated
metadata from Microsoft or an upstream server; the process is identical
for either source. If a primary SUP cannot directly communicate with
Microsoft to retrieve updates, you can manually import an update
catalog from a server that downloaded the catalog from Microsoft. Both
WSUS 2.0 and 3.0 use the same catalog format; this makes it possible to
use either version to export the catalog manually using the same
commands, as outlined here:
On the Internet-connected WSUS server, open a command prompt and run the following command:
WSUSutil export <export filename.cab> <export log filename>
WSUSUutil is typically located in the %ProgramFiles%\Update
Services\Tools folder. The export process takes from 10 to 20 minutes
to run (potentially more), depending on your hardware. WSUSutil writes
to the log file after the export completes. The file is in XML format.
Copy the export file to the SUP using whatever method is appropriate for your environment.
Open a command prompt on the destination WSUS server and run WSUSutil import:
WSUSutil import <import filename.cab> <import log filename>
The
import process is more extensive than the export process and may take
over an hour to complete, so be patient. As with the export process,
WSUSutil does not write to the XML log file until the import completes.
To
initiate synchronization manually from Microsoft or an upstream server,
navigate to Computer Management in the ConfigMgr console, expand
Software Updates, right-click Update Repository, and choose Run
Synchronization.
Aside from the obvious
manual intervention required, there are two differences between the
manual synchronization and a scheduled one:
A
manual synchronization only performs a delta synchronization, meaning
it only downloads changes to the catalog of available updates.
Scheduled synchronizations download the entire update catalog.
With a scheduled synchronization, superseded updates are only marked as expired when you do a full catalog update.
After
a successful synchronization, WSUS imports the update catalog into the
WSUS database. The WSUS Synchronization Manager (SMS_WSUS_SYNC_MANAGER)
component of ConfigMgr initiates an import of the update catalog from
the WSUS database to the ConfigMgr database. Synchronization of direct
child site SUPs are then initiated and the process continues down the
ConfigMgr hierarchy.
|
As
of this writing, a known but formally undocumented issue exists that
occasionally causes the WSUS website to disappear after a reboot of the
site server. This typically only happens when WSUS is installed on the
central site server and is not limited to a specific version of Windows
or IIS. Uninstalling WSUS, leaving the content and database intact, and
reinstalling WSUS with identical settings restores WSUS to a fully
functioning status. However, this only fixes the symptom and not the
problem, leaving the door open for it to reoccur—and based on forum
input, it will continue to happen.
Although
Microsoft has not issued a formal fix for this problem, an informal
“fix” is located in various forums to prevent the site from being
deleted. Perform the following steps:
1. | Locate
the cached Microsoft Installer (MSI) file for WSUS in the Registry.
This is stored in the value named LocalPackage under the key
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\53E7D0C2E6EE7CD4AB31C286EAED5BD9\InstallProperties.
| 2. | Change
the name of the file specified in the LocalPackage value. For example,
in the SCCMUnleashed lab the file specified is
c:\Windows\Installer\17bb1a3.msi. Simply changing this to
17bb1a3old.msi should prevent the website from being removed in the
future.
|
Note
that this is not an official Microsoft fix, and all the usual
Registry-editing precautions apply. Your mileage may vary (even if you
have inflated your tires properly).
|
4. Agent Configuration
To
configure specific Software Updates settings on client systems, open
the ConfigMgr console and navigate to Site Database -> Site
Management -> <Site Code> <Site Name>
-> Site Settings -> Client Agents. Right-click the Software
Updates Client agent and choose Properties. This opens the Software
Updates Client Agent Properties dialog box, where you can configure the
following settings:
Enable software updates on clients—
The first setting determines whether the agent is actually enabled. If
it is not, the client does not scan for updates and ConfigMgr will not
deploy updates to it. As with other ConfigMgr Client agents, disabling
the agent does not remove it from the client; this simply causes it to
do nothing.
Scan schedule—
This setting determines how often to scan the client system for
available updates. You can use the default schedule or configure a
custom schedule:
The default schedule is
a simple schedule run every 7 days. The advantage of a simple schedule
is it allows update scans to catch up when the system was powered off
or unable to contact an SUP.
A custom
schedule gives you granular control over when to perform update scans.
Scans on a custom schedule may not start for up to 2 hours after the specified
time. The actual wait time for each client after the scheduled time is
random and prevents client activity from overwhelming the SUP.
The scan schedule is completely independent of actual update deployment.
Enforce mandatory deployments—
If you use multiple mandatory deployments, your systems may also be
subject to multiple reboots. Enabling this setting instructs the agent
to install updates from all applicable mandatory updates on a system,
in effect combining the deployments and reducing the number of reboots
to one. The agent combines all deployments with deadlines up to 7 days
in the future by default, although this is customizable, as shown in Figure 7.
Hide deployment from end users—
By default, users receive a balloon notification from the agent
indicating updates are available. Depending on your organization’s
practices and policies, you may not want users to receive automated
notifications. This setting allows you to disable the notification. You
can also individually enable or disable the setting for specific update
deployments.
The balloon notification allows
users to initiate deploying updates at their convenience before a
configured mandatory deadline. Also by default, the agent displays the
notification to users at configured intervals according to Table 2. You can customize the intervals by navigating to the Reminders tab of the Computer Client Agent setting dialog box.
Table 2. Notification Intervals
| Deployment Deadline | Interval |
|---|
| More than 24 hours away | Every 3 hours |
| Less than 24 hours away | Every hour |
| Less than 1 hour away | Every 15 minutes |
Deployment reevaluation—
Update reevaluation scans ensure that old updates previously deployed
to a system are still on that system. If ConfigMgr detects an update
from a previous (but still applicable) deployment is no longer there,
it immediately reinstalls the update. Reinstallation takes place
without regard to maintenance windows and may be disruptive.
5. Group Policy Settings
Using
a group policy object (GPO) is the standard way to configure WSUS and
the WUA. When you’re installing and configuring Software Updates,
typical questions include the following:
You
do not need to create a GPO to support ConfigMgr Software Updates.
However, if you choose to create a GPO to support client installation or use an in-place GPO, you must configure the Windows
Updates server option to point to the active SUP in the site. This is
because ConfigMgr creates a local policy on clients, pointing them to
the SUP. A domain-based GPO overrides the local policy settings,
causing software updates to fail on the client if the GPO does not
specify the SUP as its update server. Additionally, an effective GPO
must not disable the Windows Updates service or the WUA.
To
avoid any possible conflicts, Microsoft recommends not applying GPOs
that enforce Windows Updates settings to ConfigMgr-managed systems. If
you use a GPO to deploy clients via WSUS, you should utilize Windows
Management Instrumentation (WMI) filtering, security group filtering,
or another mechanism to prevent these GPOs from being applied to
managed systems.
Caution: Disabling a Windows Update GPO
Be
careful when removing or disabling a GPO that applies Windows Updates
settings because the local computer’s Windows Updates setting for
downloading and installing updates will take effect. The local settings
may cause updates to immediately download and install, or previously
downloaded updates to install at the time configured in the local
policy. Reboots often accompany update installation; these will be
unexpected and most likely undesirable, particularly if the reboot
occurs on a server. Because you do not actually approve updates in WSUS
when used with ConfigMgr, this is a one-time cutover issue only.
If
you are unsure of the local Windows Updates settings on your managed
systems, you may want to configure a new GPO (or change an existing
one) to notify users of applicable updates only; this will prevent any
automatic installations. Do not use a GPO to disable Windows Updates
because this will interfere with ConfigMgr Software Updates.
