CHAPTER 15
Managing Software Updates

Applying software updates and ensuring patch compliance are important maintenance activities for information technology (IT) organizations. Microsoft first added software updates as an add-on to System Center Configuration Manager (ConfigMgr) in 2003, when it was known as Systems Management Server (SMS); the feature was called the Inventory Tool for Microsoft Updates (ITMU). Software updates was fully embedded beginning with ConfigMgr 2007, and improvements have been made in each new product release. Today software updates is rich in both design and feature sets, providing the ConfigMgr administrator with complete flexibility in deploying updates for supported Microsoft operating systems (OSs), Microsoft server products, selected Microsoft desktop applications such as Microsoft Office, and even cloud-based systems such as Microsoft Office 365. You can also scan and deploy patches for supported third-party products.

UseWUServer: This new attribute differentiates a Windows 10 computer that connects to Windows Update for Business for software update management from computers connected to Windows Server Update Services (WSUS) for software update management. You can use this attribute, located in the Windows Update section of the Resource Explorer, in a collection to remove these systems from a software update deployment.

WSUS Clean Up Task: This new option on the Supersedence Rules tab of the software update point (SUP) properties allows you to run a task that sets the status of expired software updates to Declined on the WSUS server. The Windows Update Agent (WUA) then no longer scans for that update, which causes client scans to run faster.

Manage Office 365 Client Updates: This option provides a new product in the Products tab of the SUP properties, named Office 365. Checking the box tells WSUS to sync Office 365 updates from Microsoft Updates; after syncing, updates appear in the Software Updates folder of the console.

Client Setting to Manage the Office 365 Client Agent: This is a dropdown menu item in the Software Updates section of the client settings properties. Once this option is enabled and Office 365 client updates are deployed to a client, the ConfigMgr client agent can communicate with the Office 365 client agent to download Office 365 updates from a distribution point (DP) and install them. In ConfigMgr Current Branch version 1706, the client receives a popup and in-app notifications as well as a countdown dialog prior to installing the update. More information can be found at https://docs.microsoft.com/sccm/sum/deploy-use/manage-office-365-proplus-updates#restart-behavior-and-client-notifications-for-office-365-updates.

Manually Switch Clients to a New Software Update Point: Use this new option in the client notification area of the console to tell clients to use a new SUP when their active SUP is not working. Once the client gets this policy through the fast policy channel, it looks for another SUP at the next software update scan.

Restart Options for Windows 10 Clients After Software Update Installation: This lets Windows 10 clients see the Update and Restart and Update and Shutdown options in the Power menu when there is a pending restart for a ConfigMgr software update.

Manage Windows as a Service: This new feature, commonly called Windows 10 servicing, allows ConfigMgr to view the status of Windows as a service, create servicing plans to form deployment rings, and view alerts when Windows 10 clients are near the end of support for their build of the Semi-Annual Channel.

Enforcement Grace Period for Required Application and Software Update Deployments: This new option allows you to set a period of time between 1 and 120 hours for postponing installation of required deployments, including software updates, after the deadline has passed. It allows end users that have been away for an extended length of time to not have to wait for required deployments to install before using the system.

Improvements for How Software Update Points Work with Boundary Groups: With ConfigMgr Current Branch version 1706, the time it takes to fall back to a neighbor boundary group is now configurable. Changes have also been made so that the client, independent of the configurable time, will try for 120 minutes to connect to the last SUP it used. If unsuccessful, the client randomly picks another SUP from the pool of available SUPs and tries to connect to that SUP. After two hours of failing to connect, the client will use a shorter cycle for connecting to a SUP.

Enable/Disable Support of the Installation of Windows 10 Express Files with Software Updates: A new setting, located in the Software Updates section of client settings, allows you to enable or disable using Windows 10 Express files with software updates. To use the Express files, enable this setting and change the SUP properties to allow it to synchronize the metadata for the Windows 10 Express files.

The Ability to Manage Microsoft Surface Driver Updates: A new pre-release feature with Current Branch version 1706, this capability, if enabled, creates a new classification in the SUP properties that allows the SUP to include metadata for Microsoft Surface drivers and firmware updates. Once the SUP has synchronized this metadata, the ConfigMgr administrator can deploy the drivers and updates through the software updates process. Note that the SUPs must be running Windows Server 2016 for this to work.

Configuration of Windows Update for Business Deferral Policies: This new feature in ConfigMgr Current Branch 1706 allows an administrator to create deferral policies for Windows 10 Feature Updates or Quality Updates for Windows 10 devices managed directly by Windows Update for Business. To configure these policies, navigate in the ConfigMgr console to Software Library -> Overview -> Windows 10 Servicing -> Windows Update for Business Policies. On the ribbon bar, click Create Windows Update for Business Policy to start the wizard. More information about creating the policies can be found at https://docs.microsoft.com/sccm/sum/deploy-use/integrate-windows-update-for-business-windows-10#configure-windows-update-for-business-deferral-policies.

As you move forward with Windows 10 and Office 365, new software updates features can help improve your overall ConfigMgr experience. This chapter explains how software updates work and how to configure and use this feature to help your overall patching needs.

Scope: Determine the systems and applications to patch. Although not updating all systems or applications for a particular flaw may pose a security risk, there may be specific reasons not to patch certain systems or applications.

Patch Testing: The authors highly recommend testing patches before deploying them to production systems. If you do not have a full test environment, do not let that deter you from testing. At a minimum, identify a group of systems as your pilot testing group. Deploy patches to these test systems before a production rollout and leave sufficient time to troubleshoot and resolve any problems from the patches.

Coordination and Scheduling: Windows patches typically require a reboot after installation, meaning you must schedule a window of time to apply a patch and reboot the system. As you may be patching workstations, servers, or dedicated workstations used in manufacturing or point-of-sale systems that have only a small window to reboot, you must coordinate with other IT staff, server administrators, application administrators, users, and management to establish maintenance windows with acceptable times to reboot these systems. While useful for all types of system maintenance, maintenance windows are a definite requirement for patch management. Many organizations include patch management in their established change control process or create a process to deal with the many ramifications of updates and patches.

Notification: If starting a new patching process or changing an old process, always issue fair warning to anyone potentially affected by a patch update or system reboot. Make this notification part of any process documentation. Things will go smoothly once users are used to the new or changed patching process; meanwhile, having proper notifications on a regular basis helps users get accustomed to the new process. Even when coordinating maintenance windows, sending additional notifications to other administrators and users to let them know what will transpire can prevent finger-pointing and many sleepless nights.

Political Policies and Support: IT professionals know the risks of not patching systems and applications. Implementing a successful patching strategy requires political support to establish a policy that dictates and enforces applying patches. Without such a top-down policy, you will face opposition to patching, not only from users but also within IT. A policy enforced by your CIO (or equivalent) eliminates any quibbling over patching.

Compliance regulations in the United States such as the Health Insurance Portability and Accountability Act (HIPAA), Sarbanes-Oxley Act of 2002 (SOX), and Gramm-Leach-Bliley Act (GLBA) are also drivers for patching and should eliminate any questions about its necessity. Although none of these compliance laws specifically requires patching, this is one of the first things auditors will check.

Role-Based Administration: Consider who needs permission to create patch deployments, download patches, and create deployment packages. Assign permissions based on the role, so only those individuals who need the permissions get them. Some organizations assign different roles to different people to have checks and balances when deploying software updates.

Based on the information in this section, as well as other factors unique to your own organization or environment, consider developing a patch strategy and policy document that includes items such as a time line, a rollback process, and testing procedures. Update it monthly to indicate what patches are in scope and distribute it as part of your notification process.

Number of Clients to Support: In the planning stage, this should be close to the number of clients you need to support. A single SUP can support 25,000 clients when colocated with another system role and WSUS is installed on the same machine, or it can support up to 150,000 clients on a dedicated machine that meets WSUS requirements to support that number of clients.

Number of Software Update Objects: There is a soft limit of 1,000 software updates in a single deployment. Any automatic deployment rules (ADRs) fail if the query returns more than 1,000 updates. While 1,000 may seem high, if you select several products along with different update classifications, you can get to 1,000 very quickly. The 1,000 rule also applies to any manual software update deployments and software updates in configuration baselines.

Intranet-Based Clients: These clients receive a list of SUPs configured to allow only connections from the intranet or connections from both intranet and Internet clients.

Internet-Based Clients: These clients receive a list of SUPs configured to allow only connections from the Internet or from both intranet and Internet clients.

1. When the first scan fails, the client retries in 30 minutes, using the same SUP.

2. If the failure reoccurs, the client tries again four times, with a 30-minute time-out after each retry.

3. After the fourth failure, the client waits an additional two minutes and then tries the next SUP in the SUP list.

4. When the client is successful with the next SUP in the list, that becomes the SUP the client will always use. If connecting to the next SUP in the list fails, the client starts over with step 1.

If there are problems with the active SUP or you need to take that SUP down for maintenance, you can manually fail over the clients to a new SUP, as long as the clients already know that there are multiple SUPs in the site. Navigate in the ConfigMgr console to Assets and Compliance -> Overview -> Device collections and select the collection for which you want to switch SUPs. On the ribbon bar, click Client Notification and select Switch to next Software Update Point. This creates a client notification item sent to the client via the fast channel, telling the client to pick a new SUP from its SUP list.

Switching to a new SUP has a cost, as the SUP’s failover design is different from that of DPs or management points (MPs), which affects client and network performance. The client will see an increased size in the catalog when switching, resulting in some performance issues with the network, the client, and the new SUP. This is why when a client successfully scans against a SUP, it preserves that affinity. Take care when failing over clients to a new SUP to avoid causing undue network or client issues.

Site System Install Account: This account is used during installation to copy over files needed for the install, access the WSUS server in the untrusted forest, and perform the installation of the SUP.

WSUS Server Connection Account: This account is used after installation to make ongoing connections to WSUS. These connections are to configure WSUS once changes are made in ConfigMgr, perform a time-out check every 60 minutes to verify that WSUS is still alive, and tell WSUS when to sync with Microsoft Update.

ConfigMgr integrates WSUS’s update catalog download and distribution capabilities, enabling Microsoft to maintain and support a single update catalog that contains all Microsoft-supported updates used for Windows Update, WSUS, and ConfigMgr, while also allowing each update service to deliver updates in its own way. For ConfigMgr, this means delivering updates to clients through its robust DP capabilities. Once WSUS is integrated, ConfigMgr takes control of WSUS and configures it as needed.

WSUS uses a SQL database to store information. This can be a Windows Internal Database (WID) or a SQL Server database. If you install WSUS using the defaults, the WID is installed. In the case of ConfigMgr, SQL is usually installed on the site server. If installing WSUS on that same site server, you can use SQL Server as your database. If needed, you can create a separate SQL Server instance for ConfigMgr to allow for granular resource control and troubleshooting resource issues; however, this is not required, and WSUS has little overhead on the database server, regardless of the size of the ConfigMgr installation.

WSUS can support up to 25,000 clients if the WSUS server is colocated on the ConfigMgr server. If you need to support a larger number of clients, the authors recommend installing WSUS on a dedicated server. If needed, 150,000 clients can be supported when the SUP is installed on a remote system that meets WSUS requirements to support this number of clients. Rather than using a large single dedicated system, the authors recommend installing multiple WSUS/SUP servers to offset the number of clients reporting to each server.

Installing WSUS is a wizard-driven process and fairly straightforward. To start, use Server Manager and its Add roles and features section to select the WSUS items that you want to install. Your only real choice here is to use the WID or SQL Server. Your next choice is a bit confusing because the wizard makes it sound like you can uncheck the box to store the updates:

ConfigMgr: For ConfigMgr, select to Store updates locally on the system, as shown in Figure 15.1. This setting allows WSUS to download and store license terms for specific software updates in the update content folder that you choose; ConfigMgr handles the download and deployment of updates. During the update synchronization process, ConfigMgr looks for applicable license terms in the content folder. If it cannot find license terms, it does not synchronize the update. In addition, clients must have access to the applicable license terms to scan for update compliance.

FIGURE 15.1 WSUS content location source.

SQL Server: If you selected to use SQL Server and the database is on a remote server, you must enter the machine and instance name (<machine nameinstance name>) and choose Check connection to verify connectivity. If SQL is installed on the same machine and using a default instance, just enter the machine name and select Check connection to verify connectivity.

When installation completes, the wizard informs you that configuration is required. Launch the Post-Installation task to finish installation. If something fails or goes wrong, a log file is created in your temp folder. The task details and notifications pane displays the location and name of the log file.

When the post-installation tasks are finished and successful, WSUS is completely installed. The first time you open the WSUS console after installation, it shows a configuration wizard and asks you to configure the settings. It is important to cancel out of the wizard. ConfigMgr configures WSUS based on the settings selected when the SUP is installed.

get-WindowsFeature update*

Install-WindowsFeature -Name UpdateServices -IncludeManagementTools

