Dijeli putem

  • Članak

Introduction to Software Updates in Configuration Manager

 

Updated: June 26, 2015

Applies To: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

Software updates in System Center 2012 Configuration Manager 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. 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, effective software update management requires consistent and continual attention.

See the following sections for more information about software updates:

  • Software Updates Synchronization

  • Software Updates Compliance Assessment

  • Software Update Deployment Packages

  • Software Update Deployment Workflows

  • Software Update Deployment Process

  • Extend Software Updates in Configuration Manager

  • Support for Windows Embedded Devices That Use Write Filters

  • Network Access Protection

  • What’s New in Configuration Manager

  • What’s New in Configuration Manager SP1

  • What’s New in System Center 2012 R2 Configuration Manager

For an example scenario that shows how you might deploy software updates in your environment, see Example Scenario for Using Configuration Manager to Deploy and Monitor the Security Software Updates Released Monthly by Microsoft.

Software Updates Synchronization

Software updates synchronization in Configuration Manager uses Microsoft Update to retrieve software updates metadata. The top-level site (central administration site or stand-alone primary site) synchronizes with Microsoft Update on a schedule or when you manually start synchronization from the Configuration Manager console. When Configuration Manager finishes software updates synchronization at the top-level site, software updates synchronization starts at child sites, if they exist. When synchronization is complete at each primary site or secondary site, a site-wide policy is created that provides to client computers the location of the software update points.

Note

Software updates are enabled by default in client settings. However, if you set the Enable software updates on clients client setting to No to disable software updates on a collection or in the default settings, the location for software update points are not sent to associated clients. For more information about the software updates client settings, see the Software Updates section in the About Client Settings in Configuration Manager topic.

After the client receives the policy, the client starts a scan for software updates compliance and writes the information to Windows Management Instrumentation (WMI). The compliance information is then sent to the management point that then sends the information to the site server. For more information about compliance assessment, see the Software Updates Compliance Assessment section in this topic.

For System Center 2012 Configuration Manager SP1 and later:

Starting in Configuration Manager SP1, you can install multiple software update points at a primary site. The first software update point that you install is configured as the synchronization source. This synchronizes from Microsoft Update or a WSUS server not in your Configuration Manager hierarchy. The other software update points at the site use the first software update point as the synchronization source.

Note

When the software updates synchronization process is complete at the top-level site, the software updates metadata is replicated to child sites by using database replication. When you connect a Configuration Manager console to the child site, Configuration Manager displays the software updates metadata. However, until you install and configure a software update point at the site, clients will not scan for software updates compliance, clients will not report compliance information to Configuration Manager, and you cannot successfully deploy software updates.

Synchronization on the Top-Level Site

The software updates synchronization process at the top-level site retrieves from Microsoft Update the software updates metadata that meet the criteria that you specify in Software Update Point Component properties. You configure the criteria only at the top-level site.

Note

Starting in Configuration Manager SP1, at the top-level site, you can specify as the synchronization source instead of Microsoft Update an existing WSUS server that is not in the Configuration Manager hierarchy.

The following list describes the basic steps for the synchronization process on the top-level site:

  1. Software updates synchronization starts.

  2. WSUS Synchronization Manager sends a request to WSUS running on the software update point to start synchronization with Microsoft Update.

  3. The software updates metadata is synchronized from Microsoft Update, and any changes are inserted or updated in the WSUS database.

  4. When WSUS has finished synchronization, WSUS Synchronization Manager synchronizes the software updates metadata from the WSUS database to the Configuration Manager database, and any changes after the last synchronization are inserted or updated in the site database. The software updates metadata is stored in the site database as a configuration item.

  5. The software updates configuration items are sent to child sites by using database replication.

  6. When synchronization has finished successfully, WSUS Synchronization Manager creates status message 6702.

  7. WSUS Synchronization Manager sends a synchronization request to all child sites.

  8. For a stand-alone primary site that is running System Center 2012 Configuration Manager SP1 only:

    WSUS Synchronization Manager sends a request one at a time to WSUS running on other software update points at the site. The WSUS servers on the other software update points are configured to be replicas of WSUS running on the default software update point at the site.

