1. SMS 2003 Clients
ConfigMgr
2007 continues to support down-level SMS 2003 clients to varying
degrees; this support includes software update functionality. This
support is critical during a large, in-place upgrade from SMS 2003,
when it may be impossible to transition the entire client base quickly.
This section discusses deploying updates to these SMS 2003 clients; the
information assumes a knowledge and understanding of software updates
in SMS 2003.
The upgrade maintains the following data in the site database:
Software updates metadata— Includes items such as name, description, applicability rules, and article ID
Compliance information— Includes the number of scanned clients for which a software update is required or not required
Client status information— Includes the revision for the Microsoft Update catalog used by clients when scanning for software updates compliance
The
SMS 2003 upgrade process automatically upgrades the actual ITMU scan
tool to a new, ConfigMgr-compatible version. ConfigMgr 2007 does not
support other separately released supplementary scan tools such as the
Inventory Tool for Dell Updates or the February 2005 Security Update
Scan Tool; any data pertaining to these tools is removed from the
database after the upgrade.
SMS 2003 update
advertisements are also migrated during the ConfigMgr upgrade; these
continue to function as expected. The upgrade moves the advertisements
in the console to the SMS2003 Advertisements node, under Site Database
-> Computer Management -> Software Updates -> Deployment
Management.
Because the SMS 2003 Client
agent does not have the same tight integration with the WUA as the
ConfigMgr Client agent, SMS 2003 clients must continue to receive their
update catalog by means of an ITMU-based scan advertisement. Ensure you
are only targeting SMS 2003 clients with this advertisement! Targeting
ConfigMgr clients will produce unexpected results and is unsupported.
Similarly,
you must download the updates catalog from Microsoft using a separate
catalog synchronization advertisement—this process is identical to the
process existing in SMS 2003. All updates migrated from SMS 2003 to
ConfigMgr have (LEGACY) appended to their title until the initial ITMU
catalog synchronization completes. Do not create new deployments using
updates marked with (LEGACY), because these only exist to support
migrated deployments and for reporting.
After
synchronizing the ITMU update catalog and scanning SMS 2003 clients
with the ITMU scan tool, you are once again ready to deploy updates to
those clients. The actual process for deploying updates to SMS 2003
clients is nearly identical to the process outlined previously for
ConfigMgr clients, with a few minor differences or exceptions:
Software repository—
A searchable attribute exists on all updates called Deployable to
SMS2003. As this name implies, the attribute identifies updates that
you can deploy to SMS 2003 clients. Using this attribute, you can build
search folders specific to your SMS 2003 clients.
Deployments and deployments packages—
The loose association of deployments and deployment packages does not
apply to those created for SMS 2003 clients; they roughly revert to the
behavior of ITMU-based update packages and advertisements in SMS 2003.
Each
deployment package used for SMS 2003 clients contains a legacy program,
listed under the SMS2003 Programs subnode of the package, to deploy the
updates in that package. Each of these programs is then advertised to
clients using an advertisement listed under the SMS2003 advertisements
subnode of deployment management.
Because this
pertains to legacy SMS 2003-based clients, the programs are specific
only to the updates in the package that contains the program.
Additionally, the SMS 2003 agent is not intelligent enough to download only the updates that it requires and instead downloads the entire package.
Deployment templates and deployments—
SMS 2003–specific settings exist for both these objects. Choose these
settings while running either the Deployment or the Deployment Template
Creation Wizard, or after creation using the SMS 2003 tab of the
Properties dialog box. The settings include the following:
Collect Hardware Inventory Immediately—
In SMS 2003, software update compliance information is stored locally
on clients in the WMI repository and returned to the site using
hardware inventory. It may be desirable to return this information
immediately to the site database rather than waiting for the next
hardware inventory cycle; this option initiates a new hardware
inventory, which returns the software update compliance information to
the site database immediately after update installation.
Distribution Point Locally Available—
This option allows you to specify downloading updates first from the
local distribution point or directly access them from that DP if it is
locally available.
No Distribution Point Locally Available—
This option allows you to specify to first download updates from a
remote distribution point, or directly access them from a remote
distribution point if a distribution point is not locally available.
You can also specify not to install updates at all if a distribution
point is not available locally.
Once
you eliminate all SMS 2003 clients in your infrastructure, you can
uninstall the ITMU. Until then, the hybrid approach outlined here
offers a seamless and relatively painless path to managing updates for
both types of clients.
2. Native Mode and Software Updates
As
with other site roles, some special configuration is required to
configure an SUP for use with a native mode ConfigMgr site. This
involves configuring the WSUS IIS site to use SSL-secured communication
and telling WSUS itself to use the SSL certificate. Adding this
certificate authenticates the SUP to the clients and secures all
communication between the SUP and the clients. Perform the following
steps:
1. | Begin
by acquiring the SSL certificate from your Public Key Infrastructure
(PKI). You must install this certificate into the Personal certificate
store of the computer account on the SUP; this process is dependent on
your PKI implementation.
The requirements for this certificate are as follows:
The Enhanced Key Usage value must contain Server Authentication (1.3.6.1.5.5.7.3.1). If
the site system accepts connections from the Internet, the Subject Name
or Subject Alternative Name must contain the Internet FQDN of the SUP. If
the site system accepts connections from the intranet, the Subject Name
or Subject Alternative Name must contain either the intranet FQDN
(recommended) or the computer’s NetBIOS name, depending on
configuration of the site system. If the
site system accepts connections from both the Internet and the
intranet, you must specify both the Internet FQDN and the intranet FQDN
(or computer NetBIOS name) using the ampersand (&) symbol delimiter
between the two names.
|
2. | Configure
the WSUS site in IIS to use the certificate. The steps differ between
Windows Server 2008 and Windows Server 2003. For IIS 7.0 on Windows
Server 2008, follow these steps:
- Open the IIS 7 Administration console.
- Expand
Sites and select the website used by WSUS (Default Web Site if you
installed WSUS into the default site, or WSUS Administration if you
used a custom site).
- Select Edit Bindings.
- Configure HTTPS to use the appropriate certificate.
For IIS 6.0 on Windows Server 2003, use the following steps:
1. | Open the IIS 6 Administration console.
| 2. | Edit
the properties of the website used by WSUS (Default Web Site if you
installed WSUS into the default site, or WSUS Administration if you
used a custom site).
| 3. | Click Server Certificate on the Directory Security tab.
| 4. | The Web Server Certificate Wizard launches, prompting you to select the web server certificate to use.
|
|
3. | Next, configure the following WSUS virtual folders to allow only SSL communication:
APIRemoting30 ClientWebService DSSAuthWebService ServerSyncWebService SimpleAuthWebService
You will perform this differently in Windows 2003 and Windows 2008. For
IIS 7.0 on Windows Server 2008, complete these steps in the IIS 7
Administration console:
Expand
Sites and select the website used by WSUS (Default Web Site if you
installed WSUS into the default site, or WSUS Administration if you
used a custom site). For
each of the virtual folders listed previously, double-click SSL
Settings in Features View, select Require SSL on the SSL Settings page,
and then click Apply in the Actions pane. For IIS 6.0 on Windows Server 2003, use the following steps: Edit
the properties of the website used by WSUS (Default Web Site if you
installed WSUS into the default site, or WSUS Administration if you
used a custom site). For each of the
virtual folders listed previously, click the Directory Security tab.
Then click Edit in the Secure Communications section, select Require
secure channel (SSL), and then click OK and click OK again to close the
properties for the virtual root.
|
4. | Finish by configuring WSUS to use SSL. To do this, run a single command from the command prompt:
<WSUS Installation Folder>\Tools\WSUSutil.exe configuressl <subject name in the signing certificate>
In this case, <subject name in the signing certificate> is typically the FQDN of the system hosting WSUS based on the certificate requirements listed previously. |