Install-WindowsFeature -Name UpdateServices-Services,UpdateServices-DB -IncludeManagementTools

.wsusutil.exe postinstall CONTENT_DIR=C:WUS

.wsusutil.exe postinstall SQL_INSTANCE_NAME=ARMADA CONTENT_DIR=C:WUS

If WSUS is installed on Windows Server 2012 R2, you must apply hotfixes for WSUS to support Windows 10 and Windows Server 2016. Apply these updates before your first sync with Microsoft Updates:

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 Update (April 2014): If using Windows Server 2012 R2, this rollup hotfix must be applied first. More information about this hotfix can be found at https://support.microsoft.com/kb/2919355.

Update to Enable WSUS Support for Windows 10 Feature Upgrades: This hotfix is applied after KB2919355 and allows the Windows 2012 R2 server to sync and distribute feature updates for Windows 10. For more information, see https://support.microsoft.com/kb/3095113.

Update Enables ESD Decryption Provision in WSUS in Windows Server 2012 and Windows Server 2012 R2: This update is required to deploy features and upgrades to Windows 10 that released after May 1, 2016. More information is available at https://support.microsoft.com/kb/3159706.

The configuration process is not difficult, but it has many steps, and it is easy to get confused. With this in mind, the authors have broken down the process in two parts:

Configuring server-side components

Configuring client-side components

The “Configuring Server-Side Components” section describes a wizard with several pages and walks you through the process. The “Configuring Client-Side Components” section is not as clean as there is no wizard, just steps that you need to follow closely so nothing is left out.

SUPs should be installed in a top-down fashion, meaning that you start at the CAS, if one exists, and then move to primary sites and then secondary sites, if needed. When installing a SUP, you configure it as part of the installation process; you can edit the configuration after the SUP is installed. To begin installation, navigate in the ConfigMgr console to Administration -> Overview -> Site Configuration -> Servers and Site System Roles. Locate the server you want to use as your SUP and select Add Site System Roles from the ribbon bar or from the right-click context menu to launch the Add Site System Roles Wizard. If the server is not listed, add it to ConfigMgr by choosing Create Site System Server from the ribbon bar.

The General page of the Add Site System Roles Wizard includes the following selections, displayed in Figure 15.2:

Specify an FQDN for This Site System for Use on the Internet: Check this box if this SUP will be used in a DMZ. This allows you to enter the FQDN to be published to the Internet DNS servers. The client obtains this name when it downloads policy and will try to connect to it when it is an Internet-based client (IBC).

Require the Site Server to Initiate Connections to This System: By default, site systems initiate connections to the site server to transfer data, which can be a security risk when the connection is initiated from an untrusted network to the trusted network. Check this box when site systems accept connections from the Internet or reside in an untrusted forest so all connections are initiated from the trusted network after installing the site system and any site system roles.

Site System Installation Account: The default option here is to use the site server’s local system account to connect to the remote system to begin installation. If the destination server is in an untrusted forest or if the local system account does not have permissions to access the server, add an account for ConfigMgr to use. Ensure that this account has full administrative permissions on the remote machine.

FIGURE 15.2 General Page of the Add Site System Roles Wizard.

Many organizations use a proxy server to control Internet access. The Proxy page of the wizard is where you enter the server name and port number that the proxy server uses. If your organization goes the extra mile and secures access to the proxy server with an account, that information must be entered at bottom of this page also, with the account name in the form domainusername, as well as the password. The authors recommend using a separate service account and following the rules of least privilege.

On the System Role Selection page of the wizard, select Software Update Point to add several subpages to the wizard. Figure 15.3 shows those subpages, and the next sections describe these subpages in detail.

FIGURE 15.3 Subpages of the Add Site System Roles Wizard.

WSUS Is Configured to Use Ports 80 and 443 for Client Communication (Default Settings for WSUS 3.0 SP2): This option is for backward compatibility to WSUS for older versions. It was in common use with Windows Server 2008 R2 and WSUS 3.0 Service Pack (SP) 2. Choose this option if you are using that version of the OS and you accepted the default values when installing WSUS.

WSUS Is Configured to Use Ports 8530 and 8531 for Client Communications (Default Settings for WSUS on Windows Server 2012): Microsoft integrated WSUS with the server OS starting with Windows Server 2012, allowing you to install it through Server Manager. As a security precaution, Microsoft changed WSUS to use the default ports 8530 and 8531, which are now the default entries when installing WSUS. The authors recommend that you use this option.

Require SSL Communication to the WSUS Server: If you configured your WSUS server to use SSL for communication, you must check this box for ConfigMgr to install and configure the SUP to use SSL. In the default installation, the SUP does not use SSL. When you enable SSL for WSUS that runs on a SUP at a parent site, any WSUS and SUP running on a child site must also be configured to use SSL.

Use a Proxy Server When Synchronizing Software Updates: If this box is checked, the SUP configures the WSUS server to use proxy settings when connecting to Microsoft Updates to synchronize the metadata for software updates.

Use a Proxy Server When Downloading Content by Using Automatic Deployment Rules: If this box is checked, proxy settings are used when an ADR runs and needs to download content from Microsoft Updates.

Use Credentials to Connect to the WSUS Server: By default, the SUP connects to the WSUS server using the site server’s local system account; check this box if you need to use another set of credentials to make this connection. If you use an account, the authors recommend that it be a separate account and that you follow the rules of least privilege.

Synchronize from Microsoft Update: This is the option that most hierarchies use. It tells the SUP that it needs WSUS to connect to the Microsoft Update website and download the metadata. Internet access at the CAS or the standalone primary site is required for this choice.

Synchronize from an Upstream Data Source Location: If your top-level site has no Internet access, this option may be the next best choice. The option allows you to use a top-level WSUS server that is not connected to your ConfigMgr hierarchy as a source for your metadata. You need to use a URL here; for example, https://Armada.odyssey.com:8531.

Do Not Synchronize from Microsoft Update or Upstream Data Source: Use this option when you do not have Internet access in your environment; this might be a highly secure area that doesn’t allow Internet access. In this case, you would use the import and export functions of WSUS to get the metadata from an outside WSUS server to inside the ConfigMgr server.

At the bottom of the page, determine what WSUS reporting events to view. These are status messages the WUA creates on the client system to tell WSUS the results of the scan it has run. ConfigMgr does not use these messages; they are only visible inside the WSUS administration console. Your choices follow:

Do not create WSUS reporting events

Create only WSUS status reporting events

Create all WSUS reporting events

The authors recommend keeping the default setting: Do not create WSUS reporting events, as this reduces overhead at the client.

Simple Schedule: The simple schedule allows you to set how often the synchronization runs, in days and hours. The recurrence pattern is set to the number you choose, such as every 7 days.

Custom Schedule: A custom schedule allows you to choose exactly—down to the day, hour, and minute—when the synchronization runs, as well as the recurrence pattern.

Alert When Synchronization Fails on Any Site in the Hierarchy: This option allows an alert to be created when the SUP synchronization fails. When it is enabled, this option is for all SUPs in the hierarchy. The alert can be seen in the console under Monitoring -> Alerts.

Immediately Expire a Superseded Software Update: If selected, this option marks the old update as expired immediately in WSUS and all ConfigMgr deployments. Your client can no longer request or install the old update.

Do Not Expire a Superseded Software Update Until the Software Update Is Superseded for a Specified Period: This allows you to select a number in months to wait before the old update is marked expired. This is a good option for customers that need extra time to verify that a new update does not break any of their applications. Say an organization has created a custom web page; if a new Internet Explorer patch is released, testing is needed to verify that it works correctly with the custom page before it can be included in deployments for clients to install.

Run WSUS Cleanup Wizard: If this check box is checked, at the end of the next sync with WSUS, the ConfigMgr WSUS Sync Manager will run the WSUS Cleanup Wizard and reset the value of the next run time to 30 days. The wizard then runs every 30 days. The Sync Manager checks the last runtime value at the end of every synchronization; when the value is greater than 30 days, it runs the Cleanup Wizard.

Critical Updates: This specifies a broadly released update for a specific problem that addresses a critical, non-security-related bug.

Definition Updates: This is used for updates to antivirus programs and definition update files.

Feature Packs: This is for new product features distributed outside a product release and for features that are typically included in the next full product release.

Security Updates: This specifies a broadly released update for a product-specific, security-related issue.

Service Packs: This is a cumulative set of hotfixes applied to an application. These hotfixes can include security updates, critical updates, software updates, and so on.

Tools: This is for a utility or a feature that helps complete one or more tasks.

Update Rollups: This is a cumulative set of hotfixes 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: This is for an update to an application or a file that is currently installed.

Upgrades: This new classification allows you to upgrade the edition of Windows 10 that users have.

When you sync with Microsoft Updates, the classifications are checked to see if they have any new updates. It is a best practice to clear all classifications before synchronizing software updates the first time; once the sync finishes, select the classifications from the properties of the SUP and then re-initiate the sync.

You see this Classifications page of the wizard only when you configure the first SUP at the site, and it is not available if you install additional SUPs. You can change any setting by choosing the properties of the first SUP in the site.

Product Families: This is an option for when you need the updates for everything in the entire family, such as Office. Instead of drilling down and choosing Office 2013, you would check the top box, and all Office products would be checked.

Products: This is a specific edition of an OS or product. An example of this would be choosing only the Windows 10 product out of the Windows product family.

Figure 15.4 shows the product families and products, with the Office product family checked and only the Windows 10 product checked in the Windows product family.

FIGURE 15.4 SUP product families and products.

If a software update selected for synchronization is applicable to multiple products, you will see those multiple products listed in the ConfigMgr console after synchronization completes. For example, if you selected Windows 7, the console would show updates for both Windows 7 and Windows Embedded Standard 7.

Product settings can only be configured at the top-level site. Once the changes are made, the software updates metadata is replicated to all child-level sites. Realize that the more products you sync, the longer the sync with Microsoft Updates takes; there is also a performance hit on the client side, as it takes longer to scan the catalog when more products are in it. The authors recommend selecting only products that are active in your organization.

Software Update File: This item allows you to select the different languages for which you want the software update files to be downloaded. For each language you select, one or more software update files are downloaded. For example, if you select English, French, and Spanish, then for every software update you want to deploy, ConfigMgr will download the corresponding configured language versions of the software update file. Take care when selecting the languages, as your software update deployment package could be very large. The authors recommend that you select only the languages most often used in your organization. During the download process, you have the option of modifying the number of languages you want to download; this is an option you need to configure for each download.

Summary Details: This option allows you to download the software updates metadata in the selected languages you choose. The metadata consists of items such as the name, description, products that the update supports, update classification, article ID, applicability rules, and so on. Because this is metadata, and metadata is replicated to other sites, this option is available only at the top-level site. The authors recommend selecting only the languages most common in your organization, as the more languages that you select, the longer synchronization with Microsoft Updates takes.

WCM.log: This log file is for the SMS WSUS Configuration Manager, which is responsible for connecting to WSUS and configuring it according to the settings selected in the SUP properties. In this log, you are looking for items like the following:

Click here to view code image

Successfully connected to server: Armada.Odyssey.com, port: 8530
Configuration successful. Will wait for 1 minute for any subscription or proxy changes
Setting new configuration state to 2 (WSUS_CONFIG_SUCCESS)

WSUSCtrl.log: This log file is for the SMS WSUS Control Manager, which is responsible for connecting to the WSUS server and verifying that connectivity is working correctly and that WSUS is running with the supported version. In this log file, you are looking for things like the following:

Click here to view code image

Checking for supported version of WSUS (min WSUS 3.0 SP2 + KB2720211 + KB2734608)
Supported WSUS version found
Successfully connected to local WSUS server
There are no unhealthy WSUS Server components on WSUS Server  Armada.Odyssey.com

Wsyncmgr.log: This log file is for the SMS WSUS Sync Manager. This component is responsible for communicating with WSUS and telling it to sync with Microsoft Updates. When that finishes, it syncs with the WSUS database. In this log, you are looking for items like the following:

Click here to view code image

Synchronizing WSUS server armada.odyssey.com ...
sync: Starting WSUS synchronization
sync: WSUS synchronizing categories
sync: WSUS synchronizing updates
Done synchronizing WSUS Server armada.odyssey.com
Synchronizing SMS database with WSUS server Armada.Odyssey.com
Sync succeeded

Sync failed: WSUS update source not found on site CAS. Please refer to
WCM.log for configuration error details. Source: getSiteUpdateSource

FIGURE 15.5 Client Default Settings.

Several settings in the Default Settings dialog affect how software updates work:

Computer Agent -> Deployment Deadline Reminders: The first three options on this page deal with how the user is reminded that a deadline for deployments is about to occur. The first option is the number of hours to remind the user when the deployment is over 24 hours away from beginning. The second option is how often to remind the user when the deadline is less than 24 hours away. The third option is how often to notify the user when the deadline deployment is less than 1 hour away. The defaults for these three options are 48, 4, and 15, respectively.