Synchronization on Child Primary and Secondary Sites

During the software updates synchronization process on the top-level site, the software updates configuration items are replicated to child sites by using database replication. At the end of the process, the top-level site sends a synchronization request to the child site, and the child site starts the WSUS synchronization. The following list provides the basic steps for the synchronization process on a child primary site or secondary site:

  1. WSUS Synchronization Manager receives a synchronization request from the top-level site.

  2. Software updates synchronization starts.

  3. WSUS Synchronization Manager makes a request to WSUS running on the software update point to start synchronization.

  4. WSUS running on the software update point on the child site synchronizes software updates metadata from WSUS running on the software update point on the parent site.

  5. When synchronization has finished successfully, WSUS Synchronization Manager creates status message 6702.

  6. From a primary site, WSUS Synchronization Manager sends a synchronization request to any child secondary sites. The secondary site starts the software updates synchronization with the parent primary site. The secondary site is configured as a replica of WSUS running on the parent site.

  7. For Configuration Manager with no service pack only:

    When there is a remote Internet-based software update point, WSUS Synchronization Manager starts the synchronization process for WSUS running on the remote site system.

  8. For System Center 2012 Configuration Manager SP1 and later: 

    WSUS Synchronization Manager sends a request one at a time to WSUS running on other software update points at the site. The WSUS servers on the other software update points are configured to be replicas of WSUS running on the default software update point at the site.

Synchronization for Internet-Based Software Update Points

Important

This section applies to Configuration Manager with no service pack only.

When synchronization has finished for the active software update point at a site, synchronization is started for the active Internet-based software update point for the site, if you configured it. This process resembles the synchronization process on child sites, except that WSUS running on the active Internet-based software update point synchronizes with WSUS running on the active software update point for the same site.

  1. WSUS Synchronization Manager makes a request to WSUS running on the remote Internet-based software update point to start synchronization.

  2. WSUS running on the remote Internet-based software update point synchronizes software updates metadata from WSUS running on the active software update point for the same site.

  3. When synchronization has finished successfully, WSUS Synchronization Manager creates status message 6702.

  4. WSUS Synchronization Manager sends a synchronization request to any child sites.

When the synchronization source configured for the Internet-based software update point is not configured to synchronize with an upstream update server, you can use the Export and Import functions of the WSUSutil tool to synchronize software updates metadata from an active software update point for the site. For more information, see the Synchronize Software Updates from a Disconnected Software Update Point section in the Configuring Software Updates in Configuration Manager topic.

Software Updates Compliance Assessment

Before you deploy software updates to client computers in Configuration Manager, start a scan for software updates compliance on client computers. For each software update, a state message is created that contains the compliance state for the update. The state messages are sent in bulk to the management point and then to the site server, where the compliance state is inserted into the site database. The compliance state for software updates is displayed in the Configuration Manager console. You can deploy and install software updates on 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

The following table lists and describes each compliance state that is displayed in the Configuration Manager console for software updates.

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 was not deployed to the client computer.

  • The software update was installed on the client computer. However, 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 has finished. There might be a delay of up to two minutes before the client sends the updated state to the management point that then forwards the updated state to the site server.

  • The software update was installed on the client computer. However, the software update installation requires a computer restart before the update is completed.

  • The software update was deployed to the client computer but has not yet been installed.

Not Required

Specifies that the software update is not applicable on the client computer. 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 the site server has not received a state message from the client computer, typically because one of the following:

  • The client computer did not successfully scan for software updates compliance.

  • The scan finished successfully on the client computer. However, the state message has not yet been processed on the site server, possibly because of a state message backlog.

  • The scan finished successfully on the client computer, but the state message has not been received from the child site.

  • The scan finished successfully on the client computer, but the state message file was corrupted in some way and could not be processed.

