SCCM2007_Workbook__2008-12-15

Configuration Manager 2007 WORKBOOK Page 2

Microsoft® System Center Configuration

Manager 2007 Premier Workshop

Configuration Manager 2007 workbook

This is the workbook for Configuration Manager 2007.

Version 1.0


Terms of Use

MICROSOFT PARTNER

For use as described in Partner Agreement and below

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless

otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and

events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail

address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the

responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or

introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording,

or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

For more information see Microsoft Copyright Permissions at

http://www.microsoft.com/permission/

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject

matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this

document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 2003 Microsoft Corporation. All rights reserved.

Active Directory®, Microsoft® Background Intelligent Transfer Service, Microsoft® Baseline Security Analyzer, Microsoft®

Download Center, Microsoft® Exchange Server, Microsoft® Internet Explorer, Microsoft® Internet Explorer 5.5, Microsoft®

Internet Information Server, Microsoft® Internet Information Server 6.0, Microsoft® Management Console, Microsoft®

Notepad, Microsoft® Office, Microsoft® Office Inventory Tool for Updates, Microsoft® Office Update Database, Microsoft®

Office Update Tool, Microsoft® Software Update Services, Microsoft® SQL Server™, Microsoft® SQL Server™ 2000, Microsoft®

Systems Management Server 2.0, Microsoft® Systems Management Server 2003, Microsoft® System Center Configuration

Manager 2007, Microsoft® Virtual Server, Microsoft® Visual Basic®, Microsoft® Visual Basic® Scripting Edition, Microsoft®

Windows NT®, Microsoft® Windows NT® 3.51, Microsoft® Windows NT® 4.0, Microsoft® Windows Server™ 2003,

Microsoft® Windows®, Microsoft® Windows® 2000, Microsoft® Windows® 95, Microsoft® Windows® Installer, Microsoft®

Windows® Internet Name Service, Microsoft® Windows® Management Instrumentation, Microsoft® Windows® XP are either

registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

THIS DOCUMENT IS FOR INFORMATIONAL AND TRAINING PURPOSES ONLY AND IS PROVIDED "AS IS" WITHOUT

WARRANTY OF ANY KIND, WHETHER EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED

WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT.


Table of Contents

Client Deployment for Configuration Manager ........................................................................................ 7

Configuration Manager Clients ............................................................................................................. 7

Planning and Deploying Clients for Configuration Manager 2007 ..................................................... 18

Firewall Settings for Configuration Manager 2007 Clients ................................................................. 47

Client Policy ......................................................................................................................................... 49

Troubleshooting Client Issues ................................................................................................................. 51

Log Files for Managing Clients ............................................................................................................ 52

Overview of Software Update Management .......................................................................................... 58

Overview ................................................................................................................................................. 59

Definitions ........................................................................................................................................... 59

Prerequisites for Software Updates .................................................................................................... 60

Administrator Workflow: Software Updates End to End Workflow ................................................... 62

The Software Updates Process ........................................................................................................... 64

Software Updates Objects .................................................................................................................. 65

The Software Updates Client Agent .................................................................................................... 68

Software Updates Metadata ............................................................................................................... 69

Software Updates Synchronization ..................................................................................................... 73

Compliance for Software Updates ...................................................................................................... 76

Update Lists in Software Updates ....................................................................................................... 78

Deployment Templates in Software Updates ..................................................................................... 80

Deployment Packages in Software Updates ....................................................................................... 83

About Software Update Deployments ................................................................................................ 87

About the Software Updates End User Experience ............................................................................ 91

The Inventory Tool for Microsoft Updates ......................................................................................... 94

Product Documentation...................................................................................................................... 95

System Center Updates Publisher....................................................................................................... 95

Determine the Software Update Point Infrastructure ........................................................................ 96

Planning for the Software Update Point Settings ............................................................................. 100

Planning for Software Updates Client Settings ................................................................................. 112


Planning for Software Updates Server Settings ................................................................................ 118

Determine What Software Updates to Deploy ..................................................................................... 123

Planning for a Software Update Deployment ....................................................................................... 127

Software Update Point Settings ........................................................................................................ 127

Software Update Deployment Settings ............................................................................................ 127

Using Deployment Templates When Creating Deployments ........................................................... 137

Maintenance Windows ..................................................................................................................... 138

Restart Behavior on Client Computers ............................................................................................. 139

Hiding Deployments from End Users ................................................................................................ 139

Software Updates with License Terms .............................................................................................. 140

Delegated Administration ................................................................................................................. 140

General SUM/WSUS Architecture......................................................................................................... 141

System Architecture .......................................................................................................................... 141

Component Architecture .................................................................................................................. 143

Component Design ............................................................................................................................ 145

Registry Settings ................................................................................................................................ 156

Configuration Manager WSUS Managed Service Provider (WSUS MSP) .......................................... 158

WSUS Configuration Manager (WCM) .............................................................................................. 159

WSUS Subscriptions .......................................................................................................................... 164

WSUS Server Locations ..................................................................................................................... 164

Replica Vs Autonomous modes of WSUS Server .............................................................................. 165

Content hashing ................................................................................................................................ 168

Software updates’ assignments ........................................................................................................ 170

Software updates compliance .......................................................................................................... 170

WSUS Sync Manager ......................................................................................................................... 172

Synchronizing updates into Configuration Manager database ........................................................ 175

State messages collection ................................................................................................................. 176

Offline sync tool ................................................................................................................................ 177

Updates Store ................................................................................................................................... 177

Software Update Manager (SUM) .................................................................................................... 182

Policy Provider .................................................................................................................................. 183

Scan Agent in the Configuration Manager Client ............................................................................. 184


System Center Updates Publisher ........................................................................................................ 190

Installation of System Center Updates Publisher ............................................................................. 190

Usage of System Center Updates Publisher...................................................................................... 193

Detection Logic Enabled by the update metadata ........................................................................... 195

High-level schema ............................................................................................................................. 195

System Center Updates Publisher Backup and Restore ................................................................... 220

Software Update Point Settings ........................................................................................................ 225

Software Updates Security Best Practices and Privacy Information ................................................ 238

Troubleshooting SUM ........................................................................................................................... 241

Monitoring Software Updates .......................................................................................................... 241

How to Enable Verbose Logging for the Console .............................................................................. 248


Client Deployment for Configuration Manager

Configuration Manager 2007 Client Deployment

Configuration Manager Clients

Microsoft System Center Configuration Manager 2007 supports many Windows-

based platforms as clients. You must install Configuration Manager 2007 client

software on the clients you want to manage.

Note

Configuration Manager 2007 supports only Windows-based platforms. Support

for non-Windows platforms like Macintosh and Unix platforms might be provided by

other software vendors as add-on products to Configuration Manager.

Types of Clients

You can install Configuration Manager 2007 client software on desktop and laptop

computers, which are typically thought of as "client computers". In addition, you can

install Configuration Manager 2007 client software on server computers and manage

them as clients of Configuration Manager 2007. While servers often have specific

operational requirements, for example the times you are allowed to reboot server

computers might be more limited than desktop computers, Configuration Manager

2007 makes no functional distinction between server or client computers.


Throughout the documentation, the term client computer can mean either a server in

a server room or a computer on a user's desktop.

Client computers typically connect into the organization network directly, either by

being attached directly to the network or by using VPN or dial-up access. In

Configuration Manager 2007, client computers can also be managed by Configuration

Manager 2007 sites if they have a connection to the Internet but never connect

directly to the organization network. For example, a home-based worker could be

managed by Configuration Manager 2007 without ever dialing into the corporate

network. These clients are called Internet-based clients, and they require additional

infrastructure support.

Configuration Manager 2007 also supports installing the client components on mobile

devices, such as devices running Windows Mobile or Windows CE. Mobile device

clients support many but not all of the features supported by standard clients. For

example, you can deploy software to a client cell phone, but you cannot use remote

control to provide troubleshooting assistance to the cell phone user.

Microsoft supports running an embedded version of Windows on devices that are not

traditional desktop, laptop, or server computers. For example, Windows XP

Embedded can be installed on automated teller machines or medical devices.

Configuration Manager 2007 components can be installed by the manufacturer on

these devices along with the embedded operating system. Devices support many but

not all of the features supported by standard clients.

Throughout the documentation, the term client is used to refer to all clients that run

the Configuration Manager 2007 client components, while client computer is used to

refer servers, desktops, and laptops.

Discovering Clients

Configuration Manager 2007 has the ability to discover resources on the network

using several different discovery mechanisms. The following table describes the

available discovery methods.

Table 1. Configuration Manager Discovery Methods

Discovery Method Description

Active Directory System Discovery Retrieves details about the computer, such as computer name, Active Directory container name, IP address, and Active Directory site.


Discovery Method Description

Active Directory System Group Discovery Cannot discover a computer that has not already been discovered by another method. If a resource has been discovered and is assigned to the site, Active Directory System Group Discovery extends other discovery methods by retrieving details such as organizational unit, global groups, universal groups, and nested groups.

Active Directory User Discovery Retrieves information about user accounts created in Active Directory.

Active Directory Security Group Discovery Retrieves security groups created in Active Directory.

Heartbeat Discovery Refresh Configuration Manager client computer discovery data in the site database. Unlike the other methods, this method works only on computers that already have the Configuration Manager 2007 installed.

Network Discovery Searches the network for resources that meet a specific profile. Network discovery can discover resources that are

■ Listed in a router's ARP cache for a specified network subnet

■ Running An SNMP agent and configured for a specified community

■ Configured as Microsoft DHCP clients

Each discovery method creates data discovery records (DDRs) for resources and

sends them to the site database, even if the discovered resource is not capable of

being a Configuration Manager 2007 client. For example, Network Discovery might

discover routers and printers, which could be helpful for tracking purposes, but those

devices will not actually be managed by Configuration Manager 2007. Mobile devices

cannot be discovered until the mobile device client is installed. Computers running

ActiveSync (for Windows XP clients) or Mobile Device Center (for Vista clients) to

synchronize with mobile devices can be discovered and targeted to install the mobile

device client on connected mobile devices.


Note

All resources for which DDRs have been created show up in the Configuration

Manager 2007 console under the following part of the tree: Configuration Manager /

Site Database / Computer Management / Collections / All Systems.

While it is possible to discover resources but never install a single client, usually

discovery is related to locating potential clients either prior to or as part of installing

the client software that makes a computer manageable by Configuration Manager

2007. Active Directory User Discovery and Active Directory Security Group Discovery

allow you to target software distribution packages to users and groups instead of

computers.

Installing the Client Components

Configuration Manager 2007 provides several options for installing the client

software. The following table lists the client computer installation methods.

Table 2. Client Computer Installation Methods

Client Computer Installation Method Description

Software update point installation Uses the Automatic Update configuration of a client to direct the client computer to a WSUS computer configured as a Configuration Manager 2007 software update point. The client computer installs the Configuration Manager 2007 client software as though it was a software update.

Client push installation Uses an account with administrative rights to access the client computers and install the Configuration Manager 2007 client software. This method requires File and Print sharing and the related ports to be enabled on the client computer.

Manual client installation A user with administrative rights can install the client software by running CCMSetup on the client computer. A variety of switches modify the installation options.

Group Policy installation Uses Group Policy software installation to install CCMSetup.msi.


Client Computer Installation Method Description

Imaging The client software can be added to an image, including images created and deployed with Configuration Manager 2007 operating system deployment.

Software Distribution Existing clients can be upgraded or redeployed using Configuration Manager 2007 software distribution.

Mobile devices use different installation methods. A client computer that

synchronizes with a mobile device can be targeted to install the mobile device client

the next time the device is docked. Mobile devices can also install the client software

from a memory card.

Client Assignment

Clients must be assigned to a site before they can be managed by that site. Clients can

be assigned to a site during installation or after installation. Assigning a client

involves either telling it a specific site code to use, or configuring the client to

automatically assign to a site based on boundaries. If the client is not assigned to any

site during the client installation phase, the client installation phase completes, but

the client cannot be managed by Configuration Manager 2007.

Clients cannot be assigned to secondary sites; they are always assigned to the parent

primary site, but can reside in the boundaries of the secondary site, taking advantage

of any proxy management points and Distribution Points at the secondary site. This is

because clients communicate with management points and management points must

communicate with a site database. Secondary sites do not have their own site

database; they use the site database at their parent primary site.

Authenticating Clients

Before Configuration Manager 2007 trusts a client, it requires some manner of

authentication. In mixed mode, clients must be approved, either by manually

approving each client or by automatically approving all clients or all clients in a

trusted Windows domain. In native mode, clients must be issued client authentication

certificates prior to installing the Configuration Manager 2007 client software.

Blocking Clients

If a client computer is no longer trusted, the Configuration Manager administrator can

block the client in the Configuration Manager 2007 console. Blocking applies to both

native mode and mixed mode sites. Blocked clients are ignored by the Configuration

Manager 2007 infrastructure. This is especially useful for laptop computers that are


lost or stolen, to help prevent attackers from using a trusted client to attack the site

or the network.

Client Agents

Client agents are Configuration Manager 2007 components that run on top of the base

client components. If you install only the Configuration Manager Client without

enabling any client agents, Configuration Manager 2007 cannot manage anything

about the client. Every client agent that you enable lets you use a different feature of

Configuration Manager 2007. You can configure the client agents to suit your

environment. The following table describes the client agents in Configuration

Manager 2007.

Table 3. SCCM 2007 Client Agents

Client Agent Description

Computer Client Agent Properties Configures how often client computers retrieve the policy that gives them the rest of their configuration settings. For example, after you configure the other client agent settings, Configuration Manager puts those settings into policy and sends them to the management point and client computers poll for them on the schedule you configure. This agent also controls settings that are common to several Configuration Manager features like how often users are prompted with reminders and what customized organization names users see with the reminders.

Device Client Agent Properties Configures all of the properties specific to mobile device clients. Mobile device clients have settings for software distribution, software inventory, hardware inventory, and file collection. This agent also controls the polling interval used by mobile device clients.

Hardware Inventory Client Agent Enables and configures the agent that collects a wide variety of information about the client computer. Information about the computer hardware is most commonly collected, but you can inventory any information stored in the Windows Management Instrumentation (WMI) repository of the computer, such as registry keys. You can configure how often the client computer takes inventory.


Client Agent Description

Software Inventory Client Agent Enables and configures which files Configuration Manager inventories and collects. Copies of collected files are stored in the Configuration Manager database.

Advertised Programs Client Agent Enables and configures the software distribution feature.

Desired Configuration Management Client Agent Enables the client agent that evaluates whether computers are in compliance with configuration baselines that are assigned to them. You can also configure the default compliance evaluation schedule for assigned configuration baselines.

Remote Tools Client Agent Enables Configuration Manager remote control and configures Configuration Manager integration with Remote Assistance.

Network Access Protection Client Agent Enables Configuration Manager Network Access Protection and configures how client computers are evaluated for compliance by the Windows Network Policy Server. If client computers are not in compliance with the configured policies, for example if they do not have specified software updates, NAP can prevent the client computers from access network resources until they complete remediation measures. Configuring this client agent without proper planning and deployment can prevent your client computers from accessing the network.

Software Metering Client Agent Enables the agent that monitors which software is run and how often and configures how often software metering data is collected.

Software Updates Client Agent Enables the agent that scans for and installs software updates on client computers. This agent allows you to configure how often clients are re-evaluated for software updates that were previously installed. Before you can use the software update feature, you must also install Windows Server Update Services (WSUS) and configure a software update point.


FYI

There is no client agent for Operating System deployment.

Client deployment in Microsoft System Center Configuration Manager 2007

introduces a number of changes and new features designed to improve the ease and

security of client deployment, and to improve the identification of any problems using

standard reports.

Checking for Site Compatibility to Complete Site Assignment

The improved functionality from SMS 2003 means that a Configuration Manager 2007

client will not work if it is assigned to a site running SMS 2003. To prevent this

situation, site assignment in Configuration Manager 2007 now includes a version

check to ensure compatibility between the client and its assigned site.

For site assignment to complete in Configuration Manager 2007, you must either

extend the Active Directory schema for Configuration Manager 2007 or clients must

be able to communicate with a server locator point in the hierarchy. Additionally, if

you have extended Active Directory but have clients from a separate forest, or clients

from workgroups, you will need a server locator point.

Important

If a Configuration Manager 2007 client cannot complete the check for site

compatibility, site assignment will not succeed.

Client Prerequisite Checks

When CCMSetup installs the Configuration Manager 2007 client, it checks the

destination computer for the correct prerequisites required by your Configuration

Manager 2007 site. If these are not found, CCMSetup will install these before

installing the client.

Approval for Clients in Mixed Mode

A new procedure called approval helps to protect the security of a site in mixed mode.

Only clients that are approved will be sent policies that might contain sensitive data.

You should ensure that all client computers that you trust are approved with their

assigned site.

The default site setting for approval in Configuration Manager 2007 is to

automatically approve trusted computers. This means that in most circumstances you


will not have to manually approve many computers, unless they are from a separate

Active Directory forest or a workgroup. However, if your Configuration Manager

2007 spans multiple domains, ensure that the site's default management point (or

NLB management point) is configured with an intranet fully qualified domain name

(FQDN).

Client Blocking

If a client computer is no longer trusted, the Configuration Manager administrator can

block the client from the Configuration Manager infrastructure. Blocked clients are

rejected by Configuration Manager so that they cannot communicate with site

systems to download policy, upload inventory data, or send state or status messages

to the site. This action is especially useful for laptop computers or mobile devices that

are lost or stolen, to help prevent attackers from using a trusted client to attack the

Configuration Manager 2007 site or the network. However, it does not replace the use

of certificate revocation checking if this is supported in a public key infrastructure

(PKI) environment.

Fallback Status Point

The fallback status point is a new site system role in Configuration Manager 2007 that

receives state messages from client computers during the installation process, and if

they cannot connect to a management point. This information is then displayed in

reports to help you more easily identify computers that have failed to install the client

software or that cannot communicate with their site.

The fallback status point is not published to Active Directory Domain Services as a

site setting, so it must be assigned to clients during installation.

Group Policy Based Installation and Assignment

Configuration Manager 2007 supports using Windows Group Policy to install or

assign the client software to computers in your enterprise. You can use this method to

assign new or existing clients to a Configuration Manager 2007 site. An

administrative template to perform site assignment is included on the Configuration

Manager 2007 installation media.

Software Update Point Based Client Installation

Software update point based client installation is a new client deployment method

introduced in Configuration Manager 2007 that allows the administrator to publish

the latest version of the Configuration Manager 2007 client into the WSUS catalog.

This allows the latest client software to be installed using standard software update


deployment methods. One of the advantages of this installation method is that it does

not require local administrative rights on the target computer.

Default Management Point Published to DNS

The most secure method for a client to find its default management is through Active

Directory Domain Services. However, if this is not possible either because Active

Directory is not extended, or because clients are from a separate Active Directory

forest or a workgroup, DNS publishing offers a recommended alternative.

This configuration requires an entry in DNS that is added either automatically or

manually, and configuration on the client.

Uninstalling the Configuration Manager Client Software

The ccmclean.exe utility provided with SMS 2003 Toolkit 2 cannot be used to

uninstall the Configuration Manager 2007 client software. To successfully uninstall

the Configuration Manager 2007 client software you must use the CCMSetup.exe

executable together with the /uninstall property.

Client Network Access Account

The SMS 2003 client network access account is no longer used for client push

installations in Configuration Manager 2007.

Client Installation Properties Published in Active Directory

If you have extended the Active Directory schema for Configuration Manager 2007

and the site is configured to publish to Active Directory Domain Services, a number of

client installation properties are published. These settings can remove the need to

specify CCMSetup command line properties under certain circumstances, such as

when you install the Configuration Manager 2007 client using software update point

based installation or use Group Policy installation.

Provision Client Installation Properties Using Group Policy

You can use Windows Group Policy to provision client installation properties on

computers prior to installing the Configuration Manager 2007 client. When the client

is installed, these properties will be used if no other installation properties have been

specified. An administrative template to provision client computers with installation

properties is included on the Configuration Manager 2007 installation media.


Low Rights Client Installation No Longer Supported

In SMS 2003, users without administrative rights to the computer could manually

install the SMS advanced client. These computers would then submit a CCR to the site

server which would initiate the installation. In Configuration Manager 2007, this

feature is no longer supported. You can install the Configuration Manager 2007 client

on computers logged on with non-administrator rights using the following methods:

■ Client push installation (if a valid client push installation account has been

specified)

■ Software update point based client installation

■ Group Policy installation

CAPINST.EXE is No Longer Supported

Capinst.exe is no longer used in Configuration Manager 2007 for logon script client

installation. For information about how to install Configuration Manager 2007 clients

using a logon script, see How to Install Clients Using Logon Scripts.

Client Installation Files are Downloaded from the Management Point over HTTP

In SMS 2003, client installation files were downloaded from an SMB share on the

management point. In Configuration Manager 2007, the default behavior is to

download these files using a HTTP connection. You can still use an SMB share to

download client installation files, but you must create this share yourself and specify

the CCMSetup installation property /source.

Managing Client Identity

Configuration Manager 2007 manages client identity to help eliminate duplicate

GUIDs. For each client computer, Configuration Manager 2007 calculates a hardware

ID using a proprietary algorithm to help ensure that each client is uniquely identified.

If Configuration Manager 2007 detects a duplicate hardware ID, Configuration

Manager 2007 can automatically create a new client record for the duplicate record.

This setting allows you to easily upgrade or deploy clients that might potentially have

duplicate hardware IDs, without requiring manual intervention. However, with this

setting, if you recover a computer and it maintains the original hardware ID,

Configuration Manager 2007 will create a new record and you lose the historical

continuity for reporting purposes. If you want to manually resolve conflicting records,

you can change the setting on the Site Properties Advanced tab so that conflicting

records will be displayed in the Conflicting Records node. If you enable manual


conflict resolution for all sites in a hierarchy branch, then the administrator at the top

of the branch can manually resolve conflicts for all child sites.

Planning and Deploying Clients for Configuration Manager 2007

Client deployment in Configuration Manager 2007 provides a set of tools and

resources that can help to successfully deploy the Configuration Manager 2007 client

in your organization.

Click any link in the following section for detailed information about planning,

configuring, monitoring, maintaining and troubleshooting client deployment in

Configuration Manager 2007.

Overview of Client Deployment

Client deployment in Configuration Manager 2007 refers to the planning, installation

and management of the Configuration Manager 2007 client software in your

enterprise.

Topics in this section refer to deploying and managing the Configuration Manager

2007 client on computer systems.

The following table lists the various methods that you can use to install the

Configuration Manager 2007 client software:

Table 4. Client Installation Methods

Client Installation Method Description

Client push installation Used to target the client to assigned resources.

Software update point installation Used to install the client using the Configuration Manager 2007 software updates feature.

Group Policy installation Used to install the client using Windows Group Policy.

Logon script installation Used to install the client by means of a logon script.

Manual installation Used to manually install the client software.

Upgrade installation Used to upgrade clients to a newer version.


Client Installation Method Description

Client Imaging Used to pre-stage the client installation in an operating system image.

After the client has installed successfully, it will attempt to assign to a site and find

that site's default Management Point to download policy.

The client's success or failure for these processes can be captured with the fallback

status point if this role has been defined for the site, and the client is assigned to it.

About the Fallback Status Point

A fallback status point in Configuration Manager 2007 is a site system role that is

used to help administrators monitor client deployment and identify any problems

encountered during installation or assignment. It is also used to help identify clients

that are unmanaged because they have problems communicating with their

Management Point, which is particularly relevant for when the site is operating in

native mode.

The fallback status point is an optional but recommended site system role that helps

you manage clients and identify any client-related problems.

Note

SMS 2003 client computers cannot use a fallback status point.

The fallback status point receives state messages from Configuration Manager 2007

client computers and then relays these back to the site. The state message system

allows client computers to send short messages to the fallback status point or to the

Management Point that indicate changes of state, for instance, success or failure.

These changes of state are then made available to the administrator through a

number of Configuration Manager 2007 reports.

Note

There is no equivalent of the status message viewer for state messages.

If you decide to use a fallback status point, install and configure this site system role

before you deploy clients. This allows you to assign the fallback status point when the

client is installed. Although you can install more than one fallback status point for a

Configuration Manager 2007 site, client computers can be assigned to only one

fallback status point.


Information about the Fallback Status Point is stored in the registry at

HKLM\Software\Microsoft\CCM\FSP. During setup, a new registry key is created

under CCM\FSP. The values persisted under this key are:

1. The NetBIOS name of the FSP

2. The FQDN of the FSP

Using the Fallback Status Point for Client Deployment

Examples of state messages a client might send to a fallback status point if it

encountered problems during client deployment include the following:

■ The client failed to install properly (for example, because of incorrect setup

options or syntax errors, or because it failed to locate the required files).

■ The client failed to be assigned to a site.

■ The client failed to register with its assigned site.

■ The client failed to locate its Management Point.

■ There was a network connectivity problem between the client and the

Management Point.

■ The Management Point is not configured correctly (for example, Internet

Information Services (IIS) is not configured correctly for a Configuration Manager

Management Point).

In addition to sending state messages when there is a problem during client deployment, the client will

send a state message to the fallback status point when it is successfully installed and when it is

successfully assigned to a Configuration Manager 2007 site. In this scenario, the client will also report if

a restart is required to complete the installation.

About Client Approval

Configuration Manager 2007 mixed mode does not authenticate clients before they

are allowed to join the site. Any computer with the System Center Configuration

Manager 2007 client and a self-signed certificate can communicate with a

Management Point, display in the System Center Configuration Manager 2007

console, receive policy from the site, and send information to the site. In mixed mode,

if the check box This site contains only ConfigMgr 2007 clients is not selected, then

policies containing sensitive data can be sent to any client. However if the check box

is selected, only clients that are approved can receive policies containing sensitive

data.


Approval can be manual, automatic for computers in trusted domains, or automatic

for all computers and is configured as a site property on the site mode tab for mixed

mode sites.

The most secure approval method is to automatically approve clients that are

members of trusted domains. In this mode, clients that are not members of a trusted

domain, including workgroup clients, must be manually approved. If you want to

manually verify every client before it is allowed to receive policies containing

sensitive data, set the approval mode to manual. Automatically approving all clients is

not recommended unless you have other access controls to prevent untrustworthy

computers from accessing your network. If a client is not approved by an automatic

method, it still displays in the Configuration Manager 2007 console and can be

manually approved by locating it in a collection and using Approve from the Action

menu.

Mobile device clients do not receive any policies containing sensitive data and

therefore do not require approval.

Approval is also not required when the site is configured for native mode, because

public key infrastructure (PKI) certificates authenticate clients to the Management

Point and other site systems.

Note

When a Configuration Manager 2007 site is in native mode, client approval is not

used. However, if you view a collection in the Configuration Manager console, the

approval column is displayed. For native mode sites, the information in this column

should not be used.

The following table lists the three approval options that are available as a mixed

mode site option.

Table 5. Mixed Mode Site Approval Options

Approval Setting More Information

Manually approve each computer Manually approving every computer to join the site introduces the least risk, but the largest administrative overhead. Clients must be manually approved from within the Configuration Manager console. You can approve clients from either their assigned Configuration Manager 2007 site or from a parent site.


Approval Setting More Information

Automatically approve computers in trusted domains

Automatically approving computers in trusted domains automatically approves client computers joined to domains trusted by the site server's domain. When using this setting, you should ensure that you have other security controls in place to prevent untrustworthy computers from joining a trusted domain. IMPORTANT: If clients are from a different domain from the site server's domain, you must configure the site's default Management Point (or NLB Management Point) with a fully qualified domain name (FQDN) to use this option.

Automatically approve all computers Automatically approving all computers to join the site will allow any computer to join the site. This setting is never recommended because it allows any computer to become a client without verifying trustworthiness.

Resetting the Client's Approval Status on Site Migration to Native Mode

When a Configuration Manager 2007 site is migrated from mixed mode to native

mode, clients do not retain their approval status and the approval status of all clients

assigned to the site is automatically set to unapproved.

When the site is operating in native mode, client authentication using the PKI

certificates takes the place of approval, and the approval status is not used. However,

if the site reverts to mixed mode, clients must be re-approved as if they are new

clients.

Client Assignment

Before a Configuration Manager 2007 client can be managed, it must belong to a

Configuration Manager 2007 primary site. The site that a client computer belongs to

is referred to as its assigned site.

Configuration Manager 2007 clients cannot be assigned to secondary sites; they are

always assigned to the parent primary site. However, if they reside in the boundaries

of the secondary site, they can take advantage of any proxy Management Points and

distribution points at the secondary site.

The assignment process happens after the client is successfully installed, and

determines which site manages the client computer. However, it is possible to install

a client and not immediately assign it to a site, but in this scenario it is considered an

unmanaged client until site assignment is successful.


You can either directly assign a client to a site, or use auto-site assignment.

After the client is assigned to a site, it remains assigned to that site even if it roams to

another site. Only an administrator can later manually assign the client to another site

or remove the client assignment.

If the client fails to assign to a site, the client software remains installed, but will be

unmanaged.

Note

A client is considered unmanaged when it is installed but not assigned to a site, or

is assigned to a site but cannot communicate with that site's default Management

Point.

How Manual Site Assignment Works

Clients can be manually assigned to a site using the following two methods:

■ A client installation property which specifies the site code.

■ Specifying the site code in Configuration Manager in the computer's Control

Panel.

Note

If you manually assign a client computer to a Configuration Manager 2007 site

code that does not exist, site assignment will fail. The client will remain installed but

unmanaged until it is assigned to a valid Configuration Manager 2007 site.

How Auto-Site Assignment Works

During client deployment, clients that are configured to use auto-site assignment

compare their own IP address with the site boundaries configured in the

Configuration Manager 2007 hierarchy. When the client IP address falls within the

boundaries of a site, the client is automatically assigned to that site.

Boundaries are configured for one or more of the following:

■ IP subnet

■ Active Directory site

■ IP v6 prefix

■ IP address range


Note

If a Configuration Manager 2007 client has multiple network cards (possibly a

LAN network card and a dial-up modem), and therefore has multiple IP addresses, the

network card that is bound first is used for evaluating client site assignment.

Configuration Manager 2007 clients that use auto-assignment attempt to find site

boundaries published to Active Directory Domain Services. If this method fails (for

example, the Active Directory schema is not extended for Configuration Manager

2007, or clients are not within the same forest), clients can find boundary information

from a Server Locator Point.

The Server Locator Point can be directly assigned to the client during installation, or

the client can attempt to locate it using WINS.

If the client cannot find a site configured with boundaries that match its own IP

address, the client will retry every 10 minutes until it is able to assign to a site.

Configuration Manager 2007 clients can be automatically assigned to a site only if

they are not currently assigned to a site, and if they are not currently on the Internet.

Completing Site Assignment by Checking Site Compatibility

After a client has found its assigned site, the client version and its site mode is

checked to ensure compatibility with the site. The site compatibility check prevents

the incorrect assignment of a Configuration Manager 2007 client to an SMS 2003 site,

and the incorrect assignment of a Configuration Manager 2007 native mode client to a

mixed mode site. When this check completes successfully, site assignment is

successful.

The site compatibility check requires one of the following conditions:

■ The client can access site information published in Active Directory Domain

Services.

■ The client can access a Server Locator Point.

If the site compatibility check fails to complete successfully, site assignment will fail

and the client will remain unmanaged until the site compatibility check is successful.

Locating the Default Management Point

After a client is successfully assigned to a site, it must then locate that site's default

Management Point so that it can download policy. When this completes, the client is

then a managed client.


Client States

When you view Configuration Manager 2007 collections in the Configuration

Manager console, there are a number of columns that indicate the current state of the

client.

Table 6. Client States

Client State More Information

Approved If the Configuration Manager 2007 site is in mixed mode, displays the approval status of clients.

Assigned Indicates whether the client computer is being managed by a Configuration Manager 2007 site.

Blocked Indicates whether the client computer has been blocked from communicating with the Configuration Manager 2007 site.

Client Indicates whether the client computer has a Configuration Manager 2007 client installed.

Obsolete Indicates whether this client record is obsolete. A record that is marked obsolete typically was superseded by a newer record for the same client. The newer record becomes the client's current record, and the older record becomes obsolete.

Active If a client computer is marked as obsolete, this state is set to No.

Decommissioned When a Configuration Manager 2007 client is removed from a child site, its record is not automatically deleted from the parent site. However, a new DDR is sent to the parent site and the client becomes marked as decommissioned. You can then use Configuration Manager 2007 queries or collections to identify decommissioned client computers. NOTE: This state is not shown by default in the Configuration Manager console Collections view. To view this column. Click View and then Add/Remove columns in the actions pane.

Client Roaming

Roaming in Configuration Manager 2007 allows a Configuration Manager 2007 client

to make the best use of network resources when it moves from one intranet location

to another in the organization.

When the client is no longer within the designated boundaries of its assigned site,

roaming behavior allows Configuration Manager 2007 clients to find the closest

distribution points from which to download package source files required for

software distribution, software updates, or operating system deployment.


Roaming behavior helps reduce the need for clients to download content over slow or

unreliable network connections so that clients receive the content as efficiently as

possible, and network bandwidth usage is minimized.

Roaming is ideally suited to laptop computers that move from one network segment

to another. Some examples of client roaming are the following:

■ Moving a laptop computer from building to building.

■ Moving a laptop computer from one geographical location to another.

■ Moving a laptop computer from its wired network connection and connecting to

the network using a wireless network card.

■ Removing a laptop computer from the office and connecting it to a virtual private

network (VPN) from home.

Configuration Manager 2007 site boundaries are used to identify a roaming client's

position in the Configuration Manager 2007 hierarchy, which in turn allows them to

find the closest distribution points. When a change in network location results in a

client being outside its assigned site's boundaries, it relies on roaming behavior to

locate package source files.

The Different Types of Roaming: Global and Regional

When a client roams to another site in the Configuration Manager 2007 hierarchy, the

roaming behavior depends on whether the client is globally roaming or regionally

roaming.

Global roaming offers full roaming support so that a client can download content

locally from any site in the Configuration Manager 2007 hierarchy. However, it

requires that Active Directory Domain Services is extended for Configuration

Manager 2007 and that clients can access Configuration Manager site information

published to Active Directory Domain Services. This is not possible for clients from

another forest, workgroup clients, or mobile devices.

Regional roaming offers limited roaming support so that clients can download

content locally from sites lower than its assigned site in the Configuration Manager

2007 hierarchy.

Global Roaming

When the Active Directory schema has been extended for Configuration Manager

2007 and all sites in the hierarchy are published to Active Directory Domain Services,

roaming clients from the same forest first identify the site into which they have

roamed. They do this by comparing their current IP address with the list of IP


networks that define the site boundaries in the Configuration Manager 2007

hierarchy.

With the site identified, clients then locate that site's default Management Point. The

default Management Point for the site that the client has roamed into is referred to as

the resident Management Point.

The resident Management Point informs the roaming client of distribution points in

its site that contain package source files the client can access. However, if the package

source files are not available in the site the client has roamed into, the client falls back

to asking its default Management Point for distribution points.

Regional Roaming

When clients cannot access Configuration Manager 2007 site information published

to Active Directory Domain Services, clients continue to contact their default

Management Point. They are not aware of the site's identity that they have roamed

into, or of that site's Management Point.

In this scenario, when clients roam into a site that is lower in the hierarchy than their

assigned site (for example, a child site or a grandchild site), the client's default

Management Point informs the roaming client of the closest distribution points the

client can access.

How Roaming Clients Locate Content

When a roaming client needs to access content such as an advertised program's

package source files, it sends a package source location request to the resident

Management Point if globally roaming, or to its default Management Point if

regionally roaming.

The Management Point determines which distribution points contain the content

requested and are available to the client. It makes this determination by checking

whether the distribution points are in a fast or slow network boundary associated

with the boundary the client computer is in, and if the client is located within the

boundaries of a protected distribution point.

When Content is Locally Available to Roaming Clients

If content is available from distribution points in the site the client has roamed into,

the client downloads the content from them.

If the client disconnects before the content has completed its download, and roams

into another site or returns to its assigned site, a content download using BITS

(download and then run) will continue where it left off even though it is from a

different distribution point.


When Content is Not Locally Available to Roaming Clients

If the content isn't available locally in the site the client has roamed into, the

advertisement or software update deployment configuration settings determine if the

roaming client can access it from a remote site.

If the advertisement or software update deployment is configured to prevent

installation when a client is connected using a slow or unreliable network connection,

and the client is currently located on a slow or unreliable site boundary, the client

cannot access the package source files.

To prevent clients from accessing package source files across slow or unreliable

network links, configure the following settings:

■ For an advertisement: When no distribution point is available locally: Do not run

program on the Advertisement Name Properties: Distribution Points Tab.

■ For a software update deployment: When no distribution point is available

locally: Do not install software updates on the Deployment Name Properties:

Download Settings Tab and Deployment Name Properties: SMS 2003 Settings

Tab.

In this scenario, the client cannot download the content until it returns to its assigned

site or it roams into another site that hosts the content on local distribution points.

This configuration protects the network from network saturation associated with

large packages such as operating system deployment packages and software updates

that contain service packs.

However, if the advertisement or software update deployment is not configured with

this option, the client downloads the content from distribution points, even if the

content is not local to them. This ensures that the client gets the content it needs,

even if it takes a long time to transfer over a slow network and might consume a high

proportion of the limited network bandwidth.

Roaming Exceptions

When the Configuration Manager 2007 hierarchy contains some sites in native mode,

and some sites in mixed mode, this affects roaming behavior.

Client Installation Properties

Use the Configuration Manager 2007 CCMSetup.exe command to manually install the

Configuration Manager 2007 client software onto computers in your enterprise.

CCMSetup downloads all the necessary files to complete the client installation from a

specified Management Point or from a specified source location. These files might

include the following:


■ The executable client.msi that installs the Configuration Manager 2007 client

software.

■ Background Intelligent Transfer Service (BITS) installation files (if required).

■ Windows Installer installation files (if required).

■ Patches and fixes for the Configuration Manager 2007 client (if required).

Note

In Configuration Manager 2007, you cannot run client.msi directly.

CCMSetup.exe provides several command line properties to customize the installation

behavior. Additionally, you can also specify properties to modify the behavior of

client.msi from the CCMSetup.exe command line.

Important

You must specify all required CCMSetup properties before you specify properties

for client.msi.

CCMSetup.exe and its supporting files are located on the Configuration Manager 2007

site server in the SMS\Client folder.

The format of the CCMSetup.exe command line is as follows:

CCMSetup.exe [ccmsetup properties] [client.msi setup properties]

For example, the following command line performs the following actions:

CCMSetup.exe /mp:SMSMP01 /logon SMSSITECODE=S01 FSP=SMSFSP01

■ Specifies to download installation files from the Management Point named

SMSMP01

■ Specifies that installation should stop if a version of the Configuration Manager

2007 or SMS 2003 client already exists on the computer.

■ Instructs client.msi to assign the client to the site code S01

■ Instructs client.msi to use the fallback status point named SMSFP01

Note

If a property contains spaces, surround it by quotation marks ("").


The following properties are available to modify the installation behavior of

CCMSetup.exe.

Important

If you have extended the Active Directory schema for Configuration Manager

2007, many client installation properties are published in Active directory and read

automatically by the Configuration Manager 2007 client. For a list of the client

installation properties published in Active Directory, see About Client Installation

Properties Published in Active Directory.

Table 7. CCMSetup.exe Command Line Properties

Property More Information

/? Opens the CCMSetup dialog box showing command line properties for ccmsetup.exe. Example: CCMSetup.exe /?

/source:<Path> Specify the location from which to download installation files. You can use a local or UNC installation path. NOTE: You can use the /source property multiple times on the command line to specify alternative locations from which to download installation files. IMPORTANT: To use the /source switch, the Windows user account being used for client installation must have read permissions to the install location. Example: CCMSetup.exe /source:"\\computer\folder"

/mp:<Computer> Specify the source Management Point for downloading installation files. Files are downloaded over a http connection. NOTE: You can use the /mp property multiple times on the command line to specify alternative locations from which to download installation files. IMPORTANT: This property is only used to specify the Management Point from which to download installation files. It does not specify the Management Point that the client will become assigned to after installation. Example: CCMSetup.exe /mp:SMSMP01

/retry:<Minutes> Specify the retry interval if CCMSetup.exe fails to download installation files. The default value is 10 minutes. CCMSetup will continue to retry until it reaches the limit specified in the downloadtimeout installation property. Example: CCMSetup.exe /retry:20



/noservice Prevents CCMSetup from running as a service which might have insufficient rights to access network resources. If this property is not specified, /service will be used by default. Example: CCMSetup.exe /noservice

/service Specifies that CCMSetup should run as a service using the local system account. Example: CCMSetup.exe /service

/uninstall Specify that the Configuration Manager 2007 client software should be uninstalled. Example: CCMSetup.exe /uninstall

/logon Specify that the client installation should stop if any version of the Configuration Manager 2007 or SMS client is already installed. Example: CCMSetup.exe /logon

/forcereboot Specify that CCMSetup should force the client computer to restart if this is necessary to complete the client installation. If this option is not specified, CCMSetup will exit when a restart is necessary and then continue after the next manual restart. Example: CCMSetup.exe /forcereboot

/BITSPriority:<Priority> Specify the download priority when client installation files are downloaded over an http connection. Possible values are:

■ FOREGROUND

■ HIGH

■ NORMAL

■ LOW

The default value is NORMAL. Example: CCMSetup.exe /BITSPriority:HIGH

/downloadtimeout:<Minutes> Specify the length of time in minutes that CCMSetup will attempt to download the client installation files before it gives up. The default value is 1440 minutes (1 day). Example: CCMSetup.exe /downloadtimeout:100



/native: [<native mode option>] Specifies native mode client communication. NOTE: You must specify this property if you are installing a client for Internet-only communication. The following optional properties can be specified:

■ CRL Certificate revocation list (CRL) checking enabled

■ FALLBACK HTTP communication for roaming and site assignment

■ CRLANDFALLBACK Certificate revocation list (CRL) checking, and HTTP communication for roaming and site assignment

Examples:

CCMSetup.exe /native CCMSetup.exe /native:CRLANDFALLBACK

/config:<configuration file> Specifies the name of a text file containing client installation properties. Example: CCMSetup.exe /config:<Configuration File Name.txt>

Table 8. Client.MSI Properties


CCMALWAYSINF Set to 1 to specify that the client will always be Internet-based and will never connect to the intranet. The client's Connection type will display Always Internet. This property should be used in conjunction with CCMHOSTNAME which specifies the FQDN of the Internet-based Management Point. Example: CCMSetup.exe CCMALWAYSINF=1



CCMCERTSEL Specifies the certificate selection criteria if the client has more than one certificate that can be used for native mode communication (a valid certificate that includes client authentication capability). You can search for an exact match in the Subject Name or Subject Alternative Name (use Subject:) or a partial match (use SubjectStr:), in the Subject Name or Subject Alternative Name. Examples: CCMCERTSEL="Subject:computer1.contoso.com" searches for a certificate with an exact match to the computer name "computer1.contoso.com" in either the Subject Name, or the Subject Alternative Name. CCMCERTSEL="SubjectStr:contoso.com" searches for a certificate that contains "contoso.com" in either the Subject Name, or the Subject Alternative Name. You can also use Object Identifier (OID) or distinguished name attributes in the Subject Name or Subject Alternative Name attributes, for example: CCMCERTSEL="SubjectAttr:2.5.4.11 = Computers" searches for the organizational unit attribute expressed as an OID, and named Computers. CCMCERTSEL="SubjectAttr:OU = Computers" searches for the organizational unit attribute expressed as a distinguished name, and named Computers. IMPORTANT: If you use the Subject Name field, the matching process for the Subject: selection criteria value is case sensitive and the matching process for the SubjectStr: selection criteria value is case insensitive. If you use the Subject Alternative Name field, the matching process for both the Subject: selection criteria value and the SubjectStr: selection criteria value is case insensitive. If more than one certificate matches the search and the property CCMFIRSTCERT has been set to 1, a certificate from the search results is randomly selected. If CCMFIRSTCERT has not been set and the client has more than one certificate that can be used for native mode communication, the client sends a failure message to its assigned fallback status point.

CCMCERTSTORE Specifies an alternate certificate store name if the client certificate to be used for native mode communication is not located in the default certificate store of Personal in the Computer store. Example: CCMSetup.exe CCMCERTSTORE="ConfigMgr"

CCMFIRSTCERT If set to 1, this property specifies that the client should select any valid and matching certificate for native mode communication if multiple valid certificates are found in the certificate store. Example: CCMSetup.exe CCMFIRSTCERT=1



CCMHOSTNAME Specifies the FQDN of the Internet-based Management Point, if the client is managed over the Internet. Example: CCMSetup.exe CCMHOSTNAME="SMSMP01.corp.contoso.com"

CCMHTTPPORT Specifies the port the client should use when communicating over HTTP to site system servers. If this is not specified then the default value of 80 will be used. Example: CCMSetup.exe CCMHTTPPORT=80

CCMHTTPSPORT Specifies the port the client should use when communicating over HTTPS to site system servers. Example: CCMSetup.exe CCMHTTPSORT=443

SMSPUBLICROOTKEY Specifies the trusted root key where this cannot be retrieved from Active Directory. Example: CCMSetup.exe SMSPUBLICROOTKEY=<key>

SMSSIGNCERT Specifies the full path and .cer filename of the exported site server signing certificate for native mode clients. Example: CCMSetup.exe SMSSIGNCERT=<Full path and filename>

SMSROOTKEYPATH Used to reinstall the trusted root key. Specify the full path and filename to a file containing the trusted root key. Example: CCMSetup.exe SMSROOTKEYPATH=<Full path and filename>

RESETKEYINFORMATION If a Configuration Manager 2007 client has the wrong trusted root key and cannot contact a trusted Management Point to receive a valid copy of the new trusted root key, you must manually remove the old trusted root key by using this property. This situation commonly occurs when you move a client from one site hierarchy to another. Example: CCMSetup.exe RESETKEYINFORMATION=TRUE

CCMDEBUGLOGGING Enables debug logging. Values can be set to 0 (off) or 1 (on). The default value is 0. This causes the client to log low-level information that might be useful for troubleshooting problems. As a best practice, avoid using this property in production sites because excessive logging can occur which might make it difficult to find relevant information in the log files. CCMENABLELOGGING must be set to TRUE to enable debug logging. Example: CCMSetup.exe CCMDEBUGLOGGING=1



CCMENABLELOGGING Enables logging if this property is set to TRUE. By default, logging is enabled. The log files are stored in the Logs folder in the Configuration Manager Client installation folder. By default, this folder is %Windir%\System32\CCM\Logs. Example: Ccmsetup.exe CCMENABLELOGGING=TRUE

CCMLOGLEVEL Specifies the amount of detail to write to Configuration Manager 2007 log files. Specify an integer ranging from 0 to 3, where 0 is the most verbose logging, and 3 logs only errors. The default is 1. Example: CCMSetup.exe CCMLOGLEVEL=3

CCMLOGMAXHISTORY When a Configuration Manager 2007 log file reaches 250,000 bytes in size (or the value specified by the property CCMMAXLOGSIZE), it is renamed as a backup, and a new log file is created. This property specifies how many previous versions of the log file to retain. The default value is 1. If the value is set to 0 then no old log files are kept. Example: CCMSetup.exe CCMLOGMAXHISTORY=0

CCMLOGMAXSIZE Specifies the maximum log file size in bytes. When a log grows to the size that is specified, it is renamed as a history file, and a new file is created. This property must be set to at least 10000 bytes. The default value is 250000 bytes. Example: Ccmsetup.exe CCMLOGMAXSIZE=300000

CCMALLOWSILENTREBOOT If this property is set to 1, the computer will be allowed to restart following the client installation if this is required. IMPORTANT: The computer will restart without warning even if a user is currently logged on. Example: CCMSetup.exe CCMALLOWSILENTREBOOT=1

DISABLESITEOPT If set to TRUE, disables the ability of end users with administrative credentials on the client computer to change the Configuration Manager Client assigned site using Configuration Manager from the client computer's Control Panel. Example: CCMSetup.exe DISABLESITEOPT=TRUE

DISABLECACHEOPT If set to TRUE, disables the ability of end users with administrative credentials on the client computer to change the temporary program download folder settings for the Configuration Manager Client by using Configuration Manager from the client computer's Control Panel. Example: CCMSetup.exe DISABLECACHEOPT=TRUE



SMSCACHEDIR Specifies the location of the temporary program download folder on the client computer. By default, the location is %windir%\System32\CCM\Cache. Example: CCMSetup.exe SMSCACHEDIR="C:\Temp" This property can be used in conjunction with the SMSCACHEFLAGS property to further control the temporary program download folder location. Example: CCMSetup.exe SMSCACHEDIR=Cache SMSCACHEFLAGS=MAXDRIVE installs the temporary program download folder on the largest available disk drive on the client.



SMSCACHEFLAGS Configures the Configuration Manager 2007 temporary program download folder. You can use SMSCACHEFLAGS properties individually or in combination, separated by semicolons. If this property is not specified, the temporary program download folder is installed according to the SMSCACHEDIR property, the folder is not compressed, and the SMSCACHESIZE value is used as the size in MB of the folder. Specifies further installation details for the client temporary program download folder. The following properties can be specified.

■ PERCENTDISKSPACE: Specifies the folder size a percentage of the total disk space. If you specify this property, you must also specify the property SMSCACHESIZE as the percentage value to use.

■ PERCENTFREEDISKSPACE: Specifies the folder size as a percentage of the free disk space. If you specify this property, you must also specify the property SMSCACHESIZE as the percentage value to use. For example, if the disk has 10MB free and SMSCACHESIZE is specified as 50, then the folder size is set to 5MB. You cannot use this property with the PERCENTDISKSPACE property.

■ MAXDRIVE: Specifies that the folder should be installed on the largest available disk. This value will be ignored if a path has been specified with the SMSCACHEDIR property.

■ MAXDRIVESPACE: Specifies that the folder should be installed on the disk drive which has the most free space. This value will be ignored if a path has been specified with the SMSCACHEDIR property.

■ NTFSONLY: Specifies that the folder can only be installed on disk drives formatted with the NTFS file system. This value will be ignored if a path has been specified with the SMSCACHEDIR property.

■ COMPRESS: Specifies that the folder should be held in a compressed form.

■ FAILIFNOSPACE: Specifies that the client software should be removed if there is insufficient space to install the folder.

NOTE: Multiple properties for this property can be specified by separating each with a semicolon. If this property is not specified, the temporary program download folder will be created according to the SMSCACHEDIR property, will not be compressed and will be the size specified in the SMSCACHESIZE property.

Example: CCMSetup.exe SMSCACHEFLAGS=NTFSONLY;COMPRESS



SMSCACHESIZE Specifies the size of the temporary program download folder in MB or as a percentage. If this property is not set, the folder defaults to a maximum size of 250 MB. If a new package that must be downloaded would cause the folder to exceed the maximum size, and the folder cannot be purged to make sufficient space available, then the package download fails and the advertised program does not run. Specifies the size of the temporary program download folder in MB or as a percentage when used with the PERCENTDISKSPACE or PERCENTFREEDISKSPACE properties. If this property is not set then the folder defaults to a maximum size of 5,120 MB. NOTE: If a new package that must be downloaded would cause the folder to exceed the maximum size, and the folder cannot be purged to make sufficient space available, then the package download fails and the advertised program will not run. This setting is ignored when upgrading an existing client. Example: CCMSetup.exe SMSCACHESIZE=100

SMSCONFIGSOURCE Specifies the location and order that the Configuration Manager Client Installer checks for configuration settings. The property is a string containing one or more characters, each defining a specific configuration source. Use the character values R, P, M, and U, alone or in combination, as shown in the examples below.

■ R: Check for configuration settings in the registry.

■ P: Check for configuration settings in the installation properties provided on the command line.

■ M: Check for existing settings when upgrading an older client with the Configuration Manager 2007 client software.

■ U: Upgrade the SMS 2003 advanced client or upgrade the Configuration Manager 2007 client to a newer version (using the assigned site code).

By default, the client installation uses PU to check first the installation properties and then the existing settings. Example: CCMSetup.exe SMSCONFIGSOURCE=RP



SMSDIRECTORYLOOKUP Specifies how the client uses WINS for service location. Service location using WINS in mixed mode includes the Management Point and Server Locator Point. Service location using WINS in native mode includes the Server Locator Point only. If WINS is not used by clients to find a Server Locator Point, it must be directly assigned to clients, for example using the SMSSLP Client.msi property. This property has no impact on whether the client uses WINS for name resolution. You can configure how WINS is used for service location using one of the following three modes:

■ NOWINS: This is the most secure method. In this mode, WINS is not used for service location and clients must have an alternative method of locating Management Points and a Server Locator Point (if required).

■ WINSSECURE: In this mode, the mixed mode client can use WINS for service location but verifies the Management Point's mixed mode certificate before communicating with it. To verify the certificate, the client checks its copy of the mixed mode trusted root key in WMI. If the signature on the Management Point certificate matches the client’s copy of the trusted root key, the certificate is validated, and the client communicates with the Management Point found through WINS. If the signature on the Management Point certificate does not match the client’s copy of the trusted root key, the certificate is not valid and the client will not communicate with the Management Point located with WINS.

■ WINSPROMISCUOUS: In this mode, the mixed mode client can use WINS for service location but does not verify the Management Point's mixed mode certificate before communicating with it. This mode is not secure and is not recommended.

If this property is not specified, the default value of WINSSECURE will be used. Example: CCMSetup.exe SMSDIRECTORYLOOKUP=NOWINS



SMSMP Assign the Configuration Manager 2007 client to the specified Management Point. You can specify a fully qualified domain name as this property. Example: CCMSetup.exe SMSMP=SMSMP01

SMSSITECODE Specifies the Configuration Manager 2007 site to assign the Configuration Manager Client to. This can either be a three-character Configuration Manager 2007 site code or the word AUTO. If AUTO is specified, the Configuration Manager Client attempts to determine its Configuration Manager 2007 site assignment by using Active Directory or a Server Locator Point. NOTE: Do not use AUTO if the client will find its default Management Point using DNS. In this scenario, you must directly assign the client to its site. Example: CCMSetup.exe SMSSITECODE=AUTO

SMSSLP Specifies the Server Locator Point for site assignment and locating Management Points for clients that cannot locate this information from Active Directory Domain Services, DNS, or WINS. Example: CCMSetup.exe SMSSLP=SMSSLP01

CCMINSTALLDIR Identifies the folder where the Configuration Manager Client files are installed. If this property is not set, then the client software is installed in the %Windir%\System32\CCM folder. Regardless of where the Configuration Manager Client files are installed, the Ccmcore.dll file is always installed in the %Windir%\System32 folder. Example: CCMSetup.exe CCMINSTALLDIR="C:\Temp"

CCMADMINS Specifies one or more Windows user accounts or groups to be given access to client settings and policies. This is useful where the Configuration Manager 2007 administrator does not have local administrator privileges on the client computer. You can specify a list of accounts separated by semi-colons. Example: CCMSetup.exe CCMADMINS="Domain\Account1;Domain\Group1"

FSP Specifies the fallback status point that will receive and process state messages sent by Configuration Manager 2007 client computers. Example: CCMSetup.exe FSP=SMSFP01



DNSSUFFIX Specifies the DNS domain to use for locating the default Management Point in DNS, when DNS publishing is used. If this property is specified, SMSSITECODE must not be set to AUTO. When this property is specified, client assignment will look for a DNS service location resource record (SRV RR) in DNS, which includes this DNS suffix of the Management Point. NOTE: DNS publishing is not enabled by default in Configuration Manager 2007. Example: CCMSetup.exe SMSSITECODE=ABC DNSSUFFIX=contoso.com

Client Installation Properties Published in Active Directory

If you have extended the Active Directory schema for your Configuration Manager

2007 site, then a number of client installation settings will be published to Active

Directory Domain Services. When a new Configuration Manager 2007 client is

installed, it can then search Active Directory Domain Services to find standard

installation properties to use.

Advantages of using Active Directory to store client installation properties include the

following:

■ Software update point client installation and Group Policy based client

installations do not require setup parameters to be provisioned on each

computer.

■ Because this information is automatically generated, the risk of human error

associated with manually entering installation properties is eliminated.

Client installation properties stored in Active Directory Domain Services are used

only if no other setup properties are specified with any of the following methods:

■ Manual installation

■ Provisioning client installation properties using Windows Group Policy

The following table lists Configuration Manager 2007 client installation methods and

the circumstances in which they will use Active Directory to obtain installation

properties:


Table 9. Client Installation Methods

Installation Method Comments

Client push installation Client installation properties are specified in the Client tab of the Client Push Installation Properties dialog box. Configuration settings are stored in a file which is read by the client during installation. Client push installation does not use Active Directory to obtain installation properties. Client push installation properties specified in this tab are published to Active Directory if the schema is extended for Configuration Manager 2007 and read by client installations where CCMSetup is run with no installation properties. NOTE: You do not need to specify client push installation properties for the fallback status point or for native mode settings in this tab as these are supplied by default to client push installations.

Software update point based installation The software update point installation method does not support adding installation properties to the CCMSetup command line. If no command line properties have been provisioned on the client computer using Group Policy, it will search Active Directory for installation properties.

Group Policy installation The Group Policy installation method does not support adding installation properties to the CCMSetup command line. If no command line properties have been provisioned on the client computer using Group Policy, it will search Active Directory for installation properties.

Manual installation Active Directory will be searched for installation properties under the following circumstances: No command line properties are specified following the CCMSetup.exe command. The computer has not been provisioned with installation properties using Group Policy.


Installation Method Comments

Logon script installation Active Directory will be searched for installation properties under the following circumstances: No command line properties are specified following the CCMSetup.exe command. The computer has not been provisioned with installation properties using Group Policy.

Software distribution installation Active Directory will be searched for installation properties under the following circumstances: No command line properties are specified following the CCMSetup.exe command. The computer has not been provisioned with installation properties using Group Policy.

Installations for clients that cannot access Active Directory for published information:

■ Workgroup computers

■ Clients from a different Active Directory forest to the site server computer's forest

■ Clients that are installed on the Internet

These client computers cannot read installation properties from Active Directory, and so will not be able to access installation properties published to Active Directory.

The following client installation properties are published by Configuration Manager

2007 to Active Directory.

■ The Management Point used to download content for the client installation.

■ The Configuration Manager 2007 site code.

■ The HTTP port used for client communications in both mixed mode and native

mode.

■ The HTTPS port used for client communication in native mode.

■ A setting to indicate that the client must communicate in native mode.

■ The fallback status point (if the site has multiple fallback status points, only the

first one that was created will be published to Active Directory).

■ The certificate store name if the default (Local Computer) is not being used.


■ The selection criteria for certificate selection, if this is required because the client

has more than one valid certificate that can be used for native mode

communication.

■ A setting to determine if the any valid certificate should be used for native mode

communication if multiple valid certificates exist.

■ Installation properties specified in the Client tab of the Client Push Installation

Properties dialog box.

Reports for Clients

The following reports in Configuration Manager 2007 help you manage and

troubleshoot clients in the Configuration Manager 2007 hierarchy. They have the

report category of Site - Client Information.

For more general information about using reports, see Reporting in Configuration

Manager.

Client Deployment and Assignment Reports

The following reports help you track and monitor client deployment for both

Configuration Manager 2007 clients and SMS 2003 clients, and do not require that

clients are assigned a fallback status point:

■ Computers Assigned but not installed for a particular site

■ Computers with a specific SMS client version

■ Count clients assigned and installed for each site

■ Count clients for each site

■ Count SMS client versions

The following reports help you track and monitor client deployment for

Configuration Manager 2007 clients only, and require that these clients are assigned a

fallback status point:

■ Client Assignment Detailed Status Report

■ Client Assignment Failure Details

■ Client Assignment Status Details

■ Client Assignment Success Details

■ Client Deployment Failure Report


■ Client Deployment Status Details

■ Client Deployment Success Report

Client Communication Reports

The following reports help you to identify client communication problems, for

example if a client cannot communicate with its Management Point because of

certificate problems.

These reports apply to Configuration Manager 2007 clients only, and require that

these clients are assigned a fallback status point:

■ Issues by incidence detail report for a specific collection

■ Issues by incidence summary report for a specific collection

■ Issues by incidence detail report for a specific site

■ Issues by incidence summary report

Important

Configuration Manager 2007 reports that require a fallback status point will only

display data from computers that have commenced client installation and reported

state messages to the fallback status point. Data from the fallback status point might

take some time to reach the Configuration Manager 2007 site server if you are

deploying the client to a large number of computers.

Client Mode Reports

These reports help you to manage clients for when sites are configured for native

mode, which requires public key infrastructure (PKI) certificates for all clients, and

specific site systems.

Use the following report when you are migrating sites from mixed mode to native

mode, to help you identify which clients have successfully switched their site mode

configuration so that they can communicate with their native mode site:

■ Summary information of clients in native mode

The following reports help you to determine if clients are ready to be migrated to

native mode, but require that the Configuration Manager Native Mode Readiness Tool

is first run on Configuration Manager 2007 clients.

■ Clients incapable of native mode

■ Summary information of clients capable of native mode


Note

To incorporate these reports into the procedures for migrating a site to native

mode, see Administrator Checklist: Migrating a Site to Native Mode.

Client Registration

Client registration is the process whereby a SMSv4 client securely informs its

assigned site of its existence and provides the necessary information to the site such

that any future communication between this client and the site is secure and trusted.

Registration DDR (.RDR) Generation

The registration request is forwarded to the site server in the form of a DDR. This file

is called a Registration Discovery Record and has the file extension “.RDR” to

distinguish the registration DDR file from a typical DDR file. The RDR section of the

varfile that is generated contains the following information:

■ SMS ID

■ NetBIOS Name (if present)

■ FQDN (if present)

■ Client Type

■ Client Version

■ Client install flag

Additionally, a new varfile record is appended to the RDR varfile. This record has a

tag value of 1 and contains a series of null-terminated strings that represent the

following properties (in order):

■ SMS ID

■ ClientIdentity (encoded in hex string)

■ DeviceID

■ Certificate binary blob (encoded in hex string)

■ Key Type

■ Public Key (encoded in hex string)

■ Thumbprint (encoded in hex string)

■ ValidFrom (an ANSI string in ODBC ‘Ts’ style datetime format)


■ ValidUntil (an ANSI string in ODBC ‘Ts’ style datetime format)

■ Agent Type

The RDR, once created, is dropped into the DDR outbox on the MP. The File Dispatch

Manager on the MP drops the RDR files into the Auth DDR Inbox on the site server.

Firewall Settings for Configuration Manager 2007 Clients

Client computers that run Windows Firewall might require exceptions to be defined

to allow communications with Configuration Manager 2007 site systems. These

exceptions vary depending on the features of Configuration Manager 2007 you intend

to use.

The following sections list the features of Configuration Manager 2007 which require

exceptions to be made on the Windows Firewall and provide a procedure for

configuring these exceptions.

Modifying the Ports and Programs Permitted by Windows Firewall

To modify the ports and programs permitted by Windows Firewall:

1. On the computer running Windows Firewall, open Control Panel.

2. Right-click Windows Firewall and click Open.

3. On the Exceptions tab of the Windows Firewall Settings dialog box, select enable

any required exceptions in the list box, or Click Add Program or Add Port to

create custom programs or ports

Programs and Ports Required by Configuration Manager 2007

The following Configuration Manager 2007 features require exceptions to be made on

the Windows Firewall:

Configuration Manager Console

Computers running the Configuration Manager console require the following

exceptions on the Windows Firewall:

■ TCP Port 135

■ Program unsecapp.exe

Queries

If you are running the Configuration Manager console on a computer running

Windows Firewall, queries will fail the first time they are run.


After failing to run the first time, the operating system displays a dialog box asking if

you want to unblock statview.exe. If you unblock statview.exe, future queries will run

without errors. You can also manually add statview.exe to the list of programs and

services on the Exceptions tab of the Windows Firewall prior to running a query.

Client Push Installation

In order to successfully use client push to install the Configuration Manager 2007

client, you must add the following as exceptions to the Windows Firewall:

■ File and Printer Sharing

■ Windows Management Instrumentation (WMI)

Client Requests

In order for client computers to communicate with Configuration Manager 2007 site

systems, you must add the following as exceptions to the Windows Firewall:

■ TCP Port 80 (for HTTP communication)

■ TCP Port 443 (for HTTPS communication)

Important

These are default port numbers which can be changed in Configuration Manager

2007.

Network Access Protection

In order for client computers to successfully communicate with the system health

validator point, you need to allow the following ports:

■ UDP 67 and UDP 68 for DHCP

■ TCP 80/443 for IPSec

Remote Control

In order to use the remote tools features of Configuration Manager 2007, you need to

allow the following ports:

■ TCP port 2701

■ TCP port 2702

Remote Assistance and Remote Desktop

To enable Remote Assistance to be initiated from the SMS Administrator console, add

both the custom program helpsvc.exe and the custom port TCP 135 to the list of

permitted programs and services in Windows Firewall on the client computer. Also,


Windows Firewall must be configured to permit Remote Assistance and Remote

Desktop. If a user initiates a request for Remote Assistance from that computer,

Windows Firewall will automatically be configured to permit Remote Assistance and

Remote Desktop.

Windows Event Viewer, Windows Performance Monitor and Windows Diagnostics

To enable Windows event viewer, Windows performance monitor and Windows

diagnostics to be accessed from the Configuration Manager console, you must enable

File and Printer Sharing as an exception on the Windows Firewall.

Client Policy

When you make a change in the Microsoft System Center Configuration Manager

2007 console, the site server creates a policy to communicate the change to the client.

The site server sends the policy to the Management Point and the client polls for

policy at the interval configured on the Computer Client Agent properties.

Policy Assignments and Policy Bodies

For efficiency, policies are created and accessed in two parts, policy assignments and

policy bodies. Policy assignments can contain applicability rules so the clients

download only the policy assignments that apply to them. If there is no applicability

rule in the policy, it applies to all clients. Policy assignments contain pointers to the

actual policy, which is contained in the policy body. The pointer is actually a URL to

the policy body on the Management Point. The URL in the policy assignment does not

actually contain the name of the Management Point, just a variable that the client

replaces with the name of the assigned Management Point or, if at a secondary site,

the proxy Management Point. For information about how clients locate their

Management Point, see Configuration Manager and Service Location.

Full and Delta Policy

The first time a client requests policy assignments it requests full policy but

thereafter it usually requests only the policy assignments it does not already have.

The server uses a reference with the date and time stamp to determine which policy

assignments the client has already received. Certain situations can trigger a full policy

request, such as changing the site mode, assigning a client to a new site, or using the

PolicySpy tool to request assignments.

Policy Caching

Policy assignments are never cached. Every time the client asks for policy

assignments the Management Point contacts the site database so the client always


gets the most recent assignments. If the client is at a secondary site that is the child of

its assigned site, it can request policy assignments from the proxy Management Point

at the secondary site. If the client is roaming to another primary or secondary site in

the hierarchy, the client requests policy from the assigned Management Point.

Policy bodies can be cached by the Management Point to help preserve bandwidth. If

the policy is frequently requested by clients, it remains in cache (space permitting)

and if it is not requested, it ages out. The policy body is never updated. If the body

requires a change, the policy body is marked as obsolete and the policy assignment

will point to a new policy body.

Policy and BITS

Most policy is downloaded using BITS. Client BITS settings can be configured on the BITS tab of the

Computer Client Agent properties. If you configure throttling settings to apply to clients, it might take

longer for clients to receive policy.


Troubleshooting Client Issues

Troubleshooting SCCM 2007

Microsoft Confidential

Troubleshooting Client Deployment

There are a number of log files you can reference to help troubleshoot client issues in Configuration Manager 2007. These are located on both the client computer and the Configuration Manager 2007 site server

Configuration Manager 2007 client log files can be found in one of the following locations:

On client computers that serve as management points, the client log files are located in the SMS_CCM\Logs folder

On all other computers, the client log files are located in the %Windir%\System32\CCM\Logs folder

Troubleshooting Client Deployment


Click any link in the following section for troubleshooting information for client

issues with Configuration Manager 2007.

This content might have been updated. For the most recent information about

troubleshooting client deployment, see http://go.microsoft.com/fwlink/?LinkId=88869.

Log Files for Managing Clients

There are a number of log files you can reference to help troubleshoot client issues in

Configuration Manager 2007. These are located on both the client computer and the

Configuration Manager 2007 site server.

Configuration Manager Log Files

Client Computer Log Files

The Configuration Manager 2007 client log files can be found in one of the following

locations:

On client computers that serve as management points, the client log files are located

in the SMS_CCM\Logs folder.

On all other computers, the client log files are located in the

%Windir%\System32\CCM\Logs folder.

Table 10. Client Computer Log Files

Log file name Description

CcmExec.log Records activities of the client and the SMS Agent Host service. Can help to troubleshoot scenarios where the client is corrupted or not functioning. For example, this log file applies to a scenario where the client cannot communicate with a management point.

CertificateMaintenance.log Records certificate maintenance for Active Directory and management points. Can help to troubleshoot scenarios where the client cannot communicate with a management point or with Active Directory.

ClientIDManagerStartup.log Records the creation and maintenance of client GUIDS. Can help to troubleshoot scenarios where the client changes its GUID after a hardware change or after Windows activation.

ClientLocation.log Records site assignment tasks. Can help to troubleshoot scenarios where the client is not assigned to a Configuration Manager 2007 site.

http://go.microsoft.com/fwlink/?LinkId=88869



LocationServices.log Records attempts to find management points and distribution points. Can help to troubleshoot scenarios where the client cannot find a management point or distribution point.

PolicyAgent.log Records policy requests using the Data Transfer service. Can help to troubleshoot policy request problems.

PolicyAgentProvider.log Records policy changes. Can help to troubleshoot policy request problems or WMI errors.

PolicyEvaluator.log Records new policy settings. Can help to troubleshoot policy override issues.

StatusAgent.log Records status messages that are created by the client components. Can help to troubleshoot scenarios where the client cannot send status to the management point.

Configuration Manager Site Server Log Files

The Configuration Manager 2007 site server log files can be found in the folder

SMS\Logs on the site server.

Table 11. Site Server Log Files


Ccm.log Records client configuration manager tasks. Can help to troubleshoot scenarios where the site cannot connect to computers because of permissions or name resolution.

Fspmgr.log Records fallback status point activities. Can help to troubleshoot problems with the fallback status point.

Hman.log Records site configuration changes and publishes site information in Active Directory. Can help to troubleshoot site control serial number or delta serial number issues, or scenarios where the site cannot publish site information to Active Directory.

Mpcontrol.log Records the registration of the management point with WINS. Records the availability of the management point every ten minutes. Can help to troubleshoot possible IIS issues if the management point is unavailable.

Policypv.log Records updates to the Advanced Client policies to reflect changes to client settings or advertisements. Can help to troubleshoot scenarios where policy updates do not occur after you make changes to advertisements or to client settings.



Sitecomp.log Records maintenance of the installed site components. Can help to troubleshoot upgrade issues, registry or file system permission issues, or scenarios where the site cannot publish site information to Active Directory.

Client Setup Log Files

Information on the client information can be found in the client setup log files located

in the folder %windir%\system32\CCMSetup on the client computer.

Table 12. Client Setup Log Files


CCMSetup.log Records setup tasks performed by CCMSetup. Can be used to troubleshoot client installation problems.

Client.msi.LOG Records setup tasks performed by client.msi. Can be used to troubleshoot client installation problems.

This section provides troubleshooting information to help you resolve issues when

deploying and managing clients in Configuration Manager 2007.

Note

Assigning a fallback status point to Configuration Manager 2007 clients is one of the easiest ways for an administrator to identify troubleshooting issues for client installation or assignment. It also helps to identify clients that are unmanaged because they have problems communicating with their management point.

Clients Fail to Assign to a Site Because the Site Compatibility Check Fails

If Configuration Manager 2007 clients successfully install but fail to assign to a site, a

likely reason is that the check for site compatibility failed during the assignment

process.

Solution

Ensure that clients have a mechanism to check for site compatibility. This is achieved

in one of two ways:

Active Directory Domain Services is extended for Configuration Manager 2007, and

clients belong to this forest.

Clients can find a server locator point that's published in WINS, or they are reinstalled

and assigned to a server locator point during installation.


Clients Cannot be Managed Because they Cannot Locate their Default Management Point

If Configuration Manager 2007 clients successfully install, assign to a site, but fail to

download policy, a likely reason is that either the site has no default management

point, or clients cannot locate it.

Solution

■ Make sure that a default management point is configured for the site.

■ Clients find their default management point using one of the following service

location requests:

■ Active Directory Domain Services (if the schema is extended for Configuration

Manager 2007)

■ DNS (if Configuration Manager 2007 is configured for DNS publishing)

■ WINS

■ Server locator point.

■ Ensure that one of these mechanisms is available to clients.

Clients Fail to Install Using Client Push Because Windows Firewall Blocks Installation

If Configuration Manager 2007 clients are running Windows Firewall, client push

installation can fail if the Windows Firewall is not configured appropriately. Because

packets are blocked from the client, no information is sent to the fallback status point

and client logs do not contain any data.

Solution

In order to successfully use client push to install Configuration Manager 2007 clients,

add the following as exceptions to the Windows Firewall:

■ File and Printer Sharing

■ Windows Management Instrumentation (WMI)

Missing Data in Client Deployment and Assignment Reports

If you view the following reports and they do not contain client data, ensure that

clients are assigned to a fallback status point:

■ Client Assignment Detailed Status Report

■ Client Assignment Failure Details

■ Client Assignment Status Details

■ Client Assignment Success Details


■ Client Deployment Failure Report

■ Client Deployment Status Details

■ Client Deployment Success Report

Solution

Assign a fallback status point to Configuration Manager 2007 clients and view the

reports from the site in which the fallback status point is installed. SMS 2003 clients

do not use these reports.

Additionally, if you are deploying a high number of clients at the same time, there

might be a delay in processing all the state messages sent from the fallback status

point to the site. In this scenario, wait for the data to appear and consider configuring

the throttling settings on the fallback status point.

Clients Fail to Install Because the Management Point is Not Operational

All clients in a site fail to be managed if their default management point is not

operational because of an unsupported configuration or missing dependencies on the

management point.

Solution

■ Ensure that the management point has the required dependencies..

■ Consider manually running the Configuration Manager 2007 Setup Prerequisite

Checker to identify any missing dependencies for the management point.

Clients Fail to Automatically Approve (Mixed Mode)

If Configuration Manager 2007 clients do not automatically approve, even though you

are using the default site setting of Automatically approve computers in trusted

domains (recommended), this scenario can happen in the following situations:

■ Client computers do not belong to the same domain as the site server's domain,

and the site's default management point is not configured with a fully qualified

domain name (FQDN).

■ Clients belong to a separate Active Directory forest, or are workgroup computers

■ You are using a network load balancing (NLB) management point

■ You have changed the site approval setting after clients have successfully

assigned to the site.

Solution

Refer to the following table to troubleshoot each situation listed above.


Table 13. Troubleshooting Automatic Approval Failures

Situation Solution

Client computers do not belong to the same domain as the site server's domain, and the site's default management point is not configured with a fully qualified domain name (FQDN).

Configure the site system that holds the default management point role with an FQDN

Clients belong to a separate Active Directory forest, or are workgroup computers

This is by design and you must manually approve these clients because they cannot be automatically verified using Windows integrated authentication.

You are using an NLB management point. This scenario requires additional configuration: Make sure that the NLB management point is configured to use an FQDN. Locate the configuration steps provided in the Microsoft Windows Server 2003 article that explains how to configure Kerberos authentication for load balanced web sites:

http://go.microsoft.com/fwlink/?LinkId=92667 Follow the instructions in the article with the following two exceptions: At the end of Phase 1: Administration of Domain Controller, add the domain user account to the local Administrators account on each server in the NLB cluster. During Phase 2: Administration of Servers, add the domain user account to the application pool named CCM Windows Auth Server Framework Pool, rather than to the example application pool named DefaultAppPool.

You have changed the site approval setting after clients have successfully assigned to the site.

This is by design, because the client approval state is set when the client assigns to a site. To approve clients that have successfully assigned to the site, but are unapproved, perform either of the following actions: Manually approve the client. Reinstall the client.



Overview of Software Update Management

Software Update Management with System Center Configuration Manager 2007


Overview

Definitions

WSUS – Windows Server Update Services

WCM – WSUS Configuration Manager

WSM – WSUS Synchronization Manager

SUM – Software Update Management

MU – Microsoft Update website used to retrieve update metadata and content

WUA – Windows Update Agent, the service on the client that installs and scans for

updates

CLR – Common Language Runtime

ITCU – Inventory Tool for Custom Updates that supports importing updates using

SDP documents.

CI – A Configuration Item is a unit of configuration in Configuration Manager, which

can be assigned to target systems for configuring those systems. Each CI references

an SDM class type representing the desired configuration.

CI Assignment – A Configuration Manager policy object which binds a CI to a

collection of Configuration Manager Clients. The assignment can contain additional

properties which determine how the CI should be handled on the client. For example,

an assignment may specify a schedule on which the client should evaluate the

configuration (i.e. SDM class type) contained in the CI. CI’s and CI assignments are not

modles in SDM in Configuration Manager 2007.

DCM – The Desired Configuration Monitoring feature in Configuration Manager

allows an administrator to assess compliance of configuration items on target

systems.

NAP –Network Access protection is a new feature, which is available in Configuration

Manager, which allows administrators to select software updates and if clients are

not complaint with these software updates Configuration Manager will restrict

network access for those clients using the infrastructure provided by Windows 2008

Server.

Providing updates to software and maintaining managed resources is a reality of

networked, distributed computing. An effective Software Update Management


process is necessary to maintain operational efficiency, overcome security issues, and

maintain the stability of the network infrastructure. However, because of the

changing nature of technology and the continual appearance of new security threats,

the task of effective Software Update Management can be challenging.

The Microsoft System Center Configuration Manager 2007 software updates feature

provides a set of tools and resources that can help manage the complex task of

tracking and applying software updates to client computers in the enterprise.

Prerequisites for Software Updates

Before deploying software updates in Configuration Manager 2007, there are several

components that must be installed and configured depending on the environment.

The following table provides a list of these components, and then each is described in

more detail in the following sections.

Table 14 Dependencies external to Configuration

Dependency More Information

Windows Server Update Services (WSUS) 3.0

Software updates requires WSUS 3.0 for software updates synchronization and for software update compliance assessment scan on clients. The WSUS server must be installed before creating the software update point site role, which uses the WSUS server as a prerequisite component. The software update point component handles synchronization requests to WSUS, inserting synchronized software updates metadata into the site server database and sending state messages to indicate the current status. Clients connect to the WSUS server when performing compliance assessment scans for software updates. The Windows Update Agent (WUA) on the client computer connects to the WSUS server to retrieve the relevant software updates metadata to perform the scan. WSUS 3.0 is available for download on the Microsoft Download Center Web site.

WSUS 3.0 Administration Console

The Windows Server Update Services (WSUS) 3.0 Administration Console is required on the Configuration Manager 2007 site server when the active software update point is on a remote site system server and WSUS is not already installed on the site server. This component is required on the site server before it can communicate with the WSUS server on the remote active software update point, allowing the site server to configure the WSUS components and synchronize software updates.

Windows Update Agent (WUA) 3.0

The WUA 3.0 client is required on clients to connect to the WSUS 3.0 server and retrieve the list of software updates that need to be scanned for compliance.

Site server communication to the active software update point

There could be configuration settings that must be addressed depending on the software update point infrastructure and Configuration Manager 2007 site settings.



Network Load Balancing (NLB)

Each software update point can support up to 25,000 client computers. When you expect that more client computers will connect to the active software update point, the WSUS server and active software update point must be configured to use a Network Load Balancing (NLB) cluster.

Background Intelligent Transfer Server (BITS) 2.5

It is highly recommended that BITS 2.5 is enabled and configured for the site and also that Distribution Points are BITS enabled. When software updates install on client computers, the source files are first downloaded to the local cache and then installed. If BITS is enabled on the Distribution Point, disconnection from the network while software updates are downloading does not cause the deployment to fail because BITS resumes the download, starting where it was interrupted, the next time the client has network access. If BITS is not enabled on the Distribution Point and a network problem occurs while downloading software update files, the software update installation fails.

Windows Installer 3.1 Client computers must have Windows Installer 3.1 installed or certain software updates, such as Microsoft Office updates, will not be detected during a scan for software update compliance. Most client computers should already have Windows Installer 3.1 installed, but if needed, it is available to download from the Microsoft Download Center Web site (http://go.microsoft.com/fwlink/?linkid=21788)

Table 15 Dependencies Internal to Configuration Manager


Reporting Point Site System

The reporting point site system role must be installed before software updates reports can be displayed.

Interop with SMS 2003

When there are SMS 2003 clients in the Configuration Manager 2007 hierarchy, the

Configuration Manager version of the Inventory Tool for Microsoft Updates must be

installed on the highest site in the hierarchy. Without the Configuration Manager

version of the inventory tool, the option to deploy software updates to SMS 2003

clients is not available from the Configuration Manager console.

The Inventory Tool for Microsoft Updates is automatically upgraded after a site is

upgraded, and the tool is also available on the Configuration Manager 2007 CD. After

a site has been installed or upgraded, the inventory tool downloads the Microsoft

Updates catalog from the download location, synchronizes the software updates in

the catalog, and stores the software update information in the site database. After the

http://go.microsoft.com/fwlink/?linkid=21788


inventory tool is installed on SMS 2003 client computers, the client scans for the

software updates based on the catalog.

Before distributing the Inventory Tool for Microsoft Updates to all clients that meet

the minimum requirements, it is highly recommended that the distribution first be

tested on the test client that is specified during installation. The following procedures

provide the steps to install the Inventory Tool for Microsoft Updates, verify that the

inventory scan tool and synchronization components are installed, and verify that the

test client scanned for software updates and sent the data to the site server.

Administrator Workflow: Software Updates End to End Workflow

Software updates in Configuration Manager 2007 must be configured before

deploying updates to clients. Several additional steps should also be considered when

planning for a deployment. After Configuration Manager is installed, the dependent

components for software updates must be installed and configured, an active

software update point must be enabled and configured, synchronization must occur

between the software update point and Windows Server Update Services (WSUS),

clients must scan for software updates compliance, software updates must be

selected for deployment, and finally the deployment can be created and sent to

clients.

The following flowchart provides a high level visual workflow for these steps.


Figure 1. Software Updates End-to-End Flow


The Software Updates Process

Software updates in Configuration Manager 2007 are composed of two main parts.

The metadata is the information about each software update, and it is stored in the

site server database. The second part is the software update file, which is what client

computers download and run to install the software update. There are three main

operational phases. The synchronization phase is when the software update metadata

is synchronized from the upstream Windows Server Update Services (WSUS) server,

or from Microsoft Update, and inserted into the site server database. The compliance

assessment phase is when client computers scan for software update compliance and

report their compliance state for synchronized software updates. The deployment

phase is when software updates selected for deployment by the administrator, the

software updates policy sent to client computers, and then the software update files

are downloaded to and installed on client computers. Each phase is described in

detail later in this section.

Before software update compliance assessment data can be displayed in the

Configuration Manager 2007 console and software updates can be deployed to client

computers, considerable planning should take place for software updates in the

hierarchy. Then the software updates components must be configured to meet the

needs of the environment.

Planning Phase

The planning phase for software updates involves learning the Configuration

Manager 2007 concepts, becoming familiar with the software updates in a test

environment, collecting information about your production environment, planning

for software updates when there are Systems Management Server (SMS) 2003 child

sites, planning software updates when there are Internet-based client computers,

determining whether Network Load Balancing (NLB) should be used on the software

update point, and so on.

Configuration Phase

After Configuration Manager 2007 is installed, the software updates feature must be configured. The

configuration phase for software updates involves installing and configuring the software update point,

as well as reviewing the configuration settings for other software updates components and modifying

the settings as needed.

Synchronization Phase

Software updates synchronization in Configuration Manager 2007 is the process of

retrieving the software updates metadata that meets the configured criteria from the


upstream Windows Server Update Services (WSUS) server or Microsoft Update.

Synchronization can be scheduled as part of the software update point properties or

manually initiated by using the Run Synchronization action on the Update

Repository console tree node on the highest site in the hierarchy with software

updates enabled. Child sites initiate synchronization only after receiving a request

from their parent site.

Compliance Assessment Phase

The Software Updates Client Agent is enabled in Configuration Manager 2007 by

default, which installs components used on client computers to manage the

compliance assessment and evaluation scanning for software updates, and the

installation of software updates that are deployed to them. When the software update

point is installed and synchronized, a site-wide machine policy is created that informs

client computers that software updates has been enabled for the site and the client

computer initiates a scan for software updates compliance. The compliance results

are sent to the Management Point using state messages, forwarded to the site server,

and then inserted into the site database.

Deployment Phase

The Configuration Manager 2007 console displays the compliance assessment data

for client computers in the hierarchy. Software update deployments are created for

software updates that are required using the Deploy Software Updates Wizard.

Deployments can be created so that client computers have the option to install the

updates (optional deployment) or automatically initiate software update installation

on client computers at the configured deadline (mandatory deployment).

Software Updates Objects

Each feature in Configuration Manager 2007 uses and provides the ability to create

objects. In most cases, class and instance security rights can be configured for the

object and administrative actions can be run against the object to initiate a process.

The following software updates objects are available in the Configuration Manager

console:

Table 16. Software Updates Objects

Object Description

Deployments Deployments are used to deploy software updates to clients in the target collection. Deployment objects are replicated to child sites where they are read-only.

Deployment packages

Deployment packages host the software update source files. Deployment package objects are replicated to child sites where they are read-only.


Object Description

Deployment templates

Deployment templates store many of the deployment properties that might not change from deployment to deployment and are used to save time and ensure consistency when creating deployments.

Search folders Search folders provide an easy way to retrieve a set of software updates that meet the defined search criteria.

Software updates

Each software update is a configuration item object that is created during the software update synchronization process.

Update lists Update lists are a fixed set of software updates and can be used for delegated administration and creating software update deployments. There are also several reports that provide information about update lists.

Objects Replicated to Child Sites

Software updates deployment and deployment package objects are replicated from

the site where they were created to all child sites in the Configuration Manager

hierarchy. Each of the objects replicated to a child site contain read-only properties.

Even though the properties for these objects must be modified at the site where they

were created, the actions available for deployments at child sites are the same as on

the site where they were created and deployment packages can be used to host the

software updates that are deployed on the child sites.

Icons for Software Updates Objects

Each software updates object displays an icon in the Configuration Manager console.

Depending on the state of the object, there might be different icons for the same

software updates object. For example, a software update typically displays an icon

with a green arrow, but a software update that has been superseded by another

update displays an icon with a yellow arrow.

The Software Update Point

The software update point in Configuration Manager 2007 is a required component of

software updates and is installed as a site system role in the Configuration Manager

console. The software update point site system role must be created on a server that

has Windows Server Update Services (WSUS) 3.0 installed. The software update point

interacts with the WSUS services to configure update settings, to request

synchronization to the upstream update server, and to synchronize the updates from

the WSUS database to the site server database.


Requirements for the Software Update Point

WSUS 3.0 must be installed on each site system server before it is assigned the

software update point site system role, and other requirements might be necessary

depending on your environment and the Configuration Manager 2007 site server

infrastructure.

Software Update Point Process

When the software update point site system role is created and configured as the

active software update point, the software update point components are installed and

enabled. The WSUS Control Manager component configures the associated WSUS

server with the settings that were configured while creating the software update

point site system role.

Software Update Point Settings

The software update point settings can be modified from the Software Update Point

Component properties. The software update point settings configure what site

system server is the active software update point, what site system server is the

active Internet-based software update point if one is specified at the site, the

synchronization source, synchronization schedule, and the products, classifications,

and languages for which software updates will be synchronized.

Software Update Point Synchronization

The software update point initiates synchronization at the synchronization schedule,

if configured, or when the Run Synchronization action is run from the Update

Repository console tree node. The WSUS Synchronization Manager (WSM)

component makes a request to WSUS on the active software update point server to

start synchronizing with its synchronization source, which is configured to be WSUS

on the parent site's active software update point server or Microsoft Update. When

the WSUS synchronization completes, WSM initiates a site server synchronization

that retrieves any new or modified software update metadata from WSUS on the

active software update point server and inserts or updates the metadata in the site

server database. Once the software update metadata is synchronized, it can be viewed

in the Configuration Manager console.

The first time the software update point synchronization completes, the Software

Updates Client Agent components are activated from a previously dormant state and

will connect on a schedule to WSUS on the active software update point server to

initiate a scan for software updates compliance.


The Software Updates Client Agent

The Software Updates Client Agent in Configuration Manager 2007 is enabled by

default and client agent components are installed on client computers with the other

Configuration Manager client components. The Software Updates Client Agent

handles compliance assessment scan requests, software update evaluation requests,

deployment policies for the client, and content download requests. The Software

Updates Client Agent properties contain several sitewide client agent settings.

Software Updates Client Agent Settings

The Software Updates Client Agent settings are configured in the Software Updates Client

Agent Properties dialog box, which is accessed from the Client Agents Configuration

Manager console tree node. The following client agent settings can be configured:

General Settings

The Enable Software Updates on Clients setting specifies whether to enable the

Software Updates Client Agent and the Scan Schedule specifies how often the client

agent initiates compliance assessment scans on client computers. Disabling the

Software Updates Client Agent puts the client agent components on client computers

into a dormant state, but does not remove the components. Reenabling the Software

Updates Client Agent will initiate a policy to request that the components on clients

be enabled. The Software Updates Client Agent is configured on a site-by-site basis.

Disabling the client agent on a site affects only the client computers assigned to that

site and prevents compliance assessment scanning and deployments from being

received on client computers.

Update Installation Settings

The Enforce all mandatory deployments setting specifies whether to enforce all

mandatory software update deployments that have deadlines within a specified

period of time. When a deadline is reached for a mandatory software update

deployment, installation is initiated on clients for the updates defined in the

deployment. This setting determines whether to also initiate the installation for

software updates defined in other mandatory deployments that have a configured

deadline within the specified period of time. The Hide all deployments from end

users setting provides the ability to hide deployments when they are received and

installed on client computers.

Deployment Reevaluation Setting

The Deployment Reevaluation setting specifies how often the Software Updates

Client Agent reevaluates software updates for installation status. When software

ms-its:C:\Documents%20and%20Settings\Reneeg\Desktop\SMSv4.chm::/html/30e3d2f8-5b51-4b0f-a7c9-5b6bea5215e0.htm




updates that have been previously installed are no longer found on client computers,

and still required, they are reinstalled.

Software Updates Metadata

Software updates in Configuration Manager 2007 consist of software update files and

metadata. The software update file is the actual file that the client computer

downloads, such as an executable (.exe) or Windows Installer (.msi) file, and then

installs to update a component or application. The metadata provides the information

about the software update, such as name, description, products that the update

supports, update classification, article ID, download URL, applicability rules, and so

on.

Software Update Products, Classifications, and Languages

Software updates are synchronized based on product (or product family),

classification, and language. Each of these can be configured in the Software Update

Point Configuration Properties dialog box, which can be accessed by using the

following procedure.

1. In the Configuration Manager console, navigate to System Center Configuration

Manager / Site Database / Site Management / <site code> - <site name> / Site

Settings / Component Configuration.

2. Right-click Software Update Point Component, and then click Properties.

Products Synchronized by Configuration Manager

The metadata for each software update defines what products are applicable to the

update. A product is a specific edition of an operating system or application (for

example, Microsoft Windows Server 2003). A product family is the base operating

system or application from which the individual products are derived. An example of

a product family is Microsoft Windows, of which Microsoft Windows Server 2003 is a

member. You can specify a product family or individual products within a product

family. The products are configured from the Products tab of the Software Update

Point Component Properties dialog box on the active software update point highest

in the Configuration Manager hierarchy, which is most often the central site.


Note

When software updates are applicable to multiple products and at least one of the

products has been selected for synchronization, all the products will appear in the

Configuration Manager console even if some have not been selected. For example, if

Windows Server 2003 is the only operating system that you have subscribed to and a

software update applies to product "Windows Server 2003" and "Windows

Server 2003 Datacenter Edition," both products will show up in the Configuration

Manager repository.

Update Classifications Synchronized by Configuration Manager

The metadata for each software update defines what classification type the update is

a member of. The update classification represents what type of software the software

update will update on client computers. For any given product or product family,

software updates can be defined with many different update classifications. The

following update classifications are currently available for software updates in

Configuration Manager:

■ Critical Updates: Specifies a broadly released update for a specific problem that

addresses a critical, non-security-related bug.

■ Definition Updates: Specifies an update to virus or other definition files.

■ Drivers: Specifies an update to software components designed to support

hardware.

■ Feature Packs: Specifies new product features that are distributed outside of a

product release and typically are included in the next full product release.

■ Security Updates: Specifies a broadly released update for a product-specific,

security-related issue.

■ Service Packs: Specifies a cumulative set of hotfixes that are applied to an

application. These hotfixes can include security updates, critical updates,

software updates, and so on.

■ Tools: Specifies a utility or feature that helps to complete one or more tasks.

■ Update Rollups: Specifies a cumulative set of hotfixes that are packaged together

for easy deployment. These hotfixes can include security updates, critical

updates, updates, and so on. An update rollup generally addresses a specific area,

such as security or a product component.

■ Updates: Specifies an update to an application or file currently installed.


The update classifications are configured from the Classifications tab of the

Software Update Point Component Properties dialog box on the active software

update point highest in the Configuration Manager hierarchy, which is most often the

central site.

Update Language

The metadata for each software update defines what languages the update file is

applicable to, and it provides the summary information for the software update in

one or more languages. The summary information includes the title and description

for the software update and is configured from the Languages tab of the Software

Update Point Component Properties dialog box on the active software update point

highest in the Configuration Manager hierarchy, which is most often the central site.

Important

It is very important that you select all of the summary details languages that will

be needed in your Configuration Manager hierarchy. When the active software update

point on the central site is synchronized, the selected summary details languages

determine what software update metadata is retrieved. If the summary details

languages are modified after the synchronization has run at least one time, the

metadata is retrieved for the modified summary details languages for only new or

updated software updates. The software updates that have already been

synchronized will not retrieve metadata for different languages unless there is a

change to the update on Microsoft Update.

Software Updates Metadata After a Site Upgrade

During a site server upgrade, supported software updates are migrated into the

Configuration Manager 2007 database and the Expired attribute for each update is set

to Yes, putting them in an expired state. Before Configuration Manager client

computers are able to scan for software update compliance and before software

update deployments can be created at the site server, the updates must be put back

into an active state by running software updates synchronization.

Software Updates Supersedence

Supersedence occurs when a new software update contains the same fixes that were

in a previously released software update. In the past, new and previously released

software updates, which contained the same fix, might have both been marked as

required when the only one that was necessary was the newer software update.

In Configuration Manager 2007, when new software updates are released that

contain fixes for previously released updates, Microsoft Update is refreshed with


information relating to the new software update and any software updates that it

supersedes. As client computers scan for software update compliance, any required

software updates that supersede previous updates are returned with the compliance

state but the previously released software updates are not returned. The exception to

this is when a Service Pack contains a required software update. The Windows

Update Agent returns both the software update and the service pack with a required

compliance state. This provides administrators with the flexibility to deploy

individual software updates or full service packs.

Software Update Files

Software updates in Configuration Manager 2007 consist of metadata and software

update files. The metadata provides the information about the software update, such

as name, description, products that the update supports, update classification, article

ID, download URL, applicability rules, and so on. The software update file is the actual

file that the client computer downloads, such as an executable (.exe), Windows

Installer (.msi) file, or Windows Installer Patch (.msp), and then installs to update a

component or application. The software update file might be stored on a Windows

Server Update Services (WSUS) 3.0 server that is configured to be an active software

update point, and is always stored on Distribution Points for the site when the

software update is downloaded or deployed.

How WSUS Stores Update Files

When software updates are synchronized at the central site, the software updates

metadata is synchronized from Microsoft Update, but depending on how the

Windows Server Update Services (WSUS) server is synchronized, the update files

might or might not be copied down to a shared folder on the WSUS server. When

synchronization completes on the WSUS server, only the metadata is synchronized

from the WSUS server database to the Configuration Manager site database.

Note

When System Center Updates Publisher is used to publish software updates, the update files are automatically stored in the shared folder on the WSUS server.

How Configuration Manager Stores Update Files

Software update files are retrieved and copied to Distribution Points when the

software update is downloaded using the Download Updates Wizard or deployed to

client computers using the Deploy Software Updates Wizard. Both methods download

the software update file to a temporary location on the site server hard drive, which

creates and stores a compressed package file containing the software update,

decompresses the package file, and then copies the update file to the package shared


folder on the Distribution Point. When client computers receive a deployment with

the update, they will download the software update file from the Distribution Point,

store the update file in the local cache, and then run the update file.

Software Updates Synchronization

Software updates synchronization in Configuration Manager 2007 is the process of

retrieving the software updates metadata that meet the configured criteria from the

upstream Windows Server Update Services (WSUS) 3.0 server or Microsoft Update.

The highest site in the Configuration Manager hierarchy with an active software

update point (most likely the central site and referred to as the central site for the

rest of this topic) synchronizes with Microsoft Update, which can be scheduled as part

of the software update point properties or manually initiated by using the Run

Synchronization action on the Update Repository console tree node.

When synchronization is initiated on a configured schedule, all changes to the

software updates metadata since the last scheduled synchronization are inserted into

the site database. This includes new software updates metadata or metadata that has

been modified or removed. When synchronization is initiated manually, only new

software updates metadata since the last synchronization is inserted into the site

database. The manual synchronization completes faster than the scheduled

synchronization.

Synchronization on Child Sites

When software update synchronization completes at the central site, a

synchronization request is sent to any child sites. When the child site receives a

synchronization request from its parent, it will complete the synchronization process

and send a synchronization request to any of its child sites, and the process is

repeated throughout the hierarchy. The software update point on the child site

synchronizes with the software update point on the parent site.

Synchronization on an Internet-Based Software Update Point

When an active Internet-based software update point is installed on a site,

synchronization for the Internet-based software update point is initiated immediately

after synchronization completes on the active software update point. The

synchronization process for both active software update points is the same, except

that the upstream server for the Internet-based software update point is

automatically configured to be the active software update point for the site and the

site server database is not updated at the completion of the Internet-based software

update point synchronization.


When the synchronization source for the Internet-based software update point is not

configured to synchronize, the export and import function of the WSUSutil tool can be

used to synchronize software updates metadata from active software update point for

the site.

Synchronization Process

The software update point site system role must be created on a computer that has

WSUS 3.0 server installed. The WSUS Synchronization Manager component on the

software update point works with the WSUS services to complete the synchronization

process. When synchronization is initiated at the central site, WSUS Synchronization

Manager makes a request to the WSUS service to initiate synchronization. The

software updates metadata is then synchronized from Microsoft Update and any

changes are inserted into the WSUS database. When WSUS completes

synchronization, WSUS Synchronization Manager initiates synchronization with the

WSUS database and inserts any changes into the site server database. When

synchronization completes, the WSUS Synchronization Manager component,

SMS_WSUS_SYNC_MANAGER, creates status message 6702.

When an active Internet-based software update point is configured on the central

site, the same synchronization process is followed as described above, except that the

active Internet-based WSUS server synchronizes with the active software update

point configured for the site, not Microsoft Update, and the site server database is not

synchronized as part of the process.

When synchronization completes on the central site, a synchronization request is

then sent to any child sites, the WSUS Synchronization Manager on the child site

makes a request to the WSUS service to initiate synchronization, and the WSUS

service synchronizes with the upstream WSUS server, which is automatically

configured to be the software update point on the parent site. When synchronization

completes on the software update point, the Internet-based software update point, if

configured, synchronizes with the active software update point for the site. The

process continues throughout the hierarchy. When synchronization completes at

each site, a site wide machine policy is created that allows client computers to

retrieve the location of the WSUS server and to initiate a scan for software updates

compliance.

If synchronization fails, there is a retry interval of 60 minutes. The WSUS

Synchronization Manager component will schedule the synchronization in 60

minutes from the failed process, and then initiate the same synchronization process

as described earlier. WSUS Synchronization Manager will create status message 6703

when synchronization fails.


Synchronizing Software Updates for SMS 2003 Clients

Systems Management Server (SMS) 2003 clients use the Inventory Tool for Microsoft

Update to scan for the software updates that are defined in the Microsoft Update

catalog. The Microsoft Update catalog must be synchronized for the client computers

to scan for the most recent software updates. By default, the catalog is synchronized

every seven days using the Microsoft Update Tool Sync advertisement on the site

where the Inventory Tool for Microsoft Updates is installed, most likely the central

site.

About the Icons for Software Updates

Every software update that has been synchronized displays in the Configuration

Manager 2007 console, and the first column for each software update contains one of

four icons. This section provides information about each icon that can be associated

with a software update.

Normal Icon

The green icon represents a normal software update.

Description: Software updates that have been synchronized available for

deployment.

Operational Concerns: There are no operational concerns.

Expired Icon

The grey icon represents an expired software update. Expired software updates

can also be identified by viewing the Expired column for the software update when it

displays in the Configuration Manager console.

Description: Expired software updates were previously deployable to client

computers, but once a software update is expired, new deployments can no longer be

created for the updates. Existing deployments that contain an expired update

continues to work.

Operational Concerns: Expired software updates should be replaced when possible.

Expired software updates that have been deployed continue to work and will

continue to be tracked for software update compliance.

Superseded Icon

The yellow icon represents a software update that has been superseded by

another update. Superseded updates can also be identified by viewing the Superseded


column for the software update when it displays in the Configuration Manager

console.

Description: Superseded software updates have been replaced with newer versions

of the update, but are still deployable. For example, a software update that has been

included in a service pack or update rollup would be superseded.

Operational Concerns: When possible, you should deploy the superseding software

update to client computers instead of the update that was superseded. When

selecting a superseded software update in the Configuration Manager console, the

Superseded tab displays that provides a list of the software updates that supersede

the selected update.

Invalid Icon

The red icon represents an invalid software update.

Description: Invalid software updates are deployed but for some reason, the content

(update file) is not available. There are 2 main ways this could happen – first is that

updates get deployed successfully but sometime later someone deletes the update

binary from a package; second is one a child site, where the deployment created at a

parent site has been replicated successfully, but for some reason, the deployment

packages have not been replicated to a DP for the child site

Operational Concerns: The invalid software update needs to be redeployed. When

content is missing for an update in a deployment created at a parent site, the software

update needs to replicated or re-downloaded on child sites.

Locked Software Update Icons

The software updates metadata is synchronized at the highest site in the

Configuration Manager hierarchy that has an active software update point, which is

usually the central site. The properties for the software updates can be modified at

the central site, but at child sites the properties are locked. This is indicated by a lock

displayed on the software update icon.

Compliance for Software Updates

Before software updates can be deployed to client computers in Configuration

Manager 2007, the scan results for software update compliance must be initiated on

client computers. Once the compliance data is inserted into the site database,

software updates can be deployed and installed on client computers that require the

updates. The following sections provide information about the compliance states and

describe the process for scanning for software updates compliance.


Software Updates Compliance States

There are four compliance states that are displayed in the Configuration Manager

console for software updates. The following table lists and describes each compliance

state:

Table 17 Software Update Compliance States

State Description

Required Specifies that the software update is applicable and required on the client computer. Any of the following conditions could be true when the software update state is Required: The software update has not been deployed to the client computer. The software update has been installed on the client computer, but the most recent state message has not yet been inserted into the database on the site server. The client computer rescans for the update after the installation completes. There might be a delay of up to two-minutes before it sends the updated state to the Management Point, which then forwards it to the site server. The software update has been installed on the client computer, but the software update installation requires a computer restart before it completes. The software update has been deployed to the client computer but not yet installed.

Not Required

Specifies that the software update is not applicable on the client computer, and therefore, the software update is not required.

Installed Specifies that the software update is applicable on the client computer and that the client computer already has the software update installed.

Unknown Specifies that it is unknown whether the client computer requires the software update. This state usually means that the software update has been synchronized to the site server, but since that time, the client computer has not scanned for software update compliance.

Scan for Compliance Process

When the software update point is installed and synchronized, a site-wide machine

policy is created that informs client computers that software updates has been

enabled for the site. When a client computer receives the machine policy, a

compliance assessment scan is scheduled to start randomly within the next two

hours. When the scan is initiated, a component of the Software Updates Client Agent

clears the scan history, submits a request to find the WSUS server that should be used

for the scan, and updates the local Group Policy with the WSUS server location.

Note

Internet-based clients and clients attached to a site configured for Native mode

must connect to the WSUS server using Secure Sockets Layer (SSL).


A scan request is passed to the Windows Update Agent (WUA). The WUA then

connects to the WSUS server location listed in the local policy, retrieves a list of the

software updates that have been synchronized on the WSUS server, and scans the

client computer for the updates in the list. A component of the Software Updates

Client Agent detects that the scan for compliance has completed, and it creates state

messages for each software update that had a change in compliance state since the

last scan. The state messages are sent to the Management Point in bulk every five

minutes. The Management Point then forwards the state messages to the site server,

where the state messages are inserted into the site server database.

Update Lists in Software Updates

An update list in Configuration Manager 2007 contains a set of software updates.

Using the update list provides several benefits when deploying and monitoring

software updates and is, therefore, part of the recommended software updates

workflow. The update lists are displayed in System Center Configuration Manager

/ Site Database / Computer Management / Software Updates / Update Lists. The

software updates contained in each update list are displayed by selecting an update

list in the Update Lists console tree node.

The following sections provide information about using update lists, how an update

list can be used for delegated administration, and how using update lists for

deploying software updates provides a better reporting experience for retrieving the

compliance state for software updates.

Creating an Update List

You create an update list by selecting one or more software updates, and then

initiating the Update List action to open the Update List Wizard. You must have

Create rights on the Configuration items class to create an update list.

Adding Software Updates to an Update List

Software updates are added to an update list by using the Update List Wizard.

Software updates are selected in the Configuration Manager console and the Update

List action is used to open the wizard. You can add the software updates to an existing

update list or create a new one. You must have Modify rights on the Configuration

items class to add software updates to an update list.

Delegated Administration

Using an update list provides the ability to delegate the administration for approving

and deploying software updates. For example, an administrator at the central site can


select the software updates that need to be deployed and add the updates to an

update list. Administrators at child sites, with restricted object rights, can then use

the update list and deploy the updates in the update list to an appropriate collection.

The following table provides the minimum object class rights for an administrator at

a child site when the update list, deployment template, and collection have been

created, and when the software updates have been downloaded to a deployment

package:

Table 18 Minimum Object class rights for SUM

ConfigMgr Object Read Distribute Create Advertise

Collection * *

Configuration Items * *

Deployment * *

Deployment Package * *

Deployment Template *

Site *

Example Deployment Scenario

The Configuration Manager administrator at the central site reviews software

updates on a monthly basis for her phased deployment scenario. The administrator

has several deployment templates that she has created for her typical deployment

scenarios. She adds the software updates to the update list and chooses to download

the updates as part of the Update List Wizard. She creates a user group for her child

site administrators, gives the user group the rights from the table above, and adds the

child site administrators to the user group. She then instructs the Configuration

Manager administrators at child sites to deploy the update list, using a specific

deployment template, to all of the client computers at their sites.

The child site administrator expands the Deployment Templates console tree node,

expands the Update Lists console tree node, and then drags the appropriate update

list to the appropriate deployment template. The child site administrator selects an

appropriate target collection, specifies the deployment schedule, and specifies

whether to enable NAP evaluation.

Using an Update List to Deploy Software Updates

The update list is used to open the Deploy Software Updates Wizard to create

software update deployments for the updates that are contained within the update


list. This provides an easy method for creating multiple deployments for the same set

of software updates without having to manually select the updates each time the

deployment is created. Update lists can also be used to add software updates to an

existing deployment.

The following methods open the Deploy Software Updates Wizard to create a new

deployment for the software updates in the update list:

■ Right-click the update list, and click Deploy Software Updates.

■ Drag the update list to an existing deployment template.

The following method opens the Deploy Software Updates Wizard and adds the

software updates in the update list to an existing deployment:

Drag the update list to an existing deployment.

Using Update Lists to Track Deployment State

Tracking the compliance state for the software updates in deployments is an

important task for Configuration Manager administrators. When deployments are

created without using update lists, it is very difficult to get the overall compliance

state for the same set of software updates that have been deployed using multiple

deployments. When update lists are used to create the deployments, you can run the

Compliance 1 - Update list overall report to get the overall compliance for the set of

software updates in the update list. You can also run the Compliance 3 - Update list

(per update) report to get a list of the software updates in the update list and the

overall compliance for each update. These reports provide another reason to use

update lists as part of the normal software updates administrator workflow.

Deployment Templates in Software Updates

Deployment templates in Configuration Manager 2007 store many of the software

update deployment properties, and they can be created for consistency and to save

time when creating deployments. Templates are created prior to deploying software

updates by running the Deployment Template Wizard, and they are configured with

the following deployment properties:

Table 19 Deployment Template Properties

Setting Description

Collection Specifies the collection that will be targeted for the software update deployment. This setting is optional when creating a deployment template.


Setting Description

Display/Time Settings

Specifies whether the user will be notified of pending software updates, the installation progress for software updates, whether a client evaluates the deployment schedule based on local or Coordinated Universal Time (UTC), and the default duration between software update availability and mandatory installation on clients.

Restart Settings

Specifies the system restart behavior when a software update installs on a client and requires a restart to complete.

Event Generation

Specifies whether Microsoft Operation Manager alerts are disabled while the software updates install and whether an Operation Manager alert is created when a software update installation fails.

Download Settings

Specifies how clients will interact with Distribution Points when they receive a software update deployment.

SMS 2003 Settings

Specifies whether to deploy software updates to SMS 2003 clients that are in the target collection.

The deployment properties can also be saved to a deployment template when

creating a deployment in the Deploy Software Updates Wizard. This allows the

template to be used in future deployments.

Strategy for Using Deployment Templates

Deployment templates store many of the deployment properties that might not

change from deployment to deployment, and they can save a lot of time for

administrators when creating software update deployments. Templates can be

created for different deployment scenarios in your environment. For example, you

can create a template for expedited software update deployments and planned

deployments. The template for the expedited deployment can suppress display

notifications on client computers, set the deadline for 0 days from the deployment

schedule, and allow system restarts outside of maintenance windows. The template

for a planned deployment can allow display notifications on client computers and set

the deadline for 14 days from the deployment schedule.

Pre-creating deployment templates for typical deployment scenarios in your

environment allows you to create deployments using templates that populate many

of the deployment properties that are most often static for the particular deployment

scenario. Using the deployment template also reduces the number of wizard pages in

the Deploy Software Updates Wizard by up to seven pages, which saves time and

helps to prevent mistakes when configuring the deployment.


Configuring a Collection in a Deployment Template

The collection setting in a deployment template is optional. Depending on your

deployment strategy, you might want to leave the collection setting blank. When

there are a lot of collections in your environment that will be used for deploying

software updates, you might want to leave the collection setting blank and configure

the collection when creating the deployment. When there are a few collections,

configuring the collection in the template might be desired.

Using Deployment Templates

The configured deployment properties that are defined in a deployment template are

used when creating a deployment. An update list or individually selected software

updates can be dragged-and-dropped onto an existing template to open the Deploy

Software Updates Wizard, or an existing template can be selected when in the wizard.

Drag-and-Drop to a Deployment Template

To start the Deploy Software Updates Wizard using a deployment template, you can

select either the update list that contains the software updates to deploy or the

individual software updates, and then drag-and-drop the update list to an existing

deployment template. This starts the Deploy Software Updates Wizard using the

configured deployment properties from the template.

Note

When starting the Deploy Software Updates Wizard using this method, the properties configured in the template are not displayed in the wizard and cannot be modified while creating the deployment. These properties can be modified after creating the deployment by going to the properties for the deployment.

Selecting a Template from the Deploy Software Updates Wizard

To use a deployment template when creating a deployment, navigate to the Deploy

Software Updates Wizard: Deployment Template Page of the Deploy Software Updates Wizard

and select from a list of previously created deployment templates. The deployment

properties contained in the highlighted template are displayed in the Details pane.

When an existing template is selected, the deployment properties configured in the

template are used and the associated wizard pages are not displayed.

Templates that Specify SMS 2003 Settings

When deployment templates are created with the Deploy software updates to

SMS 2003 clients setting enabled, the template will be available on the Deployment

Template page of the Deploy Software Updates Wizard only when all software

updates can be deployed to SMS 2003 clients. For example, if the software updates

that are being deployed all have a value of Yes for the Deployable to SMS2003

ms-its:C:\Documents%20and%20Settings\Reneeg\Desktop\SMSv4.chm::/html/2cba4983-105d-4c9c-86ee-1335d189467c.htm




setting, the Deploy Software Updates Wizard will show all templates regardless of

configured SMS 2003 settings. If the software updates that are being deployed have a

value of No for the Deployable to SMS 2003 setting, the Deploy Software Updates

Wizard will not show templates that have the SMS 2003 settings configured.

Deployment Packages in Software Updates

The deployment package is the vehicle used to download software updates to a

network shared folder and copy the software update source file to Distribution Points

defined in the deployment. Software updates can be downloaded and added to

deployment packages prior to deploying them by using the Download Updates

Wizard. This wizard provides administrators with the ability to provision software

updates on Distribution Points and verify that this part of the deployment process

was successful.

When downloaded software updates are deployed using the Deploy Software Updates

Wizard, the deployment automatically uses the deployment package that contains

each software update. When software updates that haven't been downloaded are

deployed, a new or existing deployment package must be specified in the Deploy

Software Updates Wizard and the updates are downloaded to the package when the

wizard completes.

Important

The network shared folder for the deployment package source files must be

manually created prior to specifying it in the wizard. Each deployment package must

use a different shared folder.

Deployment Packages Are Not Linked to Deployments

There is no hard link between a deployment and deployment package. Clients install

software updates in a deployment by using any Distribution Point that has the

software updates available, regardless of the deployment package. Even if a

deployment package is deleted for an active deployment, clients are still able to install

the software updates in the deployment as long as each update has been defined in at

least one other deployment package and is available on a Distribution Point

accessible from the client. When the last deployment package that contains a software

update is deleted, client computers will not be able to retrieve the update until the

software update is downloaded again to a deployment package.


Deployment Package Access Accounts

Deployment Package access accounts enable you to set permissions to specify users

and user groups that can access a deployment package folder on Distribution Points.

By default, Configuration Manager 2007 makes these folders available to all users. If

deployment packages contain sensitive data or should otherwise have restricted

access, you can configure deployment package access accounts to limit access to

specific users and user groups.

For each account, you specify the permissions that users and user groups can have.

The following table lists the permissions that can be specified.

Table 20 Account Permissions for SUM

Permission Description

No Access Prevents the account from reading, writing, or deleting files on the shared folder for the deployment package.

Read Enables the account to view and copy files, run programs, change folders within the shared folder, and read extended attributes of files. By default, Configuration Manager grants the Users and Guests generic accounts Read permission to the shared folder for the deployment package on Distribution Points.

Change Enables the account to change the contents and extended attributes of files and to delete files. Change permission is required for applications that need to write information back to the shared package folder on the Distribution Point.

Full Control Enables the account to write the contents and extended attributes of files, and to delete files. By default, the Administrators generic account has Full Control permission so that the Configuration Manager 2007 components can access the deployment package data.

The generic deployment package access accounts (Users, Guests, and Administrators)

are mapped to operating system-specific accounts, and the appropriate rights on each

operating system are applied to the deployment package folder on the Distribution

Point.

Choose an item.

If you remove the Administrators default account, Configuration Manager 2007

components cannot update and modify the deployment package data.


If a client computer does not have sufficient rights to the deployment package folder,

the software update will fail to install.

Deployment Package Distribution Points

Configuration Manager 2007 uses Distribution Points to store the files needed to

deploy software updates to client computers. To run a software update installation,

client computers must have access to at least one Distribution Point that contains the

update. Therefore, you should specify for each deployment package a group of

Distribution Points that can be accessed by all targeted clients.

You can have multiple Distribution Points in each site. By default, the site server is the

only site system used as a Distribution Point. To reduce the load on the site server,

additional Distribution Points should be configured at each site.

Selective Download

Configuration Manager 2007 client computers identify which targeted software

updates are applicable and retrieve only the files for required updates from the

deployment package contents that might contain both required and not required

software updates. This allows administrators to have multiple software updates in a

single deployment package and use the package in deployments that target client

computers that need only a subset of the deployment package contents.

Important

Selective download is not available on SMS 2003 clients. These clients download

the entire deployment package contents regardless of how many software updates

are applicable in the package. When creating SMS 2003 deployments, it is

recommended that you use deployment packages containing only the applicable

software updates for the client. Otherwise, unnecessary hard drive space is used on

the clients. Alternatively, SMS 2003 clients can be configured to install software

updates directly from the Distribution Point (run from network).

Removing Updates from a Deployment Package

Before removing software updates from a deployment package, you should verify that

the update is not part of an active software update deployment or that the update has

been downloaded to a different deployment package. When the last deployment

package that contains a software update is deleted, client computers will no longer be

able to retrieve the update until the software update is downloaded again to a

deployment package.


When deleting a software update from a deployment package, the Delete Updates

dialog box appears to allow you to cancel the process or confirm it and choose

whether to remove the update file from the Distribution Points configured for the

package. If the software update is in an active deployment and no other deployment

packages contain the update, the Software Update Deployment Deletion

Confirmation dialog box is displayed. When a NAP enabled software update is

deleted from a deployment package and no other deployment packages contain the

update, a warning dialog box is displayed.

When software updates are removed from a deployment package, the software

update no longer displays in the \Deployment Packages\<package

name>\Software Updates console tree node, the Downloaded property for the

software updates displays as "No" if the update is not downloaded to another

package, and the update file is removed from the deployment package source.

Deployments Containing Deleted Software Updates

When a software update is being removed from a deployment package, the update is

not in any other packages at the site, and the update is in an active deployment, client

computers will not be able to install the software update. Also, the icon for the

software update in the Configuration Manager console displays a red arrow and the

icon for the deployment that contains a software update that is missing content

displays a red double arrow.

Deleting a NAP Enabled Software Update from a Deployment Package

When a software update is being removed from a deployment package, the update is

not in any other packages at the site, and NAP evaluation has been enabled for the

software update, a warning appears with a confirmation to delete the software

update, and if accepted the NAP policy is deleted from the NAP Policies console tree

node, and then the NAP policy is tombstoned from the site server database.

Checking for Deployment Package Status

The Package Status console tree node in Configuration Manager 2007 displays

summary information about each package for each site to which the package is

targeted. The Package Status node displays under each deployment package and

provides information about the specific package or under the System Status console

tree node where is displays all packages and deployment packages. This behavior

allows you to easily verify that a deployment package has been successfully

provisioned on Distribution Points.


About Software Update Deployments

Software updates are delivered to client computers in Configuration Manager 2007

by creating software update deployments. The Deploy Software Updates Wizard is

used to create deployments and can be started by using several different methods.

Software Update Deployment Settings

When creating a software update deployment, the following settings are configured:

Table 21 Software Update Settings

Setting Description

General Specifies the name and description of the deployment.

* Collection Specifies the collection that will be targeted for the software update deployment.

* Display/Time Settings

Specifies whether the user will be notified of pending software updates, the installation progress for software updates, whether a client evaluates the deployment schedule based on local or Coordinated Universal Time (UTC), and the default duration between software update availability and mandatory installation on clients.

* Restart Settings

Specifies the system restart behavior when a software update installs on a client and requires a restart to complete.

* Event Generation

Specifies whether Microsoft Operation Manager alerts are disabled while the software updates install and whether an Operation Manager alert is created when a software update installation fails.

* Download Settings

Specifies how clients will interact with Distribution Points when they receive a software update deployment.

* SMS 2003 Settings

Specifies whether to deploy software updates to SMS 2003 clients that are in the target collection.

Deployment Package

Specifies the deployment package that will be used to host the software updates in the deployment. This setting is not available when all software updates in the deployment have already been downloaded to a package.

Download Location

Specifies whether the software updates in the deployment are downloaded from the Internet or from the local network.

Language Selection

Specifies the languages for which the software updates in the deployment are downloaded.

Deployment Schedule

Specifies the schedule for when a software update deployment becomes active, when software update installation is enforced on clients, whether to enable Wake On LAN, and whether to ignore maintenance windows when installing updates.


Setting Description

NAP Evaluation Specifies whether the software updates in this deployment will be included in a Network Access Protection (NAP) evaluation.

An asterisk (*) denotes the deployment properties that can be stored in a deployment template. An

existing deployment template can be selected at the start of the wizard to automatically populate these

properties. If a deployment template is not used when creating a deployment, the properties are

manually entered and can optionally be saved as a deployment template within the wizard and used in

future deployments.

Deployment Package Setting

The deployment package properties are not displayed when all software updates in

the deployment have previously been downloaded and copied to a package shared

folder on the Distribution Point. When previously downloaded, the deployment is

automatically configured to use the package that hosts the downloaded software

updates.

Deployment Deadline

When creating a software update deployment in the Deploy Software Updates

Wizard, the Deployment Schedule page allows a deployment deadline date and time

to be configured. Deployment deadlines can also be configured from the Deployment

Schedule tab in the properties for the deployment.

Setting a deadline makes the deployment mandatory, and it enforces the software

update installation on client computers by the configured date and time. If the

deadline is reached and the software update deployment has not yet run on the client

computer, the installation starts automatically whether or not a user is logged on to

the computer. A system restart can be enforced if it is necessary for the software

update installation to complete.

On client computers, display notifications will appear that inform the user that one or

more software updates are ready to install and the date for the earliest deadline time

displays. For example, if there are two deployments with deadlines that are two days

apart, the deployment deadline that comes first displays in the notifications to users.

Once the software updates have been installed for the deployment with the earliest

deadline, the client computer will continue to receive notifications, but the deadline

will now display the deadline for the second deployment.

In SMS 2003, deadlines were set to occur x days after the client received the policy to

install the software updates. Deployment deadlines have been simplified in

Configuration Manager 2007 and are now configured for an explicit date and time.


SMS 2003 clients in the Configuration Manager hierarchy will also use the configured

deadline date and time for deployments targeted to them.

NAP Evaluation Setting

The NAP evaluation page of the Deploy Software Updates Wizard does not display

unless NAP is configured for the site.

License Terms for Software Updates

When a software update has an associated Microsoft Software License Terms and the

License Terms has not yet been accepted, the Review/Accept License Terms Dialog Box

displays before opening the Deploy Software Updates Wizard. Once the License

Terms for a software update has been accepted, the wizard opens and the software

updates can be deployed. Future deployments for the software update will not

require license terms acceptance. When the license terms are declined, the process is

cancelled.

Software Update Deployment Process

The compliance assessment data is used to determine which software updates are

required on client computers. When you are creating a software update deployment

in the Deploy Software Updates Wizard, the software updates in the deployment are

downloaded from the location specified on the Download Location page of the

wizard to the configured package source, if not previously downloaded. When the

wizard completes, a deployment policy is added to the machine policy for the site.

The software updates are then copied from the package source to the configured

shared folders on the Distribution Points defined in the package, where they are

available for client computers.

When a client computer in the target collection for the deployment receives the

machine policy, a software update client component initiates an evaluation scan.

Software updates that are still required on the client are added to a class in Windows

Management Instrumentation. The software updates in mandatory deployments are

downloaded as soon as possible from the Distribution Point to the local cache on the

client computer. The software updates in optional deployments are not downloaded

until installation is manually initiated. If a deadline is added to an optional

deployment, making it a mandatory deployment, client computers will download the

software updates in the deployment as soon as they are made aware of the change.

ms-its:C:\Documents%20and%20Settings\Reneeg\Desktop\SMSv4.chm::/html/d4518d8f-42ce-4272-8d21-0610d11dbc10.htm


Note

In Configuration Manager 2007, software updates are always downloaded to the local cache and then installed. Systems Management Server 2003 clients have an option to run the software updates installation directly from a Distribution Point.

If the client is unable to retrieve the location for the Distribution Point through

Location Services, the client will retry for up to five days before failing. If the client is

unable to connect to the Distribution Point to download the content or the download

fails, the client will retry for up to 10 days before failing. When updates are manually

initiated, the client retry intervals are 1 hour per Distribution Point with a four-hour

maximum before the request fails.

When software updates that have a configured deadline become available on a client

computer, the Available Software Updates icon appears in the notification area that

informs the user of the pending deadline. Display notifications are presented on a

periodic basis until all pending mandatory software update installations have

completed. By default, they are displayed every three hours for deadlines more than

24 hours away, every hour for deadlines less than 24 hours away, and every 15

minutes for deadlines that are less than one hour away.

Note

There is a site-wide setting available that hides deployments from client

computers. If this setting is enabled, display notifications, notification area icons, and

software update installation progress dialog boxes are not displayed. Only software

updates from mandatory deployments can be run on client computers.

Unless deployments are configured to be hidden, users can open the

Express/Advanced dialog box to initiate installation for all mandatory software

updates. Or they can open the Available Software Updates dialog box, where they

can choose to install either mandatory or optional software updates.

When the configured deadline passes on mandatory software updates, a scan is

initiated to verify that the software update is still required, the local cache on the

client computer is checked to verify that the software update source file is still

available, and then the software update installation is initiated. When the installation

completes, it is verified that the software update is no longer required and a state

message is sent to the Management Point that indicates that the update is now

installed.


Required System Restart

By default, when software updates from a mandatory deployment have installed on a

client computer but a system restart is required for the installation to complete, the

system restart will be initiated. For software updates that have been installed prior to

the deadline, the automatic system restart will be postponed until the deadline,

unless the computer is restarted prior to that for some other reason.

The system restart can be suppressed for servers and workstations. These settings

are configured in the Restart Settings page of the Deploy Software Updates Wizard

when creating a deployment and in the Restart Settings tab in the deployment

properties. This setting can also be configured in a deployment template.

Deployment Reevaluation Cycle

Client computers initiate a deployment reevaluation cycle every 2 hours, by default.

During this evaluation cycle, the client computer scans for software updates that have

been previously deployed and installed. If any are missing, the software updates are

reinstalled from the local cache. If a software update is no longer available in the local

cache, it is downloaded from a Distribution Point and then installed. The reevaluation

cycle is configured on the Deployment Re-Evaluation tab of the Software Updates

Client Agent Properties page.

Deployment Packages

Deployment packages are not hard-linked to deployments. When client computers

receive a new deployment, they will use the software update source files from any

Distribution Point that has them, even from a deployment package and Distribution

Point that was not configured in the deployment

Managing Deployment Collections

When you are creating a deployment in the Deploy Software Updates Wizard, the

software updates are deployed to the members of the specified target collection. Prior

to creating a new deployment, you might want to create a new collection that

contains client computers that require particular software updates.

Caution!

When a collection that is used in a deployment is deleted, the software update

deployment is deleted as well. Do not delete collections that are used in active

deployments.

About the Software Updates End User Experience

When software update deployments target client computers and software updates

are available for installation, you can configure the end-user experience for what is

displayed and how software updates are received and installed.


Client Computer Machine Policy Polling Interval

When software updates are deployed to client computers, the software update

deployment information is added to the Configuration Manager machine policy, and

the client computer becomes aware of the deployment on the next Machine Policy

Retrieval & Evaluation Cycle configured on the General tab of the Computer Client

Agent Properties. The default setting is every 60 minutes.

Mandatory Software Updates

When a client receives a software update deployment policy with a configured

deadline, it downloads the required software updates and stores them in the local

cache. The client will run software update installation from the local cache when the

deadline is reached or the installation is initiated manually from the Available

Software Updates dialog box. If the software update no longer exists in the local

cache at the time of install, it will be downloaded again from the Distribution Point

and then installed.

When new software updates that have a configured deadline are available, a display

notification is presented to users that informs them of the pending deadline. Display

notifications are presented on a periodic basis until all pending mandatory software

update installations have completed. By default, they display every 3 hours for

deadlines more than 24 hours away, every hour for deadlines less than 24 hours

away, and every 15 minutes for deadlines that are less than 1 hour away.

When there is a maintenance window configured for the client computer, the

software update installation will be initiated after the deadline at the first available

maintenance window.

Pending System Restarts

When there are software update installations that have run and require a restart for

them to complete, new software updates that become available are not shown and the

notification area icon will not be visible. A system restart will be forced on client

computers when mandatory software updates have a pending restart and the

deadline has been reached.

Optional Software Updates

When a client computer receives a software update deployment policy without an

assigned deadline (optional deployment), it does not immediately download the

optional software updates. The optional software updates are displayed in the

Available Software Updates dialog box after the client computer receives the

machine policy for the deployment. At the time of installation, optional software

ms-its:C:\Documents%20and%20Settings\Reneeg\Desktop\SMSv4.chm::/html/68a726ec-845a-4f45-888c-f4298bd06e43.htm




updates are downloaded to the local cache on the client computer and then installed

locally. There are no display notifications presented for optional software updates.

Note

When the site-wide setting is enabled to hide deployments, the end user will not be able to install optional software updates.

Scheduling Software Update Installation

Mandatory software updates can be installed on client computers using a configured

schedule. This provides the ability to initiate software update installation at a

convenient time and install mandatory updates prior to the configured deadline. At

the scheduled time, all software updates from mandatory deployments will install.

The Install required updates on a schedule setting is on the Updates tab in the

Configuration Manager Properties that is opened from the Control Panel on client

computers.

Selecting Software Updates to Install

When new software updates are available, the user is notified by a display

notification and a notification area icon. When the user double-clicks on the display

notification or right-clicks on the notification area icon, a different dialog box is

presented for the following conditions.

Mandatory Software Updates Are Available

If any of the available software updates are mandatory, a dialog box is presented

asking the user how he or she would like to install the software updates. The user has

the option to select Express Install or Custom Install.

Express Install: Opens the Required Software Updates dialog box displaying only

the mandatory software updates, initiates software update installation for each

update, and minimizes the dialog box that displays installation progress for each

update. The user cannot initiate any action in the dialog box, and closing it will not

affect the software updates installation.

Custom Install: Opens the Available Software Updates dialog box with all

mandatory software updates selected and optional software updates listed but not

selected. The user chooses which software updates to install. Even though the

mandatory software updates are selected by default, the user has the option to

deselect them and install them at a later time.


Only Optional Software Updates Are Available

If only optional software updates are available, the Available Software Updates

dialog box is displayed. All available optional software updates are listed. No software

updates are selected by default.

Installation Progress

During a software update installation, the Software Updates Installation Progress

dialog box shows the Installation Progress for the selected updates. There are three

states for software update installation:

1. Preparing for download: The client computer is scanned to make sure the

software update is still applicable.

2. Downloading: The software update is downloaded from the Distribution Point

to the client's local cache, if required.

3. Installing: The software update installation is in progress. When the installation

completes, a verification scan is initiated to ensure the software updates have

successfully installed.

When a software update successfully installs, it no longer appears in the Available

Software Updates dialog box.

Typically, three operational scenarios are available for software updates in

Configuration Manager 2007:

■ Phased deployment : Refers to a mandatory deployment that is created as part

of a routine administrative task and usually contains software updates that are

not of an urgent nature and must be installed on client computers by a configured

future deadline.

■ Expedited deployment : Refers to a mandatory deployment that is created

unexpectedly and usually contains software updates that fix potential

vulnerabilities (zero-day exploit) and must be deployed to client computers as

soon as possible.

■ Optional deployment : Refers to a deployment that contains optional software

updates that might or might not be required on client computers and are not

urgent in nature.

The Inventory Tool for Microsoft Updates

The Inventory Tool for Microsoft Updates in Configuration Manager 2007 provides

backward compatibility for Systems Management Server (SMS) 2003 clients to scan


for software updates compliance using the Microsoft Update catalog. During the

SMS 2003 site upgrade to Configuration Manager 2007, Setup detects whether a

previous version of the Inventory Tool for Microsoft Updates is installed on the site

and whether the site is the highest in the hierarchy. If both are true, Setup initiates a

silent upgrade for the inventory tool on the site server. After the Inventory Tool for

Microsoft Updates is upgraded on the site, the catalog will be synchronized with the

latest Microsoft Updates catalog, the new scan package will be updated, and client

computers will upgrade the scan tool following their next Machine Policy Retrieval &

Evaluation Cycle. Software updates will be scanned for compliance using the

Microsoft Update catalog and will continue to work on SMS 2003 and Configuration

Manager 2007 client computers.

After the site server synchronizes with the software update point and Configuration

Manager client computers scan for software updates compliance, the Inventory Tool

for Microsoft Updates is no longer required for Configuration Manager client

computers, and it is recommended that the Microsoft Update Tool advertisement no

longer targets these client computers. When all client computers in the hierarchy

have been upgraded to Configuration Manager 2007, the Inventory Tool for Microsoft

Updates can be removed from the site server.

Product Documentation

The Deployment Guide for the Configuration Manager Inventory Tool for Microsoft

Updates is available in the help file for the tool. The help file includes introductory

topics, such as overviews of features and concepts, as well as procedures and

technical reference information.

You can access the help file using one of the following methods:

■ If you have not installed the Inventory Tool for Microsoft Updates yet, you can

locate the file ITMU_CM07.chm under the Configuration Manager 2007 product

DVD, in SMSSETUP\HELP. You can also copy the ITMU_CM07.chm file to any

convenient location and run it locally, without installing the tool.

■ If you have installed the Inventory Tool for Microsoft Updates, you can access the

help file in %windir%\Help.

System Center Updates Publisher

The System Center Updates Publisher has been built on the custom updates

framework that was introduced in Systems Management Server 2003 R2. Updates

Publisher is a stand-alone tool that enables independent software vendors or line-of-

business application developers to import software update catalogs, create and


modify software update definitions, export update definitions to catalogs, and publish

software updates information to a configured Windows Server Update Services

(WSUS) server. By using Updates Publisher to define software updates and publish

them to the WSUS server, software updates in Configuration Manager 2007 is able to

synchronize the custom updates from the WSUS server database to the site server

database, enable client computers to scan for custom update compliance, and provide

administrators the ability to deploy the custom updates to client computers.

For more information about Updates Publisher, visit the System Center Updates

Publisher Web site (http://go.microsoft.com/fwlink/?LinkId=83534). The product

documentation provides information that will help you to plan, deploy, operate, and

troubleshoot System Center Updates Publisher.

Product Documentation

Comprehensive information about Updates Publisher is available in the Updates

Publisher help file. The help file includes both introductory topics such as an

overviews of features and concepts, as well as in-depth technical discussions and

technical reference information.

There are several ways to access the Updates Publisher help file:

■ If you have not installed Updates Publisher yet, you can locate the file

SC_UpdatesPublisher.chm under the Configuration Manager 2007 product DVD,

in <DVD Drive>\SCUP. You can also copy the SC_UpdatesPublisher.chm file to any

convenient location and run it locally, without installing Updates Publisher.

If you have installed Updates Publisher, you can access the help file in the Updates

Publisher console by pressing F1, by clicking Help buttons, selecting Help from the

Action menu, or by clicking some hyperlinks. After Updates Publisher is installed, the

SC_UpdatesPublisher.chm file is available in %ProgramFiles%\System Center

Updates Publisher\Help, by default.

The System Center Updates Publisher content is available on the System Center

Updates Publisher Web site (http://go.microsoft.com/fwlink/?LinkId=83449).

Determine the Software Update Point Infrastructure

This section will help you determine what Configuration Manager sites must have an

active software update point, which sites should have an active Internet-based

software update point, and when a Network Load Balancing (NLB) cluster should be

configured to be the active software update point.




Active Software Update Point

■ The central site server is the primary site server at the top of the Configuration

Manager hierarchy. An active software update point is configured on the central

site so that software updates can be centrally managed and monitored. Most of

the software updates synchronization settings are configured at the central site

and propagated downward to sites throughout the hierarchy. The active software

update point on the central site synchronizes with Microsoft Update.

■ All primary sites in the Configuration Manager hierarchy must have an active

software update point. The child site synchronizes with the active software

update point configured for the parent site. Secondary site servers can be

configured with an active software update point, or client computers at the

secondary site can connect directly to the active software update point on the

parent primary site.

■ When the site is in native mode, the active software update point can be

configured to accept connections from both client computers on the intranet and

Internet or from only clients on the intranet. When Internet-based client

computer connectivity is not accepted on the active software update point, an

active Internet-based software update point can be created.

Internet-Based Software Update Point

■ When a site server is in native mode, you have an option to create an Internet-

based software update point that allows connectivity from Internet-based client

computers. This site system server role must be assigned to a site system server

that is remote to the site server and active software update point. When there are

Internet-based client computers assigned to a site and the active software update

point has been configured not to accept connections from Internet-based client

computers or access to the site server is not possible, you must configure an

active Internet-based software update point.

When the active Internet-based software update point does not have connectivity to the active

software update point for the site, you must use the export and import function of the WSUSUtil

tool to synchronize the software update metadata.

NLB Cluster Configured as an Active Software Update Point

Using NLB provides enhanced scalability and availability for server applications.

When there are more than 25,000 client computers that will connect to WSUS on the

active software update point site system server, an NLB cluster must be configured on

the WSUS server and then configured for the Configuration Manager 2007 site so that

the NLB cluster is used as the active software update point. When configuring the

NLB cluster, there are several steps that must be taken.


Figure 2. Software Update Point Installation – Mixed Mode

Install the WSUS 3.0 Administration Console on the site system server computer if WSUS 3.0 or the WSUS 3.0 Administration Console is not already installed.

Install WSUS 3.0 on the computer that will host the active software update point.

Determine which computer will host the active software update point for this site.

Is the computer remote from the site server?

No

Create the site system server on the computer, if not already created. Add the software update point site system role, and then configure the active software update point settings.

Will the active software update point communicate using SSL?

Configure WSUS for SSL on the computer that will host the active software update point.

Yes

Software update point installation complete.

Yes

No


Figure 3. Software Update Point Installation - Native Mode


Will there be an active Internet-based software update point?

Determine which computer will host the active software update point for this site.

Determine which computer will host the active Internet-based software update point for this site.

Determine if an active Internet-based software update point should be created to accept communication from Internet-based client computers.

Install the WSUS 3.0 Administration Console on the site server computer if WSUS 3.0 or the WSUS 3.0 Administration Console is not already installed.

Create the site system server, if not already created. Add the software update point role, but do not configure it as the active software update point.

Is the computer remote from the site server?

Create the site system server on the computer, if not already created. Add the software update point site system role, and then configure the active software update point settings.

Install WSUS 3.0 on the computer that will host the active software update point.

Configure WSUS for SSL on the computer that will host the active Internet-based software update point.

No

Configure WSUS for SSL on the computer that will host the active software update point.

Install WSUS 3.0 on the computer that will host the active Internet-based software update point.

Configure the active Internet-based software update point in Software Update Point Component Properties.

Software update point installation complete.

No

Yes

Yes

Planning for the Software Update Point Settings

The software update point in Configuration Manager 2007 is a required component of

software updates and is installed as a site system role in the Configuration Manager

console. The software update point site system role must be created on a site system

server that has Windows Server Update Services (WSUS) 3.0 installed and that

interacts with the WSUS components to configure update settings, to request

synchronization to the upstream update server, and to synchronize the updates from

the WSUS database to the site server database.


The software update point settings configure which site system server is the active

software update point, which site system server is the active Internet-based software

update point if one is specified at the site, the synchronization source,

synchronization schedule, and the products, classifications, and languages for which

software updates will be synchronized.


General Settings

The general settings in the New Site Role Wizard and Software Update Point

Component properties specify whether the active software update point is a local

server or a remote server, or whether it uses a Network Load Balancing (NLB)

cluster. These settings also specify which port settings are used for connectivity to the

site system server that is assigned the software update point role, whether a Software

Update Point Connection account should be used instead of the computer account

when the site server connects to the WSUS components on the site system server,

whether Internet-based clients are allowed to connect to the software update point

when the site is in native mode, and whether Secure Sockets Layer (SSL) is used when

synchronizing data from the active software update point and when clients connect to

the WSUS server on the active software update point.

When the site is in native mode, the active software update point is configured to

accept communication only from client computers on the intranet, and there are

Internet-based client computers assigned to the site, you must follow a specific

procedure to install and configure an active Internet-based software update point.

Internet-Based Settings

When the Configuration Manager 2007 site server is in native mode and the active

software update point is configured with Do not allow access from Internet-based

clients, a software update point site system role must be created (not configured as

the active software update point), and then you must configure the software update

point site system server to be the active Internet-based software update point on the

Internet-Based tab in the Software Update Point Component Properties dialog

box. You can specify whether the active Internet-based software update point is a

remote server or uses NLB, which port settings are used for connectivity to the

software update point server, whether a Software Update Point Connection account

should be used instead of the computer account when the site server connects to the

WSUS components on the site system server, and whether the Internet-based

software update point should synchronize with the active software update point for

the site. If synchronization is not configured, the export and import function for the

WSUSUtil tool must be used to synchronize software update metadata.

Synchronization Settings

The synchronization settings for the active software update point specify the

synchronization source and whether WSUS reporting events are created during the

synchronization process.

■ Synchronization Source: The synchronization source for the active software

update point at the central site is configured to use Microsoft Update. The active

software update points on child sites are automatically configured to use the

active software update point on its parent site as the synchronization source.


When there is an active Internet-based software update point, the active software

update point for the site is automatically configured to be the synchronization

source. Optionally, the active software update point or active Internet-based

software update point can be configured not to synchronize with the configured

synchronization source, but instead use the export and import function of the

WSUSUtil tool. WSUS Reporting Events: The Windows Update Agent on client

computers can create event messages that are used for WSUS reporting. These

events are not used in Configuration Manager 2007 software updates, and

therefore, the Do not create WSUS reporting events setting is selected by

default. When these events are not created, the only time the client computer

should connect to the WSUS server is during software update evaluation and

compliance scans. If these events are needed for reporting outside of software

updates in Configuration Manager 2007, you will need to modify this setting to

create WSUS status reporting events or create all WSUS reporting events

depending on your needs.

Synchronization Schedule

The synchronization schedule can be configured only at the active software update

point on the central site. When the synchronization schedule is configured, the active

software update point on the central site will initiate synchronization with Microsoft

Update at the scheduled date and time. The custom schedule allows you to

synchronize software updates on a date and time when the demands from the WSUS

server, site server, and network are low, such as every week at 2:00 AM.

Alternatively, synchronization can be initiated on the central site by using the Run

Synchronization action from the Update Repository in the Configuration Manager

console tree node.

After the active software update point has successfully synchronized with Microsoft

Update, a synchronization request is sent to the active Internet-based software

update point, if installed, and to the active software update point on any child sites.

The process is repeated on every site in the hierarchy.

Update Classifications

Every software update is defined with an update classification that helps to organize

the different types of updates. During the synchronization process, the software

updates metadata for the specified classifications will be synchronized. Configuration

Manager 2007 provides the ability to synchronize software updates with the

following update classifications:

■ Critical Updates: Specifies a broadly released update for a specific problem that

addresses a critical, non security-related bug.

■ Definition Updates: Specifies an update to virus or other definition files.


■ Drivers: Specifies an update to software components designed to support

hardware.

■ Feature Packs: Specifies new product features that are distributed outside of a

product release and typically included in the next full product release.

■ Security Updates: Specifies a broadly released update for a product-specific,

security-related issue.

■ Service Packs: Specifies a cumulative set of hotfixes that are applied to an

application. These hotfixes can include security updates, critical updates,

software updates, and so on.

■ Tools: Specifies a utility or feature that helps to complete one or more tasks.

■ Update Rollups: Specifies a cumulative set of hotfixes that are packaged together

for easy deployment. These hotfixes can include security updates, critical

updates, updates, and so on. An update rollup generally addresses a specific area,

such as security or a product component.

■ Updates: Specifies an update to an application or file currently installed.

The update classification settings are configured only on the active software update

point highest in the Configuration Manager hierarchy, which is most often the central

site server. The update classification settings are not configured on the active

software update point and active Internet-based software update point, if configured,

on child sites because they synchronize the metadata from the upstream

synchronization source using the update classification settings from the central site.

When selecting the update classifications, be aware that the more classifications that

are selected, the longer it takes to synchronize the software updates metadata.

Products

The metadata for each software update defines what product or products for which

the update is applicable. A product is a specific edition of an operating system or

application, for example, Microsoft Windows Server 2003. A product family is the

base operating system or application from which the individual products are derived.

An example of a product family is Microsoft Windows, of which Microsoft Windows

Server 2003 is a member. You can specify a product family or individual products

within a product family.

When software updates are applicable to multiple products, and at least one of the

products has been selected for synchronization, all of the products will appear in the

Configuration Manager console even if some have not been selected. For example, if

Windows Server 2003 is the only operating system that you have subscribed to, and if

a software update applies to Windows Server 2003 and Windows Server 2003


Datacenter Edition, both products will show up in the Configuration Manager

repository.

The product settings are configured only on the active software update point highest

in the Configuration Manager hierarchy, which is most often the central site server.

The product settings are not configured on the active software update point and

active Internet-based software update point, if configured, on child sites because they

synchronize the metadata from the upstream synchronization source using the

product settings from the central site. When selecting the products, be aware that the

more products that are selected, the longer it takes to synchronize the software

updates metadata.

Languages

The language settings for the software update point allow you to configure the

languages for which the summary details (software updates metadata) will be

synchronized for a software update and the update file languages that will be

downloaded for the software update.

Note

In Systems Management Server (SMS) 2003, the download.ini file stored the configuration settings for the languages that were used. The download.ini file is no longer used when synchronizing software updates.

Update File

The languages configured for the update file setting provide the default set of

languages that will be available when downloading software updates at the site.

When on the Language Selection page of the Deploy Software Updates Wizard or

Download Software Updates Wizard, the languages configured for the active software

update point are automatically selected, but can be modified each time updates are

downloaded or deployed. When the wizard completes, the software update files for

the configured languages are downloaded, if update files are available in the selected

language, to the deployment package source location and copied to the Distribution

Points configured for the package.

The update file language settings should be configured with the languages that are

most often used in your environment. For example, if client computers in the site use

mostly English and Japanese languages for the operating system or applications, and

there are very few other languages used at the site, select English and Japanese in the

Update File column and clear the other languages. This allows you to most often use

the default settings on the Language Selection page of the wizards and also prevents

unneeded update files from being downloaded. This setting is configured at each

software update point in the Configuration Manager 2007 hierarchy.


Summary Details

During the synchronization process, the summary details information (software

updates metadata) is updated for the software updates in the languages specified.

The metadata provides the information about the software update, such as name,

description, products that the update supports, update classification, article ID,

download URL, applicability rules, and so on.

The summary details settings are configured only on the active software update point

on the central site server. The active software update point and Internet-based

software update point, if configured, on child sites synchronize the software updates

metadata from the upstream synchronization source for the languages configured at

the central site. When selecting the summary details languages, you should select

only the languages needed in your environment. The more languages that are

selected, the longer it takes to synchronize the software updates metadata. The

software updates metadata is displayed in the locale of the operating system where

the Configuration Manager console is running. If the localized properties for the

software updates are not available, the information displays in English.

Important

It is very important that you select all of the summary details languages that will be needed in your Configuration Manager hierarchy. When the active software update point on the central site is synchronized, the selected summary details languages determine what software updates metadata is retrieved. If the summary details languages are modified after the synchronization has run at least one time, the metadata is retrieved for the modified summary details languages for only new or updated software updates. The software updates that have already been synchronized will not retrieve metadata for different languages unless there is a change to the update on Microsoft Update.

Using Active WSUS Servers for the Active Software Update Point

You can use a WSUS server that was active in your environment before installing Configuration Manager

2007. When the active software update point or active Internet-based software update point is

configured, the synchronization settings are specified. A component of the software update point then

configures the WSUS server with the same settings. When the WSUS server was previously synchronized

with products or classifications that were not configured as part of the active software update point

settings, the software updates metadata for the products and classifications will be synchronized for all

of the software updates metadata from the WSUS server regardless of the synchronization settings for

the active software update point. This might result in metadata for products or classifications that is

unexpected. You will experience the same behavior when adding products or classifications directly in

the WSUS Administration console of the active software update point.


Using the Software Updates Reports

The predefined software updates reports and underlying software updates SQL

Server views have been modified in Configuration Manager 2007 to work with the

new software updates infrastructure. Existing views from SMS 2003 will mostly work,

but you should use the Configuration Manager views when creating or modifying

reports.

During a site upgrade, the SMS 2003 reports are migrated, but they are deprecated

and might fail to run or retrieve the expected data. You should not use the SMS 2003

software updates reports. Several new reports have been created to support software

updates in Configuration Manager and are grouped in the following categories:

■ Software Updates - A. Compliance

■ Software Updates - B. Deployment Management

■ Software Updates - C. Deployment States

■ Software Updates - D. Scan

■ Software Updates - E. Troubleshooting

■ Software Updates - F. Distribution Status

The Configuration Manager 2007 software updates reports should be the only ones

used to retrieve software updates data. When there are customized SMS 2003 reports

that have been created on the site, it is recommended that a similar Configuration

Manager report should be customized or a new report should be created to retrieve

the desired data.

The following section lists information about each of the reports contained in these

six categories.

Software Updates - A. Compliance

The reports in the Software Updates - A. Compliance category provide the scan

results for software update compliance on client computers. More specifically, these

reports provide information about what software updates are required, installed, or

not required on clients. The following software updates reports are in this category:

■ Compliance 1 - Overall Compliance - This report returns the overall

compliance for the set of software updates in a specific update list and collection.

The Collection ID and Update List ID are required parameters. You can drill into

report "Compliance 8 - Computers in a specific compliance state for an update list

<secondary>" to view the computers in the compliance state.


■ Compliance 2 - Specific software update - This report returns the overall

compliance data for a specified software update. The Collection ID and Update

Title, Bulletin ID, or Article ID are required parameters. You can drill into report

"Compliance 7 - Specific software update states <secondary>" to view the count

and percentage of computers in each state for the update.

■ Compliance 3 - Update list (per update) - This report returns the overall

compliance data for software updates defined in an Update List. The Update List

ID and Collection ID parameters are required. You can drill into report



■ Compliance 4 - Deployment (per update) - This report returns the overall

compliance data for software updates defined in a deployment. The Deployment

ID and Collection ID parameters are required. You can drill into report



■ Compliance 5 -Updates by vendor/month/year - This report returns the

compliance data for software updates released by a vendor during a specific

month and year. The Collection ID, Vendor, and Year parameters are required. To

limit the amount of information returned, you can filter on the Update Class,

Product, or Month parameters. You can drill into report "Compliance 7 - Specific

software update states <secondary>" to view the count and percentage of

computers in each state for the update.

■ Compliance 6 - Specific computer - This report returns the software update

compliance data for a specific computer. The Computer Name parameter is

required. To limit the amount of information returned, you can filter on the

Vendor and Update Class parameters.

■ Compliance 7 - Specific software update states <secondary> - This report

returns the count and percentage of computers in each compliance state for the

specified software update. For best results, start with a compliance 2 - 5 report,

and then drill into this report to return the count of computers in each

compliance state. You can drill into report "Compliance 9 - Computers in a

specific compliance state for an update <secondary>" to view the computers in

the specific state for the update.

■ Compliance 8 - Computers in a specific compliance state for an update list

<secondary> - This report returns all computers that have a specific compliance

state for the set of software updates in an update list. For best results, start with

"Compliance 1 - Overall Compliance" to return the count of computers in each

compliance state, and then drill into this report to return the computers in the


selected compliance state. You can drill into report "Compliance 6 - Specific

computer" to view the compliance data for the computer.

■ Compliance 9 - Computers in a specific compliance state for an update - This

report returns all computers in a specific compliance state for a software update.

For best results, start with a compliance 2 - 5 report, drill into "Compliance 7 -

Specific software update states <secondary>" to return the count of computers in

each compliance state, and then drill into this report to return the computers in

the selected compliance state. You can drill into report "Compliance 6 - Specific

computer" to view the compliance data for the computer.

Software Updates - B. Deployment Management

The reports in the Software Updates - B. Deployment Management category provide

information about the software update deployments. The following software updates

reports are in this category:

■ Management 1 - Updates required but not deployed - This report returns all

vendor-specific software updates that have been detected as required on clients

but that have not been deployed to a specific collection. The Collection ID and

Vendor parameters are required. To limit the amount of information returned,

you can specify the software update class.

■ Management 2 - Updates in a deployment - This report returns the software

updates that are contained in a specific deployment. The Deployment ID

parameter is required. For each software update, you can drill down to report

"States 5 - States for an update in a deployment <secondary>" to view the states

for the specific software update.

■ Management 3 - Deployments that target a collection - This report returns the

deployments that have targeted a specific collection. The Collection ID parameter

is required. You can drill down to report "Management 2 - Updates in a

deployment" to view the software updates in the selected deployment.

■ Management 4 - Deployments that target a computer - This report returns the

deployments that have targeted a specific computer. The Computer Name

parameter is required. You can drill down to report "Management 2 - Updates in

a deployment" to view the software updates in the selected deployment.

■ Management 5 - Deployments that contain a specific update - This report

returns the deployments that contain a specific software update. The Update

parameter is required. You can drill down to report "Management 2 - Updates in

a deployment" to view the software updates in the selected deployment.


■ Management 6 - Deployments that contain an update list - This report

returns the deployments that were created using a specific update list. The

Update List ID parameter is required. You can drill down to report

"Management 2 - Updates in a deployment" to view the software updates in the

selected deployment.

■ Management 7 - Updates in a deployment missing content - This report

returns the software updates in a specified deployment that do not have all the

associated content retrieved, preventing clients from installing the update and

achieving 100% compliance for the deployment. The Deployment ID parameter is

required. You can drill down to report "Management 8 - Computers missing

content <secondary>" to view the computers that require the software update

files.

■ Management 8 - Computers missing content <secondary> - This report

returns all computers that require a specific software update contained in a

specific deployment that is not provisioned on a Distribution Point. For best

results, start with "Management 7 - Updates in a deployment missing content" to

return all software updates in the deployment that do not have all the associated

content retrieved, and then drill into this report to return all computers that

require the software update.

Software Updates - C. Deployment States

The reports in the Software Updates - C. Deployment States category provide

information about the evaluation and enforcement states on client computers for

software update deployments. The following software updates reports are in this

category:

■ States 1 - Enforcement states for a deployment - This report returns the

enforcement states for a specific software update deployment, which is typically

the second phase of a deployment assessment. For the overall progress of the

software update installation, use this report in conjunction with "States 2 -

Evaluation states for a deployment." The Deployment ID parameter is required.

You can drill down to report "States 4 - Computers in a specific state for a

deployment <secondary>" to view all computers in the state.

■ States 2 - Evaluation states for a deployment - This report returns the

evaluation state for a specific software update deployment, which is typically the

first phase of a deployment assessment. For the overall progress of the software

update installation, use this report in conjunction with "States 1 - Enforcement

states for a deployment." The Deployment ID parameter is required. You can drill


down to report "States 4 - Computers in a specific state for a deployment

<secondary>" to view all computers in the state.

■ States 3 - States for a deployment and computer - This report returns the

states for all software updates in the specified deployment for a specified

computer. The Deployment ID and Computer Name parameters are required. You

can drill into the Status Message Details page for any software update that

contains an Error Record ID value.

■ States 4 - Computers in a specific state for a deployment <secondary> - This

report returns all computers in a specific state for a software update deployment.

For best results, start with "States 1 - Enforcement states for a deployment " or

"States 2 - Evaluation states for a deployment" to identify the states for the

deployment, and then drill into this report to return all computers in the specific

state. You can drill down to report "States 7 - Error status messages for a

computer <secondary>" to view the status messages for the computer.

■ States 5 - States for an update in a deployment <secondary> - This report

returns a summary of states for a specific software update targeted by a specific

deployment. For best results, start with "Management 2 - Updates in a

deployment" to return the software updates contained in a specific deployment,

and then drill into this report to return the state for the selected software update.

You can drill down to report "States 6 - Computers in a specific enforcement state

for an update <secondary>" to list the computers in the state.

■ States 6 - Computers in a specific enforcement state for an update

<secondary> - This report returns all computers in a specific enforcement state

for a specific software update. For best results, start with " Management 2 -

Updates in a deployment" to return the software updates contained in a specific

deployment, drill into "States 5 - States for an update in a deployment

<secondary>" to return the states for the selected software update, and then drill

into this report to return all computers in the selected state.

■ States 7 - Error status messages for a computer <secondary> - This report

returns all status messages for a given Update or Deployment on a specific

computer for a given status message. For best results, start with "States 1 -

Enforcement states for a deployment" or "States 2 - Evaluation states for a

deployment" to identify the states for the deployment, drill into "States 4 -

Computers in a specific state for a deployment <secondary>" to return all

computers in the specific state, and then drill into this report.


Software Updates - D. Scan

The reports in the Software Updates - D. Scan category provide information about

computers in a specific scan state. The following software updates reports are in this

category:

■ Scan 1 - Last scan states by collection - This report returns the count of

computers in each of the compliance scan states returned by client computers in

a specific collection during their last scan for software updates compliance. The

Update Source ID and Collection ID parameters are required. You can drill down

to report "Scan 3 - Clients of a collection reporting a specific state <secondary>"

to view the computers in a specific state.

■ Scan 2 - Last scan states by site - This report returns the count of computers in

each of the compliance scan states returned by client computers assigned to a

specific site during their last scan for software updates compliance. The Update

Source ID and Site Code parameters are required. You can drill down to report

"Scan 4 - Clients of a site reporting a specific state <secondary>" to view the

computers in a specific state.

■ Scan 3 - Clients of a collection reporting a specific state <secondary> - This

report returns the computers in a specific collection that returned a specific state

during their last scan for software updates compliance. For best results, start

with "Scan 1 - Last scan states by collection" to return the count of computers in

each scan state, and then drill into this report. You can drill down to report

"States 7 - Error status messages for a computer <secondary>" to view the status

messages for the computer.

■ Scan 4 - Clients of a site reporting a specific state <secondary> - This report

returns the computers assigned to a specific site that returned a specific state

during their last scan for software updates compliance. For best results, start

with "Scan 2 - Last scan states by site" to return the count of computers in each

scan state, and then drill into this report. You can drill down to report "States 7 -

Error status messages for a computer <secondary>" to view the status messages

for the computer.

Software Updates - E. Troubleshooting

The reports in the Software Updates - E. Troubleshooting category provide

information about scan and deployment errors that occur on client computers. The

following software updates reports are in this category:


Software Updates - F. Distribution Status

The reports in the Software Updates - F. Distribution Status category provide

distribution status data for SMS 2003 clients that are targeted in a software updates

deployment. The following software updates reports are in this category:

■ Distribution 1 - Advertisement Status for SMS 2003 clients - This report lists

all software distribution advertisements for the selected update. For each

advertisement, it also shows the advertisement state and count of machines in

that state. This report also covers additional advertisement states available for

software update advertisements. The Type and Update Title, Bulletin ID, or Article

ID parameters are required. You can drill down to report "Distribution 2 -

SMS 2003 clients with a specific update advertisement state" to view the

computers in the state.

■ Distribution 2 - SMS 2003 clients with a specific update advertisement state

- This report shows a list of computers that are in a specific state of an

advertisement. This report also covers additional advertisement states available

for software update advertisements. The Advertisement ID and Distribution Status

parameters are required. You can limit the results by specifying a value for the

Update Distribution Status parameter. You can drill down to report

"Advertisement status messages for a particular client and advertisement" to

shows the status messages reported for the computer and advertisement.

Planning for Software Updates Client Settings

The software updates client settings in Configuration Manager 2007 are site wide and

configured with default values. There are software updates client agent settings and

general settings that affect when software updates are scanned for compliance, and

how and when software updates are installed on client computers. The client settings

specific to software updates are configured within the Software Updates Client Agent

properties, the site-wide general settings that affect software updates are configured

within the Computer Client Agent properties, and the software updates installation

schedule can be configured from the Configuration Manager icon in the Control Panel

on the client computer. There are also Group Policy settings on the client computer

that might need to be configured depending on your environment.

Important

Before client computers can scan for software update compliance and before deployments can be created that target client computers, the software updates environment must be planned and configured.


Software Updates Client Agent Settings

The Software Updates Client Agent properties contain three tabs that provide

configuration settings to enable software updates and configure the software updates

settings on client computers. Use the following procedure to open the properties

dialog box.

To open the Software Updates Client Agent properties

1. In the Configuration Manager console of the primary site server, navigate to

System Center Configuration Manager / Site Database / Site Management /

<site code> - <site name> / Site Settings / Client Agents.

2. Right-click the Software Updates Client Agent, and then click Properties.

The following client settings are available in the Software Updates Client Agent

properties:

General Tab

Enable Software Updates on Clients

This setting specifies whether the Software Updates Client Agent is enabled or

disabled for the site. The Software Updates Client Agent is installed on Configuration

Manager 2007 clients by default. If the client agent is disabled, the client agent

components are put into a dormant state but not removed on clients. Existing

deployment policies will be removed from client computers when the client agent is

disabled. Re-enabling the Software Updates Client Agent initiates a policy to request

that the components on clients be enabled and the deployment metadata be

downloaded. The Software Updates Client Agent is configured on a site-by-site basis

and affects only clients assigned to that site. Disabling the Software Updates Client

Agent at a site prevents software update compliance assessment and software

updates from being deployed.

Scan schedule

This setting specifies how often the client computer initiates a scan for software

updates compliance. By default, a simple schedule is configured to run the scan for

compliance every 7 days and the site database is updated with any changes since the

last scan. The minimum value allowed for the scan schedule is 1 minute and the

maximum is 31 days. This setting is available to configure only after an active

software update point site role has been installed on a site system server for the site.


Note

When a custom schedule is selected, the actual start time on client computers is

the start time plus a random amount of time up to 2 hours. This prevents client

computers from initiating the scan and connecting to Windows Server Update

Services (WSUS) on the active software update point server at the same time.

Update Installation Tab

Enforce all mandatory deployments

This setting specifies whether to enforce all mandatory software update deployments

that have deadlines within a specified period of time. When a deadline is reached for a

mandatory software update deployment, installation is initiated on clients for the

updates defined in the deployment. This setting determines whether to also initiate

the installation for software updates defined in other mandatory deployments that

have a configured deadline within the specified period of time.

The benefit of this setting is that it expedites software update installation for

mandatory updates, might increase security, might decrease display notifications, and

might decrease system restarts on client computers. By default, this setting is not

enabled.

For deployment deadlines within

This setting specifies the timeframe for the Enforce all mandatory deployments

setting. The minimum value allowed is 1 to 23 hours and 1 to 365 days. By default,

this setting is configured for 7 days.

Hide all deployments from end users

This setting specifies that all deployments are hidden when they are received on

client computers. Use this setting to deploy software updates to computers with any

display notifications or notification area icons. By default, this setting is not enabled.

Important

When this setting is enabled, only software updates in mandatory deployments will be installed on client computers.

Deployment Re-Evaluation Tab

The setting on this tab configures how often the Software Updates Client Agent

reevaluates software updates for installation status. When software updates that

have been previously installed are no longer found on client computers and are still

required, they are reinstalled. The deployment reevaluation schedule should be

adjusted based on company policy for software update compliance, whether users

have the ability to uninstall software updates, and so on, and with the consideration

that every deployment reevaluation cycle results in some network and client


computer CPU activity. The minimum value allowed for the deployment reevaluation

schedule is 1 day and the maximum is 31 days. By default, a simple schedule is

configured to run deployment reevaluation every 7 days.

Note

When a custom schedule is selected, the actual start time on client computers is the start time plus a random amount of time up to 2 hours. This prevents client computers from initiating the scan and connecting to Windows Server Update Services (WSUS) on the active software update point server at the same time.

Computer Client Agent Settings

The Computer Client Agent properties contain four tabs that provide configuration

settings that affect the software updates reminders and the customization for

software update deployments on client computers. Use the following procedure to

open the properties dialog box.

To open the Computer Client Agent properties

1. In the Configuration Manager console of the primary site server, navigate to

System Center Configuration Manager / Site Database / Site Management /

<site code> - <site name> / Site Settings / Client Agents.

2. Right-click the Computer Client Agent, and then click Properties.

The following settings are applicable to software updates in the Computer Client

Agent properties:

General Tab

Interval

The Policy polling interval (minutes) setting specifies how often client computers

retrieve machine policy. This setting is relevant to software updates in that when new

deployments are created, the machine policy is updated with the deployment

information. Clients can take up to the Policy polling interval (minutes) value to

receive the deployment policy. The default value for this setting is 60 minutes.

State messages

The State message reporting cycle (minutes) specifies how often client computers

sent state messages to the Management Point. The software updates client creates

state messages for scan, software updates compliance, deployment evaluation, and

deployment enforcement. The default value for this setting is 5 minutes.


Customization Tab

Organization name

This setting specifies the name of the organization authoring the software update

installation. By default, the text box displays "IT Organization." The organization

name displays in software updates display notifications, the Available Software

Updates dialog box, and the restart countdown dialog box on clients that receive

deployed software updates. It is recommended that this setting be customized with

something more appropriate for your organization.

Software updates

This setting specifies an optional subheading used by software updates dialog boxes

on client computers. By default, the text box displays "Protecting your computer." The

software updates setting displays in the Available Software Updates and restart

countdown dialog boxes on client computers that receive deployed software updates.

Reminders Tab

The settings on this tab specify how often display notifications are displayed on client

computers when a deployment deadline is approaching for software updates. The

reminder intervals can be configured for when the deadline is greater than 24 hours,

when the deadline is less than 24 hours away, and when the deadline is less than an

hour away.

BITS Tab

The settings on this tab specify whether bandwidth throttling is configured for the

site. These settings apply to Configuration Manager client computers when they use

BITS to download software update files from Distribution Points.

Restart Tab

The settings on this tab configure the restart countdown timeframe and restart final

notification when a software update is installed on client computers and a restart is

required for it to complete. By default, the initial countdown is 5 minutes and a final

notification is displayed when there is 1 minute before the restart will be initiated.

Configuration Manager Property Settings

The Configuration Manager Properties dialog box provides software updates

actions and configuration settings. Use the following procedure to open the

properties dialog box.

To open the Configuration Manager properties

1. On a client computer, open the Control Panel.

2. Double-click the Configuration Management icon.


The following actions and settings are applicable to software updates in the

Configuration Manager properties:

Actions

The following actions are applicable to software updates:

■ Software Updates Deployment Evaluation Cycle: Evaluates active

deployments when this action is initiated.

■ Software Updates Scan Cycle: Scans for software updates compliance when this

action is initiated.

Updates Tab

The setting on this tab configures whether there is a schedule for installing software

updates that are required on the client computer. When this setting is not enabled,

mandatory software updates will be installed at the deadline date and time scheduled

by the Configuration Manager administrator or manually installed prior to the

deadline.

When this setting is enabled, it allows you to schedule software update installation at

a time that is convenient, for example, every day at 2 AM. When multiple users are

using a client computer and this setting is modified, the setting that was configured

last is used.

Install required updates on a schedule

This setting specifies whether required software updates that have been deployed to

this client computer will install on a specified schedule. When it is enabled, you can

specify a recurrence pattern of every day or a specific day of the week, and a specific

time. Local users and administrators can modify this setting.

Group Policy Settings

The following Group Policy settings are required for the Windows Update Agent

(WUA) on client computers to connect to WSUS on the active software updates point

and successfully scan for software update compliance.

Specify intranet Microsoft update service location

When the active software update point is created for a site, client computers receive a

machine policy that provides the active software update point server name and

configures the Specify intranet Microsoft update service location local policy on

the computer. The WUA retrieves the server name specified in the Set the intranet

update service for detecting updates setting, and then connects to this server when

it scans for software updates compliance. When a domain policy has been created for

the Specify intranet Microsoft update service location setting, it overrides the

local policy, and the WUA might connect to a server other than the active software


update point. If this happens, the client computer might scan for software update

compliance based on different products, classifications, and languages. It is

recommended that this domain policy not be configured for Configuration Manager

2007 client computers.

Allow signed content from intranet Microsoft update service location

Before the Windows Update Agent (WUA) 3.0 on computers will scan for updates that

were created and published with the System Center Updates Publisher, the Allow

signed content from intranet Microsoft update service location Group Policy

setting must be enabled. When the policy setting is enabled, WUA 3.0 will accept

updates received through an intranet location if the updates are signed in the Trusted

Publishers certificate store on the local computer.

Configure Automatic Updates

Automatic Updates allows security updates and other important downloads to be

received on client computers. Automatic Updates is configured through the

Configure Automatic Updates Group Policy setting or the Control Panel on the local

computer. When Automatic Updates is enabled, client computers will receive update

notifications and, depending on the configured settings, download and install

required updates. When Automatic Updates coexists with software updates, each

might display notification icons and popup display notifications for the same update.

Also, when a restart is required, each might display a restart dialog box for the same

update.

Self Update

During the Configuration Manager 2007 client installation the Windows Update Agent

(WUA) is installed on client computers if it is not already installed. When Automatic

Updates is enabled, the WUA on client computers automatically do a self update when

a newer version becomes available or when there are problems with the component.

When Automatic Updates is not configured or disabled, the WUA is installed during

client installation. However, if the WUA install failed, if a WUA component becomes

corrupt, or when a newer version of the WUA is available, a software distribution

must be created to update the agent on client computers. When the WUA fails on

client computers, the scan for software update compliance also fails.

Planning for Software Updates Server Settings

There are software updates settings and general site settings that have an impact on

software updates in Configuration Manager 2007. These settings configure the active

software update point and determine what updates are synchronized, whether there

are maintenance windows for installing updates, how much time software updates


have to complete, whether software updates are included in a Network Access

Protection (NAP) evaluation, and so on.

Important

Before client computers can scan for software update compliance and before deployments can be created that target client computers, the software updates environment must be planned and configured.


The software update point site system role is required before software updates can

be synchronized, assessed for compliance on clients, and deployed. Multiple site

system servers can have the software update point site system role, but only one site

system server can be configured as the active software update point. When the site is

in Native mode, an additional active Internet-based software update point can be

assigned to a remote site system server that allows communication from only

Internet-based client computers. Additionally, if the active software update point is

configured as a Network Load Balancing (NLB) cluster, a site system server with the

software update point site role should be created for each server in the NLB cluster.

Planning for Maintenance Windows

Maintenance windows provide administrators with a way to define a period of time

that limits when changes can be made on the systems that are members of a

collection. Maintenance windows restrict when the software updates in deployments

can be installed on client computers, as well as operating system advertisements and

software distribution advertisements.

Client computers determine whether there is enough time to start a software update

installation by using the following three settings:

■ Restart countdown: Specifies the length of the client restart notification (in

minutes) for computers in this site. The default setting is 5 minutes. This setting

is available as a global setting in the Computer Client Agent Properties dialog

box.

■ System restart turnaround Time: Specifies the length of time given for

computers to initiate the system restart and reload the operating system. This

setting is stored in the site control file for the site and has a default value of 10

minutes.

■ Maximum run time: Specifies the amount of time that is estimated for a

software update to install. The default setting is 20 minutes for updates and 60

minutes for service packs. This setting can be modified for individual software


updates on the Maximum Run Time tab for the properties for the software

update.

When these settings are used to determine the available maintenance window, each

software update has a default of 35 minutes (75 minutes for service packs). When

planning for maintenance windows, take these defaults into consideration. When

planning software update deployments to client computers, be aware of the

configured maintenance window, how many software updates are in a deployment

(so that you can forecast whether client computers will be able to install the updates

within the maintenance window) and whether the update installation will span

multiple maintenance windows. When software update installation has completed,

but there is not enough time in the maintenance window for the computer to restart,

the computer will wait until the next maintenance window and initiate the restart

before installing pending update installations.

When there are multiple software updates to be installed on a client computer with a

configured maintenance window, the update with the lowest maximum run time

installs first, the update with the next lowest maximum run time installs next, and so

on. Before installing each update, the client verifies that the available maintenance

window is long enough to install the update. After an update starts installing, it will

continue to install even if the installation goes beyond the end of the maintenance

window.

When creating a software update deployment, there are two settings that allow

maintenance windows to be ignored as follows:

■ Allow system restart outside of maintenance windows: Specifies whether to allow system restarts for both workstations and servers outside of configured maintenance windows. By default, this setting is not enabled. This setting is beneficial when you want your software update installation to complete on client computers as soon as possible. When this setting is not specified, a system restart will not be initiated if the maintenance window ends in 10 minutes or less. This could prevent the installation from completing and leave the client computer in a vulnerable state until the next maintenance window. This setting is available on the Restart Settings page of the Deployment Template Wizard or Deploy Software Updates Wizard.

■ Ignore maintenance windows and install immediately at deadline: Specifies whether the software updates in the deployment are installed at the deadline regardless of a configured maintenance window. By default, this setting is not enabled and is available only when there is a deadline configured for the deployment. This setting is beneficial when there are software updates that must be installed on client computers as soon as possible, such as the updates in an expedited deployment. This setting is available on the Schedule page of the Deploy Software Updates Wizard.


Planning for Settings on Software Updates

The Software Updates Client Agent properties dialog box contains three tabs that

provide configuration settings to enable software updates and configure the software

updates settings on client computers. Use the following procedure to open the

properties dialog box.

To open the properties dialog box for a software update

In the Configuration Manager console, navigate to System Center Configuration

Manager / Site Database / Computer Management / Software Updates / Update

Repository.

Right-click the software update, and then click Properties.

The following client settings can be configured in the properties for the software

update.

Maximum Run Time Tab

The Maximum Run Time tab in the properties dialog box for a software update

allows you to set the maximum amount of time a software update has to complete

installation on client computers. If the maximum run-time value has been reached, a

status message is created and the deployment is no longer monitored for software

update installation. This setting is also used to determine whether the software

update installation should be initiated within a configured maintenance window. If

the maximum run-time value is greater than the time left in the maintenance window,

software update installation is not initiated until the start of the next maintenance

window. This setting can be configured only on the site that synchronizes with

Microsoft Update, most likely the central site.

Important

Ensure that the maximum run-time value is not set for more time than the configured maintenance window or the software update installation will never initiate.

Some software updates might take more time to install than the default setting

allows. Increasing the Maximum run time (minutes) setting to accommodate larger

software updates is recommended.

The Maximum run time (minutes) setting specifies the maximum number of

minutes that a software update installation has to complete before the installation is

no longer monitored by Configuration Manager. This setting is also used to determine

whether there is enough time to install the update before the end of a maintenance


window. The default setting is 60 minutes for service packs and 20 minutes for all

other software update types. Values can range from 5 to 9999 minutes.

NAP Evaluation Tab

The NAP Evaluation tab is used to specify whether the software update is required

for compliance when using Network Access Protection (NAP). Enable NAP evaluation

to include the software update in a NAP policy that will become effective on NAP-

capable clients based on the configured schedule. When the policy becomes effective,

NAP-capable clients might have restricted access until they comply with the selected

software update. Network restriction and remediation is dependent on how the

policies are configured on the Windows Network Policy Server. This setting can be

configured only on the site that synchronizes with Microsoft Update, most likely the

central site.

Custom Severity Tab

The Custom Severity tab can be used to configure custom severity values for software

updates if predefined severity values do not meet your needs. The custom values are

listed in the Custom Severity column in the Configuration Manager console. The

software updates can be sorted by the defined custom severity values, the search

folder can be created based on these values, queries and reports can be created that

can filter on these values, and so on. This setting can be configured only on the site

that synchronizes with Microsoft Update, most likely the central site.


Determine What Software Updates to Deploy

The software updates feature in Configuration Manager 2007 provides the ability to

identify whether the software updates that are scanned for are installed or required

on client computers. There are several ways to determine what software updates

need to be installed. The reports in the Software Updates - A. Compliance category

provide the best interface for finding the software updates that are required on client

computers. You can also use the Software Updates home page, the Update Repository

console tree node, or Web reports. Use the following procedures as a guide to help

you identify when software updates are required on clients in the Configuration

Manager hierarchy.

Software Updates Reports

Compliance information can be retrieved by running reports within the Software

Updates - A. Compliance category. The reports provide useful information about the

compliance of software updates. Use the following procedure to display a list of

software updates with associated compliance state.

To use Web reports to identify required software updates

1. In the Configuration Manager console, navigate to System Center

Configuration Manager / Site Database / Computer Management /

Reporting / Reports.

2. A list of all the reports will be displayed in the display pane. Right-click

Compliance 5 - Updates by vendor/month/year, and then click Run. Specify

the Collection ID, Vendor, and Year. To filter the list of updates, also specify

Update Class, Product, and Month. Click Display.

3. The software updates that meet the criteria are displayed. Many columns

present information about each software update. The Required column

identifies the number of client computers that require a software update. The

report also lists the software updates that have been deployed by listing an

asterisk (*) in the Approved column. For more information about the software

update, you can click the Information URL link to open a Web site with specific

information about the selected software update. The Web site provides

information about the issue that the software update resolves.

4. Click the drill-down link in the first column for any software update to open the

Compliance 7 - Specific software update states report that displays a count of

computers in each compliance state.


Software Updates Home Page

The Software Updates home page allows you to find software updates for a specific

vendor, during a specific month and year, and for a specific update classification. The

following procedure provides the steps to determine what software updates are

required using the Software Updates home page.

To use the Software Updates home page to identify software updates for

deployment

1. In the Configuration Manager console, navigate to System Center Configuration

Manager / Site Database / Computer Management / Software Updates.

2. The software updates are displayed in the Software Update Compliance Status

Summary pane based on the article ID of the update. By default, the software

updates from the month when software updates were last synchronized will be

displayed. You can modify the criteria and then click Go to update the display.

You can determine what software updates are required on client computers, and

how many computers need the updates, by reviewing the Required column.

Highlight multiple software updates to display the overall compliance level in a

graph. The software updates displayed in the results pane can be downloaded,

added to an update list, or deployed by selecting the associated action.

3. For more information about the software update, you can click the article ID for

the software update to open a Web site with specific information about the

selected software update. The Web site provides information about the

vulnerability if the software update is not installed, the maximum severity

rating, recommendations, affected software, affected components, and so forth.

Update Repository

The Update Repository node in the Configuration Manager 2007 console tree

organizes software updates by update classification and then by product. You can

browse for software updates by classification, vendor, or product, or you can create a

search folder to find the updates that should be deployed. The following procedure

provides the steps to find software updates in the Updates Repository console tree

node.

To use the Updates Repository node to display software updates


Configuration Manager / Site Database / Computer Management / Software

Updates / Update Repository.


2. Expand the desired classification. All software updates are displayed for the

classification by clicking All Updates, you can expand a vendor node and get all

updates for the vendor within the classification, or you can click a product node

to get the updates within the classification for a specific product by a vendor.

3. The software updates are displayed by article ID. You can determine what

software updates are required on client computers, and how many computers

need the updates, by reviewing the Required column. Click any column header

to sort the data. For example, click the Required column header to sort by the

software updates that are required by the most client computers. The software

updates displayed in the results pane can be downloaded, added to an update

list, or deployed by selecting the associated action.

Software Updates Search Folders

You can create search folders that specify a set of criteria to help you find software

updates that are required on client computers. For example, you could create a search

folder that displays only required software updates that were released in the

previous month. Using search folders is part of the recommended software updates

workflow. For example, you can create a search folder with specific criteria to display

a set of software updates, add the set of updates to an update list, use software

updates reports to display compliance information for the update list, and create a

deployment using the update list.

The following procedure provides the steps to use search folders to find the software

updates that are required on client computers.

To use the search folders to display software updates


Configuration Manager / Site Database / Computer Management / Software

Updates / Update Repository / Search Folders.

2. Right-click Search Folders, and then click New Search Folder.

3. Specify one or more object properties for the search criteria.

4. Specify the search criteria for the object property by clicking the underlined

property in the Step 2: Edit the property's search criteria window.

5. Click Search all folders under this feature.

6. Specify the name of the search folder, and then click OK.


7. Expand the Search Folders console tree node, and then click the search folder

that you just created.

8. The software updates are displayed by article ID based on the criteria that was

specified for the search folder. You can determine what software updates are

required on client computers, and how many computers need the updates, by

reviewing the Required column. Click any column header to sort the data. For

example, click the Required column header to sort by the software updates that

are required by the most client computers. The software updates displayed in

the results pane can be downloaded, added to an update list, or deployed by

selecting the associated action.

Software Updates Supersedence

Supersedence is when a new software update contains the same fixes that were in a

previously released software update. It is recommended that the software update

that supersedes another update be deployed to avoid installing outdated software

updates on client computers. Superseded software updates are identified in the

Configuration Manager console by an icon that contains a yellow arrow. You can

highlight a software update in the Configuration Manager console and click the

Supersedence Information tab to display updates that the highlighted update

supersedes and the updates that supersede the highlighted update.


Planning for a Software Update Deployment

Before creating a software update deployment in Configuration Manager 2007, there

are several settings that must be considered depending on your Configuration

Manager 2007 hierarchy. You should also consider creating deployment templates for

common deployment scenarios, understand how maintenance windows and client

computer restart behavior works on client computers, determine whether the

deployments tasks will be delegated, and plan for deployments to Systems

Management Server (SMS) 2003 clients.


When creating the active software update point, you configure the update

classifications, products, and languages for which the software update metadata is

synchronized. The synchronized software updates are displayed in the Configuration

Manager console and can then be deployed to client computers. These settings can be

modified at any time, but you should pay special attention to the Summary Details

language setting before synchronizing and deploying software updates.

It is very important that you select all of the summary details languages that will be

needed in your Configuration Manager hierarchy. When the active software update










Wizard, many deployment settings need to be considered. The following sections

provide information about the settings on each page of the Deploy Software Updates

Wizard.

General Page

The General page allows you to provide the name and description for the deployment.

The name must be unique for the site.


Recommendation

Provide a name and description that will help you to distinguish this deployment

from any others. Deployments are sorted in the Configuration Manager console by

name. Deployments are easy to find when there are a small number of them, but they

can be difficult to find when there are many. Before creating deployments, think

about the naming convention that will be used at your site.

Collection Page

The Collection page specifies the collection that will be targeted for the software

update deployment. Members of the collection and subcollections, if configured,

receive available deployments during their next Machine Policy Retrieval &

Evaluation Cycle. The following settings are available on the Collection page:

Collection: Specifies the target collection for the deployment. Members of the

collection receive the software updates defined in the deployment.

Include members of subcollection: Specifies whether members of any subcollection of

the main collection receive the software updates defined in the deployment. By

default, this setting is enabled and members of both the collection and subcollection

are targeted for the deployment.

Recommendation

When creating deployment templates, you do not have to specify the collection as

part of the template. This allows you to use the template when creating multiple

deployments that target different collections.

Display/Time Settings Page

The Display/Time Settings page specifies whether the user will be notified of pending

software updates, the installation progress for software updates, whether a client

evaluates the deployment schedule based on local or Coordinated Universal Time

(UTC), and the default duration between software update availability and deployment

deadline. The following settings are available on the Display/Time Settings page:

Display Settings

Select one of the following settings:

■ Allow display notifications on clients: Specifies that display notifications are used

on clients that inform end users of available software updates and progress


indicators are displayed during software update installation. By default, this

setting is selected and display notifications are allowed on clients.

■ Suppress display notifications on clients: Specifies that display notifications are

not used on clients and progress indicators are not displayed during update

installation. Software update notification icons will still display on clients and

users can click this icon to see available updates.

Time Settings


■ Client Local Time: Specifies that clients use their local time to evaluate schedules

for the time when software updates become available on clients and when

deadlines enforce software update installation, if enabled.

■ UTC: Specifies that clients use UTC to evaluate schedules for the time when

software updates become available on clients and when deadlines enforce

software update installation. By default, this setting is selected and UTC is used to

evaluate deployment schedules.

Duration Setting

Duration: Specifies the duration, which is used only when creating a deployment

using a template. The deadline setting in the deployment defaults to the time when an

update is available plus the configured duration setting. By default, the duration is set

at 2 weeks.

Restart Settings Page

The Restart Settings page specifies the system restart behavior when a software

update installs on a client computer and requires a restart to complete. The following

settings are available on the Restart Settings page:

Suppress the system restart on:

■ Servers: Specifies whether to suppress a system restart on servers. This action is

requested by a software update installation when a restart is required for the

installation to complete. By default, this setting is not enabled, and servers will

restart if required by the software update installation.

■ Workstations: Specifies whether to suppress a system restart on workstations.

This action is requested by a software update installation when a restart is

required for the installation to complete. By default, this setting is not enabled,

and workstations will restart if required by the software update installation.


Specify whether to allow a system restart outside of maintenance windows both

for servers and for workstations:

■ Allow system restart outside of maintenance windows: Specifies whether to

allow system restarts for both workstations and servers outside of configured

maintenance windows. By default, this setting is not enabled, and when a system

restart is required for a software update installation to complete, it is initiated

only when more than 10 minutes are left in the configured maintenance window.

Recommendation

Suppressing system restarts can be useful in server environments or in cases in

which you do not want the computers that are installing the software updates to

restart by default. However, forcing a system restart after software update

installation ensures that updates fully complete, whereas suppressing post-

installation restart requests can leave systems in an insecure or unstable state.

Event Generation Page

The Event Generation page specifies whether Microsoft Operation Manager alerts are

disabled while the software updates install and whether an Operation Manager alert

is created when a software update installation fails. The following settings are

available on the Event Generation page:

Disable Operations Manager alerts while software updates run: Specifies that

Operation Manager alerts are disabled during the software update installation. This is

useful when deploying software updates will impact an application that is being

monitored by Operations Manager. By default, this setting is not enabled.

Generate Operation Manager alert when a software update installation fails: Specifies

that an Operations Manager alert is created for each software update installation

failure. By default, this setting is not enabled.

Recommendation

These settings are useful when deploying software updates will impact an application

that is being monitored by Operations Manager. Disabling alerts while the update is

being installed will prevent alerts from triggering, such as a notification that a service

has stopped, as a result of the update installation. By default, these settings are not

enabled.


Download Settings Page

The Download Settings page specifies how Configuration Manager 2007 client

computers will interact with distribution points when they receive a software update

deployment. The following settings are available on the Download Settings page:

When a client is connected within a slow or unreliable network boundary:

■ Do not install software updates: Specifies that clients do not install software

updates if they are within network boundaries that are designated as slow or

unreliable. This is the default selection.

■ Download software updates from distribution point and install: Specifies that

clients download the software updates from the distribution point and install

them if they are within network boundaries that are designated as slow or

unreliable. This is the same behavior as if the client was within a local area

network boundary.

Specify whether to allow clients that are within the boundaries for one or more

protected distribution points to download and install software updates from

unprotected distribution points when the updates are not available from any

protected distribution point:

■ Do not install software updates: Indicates that when protected distribution

points do not have the software updates available for clients that are within the

protected distribution point boundaries, software updates will not be installed.

■ Download software updates from unprotected distribution point and install:

Indicates that when protected distribution points do not have the software

updates for clients that are within the protected distribution point boundaries,

the client will download the software updates from an unprotected distribution

point and install them. This is the default selection.

SMS 2003 Settings Page

The SMS 2003 Settings page specifies whether to deploy software updates to SMS

2003 clients that are in the target collection. This setting is available only when all of

the software updates in the deployment have been synchronized using the Inventory

Tool for Microsoft Updates and have a value of Yes for the Deployable to SMS 2003

setting. The following settings are available on the SMS 2003 Settings page:

Deploy software updates to SMS 2003 clients


This setting specifies whether to deploy the software updates in the deployment to

SMS 2003 clients that are in the target collection. A package, package instruction files,

and advertisement are created and sent to child SMS 2003 sites to support the update

installation on SMS 2003 clients. By default, this setting is not enabled. When this

setting is selected, the following settings are available:

■ Collect hardware inventory immediately: Specifies whether to collect hardware

inventory on SMS 2003 clients immediately following software update

installation. This increases reporting accuracy but might increase system activity

on the SMS 2003 clients. By default, this setting is not enabled and hardware

inventory is collected during its scheduled hardware inventory cycle.

■ When a distribution point is available locally: Specifies that SMS 2003 clients

handle software update installation when the updates are available on a local

distribution point according to the following options:

□ Run update installation from distribution point: Specifies that the software

updates are installed from the distribution point. This is the default setting.

□ Download updates from distribution point and then run installation:

Specifies that the software updates are downloaded from the distribution

point and then installed on the client.

■ When a client is connected within a slow or unreliable network boundary:

Specifies that SMS 2003 clients handle software update installation when the

updates are available only on remote distribution points according to the

following options:

□ Do not run update installation: Specifies that the software update installation

will not run. This is the default setting.

□ Download updates from a remote distribution point prior to update

installation: Specifies that the software updates are downloaded from the

distribution point and then installed on the client.

□ Run update installation from a remote distribution point: Specifies that the

software updates are installed from the remote distribution point.

Recommendation

When software updates are downloaded and then installed on SMS 2003 clients, all

updates contained in the package are downloaded regardless of applicability for the

client. If deployment packages contain a lot of updates that might not be applicable to

the SMS 2003 client, you should consider whether to run the update installation

directly from the distribution point.


Deployment Package Page

The Deployment Package page specifies the deployment package that will be used to

host the software updates in the deployment. The software updates in the

deployment are downloaded and copied to the deployment package folder on the

distribution points configured for the package. If all software updates in the

deployment have previously been downloaded and copied to a shared package folder

on the distribution point, the Deployment Package page of the wizard does not

display and the deployment is automatically configured to use the package that

downloaded the update. If the deployment targets SMS 2003 clients, the wizard will

always ask for a deployment package regardless of whether the updates have been

previously downloaded. The following settings are available on the Deployment

Package page:

■ Select deployment package: Specifies that an existing package is used for the

software updates in the deployment. Deployment packages that were created at

the site can be selected. Packages created at a parent site are not available.

■ Create a new deployment package: Specifies that a new package is created for the

software updates in the deployment. The following properties are configured as

part of the deployment package:

■ Deployment package name: Specifies the name of the deployment package. The

package should have a unique name, describe the package content, and is limited

to no more than 50 characters.

■ Deployment package description: Specifies the description of the deployment

package. The package description should describe the package contents in detail

and is limited to no more than 127 characters.

■ Deployment package source: Specifies the location of the software update source

files. When the deployment is generated, the source files are compressed and

copied to the distribution points that are associated with the deployment

package. The source location must be entered as a network path (for example,

\\server\sharename\path), or the Browse button can be used to find the

network location. The shared folder for the deployment package source files

must be manually created before proceeding to the next page.

Important

The deployment package source location must not be used by another

deployment or software distribution package.


■ Deployment package sending priority: Specifies the sending priority for the

deployment package. The sending priority is used for the deployment package

when it is sent to distribution points at child sites. Packages are sent in priority

order: High, Medium, or Low. Packages with identical priorities are sent in the

order in which they were created. Unless there is a backlog, the package will

process immediately regardless of its priority.

■ Enable binary differential replication: Specifies whether binary delta comparison

should be used on changed package source files. Selecting the check box enables

this behavior and allows Distribution Manager to transfer only parts of the file

that have changed instead of the entire file. This behavior can result in large

bandwidth savings when transferring the changes for large files, compared with

the traditional method in which the entire file is transferred. For more

information, see About Binary Differential Replication. This setting can be

modified for existing packages in the properties for the package.

Download Location Page

The Download Location page specifies whether the software updates in the

deployment should be downloaded from the Internet or from the local network. The

following settings are available on the Download Location page:

■ Download software updates from the Internet: Specifies that the software

updates are downloaded from the location on the Internet that is defined in the

software update definition. This setting is enabled by default.

■ Download software updates from a location on the local network: Specifies that

the software updates are downloaded from a local directory or shared folder. Use

this setting if the site server does not have Internet access or if the software

updates are available on the local network. The software updates can be

downloaded from any computer that has Internet access and stored in a location

on the local network that is accessible from the site server.

Recommendation

If the software updates have already been downloaded to the Microsoft Windows

Server Update Services (WSUS) server on the active software update point, you can

specify Download software updates from a location on the local network and

configure \\<WSUS Server Name>\<WSUSContentPath> to download the software

updates from the WSUS server instead of the Internet.

Language Selection Page

The Language Selection page specifies the languages that are downloaded for the

selected software updates. The software updates are downloaded only if they are


available in the selected languages. Software updates that are not language specific

are always downloaded.

If all software updates in the deployment have previously been downloaded and

copied to the shared folder for the package on the distribution point, the Language

Selection page of the wizard does not display. The deployment is automatically

configured to download the updates in the languages that were previously

downloaded. The following settings are available on the Language Selection page:

■ Update File: Specifies the languages for which software update files are

downloaded. By default, the languages configured in the software update point

properties are selected. Selecting additional languages does not add them to the

configured software update point language settings. At least one language must

be selected before proceeding to the next page. If a language is selected on this

page that is not supported by the software update, the download will fail for the

software update.

Deployment Schedule

The Deployment Schedule page specifies when a software update deployment will

become active and whether software update installation will be enforced on clients.

The following settings are available on the Deployment Schedule page:

Select the data and time that software updates will be made available to clients:

■ As soon as possible: Specifies that the software updates in the deployment are

made available to clients as soon as possible. When the deployment is created,

the machine policy is updated, clients are made aware of the deployment at their

next machine policy evaluation cycle, and then the updates are available for

installation.

■ Date and time: Specifies that the software updates in the deployment will not be

made available to clients until a specific date and time. When the deployment is

created, the machine policy is updated and clients are made aware of the

deployment at their next machine policy evaluation cycle, but the software

updates in the deployment are not available for installation until the configured

date and time.

Specify whether the software updates should automatically install on clients at a

configured deployment deadline:


■ Do not set a deadline for software update installation: Specifies that the software

updates in the deployment are optional and do not require automatic installation

by a specific date and time.

■ Set deadline for software update installation: Specifies that the software updates

in the deployment are mandatory and require automatic installation by a specific

date and time. If the deadline is reached and the software updates in the

deployment are still required on the client, the update installation will

automatically be initiated. When a deadline is configured, the following

additional settings are available:

□ Enable Wake On LAN: Specifies whether to enable Wake On LAN at the

deadline to send wake-up packets to computers that require one or more

updates in the deployment. The computers that are not running are started

at the deadline so the update installation can be initiated. Clients that do not

require any updates in the deployment are not started. By default, this

setting is not enabled and available only when there is a deadline configured

for the deployment.

□ Ignore maintenance windows and install immediately at deadline: Specifies

whether the software updates in the deployment are installed at the deadline

regardless of a configured maintenance window. By default, this setting is not

enabled and available only when there is a deadline configured for the

deployment.

More Information











After the software updates have been installed for the deployment with the earliest


will now display the deadline for the second deployment. SMS 2003 clients in the

Configuration Manager hierarchy will also use the configured deadline date and time

for deployments targeted to them.


NAP Evaluation Page

The NAP Evaluation page specifies whether the software updates in this deployment

are required for compliance when using Network Access Protection (NAP). Enable

NAP evaluation to include the software updates in a NAP policy that will become

effective on NAP-capable clients based on the configured schedule. When the policy

becomes effective, NAP-capable clients might have restricted access until they comply

with the selected software update. Network restriction and remediation are

dependent on how the policies are configured on the Windows Network Policy

Server. The following settings are available on the Deployment Schedule page:

Enable NAP evaluation: Specifies whether the software update is included in the NAP

policy and evaluated on NAP-capable clients. When this setting is selected, the

following settings are available:

■ Specify when these settings become effective:

■ As soon as possible: Specifies that the software update is included in the NAP

policy, which becomes effective on NAP-capable clients as soon as possible.

■ Date and time: Specifies that the software update is included in the NAP policy,

which becomes effective on NAP-capable clients on the specified date and time.

The default date and time value is determined by adding 14 days to the

deployment deadline date and time that was configured on the Deployment

Schedule page.

■ The NAP evaluation page of the Deploy Software Updates Wizard does not

display unless NAP is configured for the site.

Using Deployment Templates When Creating Deployments

















helps to prevent mistakes when configuring the deployment. The deployment

settings from the following wizard pages can be configured in a deployment template:

■ Collection

■ Display/Time Settings

■ Restart Settings

■ Event Generation

■ Download Settings

■ SMS 2003 Settings

If a deployment template is not used when creating a deployment, the properties are

manually entered and can optionally be saved as a deployment template within the

wizard and used in future deployments. For more information, see About Deployment

Templates in Software Updates.

Maintenance Windows

When maintenance windows are configured on collections that will be targeted for

software update deployments, you should consider the following:

■ Each software update is given a default setting of 35 minutes to install and

restart, if necessary (75 minutes for service packs). When the available time left

in a maintenance window is less than this, the software update installation will

not start until the next maintenance window. When planning a deployment to a

collection with maintenance windows, take these defaults into consideration. For

example, if a 2-hour maintenance window is configured on the collection and

there are four software updates in a deployment, only three software updates

will be installed during the first maintenance window and the last update will be

installed during the second maintenance window.

■ The following deployment settings affect how software updates are installed on

client computers that have maintenance windows:

□ Allow system restart outside of maintenance windows: Specifies whether to

allow system restarts for both workstations and servers outside of


configured maintenance windows. By default, this setting is not enabled. This

setting is beneficial when you want your software update installation to

complete on client computers as soon as possible. When this setting is not

specified, a system restart will not be initiated if the maintenance window

ends in 10 minutes or less. This could prevent the installation from

completing and leave the client computer in a vulnerable state until the next

maintenance window. This setting is available on the Restart Settings page of

the Deployment Template Wizard or Deploy Software Updates Wizard.

□ Ignore maintenance windows and install immediately at deadline: Specifies



enabled and is available only when there is a deadline configured for the

deployment. This setting is beneficial when there are software updates that

must be installed on client computers as soon as possible, such as the

updates in an expedited deployment. This setting is available on the Schedule

page of the Deploy Software Updates Wizard.

Restart Behavior on Client Computers

When software update installations have run and require a restart for them to

complete, new software updates that become available are not shown and the

notification area icon will not be visible on client computers. A system restart will be

automatically initiated on client computers when the deadline has been reached on

mandatory deployments. When multiple deployments have the same deadline, the

software updates will all be installed at the deadline and then one system restart will

be initiated.

Note

Some software updates must be installed exclusively, and a system restart might

be initiated for these software updates before installing other updates in the same

deployment or in deployments with the same deadline.

Hiding Deployments from End Users

To hide software update deployment and installation on client computers, use the

Hide all deployments from end users setting on the Update Installation tab of the

Software Updates Client Agent properties. This setting specifies that display

notifications and notification area icons for the software updates in all deployments

will not display on client computers. This setting is not enabled by default. When this

setting is enabled, the software updates only in mandatory deployments are available


for installation and the silent installation will initiate by the configured deadline.

Hidden deployments will become visible on client computers when this setting is not

enabled. For more information, see How to Hide Deployments on Client Computers.

Software Updates with License Terms

When a software update has associated Microsoft Software License Terms and the

terms have not yet been accepted, the Review/Accept License Terms dialog box

displays before opening the Deploy Software Updates Wizard. After the license terms

for a software update have been accepted, the wizard opens and the software updates

can be deployed. Future deployments for the software update will not require license

terms acceptance. If the license terms are declined, the process is cancelled. The

license terms can also be accepted from the Configuration Manager console by

highlighting one or more software updates, and then initiating the Review/Accept

License Terms action.


Using an update list provides the ability to delegate the administration for deploying software updates.

For example, an administrator at the central site can select the software updates that need to be

deployed and add the updates to an update list. Administrators at the site or child sites, with restricted

object rights, can then use the update list and deploy the updates in the update list to an appropriate

collection. For more information, see the "Delegated Administration" section of About Update Lists in

Software Updates.


General SUM/WSUS Architecture

Given the limitations with the current Patch Management features in SMS 2003, a

decision was made to integrate Configuration Manager with WSUS. This decision

benefits customers in several ways.

■ Provides catalog parity with Microsoft Update

■ Updates no longer restricted to security updates and service packs

■ Drivers, hotfixes and LDRs available

■ Update definitions from OEMs and ISVs

■ Infrastructure Efficiencies

■ Consolidation of Scan Engines

■ Removal of OEM Proprietary Engines as they migrate to WSUS solution

■ Removal of Generic Scan Tool

■ WUA is the sole engine for compliance scanning

■ Scalability concerns associated with offline catalog addressed

■ Replication challenges resolved

■ Attain ongoing engineering efficiencies

■ Streamline the SUM setup experience

■ Resolve synch as a site role requirements

■ Provides incremental value to OSD/DCM and NAP scenarios associated with

Update Management

The WSUS server integration is used solely to provide compliance scanning

functionality; the current offline catalog model will no longer be required although

support is maintained for interoperability with SMS 2003 sites.

System Architecture

The following diagram depicts the overall system architecture for WSUS and SMS

integration. This architecture is described in the following diagram:


Figure 4. WSUS Integration

Update Metadata,

Metadata (no content)

WSUS Server

WSUS Server

WU/MU Server

SMS Admin

Console

Update metadata,

binaries, deployments

Update Metadata

WSUS Agent

UI for

“Available”

Updates

Update Metadata,

Deployments

Distribution Point

SMS Client

Control

and

Status

Control

and

Status

Update

binaries

Update

Binaries

MSFT

Server

Central

Corporate

Server

Corporate

DSS - Replica

Distribution

Point

Client

WUS components SMS components

SMS Admin

Console

Update binaries

SMS Client

Content

Cache

Update

Binaries

Update

Binaries

WSUS Client

Configuration

Update Metadata

WSUS Server Config

SMS Central Site

WSUS

Manager

WSUS

Config Mgr

WSUS Sync

Update Metadata

WUS Server Config

SMS Child Site

WSUS

Manager

WSUS

Config Mgr

WSUS Sync

SMS SDK

SMS SDK

Update

Config

Update

Config

Site

Repository

Site

Repository


Component Architecture

The following diagram describes the various Configuration Manager Site Server and

WSUS Server components involved in managing the WSUS Server site system role.

Figure 5. WSUS Integration Components

Site Component

Manager

SMS Executive

Object

Replication

Manager &

CI Assignment

Manager

SMS Executive

WSUS Config

Manager

File Dispatch

ManagerState System

CLR

Microsoft.

UpdateServices.

Adminstration.dll

(.NET Assembly)WSUS Config

Manager &

SMS Sync

SMS Site

Database

WSUS

ConfigurationWSUS Server (Upstream)

WSUS ServerWSUS

Database

Updates

WSUS

Configuration

Inboxes

Registry

WSUS

Configuration

SDM Packages

CI’s

State Messages

State

CI’s

CI Assignments

SMS-WSUS

Managed Service

Provider

(.NET Assembly)

Install

WCM

WSUS Site System Role

(smsexec.exe)

State Messages

WSUS

Configuration

SMS Site Server

(Central Site)

WSUS Server Site System

(Upstream WSUS Server)

SMS Site Server

(Child Site)

WSUS Server Site System

(Downstream WSUS Server)

WSUS Server (Downstream)

WSUS ServerWSUS

Database

Updates

Updates

SMS Executive

(WCM, FDM, MSP)

Updates

WSUS

Configuration

SMS Site

Database

SMS Executive

(SCM, CIAMgr, ObjReplMgr, Sync, WCM

& MSP)

WSUS Setup,

Configuration,

State Messages

SDM Packages

CI’s

CI Assignments

CI,

SDM Package,

CI Assignment,

Update CI State

IWSUSConfiguration

IWSUSSubscription

IWSUSServer

CLR

wsus

.NET

dll

SMS

MSP

WSUS

Remote

Administration

Web Service

Subscriptions

Updates

Updates

Subscriptions

Updates

Subscriptions

WSUS

Remote

Administration

Web Service SubscriptionsSubscriptions,

Updates

Inboxes

State

Messages

State

Messages


Component Descriptions

Site Component Manager (SCM)

Site Component Manager is an existing Configuration Manager Site Server component

that manages the SMS Executive install and uninstall. When the Configuration

Manager Administrator selects a WSUS Server site system role on the host server, Site

Component Manager bootstraps the necessary binaries to the host server and installs

the SMS Executive, WSUS Configuration Manager and File Dispatch Manager

components. Similarly, when the Software Update Point is removed, Site Control

Manager uninstalls SMS Executive.

WSUS Configuration Manager (WCM)

WSUS Configuration Manager is a new component that is responsible for WSUS

Server Configuration, Monitoring and Subscription. It runs as a new SMS Executive

thread that is installed locally on the Configuration Manager Site Server and remotely

on the WSUS Server site system role host server.

WSUS Configuration Manager calls into the WSUS .NET API for most of its tasks. As

the WSUS Configuration Manager is written in native unmanaged code, it uses the

SMS-WSUS Managed Service Provider that provides COM interoperability with the

WSUS .NET API.

Microsoft.UpdateServices.Administration.dll (WSUS .NET API)

WSUS provides a set of managed .NET libraries for WSUS Server administration.

Configuration Manager uses these libraries to manage the WSUS Server.

Configuration Manager – WSUS Managed Service Provider (SMS – WSUS – MSP)

WSUS managed .NET libraries do not provide COM interoperability so the WSUS

Configuration Manager cannot call directly into this managed API for WSUS Server

administration. Due to this, and other interoperability issues a managed component

layer that supports COM interoperability and calls into the WSUS .NET API directly

and efficiently was designed. This managed component is the Configuration Manager

– WSUS Managed Service Provider. WSUS Configuration Manager and WSUS

Synchronization Manager both use this Managed Service Provider as a regular COM

component using standard COM interoperability.

WSUS Synchronization Manager (WSM)

Currently the SMS Sync component reads the catalog for Microsoft Security software

updates and other third party catalogs retrieved either locally or from Microsoft

Update. It then inserts this software updates as System Definition Model (SDM)

Packages and Configuration Items into the Configuration Manager Site Server

database using the SMS Provider. WSUS Synchronization Manager (WSM) uses the


MSP layer and Managed C++ to directly call the SMS base classes to insert updates in

the database. This provides performance improvements over the old approach of

using the SMS Provider.

File Dispatch Manager (FDM)

File Dispatch Manager is an existing component that is used to transfer files from site

system roles (MP, SHV, etc) to the Configuration Manager Site Server. The WSUS

Configuration Manager on the WSUS Server site system role uses File Dispatch

Manager to transfer the status messages from the Software Update Point to the

Configuration Manager Site Server.

Object Replication Manager (ObjReplMgr)

ObjReplMgr is a Configuration Manager component that is used to replicate

Configuration Item’s (CI’s), System Definition Model (SDM) Packages, Update Source

information, Categories and EULA information to child Primary Site Servers. It also

supports relationships such as update CI’s with supported platforms and update

synchronization from multiple sources. ObjReplMgr replicates these new

relationships down to the child sites.

CI Assignment Manager (CIAMgr)

CI Assignment Manager is the Configuration Manager component used to replicate CI

Assignments to child Primary Site Servers and manage SUM Deployment Policies.

Hierarchy Manager (HMAN)

HMAN is an existing SMS /Configuration Manager component that is used to process

hierarchy changes via Site Control File changes. Software Update Point Site System

Role and WSUS Hierarchy Configuration is a part of the Site Control File. Hierarchy

Manager adds this configuration information to the Configuration Manager database

so the MP can provide WSUS Locations when requested to do so by the clients.

Component Design

The following section details the design of new and existing components. The

subsections also describe the scenarios and flow involving that component.

Site Component Manager

As mentioned previously, the Site Component Manager installs site system roles,

including the Software Update Point. Site Component Manager uses the

SMS_SERVER_BOOTSTRAP service to install components on remote site systems. It

installs the following SMS Site Server components on the WSUS Server for the

Software Update Point Role.

■ SMS Executive


■ WSUS Configuration Manager

■ File Dispatch Manager

Configuration Manager Site Server Hierarchy and WSUS Server Hierarchy

The following figure depicts a sample Configuration Manager and WSUS Hierarchy

and the flow of updates. The Central site is managing multiple WSUS servers behind

an NLB and the child site manages a single WSUS server.

Figure 6. Multiple WSUS servers in NLB Configuration

WU/MU

SMS

Central Site

Server

SMS

Primary

Site Server

NLB Virtual IP

WSUS

Server

WSUS

Server

WSUS

Server

Updates

Updates

Configuration

Subscription

Configuration

SQL

Cluster

SQL

The Configuration Manager Admin UI allow settings up the Software Update Point

(Software Update Point) at every site. These settings are translated into the following

Site Control File settings.

Central Site Server Site Control File

□ Site Wide WSUS Server settings

BEGIN_COMPONENT <SMS_WSUS_CONFIGURATION_MANAGER> <SMS WSUS Server Point> PROPERTY <DefaultWSUS><>< SERVER1><0> PROPERTY <DefaultWSUSType><><><1> PROPERTY <SSLClientsToDefaultWSUS><><><0> PROPERTY <SSLDownstreamWSUSToDefaultWSUS><><><0> PROPERTY <INFWSUS><><><0> PROPERTY <INFWSUSType><><><0> PROPERTY <SSLClientsToINFWSUS><><><1> PROPERTY <UpstreamWSUS><><Microsoft Update><0>


PROPERTY <IISPort><><><80> PROPERTY <IISSSLPort><><><443> PROPERTY <ParentWSUS><><Microsoft Update><0> PROPERTY <ParentWSUSPort><><><80> PROPERTY <SSLDefaultWSUSToParentWSUS><><><0> END_COMPONENT

■ Software Update Point settings

BEGIN_SYSTEM_RESOURCE_USE RESOURCE<Windows NT Server><["Display=\\SERVER1\"]MSWNET:["SMS_SITE=S01"]\\SERVER1\> ROLE<SMS WSUS Server Point> PROPERTY <UseProxy><><><0> PROPERTY <ProxyName><><><0> PROPERTY <ProxyServerPort><><><0> PROPERTY <AnonymousProxyAccess><><><0> PROPERTY <ProxyUserName><><><0> PROPERTY <ProxyUserDomain><><><0> PROPERTY <Reserved1><><><0> PROPERTY <AllowProxyCredentialsOverNonSsl><><><0> END_SYSTEM_RESOURCE_USE

Child Site Server Site Control File

□ Site Wide WSUS Server settings

BEGIN_COMPONENT <SMS_WSUS_ CONFIGURATION _MANAGER> <SMS WSUS Server Point> PROPERTY <DefaultWSUS><><SERVER2><0> PROPERTY <DefaultWSUSType><><><1> PROPERTY <SSLClientsToDefaultWSUS><><><0> PROPERTY <SSLDownstreamWSUSToDefaultWSUS><><><0> PROPERTY <INFWSUS><><><0> PROPERTY <INFWSUSType><><><0> PROPERTY <SSLClientsToINFWSUS><><><1> PROPERTY <UpstreamWSUS><><SERVER1><0> PROPERTY <IISPort><><><80> PROPERTY <IISSSLPort><><><443> PROPERTY <ParentWSUS><><SERVER1><0> PROPERTY <ParentWSUSPort><><><80> PROPERTY <SSLDefaultWSUSToParentWSUS><><><0> END_COMPONENT

Based on the Site Control File settings the Site Attach and Detach scenarios will be

addressed.


The following flow chart explains the basic scenario when enabling WSUS Server site

system role in a Configuration Manager Site Server hierarchy.

Figure 7. Enabling Software Update Point Flow


Install.map changes

Install.map was modified to include the Software Update Point so that it can be set

and exposed via the SMS_SIIB_SysResRole.

BEGIN_SYSTEM_RESOURCE_ROLE <SMS WSUS Server Point> // Role Name <GUID> <sms20hlp.chm> <bar.htm> <1> // Assignable <MMCPgRes.dll> // Resource Binary <0> // Display Name Resource ID <0> // Description Resource ID <0> // Display Icon Resource ID BEGIN_RESOURCE_TYPE <Windows NT Server> // Server END_RESOURCE_TYPE UNIT <ADMIN UI> END_SYSTEM_RESOURCE_ROLE

Install.map was also modified to include the component list so that

SMS_SITE_COMPONENT_MANAGE can monitor the service.

BEGIN_COMPONENT_FILELIST <SMS_WSUS_CONFIGURATION_MANAGER> <4194937> BEGIN_DIRECTORY <bin\i386> <9><X86><> FILE <WCM.dll><1><123> FILE <WSUSMSP.dll><0><123> END_DIRECTORY UNIT <SMS> END_COMPONENT_FILELIST

Modify the SMS_MP_FILE_DISPATCH_MANAGER component flags to include the new

Software Update Point Site System Role bit.

#define IMAPITEM_CFL_ONWSUS 0x00400000 // SETUP use only, used to generate site control component items for Software Update Point: BEGIN_COMPONENT_FILELIST <SMS_MP_FILE_DISPATCH_MANAGER> <4751481> BEGIN_DIRECTORY


<bin\i386> <9><X86><> FILE <mpfdm.dll><1><123> FILE <srvboot.exe><0><123> END_DIRECTORY UNIT <SMS> END_COMPONENT_FILELIST

Site Control File changes

WSUS Configuration Manager component level configuration in the Site Control File

These properties are defined in the Install.map under the

<SMS_WSUS_CONFIGURATION_MANAGER> section.

BEGIN_COMPONENT <SMS_WSUS_CONFIGURATION_MANAGER> <SMS WSUS Server Point> PROPERTY <DefaultWSUS><>< SERVER1><0> PROPERTY < DefaultWSUSType><><><1> … … END_COMPONENT

The individual WSUS Configuration Manager component level Site Control File

properties are defined in the following table.

Table 22 WCM Site Control File Properties

Name Type Values Description

<DefaultWSUS> String Server Name OR Virtual IP

This property is used by WCM to connect to the WSUS Server for configuration.

<DefaultWSUSType> DWORD 0 – Unknown (default) 1 – Server Name 2 – Virtual IP (NLB)

This property is used by the SMS Admin UI display the server name or virtual IP of the default WSUS Server.



<SSLClientsToDefaultWSUS> DWORD 0 – SSL not needed (default) 1 – SSL enabled

This property is used by WCM to update the SMS database to return WSUS https locations to clients. If Set the client needs to connect to the WSUS Server using SSL.

<SSLDownstreamWSUSToDefaultWSUS>

DWORD 0 – SSL not needed (default) 1 – SSL enabled

This property is set by the SMS Admin if the WSUS Server requires SSL for the Downstream Server to sync updates from it.

<INFWSUS> String Server Name OR Virtual IP

This property is used by WCM to populate the INF WSUS Server location. The clients on the internet should use this location.

<INFWSUSType> DWORD 0 – Unknown (default) 1 – Server Name 2 – Virtual IP (NLB)

This property is used by the SMS Admin UI display the server name or virtual IP of the INF WSUS Server.

<SSLClientsToINFWSUS> DWORD 0 – SSL not needed 1 – SSL enabled (default)

This property is used by WCM to update the SMS database to return INF WSUS https locations to clients. If Set, the internetc lient needs to connect to the INF WSUS Server using SSL.



<UpstreamWSUS> String “Microsoft Update” (default, Central site) Host Server machine Name (Child Site) Virtual IP (Child site if Upstream servers are behind the NLB)

This property is used by WCM to configure the Upstream Server setting of the WSUS Server. In case it is the central site, WCM expects this value to be “Microsoft Update” and configures the WSUS server in the Autonomous mode. In case it is a child site, WCM expects this value to be anything but “Microsoft Update” and configures the WSUS server in the Replica mode.

<IISPort > DWORD 80 – Default value. Only applies if the upstream server name is not “”Microsoft Update”

This property is used by WCM to configure the Upstream Server Port Number setting of the WSUS Server on child sites.

<IISSSLPort> DWORD 0 – Do not use SSL 1 – Use SSL

This property is used by WCM to configure the Upstream Server SSL setting of the WSUS Server on child sites.

<ParentWSUS> String WSUS Server Name or Virtual IP of the default WSUS Server at the parent SMS site

This property is used by WCM to configure the Upstream Server setting of the WSUS Server based on the SMS Admin choice.

<ParentWSUSPort > DWORD 80 – Default value. Only applies if the upstream server name is not “”Microsoft Update”

This property is used by WCM to configure the Upstream Server Port Number setting of the WSUS Server on child sites.



<SSLDefaultWSUSToParentSite> DWORD 0 – Do not use SSL 1 – Use SSL

This property is used by WCM to configure the Upstream Server SSL setting of the WSUS Server on child sites to use SSL to connect to the upstream server.

<Number of Retries> DWORD 100 – default This property is used by WCM when it retries configuration failures.

<Retry Delay> DWORD 30 – default in minutes This property is used by WCM when it retries configuration failures. This is also used as a periodic timeout to handle periodic tasks.

Software Update Point Site System Role settings in the Site Control File

These properties are defined by the Admin UI and are the Software Update Point Site

System Role settings needed by the WCM for local WSUS Server configuration. Site

Control Manager reads these from the Site Control File and remotely writes to the

…\SMS\WSUS\ registry key on the remote Software Update Point Site System Role

host machine.

BEGIN_SYSTEM_RESOURCE_USE RESOURCE<Windows NT Server><["Display=\\SERVER1\"]MSWNET:["SMS_SITE=S01"]\\SERVER1\> ROLE<SMS WSUS Server Point> PROPERTY <UseProxy><><><0> PROPERTY <ProxyName><><><0> PROPERTY <ProxyServerPort><><><0> PROPERTY <AnonymousProxyAccess><><><0> PROPERTY <ProxyUserName><><><0> PROPERTY <ProxyUserDomain><><><0> PROPERTY <Reserved1><><><0> PROPERTY <AllowProxyCredentialsOverNonSsl><><><0> … END_SYSTEM_RESOURCE_USE


These Software Update Point Site System Role settings are defined in detail in the following table.

Table 23 Software Update Point Site System Role settings


<UseProxy> DWORD 0 – WSUS Server does not use Proxy server to download updates 1 – WSUS Server uses Proxy server to download updates

This property is read by SCM and copies to the registry of the Software Update Point Site System Role host machine. WCM reads this from the registry to configure the WSUS Server locally.

<ProxyName> String Well-formed name of the proxy server to use to download updates. The name must be less than 256 characters. You can specify a host name or an IP address.


<ProxyServerPort> DWORD Port number that is used to connect to the proxy server. The default is port 80. The port number must be greater than zero and less than 65536.




<AnonymousProxyAccess>

DWORD 1 – To connect to the proxy server anonymously (without specifying user credentials) 0 – To connect using user credentials.


<ProxyUserName> String User name to use when accessing the proxy server. The name must be less than 256 characters.


<ProxyDomainName> String Name of the domain that contains the user's logon account. The name must be less than 256 characters.


<Reserved1> String Encrypted PWD of the Proxy account

This property is read by SCM and copies to the registry of the Software Update Point Site System Role host machine. WCM reads this from the registry to decrypt and configure the WSUS Server locally.

<AllowProxyCredentialsOverNonSsl>

DWORD True allows user credentials to be sent to the proxy server using HTTP; otherwise, the user credentials are sent to the proxy server using HTTPS.




<WSUS Log File Path> String Blank – defaults to …\SMS\Logs\WSUS.log Any other location on the WSUS Server


<WSUS Log Level> DWORD 0 – Logging Off 1 – Log Error Messages 2 – Log Error and Warning messages 3 – (default) Log Error, Warning and Info messages 4 – Verbose


<WSUS Log File Size In MB>

DWORD 20 - Defaults to 20000000 bytes (20MB).

This property is read by SCM and copies to the registry of the Software Update Point Site System Role host machine. WCM reads this from the registry to configure the WSUS Server locally. When the current log file reaches the specified file size, WSUS renames the log file to include a ".bak" extension and creates a new log file with the original name. If a log file with the .bak extension already exists, WSUS overwrites the file.

Registry Settings

On SMS Site Server

Site Control Manager maintains the following registry key on the Configuration

Manager Site Server for the WSUS Server Site System Role.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_SITE_COMPONENT_MANAGER\Component Servers\Server Name\Components\SMS_WSUS_CONFIGURATION_MANAGER]


The “State” value under this key is monitored by WSUS Configuration Manager to

check if the role installation was complete.

All WSUS Configuration Manager component based settings are stored under the

following key

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_WSUS_CONFIGURATION_MANAGER]

The following properties are defined under this key.

Table 24. WCM Registry Key settings


Last Row Version

String Last database row version processed by WCM for subscription

This property is used by WCM to read the CI_CategorySubscription table to get the categories that need to be subscribed on the WSUS Server.

Configuration State

DWORD 0 – None (default) 1 – In Process of configuring WSUS Server 2 – WSUS Server Configuration successful 3 – WSUS Server Configuration failed

WCM will maintain this registry value to depict various configuration states. These states can be used by WSUS Sync Manager before synching.

WCM SITE CONTROL FILE CRC

String CRC of all properties in the SITE CONTROL FILE under section SMS_WSUS_CONFIGURATION_MANAGER

WCM waits on this SITE CONTROL FILE change and only needs to process if the CRC has changed

Last SITE CONTROL FILE Serial No.

DWORD The serial number of SITE CONTROL FILE that WCM processed last.

WCM only checks for the change if the serial number of the SITE CONTROL FILE has changed

On the Software Update Point Site System Role host machine

The configuration properties that the WSUS Configuration Manager on the Software

Update Point Site System Role host machine uses to configure the WSUS Server

locally are also maintained in the registry.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\WSUS]

Apart from the WSUS local configuration properties under the above key the IIS port

properties that are used to configure IIS are also defined here. These are populated by


Site Control Manager from the SMS_MP_CONTROL_MANAGER section in the Site

Control File.

"IISPortsList"="80,8080" "IISSSLPortsList"="443" "IISSSLState"=dword:00000000

Once configured the IIS Ports are defined under the following Key.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\IIS]

The Configuration Manager OpsMgr Management Pack monitors each Site System

Role on a server using a registry entry. The WSUS Server Site System role is

registered in the registry under the same key.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Operations Management\SMS Server Role\WSUS Server]

■ Site Code- String value, site code of the site server

■ Version - String value

Configuration Manager WSUS Managed Service Provider (WSUS MSP)

This Managed Service Provider is the COM Component that is used by the unmanaged

Configuration Manager Site Server components. This MSP provides interfaces via

COM interoperability. This is a .NET managed code assembly that calls into the WSUS

.NET API. This MSP provides the interface for the following administration tasks of

the WSUS Server.

From Configuration Manager Client (WSUS Agent) to WSUS Server

Configuration Manager allows the administrator to specify site wide IIS Ports for all

the Site Systems on that Configuration Manager Site Server. These are populated by

the Site Control File on the Remote Site System under the registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\WSUS] "IISPortsList"="80,8080" "IISSSLPortsList"="443" "IISSSLState"=dword:00000000

The WSUS Configuration Manager configures these ports in IIS on the Web Site that

WSUS Server uses, which by default is the “Default Web Site”. WSUS provides a

method to get the custom web site name to set the ports.

In case the administrator chooses to set multiple Configuration Manager Site Roles on

the same server, a common port location is used in the registry:


[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\IIS] "SMSSSLState"=dword:00000000 "SMSPortList"="" "SITE CONTROL FILEPortList"="80,8080" "SMSSSLPortList"="" "SITE CONTROL FILESSLPortList"="443" "SMSPortUsageCount"=dword:00000005

The "SMSPortUsageCount" defines the bitmask of the Site Roles using this IIS port

setting. WSUS Configuration Manager monitors the change to the WSUS registry key

then updates and configures IIS with any change to the port lists.

SSL can be enabled for the clients to communicate with the WSUS Server by setting up

certificates and enabling SSL directly in IIS. In addition, the following properties must

be set in the Site Control File properties via the Configuration Manager Admin UI :

<SSLClientsToDefaultWSUS> and <SSLClientsToINFWSUS>

Subscription

WSUS Configuration Manager running on the Configuration Manager Site Server

remotely subscribes the Categories, Classification and Languages selected by the

Administrator. This subscription information is stored in the Configuration Manager

Database.

Monitoring

WSUS Configuration Manager running on the Configuration Manager Site Server

remotely monitors the WSUS Server periodically for basic health status.

WSUS Configuration Manager (WCM)

WSUS Configuration Manager (WCM) is a component of SMS Executive that runs as

another thread of SMS Executive. WSUS Configuration Manager is installed on the

Configuration Manager Primary and Secondary Site Servers at setup and is always

running on the site server. If a Software Update Point Site System Role is installed on

a remote machine, WSUS Configuration Manager is also installed on that Remote Site

System. This remote installation is done by Site Control Manager.

WSUS Configuration Manager performs the following functions:

■ WSUS Configuration Manager on the Site Server monitors the Site Control File to

read the default WSUS Server Name or a Virtual IP

■ WSUS Configuration Manager on the Site Server monitors the Site Control

Manager Components registry key to verify if the WSUS Server Site System Role


is successfully installed. Based on this key it will remotely configure the WSUS

Server for Subscriptions and Classifications.

Subscriptions and Classifications are stored in the Site Server Database. WSUS

Configuration Manager periodically configures the WSUS Server with these

Subscriptions and Classifications. If a new subscription is chosen in the Admin UI the

database is updated causing SMSDBMON to drop a change notification in the WSUS

Configuration Manager inbox. WSUS Configuration Manager processes this change

and reconfigures the WSUS server.

When WSUS Configuration Manager runs remotely it monitors the WSUS registry key

that is updated by Site Control Manager based on settings in the Site Control File.

These registry settings are configured locally on the WSUS Site System by WCM.

Figure 8. SUM Flow

SMS Primary Site Server

WSUS Config

Manager

(WCM)

SMS SQL

Monitor

(SMSDBMON)

SMS Inboxes

(WCM.box)

SMS SQL

Server

SMS

Provider

SMS Admin UI

SMSDatabase

Subscription

Classification

Subscribe

Products

Classifications

Locales

Change

Notification

Registry

[...\SMS\WSUS]

Registry

[...\SMS\IIS]

Registry

[...\WSUS\State]

Site

Component

Manager

(SCM)

WSUS Install

State

State

WSUS Site System Role

WSUS Config

Manager

(WCM)

WSUS

Server

Install WCM

SMSExec & FDM

Local WSUS

Configuration

(Ports, Proxy, etc)

Local WSUS

Configuration

Local WSUS

Configuration

IIS Ports

Setting

Products

Classifications

Locales

Subscription

IIS

WSUS

Web Site

SMS Inboxes

Site Control File

(SiteCtrl.box)

Local

WSUS

Settings

WCM Config

WSUS Server Name/

Virtual IP

The following flow chart explains the flow of configuration data in and out of WSUS

Configuration Manager


Figure 9. WCM Flow

SMS Executive

starts WCM

Initialize WCM

Register for SMSDBMON Triggers for subscription

change and Site Attach/Detach.

Read registry and SCF for component config info.

Create WCM.box

Initialization

Succeeded?

Failure Status

Message: Cannot

start WCM

No

Yes

Wait for Events

Inbox File change notification

Site Attach/Detach file notification

SCF change

Registry change

File change

Notification?

No

YesSubscription

Change?

Enumerate

Inbox files

No

Yes

Process

Subscription

Change

Site Attach? YesProcess Site

Attach

No

Site Detach? YesProcess Site

Detach

No

Delete

Unknown File

Notification

WCM SCF

CRC

Changed?

No

Yes

Configure

Remote

WSUS

Settings

…\SMS\WSUS\

Registry Settings

Changed?

No

Yes

Configure

Local

WSUS

Settings

Verify WSUS

Configuration

On Time Out

Configuration

Succeeded?

Set

Configuration

State = 2

Yes

Set

Configuration

State = 3

No

Set Wait

Timeout = Retry

Timeout

Subscription

Succeeded?Yes

No


The various actions of WSUS Configuration Manager as shown in the above diagram

are explained below.

Configure Remote WSUS Settings

Settings such as WSUS Upstream Server, Autonomous or Replica modes, are handled

by this action. WSUS Configuration Manager uses the IWSUSServerConfiguration

interface methods to configure these settings on the WSUS Server. WSUS

Configuration Manager reads these settings from the Site Control File section of

SMS_WSUS_CONFIGURATION_MANAGER.

Before saving the new configuration on the WSUS Server, WSUS Configuration

Manager sets the Configuration State to 1 meaning the Configuration is in progress.

When the configuration succeeds the State is set to 2. If the configuration fails the

State is set to 3.

In case the Sync is in progress on the WSUS Sever and configuration cannot be saved

it is treated as “In Progress” i.e. State = 1 and the configuration is retried again after

the retry interval.

If the WSUS Synchronization Manager fails when it tries to sync and the Configuration

State is not 2 then WSM will retry.

If WSUS prerequisites such a IIS or .NET Framework are not met, WSUS Configuration

Manager sends a failure status message.

Configure Local WSUS Settings

Settings such as Proxy and Ports, are handled by this action. WSUS Configuration

Manager on the Software Update Point Site System Role uses the

IWSUSServerConfiguration interface methods to configure these settings in the WSUS

Server. WSUS Configuration Manager reads these settings from the registry under key

…\SMS\WSUS\.

Process Subscription Change

Settings such as Categories, Classifications, and Languages, are handled by this action.

WSUS Configuration Manager uses the IWSUSServerSubscription interface methods

to subscribe these categories in the WSUS Server. WSUS Configuration Manager reads

these settings from the CI_CategorySubscription table.

Similar handling of Success, Failures and Retry is done as described in the

Configuration section above.


Process Site Attach and Detach

Upon receiving notification of a site attach, the parent site sends it’s Default WSUS

Server Name via Site Control File to the newly attached child site that needs to be its

Upstream WSUS Server. Upon receiving this Site Control File change, if the child site

has a Software Update Point Site System Role, WSUS Configuration Manager changes

the configuration so the WSUS Server is a Replica and uses the new Upstream WSUS

Server.

When a site detaches the change is received by WSUS Configuration Manager and it

alters the upstream server to be “Microsoft Update” in the Site Control File. It also

sends a Status Message saying that there is no upstream server. Once that occurs, the

administrator should change the WSUS configuration to Autonomous in the Admin UI.

WSUS Configuration Manager will then configure this WSUS Server as the root server.

WSUS Configuration on Timeout

All WSUS Configuration needs to be verified and monitored for failures periodically

and WSUS Configuration Manager does this every hour or based on the setting in the

Site Control File.

WSUS Database Monitoring

The interface for health monitoring has methods periodically called by WSUS

Configuration Manager:

■ TestDatabaseConnection

■ GetComponentsWithErrors

Status messages are reported if any of the calls fail.

SMS_WSUS_CONFIGURATION_MANAGER Registry Configuration Class

WSUS Configuration Manager on the Configuration Manager Site Server maintains

settings under the registry key [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_SITE_COMPONENT

_MANAGER\Component Servers\Server

Name\Components\SMS_WSUS_CONFIGURATION_MANAGER]


WSUS Subscriptions

After the WSUS server is successfully installed on the central Configuration Manager

site, WSUS Configuration Manager retrieves.the root Categories of Products and

Classifications and supported locales from the WSUS Server.

WSUS Configuration Manager registers for a database trigger with SMSDBMON. Upon

any change to this table SMSDBMON drops an empty notification file

<CategoryID>.CTN into the WSUS Configuration Manager inbox. WSUS Configuration

Manager queries the CI_CategorySubscription table for the changed entries and then

configures them accordingly in the WSUS Server.

WSUS Server Locations

The following table stores the WSUS locations of WSUS Servers in the Configuration

Manager Hierarchy. These are the locations that are returned by the Management

Point (MP) when the client requests them. HMAN populates these WSUS servers by

reading the Site Control File(s) for all sites. HMAN updates this table when the Site

Control File changes and also during Site Attach. At site detach the WSUS Server

entries are deleted via the Sites_del database trigger. For a location the MP Stored

Procedure joins this table with the Sites table and the Boundaries table to return the

WSUS location for the assigned site and if needed the secondary site.

Table 25 WSUS Server Locations

Column Name Type Length Allow Nulls

Key Description

WSUSLocationID Int 4 No PK ID for the Category Item

WSUSLocationUniqueID Varchar 255 No e.g. <Site Code>:<UpdateSourceGUID>

SiteCode Varchar 3 No Site Code of the WSUS Role

WSUSServerName Varchar 64 No WSUS Server Name OR NLB Virtual IP

WSUSType Bit 1 No 0 – Server Name 1 – Virtual IP

IsINF Bit 1 No 0 – Intranet 1 – Supports Internet clients

IsSSL Bit 1 No 0 – Non-SSL 1 – SSL


Column Name Type Length Allow Nulls

Key Description

IISPort Int 4 No Port used by the WSUS client to talk to the WSUS server

IISSSLPort Int 4 No Port used by the WSUS client to talk to the WSUS server over SSL

rowversion timestamp 4 No SQL rowversion

Replica Vs Autonomous modes of WSUS Server

Administrators can specify if a server replicates an upstream server when installing

WSUS and this setting cannot be changed. This type of server is called a Replica

server and it cannot be switched to an Autonomous server but an Autonomous server

can be changed to a replica server.

A downstream server can be an autonomous server or a replica server. An

autonomous server synchronizes the same updates as the upstream server; however,

it can create its own target groups and manage its own approvals, and can download

content from Microsoft Update or from the upstream server.

A replica server replicates the upstream server, synchronizing the same updates,

using the same target groups, approvals, accepted license agreements (EULAs) and

declined status as the upstream server. The downstream server cannot create it’s

own target groups or manage it’s own approvals and it cannot download content

from Microsoft Update. In addition, Automatic approval rules are disabled.

Administrators can only view the status of the replica servers clients from that

server.

Scenarios

Site Attach – Detach scenarios

Scenario 1: Create the Software Update Point on the Central site

The Administrator is presented with the Software Update Point UI. The Software

Update Point settings selected by the Administrator are saved in the Site Control File

by the Admin UI, which triggers Site Control Manager. Site Control Manager

bootstraps the WSUS Configuration Manager installation. Any errors in installation

are flagged by Site Control Manager via status messages. If the installation fails, by

default, Site Control Manager will retry every hour. Once the installation is successful

a success status message is sent by Site Control Manager.


The Administrator sets the Default WSUS server during the Software Update Point

installation which in turn sets the <DefaultWSUS> parameter in the Site Control File.

WSUS Configuration Manager monitors the file, and when this parameter changes it

updates the Site Control File on child sites with the following properties:

■ Sets the arentWSUS property with the server name. I

■ Sets the ParentWSUSPort and SSLDefaultWSUSToParentWSUS

WSUS Configuration Manager on the Software Update Point reads and monitors the

local …\SMS\WSUS\ registry key for local configuration. WSUS Configuration

Manager uses the WSUS MSP and configure the local settings. In case of failure it

retries the configuration and sends a failure status message. WSUS Configuration

Manager waits for changes to this key y to reconfigure and periodically verify

configuration.

On the Configuration Manger Site server the WSUS Configuration Manager monitors

the Site Control Manager’s component state in the registry. When Site Control

Manager successfully installs the Software Update Point, WSUS Configuration

Manager connects to the remote WSUS Server and configures remote settings from

the Site Control File. It configures the upstream server which in this case is WU/MU

and sets it in Autonomous mode. In case of failure it retries the configuration and

generates a failure status message. Reconfiguration and configuration verification are

performed when changes are made to the Site Control File for the Software Update

Point. Subscriptions are defined in the Configuration Manager Database and are used

by WSUS Configuration Manager to subscribe to the WSUS Server.

Scenario 2: Create a Software Update Point on the primary child site

The Administrator chooses to install the Software Update Point on a Primary Child

Site in the Admin UI. After all the settings are specified, the Admin UI checks to see if

the ParentWSUS property is set in the Site Contol File because it is a Primary Child

site. If this propery is not set the Admin UI displays WU/MU as the default choice. If

the propery is set the Parent WSUS server name appears in the UI as the default

choice for the upstream server. The rest of the installation proceeds as it did in

Scenario 1.

Scenario 3: Disable a Software Update Point on a site

When the Software Update Point role is disabled, the Admin UI displays a dialog

stating “Downstream WSUS servers will not work if you disable this role”. The

downstream servers are not be disabled or uninstalled automatically.

Site Control Manager runs the un-install for the Software Update Point role. Upon

successful un-installation, WSUS Configuration Manager blank s out the DefaultWSUS


property in the Site Control File on that server and blanks out the ParentWSUS

property in the Site Control File on any child sites. Upon receiving this Site Control

File change, the child site sends an error status message that the Upstream Server is

no longer available and the Software Update Point on this site will not work.

Scenario 4: A new Software Update Point is recreated on the central/parent site

This invokes the same actions as Scenario 1 with the new Upstream Server Name

being sent to the child site. WSUS Configuration Manager on the child site

reconfigures the WSUS Server with this new Upstream Server.

Scenario 5: Child Site is detached from the parent site

WSUS Configuration Manager handles this site detach and blanks out the ParentWSUS

property in the Site Control File. The Site Detach also generates a failure status

message that nstructs the Administrator to take action.

The Administrator can choose WU/MU as the Upstream WSUS Server and set the

UpstreamWSUS property as Microsoft Update in the Site Control File. This action

causes the Software Update Point on the child site to be reconfigured to Autonomous

mode.

Scenario 6: Child Site is attached to a parent site

When a child site is attached to a parent site, WSUS Configuration Manager updates

the ParentWSUS property in the Site Control File and generates a failure status

message to alert the Administrator that action needs to be taken. The Administrator

needs to change the setting for the upstream server on the child site from WU/MU to

the new upstream server name. This action causes WSUS Configuration Manager to

set the UpstreamWSUS property in the Site Control File and the child site and

reconfigure it for Replica Mode.

Scenario 7: SMS Admin creates another Software Update Point on the same site

behind a NLB.

When there are multiple WSUS servers in an NLB configuration, the Administor must

set the Virtual IP address by using the Site Wide WSUS Server Component

Configuration. The Virtual IP is stored in the Site Control File as the DefaultWSUS

property and the DefaultWSUSType is set to 2 for Virtual IP. WSUS Configuration

Manager processes this Site Control File change and updates the Site Control File on

child sites by setting the ParentWSUS property with this Virtual IP. WSUS

Configuration Manager uses this Virtual IP for administration and also configures the

child site WSUS Servers to use this Virtual IP as the upstream server. When the WSUS

servers are no longer in an NLB, the Administraor will unselect the Virtual IP and


choose the Upstream Server using the Site Wide WSUS Server Component

Configuration UI.

Content hashing

All supported update sources provide update metadata containing individual file

hashes for the update files. Current SMS 2003 content hashing is done per content

folder, accumulating a single hash from the file names and the file data in the folder.

This means we cannot generate SMS 2003 hashes from the hashes provided by the

update sources.

To be able to provide content verification a new hashing algorithm was created to

hash the content based on idividual file hashes. It is hash version 3

(SMS40_HASH_VERSION), and works as follows:

■ for each content file (file in the content folder) create a string of the form:

file_name ‘:’ file_ hash ‘;’

■ uppercase the strings to avoid character case affecting the hash.

■ sort the resultant string list alphabetically to avoid file ordering affecting the

hash.

■ hash the sorted string list as a single data stream

Versioning of content metadata

Content versioning is based on detecting changes in the content hash. Content hash is

reevaluated every time there is a change in the associated file set. A set of triggers on

the CI_ContentFiles table detects these changes and marks the corresponding content

record for rehashing.

The hashing and versioning is done by a task, part of the CI Manager, which executes

every 1 hour or on demand, and enumerates all CI_Contents records having

ContentHashVersion set to null. For each such record the task performs the following:

■ hash the content with the new hashing algorithm, using file hashes from

CI_ContentFiles table

■ compare the hash with the current ContentHash

■ if hashes are different, increment ContentVersion and set ContentHash to the new

hash


■ set ContentHashVersion to SMS40_HASH_VERSION (3)

Since content versioning depends on detection of changes in the hash, it is possible to

introduce content version inconsistencies in the hierarchy if the hashing/versioning

is done independently by the sites. To avoid this, the sites hash and version only

content for which they are the source sites, and the CI Manager will not replicate

unhashed content (with null ContentHashVersion).

Versioning of content in packages

SMS 2003 did not support update content versioning, so there is no information in

the legacy tables about the content versions inside the associated packages.

To evaluate content versions inside packages, upgrade sets the migrated record

ContentVersion to -1 to indicate the version is unknown, then the actual content

versioning is done by a task, part of the Distribution Manager, which executes every

24 hours or on demand. It enumerates all CI_ContentPackages records with

ContentVersion set to -1 and a non-null ContentHashVersion in the corresponding

CI_Contents record. For each such record the task performs the following:

■ calculate the hash of the packaged content using the hash version algorithm

specified in the CI_Contents record, using theactual hashes of the content files in

the package.

■ compare the calculated hash with the corresponding CI_Contents.ContentHash

■ If the hashes match, set ContentVersion = CI_Contents.ContentVersion

■ If the hashes don’t match, set ContentVersion = 0 (content is out-of-date).

The content version can be used to verify and restrict deployment of outdated

content:

■ when a client requests an update content location, it receives only locations

containing up-to-date content

■ when a deployment is configured or initiated in the UI, the UI verifies that the

package content is up-to-date and notifies the admin if any content is outdated.

■ when advertisement for a SMS2003 deployment is to be run, the offer manager

can verify if the package content is up-to-date and fail with a status message if

not.


Software updates’ assignments

In Configuration Manager updates are deployed via assignments. Update assignments

have optional legacy deployment properties, which define assignment’s deployment

to SMS 2003 clients. The legacy deployment for the assignments is maintained by the

SMS provider for the update assignment class. It is done by maintaining legacy

programs and advertisements owned by assignments.

To allow assignments to own advertisements, programs and authorization lists, a link

toadvertisements with owning assignments was created using a new field in the

ProgramOffers table, named AssignmentID. Owned programs and authorization lists

are named after the assignment unique id.

Advertisements also have a new field, AssignmentID, which shows their owner

assignment. A value of 0 indicates advertisements not owned by assignments. Owned

advertisements are shown only for troubleshooting, SDK cannot create, modify or

delete an owned advertisement.

Similarly the Packages have a ContentType field which indicates what type of content

they hold. Currently the content is software (0) and updates (1). An updates package

shows no programs and SDM is not able to create programs for it.

Managing legacy deployments for assignments

A new WMI class, SMS_SoftwareUpdatesAssignment, extends the DCM assignment

object with update-specific aspects, including legacy deployment. When legacy

deployment is enabled for the assignment object, the provider transparently creates

and manages the associated programs and advertisements based on the assignment

object deployment options. All associated database changes are performed as a single

transaction when the assignment object instance is written to WMI.

To avoid synchronization issues when multiple advertisements share the same

program, copy on write was implemented with programs and authorization lists:

initially assignments refer to them as they are. When assignment propertie changes

requires modification of the program or authorization list, the provider creates an

assignment-owned copy of the program and/or list and applies the changes there.

When an assignment is deleted, theprovider deletes owned advertisements,

programs and authorization lists.

Software updates compliance

Updates compliance status is collected and summarized in two new tables: one

collects update status per machine (Update_ComplianceStatus); the other


summarizes update status per collection (Update_ComplianceSummary). The

Update_ComplianceStatus table contains the individual update status per client.

Table 26. Update_ComplianceStatus table

Value Type Description

UpdateID Int not null Update ID

ItemKey Int not null Client ID

IsLegacy Bit not null Status comes from legacy LastStatus

LastStatusScanTime Datetime null Last time status scanned

LastStatusChangeTime Datetime null Last time status changed

LastStatusMessage Int null Last status message

LastStatusMessageTime Datetime null Last status message time

LastInstallMessage Int null Last install message

LastInstallMessageTime Datetime null Last install message time

The LastStatus field contains the update status on the machine, as one of:

■ 0: Unknown – client status unknown (not reported)

■ 1: NotApplicable – update not applicable on client

■ 2: Present – update found

■ 3: Missing – update not found

■ 4: Installed – update was installed by SMS

■ 5: Failed – update installation by SMS failed

Updates not listed in the Update_ComplianceStatus table are of Unknown status.

Additional details like install failure, reboot required, etc., can be found in the

LastInstallMessage field.

The Update_ComplianceStatus table is populated from the DCM CI compliance status,

the SMS 2003 hardware inventory, and from software updates installer status

messages.


WSUS Sync Manager

WSUS Sync Manager (WSM) is a site server component that runs inside the SMS

executive service. The component behaves differently depending on whether it is

running on the top site or on a child site.

Sync on the top site

On the top site, WSM can execute on a schedule or on demand. The admin UI exposes

sync scheduling and a "Sync Now" request. The schedule is stored in the Site

Configuration File. When WSM performs a sync, it initiates a WSUS server sync and

waits for it to finish. When the server sync is done, if there are changes since the last

sync, WSM inserts the changes into the Configuration Manager database and

increments the content version, then notifies the child sites to sync to that version.

Sync on a child site

On a child site, WSM syncs upon receiving parent notification. The admin UI does not

expose sync scheduling but does expose "Sync Now". When WSM performs a sync, it

initiates a WSUS server sync and waits for it to finish. When the server sync is done,

WSM sets its content version to the same content version as it’s parent, then notifies

its own child sites to sync to that version.

Note

This versioning schema works only if all sites ultimately sync from a single source, directly or as replicas. This means that all WSUS servers on child sites must be configured as replicas of their corresponding parent site WSUS servers.

Failures and retries

In case of a sync failure, WSM enters a retry mode, governed by two properties

defined in the Site Configuration File: Retry Interval and Retry Count. Retry Interval

configures the interval between retries, and Retry Count configures how many times

to retry before giving up.

Site WSUS (re)configuration

WSUS server should not be synchronized until it is completely configured. For that

reason WCM exposes a registry value, that reports on the configuration status of the

WSUS server. WSM sync fails if the WSUS server configuration is not completed.


Site attach/detach

On site attach, child site WSM will set its content version to 0 and try to resync as

soon as the WSUS server configuration is complete.

On site detach, WSM will not perform any special actions. The WCM component on

the child site should mark its server as unconfigured, which will prevent WSM from

syncing until the server is reconfigured.

Content version on the clients

The client scan agents receive the content version as a part of the scan tool policy and

report it back in the scan status and/or HINV messages. Every time content versions

change on the server, WSM triggers the policy provider to regenerate its scan tool

policy.

Before the WSUS server is synced for the first time, initially or after a site attach, its

content is unknown. WSM indicates this with content version 0. Since all updates are

introduced with scan content version 1 or above, a scan with content version 0 will

automatically deduce on the server that the state of all unreported updates is

Unknown.

Site Control File properties

WSM is represented with a new component section in the site control file, with the

following properties:

■ Sync Schedule: string – contains the schedule on which the sync is performed.

■ Sync Retry Count: dword – contains the number of times WSM should retry on failures.

■ Sync Retry Interval: dword – contains the time inverval between retries on failures.

■ Registry

■ The WSM component registry key contains the following values:

■ Content Version: dword

■ Sync Parent: string

■ Sync Time: dword

■ Last Attempt Status: dword

■ Last Attempt Number: dword

■ Last Attempt Time: dword

■ New Content Version: dword

All are internal values used to maintain sync status between executions.


WSM component

WSM is implemented as a new component of the SMS executive service. It is installed

only on Configuration Manager Primary Site Servers during setup and is initially set

to disabled. The component registers itself to receive site attach/detach notifications.

Main loop

In its main loop it performs the following:

■ Set next attempt to never.

■ if Last Attempt Status is not zero, and Last Attempt Number < Sync Retry Count

or on a child site, set next attempt time to Last Attempt Time + Sync Retry

Interval. Set sync reason to "Retry".

■ if on top site, and next scheduled time < next attemt time, set next attempt time to

next scheduled time, set sync reason to "Schedule"

■ process inbox files until next attempt time is reached. If a sync is requested, set

inbox processing will leave early

■ if termination request received, leave

■ if sync reason is "Retry" increment Last Attempt Number, else reset it to 0

■ if New Content Version <> 0, perform sync action

■ Processing inbox files

■ Processing inbox files performs the following steps:

■ Process site attach/detach notifications in time order

■ Add all attached children to a new children list

■ Remove all detached children from the children list

■ Set new parent site to the current parent

■ When done with notifications, if new parent site <> Sync Parent, set Sync Parent

to the new parent site, set Sync Time to site attach time, set Content Version to 0,

set New Content Version to 0, send sync notification to all children.

■ If new child list is not empty, send sync notification to each new child, then insert

the new children in the children list.

■ Drop all messages older than Sync Time


■ If a "Sync Now" message is pending, set sync reason to "Request"

■ if a parent sync messages is pending, from the (new) Sync Parent, set sync reason

to "Request", set New Content Version to the version from the latest parent sync

message.

■ Repeat until timeout is reached or sync reason becomes "Request".

■ Sync action

■ Main sync action code

■ When sync is executing, it perform the following steps:

■ Remember the action start time. It is put in the Sync Time if the rest of the sync

succeeds.

■ Check with WCM if the WSUS server is configured and ready for sync. Fail if it

isn't.

■ Get from WCM a pointer to the WSUS Server and subscription.

■ Initiate sync on the WSUS server/subscription. Wait for sync completion by

polling the sync status. While WSUS is syncing, respond to progress requests by

reporting the WSUS progress. Report half progress on top sites, the other half will

be syncing with SMS database.

■ If on top site, get updates changed since Sync Time. If the list is not empty set

New Content Version = Content Version + 1, synchronize the changes in SMS

database

■ Set Last Attempt Time = action start time, set Last Attempt Status = sync attempt

status

■ If sync succeeds set Sync Time to the action start time, set Content Version = New

Content Version, send a WSUS content update state message to self, and send

sync messages down to all child sites.

Synchronizing updates into Configuration Manager database

On the top site the sync action synchronizes the WSUS server changes into the

Configuration Manager database. The synchronization procedure requests a list of all

updates received after the last sync time from the WSUS server using the GetUpdates

method. The list it receives represents all new and changed explicitly-deployable

(XD) updates. Nested XD updates are processed recursively. XD updates are self


sufficient and contain a full set of properties. Non-deployable updates can

(optionally) override only the language list of its enclosing bundle.

■ The sync code processes each XD update as follows:

□ If PublishedState equals Published, the sync code inserts/updates the item in

the database as follows:

□ Compare revision/timestamp with item in Configuration Manager database.

If item exists and is up-to-date, skip it.

□ Collect its properties, including localized data in each requested language

(might require multiple calls for localized properties per update).

□ Collect associated content files

□ Insert/update item in the database. Un-tombstone if necessary.

■ Process all bundled non-XD items as follows:

□ New item will have no properties

□ If the item has its own language list, use it, otherwise copy parent's language

list.

□ Collect associated content files.

□ Insert/update item in the database. Un-tombstone if necessary

□ Insert/update a bundle relationship in the database

□ Descend into item's own bundled items and repeat the process.

□ Process all bundled XD updates same way as the current update. After

processing a bundled update, insert a bundle relationship for it

□ If PublishedState equals Expired, sync code should mark the item and all its

bundled non-XD children as Tombstoned in the database.

All tombstoned items are maintained until they reach at certain age at which point

hey6 are deleted. The Database trigger disallows any changes to tombstoned items,

unless the change also removes the tombstoned status.

State messages collection

WSUS content versions are tracked for reporting purposes. Version changes are

reported by state messages and propagated up to the central site. Messages are


processed by database code independent of WCM/WSM, and data is stored in a new

table with the following structure:

Table 27 Sync State Message Table Schema

Column Type Nullable Key

UpdateSource_ID int No Yes

Site Code varchar(3) No Yes

Version int No

Date datetime No

Rowversion rowversion No

Offline sync tool

The offline sync tool backend already has some support for bundles and was

extended to support WSUS bundles.

The WSUS offline catalog parser was modified in the following aspects:

■ The node-processing filter includes bundle nodes

■ Non-XD nodes do not define any properties but product and language

associations.

■ All code refering to the properties in the immediate parent bundle was either

removed, or changed to refer to the properties of the closest XD node (including

self).

■ Code defines bundle relationships between nodes and their immediate parents.

The offline sync tool SDM Package XML generation was extended to support multiple

update sources.

Updates Store

This is a component in CCMExec that stores and reports the status of updates to the

MP. The Updates Store replaces Scanwrapper.exe. The ScanAgent (formerly

SMSWusHandler and now also part of CCMExec) insures that updates status reported

by the scanner is delivered to the Updates Store.


Architectural Overview

Figure 10. Update Store Architecture

UpdatesHandler

UpdatesStore

ScanAgent

ICC

MU

pd

ate

Eva

lua

tor

IUp

da

tesS

tore

Evaluate

Updates

Set Update Status/

Evaluate Updates

CCM Framework

Report Update Status to

MP

WMI:

Root\Ccm\SoftwareUpdates\

UpdatesStore

Set/Read

Update Status

The main operations of the UpdatesStore are the following:

■ Add/Change Update Status

■ Evaluate Update Status

■ Report Update Status to MP

■ Storage of Update Status

■ Add/Change Update Status

The setting of update status is performed by the ScanAgent, as it receives the status

back from the calling scan on the available scanners. Then it calls IUpdatesStore and

report the status through SetUpdateStatus().

The ICcmUpdateStatus class contains the following properties to be used in setting

update status:

■ Update_UniqueId

■ RevisionNumber

■ Status

■ LastUpdateSourceId

■ LastUpdateSourceVersion

■ LastScanTime


Additional informational properties, such as Bulletin, Title, Article Number, and

Language

The UpdatesStore uses the above mentioned properties to set the status in the WMI

repository.

Evaluate Update Status

Looking at the LastUpdateSourceId, the UpdatesStore is able to determine which

Update Source should receive the status of the update. If the update is not found,

then it no changes are made to the status. If it is found, the Status property of the

ICcmUpdateStatus object is changed.

If there are multiple Update Sources specified in the ICcmUpdateStatus object, then

ScanAgent is responsible for fill ing in the following properties before passing the

object to UpdatesStore: Status, LastUpdateSourceId, LastUpdateSourceVersion and

LastScanTIme. This information is necessary in order to evaluate the status of an

update. if an update that comes from an Update Source, which ScanAgent never

scanned with, the status of the update is set to UNKNOWN this information is

returned to the caller, without going through UpdatesStore. However, if the Update

Source was used, then ScanAgent sets the status to Not-Applicable, and passes it to

UpdatesStore. If the UpdatesStore does not find that Update, it will not change its

status. Thus, the caller will receive Not-Applicable status on an Update that was

scanned with its Update Source (and the Update Source had at least the Minimum

Required Version that the update requires), but was not found by UpdatesStore.

Report Update Status to MP

Reporting to the MP occurs immediately after a scan is completed and the results

have been passed onto UpdatesStore. When the UpdatesStore receives the update

status, it first compares it to what it has stored in its own repository, and if an update

status has changed, it raises a status message, and then finally update its own

repository. The main messages it sends is “Installed” or “Missing”, and rarely Not-

Applicable.

The only scenario where not-applicable status is raised is if the UpdatesStore receives

a new set of updates’ status, and the number of applicable updates is less by 1 (or

more) update, compared to the previous scan with that same update source. That

update that has turned from applicable to not-applicable is still in the UpdatesStore

repository in WMI. The UpdatesStorel ook s for that update (or any updates that are

not part of that set, but were previously), and it removes the status of that Update

Source from the WMI repository, then reports a not-applicable status message to the

MP. This should be the only time not-applicable status messages should be sent.


Storage of Update Status

The status of updates being set through the IUpdatesStore interface is to WMI for

storage. The namespace that used is under SoftwareUpdates;

Root\Ccm\SoftwareUpdates\UpdatesStore

Class CCM_UpdateStatus { [key] String UniqueId; [key] Uint32 RevisionNumber; String Title; String Language; String Bulletin; String Article;

CCM_SourceStatus Status[]; }

Class CCM_SourceStatus { [key] String SourceUniqueId; DateTime ScanTime; Uint32 SourceVersion; }

Each unique update, defined by its unique id and revision number, has an instance of

CCM_UpdateStatus. Each Update Source that sets the status of that update will add, or

if it exists already, modify the CCM_SourceStatus instance. So if there was a scan done

with the offline catalog, and then a scan done with the WSUS Server, an update that

exists in both Update Sources will have 2 CCM_SourceStatus instances inside it, each

specific to the Update Source.

Software Updates Deployment Job

This job represents the aggregate of all the updates belonging to an assignment. This

job is created at the following points:

To check the compliance for the update CIs.

To remediate by downloading/installing a list of updates.

The Software Update Deployment job is persisted in WMI under the

\\root\CCM\SoftwareUpdatesAgent namespace. The Software Updates Deployment

job contains the following fields:


Table 28 Software Updates Deployment Job Fields

Field Persistent Purpose

JobID Yes Key field identifies job. Usually a random GUID will be used and a local software dist policy will be generated.

spInitiatorCallback No Callback to the client component like SDM

spExecMgrCallback No Callback to notify execution manager for the completion of installation.

JobType Yes Possible Values: Install, ScanOnly

JobState Yes Possible Values: WaitScan, ScanComplete, WaitContent, Ready, VerifyScan, Running, Complete

JobAction Yes Install or Uninstall

UpdatesList Yes List of updates belonging to this job.

The Software Updates Deployment job creates its child update objects through UpdatesManager .

Release of a deployment job also releases individual update objects. Most of the actions assigned to the

individual updates are asynchronous in nature, meaning the update object is responsible for notifying

the parent job of the completion of the task.


Figure 11. Software Update Scan Flow

[Request (compliance, download )

]

WaitContent

Ready

[DownloadCompleted]

Running

[Advertisement Started]

Complete[InstallationComplete]

WaitScan

ScanComplete

[Status Check / No Updates Applicable] [Release]

[Release] VerifyScan

[No Updates Applicable]

Software Update Manager (SUM)

Software Update Manager is a new server side component which is responsible for

replicating all the data related to an update. This component is also responsible for

replicating the Scan_Tool table which contains information about the source of an

update.

When the SMS provider updates the Scan_Tool properties it notifies SUM about the

change in scan tools. The provider generates the notification to SUM by adding a row

to the Scan_Tool_Notification table. SUM picks up the change and replicates the scan


tool properties and the first update belonging to the scan tool as part of a .UPD file

sent down the hierarchy. In order to replicate scan tools a .UPD file is always used

and the first update belonging to the scan tool is used as the candidate for replicating

scan tool properties. SUM also notifies the policy provider of this change so it can

generate the scan tool policy.

Software Update Manager is only responsible for replicating scan tool information

required for the update it is replicating. When Software Update Manager replicates

scan tool instances it uses the ToolUniqueID to determine if a tool already exists at

the child site. If a matching instance exists of the replicated tool at the child site it

comparesthe source site of the tool being replicated with the source site value of the

instance at the child site. If they match a comparision is done if there is a change in

the instance. When a change is detectedin an instance the instance is updated and

policy provider is notified of the change. if source sites for the tool are different from

what’s being replicated the instance is updated with new values and a status message

is raised stating the tool and it’s related updates are no longer available for editing at

the child site. SUM then notifies the policy provider of the change so it can generate

the appropriate policy. SUM does not wait for a scan package to replicate before

inserting a scan tool instance as policy provider cannot generate a scan policy for a

tool whose package does not exist.

To prevent conflicting information regarding a scan tool replicated in the multiple

.UPD files from being added to the database, a DataModified time stamp is used to

determine whether or not to update the ScanTool table. If the source site for scan tool

information is different from that contained at the current site SUM overwrites the

scan tool information with what was replicated, including the source site. If the

source site is the same, the DataModified is compared and if newer then SUM

overwrites the existing scan tool information in the database with the replicated data.

If a site is detached, it becomes the owner of the scan tool and the source site of all

scan tools is set to the current site. Administrators doe not have to re-install the scan

tools at the detached site in order to make then fully functional. If the site was

detached in order to attach it to a new site in the hierarchy then it is recommended

that administrators do not install scan tools if any of the parent sites in that hierarchy

already have the same scan tool installed.

Policy Provider

Each time Policy provider is modified to enable creation of scan tool policy. This scan

tool policy allows clients to determine what scan tools are available to perform scans

with. The policy provider generates scan tool policy using the class CCM_ScanTool.


There are multiple instances of CCM_ScanTool residing in one policy body. The Scan

Tool policy body is targed to all machines reporting to the site. Each instance of

CCM_Scantool can have an applicability condition which is queried from the

ApplicabilityCondition column in the Scan_Tool table. Policy rules that have a NULL

or empty WMI condition are grouped together under one policy rule body. Policy

instances that contain a WMI condition are grouped in individual policy rule bodies.

All policy rule bodies are grouped into one policy body.

All attributes of the CCM_ScanTool class match to corresponding columns in the

Scan_Tool table with the exception of the ToolPackageVersion attribute which maps

to the SMSPackages table. Policy Provider does not generate an instance of scan tool

policy if the tool requires a Configuration Manager package and the corresponding

package either does not exisit at the site or is marked for deletion.In addition policy

provider should also not generate policy for those scan tools which are marked for

removal. Scan tool packages corresponding to a scan tool could be missing if the scan

tool was removed or there is latency in package replication. The latter should never

be an issues on the source site where the scan tool was installed.

Policy provider generates scan tool policy based on following two events:

■ When policy provider detects a package change notification being generated from

Distribution Manager it evaluates the change to determine if it will cause a

change in the scan tool policy. Deletion of the package or a change in the package

source version will cause a change in scan tool policy

■ SUM notifies policy provider whenever it detects a change in the scan tool table.

In order to notify policy provider SUM s place a file with name the [Internal Scan

Tool ID].STN in the policy provider inbox. Policy provider picks up this

notification and extracts the internal ID of the scan tool from the notification

filename. It reads the instance of the scan tool from the database and compares it

with the corresponding in-memory CRC for the same instance of the scan tool. If

any change is detected or it detects a scan tool instance being added or removed

it regenerates a new scan tool policy body with all scan tool instances.

Scan Agent in the Configuration Manager Client

The Scan Agent is a new Configuration Manager client component that exposes and

interface allowing other client components to request a scan using a set of scan tools.

The following flow chart diagrams this process:


Figure 12. Scan Agent Flowchart

Scan tool

requested

count > 0

Scan requested for

one or more tools

Request scan for a

particular tool

ForceScan is

TRUE

Scan Results

Expired

Request Scan

content

Launch scan

Notify scan

completion status

Complete

Execution Manager requests

scan on scan tool

advertisement schedule

Software Update Agent requests

scan when asked for

compliance check or installation

Policy agent notifies of scan

policy change

Has scan

content

changed

Get scan tool corresponding to

advertisement scheduleYes

No

Yes

Yes

No

Yes

No

No

Wait for

scan

results

Scan agent client components use the ICCMScanAgent interface to make calls to the

following methods to perform different actions.


Scan by Tool

This method is used by client components like the Software Update Agent to request

a scan for a set of scan tools. The Software Update Agent filters the list of tools from

the updates they are managing and passes on the clients scan request to the Job

Manager for processing.

Scan by Type

This method is used by client components to request a scan for all scan tools

supported for a particular scan type. This method will look at all the scan policies to

retrieve all tools which support requested type of scan. It will then ask scan job

manager to perform scan with those tools.

Scan by Content

This method is used be client components to request scans based on the Content ID.

This method is mainly used by the Execution Manager component of the client. For

Execution Manager the Content ID is always equal to the ID of the Software

Distribution Package that corresponds to the scan tool. This method looks at all scan

policies to filter out a set of scan tools which share the same content ID. It then sends

a request to the Scan Job Manager to perform a scan with those tools.

Interface ICCMUpdateEvaluator

This interface is implemented by the CScanAgent class. The primary purpose of this

interface is to return compliance status of updates.

Scan Job Manager

This class manages all scan jobs based on requests made from other components.

Scan Job Manager is responsible for maintaining a list of scan jobs and managing the

state of the job. The Scan Job Manager also updates scan results upon the completion

of a scan job. If a scan is executed that contains multiple sources, any failures are

overwritten with successful scan results.

If a scan fails for an update source, all associated update status is populated based on

the last known status. The caller uses HResults per update to determine whether the

status is the latest one.


Figure 13. Scan Job State Diagram

In Progress

Scan Job State Diagram

Scan Job

Complete

Scan jobs are not persistent, however the global force inventory flag for a scan job

will persist. Scan Job uses this flag to determine whether or not to force an inventory

cycle. By default the flag bforceInventory is set to TRUE whenever a scan job is

requested. The flag gets reset when the inventory cycle completes.

Scan Complete

When a scan is completed the ScanComplete method notifies Scan Job Manager. The

Scan Job Manager re-evaluates all scan jobs which contain the Scan Tool ID of the

completed scan to determine if all the jobs using that scan tool are completed. If all of

the jobs have finished Scan Job Manager releases the scan tool and sends notification

that the jobs are complete. Completed jobs are removed from Scan Job Managers list

and if the global force inventory flag is on and all jobs are completed, Scan Job

Manager initiates the inventory cycle then sets the flag to false when the cycle is

complete.

Scan Tool Manager

The purpose of this class is to manage scan tools and support instantiation and

scanning using installed scan tools.


Add Scan Tool

This method will be called by Scan job manager to add a scan tool for scanning. This

method will take scan tool id and bForceScan flag as input and will return an

HRESULT as output. This method will first check if there is an existing instance of

scan tool running with same ToolID. If there is one it will just increase the reference

count for that particular scan tool and will return with result S_OK. If an instance of

scan tool is not already running then it will check scan tool history from registry to

check the last time this scan tool was run. If scan tool was executed in past then its

last updated time will be compared with the duration the scan results can be valid for.

This duration will be called Time to live for scan results or TTLS. If the last scan

results have expired based on TTLS value then a scan tool instance will be created to

perform a scan. The tool instance will be created by looking at site wide policy for

scan tools. If site wide policy doesn’t exist for a scan tool a failure will be returned. If

bForceScan flag was TRUE then it that scan we will ignore any history check and will

ask scan tool to run again.

Initialize

HRESULT Initialize()

Scan tool manager will persist its tool queue in order to resume scan after reboot and

across service restart. This method will be called each time a service restarts or

reboots. In case if a scan tool instance persisted it will be restored in this method at

the state where it left and a list of scan tools resumed will be returned to scan tool

agent which will create a temporary scan job for these scan tools.

Scan Tool History

Whenever a scan tool finishes the execution successfully a scan tool history instance

will be added. Following is the table which list all values stored in scan tool history:

Table 29. Scan Tool History Table

Properties Description

Tool ID This will be the Key value and will represent the tool unique ID

Tool Version This will be the version of the tool with which last scan was performed

Content ID This will be ID of the content with which last scan was performed

Content Version This will be the version of the content with which last scan was performed

Last Completion Time This is the time when last scan was completed successfully


System Center Updates Publisher

System Center Updates Publisher is an add-on application that is designed to extend

SCCM 2007 software update management. With the Updates Publisher, customers can

author custom update information and publish that information to the SCCM server.

From there, customers can detect and deploy these updates using the SCCM/WSUS

infrastructure just as they would software updates for standard Microsoft products.

Installation of System Center Updates Publisher

Software Requirements

Microsoft Management Console 3.0 (MMC). MMC 3.0 must be installed prior to

running the Updates Publisher Setup. You can download the MMC 3.0 from the

Microsoft Download Center Web site

(http://go.microsoft.com/fwlink/?linkid=21788).

Microsoft Windows Server Update Services (WSUS) 3.0 Administrator Console. If

WSUS 3.0 is not already installed on the local computer, the WSUS 3.0

Administrator Console must be installed prior to running the Updates Publisher

Setup. You can download the WSUS 3.0 Administrator Console from the

Windows Server Update Services Web site

(http://go.microsoft.com/fwlink/?LinkId=83535).

Microsoft Internet Explorer 6 SP1 or later. A supported version of Internet

Explorer must be installed prior to running the Updates Publisher Setup. You can

download Internet Explorer 6 SP1 from the Microsoft Download Center Web site

(http://go.microsoft.com/fwlink/?linkid=21788).

Microsoft Windows Installer 3.1. The Updates Publisher Setup installs Windows

Installer 3.1, if required.

Microsoft .NET Framework 2.0. The Updates Publisher Setup installs .NET

Framework 2.0, if required.

Microsoft SQL Server 2005 SP1 or Microsoft SQL Server 2005 Express Edition

SP1. The Updates Publisher Setup installs SQL Server 2005 Express Edition SP2,

if required. If you are running from your SCCM server, you should already be at

SP2 for SQL 2005.

The installation process of Updates Publisher is as follows:

1. The EULA is presented.


2. By default, the radio button is set to “I do not accept the license agreement” so

the user will need to choose to accept the agreement in order for Setup to

continue. There is also an option to “Print License Agreement.”

3. Next, Setup requests the location of the database server.

a. The user has the option to specify a Local Database or a Remote Database.

1) If “Local Database“ is selected and a local install of SQL 2005 is detected,

Setup will prompt the administrator to choose the SQL instance to be

used for the Updates Publisher database.

2) If the “Remote Database” option is chosen then the user must specify the

database server and the SQL server instance.

b. When this option is selected, Setup will make a test connection as the logged

on user to verify the version of SQL running.

c. If the connection fails the following, error is displayed: “Unable to verify the

database connection with the provided information.”

Important

The Named Pipes setting in SQL Server 2005 must be enabled for the System Center Updates

Publisher to work properly. If SQL Server 2005 Express Edition is installed by the System Center

Updates Publisher Setup, Named Pipes is automatically enabled. If SQL exists on the system prior

to Setup, Named Pipes must be manually enabled in the SQL Server 2005 Network Configuration

node of SQL Server Configuration Manager.

4. Setup checks the version of SQL installed and if no version of SQL is detected or

it detects a version other than SQL 2005 then Setup will install SQL 2005

Express.

a. If the Remote Database option is selected and the Remote SQL Server is

2000, setup will not be able to verify the connection and the user will either

have to select “Local Database” or they will need to install SQL 2005 on a

remote server then create and configure the database using the steps listed

below:

1) Navigate to the directory that the Updates Publisher setup files were

extracted to.

2) Copy the CreatePubToolDb.sql script to a folder on the SQL Server 2005

computer.


3) Open the Microsoft SQL Server Management Studio console on the SQL

Server computer using an account that has permissions to create a new

database.

4) On the File menu, click Open, click File, browse to the saved SQL script,

and then click Open.

5) On the Query menu, click Execute to create the mscuptdb database and

MS_Custom_Updates_Publishing_Tool_User database role.

6) When the script completes, refresh the System Databases node and

verify that the new database displays.

5. If the user installing the System Center Updates Publisher is not an

administrator on the SQL Server computer, open the Object Explorer, expand

Security node and then click Logins.

If the user account is listed under the Logins node:

1. Right-click the user, and then click Properties.

2. In the Select a page section, click User Mapping.

3. In the Users mapped to this login section, ensure that mscuptdb is selected.

4. In the Database role membership for: mscuptdb section ensure that

MS_Custom_Updates_Publishing_Tool_User is selected, and then click OK.

If the user account is not listed under the Logins node:

1. Right-click the Logins node, and then click New Login.

2. Enter the name of the user, or click Search to browse for the user.

3. Click User Mapping from the Select a page section.

4. In the Users mapped to this login section, ensure that mscuptdb is selected.

5. In the Database role membership for: mscuptdb section, ensure that

MS_Custom_Updates_Publishing_Tool_User is selected, and then click OK.

Note

Modification of the script is not supported. The database must be created on a system

running a version of Microsoft SQL Server 2005.


Note

Local Database with SQL Server 2005 64bit:

The above script will also need to be run if the local database server is running the 64 bit version

of SQL Server 2005 and during the installation of the Publishing Tool the Select Database Server

and Instance Name page displays. “Due to a known issue, you must select Remote Database, even

though the database server is local”. In the Database Server field, enter the name of the local

server. Enter the SQL Instance as appropriate and then click Next.

Any components Setup detects as required but not installed will be listed on the

“Detect and Install” setup screen and will be installed if disk space check permits.

These components can include the following:

■ MSI 3.1 engine

■ .NET Framework 2.0

■ Microsoft Visual C++ Runtime

■ SQL Server Express 2005

■ Windows Server Update Services (WSUS) 3.0 Administrator Console

Once the prerequisites are verified and/or installed, Setup launches Windows

Installer to install SMSPT.msi. A verbose MSI log file is created at

%USERPROFILE%\Local Settings\Temp\PublishingToolsetup.log in the current

user’s profile by default. Four MSI properties are passed to confirm that the MSI was

launched via Setup.exe and to provide the path to the installation source.

SMSPT.msi prompts for the installation location, which by default is C:\Program

Files\System Center Updates Publisher.

Next, Windows Installer begins the actual installation process, creates a new database

named MSCUPTDB, installs SQL Server locally if necessary and, as required, installs

the console and then displays the setup completion screen. When the users click

“Finish” the dialog exits and setup is complete.

Usage of System Center Updates Publisher

Publishing Tool

The System Center Updates Publisher provides SCCM administrators the ability to

import, create, and publish custom software update information to the SCCM

environment using the public WSUS APIs. By using the Updates Publisher to define a


custom software update and publish it to the server, the administrator can begin

detecting and deploying that update to the client and server computers in their

organization. The System Center Updates Publisher enables administrators to do the

following:

■ Create the correct applicability and deployment metadata for an updates that can

be deployed with SCCM

■ Import catalogs of updates from third-parties and from within the customer’s

own organization

■ Export and share these software updates catalogs

■ Manage custom software updates information.

Customers or Independent Software Vendors (ISV) can create content and author

updates while assigning properties. These properties determine title, description,

detection type, update location, and more. Once the required update information is

entered into the Updates Publisher, the tool can be used to publish that information

to the WSUS database (SUSDB). The SCCM console can then be used to approve the

updates for deployment to SCCM clients.

Figure 52. Updates Publisher

Update Definitions/Metadata

The Updates Publisher creates software update information/properties by creating

an XML file that can be published to an updates catalog. Through the creation of

update definitions, an end-user can add updates to the updates catalog.

Update Definition Language (UDL) has the following characteristics:

■ Is a human-readable, XML schema for defining software updates


■ Enables the content provider to define an update with properties such as ID,

Title, Description, Date Created, Severity, Platform, etc.

■ Enable content providers to define detection parameters such as the file version

or registry setting along with values that accompany those criteria.

Detection Logic Enabled by the update metadata

The following describes the supported detection logic by the update metadata:

Detection types

■ File – detecting the existence of files, versions, checksums, size, timestamp, etc.

■ Registry - including key values, key existence.

■ MSI – includes the existence of an MSI product code, product code value, product

version, patch code existence, and patch code value.

■ WMI – WMI queries to cover BIOS and driver detection.

■ Potentially custom script detection would be included.

High-level schema

The schema for the catalog has to support the catalog and each of its update nodes.

Each update node has to have three basic characteristics: properties, detections and

actions.

Figure 53. Updates Definition


How It Works

System Center Updates Publisher is a stand-alone tool that is used to import pre-

existing update catalog (CAB) files and/or create new update definitions. Pre-existing

CAB files can be downloaded from third party vendors online or exported internally

(from a test or staging environment, for example). The imported, or custom, update

definitions are stored in the MSCUPTDB database on a local or remote SQL 2005

server.

Updates that have been imported, or manually defined, can then be published to the

SCCM/WSUS server or exported to a .CAB file.

The Updates Publisher also has an option to export updates to a test catalog, which

allows the Administrator to test the validity of the applicability rules on computers

before publishing the software updates to the server.

The tool also includes a function for locating all available partner catalogs. A CAB file

containing the master list of available partner catalogs is hosted from

http://go.microsoft.com/fwlink/?linkid=66596.

This master CAB file contains an XML file which details the vendor name, catalog ID,

catalog language, download link, etc, for each available catalog.

There is also a mechanism for notifying the user when a partner catalog that has

already been imported is updated by the vendor. If this option is enabled, the

Updates Publisher will attempt to download an XML file for each imported catalog

from the vendor’s web site on startup. Each XML file contains the hash of the most

recent catalog release which is compared with the hash of the catalog stored in the

database at the time of import. If the two hashes differ then the user is notified that a

new catalog exists.

How to create Custom Updates

The Create Update Wizard guides you though the creation of a new custom software

update. The following procedures provide detailed steps on starting and using the

wizard.

To view detailed descriptions for configuration options when on a page in the Create

Update Wizard, press F1. For more information about the Create Update Wizard and

the configuration options on each wizard page, see the section “Create/Modify

Update Wizard.”

In order to create an update, you must first create a vendor.

To create a new Vendor

http://go.microsoft.com/fwlink/?linkid=66596


1. In the System Center Updates Publisher console, select the System Center

Updates Publisher node in the tree pane.

2. Add a new vendor by performing one of the following actions:

a. Right-click the node, and then click Add Vendor.

b. On the Action menu item, click Add Vendor.

c. In the Action pane, click Add Vendor.

3. You will now see New Vendor underneath the System Center Updates

Publisher node in the console.

a. You can right-click the New Vendor folder and select Rename to give it an

appropriate name.

Now that you have a new Vendor you can create a new product for that Vendor

1. With your newly created Vendor selected, you can create a new product by

performing one of the following actions:

a. Right-click the newly created vendor and select Add Product

b. On the Action menu, click Add Product

2. You will now see New Product folder underneath your new Vendor.

a. You can right-click the New Product folder and select Rename to give it an

appropriate name.

To start the Create Update Wizard


Updates Publisher, vendor, or product node in the tree pane.

2. Start the Create Update Wizard by performing one of the following actions:

a. Right-click the node, and then click Create Update.

b. On the Action menu item, click Create Update.

c. In the Action pane, click Create Update.


To use the Create Update Wizard

1. On the Update Information page, configure the following custom update

information:

a. Update Title: Enter the name of the custom update. This is a required field.

b. Description: Enter the description of the custom update. This is a required

field.

c. Classification: Select a classification type from the drop-down list. You can

select from the following values: Critical Updates, Feature Packs, Updates,

Security Updates, Service Packs, Hotfixes, Tools, and Update Rollups. This is

a required field.

d. Bulletin ID: Enter the bulletin ID for the custom update. This is an optional

field.

e. Vendor: Enter the vendor name for the custom update. If the Create Update

Wizard is started from the Vendor or Product node, this value is pre-

populated. This is a required field.

f. Product: Enter the product name for the custom update. If the Create

Update Wizard is started from the Product node of the console, this value is

pre-populated. This is a required field. Click Next.

2. On the Extended Properties page, configure the following properties for the

custom update:

a. Article ID: Enter the article ID for the custom update. This is an optional

field.

b. CVE ID: Enter the Common Vulnerability and Exposures (CVE) ID that

provides the security information about the custom update. This is an

optional field.

c. Severity: Select a severity type from the drop-down list. You can select from

the following values: None (default), Critical, Important, Moderate, and Low.

This is a required field when selecting the Security Updates classification on

the previous page. For all other custom update classifications, this is an

optional field.

d. Support URL: Enter the URL that provides support information about the

custom update. This is an optional field.


e. More Info URL: Enter the URL that provides more information about the

custom update. This is a required field.

f. Impact: Select an impact category from the drop-down list. You can select

from the following values: Normal (default), Minor, and Requires Exclusive

Handling. This is an optional field.

g. Reboot Behavior: Select the reboot behavior from the drop-down list. You

can select from the following values: Never reboots, Always requires reboot,

and Can request reboot (default). This is an optional field. Click Next.

3. On the Define Prerequisite Rules page, provide the higher-level rules used as

an initial check to determine whether the custom update is needed on the client,

and then click Next. Providing the prerequisite rules is optional. See more about

expression builder later in this section.

4. On the Select Package page, configure the following package properties:

a. Installer Type: Select the type of installation required for the custom

update from the drop-down list. You can select from the following values:

Command Line Installation (.exe), Windows Installer File (.msi), and

Windows Installer Patch (.msp). This is a required field.

b. Update Package Source: Enter or browse to the path for where the custom

update is created. The source path must be on the local drive. This is a

required field.

c. Download URL: Enter the URL or UNC path to the publish location for the

custom update. This is a required field.

d. Binary Language: The wizard detects the language from the Update

Package Source file for Command Line Installation (.exe) and Windows

Installer File (.msi) custom updates and automatically populates the

language field. For Windows Installer Patch (.msp) type files, you must select

the language for the custom update from the drop-down list. This is a

required field.

e. Success Return Codes: The wizard detects the success return codes for

Windows Installer File (.msi) and Windows Installer Patch custom updates

and automatically populates the Success Return Codes field. For Command

Line Installation (.exe), you must specify the success return codes for the

custom update. This is an optional field.

f. Success Pending Reboot Codes: The wizard detects the success pending

reboot codes for Windows Installer File (.msi) and Windows Installer Patch


custom updates and automatically populates the Success Pending Reboot

Codes field. For Command Line Installation (.exe), you must specify the

success pending reboot codes for the custom update. This is an optional

field.

g. Command line (quiet): The wizard detects the command-line arguments

for a quiet custom update installation (unattended setup with no user

intervention) for Windows Installer File (.msi) and Windows Installer Patch

custom updates and automatically populates the Command line (quiet) field.

For Command Line Installation (.exe), you must specify the command-line

arguments for the custom update. This is an optional field. Click Next.

5. On the Define Applicability Rules page, define the rules used to determine

whether the software update is applicable to a specific client. The applicability

rules are optional, but to retrieve accurate reporting results about whether the

custom update is applicable on clients, at least one rule must be defined. Click

Next. See more about expression builder later in this section.

6. On the Define Installed Rules page, define the rules used to determine whether

the custom update is already installed on the client. The installed rules are

optional, but the custom update cannot be published until at least one installed

rule is defined. See more about expression builder later in this section.

7. On the Summary page, which displays a summary of the configured properties

for the custom update, click Next to create the update. The Progress page

displays the status and progress while creating the custom update.

8. The Confirmation page displays a summary of the configured properties for the

custom update that was created. If an error occurred during the custom update

creation process, the error message displays

Tip

If an error occurs during the custom update creation process, review the

UpdatesPublisher.log file, located in %USERPROFILE%\Local Settings\Temp, for

more information.

How to Use the Expression Builder

The Expression Builder is available on the Define Prerequisite Rules, Define

Applicability Rules, and Define Installed Rules pages of the Create Update Wizard in

the System Center Updates Publisher. This tool provides the ability to add, modify,

delete, and group the rules defined for each type of custom update verification. The


following procedure describes how to use the Expression Builder to add, edit, and

delete rules, and arrange the rules in logical groups.

To create rules and group them using Expression Builder

1. In the Create Update or Modify Update Wizard, go to the Define Prerequisite

Rules, Define Applicability Rules, or Define Installed Rules page.

2. Click the Add Rule icon, and in the Add Rule dialog box, configure the new rule

by performing one of the following actions:

3. Select from one of the following rule categories:

a. Create Basic rule: Basic rules check for a specific file, file version, registry

key, and so on. There are over 20 rule types available for basic rules.

b. Create MSI rule: MSI (Windows Installer) rules check for a specific software

update, product, component, or feature.

c. Use existing rule: Uses a previously created rule. The properties for the rule

can be modified, if required.

4. Choose the Rule Type from the drop-down list. The rule types for the specified

rule category are listed.

5. Configure the properties for the specified rule type.

6. Specify a name for the rule in the Save your rule as text box to reuse the rule.

7. Repeat the actions in step 2 to create additional rules.

8. In the Expression Builder, use the appropriate icons to organize and group the

set of defined rules.

a. Add Group icon: Groups, or nests, the selected rules. Select one or more

rules and click the Add Group icon to add a sub-grouping of logical And/Or

expressions. By default, all groupings are added as Or expressions but can be

changed to the And operator. Rules can be nested three layers deep in the

Expression Builder.

b. Delete Group icon: Deletes the group for the selected rules. Select one or

more updates that have been grouped together and then click the Delete

Group icon to remove the grouping.

c. Move Up icon: Moves the highlighted rule up in the list of rules.

d. Move Down icon: Moves the highlighted rule down in the list of rules.


e. Delete icon: Deletes the highlighted rule from the custom update definition.

Saved rules are still available in the Manage Rules dialog box.

9. After the expression is built, use the XML View tab to view the expression in XML

format.

Tip

Details about the Rule types and what they do are covered in the Updates Publisher help file

under Reference Topics for the Updates Publisher\Updates Publisher Rule Types.

How to Modify Custom Updates

The Modify Update Wizard guides you though modifying an existing custom

software update. The following procedure provides steps for starting and using the

wizard.

To view detailed descriptions for configuration options from a page in the Modify

Update Wizard, press F1.


To start the Modify Update Wizard

1. In the System Center Updates Publisher console tree pane, select the System

Center Updates Publisher product node.

2. In the list pane, select the custom update to be modified.

3. Start the Modify Update Wizard by performing one of the following actions:

a. Right-click the custom update, and then click Edit.

b. On the Action menu item, click Edit.

c. In the Action pane, click Edit.

4. Navigate to the wizard page with that contains the configuration setting that

needs to be modified.

Importing Updates

About the Import Software Updates Catalog Wizard

The Import Software Updates Catalog Wizard in the System Center Updates Publisher

imports custom updates catalogs that are created and published at a different

location. The wizard allows for the configuration for one or more catalogs to be

imported. The wizard pages are described in the following table.

Table 30. Import Software Updates Catalog Wizard

Create Update Wizard Page Description

Select Import Method Page Specifies the import method for the software updates

catalog. One or more catalogs can be imported depending

on the configuration on this page.

Select File Page Specifies the path to the software updates catalog that is

imported. This page is available only when importing a single

catalog.

Summary Page Provides a summary of the properties configured in the

wizard.

Progress Page Displays the current task and progress when the custom

update is being created.

Confirmation Page Displays a summary of the properties associated with the

new custom update.


How to Import Software Updates Catalogs

The Import Software Updates Catalog Wizard enables the importing of one or

more software updates catalogs. To import more than one catalog, an import list must

be configured prior to starting the wizard. For more information, see the section

“Error! Hyperlink reference not valid.” later in this module. The following

procedures provide detailed steps about starting and using the wizard.

To view detailed descriptions for configuration options when on a page in the Import

Software Updates Catalog Wizard, press F1.

To use the Import Software Updates Catalog Wizard

1. On the Select Import Method page, select either of the following settings:

a. Bulk Catalog Import: Specifies that all catalogs configured in the Import

List tab of the Error! Hyperlink reference not valid. are automatically

imported. The import list must be configured for this option to be available.

If enabled, this option is the default setting. See the “How to Manage

Catalog Import Lists” section below for more information on update lists.

Click Next and proceed to step 3, the Summary page.

b. Single Catalog Import: Specifies that a single software updates catalog is

imported from the configured location. Click Next and proceed to step 2.

2. On the Select File page, configure the import location of the software updates

catalog by clicking Browse to select the location of the catalog file or entering

the full path to it. The path to the catalog file can be on the local hard drive

(c:\mycatalog\catalog.cab) or UNC path (\\myserver\myshare\catalog.cab).

Click Next.

3. On the Summary page, which displays a summary of the import properties for

the software updates catalog, click Next to import the catalog.

4. The Progress page displays the status and progress while importing the software

updates catalog.

a. During the import process, the Error! Hyperlink reference not valid. might

display. Click Accept if the catalog is from a trusted publisher. If you choose

Always accept catalog from "publisher's name", the publisher

information is stored and you will not be prompted again to accept the

catalog or software update from that publisher. To remove a publisher that

you have always accepted, see the Trusted Publishers tab of the Error!

Hyperlink reference not valid.. To configure how to handle unsigned

catalogs for each import location used by the Bulk Catalog Import option,

see the Import List tab of the Error! Hyperlink reference not valid..


Important

Catalog files from untrusted publishers can potentially harm client computers when scanning

for updates. Only accept catalogs from publishers you trust. If you no longer trust a publisher that

you previously always accepted, remove that publisher from the list.

Publishing Custom Updates

The Publish Wizard in the System Center Updates Publisher uses the public WSUS

APIs to publish the custom software updates that have been marked for publishing to

the SCCM server. The wizard pages are described in the following table.

Table 31. Publish Wizard

Create Update Wizard Page Description

Summary Page Lists the number of updates to be published and the WSUS server

they will be published to.

Progress Page Displays the current task and progress when the custom updates

are being published.

Confirmation Page Displays a summary of the properties for the published custom

updates.

Tip

Only custom updates with the publish flag set are published. At least one custom update must

have the publish flag set to start the Publish Wizard.

Tip

For instructions on how to configure an update server for publishing, see the “How to

Configure the Publishing Tool Update Server” section below.

To start the Publish Wizard


Updates Publisher repository, vendor, or product node in the tree pane.

2. Start the Publish Wizard by performing one of the following actions:


a. Right-click the custom update or node, and then click Publish Update(s).

b. On the Action menu item, click Publish Update(s).

c. In the Action pane, click Publish Update(s).

Exporting Custom Updates

About the Export Wizard

The Export Wizard in the System Center Updates Publisher can be opened from

any node or custom update in the System Center Updates Publisher console. This

wizard provides the ability to export specified custom updates to a cabinet file (CAB)

that can be imported by other publishing tools or to export a test catalog Extensible

Markup Language (XML) file for testing.

Export Custom Updates to CAB File

When the Export selected updates to a cabinet file that can be imported by other

publishers option is selected in the Export Wizard, all custom updates in the

highlighted node and all sub nodes, or individual custom updates selected in the list

view pane, are exported to a CAB file when the wizard successfully completes. If the

Export all updates in the updates publisher database that have the publish flag

set option is select, all custom updates that have been flagged for publishing are

exported to a CAB file when the wizard successfully completes. The catalog is

exported to the location specified in the wizard.

The CAB file can be imported from another location by selecting the Import option in

the System Center Updates Publisher. If the custom updates contained in the

imported catalog are already present in the database, a message appears asking if the

current update should be replaced with the new one.

Export Custom Updates to an XML File for Testing

When the Export selected updates to a test catalog XML file and supporting scan

files for testing option is selected in the Export Wizard, the wizard creates a folder

in the specified location with the scan tool, schema files, custom updates test catalog,

and a script with the appropriate command-line parameters. The files in the export

for test folder provide the ability to test a catalog without synchronizing the catalog

to the SCCM/WSUS server.

Export for Testing Process

After the Export Wizard completes, the following steps are performed by the wizard:

1. The wizard retrieves the custom updates from the database, creates a temporary

test catalog file in the user %temp% folder, renames the test catalog file to

TestCatalog.xml, copies the file to the destination folder specified above, and


deletes the temporary test catalog from %temp%. If a TestCatalog.xml file

already exists in the destination folder, it is deleted.

2. The following export for test files are copied from the System Center Updates

Publisher installation folder to the location specified above:

a. RunScan.cmd: The tool used to scan the client for the updates defined in the

catalog.

b. TestScan.exe: Scan engine to test the update.

c. ScanReport.xsl: The XML stylesheet, which formats the scan results into a

report.

d. \Data folder: Contains the XSD files used to validate the schema of the

TestCatalog.xml when starting the scan. These files are copied from the

Data folder located under the System Center Updates Publisher installation

folder.

e. \Logs folder: Contains the LOG files created during a client scan. The log

files are named CSTScan_<computername>.log and contain detailed scan

information for the client.

3. When the RunScan.cmd file is run, the client is scanned for applicable custom

updates and the results are appended to the TestResults.xml file. Local and

remote clients can run the test scan to determine whether the custom update

definitions created in the System Center Updates Publisher provide the expected

scan results.

How to Export Custom Updates

The Export Wizard guides you through exporting the specified custom updates to a

cabinet file (CAB) that can be imported by other publishing tools or to export a test

catalog Extensible Markup Language (XML) file for testing. The following procedures

provide detailed steps on launching and using the wizard.To view detailed

descriptions for configuration options when on a page in the Export Wizard,

press F1.

To start the Export Wizard

1. In the System Center Updates Publisher console, select the custom updates to

be exported. All custom updates in a selected node and sub nodes are exported

to the catalog file. Individual custom updates can also be selected for export by

holding down the CTRL key and selecting the updates.

2. Start the Export Wizard by performing one of the following actions:


3. Right-click any tree node item, and then click Export.

4. In the Action pane, click Export.

5. On the Action menu item, click Export.

To use the Export Wizard

1. From the Specify Export Type page, choose one of the following settings:

a. Export selected updates to a cabinet file that can be imported by other

publishers: Choose this setting to export the selected custom updates to a

CAB file that can be imported by other publishing tools.

b. Export selected updates to a test catalog XML file and supporting scan

files for testing: Choose this setting to test whether the custom updates

catalog works as expected. A catalog XML file is created, along with the

custom updates scan tool, schema files, and a script with the appropriate

command-line parameters. The files in the export for test folder provide the

ability to test a catalog without publishing it to SCCM/WSUS.

c. Export all updates in the updates publisher database that have the

publish flag set: Choose this setting to export all updates that have been

flagged for publishing to a CAB file.

2. Specify the path for the exported or test catalog by configuring one of the

following:

a. When the Export a cabinet file that can be imported by other publishing

tools or the Export all updates in the updates publisher database that

have the publish flag set setting is selected on the previous page, configure

the Export Path on the Specify Export Path page. The default location for

the exported catalog is

%USERPROFILE%\My Documents\My Catalogs\MyUpdatesCatalog.cab

. To use a different path, enter the export path in the text box or click Browse

to select the folder for the catalog file.

b. When the Export selected updates to a test catalog XML file and

supporting scan files for testing is configured on the previous page,

configure the Export For Test Path on the Specify Export for Test Path

page. Enter the export for test path in the text box or click Browse to select

the folder for the test catalog and supporting test files. Click Next.

3. On the Summary page, which displays a summary of the configured properties

for exporting the custom updates, click Next to export the updates.


4. The Progress page displays the status and progress while exporting the custom

updates.

5. The Confirmation page displays a summary of the configured properties for the

exported custom updates. If an error occurs while exporting the custom updates,

an error message displays and the export process is cancelled. Click Close to exit

the wizard.

How to Use the Export for Test Catalog

When the Export Wizard completes, after using the Export selected updates to a

test catalog XML file and supporting scan files for testing, it creates a folder in the

specified location and copies the custom updates test catalog, scan tool, schema files,

and a script with the appropriate command-line parameters. The files in the export

for test folder provide the ability to test a catalog without synchronizing the catalog

to the SCCM/WSUS server. Use the following procedure to test the catalog on

computers.

To use the export for test catalog

1. In Windows Explorer, browse to the folder where the export for test files are

located.

2. Double-click Runscan.cmd to scan the local client for the custom updates

defined in the exported catalog and create the TestResults.xml file containing

the results of the scan.

3. Double-click TestResults.xml to view the results of the scan. The default Web

browser opens displaying a list of the custom updates in the test catalog that are

applicable to the client.

4. To run the test scan on a remote client, create a share on the folder where the

exported test files are located, map a drive to the share, browse to the share, and

then double-click Runscan.cmd. The scan results for the client are appended to

the TestResults.xml file and the applicable updates display grouped by each

client.

Tip

When a scan is rerun on clients, the existing scan results for that client are replaced with the

new scan results in the TestResults.xml file.


Configuring and Managing the Updates Publisher Settings

How to Manage Catalog Import Lists

The Import List tab in the Settings dialog box provides the ability to add, remove,

modify, or find software updates catalogs for the Import List. The following

procedure provides the steps to configure the import location.

To configure the catalogs in the import list

1. In the System Center Updates Publisher console, open the Settings dialog box


a. Right-click any tree node item, and then click Settings.

b. In the Action pane, click Settings.

c. On the Action menu item, click Settings.

2. On the Import List tab, configure the custom updates catalog import locations.

The following configuration options are available:

a. Add: Opens the Add Catalog Dialog Box containing Choose Path, Name,

Description, Support Contact, Require approval of unsigned catalogs from

this location during import, and Always flag these updates for publishing.

b. Remove: Deletes the highlighted software updates catalog file from the

import list.

c. Remove All: Deletes all software updates catalog files from the import list.

d. Edit: Opens the Modify Catalog Dialog Box, which allows you to modify the

highlighted software updates catalog. The Path, Name, Description, Support

Contact, Require approval of unsigned catalogs from this location during

import, and Always flag these updates for publishing settings can be

modified.

e. Find: Opens the Discover and Add External Catalogs Dialog Box, which

retrieves the discovery list of all vendor catalogs known by Microsoft and

provides the ability to add discovered catalogs to the import file list.

3. Click OK to exit the Settings dialog box.


How to Configure the Publishing Tool Update Server

The Update Server tab in the Settings dialog box is used to configure how the

Updates Publisher connects to an Update Server. The following procedure provides

the steps necessary to configure the update server.

To configure the Updates Publisher to publish data to an update server






2. On the Update Server tab in the Settings

a. Check the box Enable publishing to an update server

b. Select either Connect to a local update server or Connect to a remote

update server depending on where your update server is located

c. Press the Test Connection button to confirm that you are able to connect to

your update server.

d. Apply the changes and then click Okay

3. Verify the WSUS Certificate is located in the local machines Trusted Root

Certification Authorities and the Trusted Publishers nodes.

a. If your update server is on the same machine that has the updates publisher

installed.

1) On the Start Menu click Run, and type “MMC” (without quotes) and hit

enter.

2) Once the blank MMC Console opens, select Add/Remove Snap-in from

the File menu, and then click on the Add button.

3) In the Add Standalone Snap-in Window, select Certificates

4) In the Certificates snap-in Window, Select Computer account, and

then click Next. Ensure that Local Computer is selected then click

Finish. You can then close the Add Standalone Snap-in Window, and

click OK in the Add/Remove Snap-in window.


5) In the Certificates tree view expand the WSUS node and select

Certificates. In the right pane you will see the WSUS Publishers Self-

signed certificate.

6) Ensure that this same certificate is also located in the Trusted Root

Certification Authorities and the Trusted Publishers nodes. If they

are not, use copy and paste to place them there.

b. If you are using a remote updates server, complete the following on your

Update Server

1) On the Start Menu click Run, and type “MMC” (without quotes) and hit

enter.

2) Once the blank MMC Console opens, select Add/Remove Snap-in from

the File menu.

3) Click on the Add button and in the Add Standalone Snap-in Window,

select Certificates

4) In the Certificates snap-in Window, Select Computer account, and

then click Next. Ensure that Local Computer is selected then click

Finish.


5) Repeat step three to get the Certificates snap-in window again. Select

Computer account, and then click Next. This time select Another

computer and type the name of the machine that you are running

Updates Publisher from.

6) You can then close the Add Standalone Snap-in Window, and click OK

in the Add/Remove Snap-in window.

7) In the Certificates tree view expand the WSUS node and select

Certificates. In the right pane you will see the WSUS Publishers Self-

signed certificate.

8) Ensure that this same certificate is also located in the Trusted Root

Certification Authorities and the Trusted Publishers nodes on the

update server. If they are not, use copy and paste to place them there.

9) Use copy and paste to place the same WSUS Publishers Self-signed

certificate to the Trusted Root Certificate Authorities certificate node

on the machine running Updates Publisher.

4. You can now close your Certificates MMC.

How to Configure the Publishing Tool Data Source

The Data Source tab in the Settings dialog box is used to configure the server and

instance names for the System Center Updates Publisher data source. The following

procedure provides the steps necessary to configure the data source.

To configure the Updates Publisher data source






2. On the Data Source tab, in the Server name text box, enter the server name or

server and instance names for where the Updates Publisher connects to access

its database. For example, MyServerName or MyServerName\InstanceName.

If the server name is entered without an instance name, the default instance is

used.


3. Click Test Connection to validate the server name. A message displays

indicating whether the connection test succeeded or failed. If the connection

failed, enter a new server name in the text box and test the connection again.

4. Click OK to exit the Settings dialog box.

How to remove Trusted Publishers

The Trusted Publishers tab in the System Center Updates Publisher Settings

dialog box you can remove Trusted Publishers. This is the list that publishers are

added to when the Always accept catalog from “Publisher” option is selected in the

Catalog Validation – Security Warning dialogue box you are presented with when

importing updates.

How to Configure the Publishing Tool Security

The Advanced tab in the System Center Updates Publisher Settings dialog box

configures whether to check the certificate revocation list (CRL) for digitally signed

software updates catalog certificates that have been revoked from the approved list

issued by the Certification Authority (CA). The Enable certificate revocation

checking for digitally signed catalog files option is not enabled by default because

of the additional overhead to the import process that occurs when the tool

determines whether the catalog is on the revocation list.

Tip

Enable this option to ensure that digitally signed software updates catalogs are on the CA

approved list. For more information, see the Certificate Revocation and Status Web page


To configure the Updates Publisher security settings for the data source

1. In the System Center Updates Publisher console, open the Advanced dialog

box by performing one of the following actions:




2. On the Advanced tab, configure whether to enable certificate revocation

checking for digitally signed catalog files, and then click OK.




Configuring Group Policy on Client Computers

Before the Windows Update Agent (WUA) 3.0 on computers will scan for updates that

were created and published with the System Center Updates Publisher, a Group

Policy setting must be enabled to allow signed content from an intranet Microsoft

update service location. When the policy setting is enabled, WUA 3.0 will accept

updates received through an intranet location if the updates are signed in the Trusted

Publishers certificate store on the local computer. There are several methods for

configuring Group Policy on computers in the environment.

For computers that are not on the domain, a registry key setting can be configured

that will allow signed content from an intranet Microsoft update service location.

The following procedures provide the basic steps that can be used to configure Group

Policy for computers on the domain and a registry key value on computers that are

not on the domain.

To configure the Group Policy to allow WUA 3.0 on computers to scan for published

updates

1. Open the Group Policy Object Editor Microsoft Management Console (MMC)

snap-in with a user that has the appropriate security rights to configure Group

Policy.

2. Click Browse and select the domain, OU, or GPOs linked to the site where the

configured Group Policy will propagate to the desired client computers. Click OK,

click Finish, click Close, and then click OK.

3. Expand the selected policy setting in the console tree, expand Computer

Configuration, expand Administrative Templates, expand Windows Components,

and then click Windows Update.

4. In the results pane, right-click Allow signed content from intranet Microsoft

update service location, click Properties, click Enabled, and then click OK.

To configure the registry key to allow WUA 3.0 on computers to scan for published

updates


1. Open the Registry Editor on the computer.

2. Navigate to the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\windows\WindowsUpdate

3. Right click AcceptTrustedPublisherCerts, and then click Modify.

4. In the Edit DWORD Value dialog box, type 1 for the Value data, click Decimal for

the Base, and then click OK.

Deploying published updates via SCCM

Once updates have been published to your update server and synchronization has

occurred between WSUS and SCCM, your updates are available for deployment via

Software Updates node in the Configuration Manager Console just like any other

update.

Managing System Center Updates Publisher Rules

Creating New Rules in the Manage Rules Dialog Box

System Center Updates Publisher rules created in the Manage Rules dialog box are

saved and available for use when creating new custom updates in the Create Update

Wizard. The following procedure provides the steps necessary to create a new rule

from the Manage Rules dialog box.

To create a new rule from the Manage Rules dialog box

5. In the System Center Updates Publisher console, open the Manage Rules

dialog box by performing one of the following actions:

a. Right-click any tree node item, and then click Manage Rules.

b. In the Action pane, click Manage Rules.

c. On the Action menu item, click Manage Rules.

6. Click Create to open the Create Rule dialog box.

7. Configure the new rule by using the following options: Select from the following

rule categories:

a. Create Basic rule: Checks for a specific file, file version, registry key, and so

on. There are over 20 rule types available for basic rules.

b. Create MSI rule: Checks for a specific software update, product, component,

or feature.


c. Use existing rule: Uses a previously created rule. The properties for the

rule can be modified, if required.



9. Specify whether the rule is a Not rule. When the Inventory Tool for Custom

Updates evaluates a Not rule, the logical result is reversed.

10. Configure the properties for the specified rule type..

11. Specify a name for the rule in the Save your rule as text box to reuse the rule.

12. Click OK to exit the Create Rule dialog box.

Creating New Rules in the Create/Modify Update Wizard

System Center Updates Publisher rules created in the Create Update Wizard can be

created from the Define Prerequisite Rules, Define Applicability Rules, and

Define Installed Rules pages. The following procedure provides the steps necessary

to create a new rule from the Create Update Wizard.

To create a new rule from the Create Update Wizard

1. In the System Center Updates Publisher console, start the Create Update

Wizard by performing one of the following actions:

a. Right-click any tree node item, and then click Create Update.

b. In the Action pane, click Create Update.

c. On the Action menu item, click Create Update.

2. Go to the Define Prerequisite Rules, Define Applicability Rules, or Define

Installed Rules page of the wizard where the Expression Builder displays. The

following briefly describes each rule category:

a. Prerequisite Rules: Higher-level rules used as an initial check to verify that

the custom update is needed on the client. For example, the rule might

define a specific operating system; however, if the client has a different

operating system installed, the custom update is not needed on that client.

b. Applicability Rules: Rules used to determine whether the software update

is applicable to a specific client. For example, the rule might define a specific

file with a file version less than a specific value. If the client has the file with

a version less than the specified value, the custom update is applicable.


c. Installed Rules: Rules used to determine whether the custom update is

already installed on the client. For example, the rule might define a specific

file with a specific file version. If the client has the file with the specified

version, the custom update is already installed on the client and no longer

needed.

3. Click the Add Rule icon, and in the Add Rule dialog box, configure the new rule

by performing the following options: Select from the following rule categories:

a. Create Basic rule: Basic rules check for a specific file, file version, registry

key, and so on. There are over 20 rule types available for basic rules.

b. Create MSI rule: Used most often for prerequisite verification because MSI-

based (Windows Installer) updates auto-populate applicability and installed

rules for verification. Windows Installer rules check for a specific software

update, product, component, or feature.

c. Use existing rule: Uses a previously created rule. The properties for the

rule can be modified, if required.



5. Specify whether the rule is a Not rule. When the Inventory Tool for Custom

Updates evaluates a Not rule, the logical result is reversed. Configure the

properties for the specified rule type.

6. Specify a name for the rule in the Save your rule as text box to reuse the rule

window.

7. Repeat step 3 to create multiple rules. From the Expression Builder, rules can

be moved up or down in the list, deleted, or logically grouped. Each group has

the And or Or operator. For more information, see the How to Use the

Expression Builder section of this module.

How to Edit Updates Publisher Rules

System Center Updates Publisher rules are edited from the Manage Rules dialog

box or from the Expression Builder in the Modify Update Wizard. The following

procedures provide the steps necessary to edit rules from these locations.

To edit rules from the Manage Rules dialog box

1. In the System Center Updates Publisher console, open the Manage Rules

dialog box by performing one of the following actions:





2. Highlight a rule, and then click Edit, or double-click a rule from the list to open

the Edit Rule dialog box.

To edit rules from the Expression Builder



2. In the List pane, select the custom update that needs to be modified.






Installed Rules page of the wizard where the Expression Builder displays. All

of the rules currently defined for each category are listed in the rows of the

Expression Builder. If the rules are difficult to see, click Expand to open the

Expression Builder in full-screen mode.

5. Double-click the rule that needs to be edited to open the Modify Rule dialog box.

How to Delete Publishing Tool Rules

System Center Updates Publisher rules are deleted from the Manage Rules dialog

box or from the Expression Builder in the Modify Update Wizard. The following

procedures provide the steps necessary to delete rules from these locations.

To delete rules from the Manage Rules dialog box

1. In the System Center Updates Publisher console, open the Manage Rules dialog

box by performing one of the following actions:





2. Highlight a rule, click Delete, and then click Yes to confirm the deletion of the

rule. Saved rules that are deleted are no longer available when creating new

rules and selecting the Use existing rule category.

To delete rules from the Expression Builder



2. In the list pane, select the custom update that needs to be modified.






Installed Rules page of the wizard where the Expression Builder displays. All

of the rules currently defined for each category are listed in the rows of the

Expression Builder. If the rules are difficult to see, click Expand to open the

Expression Builder in full-screen mode.

5. Highlight the rule to be deleted, click the Delete icon, and then click Yes to

confirm the deletion of the rule. Deleting rules from the Expression Builder

removes the rules from the custom update definition, but does not delete saved

rules.

System Center Updates Publisher Backup and Restore

How to Backup the System Center Updates Publisher Database

The System Center Updates Publisher does not have an automatic backup task, but

a manual backup should be performed on a regular basis. There are several methods

for backing up the data in the System Center Updates Publisher database, but the

recommended method is to back up the database using SQL Server 2005 or

SQL Server 2005 Express Edition.

Backing up the SQL Server 2005 Database

Backing up the System Center Updates Publisher database with SQL Server 2005 or

SQL Server 2005 Express Edition is the preferred and most complete backup method.

All of the custom software updates and all Updates Publisher settings are backed up


and can be easily restored. Both versions of SQL Server 2005 have a graphical user

interface to create a backup of the database.

SQL Server 2005 Express Edition

If you are using SQL Server 2005 Express Edition for the System Center Updates

Publisher database, you must first install SQL Server Management Studio Express to

backup and restore the database in a graphical user interface. The following

procedure provides the steps to download, install, and use SQL Server Management

Studio Express to back up the Updates Publisher database.

Tip

For more information about SQL Server Management Studio Express, see SQL Server

Management Studio Express in the SQL Server 2005 Books Online


To download, install, and use SQL Server Management Studio Express to backup the

Updates Publisher database

1. Download SQL Server Management Studio Express from the SQL SE Web site

(http://go.microsoft.com/fwlink/?LinkId=66482) and install it on the computer

running the System Center Updates Publisher.

2. Start SQL Server Management Studio Express, leave the default values in

Server name and Authentication, and then click Connect.

3. Navigate to the mscuptdb database.

4. Right-click mscuptdb, click Tasks, and then click Backup.

5. Provide a Name and Description for the backup, and then click OK.

6. The mscuptdb database is backed up by default in the mscuptdb.bak file located

at %ProgramFiles%\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\SQL

Server 2005

Tip

For more information about SQL Server Management Studio, see Introducing SQL Server

Management Studio in the SQL Server 2005 Books Online








If you are using SQL Server 2005 for the System Center Updates Publisher database,

the following procedure provides the steps using SQL Server Management Studio to

backup the Updates Publisher database

To use SQL Server Management Studio to backup the Updates Publisher database

1. Start SQL Server Management Studio, leave the default values in Server name

and Authentication, and then click Connect.

2. Navigate to the mscuptdb database:

3. Select Database Engine for Server type, select the server name, and then click

Connect.

4. Right-click mscuptdb, click Tasks, and then click Backup.

5. Provide a Name and Description for the backup, and then click OK.

6. The mscuptdb database is backed up by default in the mscuptdb.bak file located

in the %ProgramFiles%\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\

folder.

How to Restore the System Center Updates Publisher Database

The System Center Updates Publisher has several methods for restoring data in the

System Center Updates Publisher database, but the recommended method is to

restore the database using SQL Server 2005 or SQL Server 2005 Express Edition.

Restoring the SQL Server 2005 Database

Restoring the System Center Updates Publisher database from a SQL Server 2005 or

SQL Server 2005 Express Edition backup is the most complete method for recovering

lost or damaged data. All of the custom software updates and all Updates Publisher

settings are restored using this method.

Important

The System Center Updates Publisher must be installed prior to restoring the database in

SQL Server. The restored data is overwritten if the Updates Publisher is installed after a restore.


Important

SQL Server 2005 Express Edition

If you are using SQL Server 2005 Express Edition for the System Center Updates Publisher

database, use SQL Server Management Studio Express to restore the database. The following

procedure provides the steps to download and install SQL Server Management Studio Express, if

necessary, and restore the Updates Publisher database.

Tip

For more information about SQL Server Management Studio Express, see SQL Server

Management Studio Express in the SQL Server 2005 Books Online


To download, install, and use SQL Server Management Studio Express to restore the

Updates Publisher database

1. If SQL Server Management Studio Express is not installed, download the tool at

the SQL Se Web site (http://go.microsoft.com/fwlink/?LinkId=66482) and

install it on the computer running the System Center Updates Publisher.

2. Start SQL Server Management Studio Express, leave the default values in Server

name and Authentication, and then click Connect.


4. Right-click mscuptdb, click Tasks, click Restore, and then click Database.

5. Select the backup set to restore, and then click OK. The mscuptdb database is

restored by default from the mscuptdb.bak file located at

%ProgramFiles%\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\.

6. SQL Server 2005

If you are using SQL Server 2005 for the System Center Updates Publisher

database, the following procedure provides the steps using SQL Server Management

Studio to restore the Updates Publisher database.

Tip

For more information about SQL Server Management Studio, see Introducing SQL Server

Management Studio in the SQL Server 2005 Books Online









To use SQL Server Management Studio to restore the Updates Publisher database

1. Start SQL Server Management Studio, leave the default values in Server name

and Authentication, and then click Connect.


3. Select Database Engine for Server type, select the server name, and then click

Connect.

4. Right-click mscuptdb, click Tasks, click Restore, and then click Database.

5. Select the backup set to restore, and then click OK. The mscuptdb database is

restored by default from the mscuptdb.bak file located at

%ProgramFiles%\Microsoft SQL Server\MSSQL.1\MSSQL\Backup\.

Logging

All logs for System Center Updates Publisher are located under the user profile for

the user who performs the installation or works in the Updates Publisher console.

The logs are listed in the table below.

Table 32. SCUP Logging

Log File Description

%USERPROFILE%\Local

Settings\%temp%\PTBootstrappersetup.log

Created by Setup.exe

%USERPROFILE%\Local Settings

%temp%\PublishingToolsetup.log

Verbose MSI log file created during the installation of

SMSPT.msi


%temp%\PublishingTool.log

Log file created by the MMC detailing activity

performed in the Updates Publisher console


%temp%\PublishingToolSync.log

Log file created by CSTSync.dll during site database

synchronization when initiated from the console

%AppData%\..\Local Settings\Application

Data\Microsoft\System Center Updates

Publisher\SMSCUPTSettings.xml

While not a log file, per se, the user’s console

settings are stored here



When creating the active software update point, you configure the update

classifications, products, and languages for which the software update metadata is

synchronized. The synchronized software updates are displayed in the Configuration

Manager console and can then be deployed to client computers. These settings can be

modified at any time, but you should pay special attention to the Summary Details

language setting before synchronizing and deploying software updates.

It is very important that you select all of the summary details languages that will be

needed in your Configuration Manager hierarchy. When the active software update










Wizard, many deployment settings need to be considered. The following sections

provide information about the settings on each page of the Deploy Software Updates

Wizard.

General Page

The General page allows you to provide the name and description for the

deployment. The name must be unique for the site.

Recommendation

Provide a name and description that will help you to distinguish this deployment

from any others. Deployments are sorted in the Configuration Manager console by

name. Deployments are easy to find when there are a small number of them, but they

can be difficult to find when there are many. Before creating deployments, think

about the naming convention that will be used at your site.

Collection Page

The Collection page specifies the collection that will be targeted for the software

update deployment. Members of the collection and subcollections, if configured,

receive available deployments during their next Machine Policy Retrieval &

Evaluation Cycle. The following settings are available on the Collection page:


■ Collection: Specifies the target collection for the deployment. Members of the

collection receive the software updates defined in the deployment.

■ Include members of subcollection: Specifies whether members of any

subcollection of the main collection receive the software updates defined in the

deployment. By default, this setting is enabled and members of both the

collection and subcollection are targeted for the deployment.

Recommendation

When creating deployment templates, you do not have to specify the collection as

part of the template. This allows you to use the template when creating multiple

deployments that target different collections.

Display/Time Settings Page

The Display/Time Settings page specifies whether the user will be notified of

pending software updates, the installation progress for software updates, whether a

client evaluates the deployment schedule based on local or Coordinated Universal

Time (UTC), and the default duration between software update availability and

deployment deadline. The following settings are available on the Display/Time

Settings page:

Display Settings


■ Allow display notifications on clients: Specifies that display notifications are

used on clients that inform end users of available software updates and progress

indicators are displayed during software update installation. By default, this

setting is selected and display notifications are allowed on clients.

■ Suppress display notifications on clients: Specifies that display notifications

are not used on clients and progress indicators are not displayed during update

installation. Software update notification icons will still display on clients and

users can click this icon to see available updates.

Time Settings


■ Client Local Time: Specifies that clients use their local time to evaluate schedules

for the time when software updates become available on clients and when

deadlines enforce software update installation, if enabled.

■ UTC: Specifies that clients use UTC to evaluate schedules for the time when

software updates become available on clients and when deadlines enforce


software update installation. By default, this setting is selected and UTC is used to

evaluate deployment schedules.

Duration Setting

■ Duration: Specifies the duration, which is used only when creating a deployment

using a template. The deadline setting in the deployment defaults to the time

when an update is available plus the configured duration setting. By default, the

duration is set at 2 weeks.

Restart Settings Page

The Restart Settings page specifies the system restart behavior when a software

update installs on a client computer and requires a restart to complete. The following

settings are available on the Restart Settings page:

Suppress the system restart on:

■ Servers: Specifies whether to suppress a system restart on servers. This action is

requested by a software update installation when a restart is required for the

installation to complete. By default, this setting is not enabled, and servers will

restart if required by the software update installation.

■ Workstations: Specifies whether to suppress a system restart on workstations.

This action is requested by a software update installation when a restart is

required for the installation to complete. By default, this setting is not enabled,

and workstations will restart if required by the software update installation.

Specify whether to allow a system restart outside of maintenance windows both

for servers and for workstations:



maintenance windows. By default, this setting is not enabled, and when a system

restart is required for a software update installation to complete, it is initiated

only when more than 10 minutes are left in the configured maintenance window.

Recommendation

Suppressing system restarts can be useful in server environments or in cases in

which you do not want the computers that are installing the software updates to

restart by default. However, forcing a system restart after software update

installation ensures that updates fully complete, whereas suppressing post-

installation restart requests can leave systems in an insecure or unstable state.


Event Generation Page

The Event Generation page specifies whether Microsoft Operation Manager alerts

are disabled while the software updates install and whether an Operation Manager

alert is created when a software update installation fails. The following settings are

available on the Event Generation page:

■ Disable Operations Manager alerts while software updates run: Specifies

that Operation Manager alerts are disabled during the software update

installation. This is useful when deploying software updates will impact an

application that is being monitored by Operations Manager. By default, this

setting is not enabled.

■ Generate Operation Manager alert when a software update installation

fails: Specifies that an Operations Manager alert is created for each software

update installation failure. By default, this setting is not enabled.

Recommendation

These settings are useful when deploying software updates will impact an application

that is being monitored by Operations Manager. Disabling alerts while the update is

being installed will prevent alerts from triggering, such as a notification that a service

has stopped, as a result of the update installation. By default, these settings are not

enabled.

Download Settings Page

The Download Settings page specifies how Configuration Manager 2007 client

computers will interact with Distribution Points when they receive a software update

deployment. The following settings are available on the Download Settings page:

When a client is connected within a slow or unreliable network boundary:

■ Do not install software updates: Specifies that clients do not install software

updates if they are within network boundaries that are designated as slow or

unreliable. This is the default selection.

■ Download software updates from Distribution Point and install: Specifies

that clients download the software updates from the Distribution Point and

install them if they are within network boundaries that are designated as slow or

unreliable. This is the same behavior as if the client was within a local area

network boundary.

Specify whether to allow clients that are within the boundaries for one or more

protected Distribution Points to download and install software updates from

unprotected Distribution Points when the updates are not available from any

protected Distribution Point:


■ Do not install software updates: Indicates that when protected Distribution

Points do not have the software updates available for clients that are within the

protected Distribution Point boundaries, software updates will not be installed.

■ Download software updates from unprotected Distribution Point and

install: Indicates that when protected Distribution Points do not have the

software updates for clients that are within the protected Distribution Point

boundaries, the client will download the software updates from an unprotected

Distribution Point and install them. This is the default selection.

SMS 2003 Settings Page

The SMS 2003 Settings page specifies whether to deploy software updates to

SMS 2003 clients that are in the target collection. This setting is available only when

all of the software updates in the deployment have been synchronized using the

Inventory Tool for Microsoft Updates and have a value of Yes for the Deployable to

SMS 2003 setting. The following settings are available on the SMS 2003 Settings

page:

Deploy software updates to SMS 2003 clients

This setting specifies whether to deploy the software updates in the deployment to

SMS 2003 clients that are in the target collection. A package, package instruction files,

and advertisement are created and sent to child SMS 2003 sites to support the update

installation on SMS 2003 clients. By default, this setting is not enabled. When this

setting is selected, the following settings are available:

■ Collect hardware inventory immediately: Specifies whether to collect

hardware inventory on SMS 2003 clients immediately following software update

installation. This increases reporting accuracy but might increase system activity

on the SMS 2003 clients. By default, this setting is not enabled and hardware

inventory is collected during its scheduled hardware inventory cycle.

■ When a Distribution Point is available locally: Specifies that SMS 2003 clients

handle software update installation when the updates are available on a local

Distribution Point according to the following options:

□ Run update installation from Distribution Point: Specifies that the

software updates are installed from the Distribution Point. This is the default

setting.

□ Download updates from Distribution Point and then run installation:

Specifies that the software updates are downloaded from the Distribution

Point and then installed on the client.


■ When a client is connected within a slow or unreliable network boundary:

Specifies that SMS 2003 clients handle software update installation when the

updates are available only on remote Distribution Points according to the

following options:

□ Do not run update installation: Specifies that the software update

installation will not run. This is the default setting.

□ Download updates from a remote Distribution Point prior to update

installation: Specifies that the software updates are downloaded from the

Distribution Point and then installed on the client.

□ Run update installation from a remote Distribution Point: Specifies that

the software updates are installed from the remote Distribution Point.

Recommendation

When software updates are downloaded and then installed on SMS 2003 clients, all

updates contained in the package are downloaded regardless of applicability for the

client. If deployment packages contain a lot of updates that might not be applicable to

the SMS 2003 client, you should consider whether to run the update installation

directly from the Distribution Point.

Deployment Package Page

The Deployment Package page specifies the deployment package that will be used

to host the software updates in the deployment. The software updates in the

deployment are downloaded and copied to the deployment package folder on the

Distribution Points configured for the package. If all software updates in the

deployment have previously been downloaded and copied to a shared package folder

on the Distribution Point, the Deployment Package page of the wizard does not

display and the deployment is automatically configured to use the package that

downloaded the update. If the deployment targets SMS 2003 clients, the wizard will

always ask for a deployment package regardless of whether the updates have been

previously downloaded. The following settings are available on the Deployment

Package page:

■ Select deployment package: Specifies that an existing package is used for the

software updates in the deployment. Deployment packages that were created at

the site can be selected. Packages created at a parent site are not available.

■ Create a new deployment package: Specifies that a new package is created for

the software updates in the deployment. The following properties are configured

as part of the deployment package:


□ Deployment package name: Specifies the name of the deployment package.

The package should have a unique name, describe the package content, and is

limited to no more than 50 characters.

□ Deployment package description: Specifies the description of the

deployment package. The package description should describe the package

contents in detail and is limited to no more than 127 characters.

□ Deployment package source: Specifies the location of the software update

source files. When the deployment is generated, the source files are

compressed and copied to the Distribution Points that are associated with

the deployment package. The source location must be entered as a network

path (for example, \\server\sharename\path), or the Browse button can be

used to find the network location. The shared folder for the deployment

package source files must be manually created before proceeding to the next

page.

Important

The deployment package source location must not be used by another

deployment or software distribution package.

■ Deployment package sending priority: Specifies the sending priority for the

deployment package. The sending priority is used for the deployment package

when it is sent to Distribution Points at child sites. Packages are sent in priority

order: High, Medium, or Low. Packages with identical priorities are sent in the

order in which they were created. Unless there is a backlog, the package will

process immediately regardless of its priority.

■ Enable binary differential replication: Specifies whether binary delta

comparison should be used on changed package source files. Selecting the check

box enables this behavior and allows Distribution Manager to transfer only parts

of the file that have changed instead of the entire file. This behavior can result in

large bandwidth savings when transferring the changes for large files, compared

with the traditional method in which the entire file is transferred. For more

information, see About Binary Differential Replication. This setting can be

modified for existing packages in the properties for the package.

Download Location Page

The Download Location page specifies whether the software updates in the

deployment should be downloaded from the Internet or from the local network. The

following settings are available on the Download Location page:


■ Download software updates from the Internet: Specifies that the software

updates are downloaded from the location on the Internet that is defined in the

software update definition. This setting is enabled by default.

■ Download software updates from a location on the local network: Specifies that

the software updates are downloaded from a local directory or shared folder. Use

this setting if the site server does not have Internet access or if the software

updates are available on the local network. The software updates can be

downloaded from any computer that has Internet access and stored in a location

on the local network that is accessible from the site server.

Recommendation

If the software updates have already been downloaded to the Microsoft Windows

Server Update Services (WSUS) server on the active software update point, you can

specify Download software updates from a location on the local network and

configure \\<WSUS Server Name>\<WSUSContentPath> to download the software updates

from the WSUS server instead of the Internet.

Language Selection Page

The Language Selection page specifies the languages that are downloaded for the

selected software updates. The software updates are downloaded only if they are

available in the selected languages. Software updates that are not language specific

are always downloaded.

If all software updates in the deployment have previously been downloaded and

copied to the shared folder for the package on the Distribution Point, the Language

Selection page of the wizard does not display. The deployment is automatically

configured to download the updates in the languages that were previously

downloaded. The following settings are available on the Language Selection page:

■ Update File: Specifies the languages for which software update files are

downloaded. By default, the languages configured in the software update point

properties are selected. Selecting additional languages does not add them to the

configured software update point language settings. At least one language must

be selected before proceeding to the next page. If a language is selected on this

page that is not supported by the software update, the download will fail for the

software update.

Deployment Schedule

The Deployment Schedule page specifies when a software update deployment will

become active and whether software update installation will be enforced on clients.

The following settings are available on the Deployment Schedule page:

Select the data and time that software updates will be made available to clients:


■ As soon as possible: Specifies that the software updates in the deployment are

made available to clients as soon as possible. When the deployment is created,

the machine policy is updated, clients are made aware of the deployment at their

next machine policy evaluation cycle, and then the updates are available for

installation.

■ Date and time: Specifies that the software updates in the deployment will not be

made available to clients until a specific date and time. When the deployment is

created, the machine policy is updated and clients are made aware of the

deployment at their next machine policy evaluation cycle, but the software

updates in the deployment are not available for installation until the configured

date and time.

Specify whether the software updates should automatically install on clients at

a configured deployment deadline:

■ Do not set a deadline for software update installation: Specifies that the

software updates in the deployment are optional and do not require automatic

installation by a specific date and time.

■ Set deadline for software update installation: Specifies that the software

updates in the deployment are mandatory and require automatic installation by a

specific date and time. If the deadline is reached and the software updates in the

deployment are still required on the client, the update installation will

automatically be initiated. When a deadline is configured, the following

additional settings are available:

■ Enable Wake On LAN: Specifies whether to enable Wake On LAN at the deadline

to send wake-up packets to computers that require one or more updates in the

deployment. The computers that are not running are started at the deadline so

the update installation can be initiated. Clients that do not require any updates in

the deployment are not started. By default, this setting is not enabled and

available only when there is a deadline configured for the deployment.

■ Ignore maintenance windows and install immediately at deadline: Specifies



enabled and available only when there is a deadline configured for the

deployment.

More Information












After the software updates have been installed for the deployment with the earliest


will now display the deadline for the second deployment. SMS 2003 clients in the

Configuration Manager hierarchy will also use the configured deadline date and time

for deployments targeted to them.

NAP Evaluation Page

The NAP Evaluation page specifies whether the software updates in this deployment

are required for compliance when using Network Access Protection (NAP). Enable

NAP evaluation to include the software updates in a NAP policy that will become

effective on NAP-capable clients based on the configured schedule. When the policy

becomes effective, NAP-capable clients might have restricted access until they comply

with the selected software update. Network restriction and remediation are

dependent on how the policies are configured on the Windows Network Policy

Server. The following settings are available on the Deployment Schedule page:

■ Enable NAP evaluation: Specifies whether the software update is included in the

NAP policy and evaluated on NAP-capable clients. When this setting is selected,

the following settings are available:

■ Specify when these settings become effective:

■ As soon as possible: Specifies that the software update is included in the NAP

policy, which becomes effective on NAP-capable clients as soon as possible.

■ Date and time: Specifies that the software update is included in the NAP policy,

which becomes effective on NAP-capable clients on the specified date and time.

The default date and time value is determined by adding 14 days to the

deployment deadline date and time that was configured on the Deployment

Schedule page.

The NAP evaluation page of the Deploy Software Updates Wizard does not display unless NAP is configured for the site


Using Deployment Templates When Creating Deployments
















helps to prevent mistakes when configuring the deployment. The deployment

settings from the following wizard pages can be configured in a deployment template:

■ Collection

■ Display/Time Settings

■ Restart Settings

■ Event Generation

■ Download Settings

■ SMS 2003 Settings

If a deployment template is not used when creating a deployment, the properties are

manually entered and can optionally be saved as a deployment template within the

wizard and used in future deployments.

Maintenance Windows

When maintenance windows are configured on collections that will be targeted for

software update deployments, you should consider the following:

■ Each software update is given a default setting of 35 minutes to install and

restart, if necessary (75 minutes for service packs). When the available time left

in a maintenance window is less than this, the software update installation will


not start until the next maintenance window. When planning a deployment to a

collection with maintenance windows, take these defaults into consideration. For

example, if a 2-hour maintenance window is configured on the collection and

there are four software updates in a deployment, only three software updates

will be installed during the first maintenance window and the last update will be

installed during the second maintenance window.

The following deployment settings affect how software updates are installed on client

computers that have maintenance windows:



maintenance windows. By default, this setting is not enabled. This setting is

beneficial when you want your software update installation to complete on client

computers as soon as possible. When this setting is not specified, a system restart

will not be initiated if the maintenance window ends in 10 minutes or less. This

could prevent the installation from completing and leave the client computer in a

vulnerable state until the next maintenance window. This setting is available on

the Restart Settings page of the Deployment Template Wizard or Deploy

Software Updates Wizard.

■ Ignore maintenance windows and install immediately at deadline: Specifies



enabled and is available only when there is a deadline configured for the

deployment. This setting is beneficial when there are software updates that must

be installed on client computers as soon as possible, such as the updates in an

expedited deployment. This setting is available on the Schedule page of the

Deploy Software Updates Wizard.

Restart Behavior on Client Computers

When software update installations have run and require a restart for them to

complete, new software updates that become available are not shown and the

notification area icon will not be visible on client computers. A system restart will be

automatically initiated on client computers when the deadline has been reached on

mandatory deployments. When multiple deployments have the same deadline, the

software updates will all be installed at the deadline and then one system restart will

be initiated.


Note

Some software updates must be installed exclusively, and a system restart might be initiated for these software updates before installing other updates in the same deployment or in deployments with the same deadline.

Hiding Deployments from End Users

To hide software update deployment and installation on client computers, use the

Hide all deployments from end users setting on the Update Installation tab of the

Software Updates Client Agent properties. This setting specifies that display

notifications and notification area icons for the software updates in all deployments

will not display on client computers. This setting is not enabled by default. When this

setting is enabled, the software updates only in mandatory deployments are available

for installation and the silent installation will initiate by the configured deadline.

Hidden deployments will become visible on client computers when this setting is not

enabled.

Software Updates with License Terms

When a software update has associated Microsoft Software License Terms and the

terms have not yet been accepted, the Review/Accept License Terms dialog box

displays before opening the Deploy Software Updates Wizard. After the license terms

for a software update have been accepted, the wizard opens and the software updates

can be deployed. Future deployments for the software update will not require license

terms acceptance. If the license terms are declined, the process is cancelled. The

license terms can also be accepted from the Configuration Manager console by

highlighting one or more software updates, and then initiating the Review/Accept

License Terms action.


Using an update list provides the ability to delegate the administration for deploying

software updates. For example, an administrator at the central site can select the

software updates that need to be deployed and add the updates to an update list.

Administrators at the site or child sites, with restricted object rights, can then use the

update list and deploy the updates in the update list to an appropriate collection.

Planning for SMS 2003 Deployments

If SMS 2003 clients are in the Configuration Manager 2007 hierarchy, additional steps

must be taken and special considerations should be made before deploying software

updates to them.


What Software Updates Can Be Deployed to SMS 2003 Clients

All software updates that have been synchronized using the Inventory Tool for

Microsoft Updates can be deployed to SMS 2003 clients. After the Microsoft Update

catalog has been synchronized, the Deployable to SMS 2003 setting is set to Yes.

The option to deploy to SMS 2003 clients is available only when every update in the

deployment is deployable to SMS 2003.

Using Deployment Templates When Creating SMS 2003 Deployments

If all the software updates that are selected for deployment are deployable to

SMS 2003, you can select a deployment template that has the Deploy software

updates to SMS 2003 clients setting enabled. If at least one software update is not

deployable to SMS 2003 clients, templates that deploy updates to SMS 2003 clients

are not available for use when creating the deployment.

Selective Download Is Not Available for SMS 2003 Clients

Configuration Manager 2007 client computers download only the software updates

from a deployment package that they require. This allows administrators to create

large deployment packages that support multiple deployments. By default, when

deploying software updates to SMS 2003 clients, the software update installation is

run directly from a Distribution Point. When it is configured to download software

updates and then install on the SMS 2003 Settings page of the Deploy Software

Updates Wizard, the SMS 2003 client will download all updates contained in the

deployment package regardless of applicability. If a deployment package contains a

lot of updates that might not be applicable to the SMS 2003 clients, it is recommended

that you run the update installation directly from the Distribution Point.

Software Updates Security Best Practices and Privacy Information

Applying the most recent security updates is a security best practice. Microsoft

System Center Configuration Manager 2007 can make it easier to apply software

updates to computers in your organization. However, there are some best practices to

help prevent attackers from hijacking the software update infrastructure.

Security Best Practices

Do not change the default permissions on software update packages By default,

software update packages are set to allow administrators full control and users read

access. Changing these permissions could allow an attacker to add, remove, or delete

software updates.

Control access to the download location for software updates The SMS Provider

computer account and the user who will actually download the software updates to


the download location both require write access to the download location. Restrict

access to the download location to reduce the risk of attackers tampering with the

software updates source file sin the download location.

Use UTC for evaluating deployment times If you use local time instead of UTC,

users could potentially delay installation of software updates by changing the time

zone on their computers.

Follow best practices for securing WSUS For information about securing WSUS,

including adding Active Directory authentication and SSL, see

http://go.microsoft.com/fwlink/?LinkId=93170.

Important

If your site is in native mode, in addition to performing the typical steps for configuring SSL on the WSUS server, you must enable SSL on some additional virtual roots to support Configuration Manager 2007 native mode.

Enable CRL checking By default, the certificate revocation list (CRL) is not checked

when verifying the signature on software updates. Checking the CRL each time a

certificate is used offers more security against using a certificate that has been

revoked, but it introduces a connection delay and incurs additional processing on the

computer performing the CRL check.

If the software update point is configured in a perimeter network, configure the

site server to retrieve the data from the site system By default, site systems push

their data back to the site server. A site system can be configured to require the site

server to pull the data instead, which allows great control of the ports and

permissions required for the data transfer. The setting Allow only site server initiated

data transfers from this site system applies to the entire site system and all site

system roles configured on it.

If you must deploy software updates to SMS 2003 clients, run the Inventory

Tool for Microsoft Updates on a primary site server that is highest in the

hierarchy While it is not required to install the Inventory Tool for Microsoft Updates

on the central server, you should always install it on the highest site that clients

report to. If the scan tool is installed on a primary site lower in the hierarchy, the sites

higher in the hierarchy are not able to report on the software updates.

Configure WSUS to use a custom web site When installing WSUS on the software

update point, you have the option to use the existing IIS Default Web site or to create

a custom WSUS 3.0 Web site. You should create a custom Web site for WSUS so that

Internet Information Services (IIS) hosts the WSUS 3.0 services in a dedicated virtual



Web site instead of sharing the same Web site used by the other Configuration

Manager 2007 site systems or other applications.

Enable BITS 2.5 for the site and the Distribution Points When software updates

install on clients, the source files are first downloaded to the cache on the client

computer and then installed. If BITS is enabled on the Distribution Point,

disconnection from the network while software updates are downloading does not

cause the deployment to fail because BITS resumes the download, starting where it

was interrupted, the next time the client has network access. If BITS is not enabled on

the Distribution Point and a network problem occurs while downloading software

update files, the software update installation fails, which could leave the client

vulnerable to attack.

Privacy Information

Software updates scans your client computers to determine which software updates

you require, and then sends that information back to the site database. During the

software updates process, Configuration Manager 2007 might transmit information

between clients and servers that identify the computer and logon accounts.

Configuration Manager 2007 maintains state information about the software

distribution process. State information is not encrypted during transmission or

storage. State information is stored in the site database and deleted by the database

maintenance tasks. No state information is sent back to Microsoft.

The use of Configuration Manager 2007 software updates to install software updates

on client computers might be subject to software license terms for those updates,

which is separate from the Software License Terms for Configuration Manager 2007.

You should always review and agree to the Software Licensing Terms prior to

installing the software updates using Configuration Manager 2007.

Configuration Manager 2007 does not implement software updates by default and

requires several configuration steps before information is collected. Before

configuring software updates, consider your privacy requirements.

Solution

Do not click these URL links. They are used only to display a unique name for the

uninterpreted configuration item and do not reference a Web resource.


Troubleshooting SUM


Site Server Log Files The Configuration Manager 2007 site server log files are found, by default, in

<InstallationPath>\Logs. The following table provides the log file names and descriptions

Troubleshooting SUM

File Name Descriptionciamgr.log Provides information about the addition, deletion, and modification of software update configuration items.

distmgr.log Provides information about the replication of software update deployment packages.

objreplmgr.log Provides information about the replication of software updates notification files from a parent to child sites.

PatchDownloader.log Provides information about the process for downloading software updates from the update source specified in the software updates metadata to the download destination on the site server.

replmgr.log Provides information about the process for replicating files between sites.

smsdbmon.log Provides information about when software update configuration items are inserted, updated, or deleted from the site server database and creates notification files for software updates components.

SUPSetup Provides information about the software update point installation. When the software update point installation

completes, Installation was successful is written to this log file.

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 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.

Monitoring Software Updates

At various points in the software updates process, you can use Microsoft System

Center Configuration Manager 2007 reports to view the compliance levels for specific

vulnerabilities and software updates, monitor the state of software update

deployments, and check the health of the software update components. For example,

if a new critical update is released for a particular vulnerability in Windows

Server 2003, you can run a report that shows all the computers running Windows

Server 2003 in your enterprise that are missing the critical update. When you

authorize and deploy that software update, you can periodically run another report

that shows compliance levels as reflected in state messages.

The following table lists the features that are available for monitoring software

update processes.

Table 33. Features Available for Monitoring Software Updates

Feature Description


Feature Description

Software updates status messages

The software updates components send status messages that contain information about the component installation, component processes, and component health. You can use the Configuration Manager 2007 status system to view the status messages for software updates components to help with monitoring and troubleshooting.

Software updates reporting Software updates state messages provide information about the compliance of software updates and the evaluation and enforcement state of software update deployments. The software updates reports are used to display the state messages. There are more than 25 predefined software updates reports organized in several categories that can be used to report on specific information about software updates and deployments. In addition to using the preconfigured reports, you can also create custom software updates reports, tailored to the needs of your enterprise.

Log Files for Software Updates

The log files in Configuration Manager 2007 provide detailed information about the

associated components and can be helpful when verifying functionality or when

troubleshooting issues. The log files can be found on the site server, the Windows

Server Update Services (WSUS) server, and in two locations on the client computers.

Site Server Log Files

The Configuration Manager 2007 site server log files are found, by default, in

<InstallationPath>\Logs. The following table provides the log file names and

descriptions.

Table 34 Site Server Log files for SUM

File Name Description

ciamgr.log Provides information about the addition, deletion, and modification of software update configuration items.

distmgr.log Provides information about the replication of software update deployment packages.

objreplmgr.log Provides information about the replication of software updates notification files from a parent to child sites.

PatchDownloader.log Provides information about the process for downloading software updates from the update source specified in the software updates metadata to the download destination on the site server.



replmgr.log Provides information about the process for replicating files between sites.

smsdbmon.log Provides information about when software update configuration items are inserted, updated, or deleted from the site server database and creates notification files for software updates components.

SUPSetup Provides information about the software update point installation. When the

software update point installation completes, Installation was

successful is written to this log file.

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 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.

WSUS Server Log Files

The log files for the WSUS server are found, by default, in %ProgramFiles%\Update

Services\LogFiles. The following table provides the log file names and descriptions.

Table 35 WSUS Server Log files


Change.log Provides information about the WSUS server database information that has changed.

SoftwareDistribution.log Provides information about the software updates that are synchronized from the configured update source to the WSUS server database.

Client Computer Log Files

The Configuration Manager 2007 client computer log files are found, by default, in

%windir%\CCM\Logs. For client computers that are also management points, the log

files are found in %ProgramFiles%\SMS_CCM\Logs. The following table provides the

log file names and descriptions.

Table 36 Client computer log files for SUM




CAS.log Provides information about the process of downloading software updates to the local cache and cache management.

CIAgent.log Provides information about processing configuration items, including software updates.

LocationServices.log Provides information about the location of the WSUS server when a scan is initiated on the client.

PatchDownloader.log Provides information about the process for downloading software updates from the update source to the download destination on the site server. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.

PolicyAgent.log Provides information about the process for downloading, compiling, and deleting policies on client computers.

PolicyEvaluator Provides information about the process for evaluating policies on client computers, including policies from software updates.

RebootCoordinator.log Provides information about the process for coordinating system restarts on client computers after software update installations.

ScanAgent.log Provides information about the scan requests for software updates, what tool is requested for the scan, the WSUS location, and so on.

ScanWrapper Provides information about the prerequisite checks and the scan process initialization for the Inventory Tool for Microsoft Updates on Systems Management Server (SMS) 2003 clients.

SdmAgent.log Provides information about the process for verifying and decompressing packages that contain configuration item information for software updates.

ServiceWindowManager.log Provides information about the process for evaluating configured maintenance windows.

smscliUI.log Provides information about the Configuration Manager Control Panel user interactions, such as initiating an Software Updates Scan Cycle from the Configuration Manager Properties dialog box, opening the Program Download Monitor, and so on.

SmsWusHandler Provides information about the scan process for the Inventory Tool for Microsoft Updates on SMS 2003 client computers.

StateMessage.log Provides information about when software updates state messages are created and sent to the management point.



UpdatesDeployment.log Provides information about the deployment on the client, including software update activation, evaluation, and enforcement. Verbose logging shows additional information about the interaction with the client user interface.

UpdatesHandler.log Provides information about software update compliance scanning, and the download and installation of software updates on the client.

UpdatesStore.log Provides information about the compliance status for the software updates that were assessed during the compliance scan cycle.

WUAHandler.log Provides information about when the Windows Update Agent on the client searches for software updates.

WUSSyncXML.log Provides information about the Inventory Tool for Microsoft Updates synchronization process. This log is only on the client computer configured as the synchronization host for the Inventory Tool for Microsoft Updates.

Windows Update Agent Log File

The Windows Update Agent log file is found on the Configuration Manager Client

computer, by default, in %windir%. The following table provides the log file name and

description.

Table 37 WUA Log file


WindowsUpdate.log Provides information about when the Windows Update Agent connects to the WSUS server and retrieves the software updates for compliance assessment and whether there are updates to the agent components.



User Without Sufficient Rights Cannot See Console Objects

If your account has not been assigned object rights in the Configuration Manager 2007 console, you see only the nodes you have rights to. You must also be a member of the SMS Adminsgroup or have equivalent rights

Solution

Ask someone with Administer rights to grant you permissions to the classes and instances you need to manage. Verify that your account is a member of the SMS Admins group on the site server and the SMS Provider computer.

Troubleshooting Config Mgr Console Issues

Troubleshooting Configuration Manager Console Issues

This section provides links to information about troubleshooting issues with the

Microsoft System Center Configuration Manager 2007 console.

Issues with the System Center Configuration Manager console can be traced in the

SMSAdminUI.log. The SMSAdminUI.log file is not stored with the rest of the

Configuration Manager 2007 log files; it is located in the <Installation

Directory>\AdminUI\AdminUILog directory. By default, only Administrators and SMS

Admins have permissions to the file.

User Without Sufficient Rights Cannot See Console Objects

If your account has not been assigned object rights in the Configuration Manager

2007 console, you see only the nodes you have rights to. You must also be a member

of the SMS Admins group or have equivalent rights

Solution

Ask someone with Administer rights to grant you permissions to the classes and

instances you need to manage. Verify that your account is a member of the SMS

Admins group on the site server and the SMS Provider computer.

Attempting to Connect to the Database Generates an Error

If your account does not have Remote Activation permission on the site server and

the SMS Provider computer, you get an error message telling you that you cannot

connect to the site database.


Solution

Grant Remote Activation permission on the site server and the SMS Provider

computer. If you are attempting to manage a secondary site, you must have rights to

the SMS Provider at the parent site.

Upgraded Administrators Do Not Have Access to All Objects

After upgrading, the user who ran the upgrade has access to all of the objects in the

Configuration Manager 2007 console but existing administrators have access only to

objects that existed prior to upgrade.

Solution

This is a known issue. Only the user who runs Setup has access to the new objects

after an upgrade. Manually grant administrators access to the new objects they will

manage.

Note

This is true even for software updates objects. Users who had full rights to all SMS 2003 software updates objects will have full rights to the same objects in Configuration Manager 2007 but will not have any rights to new object types such as templates.

Error Message: This Function Is Not Supported On This Site System

If you do not have permissions to the files and registry keys needed to run the

Configuration Manager 2007 console, you get the error message " This function is not

supported on this site system."

Solution

Verify that your account is a member of the SMS Admins group on the SMS Provider

computer. You might also see this error if you are not a member of the local

Administrators group, however you can first run MMC and then add the

Configuration Manager 2007 console as a snap-in instead of being a local

Administrator on the Configuration Manager 2007 console computer. After the new

console session is saved, you can also run the new console without being a local

Administrator.

Text in Dialog Boxes is Highlighted with a Blue Background

This is by design, to enable screen readers used for accessibility purposes to read the

text in the dialog box.



To enable verbose logging for the Configuration Manager console

1. Navigate to the <InstallationPath>\AdminUI\bin folder

2. Using a text editor, open adminui.console.dll.config

3. Change the line <source name="SmsAdminUISnapIn" switchValue="Error" > to <source name="SmsAdminUISnapIn" switchValue="Verbose" >

4. Restart the Configuration Manager 2007 console.

5. Examine the <InstallationPath>\AdminUI\SMSAdminUI.log file for additional information

6. After verbose logging is no longer needed, reset the SwitchValueto Error again to remove the processing overhead

How to Enable Verbose Logging for the Console

How to Enable Verbose Logging for the Console

Verbose logging is often useful in Microsoft System Center Configuration Manager

2007 when troubleshooting issues with the Configuration Manager 2007 console.

Important

Before sharing verbose log output with people outside of your organization, verify that no sensitive data is recorded in the log file.

To enable verbose logging for the Configuration Manager console

1. Navigate to the <InstallationPath>\AdminUI\bin folder.

2. Using a text editor, open adminui.console.dll.config

3. Change the line <source name="SmsAdminUISnapIn" switchValue="Error" > to

<source name="SmsAdminUISnapIn" switchValue="Verbose" >

4. Restart the Configuration Manager 2007 console.

5. Examine the <InstallationPath>\AdminUI\SMSAdminUI.log file for additional

information.

After verbose logging is no longer needed, reset the SwitchValue to Error again to

remove the processing overhead.

SCCM2007_Workbook__2008-12-15

Documents

Transcript of SCCM2007_Workbook__2008-12-15