Computer Agent -> Grace Period for Enforcement After Deployment Deadline (Hours): This option allows you to set a period of time, in hours, to postpone the installation of required deployments, including software updates deployments, after the deadline passes. This allows end users who have been away for an extended length of time to not have to wait for required deployments to install before getting to use the system. The grace period value can be between 1 and 120 hours.

Computer Restart: There are two options on this page; when a restart is required, the first option is how many minutes before the restart to provide a temporary notification to the user. The second option is the number of minutes before the restart to show a dialog box that cannot be closed by the user; this dialog displays the countdown interval before the user is logged off and the computer restarts.

Software Updates: This section of the client settings page includes some key areas that directly affect the software updates component of the ConfigMgr client agent:

Enable Software Updates on Clients: This option is turned on by default and must remain on for the clients to scan and apply software updates. If it is turned off, ConfigMgr removes existing deployment policies from the clients.

Software Update Scan Schedule: This option allows you to set the schedule you want to use when the client will again scan the update catalog. The default value is every 7 days, using the simple schedule. The actual start time for the scan on client systems is based on the start time in the schedule plus a random amount of time up to two hours. This prevents all clients from initiating the scan at once.

Schedule Deployment Re-evaluation: This option sets the schedule for when clients re-evaluate the installation status of any previously deployed and installed updates. If any updates are determined to be missing, they are reinstalled from the local ConfigMgr client cache or downloaded again from the DP, if necessary. This occurs once the client is in a maintenance window and free to perform the install. A simple schedule of every 7 days is set by default. The schedule should be set based on the company policy for software update compliance. If the organization is aggressive on compliance, the authors recommend using every 3 days as the schedule; consideration should be taken with a more aggressive schedule as it causes additional network and client CPU activity.

When Any Software Update Deployment Deadline Is Reached, Install All Other Software Update Deployments with Deadline Coming Within a Specified Period of Time: This option groups multiple update deployments together into a single deployment if scheduled to occur within the period of time specified by the next setting, minimizing the impact on the end user and decreasing the number of reboots necessary with multiple, separate update deployments.

Period of Time for Which All Pending Deployments with Deadline in This Time Will Also Be Installed: This setting is available only if the previous option is enabled by setting it to Yes. This is the period of time to consider update deployments for grouping according to the description of the previous setting.

Enable Management of the Office 365 Client Agent: If this option is enabled when Office 365 updates are deployed, the ConfigMgr client agent communicates with the Office 365 client agent to download the Office 365 updates from a DP and install them.

State Messaging: Client agent update scan and installation results are returned to the ConfigMgr site using state messages; to minimize network traffic and impact on the site server, state messages are not sent individually but bundled up on the client and sent only on the interval specified here. There is no way to trigger sending of state messages from the client to the server except to restart the client agent.

Specify intranet Microsoft update service location

Configure Automatic Updates

Figure 15.6 shows the settings possible for Specify intranet Microsoft update service location. This group policy object (GPO) allows you to set the internal location of the WSUS server clients will use to scan against and from where they will download updates. If this GPO is being applied to an organizational unit (OU) that contains ConfigMgr clients, the GPO must be set to either Not Configured or Disabled; both settings turn off this GPO.

FIGURE 15.6 GPO setting for Specify intranet Microsoft update service location.

ConfigMgr creates a local group policy setting for the client to point to the ConfigMgr SUP with the WSUS server installed. A domain-based GPO overrides the local group policy setting and causes the ConfigMgr client to show this message in its WUAHandler.log file: Group policy settings were overwritten by a higher authority (Domain Controller). The domain GPO causes software updates to fail on the client. If this GPO was enabled, once it is disabled, make sure the clients refresh their domain policy to remove the GPO before retrying software updates.

Figure 15.7 shows the GPO settings for the Windows Update Agent.

FIGURE 15.7 GPO for Windows Update Agent settings.

Settings in this GPO affect how the WUA works on the client and effectively control how it automatically handles updates, downloads, and installation of those updates. The keyword in the previous sentence is automatically; with ConfigMgr, the WUA should not do anything automatically, as the WSUS server itself does not have any updates for the clients; all updates are delivered via the content distribution mechanism in ConfigMgr and not WSUS. When a ConfigMgr client wants to do anything related to software updates, it directly controls the WUA to achieve the desired result; this includes update scans, reevaluations, and installation.

The authors recommend setting this GPO to Disabled. In the past, doing this was a problem because it caused an issue with updates to the WUA itself. Those updates were picked up by WSUS; however, since they were part of the Infrastructure Updates class, they were automatically set to approved in WSUS, causing them to be pushed out to all the clients as they connected to the WSUS server. To work around this issue, Microsoft now includes WUA updates in the WSUS catalog, so when ConfigMgr syncs with WSUS, the updates appear in ConfigMgr to be deployed to your clients.

Note that setting this GPO to Disabled doesn’t actually disable the WUA service. It does disable all of the automatic functionality of the WUA, including scanning. This means the WUA is not automatically installing any updates or causing any issues with ConfigMgr; the service is there and running when needed but not doing anything until ConfigMgr tells it to through the WUAHandler component.

All Software Updates

Software Update Groups

Deployment Packages

Automatic Deployment Rules

Windows 10 Servicing

FIGURE 15.8 All Software Updates node.

You may have noticed in Figure 15.8 that some of the updates show different icons. The icons indicate the status of the update. There can be several different statuses for the updates. Table 15.1 lists the different colors of icons and their meanings.

TABLE 15.1 Update Status Icons

Table 15.1 is also valid for software update groups and deployment packages. Figure 15.8 shows an extra column added. It is very useful in troubleshooting to add columns to the display. In this case, Unique Update ID is added. In the client logs, updates are referenced by this ID. Add columns by right-clicking a column name, which causes a long list of additional column names to appear; just pick the one you want.

Selecting an update in the list brings up either Summary or Deployment information in the Details pane at the bottom. Double-clicking an update, right-clicking, and choosing Properties or selecting an update and then choosing Properties from the ribbon bar brings up detailed information about that update, organized on six tabs plus the Security tab that is present on every dialog box:

Software Update Details: This tab displays information about the update, such as its bulletin ID, article ID, revision date, maximum severity rating, description, and application languages, as well as the affected products.

Maximum Run Time: This is a value of time in minutes that the update installation is allowed to run. This number is different for each update; Windows 10 updates are typically 30 minutes, and other OS versions typically run 10 minutes. When using maintenance windows, this value is used to calculate whether there is enough time to install the update within the time remaining in the window.

Custom Severity: You can set the custom severity of an update to one of five values, whose meanings you and your organization can define. ConfigMgr does not use these values in any way, but you can use them for filtering purposes:

None

Low

Moderate

Important

Critical

Content Information: This read-only tab contains information about the actual update file(s), whether it is downloaded, the size of the update (in megabytes), and the URL from which to download. Normally, ConfigMgr handles the download of the files listed in this tab; however, you can reference this tab if you find you need to review the location ConfigMgr is using or wish to download the file yourself. If you select a line in this list box and press Ctrl+C, the entire line is copied to the Windows Clipboard, and you can then paste it into Notepad to extract the URL.

Custom Bundle Information: Bundles are groups of updates that are installed together, normally because they are tightly related or have interdependencies. If an update is part of a bundle, that bundle information is listed here.

Supersedence Information: This tab lists any updates that this update supersedes or any updates superseding it. When there are multiple versions of an update, this tab is a good source of information for the latest version of the update.

You can select multiple updates to modify either their maximum runtime or custom severity at one time.

Sort the list of updates by clicking on any displayed header. You can also filter the list of updates to display only those you are interested in working with or examining. The first filtering technique is a simple text search: To evaluate and filter content from any displayed column that contains text, type in the word or phrase you want to search for in the Search box above the update list’s header and click Search. Note that columns such as Required that contain counts, Downloaded that contain Boolean values, and Date released that contain dates are not considered to contain text and thus are not evaluated by the simple text search functionality. To clear the filter, click the X next to Search.

You can create advanced filters by combining multiple criteria and columns using Add Criteria to the right of Search. This drops down a list where you can select the categories on which you want to filter the list; select the categories and click Add to add an advanced filter section underneath the Search input box, where you can define the values for which to search. You can add criteria to the filter by selecting Add Criteria from the Search section of the ribbon bar.

Even with advanced filters, you may find that there are so many software updates that you can get lost looking for something. Consider using subfolders of the All Software Updates node to organize your updates. Create and manage these subfolders by using the Folder tab on the ribbon bar or by right-clicking the All Software Updates node. You can apply filters to any subfolder. You must manually move updates into the subfolders you create. One popular method of using the subfolders is to create one for each year and under the yearly subfolder create each month, then add the month’s updates into those subfolders. There are several methods for organizing software updates, but filters remain one of the best choices; they are dynamic, persistent, easily modified, and self-defining. Both filters and subfolders are part of the global data replicated to all sites in a hierarchy, making them available at every site.

SUGs do not contain actual updates; a SUG contains a reference or pointer to the update. You cannot deploy updates to clients without a SUG. When software updates are deployed to a collection of clients, the list of software updates in the SUG is sent to the client in the form of a client policy authorization list.

Create SUGs by selecting updates from the All Software Updates node or one of its subfolders. Use filters to help narrow down the updates you want to include. After selecting the updates, choose Create Software Update Group from the right-click context menu or from the Home tab of the ribbon bar to launch the Create Software Update Group dialog box. In this dialog, shown in Figure 15.9, enter the name and description for the new SUG. New SUGs appear under the Software Update Groups node in the navigation tree of the console.

FIGURE 15.9 Create Software Update Group dialog box.

If a SUG already exists and you want to add or remove software updates from the group, select the updates and choose Edit Membership from the right-click context menu or from the Home tab of the ribbon bar to launch the Edit Membership dialog; place a checkmark next to each update you want to add. Remove the checkmark next to any update you want to delete from the SUG. By doing this, you are not actually deleting the update from ConfigMgr; you are just removing the reference to the update in the SUG.

To determine overall compliance either for a set of software updates or all software updates, you could create a compliance group of software updates; this is a SUG without a corresponding deployment. Use this compliance group to evaluate the compliance of a set of updates against all systems in the console or any collection of systems using the built-in reports. New to ConfigMgr is the Software Updates Dashboard, available by selecting Monitoring -> Overview -> Security -> Software Updates Dashboard. The dashboard allows you to take a quick look at compliant versus noncompliant systems, and it includes a pie chart of security updates versus critical updates versus update rollups versus others. The Devices Missing Updates chart provides a quick view of the number of systems missing the various updates.

It might seem as though the SUG and the deployment package are tied together as one unit. This is not true; the deployment package is not tied to the SUG. A SUG can have software updates that span multiple deployment packages.

Clients install software updates in a deployment by using any DP that has the software updates available, regardless of the deployment package. If a package is deleted for an active deployment, clients can still 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 DP that is accessible to the client. After the last deployment package containing a software update is deleted, client computers cannot retrieve the software update until the update is again downloaded to a deployment package. Software updates appear with a red arrow in the ConfigMgr console when the software update files are not in any deployment packages. Deployments appear with a double red arrow if they contain any updates in this condition.

You cannot create a deployment package from the console. Use one of two wizards to create the deployment package:

Download Software Updates Wizard: Navigate to All Software Updates and select a software update or a group of software updates. Choose Download from the right-click context menu or from the Home tab of the ribbon bar to access this wizard.

Deploy Software Updates Wizard: Navigate to All Software Updates and select a software update or group of software updates. Choose Deploy from the right-click context menu or from the Home tab of the ribbon bar. When you choose this wizard and the software updates are not yet downloaded, the Download Software Updates Wizard pages are folded into this wizard; you see the pages for both wizards.

The Download Software Updates Wizard, displayed in Figure 15.10, contains six or eight pages, depending on what is selected for a deployment package. If Select a deployment package is selected, there are only six pages; if Create a new deployment package is selected, there are eight pages. In either case, the last three pages are the same as with almost all wizards in ConfigMgr—the Summary, Progress, and Completion pages. The following are the other Download Software Updates Wizard pages:

FIGURE 15.10 The Download Software Updates Wizard.

Deployment Package: Select an existing deployment package by clicking Browse, or create a new package. If creating a new package, you must provide a name and description for the package; this appears in the Deployment Package node. You also must choose the source location of the package by using a URL path. The location you choose must exist before you run the wizard.

Distribution Points: Select the DPs to which you want to send this package. You can choose from either a list of DPs or a DP group from a dropdown menu.

Distribution Settings: Choose the type of settings to use with this distribution. You can choose your priority from a dropdown menu, whether you want to distribute the package to preferred DPs, and the behavior you want to occur when the DP is enabled for prestaged content.

Download Location: Choose to use Microsoft Updates or a network share as the location from which to download updates. Most organizations choose to use Microsoft Updates. If your site does not have Internet access, select a network share as the location. This requires preloading the updates from a machine with Internet access and copying them to the network location to be used by the wizard.