Scan for Software Updates Compliance Process

When the software update point is installed and synchronized, a site-wide machine policy is created that informs client computers that Configuration Manager Software Updates was enabled for the site. When a client receives the machine policy, a compliance assessment scan is scheduled to start randomly within the next two hours. When the scan is started, a Software Updates Client Agent process 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 must connect to the WSUS server by using SSL.

A scan request is passed to the Windows Update Agent (WUA). The WUA then connects to the WSUS server location that is listed in the local policy, retrieves the software updates metadata that has been synchronized on the WSUS server, and scans the client computer for the updates. A Software Updates Client Agent process detects that the scan for compliance has finished, and it creates state messages for each software update that changed in compliance state after the last scan. The state messages are sent to the management point in bulk every 15 minutes. The management point then forwards the state messages to the site server, where the state messages are inserted into the site server database.

After the initial scan for software updates compliance, the scan is started at the configured scan schedule. However, if the client has scanned for software updates compliance in the time frame indicated by the Time to Live (TTL) value, the client uses the software updates metadata that is stored locally. When the last scan is outside the TTL, the client must connect to WSUS running on the software update point and update the software updates metadata stored on the client.

Including the scan schedule, the scan for software updates compliance can start in the following ways:

  • Software updates scan schedule: The scan for software updates compliance starts at the configured scan schedule that is configured in the Software Updates Client Agent settings. For more information about how to configure the Software Updates client settings, see the see the Software Updates section in the About Client Settings in Configuration Manager topic.

  • Configuration Manager Properties action: The user can start the Software Updates Scan Cycle or Software Updates Deployment Evaluation Cycle action on the Action tab in the Configuration Manager Properties dialog box on the client computer.

  • Deployment reevaluation schedule: The deployment evaluation and scan for software updates compliance starts at the configured deployment reevaluation schedule, which is configured in the Software Updates Client Agent settings. For more information about the Software Updates client settings, see the Software Updates section in the About Client Settings in Configuration Manager topic.

  • Prior to downloading update files: When a client computer receives an assignment policy for a new required deployment, the Software Updates Client Agent downloads the software update files to the local client cache. Before downloading the software update files, the client agent starts a scan to verify that the software update is still required.

  • Prior to software update installation: Just before the software update installation, the Software Updates Client Agent starts a scan to verify that the software updates are still required.

  • After software update installation: Just after a software update installation is complete, the Software Updates Client Agent starts a scan to verify that the software updates are no longer required and creates a new state message that states that the software update is installed. When the installation has finished, but a restart is necessary, the state message indicates that the client computer is pending a restart.

  • After system restart: When a client computer is pending a system restart for the software update installation to finish, the Software Updates Client Agent starts a scan after the restart to verify that the software update is no longer required and creates a state message that states that the software update is installed.

Time to Live Value

The software updates metadata that is required for the scan for software updates compliance is stored on the local client computer, and by default, is relevant for up to 24 hours. This value is known as the Time to Live (TTL).

Scan for Software Updates Compliance Types

The client scans for software updates compliance by using an online or offline scan and a forced or non-forced scan, depending on the way the scan for software updates compliance is started. The following table describes which methods for starting the scan are online or offline and whether the scan is forced or non-forced.

Scan method

Scan type

Description

Software updates scan schedule

Non-forced online scan

At the configured scan schedule, the client connects to WSUS running on the software update point to retrieve the software updates metadata only when the last scan was outside the TTL.

Software Updates Scan Cycle

or

Software Updates Deployment Evaluation Cycle

Forced online scan

The client computer always connects to WSUS running on the software update point to retrieve the software updates metadata before the client computer scans for software updates compliance. After the scan is complete, the TTL counter is reset. For example, if the TTL is 24 hours, after a user starts a scan for software updates compliance, the TTL is reset to 24 hours.