Language Selection: Choose the language to use when downloading the update files. For example, if you choose English and French, the wizard downloads two files for each update—one in English and one in French.

Monitor the download activity by looking at the PatchDownloader.log file. The downloads run under the current logged-in user running the wizard, so the log is in the temporary folder of that user: C:users<username>AppDataLocalTemp. The AppData folder is hidden, so you may not see it until you change display options to show hidden folders.

Deployment packages are similar in nature to software packages but have some distinct differences:

Clients needing to install an applicable update deployed to them using an update deployment would download that update from any available deployment package on any DP in the boundaries for that client.

Deployment packages are not linked to update deployments in any way.

Clients do not need to download an entire deployment package to install the software update; they can download a single update from any deployment package that has the update.

Since there are many software updates across a wide range of operating systems, deployment packages can be very large, which can cause issues when the content is distributed to DPs. A common failure for software updates is not ensuring that all applicable update packages are properly replicated and available on DPs where clients will request the updates. In general, the authors recommend making all your update packages available on every DP unless your DPs are tight on space or you have severe bandwidth limitations. The authors also recommend organizing deployment packages by the release date of updates, such as by year, by half year, or even by quarter, rolling over the updates into the yearly package as needed. This lets you cut down the size of the packages that are most often used.

There are two methods for creating an update deployment. Both use the Deploy Software Updates Wizard, but one has fewer pages in the wizard than the other:

Starting with No SUG or Pre-created Deployment Package: Start this wizard in the All Software Updates node of the console by selecting the software updates you want to deploy and choosing Deploy from the right-click context menu or from the Home tab of the ribbon bar. This launches the full wizard, containing all pages, and automatically creates the SUG and deployment package.

Pre-creating the SUG and the Deployment Package: Launch this version of the wizard in the Software Update Groups node of the console by selecting the SUG you want to deploy and choosing Deploy from the right-click context menu or from the Home tab of the ribbon bar. The wizard is launched without the deployment package pages. Because you chose the SUG to deploy, that part of the General page is prefilled.

Figure 15.11 shows the Deploy Software Updates Wizard, launched by deploying an already created SUG and deployment package. The authors recommend first creating your SUG and package and then creating the update deployment by deploying the SUG.

FIGURE 15.11 The Deploy Software Updates Wizard.

This version of the wizard contains nine pages; the last three are the same as with almost all wizards in ConfigMgr (Summary, Progress, and Completion), and the other pages are discussed in the following sections.

Deployment Name: This is required and is filled in automatically with the name Microsoft Software Updates - (current date and time). Remove this name and add a more meaningful name that describes what the software updates are for (for example, MS Software Updates for 2018).

Description: This is an optional field where you can enter a brief description about the deployment.

Software Update/Software Update Group: This required field is automatically filled. If you start the deployment by choosing to deploy a SUG, this is filled in with that SUG name and grayed out so you cannot change it. If you are deploying a single software update by selecting the update from the All Software Updates node and choosing Deploy, this is the name of that single software update. If you choose several updates from the All Software Updates node and choose Deploy, this has a general name filled in but is not grayed out, so you can change the name to be more meaningful. The name you choose will be the name of the SUG it creates.

Select Deployment Template: Click this button to bring up a previously saved list of templates. The wizard then uses the pre-created template to show you the pages and settings that are in the template. This allows you to create deployments of the same nature and settings more quickly and also helps avoid human mistakes. To create a deployment template, complete the Deploy Software Updates Wizard and stop on the Summary page. From the top-right side of this page, select Save As Template; this allows you to choose the settings on the pages you want to include in the template and a name for the template. Figure 15.12 shows the Save As Template dialog box.

FIGURE 15.12 Save As Template dialog box.

Collection: This is a required field. Clicking Browse allows you to select a pre-created collection of managed systems to which you want to deploy the software updates. You can only choose device collections; user-based collections cannot be targeted by software update deployments.

Type of Deployment: Use this to select whether the deployment is mandatory. You have two choices from a dropdown menu:

Required

Available

Use Wake on LAN to Wake Up Clients for Required Deployments: You can select this check box if the type of deployment is set to Required; it is grayed out if that option is set to Available. If this option is checked, ConfigMgr uses its built-in Wake on LAN functionally to send the magic packet that wakes up the client, and the client then installs the updates. Before using this option, computers and the network must be configured for Wake on LAN.

Detail Level: This item allows you to choose the state message detail level that will be returned by the client for the deployment. There are three choices:

All Messages: This allows all messages from the client to be returned, which is important if you want to view results as soon as the client does something. This is a good option to choose by default, as when someone runs the enforcement states for a deployment report or other compliance reports, he or she will see the detailed information the client has returned.

Only Success and Error Messages: Use this option to tell the client to only return a state message about success and errors. Running compliance reports with this detail level set may display the last status as unknown. This is because no errors (or success messages) have been returned by the client. Using this option makes troubleshooting very hard if you run into issues.

Only Error Messages: This option returns a state message only if an error occurs. The same issue applies as with the previous setting, where reports may show as unknown.

Schedule Evaluation: This dropdown menu option allows you to set whether a client will use local time or Coordinated Universal Time (UTC). The authors recommend accepting the default value, Client local time.

Software Available Time: This radio button allows you to choose when the deployment is available to the client. You have two choices:

As Soon as Possible: The deployment is available to the client as soon as it receives the policy for the deployment. If you choose Use the client local time in the Schedule evaluation item and choose this option, the current time on the machine where you are running the ConfigMgr console is the time that is set for clients to evaluate when updates are available or when they are installed. If the client is in a different time zone, these actions occur when the client’s time reaches the evaluation time.

Specific Time: If this option is chosen, the two menus below it become available. The first is a dropdown menu for the month and day, and the second is for the time to set.

Installation Deadline: This option is available only if Required was chosen in the Deployment Settings page. It allows you to choose a date and time when the required deployment to install the software updates will start automatically. The same two options available in the Software available time are presented here: a dropdown menu for the month and day and the exact time for the deadline.

The actual installation deadline time is the specific time you configure plus a random amount of time, up to two hours. This reduces the potential impact of all client computers in the destination collection installing the software updates in the deployment at the same time. You can configure the Computer Agent -> Disable deadline randomization setting to disable the installation randomization delay for the required software updates. The authors recommend not disabling randomization, as doing so would have all clients run the software updates installation at the same time.

Delay Enforcement of This Deployment According to User Preferences, up to the Grace Period Defined in Client Settings: This option allows the end user to delay the installation of software updates until the grace period set in the client agent becomes applicable. This allows an end user returning from vacation or being away for an extended period from having to wait until all required deployments are installed before being able to use the system. The user can delay the installation until the grace period ends.

User Notifications: Use this option to choose what you want the user to see when balloons display in the system tray. There are three choices:

Display in Software Center and Show All Notifications: This option lets the end user see the deployment in Software Center and see all the balloon notifications for the deployment in the system tray.

Display in Software Center, and Only Show Notifications for Computer Restarts: This choice shows the deployment in Software Center but shows the notification only when the computer needs a restart.

Hide in Software Center and All Notifications: This hides the deployment from the end user, who will not see anything in Software Center and will not see balloon notifications in the system tray. This can cause issues because the end user is not notified when the reboot occurs and may lose data. This option is not available when Type of Deployment is set to Available.

Deadline Behavior: This option allows you to choose what can be done to the system when it is outside the maintenance window. You can choose to install software updates or restart the system. If this option is unchecked, updates are not installed until the maintenance window time starts. This option is grayed out if Type of Deployment is set to Available.

Device Restart Behavior: Choose whether to suppress system restart on servers and workstations. Some software updates require a system restart after the install. This option allows you to suppress that restart and have the user restart the system at a convenient time. The authors recommend always suppressing the restart for servers to prevent unplanned outages. This option is grayed out if Type of Deployment is set to Available.

Write Filter Handling for Windows Embedded Devices: This option allows you to check the box to commit the changes at the deadline or during a maintenance window. Windows Embedded systems use an overlay to store changes made to the OS; those changes are removed when the device is restarted, restoring the device back to its original state. If deploying software updates to Windows Embedded systems, you should check this box so update installations are not lost. When you do check this box and a Windows Embedded system gets a software updates deployment, the ConfigMgr client requires the Windows Embedded system to reboot; it enters Service mode, allowing only administrators to log in. ConfigMgr then installs the software updates and restarts the Windows Embedded system in Normal mode.

Software Updates Deployment Re-evaluation Behavior Upon Restart: This item configures the client to run a new software updates compliance scan immediately after it installs software updates and restarts. This allows the client to check for any additional software updates that are applicable after the restart and install them during the same maintenance window.

Configuration Manager Alerts: This option starts with a check box that enables the alert to be generated. Checking the box makes two options available for edit:

Client compliance is below the following (percent)

Offset from the deadline time

The alert generation time box shows you the day and time the alert will be generated if the criteria are met. This box is not editable. Take care when setting the criteria for the ConfigMgr alert, as incorrect settings could cause false alerts to be generated.

Operations Manager Alerts: This allows you to choose what to do with the OpsMgr agent when that agent is installed on the system and software updates need to be installed. There are two check boxes, which are unchecked by default:

Disable Operations Manager Alerts While Software Updates Run: This check box does not actually put the OpsMgr agent into maintenance mode but suppresses alerts by pausing the OpsMgr health service running on the client. This can be seen by event ID 1217 in the application event log.

Generate Operations Manager Alert When a Software Update Installation Fails: When a software update fails to install, event ID 11708 is usually generated. When this box is checked, the OpsMgr agent looks for this event ID and generates an OpsMgr alert. The OpsMgr agent is required and must be running on the client for this to occur.

Select the Deployment Option to Use When a Client Uses a DP from a Neighbor Boundary Group or the Default Site Boundary Group: Choose to download or not download when the client cannot find the content on any DP within its own boundaries. If you allow the download, the client will look at DPs containing the content in a boundary group designated as a neighbor of the client or from the default site boundary group. Following are the two options you can select:

Do not install software updates

Download software updates from distribution point and install

When Software Updates Are Not Available on Any DP in the Current or Neighbor Boundary Group, Client Can Download and Install Software Updates from DPs in Site Default Boundary Group: Choose if you want the client to download the content from the default site boundary when there are no other DPs with the content. You can choose from two options:

Do not install software updates

Download software updates from distribution point and install

Allow Clients to Share Content with Other Clients on the Same Subnet: This option, which is checked by default, tells the clients whether they can use BranchCache for the content downloads. If BranchCache is not set up on the clients, this item has no effect on the content download.

If Software Updates Are Not Available on DP in Current, Neighbor or Site Boundary Groups, Download Content from Microsoft Updates: If this option is checked, it allows the client connected to the local intranet to download updates from Microsoft Update if the updates are not found on the DPs. The authors recommend not checking this option.

Allow Clients on a Metered Internet Connection to Download Content After the Installation Deadline, Which Might Incur Additional Costs: Select this option to tell the client it can download updates while using a metered Internet connection. Some Internet network providers charge based on the amount of data sent and received with the Internet connection. The authors recommend not enabling this option.

As update deployments only exist in the context of an update group or specific update, to view or edit an existing update deployment, you must first select the update group or update to which that the deployment belongs. Update deployments particular to the update group or update are displayed at the bottom of the Details pane when you select the Deployment tab. After selecting the deployment from the Details pane, you can enable, disable, delete, or view the properties of the deployment by selecting the corresponding buttons on the Deployment tab of the ribbon bar or from the right-click context menu of the deployment. The properties displayed in the update deployment’s Properties dialog correspond to those configured using the Deploy Software Updates Wizard and are organized on tabs with the same names as the pages of the wizard.

To create an ADR, navigate to Automatic Deployment Rules and choose Create Automatic Deployment Rule from the ribbon bar or from the right-click context menu to launch the Create Automatic Deployment Rule Wizard, displayed in Figure 15.13.

FIGURE 15.13 The Create Automatic Deployment Rule Wizard.

As Figure 15.13 shows, there are several pages to the ADR wizard, most of which you have already seen for creating the SUG, downloading updates, and deploying the updates. The following sections discuss the first four pages, as those are unique to the Create Automatic Deployment Rule Wizard.

Name: This is required; unlike with other wizards that automatically fill in the name, the Create Automatic Deployment Rule Wizard leaves it blank. Use a name that is meaningful; it should describe what the ADR is creating.

Description: This is an optional field where you can enter a brief description about the deployment.

Template: This is a dropdown menu that brings up a list of templates that were previously saved. ConfigMgr also includes four templates for your use. The wizard uses the pre-created template you select to show the pages and settings that are in the template. This allows you to create ADRs of the same nature and settings faster and helps avoid human mistakes. To create a template, complete the Create Automatic Deployment Rule Wizard and stop on the Summary page, which has a Save as Template option on the top-right side. Selecting this option allows you to choose what settings on the pages you want to include in the template and a name for the template (refer to Figure 15.12).

The right-hand side has the option Manage Templates, which allows you to bring up a list of templates, select one, and then either rename the template or delete it.