Deployment reevaluation schedule

Non-forced online scan

At the configured deployment reevaluation schedule, the client connects to WSUS running on the software update point to retrieve the software updates metadata only when the last scan was outside the TTL.

Prior to downloading update files

Non-forced online scan

Before the client can download update files in required deployments, the client connects to WSUS running on the software update point to retrieve the software updates metadata only when the last scan was outside the TTL.

Prior to software update installation

Non-forced online scan

Before the client installs software updates in required deployments, the client connects to WSUS running on the software update point to retrieve the software updates metadata only when the last scan was outside the TTL.

After software update installation

Forced offline scan

After a software update is installed, the Software Updates Client Agent starts a scan by using the local metadata. The client never connects to WSUS running on the software update point to retrieve software updates metadata.

After system restart

Forced offline scan

After a software update is installed and the computer is restarted, the Software Updates Client Agent starts a scan by using the local metadata. The client never connects to WSUS running on the software update point to retrieve software updates metadata.

Software Update Deployment Packages

A software update deployment package is the vehicle used to download software updates to a network shared folder, and copy the software update source files to the content library on site servers and on distribution points that are defined in the deployment. By using the Download Updates Wizard, you can download software updates and add them to deployment packages before you deploy them. This wizard lets you provision software updates on distribution points and verify that this part of the deployment process is successful before you deploy the software updates to clients.

When you deploy downloaded software updates by using the Deploy Software Updates Wizard, the deployment automatically uses the deployment package that contains the software updates. When software updates that have not been downloaded are deployed, you must specify a new or existing deployment package in the Deploy Software Updates Wizard, and the software updates are downloaded when the wizard is finished.

Important

You must manually create the shared network folder for the deployment package source files before you specify it in the wizard. Each deployment package must use a different shared network folder.

System_CAPS_security Security Note

The SMS Provider computer account and the administrative user who actually downloads the software updates both require Write permissions to the package source. Restrict access to the package source to reduce the risk of an attacker tampering with the software updates source files in the package source.

When a new deployment package is created, the content version is set to 1 before any software updates are downloaded. When the software update files are downloaded by using the package, the content version is incremented to 2. Therefore, all new deployment packages start with a content version of 2. Every time that the content changes in a deployment package, the content version is incremented by 1. For more information about content management in Configuration Manager, see Introduction to Content Management in Configuration Manager.

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 still can install the software updates in the deployment as long as each update was downloaded to at least one other deployment package and is available on a distribution point that can be accessed from the client. When the last deployment package that contains a software update is deleted, client computers cannot retrieve the software update until the update is downloaded again to a deployment package. Software updates appear with a red arrow in the Configuration Manager console when the update files are not in any deployment packages. Deployments appear with a double red arrow if they contain any updates in this condition.

Software Update Deployment Workflows

There are two main scenarios for deploying software updates in your environment, manual deployment and automatic deployment. Typically, you deploy software updates manually to create a baseline for client computers, and then you manage software updates on clients by using automatic deployment. The following sections provide a summary for the workflow for manual and automatic deployment for software updates.

Manual Deployment of Software Updates

Manual deployment of software updates is the process of selecting software updates in the Configuration Manager console and manually starting the deployment process. You typically use this method of deployment to get the client computers up-to-date with required software updates before you create automatic deployment rules that manage ongoing monthly software update deployments, and to deploy out of band software update requirements. The following list provides the general workflow for manual deployment of software updates:

  1. Filter for software updates that use specific requirements. For example, you could provide criteria that retrieves all security or critical software updates that are required on more than 50 client computers.

  2. Create a software update group that contains the software updates.

  3. Download the content for the software updates in the software update group.

  4. Manually deploy the software update group.

Automatic Deployment of Software Updates