Collection: This is a required field. Click Browse and select a collection that will be targeted by this ADR. You can only select device collections.

Each Time the Rule Runs and Finds New Updates: Use this item to choose what to do with the SUG if the ADR finds new updates when it runs. You can have the ADR create a new SUG for the new updates or add those to an existing SUG. If you choose to add the updates to a new SUG, beware that a single rule with this option enabled can create hundreds of SUGs in a small amount of time. The authors recommend adding the updates to an existing SUG.

Enable the Deployment After the Rule Is Run: This check box enables the software updates deployment that the rule created after it completes its run. If this option is unchecked, the rule creates the deployment but leaves it disabled. The authors recommend leaving the deployment disabled until you verify that all settings are set correctly. You may want to send the deployment to a test collection to confirm that everything works properly. When the verification is complete, change this setting to enable the deployment.

Use Wake on LAN to Wake Up Client for Required Deployments: If this option is checked, ConfigMgr uses its built-in Wake on LAN functionally to send the magic packet that wakes up the client, and the client then installs the updates. Before using this option, computers and the network must be configured for Wake on LAN.

Detail Level: Use this item to choose the state message detail level returned by the client for the deployment. There are three choices:

All messages

Only success and error messages

Only error messages

Software Update License Agreement: This option deals with software updates for which there are license agreements. A license agreement must be accepted before a software update can be deployed. Since the ADR rule automatically creates the deployment, there is no way to accept the license agreement. This item lets you choose whether to deploy only software updates that do not have a license agreement or those that have the license agreement already approved or deploy all software updates and approve any license agreements. The authors recommend this last option, which is the default.

The Property filters section in the top area of this page of the wizard provides several check boxes for the item or items to use for criteria that the software update must meet. You can check as many of these as you like or as few as one of these items. After you select a check box, the bottom area fills with a link that you can select.

Search criteria at the bottom of the page has a link that allows you to fill in the criteria you want to use. The items you check in the Property filters section determine what type of criteria you are allowed to enter (free text, numeric, and product selection). You can use quotes (“ ”) for an exact string match or the minus sign (-) to indicate that it does not match the item. For example, entering -Itanium in the title property criteria will exclude all updates that include Itanium in their title property. Once you have your criteria, click Add to add the criteria to the search list.

Do Not Run This Rule Automatically: Select this rule when you want to only run the ADR manually. This might be an option when first setting up ADRs to verify that they are selecting the correct software updates.

Run the Rule After Any Software Update Point Synchronization: This allows the ADR to run after the SUP synchronizes with Microsoft Updates. The authors recommend using this setting, which allows the ADR to truly be automatic and deploys software updates to the clients shortly after they are released.

Run the Rule on a Schedule: This allows you to set a fixed date and time for the rule to run, such as the second Wednesday of each month at 2:30 PM. Select Customize to select a date and time to use. The authors recommend that if you set a schedule for the ADR to run, you should coordinate the time to run after your SUP synchronization time, so you evaluate the latest set of software updates.

When the ADR runs, it logs its information in the RuleEngine.log file. This file is located with the rest of the ConfigMgr logs in the Logs folder.

Prior to Windows 10, Microsoft would release new versions or builds of the Windows product line every few years—think Windows XP, Windows Vista, Windows 7, Windows 8, and Windows 8.1. This meant that an organization went through a massive upgrade every several years, after testing the new version of Windows. Large organizations might still be deploying a version of Windows when Microsoft released a newer version. This caused some organizations to skip newer versions and not be current on newer features of the product. Microsoft changed the game with Windows 10; instead of new versions every few years, you will see new functionalities and features in smaller incremental updates two times a year. Microsoft created two ways for Windows 10 to be updated:

Feature Updates: These are changes to Windows 10 that add new features and functionalities to the product. These are what previously would have been released in a new version of Windows, such as going from Windows 8 to Windows 8.1.

Quality Updates: These are security fixes, product hotfixes, and rollup updates. An example would be the Patch Tuesday security fixes released every month. Another change for organizations is that the quality updates are now released as one cumulative monthly update instead of as several smaller updates.

These changes introduce some new challenges for organizations in how to upgrade or maintain the Windows 10 product being used and the type of support available if they do not upgrade or if they get behind in updating.

Semi-Annual Channel: This servicing model allows feature updates to be released twice a year, around March and September. This model is typically for consumers and businesses with general-purpose devices running Windows 10. The authors recommend that businesses take a gradual approach to incorporating these releases into their general population. Following this approach would involve a testing phase to see if current applications are compatible with the new release; once that testing is completed, a pilot group would test the update, and the organization would then move to a broader deployment. Each of these twice-a-year releases will be supported by Microsoft for 18 months from the time it is released.

Long-Term Servicing Channel: This model is designed for businesses requiring the OS running on a machine to not change and to not have features added. Think of machines controlling medical equipment, point-of-sale (POS) systems, and machines running automation processes in a factory. These systems usually have a financial impact to the organization if they are taken offline or if they fail due to a new feature or update. This channel will see releases approximately every 2 to 3 years. These releases will be supported for 10 years from the date of release.

These new servicing channels mean that you must upgrade your Windows 10 devices at a much faster pace than previously to keep your systems current and keep you in a supported mode. More information about servicing branches and servicing of Windows 10 in general can be found at https://technet.microsoft.com/itpro/windows/manage/waas-overview#servicing-branches.

Table 15.2 shows the servicing options and their life cycles.

TABLE 15.2 Windows 10 Branch Servicing Options

Microsoft has created a sample of what the deployment rings might look like:

Preview: This is a pilot of IT users; users get this release through the Windows Insider Program and the Windows Insider for Business Program.

Targeted: This is a pilot of business users; these devices should be across multiple teams and groups. These teams or groups should represent most of the departments in an organization. This ring should be used to test the release before it goes out for deployment to the global set of devices.

Broad: This is a deployment to broad IT users; this will be your deployment to the rest of organization.

Critical: This for devices that are deemed critical by the business. These devices should receive the update only after the rest of the organization has tested the release and shown that it does not present issues that would affect these critical devices.

While not every organization will use the deployment rings, you should consider how many rings are needed and what users might encompass those rings. This way you can ensure that most issues with deployments of feature updates are found in pre-deployment testing and within the targeted ring.

The deployment rings are based on the servicing branches, so you begin by creating collections of the different servicing branches. This allows you to easily find users for each ring you need to create. The collections of these servicing branches are easily created in ConfigMgr, using an OS property collected as part of the ConfigMgr client discovery inventory, OSBranch. A WQL query that creates the collection follows:

select * from SMS_R_System where SMS_R_System.OSBranch = 0 and
SMS_R_System.OperatingSystemNameandVersion like "Microsoft Windows NT
Workstation 10.0%"

The values you can use for OSBranch are 0 for Current Branch, 1 for Current Branch for Business, and 2 for Long-Term Servicing Branch; this terminology has been replaced with the Semi-Annual Channel for Current Branch and Current Branch for Business and Long-Term Servicing Channel for Long-Term Servicing Branch. However, ConfigMgr and the OSBranch entries still use the terms Current Branch, Current Branch for Business, and Long-Term Servicing Branch; look for these to change in later releases of ConfigMgr and Windows 10. The second part of the query limits the data returned to only Windows 10 workstations.

Once your servicing branch collections are created, create collections for your rings by using the servicing branch collections as a limiting collection. This should give you a good idea of how many systems are in the different servicing branches and the users you would include in the different rings your deployment process uses.

Software Update Point: Windows 10 Servicing is delivered and executed by the software updates components on the server and client, so you need to have an installed and working SUP.

Heartbeat Discovery: Information from Heartbeat Discovery is used to populate the Windows 10 Servicing Dashboard. The authors recommend setting the frequency of this setting to daily. The information is small and will not cause performance issues.

WSUS Updates to Support Windows 10 Feature Upgrades: This is covered in the “Using Windows Software Update Services” section, earlier in this chapter.

Upgrade Classification and Windows 10 Product: To deploy upgrades to clients, ensure that for the SUP properties, the Upgrade box on the Classification tab is checked and that Windows 10 is checked on the Products tab. This allows the SUP to synchronize these items with Microsoft Update. These can be seen by navigating to Software Library -> Overview -> Windows 10 Servicing -> All Windows 10 Updates in the ConfigMgr console.

Assign Devices to the Correct Servicing Channel: As part of the methodology for servicing Windows 10 devices, you must decide what devices to keep at Current Branch and which move to Current Branch for Business. Devices will be at Current Branch by default until moved to Current Branch for Business. A GPO is used to move devices to Current Branch for Business. Two GPOs are used, depending on the version of Windows 10:

Windows 10 Version 1511: This version can be moved to Current Branch for Business using the GPO located at Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update -> Defer Upgrades and Updates. Enable this GPO; no other settings need to be changed. Once the client receives the GPO enabling the setting, the client is considered Current Branch for Business.

Windows 10 Version 1607: This version can be moved to Current Branch for Business using the GPO located at Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Update -> Defer Windows Updates. Right-click the Select when Feature Updates are received settings and select Edit. Enable the policy and select the Current Branch for Business branch readiness level. Once the client receives the GPO enabling the setting, it is considered Current Branch for Business. Figure 15.14 shows this GPO setting.

FIGURE 15.14 GPO for setting Windows 1607 to Current Branch for Business.

With the GPOs set and the machines at the correct serving level, when the ConfigMgr client runs the discovery process, the OSBranch property is collected and sent to the ConfigMgr database. This allows you to create your servicing branch collections. Either use GPOs or set a local machine policy for this information to be collected.

FIGURE 15.15 Windows 10 Servicing dashboard.

Figure 15.15 shows the dashboard with some of its tiles. Eight tiles provide Windows 10 information:

Windows 10 Usage: This tile gives a breakdown of the Windows 10 builds managed by ConfigMgr. Each version of Windows shows in the tile below the ring. Moving the mouse over the tile or versions listed at the bottom of the tile highlights that part of the ring and shows the number of Windows 10 devices and their builds.

Windows 10 Rings: This tile is by branch and readiness state:

LTSB: The Long-Term Servicing Branch segment will be all Long-Term Servicing Branch versions, while the first tile breaks down the specific versions, such as Windows 10 2015 Long-Term Servicing Branch.

Release Ready: This segment corresponds to Semi-Annual Channel, or Current Branch in versions of Windows 10 prior to version 1709.

Business Ready: This segment is Semi-Annual Channel (targeted), or Current Branch for Business in versions of Windows 10 prior to version 1709.

Move the mouse over the numbers in the ring or servicing branches at the bottom to highlight the number of machines in that portion of the ring and show a percentage.

Create Service Plan: This tile provides a quick way to create a servicing plan (discussed in the “Servicing Plans” section of this chapter). Specify the name, collection (only the top 10 collections display, and they display by size, smallest first), deployment package (only the top 10 packages display, and they display by most recently modified), and servicing ring. Default values are used for the other settings; to change those defaults, click Advanced Settings to start the Create Servicing Plan Wizard, where you can configure all the settings, as shown in Figure 15.16.

FIGURE 15.16 Create Servicing Plan tile.

Expired: This tile displays the percentage of devices on a build of Windows 10 past its end-of-life. ConfigMgr determines the percentage from the metadata the SCP downloads and compares it against discovery data. A build past its end-of-life no longer receives monthly cumulative updates, including security updates. ConfigMgr rounds up to the next whole number for the percentage, so if the math says that you have 4.5% of machines in this state, the tile will show 5% for the number. This tile provides a good estimate of machines in this state, but you should follow up to obtain the exact number of machines.

Alerts: This tile displays any active alerts.

Expire Soon: This tile displays the percentage of computers on a build near end-of-life. This would mean that you have about four months before that build of Windows 10 is at end-of-life. As with the Expired tile, ConfigMgr rounds up to the next whole percentage number.

Service Plan Monitoring: This tile displays the servicing plans you have created and a compliance chart for each plan, providing a quick overview of the current state of the servicing plan deployments. Clicking Deploy Now brings up a dialog box asking to select a collection. Once selected, the highlighted servicing plan is deployed to that collection, creating a basic servicing plan that uses all the default values. Use the ConfigMgr console to create a plan with custom options.

Windows 10 Builds: This tile displays a fixed image time line that provides an overview of the Windows 10 builds currently released and gives you a general idea of when builds will transition into different states. This information is gathered by the SCP and should be verified. If the SCP is not working correctly, this information may be out of date.

The dashboard provides a great deal of information in a visual form, giving most users the information they need at a glance. To obtain more information, you need to drill deeper into the Windows 10–managed systems.

Servicing plans are created using a wizard and share the same rule engine as the ADR. Some pages in the wizard are the same as the ones covered earlier in this chapter, in the “Using Automatic Deployment Rules” section. To start, open the ConfigMgr console and navigate to Software Library -> Overview -> Windows 10 Servicing -> Servicing Plans and choose Create Servicing Plan from the ribbon bar or from the right-click context menu to launch the Create Servicing Plan Wizard, displayed in Figure 15.17.

FIGURE 15.17 Create Servicing Plan Wizard.

As Figure 15.17 shows, the wizard has several pages. You may have seen many of these pages when creating the SUG or ADR, downloading updates, and deploying updates. The following are the first four pages, which are unique to the Create Servicing Plan Wizard:

General: This page is similar to the General pages of other wizards; add a name that is meaningful and an optional description for this servicing plan.

Servicing Plan: This page allows you to select the target collection to use for the servicing plan upgrade. Browse to choose from device collections; user collections are not allowed.

FIGURE 15.18 Deployment Verification warning message.

FIGURE 15.19 High-risk error message.

Deployment Ring: The top of this page allows you to choose the Windows readiness state for this servicing plan. You can choose between Release Ready (Current Branch) and Business Ready (Current Branch for Business). In the middle of the page, you can select the number of days to delay the deployment after the new upgrade is published by Microsoft. This slider bar goes from 0 to 120 days. ConfigMgr evaluates whether to include an upgrade in the deployment if the current date is after the release date plus the number of days you configure for this setting.

Upgrades: This page allows you to set the criteria to be used for the feature updates and upgrades for the deployment.

The Property filters in the top area of the page provide check boxes for Language, Required, and Title that you can use for criteria. Check as many or as few of these items as you want. After selecting a check box, the bottom area fills with a selectable link.

The Search criteria in the bottom of the page has a link allowing you to fill in the actual criteria you want to use. The items you check in the Property filters section determine the type of criteria you are allowed to enter (free text, numeric, and language selection). Use quotes (“ ”) for an exact string match or the minus sign (-) to indicate that it does not match the item. Once you have your criteria, click Add to add the criteria to the search list.

On the bottom-right side is Preview, which allows you to preview what updates and upgrades will be returned, based on the criteria selected. This provides a good opportunity to verify that you used the correct criteria.

After you complete the wizard, the servicing plan will run by default after the next SUP sync; change this by highlighting the servicing plan and choosing Properties from the ribbon bar or from the right-click context menu and navigating to the Evaluation Schedule tab. Once the rule runs, it adds updates that meet the specified criteria to a SUG, downloads the updates to the deployment package, distributes the updates to the configured DPs, and deploys the SUG to clients in the target collection. The name of the SUG is automatically created and is changeable by choosing the properties of the SUG.

When the servicing plan rule runs, it downloads the upgrade and/or update packages from Microsoft Update. These packages are in excess of 2GB, and the rule will download x64 and x86 versions of the packages. Once downloaded, the packages are distributed to the DPs. Allow time for the download and content distribution to occur before the deployment becomes available to the end user. The authors recommend setting the available time to four hours or more from the current time of creating the servicing plan.

Since the servicing plan rule and ADR use the same engine, you can monitor the process of the rule running in the RuleEngine.log file. Downloads are logged in PatchDownloader.log.

Almost all client activity for software updates takes place in the background, across multiple client components. These components interact with each other, creating and managing internal jobs to detect the updates needed, scanning to see the state of updates the machine has and needs, downloading the needed updates, installing the updates, and reporting the status of the updates (installed, failed, reboot needed, and so on).

Software update deployments can be created to be totally silent, to notify the user every step of the way, or to do something in between. The following sections point out the differences the user will see but focus mainly on full user notification.

Scan results are stored in WMI, using the ccm_updatestatus class in the rootccmsoftwareupdatesupdatesstore namespace. State messages send the results back to the ConfigMgr site. These are XML messages cached on the client for 15 minutes (by default) and submitted in bulk to the client’s site MP. They relay point-in-time information about the client to the site.

The WUA performs the compliance scan and marks each update with a compliance state. An update can be in one of four states:

Required: This means the update is still needed on the client system or that it is installed but requires a restart. If the update needs a reboot, it is not considered installed until that reboot occurs.

Not Required: This means the update is not applicable on the local system.

Installed: This means the update is already successfully installed on the local system.

Unknown: There are many reasons for an unknown update status, including communication issues, client scan issues, and configuration issues. The client’s WUAHandler.log is the first place to check to verify proper configuration.

Scan results are good for 24 hours; this is called the time to live (TTL). When the TTL expires, the results are not considered accurate. When the client receives a software updates deployment, the TTL is ignored, and a fresh scan is performed.

TABLE 15.3 Software Update Notifications

Notification is presented by a balloon in the system tray of the machine. Figure 15.20 shows the balloon displayed when the user is notified that updates need to be installed.

FIGURE 15.20 Software updates balloon notification.

In addition to the balloon, a new item is added to the system tray—a box with a red plus sign. If you right-click this icon and choose View Required Software, the dialog box shown in Figure 15.21 appears.

FIGURE 15.21 Software Center Changes dialog box.

This dialog box has several options for the user:

View Details: Click this link to open the full Software Center program and see all details for each software update that needs to be installed.

Right Now (Recommended): Choosing this option starts the installation immediately.

Outside My Business Hours: Each system has a defined set of business hours, found inside Software Center. By default, business hours are set at 5 AM through 10 PM Monday through Friday. Selecting this option causes the software updates to only install outside those hours. Clicking a hyperlink in this option opens Software Center, which shows the business hours.

Snooze and Remind Me Later: Select this dropdown to choose to be reminded at a later time.

Restart My Computer Automatically if Needed: If this option is checked, the system reboots without warning after installing the software updates, if needed.

The software changes dialog box shown in Figure 15.21 and these options are displayed only when the software updates deployment is set to Available and the deadline has not been reached.

FIGURE 15.22 Software Center.

The Installation status section of the dialog shows the status of the updates or applications as they are being installed. An update can go through several different statuses as the install occurs:

Available: The update is available for immediate installation.

Scheduled to Install After: This is a required update, scheduled to install after the date and time specified in the status message.

Past Due - Will Be Installed: This indicates that a required update is past its scheduled installation time. Updates are often in this status because of maintenance windows or failure to locate content.

Preparing to Download: The client agent is finding an available location for the update’s content.

Downloading: The client agent is downloading the content from an available location. This status also includes a percentage complete.

Waiting to Install: The update is preparing to install.

Installing: The update is installing.

Pending Verification: The update is installed but being verified.

Installed: The update is already installed and is verified as installed.

Requires Restart: The update requires a reboot to complete installation.

If an update is actively downloading or installing and notifications are enabled, an icon shows in the taskbar icon notification area with a tooltip that reads Downloading and installing software.

If the user chooses to install the updates through Software Center -> Updates, he or she can click on a single update to display the information about that update and a button that allows for update installation or scheduling of update installation, as shown in Figure 15.23.

A user who wants to install all the updates at once can click Install All (refer to Figure 15.22).

FIGURE 15.23 Software Center Update Details.

Once the updates are installed, if a reboot is needed, a Restart required balloon notification is displayed, as shown in Figure 15.24.

FIGURE 15.24 Software updates Restart required balloon.

Since the user may not be ready to reboot at that specific time, ConfigMgr places an icon in the system tray, as shown in Figure 15.25, to remind the user to reboot.

FIGURE 15.25 Software updates Restart icon.

If the user chooses not to reboot before the deadline, the icon remains in the system tray, and the user is notified with balloon notifications according to the reminders set up in Client Settings -> Computer Restart.

At each step, state messages are sent to the MP with which the client is communicating. These state messages help track the installation status of the updates and can be seen in the console by navigating to Monitoring -> Overview -> Deployments. If a reboot is needed, the update is not considered installed until it occurs. After the reboot, there may be a delay in reporting that the update is installed. To prevent this delay, Microsoft added a check box forcing a software updates deployment reevaluation upon restart to the User Experience tab of the software updates deployment. If this option is checked, after the reboot occurs, the ConfigMgr client runs the reevaluation, sees that the update is installed, creates a state message, and sends it to the MP, where it is processed into the database.

In addition to the information presented here, four excellent blog posts are available that review and step through the in-depth minutia of the software update process, as viewed through the log files. Some of these are older posts but still can be applied to ConfigMgr Current Branch:

https://blogs.msdn.microsoft.com/steverac/2011/04/10/software-updatesinternals-mms-2011-sessionpart-i/

https://blogs.msdn.microsoft.com/steverac/2011/04/16/software-updatesinternals-mms-2011-sessionpart-ii/

https://blogs.msdn.microsoft.com/steverac/2011/04/30/software-updatesinternals-mms-2011-sessionpart-iii/

https://blogs.technet.microsoft.com/configurationmgr/2016/08/25/software-updates-in-configuration-manager-current-branch-deep-dive-client-operations/

Success: Machines listed here have successfully completed the software updates deployment. They report in green.

In Process: These are machines currently running the software updates deployment but have not yet finished. These are reported in yellow.

Error: These are machines that received the software updates deployment but ran into an error when trying to download the content or execute the deployment. Dig deeper by looking at the lower part of the page, at Asset Details. One of the details is the error code returned from the client. This can give you an idea of where to start looking for the issue with that client.

Requirements Not Met: Machines in this state received the deployment but did not meet the rules that allow the deployment to run.

Unknown: All systems appear in this state once the deployment is created. When a system returns a state message, it moves out of this state. If you see machines in this state after the deployment has been running a while, they did not receive the deployment and could be broken clients.

Another area in Monitoring that can be helpful is Software Update Point Synchronization Status. This section allows you to see the current status of the SUPs, when their last synchronization attempt was, the status of that attempt, and the catalog version on each SUP. This lets you quickly see if there are sync problems or if the SUPs are using old catalog versions. If a client is saying that it doesn’t need an update, it may be that it is scanning against an older version of the catalog.

WCM.log: This component provides information about the SUP configuration and connecting to the WSUS server for subscribed update categories, classifications, and languages. When changes are made to the SUP’s settings, this component connects to WSUS and makes the changes. If you change your settings on WSUS, this component will connect to WSUS and overwrite those changes.

WSUSCtrl.log: This log file provides information about the configuration, database connectivity, and health of the WSUS server for the site. Once an hour, this component connects to the WSUS website to verify that connectivity is working. If your SUP is remote, this log file is located on the remote SUP.

wsyncmgr.log: This component synchronizes WSUS with Microsoft Updates and then synchronizes ConfigMgr with WSUS; it is a two-part process.

Most errors experienced with WSUS are configuration errors, including not matching the ports configured during installation of WSUS and then configured in the SUP. Remember that with WSUS 4.0 and above, the default port is 8530.

Also common are Internet connectivity issues due to firewalls, proxy servers, and other mitigating factors. Confirm that the system running WSUS has Internet connectivity if you are downloading the update catalog directly from Microsoft and ensure that you have properly configured the proxy account if one is required.

For ADRs, the site server hosting the SUP downloads the updates for you. This uses that system’s local system account, which in turn uses that system’s AD computer account for its identity on the network.

The PatchDownloader.log file logs download activity for updates and contains information about the update download process. The file is located in different places, depending on who is running the downloads:

SMS_CCMLogs: When the ADR runs, it runs as Local System and creates the log file in this folder.

%User%AppDataLocalTemp: When downloading updates, the file is created under the user’s temp folder. Some folders are hidden, so make sure you are viewing hidden files to see them.

ScanAgent.log: Provides information about the scan requests for software updates, the tool requested for the scan, and the WSUS location. If your clients do not seem to be requesting the newer software updates, it could be that the scan has failed or the scan is not getting a current copy of the catalog. This log is a good place to start.

UpdatesDeployment.log: Provides information about the deployment on the client. This includes software update activation, evaluation, and enforcement. This log also shows all the software updates deployments the client has received. You can also see the downloads of the updates in this log.

UpdatesHandler.log: Provides information about software update compliance scanning as well as download and installation of software updates on the client.

UpdatesStore.log: Provides information about the compliance status for software updates assessed during the compliance scan cycle.

WUAHandler.log: Provides information regarding when the WUA on the client searches for software updates. One of the main issues that can affect the scanning process is a domain-based GPO overriding the Windows Updates settings. The WUAHandler.log file clearly indicates if this issue exists in your environment.

Back Up the WSUS Database: You may ask why, as there is nothing in the database that you cannot recover by rebuilding the SUP or synchronizing with Microsoft Updates. While this is true, why waste the time to resync everything when you can restore a small backup and be up and running again quickly? Plus, if you are using System Center Update Publisher (SCUP), a lot of custom information will be lost if you lose the SUSDB. Use SQL backup or any other backup program that works with SQL databases. This can even be set up as an automated process using a SQL job and the SQL agent.

Run the WSUS Server Cleanup Wizard: ConfigMgr now provides a check box for this in the Supersedence Rules tab of the SUP properties of a site. However, this is only run every 30 days. In some organizations, it should be run every week. If it has been a long time since this was last run—or perhaps has never run—the wizard may time out. The fix is to run it repeatedly until it stops timing out.