Automatic software updates deployment is configured by using automatic deployment rules. You typically use this method of deployment for your monthly software updates (generally known as Patch Tuesday) and for managing definition updates. When the rule runs, software updates are removed from the software update group (if using an existing group), the software updates that meet a specified criteria (for example, all security software updates released in the last week) are added to a software update group, the content files for the software updates are downloaded and copied to distribution points, and the software updates are deployed to client computers in the target collection. The following list provides the general workflow for automatic deployment of software updates:

  1. Create an automatic deployment rule that specifies deployment settings such as the following:

    • Target collection

    • Decide whether to enable the deployment or report on software updates compliance for the client computers in the target collection

    • Software updates criteria

    • Evaluation and deployment schedules

    • User experience

    • Download properties

  2. The software updates are added to a software update group.

  3. The software update group is deployed to the client computers in the target collection, if it is specified.

You must determine what deployment strategy to use in your environment. For example, you might create the automatic deployment rule and target a collection of test clients. After you verify that the software updates are installed on the test group, you can change the collection in the automatic deployment rule to a target collection that includes a larger set of clients. The software update objects that are created by the automatic deployment rules are interactive.

  • Software updates that were deployed by using an automatic deployment rule are automatically deployed to new clients added to the target collection.

  • New software updates added to a software update group are automatically deployed to the clients in the target collection.

  • You can enable or disable deployments at any time for the automatic deployment rule.

Software Update Deployment Process

After you deploy software updates or when an automatic deployment rule runs and deploys software updates, a deployment assignment policy is added to the machine policy for the site. The software updates are downloaded from the download location, the Internet, or network shared folder, to the package source. The software updates are copied from the package source to the content library on the site server, and then copied to the content library on the distribution point.

When a client computer in the target collection for the deployment receives the machine policy, the Software Update Client Agent starts an evaluation scan. The client agent downloads the content for required software updates from a distribution point to the local client cache soon after it receives the deployment, but waits until after the Software available time setting for the deployment before the software updates are available to install. The software updates in optional deployments (deployments that do not have an installation deadline) are not downloaded until a user manually starts the installation.

When the configured deadline passes, the Software Updates Client Agent performs a scan to verify that the software updates are still required. Then it checks the local cache on the client computer to verify that the software update source files are still available. Finally, the client installs the software updates. If the content was deleted from the client cache to make room for another deployment, the client re-downloads the software updates from the distribution point to the client cache. Software updates are always downloaded to the client cache regardless of the configured maximum client cache size. When the installation is complete, the client agent verifies that the software updates are no longer required, and then sends a state message to the management point to indicate that the software updates are now installed on the client.

Required System Restart

By default, when software updates from a required deployment are installed on a client computer and a system restart is required for the installation to finish, the system restart is started. For software updates that were installed before the deadline, the automatic system restart is postponed until the deadline, unless the computer is restarted before that for some other reason. The system restart can be suppressed for servers and workstations. These settings are configured in the User Experience page of the Deploy Software Updates Wizard or Create Automatic Updates Rule Wizard.

Deployment Reevaluation Cycle

By default, client computers start a deployment reevaluation cycle every 7 days. During this evaluation cycle, the client computer scans for software updates that were previously deployed and installed. If any software updates 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. You can configure the reevaluation schedule on the Software Updates page in client settings for the site.

Support for Windows Embedded Devices That Use Write Filters

For System Center 2012 Configuration Manager SP1 and later:

When you deploy software updates to Windows Embedded devices that are write filter-enabled, you can specify whether to disable the write filter on the device during the deployment and then restart the device after the deployment. If the write filter is not disabled, the software is deployed to a temporary overlay and the software will no longer be installed when the device restarts unless another deployment forces changes to be persisted.

Note

When you deploy a software update to a Windows Embedded device, make sure that the device is a member of a collection that has a configured maintenance window. This lets you manage when the write filter is disabled and enabled, and when the device restarts.

The user experience setting that controls the write filter behavior is a check box named Commit changes at deadline or during a maintenance windows (requires restarts).

For more information about how Configuration Manager manages embedded devices that use write filters, see the Deploying the Configuration Manager Client to Windows Embedded Devices section in the Introduction to Client Deployment in Configuration Manager topic.

Extend Software Updates in Configuration Manager

Use System Center Updates Publisher 2011 to manage software updates that are not available from Microsoft Update. After you publish the software updates to the update server and synchronize the software updates in Configuration Manager, you can deploy the software updates to Configuration Manager clients. For more information about Updates Publisher 2011, see Updates Publisher 2011.

Network Access Protection

Configuration Manager Network Access Protection (NAP) interacts with Configuration Manager and Windows Network Access Protection to help protect the network.

Network Access Protection with Software Updates

When NAP is enabled, Configuration Manager clients can assess whether they are compliant or not with the software updates that you select. Configuration Manager clients send this information in a statement of health (SoH).This is presented to the Configuration Manager System Health Validator that resides on the System Health Validator point site system role.

The System Health Validator point is installed on a computer that is running Windows Server 2008 with the Network Policy Server role. It validates whether the client computer is compliant or noncompliant and passes the health state of that computer to the Windows Network Policy Server.

Enforcing Compliance with Software Updates on the Network Policy Server

The Windows Network Policy Server is configured to use policies that determine the action for computers that are known to be compliant or noncompliant.

If the health state of a client cannot be determined, then this is considered an error condition. By default, all error conditions are mapped to a noncompliant state. However, they are split into five categories and each category can be configured to map to either compliant or noncompliant.

The actions that the Network Policy Server can take based on computer health states include the following:

  • Restrict computers from accessing the full network

  • Provide full access to the network but for a limited period

  • Provide full access to the network indefinitely

  • Remediate noncompliant computers to bring them into compliance with policies

Be aware that the Configuration Manager administrative user cannot control the action that will be taken because of a computer health state that it passes to the Network Policy Server. However, if the Network Policy Server is configured to enforce compliance through remediation, Configuration Manager services are then used to deliver the software updates that are required to bring noncompliant clients into compliance. When compliance is successfully remediated, clients reassess their statement of health, which then changes from noncompliant to compliant, and their health state is updated to compliant.

Configuring Software Updates for Network Access Protection

You select the software updates that clients must have to be compliant by creating Configuration Manager NAP policies. You can only select software updates that are already downloaded to the content library on the site server. Unlike software update deployments that are targeted to collections of your choice, Configuration Manager NAP policies are automatically targeted to all computers that are assigned to the site. Configuration Manager NAP policies flow down the Configuration Manager hierarchy, similar to the behavior of software deployments and packages in Configuration Manager. Sites that inherit the Configuration Manager NAP policies then automatically target the Configuration Manager NAP policies to clients assigned to the site.

Important

Because of this automatic targeting and inheritance throughout the hierarchy, you must remember that a Configuration Manager NAP policy potentially affects every client in the hierarchy.

What’s New in Configuration Manager

Note

The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

Although the general concepts for deploying software updates are the same in System Center 2012 Configuration Manager as they were in Configuration Manager 2007, new or updated functionality is available that improves the software update deployment process. This includes automatic approval and deployment for software updates, improved search with expanded criteria, improvements to software updates monitoring, and greater user control for scheduling software update installation.