Decline Superseded Updates: Since the client downloads the entire catalog the first time and then delta updates afterward to scan against, that catalog will contain any superseded updates that have not been declined. Declining the superseded updates reduces the size of the catalog and the amount of time the client needs to complete a scan.

Re-index the WSUS Database: An index allows the database to be read faster, giving results quicker. Over time, with updates and deletions, the index can become out of date and may actually cause a slowdown in reading data. For optimal performance, re-index the database monthly or every week, if possible.

Most of these steps can be scripted and automated. See https://blogs.technet.microsoft.com/configurationmgr/2016/01/26/the-complete-guide-to-microsoft-wsus-and-configuration-manager-sup-maintenance/ for additional information.

Microsoft has released some best practices for software updates with ConfigMgr, which can help give the best performance overall:

Use a shared WSUS database for SUPs.

When ConfigMgr and WSUS use the same SQL Server instance, configure one of them to use a named instance and the other to use the default instance of SQL Server.

Specify the Store updates locally setting for the WSUS installation.

Limit software updates to 1,000 in a single software updates deployment.

Create a new SUG each time an ADR runs for Patch Tuesday and for general deployment.

Use an existing SUG for ADRs for Endpoint Protection definition updates.

In-depth information for these items can be found at https://docs.microsoft.com/sccm/sum/plan-design/software-updates-best-practices.

SCUP is not included with ConfigMgr but is a separate and free download from Microsoft, available at http://www.microsoft.com/download/details.aspx?id=11940. The tool lets you import updates from non-Microsoft products into ConfigMgr or define your own for third-party products or in-house applications; these non-Microsoft updates sit side-by-side with the Microsoft updates in the ConfigMgr console and are managed and deployed exactly the same way as Microsoft updates contained in the WSUS catalog. Many administrators have also used SCUP to deploy Microsoft updates not included in the WSUS catalog. Updates are updates, and managing them the same way regardless of their source has great value.

Windows 8.1

Windows Server 2012 R2

You can install SCUP on any system with connectivity to your top-level SUP, including the site server or a remote workstation that also has the WSUS administration console installed (or full WSUS) and is one of these listed operating systems.

If using Windows 8.1 for you SCUP workstation, install the Remote Server Administration Tools (RSAT) for Windows 8.1. Part of the RSAT installation also installs the WSUS 4.1 console and binary files that allow the SCUP application to connect to the Windows Server 2012 R2 WSUS server. This in turn allows the Windows 8.1 workstation to publish items into the WSUS server. Download the RSAT tools from http://www.microsoft.com/download/details.aspx?id=39296. If using a Windows 2012 R2 SUP server for the SCUP install, the WSUS server is already installed on that machine.

No matter which OS you choose for SCUP installation, you still must complete a workaround to allow local administrators to publish updates from SCUP to the Windows Server 2012 R2 WSUS server. This workaround involves editing the Registry and DCOM permissions. Details are at https://technet.microsoft.com/library/hh134747.aspx#PublishToServer2012. (This site talks about Windows Server 2012 but is also relevant for Windows Server 2012 R2.)

SCUP uses a local SQL Server Compact Edition database, so there is no need to provide permissions or connectivity to a full SQL Server instance. SQL Server Compact Edition is a local, single-user, Microsoft Access-like database engine that is automatically installed with SCUP. For more information on SQL Server Compact Edition, see http://technet.microsoft.com/library/ms173037(v=sql.105).aspx.

SCUP installation is straightforward: Launch the downloaded Windows Installer MSI package and follow the wizard. The install requires administrator rights, so on a machine with User Account Control (UAC) settings enabled, open an administrator command prompt, navigate to where the MSI is located, and launch it from the command prompt window. Figure 15.26 shows the second page of the installation program, where you might run into issues.

FIGURE 15.26 Second page of SCUP install.

If the correct version of the WSUS console and binaries are not installed on your machine, you will not be able to click Next to move forward. Installing the 3.0 SP 2 version of WSUS is not an option at this point; you must install the RSAT tools for Windows 8.1 on the workstation and restart the SCUP installation.

FIGURE 15.27 SCUP console.

After launching the SCUP console, select the Application menu from the ribbon bar and choose Options. There are five sections in the resulting Options dialog:

Update Server: On this page, shown in Figure 15.28, enable update publishing and configure the options SCUP uses to connect to the SUP so it can publish updates. Specify the top-level site in your hierarchy and be sure to set the correct port. The default of port 80 is no longer used by WSUS 4.1; the default now is 8530. If your test connection fails, check that the port is set to the correct value.

FIGURE 15.28 SCUP update options configuration.

Publishing updates into a SUP also requires a code-signing certificate so clients can verify the source of updates delivered to them. In past versions of WSUS, you could create a self-signed certificate by clicking Create on this page. When clicking Test Connection or Create, you now see a warning message, as shown in Figure 15.29, as you cannot publish content to the WSUS server until the certificate is in place.

FIGURE 15.29 SCUP update options certificate warning.

To work around this issue and restore the legacy ability to create the self-signed certificate, add a Registry key to the machine SCUP is installed on; the location of the Registry key is HKEY_LOCAL_MACHINESoftwareMicrosoftUpdate ServicesServerSetup. Next, create a new DWORD value called EnableSelfSignedCertificates and set the value to 1. The authors recommend restarting the SCUP application if it was running when you made the Registry change. Once the Registry change is in place, click Test Connection and Create to create the self-signed certificate. Note that because this is a legacy operation that has been removed from the GUI, there is no guarantee that this will continue to work with updated versions of WSUS.

You will find this self-signed certificate in the SUP’s local computer store, under the WSUS folder. You need to export the certificate; to do so, follow these steps:

1. Open a new or existing instance of the Microsoft Management Console (MMC). To open a new instance, launch mmc.exe.

2. On the MMC File menu, choose Add/Remove Snap-in.

3. On the resulting Add or Remove Snap-ins dialog, choose Certificates in the Available snap-ins list box on the right and click Add.

4. In the Certificates snap-in dialog, choose Computer account, click Next, leave Local computer selected on the next page, and click Finish.

5. Click OK on the Add or Remove Snap-ins dialog.

6. In the tree on the left, expand Console Root -> Certificates (Local Computer) -> WSUS and select the resulting Certificates node.

7. Right-click the certificate generated by SCUP (named WSUS Publishers Self-signed) in the Details pane on the right, and choose All Tasks -> Export to launch the Certificate Export Wizard.

8. Chose Next on the first page of the wizard. On the second page chose No, do not export the private key; on the third page choose DER encoded binary X.509 (.CER) and click Next.

9. Enter an appropriate filename and click Next to reach the final page of the wizard. Click Finish to complete exporting the certificate.

Figure 15.28 shows two other selections that are grayed out: Browse and Remove. These buttons work only if you connected to the WSUS server using SSL and port 8531. You must set up WSUS to use certificates and SSL before making the connection in SCUP. Once this connection is made, you can use a certificate generated by an internal public key infrastructure (PKI) or a public CA such as VeriSign. The only requirement is that the certificate be a code-signing certificate. Some public CAs call these types of certificates Microsoft Authenticode certificates. Click Browse to import an externally generated certificate. To use an internal PKI-generated certificate with SCUP, see https://blogs.technet.microsoft.com/jasonlewis/2011/07/12/system-center-updates-publisher-signing-certificate-requirements-step-by-step-guide, which documents the process for creating that certificate. Once the certificate is created, use a GPO to deploy it to all clients, including the SCUP and the WSUS server to which you will be publishing. (The article explains how to use a GPO to deploy the certificate.)

If using a public CA, ensure that you are very explicit when requesting the certificate and that you thoroughly test the certificate. Special use certificates like the one required for SCUP may require extra steps when using a public CA, depending on the CA. For in-depth information on how to use public certificates with SCUP, see https://blogs.msdn.microsoft.com/steverac/2011/09/17/using-system-center-update-publisher-2007-with-verisign-certificates.

It does not matter what type of certificate you use, as they all work the same inside SCUP. After choosing the certificate type, confirm that the certificate is added to Trusted Publishers and that the Trusted Root Publishers certificate store is on all systems, including the machine running SCUP and the WSUS/SUP server to which SCUP is trying to publish. Publishing the update will fail if the certificates are not in the correct stores. When an update is published, it is signed with the certificate inside SCUP; when the client receives the policy to execute this update, it verifies that the certificate used to sign the update is trusted by checking the Trusted Publishers and Trusted Root Publishers certificate stores. If the certificate is not found in both stores, the update is not allowed to execute.

One last requirement on any client where you wish to deploy updates published using SCUP is to enable the Allow signed content from intranet Microsoft update service location policy. This is typically set using a GPO and can be found under Computer Configuration -> Administrative Templates -> Windows Components -> Windows Update in the group policy object editor.

ConfigMgr Server: Use this tab to enable the integration with ConfigMgr. Make sure you connect to your top-level site. Use the FQDN as the name and click Test Connection to verify connectivity. If using automatic publishing, enabling ConfigMgr integration allows SCUP to query the compliance status of updates and fully publish them in ConfigMgr only if actually requested by clients and they fall under a particular size. Prior to fully publishing updates, the two thresholds at the bottom of this page are checked:

Requested Client Count (Threshold): This is the minimum number of clients that must request an update. If this number is not met, SCUP only publishes the metadata for the update.

Package Source Size Threshold (MB): This is the maximum size of the content for an update. If the size of the update is over this number, only the metadata for the update is published.

Trusted Publisher: This tab allows you to see the publishers trusted by SCUP, view the certificate of the trusted publishers, and remove a publisher from the list. Publishers are added to the Trusted Publishers list when a catalog is imported into SCUP and when publishing a software update. You cannot add certificates here; you can only remove or view them.

Proxy Settings: This tab allows you to configure the proxy settings, if necessary, for SCUP to download third-party update catalogs. If your organization requires access to the Internet to go through a proxy server using username and password credentials, you must enable these settings and add the correct information before you can download any third-party catalogs.

Advanced: The options on this tab allow you to view the location of the SCUP repository, enable some general settings, enable certificate revocation, set the location for local source publishing, and run the Software Updates Cleanup Wizard.

Database File: This is the location of the SQL Compact Edition database file used by SCUP; it is read-only and user specific, meaning that each user can have specific settings and software updates to publish. The authors recommend using only one user, as using multiple users tends to complicate the process more than help it.

Add Timestamp When Signing Updates: This adds a timestamp from an authoritative Internet source when signing updates, which is useful because it makes updates deployable even after the certificate used to sign them has expired. With this option enabled, the updates are always deployable, as long as the updates were signed during the valid lifetime of the signing certificate. If this option is not chosen, updates signed by an expired certificate cannot be deployed.

Check for New Catalog Alerts on Startup: This option enables alerts on console startup to notify you of updated update catalogs. When enabled, the startup of SCUP is delayed for a small amount of time, which can make it look like SCUP is hung.

Enable Certificate Revocation Checking for Digitally Signed Catalog Files: This option verifies that the certificates used to sign imported update catalogs have not been revoked.

Always Check the My DocumentsLocalSourcePublishing Folder for Software Update Content Before Attempting to Download from the Specified Download URL: Using this option enables you to manually download content referenced in update catalogs instead of SCUP automatically downloading the content. This option is useful for SCUP consoles that are not connected to the Internet.

Use a Custom Local Source Path: Use this option to specify a custom local path for manually downloaded content.

Software Update Cleanup Wizard: This option launches a wizard that searches for updates published in ConfigMgr that are not in the default WSUS catalog or the SCUP repository. These are updates previously published by SCUP that were deleted from SCUP and thus orphaned in ConfigMgr. If any updates meeting these criteria are found, you can select them to be cleaned up. Cleaning up an update expires it in ConfigMgr, making it no longer deployable. This operation is irreversible and should be performed only on updates that are no longer needed.

Third-party vendors can use SCUP to create update catalogs for their own products and then make these catalogs available to you for direct import and use in ConfigMgr using SCUP. There are two types of catalogs: those from Microsoft partners and directly listed in SCUP and those from other sources.

Directly import catalogs from Microsoft partners in the SCUP console by going to the Catalogs workspace and choosing Add Catalogs from the ribbon bar to launch the Add Partners Software Updates Catalogs dialog, which lists available catalogs that you can pick for import into SCUP. The list of catalogs also includes download URLs, support URLs, and descriptions. Importing a catalog into SCUP is not the same as actually publishing the updates into ConfigMgr, so this step is harmless and reversible with respect to ConfigMgr.

Catalogs from other sources can be some of the following:

Commercial catalogs for third-party products

Community catalogs

Your own organization’s internal catalogs

To import one of these types of catalogs, navigate to the Catalogs workspace and click Add on the ribbon bar to launch the Add Software Update Catalog Wizard, where you input five pieces of information:

Catalog Path: The path to the CAB file containing the catalog. This can be a local path, a UNC, or a URL.

Publisher: The name of the publisher of the catalog. You can use the name entered here to sort and filter updates in the SCUP console as well as the ConfigMgr console.

Name: The name of the catalog.