The following items are new or have changed since Configuration Manager 2007:

  • Software update groups are new in Configuration Manager and replace update lists that were used in Configuration Manager 2007. Software update groups more effectively organize software updates in your environment. You can manually add software updates to a software updates group, or add software updates automatically to a new or existing software update group by using an automatic deployment rule. You can also deploy a software update group manually or automatically by using an automatic deployment rule. After you deploy a software update group, you can add new software updates to the group, and they are automatically deployed.

  • Automatic deployment rules automatically approve and deploy software updates. You specify the criteria for software updates (for example, all Windows 7 software updates released in the last week), the software updates are added to a software update group, you configure deployment and monitoring settings, and decide whether to deploy the software updates in the software update group. You can deploy the software updates in the software update group or retrieve compliance information from client computers for the software updates in the software update group without deploying them.

  • New search and expanded criteria are available when software updates are listed in the Configuration Manager console. You can add a set of criteria that makes it easy to find the software updates that you must have. You can save the search criteria to use later. For example, you can set criteria for all critical software updates for Windows 7 and for software updates that were released in the last year. After you filter for the updates that you must have, you can select the software updates and review compliance information per software update, create a software update group that contains the software updates, manually deploy the software updates, and so on.

  • In the Configuration Manager console, you can monitor the following software updates objects and processes:

    • Important software updates compliance and deployment views

    • Detailed state messages for all deployments and assets

    • Software updates error codes with additional information to help identify issues

    • Status for software updates synchronization

    • Alerts for important software updates issues

    Software update reports are also available that provide detailed state information for software updates, software update groups, and software update deployments.

  • Superseded software updates in Configuration Manager 2007 were automatically expired during the full software updates synchronization process for a site. In System Center 2012 Configuration Manager, you can decide whether to manage superseded software updates as in Configuration Manager 2007, or you can configure a specified time where the software update is not automatically expired after it is superseded. During this time, you can deploy superseded software updates.

  • Configuration Manager gives users more control over when to install software updates on their computer. Configuration Manager Software Center is an application that is installed with the Configuration Manager client. Users run this application on the Start menu to manage the software that is deployed to them. This includes software updates. In Software Center, users can schedule software update installation at a convenient time before the deadline and install optional software updates. For example, you can configure your business hours and have software updates run outside those hours to minimize productivity loss. When the deadline is reached for a software update, the installation for the software update is started.

  • The content library in System Center 2012 Configuration Manager is the location that stores all content files for software updates, applications, operating system deployment, and so on. The content library provides a single instance store for content files on the site server and distribution points, and provides an advantage over content management functionality in Configuration Manager 2007. For example, in Configuration Manager 2007, you might distribute the same content files multiple times by using different deployments and deployment packages. The result was that the same content files were stored multiple times on the site server and on distribution points and added unnecessary processing overhead and excessive hard disk space requirements.

    For more information about content management, see the Content Library section in the Introduction to Content Management in Configuration Manager topic.

  • There is no longer a Deployment Templates node in the Configuration Manager console to manage your templates. Deployment templates can be created only in the Automatic Deployment Rules Wizard or Deploy Software Updates Wizard. Deployment templates store many of the deployment properties that might not change from deployment to deployment, and they can save much time for administrative users when they deploy software updates.

    Deployment 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 zero (0) days from the deployment schedule, and enable system restarts outside maintenance windows. The template for a planned deployment can allow for display notifications on client computers and set the deadline for 14 days from the deployment schedule.

  • When an Internet-based client receives a deployment, the client first tries to download the software files from Microsoft Update instead of distribution points. When the connection to Microsoft is not successful, clients fall back to a distribution point that hosts the software update files and is configured to accept communication from clients on the Internet.

  • Although you can still deploy software updates in System Center 2012 Configuration Manager, there is no longer a visible software update deployment object. The deployment object is now nested in a software update group.

  • There is a non-configurable limit of 1000 software updates for a software update deployment. When you create an automatic deployment rule, verify that the criterion that you specify does not result in more than 1000 software updates. When you manually deploy software updates, do not select more than 1000 updates to deploy.

  • The Network Access Protection node in the Configuration Manager console and the New Policies Wizard are no longer available in System Center 2012 Configuration Manager. To create a NAP policy for software updates, you must select Enable NAP evaluation on the NAP Evaluation tab in software update properties.

What’s New in Configuration Manager SP1

Note

The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new or have changed for software updates in Configuration Manager SP1:

  • Software update points are redesigned in Configuration Manager SP1. You can install multiple software update point site systems at a site. You can configure a software update point to be in the same forest as the site server or in a different forest, and whether to accept communication from clients on the Internet, intranet, or both. This behavior provides a level of fault tolerance without requiring a network load balancing (NLB) cluster. You cannot install more than one software update point in a secondary site. For more information, see the Determine the Software Update Point Infrastructure section in the Planning for Software Updates in Configuration Manager topic.

    Note

    The active software update point concept is deprecated in Configuration Manager SP1.

  • You no longer have the option to configure a software update point as an NLB in the Configuration Manager console. Before you upgrade from Configuration Manager with no service pack to Configuration Manager SP1, you must remove the NLB for your active software update point. After the upgrade is complete, you have the option to configure NLB by using the Set-CMSoftwareUpdatePoint PowerShell cmdlet. For more information about a software update point configured to use an NLB, see Software Update Point Configured to Use an NLB section in the Planning for Software Updates in Configuration Manager topic. For more information about the Set-CMSoftwareUpdatePoint PowerShell cmdlet, see the Set-CMSoftwareUpdatePoint topic in the System Center 2012 Configuration Manager SP1 Cmdlet Reference.

  • At the top-level Configuration Manager site, you can now specify an existing WSUS server as the upstream synchronization source location. During synchronization, the site connects to this location to synchronize software updates. For example, if you have an existing WSUS server that is not part of the Configuration Manager hierarchy, you can specify the existing WSUS server to synchronize software updates.

  • You can select from two built-in software update deployment templates from the Automatic Deployment Rule Wizard. The Definition Updates template provides common settings to use when you deploy definition software updates. The Patch Tuesday template provides common settings to use when you deploy software updates on a monthly cycle.

  • In the software update point properties, you can provide credentials for the site server to use to connect to the WSUS server. You can specify this account to connect to a software update point in a different forest, for example.

  • You can run an automatic deployment rule up to 3 times per day to align with the Endpoint Protection definition updates publishing frequency.

  • You can select multiple software updates to install as a group from Software Center.

  • You can control the behavior of the write filter on Windows Embedded devices when you deploy software updates by using the new user experience setting of Commit changes at deadline or during a maintenance windows (requires restarts). For more information about how Configuration Manager manages embedded devices that use write filters, see the Deploying the Configuration Manager Client to Windows Embedded Devices section in the Introduction to Client Deployment in Configuration Manager topic.

  • The new Computer Agent client setting, Disable deadline randomization lets you disable the installation randomization delay for required software updates and required application deployments. For more information, see the Computer Agent section in the About Client Settings in Configuration Manager topic. 

What’s New in System Center 2012 R2 Configuration Manager

Note

The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new or have changed for software updates in System Center 2012 R2 Configuration Manager:

  • New maintenance window dedicated for software updates installation. This lets you configure a general maintenance window and a different maintenance window for software updates. When a general maintenance window and software updates maintenance window are both configured, clients install software updates only during the software updates maintenance window. For more information about maintenance windows, see How to Use Maintenance Windows in Configuration Manager.

  • You can now change the deployment package for an existing automatic deployment rule. New software updates are added to the specified deployment package every time an automatic deployment rule is run. Deployment packages can become very large over time and might impact replication scenarios, particularly when a new distribution point is added to your hierarchy or when a distribution point is added to a distribution point group. You can now change the deployment package periodically to keep the size of the deployment package from getting too large. For more information about automatic deployment rules, see the Automatic Deployment of Software Updates section in this topic.

  • You can now preview software updates that meet the property filters and search criteria that you define in an automatic deployment rule. Software updates preview lets you review the software updates before you create the deployment. The Preview button is located on the Software Updates page in the Automatic Deployment Wizard and on the Software Updates tab in the properties for the automatic deployment rule.