Description: An applicable description for the catalog.

Support URL: A URL where support information for the catalog can be accessed.

After adding a catalog to SCUP, you must import the updates in that catalog into SCUP to use them. Select or multi-select the update catalogs listed in the Catalogs workspace and choose Import from the ribbon bar or from the right-click context-menu to launch the Import Software Updates Catalog Wizard. There are no real options in this wizard except selecting additional or deselecting chosen catalogs for import.

During the update import process, you may be presented with a Security Warning dialog asking you to accept content from the publisher. Choosing Always Accept content from the publisher trusts the publisher and accepts all future content from that publisher. You can view or remove the code signing certificate from that publisher in the Trusted Publishers page of the Options dialog.

Also available from the Catalogs workspace are options to edit and remove a catalog from the ribbon bar or from the right-click context menus of the catalogs. You cannot edit a vendor-signed catalog; selecting Edit displays a dialog box with read-only information about the catalog. Removing a catalog does not remove the updates imported from that catalog.

View existing publications from the Publications workspace in the console. To create a publication, choose the Publication tab in the ribbon bar and choose Create. You can also create publications from selected updates in the Updates workspace by selecting updates and choosing Assign or Publish from the ribbon bar or from the right-click context menu.

Existing publications are listed in the navigation list box on the left; this is a simple list rather than a tree, as there is no hierarchy with publications. Selecting a publication displays the list of updates it contains. Additional options available from the Home tab of the ribbon bar for a selected publication include the following:

Export: This option exports all of the selected publication’s updates to a catalog in the form of a CAB file that you can provide to other SCUP users.

Publish: This option publishes the selected publication’s updates into ConfigMgr, making them available for compliance scanning or installation, depending on publication type.

Automatic: Use this option to allow SCUP to query ConfigMgr to determine whether the selected software update or software update bundle is published with full content or only metadata. In this mode, software updates are published only when meeting the client request count and package size thresholds specified on the ConfigMgr Server page of the Options dialog box. Automatic mode is available only if ConfigMgr integration is selected in the SCUP configurations options.

Full Content: Use this option when you are sure that you want to deploy the software update by using ConfigMgr. When selected, SCUP publishes the binary of the software update and the metadata of the software update.

Metadata Only: Use this option when you only want to gather compliance information for software updates. When selected, SCUP publishes only the definition of the software update but does not publish the software update binaries.

Remove: Use this option to remove the software update(s) from the publication.

The following options are available on the Publication tab of the ribbon bar for a select publication:

Create: Use this option to create a new blank publication.

Edit: Displays a simple dialog box where you can change the name of a publication.

Delete: Deletes the selected publication.

Once you publish information into WSUS, you may find it takes two ConfigMgr synchronization cycles before your update appears in the ConfigMgr console. For example, say you have published a group of Adobe Reader updates to WSUS. When ConfigMgr synchronizes with WSUS, it learns that a new product is available. That new product appears under the Products tab of the top-level site’s SUP properties. Figure 15.30 shows the list with the new product in it.

FIGURE 15.30 SCUP product added to a list.

You must check the box under the Adobe product list that so that on the next synchronization of ConfigMgr with WSUS, the product is added to the list of software updates that it synchronizes. If you don’t check the box, your SCUP-published software updates will not appear in the ConfigMgr console.

The Details pane at the bottom displays detailed information about the selected update from the update list. If you select multiple updates, information from the first update selected is displayed in the pane.

For each update, you can choose one of several different operations from the ribbon bar or the update’s right-click context menu; most of these operations are valid and available when multiple updates are selected. The options follow:

Create: This allows you to create a custom software update or custom software update bundle. In-depth information about creating these items can be found in the “Using SCUP Custom Updates” section, later in this chapter.

Import: This item allows you to import one or more catalogs listed in the My Catalogs section into SCUP. It also allows you to import a custom catalog by providing the full path to the cab file.

Edit: This option, also accessible by double-clicking any update, displays the Edit Software Update Wizard, where you can edit all aspects of the update. A detailed description of the many options available in this wizard is provided in the “Using SCUP Custom Updates” section, later in this chapter. The authors do not recommend modifying any updates from third-party vendors; if you must modify one, make a copy of the update and then change the copy, leaving the original intact.

Assign: This option adds an update or update bundle to an existing publication or a new publication. Adding an update to a publication does not publish it to ConfigMgr.

Duplicate: As its name implies, this option creates an exact replica of an update; the new update’s name is prefixed with Copy of. Use this option to create a copy of a third-party vendor update so that you can edit the update, if needed.

View XML: This option shows the raw XML that defines an update. It is sometimes useful to see raw XML for updates to view hidden options and identifiers not displayed in SCUP or ConfigMgr. Another benefit of this option is that you can review all the rules associated with an update.

Delete: This option deletes an update from SCUP. If the update is published into ConfigMgr, this orphans the update and makes it unmanageable. Use the Software Update Cleanup Wizard to clean up orphaned updates. This option is not recommended for updates in a catalog supplied by a third-party vendor; rather, the vendor should do this cleanup for its catalog.

Export: This option exports the selected updates to a catalog in the form of a CAB file that you can provide to other SCUP users.

Publish: This option publishes an update directly to ConfigMgr, using one of the three publication types. Note that the update is not placed into a publication.

Expire: This option expires updates so they can no longer be deployed by ConfigMgr. Once published to the SUP, it is irreversible, and your only course of action is to create a new update, possibly using the Duplicate option, if the update is still needed.

Reactivate: This option reactivates updates expired in SCUP that have not been published to ConfigMgr. Some vendors include expired updates in their catalogs so you can use them if the newer updates have not yet been approved for use in your organization. In this case, use this option to reactivate and then publish them. As mentioned with the Expire option, once an update is published as Expired to the SUP, it cannot be reactivated, so you must reactivate an update before initially publishing it.

Updates must be published either directly using the Publish option from the All Software Updates list in the Updates workspace or the Publish option available in the Publications workspace. Adding an update to a publication does not publish the update in ConfigMgr.

Updates can exist in multiple publications or none at all, but they are published only once to ConfigMgr, if at all. Every occurrence of an update in a publication or the All Software Updates list shares the same publication type and date.

1. Select the All Software Updates node and choose Create Vendor from the right-click context menu or choose the Folders tab and select Create -> Vendor from the dropdown menu. Enter the vendor name in the resulting dialog box.

2. Select the new vendor folder you just created and choose Create Product from the right-click context menu or choose the Folders tab and select Create -> Product from the dropdown menu. Enter the product name in the resulting dialog box.

Alternatively, you can use an existing vendor or product folder; vendor folders may contain multiple product folders, and products may contain multiple updates. Updates are displayed in the Updates view on the right when a product folder is selected in the navigation tree.

Delete and Edit options are available from the right-click context menu of a selected vendor or product folder and the ribbon bar; Edit shows a dialog box, where you can rename the folder.

After creating your vendor and product names, you are ready to proceed with creating your custom updates. Updates must be one of the following file types:

Windows executable (.exe)

Microsoft Installer file (.msi)

Microsoft Installer Patch file (.msp)

Windows Update (.msu) files are not directly supported because WSUS does not support them by design; they are typically associated with hotfixes that are not really intended for mass distribution. If you find that you need to use an MSU file, a workaround is explained in depth at https://blogs.technet.microsoft.com/dominikheinz/2011/10/17/deploying-custom-msu-updates-with-sccm-and-scup.

To create a new custom software update, choose Create from the Home tab of the ribbon bar and then select Software Update from the resulting dropdown. You do not have to select any specific node or node type in the navigation tree for this option to work. This launches the Create Software Update Wizard, which has 10 pages; 7 of the pages require information to be entered, and the last 3 are the standard Summary, Progress, and Confirmation pages. The following are the 7 pages where you need to enter information:

Package Information: This page contains the following information about the update package you are creating:

Package Source: This is the location of the actual update file and must be a valid type previously listed in this section. This file is used only as a point of reference and to establish a filename; it is not actually captured or placed in the update.

Use a Local Source to Publish Software Update Content: If selected, this option designates that the content source used by ConfigMgr to download the actual software update file specified in the Package source option is a local folder rather than a location specified by the next option. The local folder is the current logged-in user’s DocumentsLocalSourcePublishing folder by default, but this is configurable on the Advanced page of the Options dialog. This option is useful when creating updates for your own internal use and the SCUP console is installed on your site server.

Download URL (or UNC): This field specifies the content source location used by ConfigMgr to download the update file specified in the Package source option. If the previous option is selected, this field is grayed out and is not fillable.

Binary Language: This is the language of the update file specified in the Package source field. It usually is listed as Language Neutral. If using a different language, choose the correct language to use from the dropdown.

Success Return Codes: Codes are returned from the update installation file upon a successful installation. A typical success return code is 0, but this may vary; manually test the update or consult the documentation of the vendor that created the update file to ensure that you have accounted for all valid success return codes.

Success Pending Reboot Codes: Similar to the Success return codes, these codes are returned from a successful update installation that requires a reboot. This code is usually 3010. Updates should never reboot the system on their own.

Command Line: This is the actual command line options and properties used to run the update on a target system. The specified options should suppress reboots and all user interaction, and they should be fully automated. Consult the vendor’s documentation for information on how to achieve this and then verify by manually testing the complete command line. Do not include the update filename in this field; include only the options or properties. For MSIs and MSPs, the proper options to make them silent and unattended are added automatically and should not be specified.

If the package source is an MSI or MSP, these last four fields are automatically populated, as the values are standard or extractable from the source file.

Required Information: This information defines the metadata published into WSUS, displayed in the ConfigMgr console, and used by ConfigMgr to determine if the update should be included in the catalog, including the following:

Language

Title

Description

Classification

Vendor

Product

More Info URL

Optional Information: Additional metadata is specified on this page. This information is displayed in the ConfigMgr console and can be used for filtering and sorting in the console but is not directly used by ConfigMgr. Each field’s definition is subjective, and you can define each for your own needs. Fields on this page include the following:

Bulletin ID

Article ID

CVE IDs

Support URL

Severity

Impact

Restart behavior

Prerequisites: On this page, define the prerequisites that must already be in place on a target system for an update to be scanned for compliance. Valid prerequisites include other updates from SCUP and detectoids. Detectoids are high-level rules that the WUA can evaluate quickly. You can choose from a set of well-known WSUS detectoids but cannot create your own in SCUP. There are two groups of well-known WSUS detectoids: CPU Architecture and OS language.

Superseded Updates: On this page, select which updates, if any, are superseded by this new update. You can only choose updates in SCUP.

Installable Rules: This page defines the update applicability rules; these rules are used by the WUA to scan the local system and determine if it requires the update. You combine rules on this page by using typical Boolean logic constructs such as AND, OR, and NOT. For a brief discussion of rules, see the next section, “Using SCUP Rules.” Using prerequisites is preferred to using installable rules when possible, as prerequisites are essentially pre-evaluated and thus incur very little overhead.

Installed Rules: Similar to installable rules, these rules define how the WUA verifies that the update is installed. In some cases, these rules may be identical to the installable rules; this is perfectly valid. Ensure that these rules evaluate to True after the software update is installed; otherwise, you can end up in a loop when software updates evaluation runs.

In addition to doing individual updates, you can create software update bundles. Although not very common, software update bundles ensure that specific software updates are deployed at the same time. The WUA handles software update bundles very much like it handles software updates.

Create a software update bundle by selecting Create from the Home tab of the ribbon bar and then selecting Software Update Bundle from the resulting dropdown. You do not have to select any specific node or node type in the navigation tree for this option to work. This launches the Create Software Update Bundle Wizard, whose pages are mostly identical to those in the Create Software Updates Wizard, with the exception of the following:

Optional Information: This page only differs because of the lack of the Impact and Restart behavior options.

Bundle Updates: This page allows you to select the updates you wish to include in the bundle. You can choose from any updates inside SCUP.

The Rules workspace lists all previously saved rules. Just because a rule is used by an update does not mean it is saved. You must explicitly save a rule before it appears in this workspace; there are no default saved rules in SCUP.

Use the Rules workspace to construct and save reusable rules for use with the installable and installed rule definitions in updates. You can also create rules directly in the Software Update Wizard on the Installable Rules and Installed Rules pages by using the small disk icon. To load a previously saved rule on these pages, click the yellow starburst icon and choose Saved Rule from the Rule type dropdown.

You can create four different rule types:

File

Registry

System

Windows Installer

Each rule type is self-explanatory to configure and not covered in depth here. However, because they are nearly identical to the rules used in compliance settings, you can reference Chapter 10, “Managing Compliance,” for detailed explanations.

SCUP provides a method to patch your third-party products and any homegrown applications your organization may have created. Wrap all this together, and you have a tool that provides the comfort of safely delivering software updates, Windows 10 core updates, and third-party updates with the ability to customize your settings and have a user-friendly experience.

The next chapter explains how you can integrate Intune with ConfigMgr to provide hybrid management of on-premise and mobile devices using a single console.