Merge software update

The client randomly selects a software update point from the list. It prioritizes the software update points in the same forest. Configuration Manager provides clients with a different list depending on the type of client:. Intranet-based clients : Receive a list of software update points that you can configure to allow connections only from the intranet, or a list of software update points that allow internet and intranet client connections.

Internet-based clients : Receive a list of software update points that you configure to allow connections only from the internet, or a list of software update points that allow internet and intranet client connections. Clients use boundary groups to find a new software update point. If their current software update point is no longer accessible, they also use boundary groups to fallback and find a new one. Add individual software update points to different boundary groups to control which servers a client can find.

For more information, see Software update points. If you have multiple software update points at a site, and one fails or becomes unavailable, clients will connect to a different software update point. With this new server, clients continue to scan for the latest software updates. When a client is first assigned a software update point, it stays assigned to that software update point unless it fails to scan.

The scan for software updates can fail with a number of different retry and non-retry error codes. When the scan fails with a retry error code, the client starts a retry process to scan for the software updates on the software update point. The high-level conditions that result in a retry error code are typically because the WSUS server is unavailable or because it is temporarily overloaded. When the client fails to scan for software updates, it uses the following process:.

If the scan fails, the client waits 30 minutes to retry the scan. It uses the same software update point. The client retries a minimum of four times every 30 minutes. After the fourth failure, and after it waits an additional two minutes, the client moves to the next software update point in its list. The client repeats this process with the new software update point.

After a successful scan, the client continues to connect to the new software update point. The following list provides additional information to consider for software update point retry and switching scenarios:.

If a client is disconnected from the intranet and fails to scan for software updates, it doesn't switch to another software update point. This failure is expected, because the client can't reach the internal network or a software update point that allows connections from the intranet.

The Configuration Manager client determines the availability of the intranet software update point. If you're managing clients on the internet, and have configured multiple software update points to accept communication from clients on the internet, the switching process follows the standard retry process previously described.

If the scan process starts, but the client is turned off before the scan completes, it isn't considered a scan failure and it doesn't count as one of the four retries. When Configuration Manager receives any of the following Windows Update Agent error codes, the client retries the connection:. To look up the meaning of an error code, convert the decimal error code to hexadecimal, and then search for the hexadecimal value on a site such as the Windows Update Agent - Error Codes Wiki. Switch Configuration Manager clients to a new software update point when there are issues with the active software update point.

This change only happens when a client receives multiple software update points from a management point. When you switch devices to use a new server, the devices use fallback to find that new server. Clients switch to the new software update point during their next software updates scan cycle.

Before you start this change, review your boundary group configurations to make sure that your software update points are in the correct boundary groups. Switching to a new software update point generates additional network traffic.

The amount of traffic depends on your WSUS configuration settings, for example, the synchronized classifications and products, or use of a shared WSUS database. If you plan to switch multiple devices, consider doing so during maintenance windows.

This timing reduces the impact to your network when clients scan with the new software update point. Start this change on a device collection. Once triggered, the clients look for another software update point at the next scan.

In the Configuration Manager console, go to the Assets and Compliance workspace, and select the Device Collections node. Select the target collection. Create one or more software update points at a site to support clients in an untrusted forest.

To add a software update point in another forest, first install and configure a WSUS server in that forest. Then start the wizard to add a Configuration Manager site server with the software update point site system role. In the wizard, configure the following settings to successfully connect to WSUS in the untrusted forest:. When switching to the next software update point, the clients prioritize the servers from the same forest.

Typically, the top-level site in your hierarchy is configured to synchronize software updates metadata with Microsoft Update. When your organizational security policy doesn't allow the top-level site to access to the internet, configure the synchronization source for the top-level site to use an existing WSUS server.

For example, you have a WSUS server in an internet-connected network DMZ , but your top-level site is in an internal network without internet access. Otherwise, the top-level site might not synchronize the software updates that you expect. When you install the software update point, configure a WSUS server connection account. Also confirm that the firewall permits traffic for the appropriate ports.

For more information, see the ports used by the software update point to the synchronization source. The software update point is optional on a secondary site. Install only one software update point at a secondary site. When a software update point isn't installed at the secondary site, devices within the boundaries of a secondary site use a software update point at their assigned primary site.

You typically install a software update point at a secondary site when there's limited network bandwidth between the devices in the secondary site and the software update points at the parent primary site. You may also use this configuration when the software update point at the primary site approaches the capacity limit. After you successfully install and configure a software update point at the secondary site, a site-wide policy is updated for clients, and they start to use the new software update point.

When you need to manage devices that roam off your network onto the internet, develop a plan for how to manage software updates on these devices. Configuration Manager supports several technologies for this scenario.

Use one or a combination as necessary to meet the requirements of your organization. Create a cloud management gateway in Microsoft Azure and enable at least one on-premises software update point to allow traffic from internet-based clients. As clients roam onto the internet, they continue to scan against your software update points.

All internet-based clients always get content from the Microsoft Update cloud service. For more information, see Overview of cloud management gateway and Configure boundary groups. Place a software update point in an internet-facing network and enable it to allow traffic from internet-based clients. As clients roam onto the internet, they switch to this software update point for scanning. For more information on the advantages and disadvantages of internet-based client management, see Manage clients on the internet.

Windows Update for Business allows you to keep Windows 10 or later devices always up-to-date with the latest quality and feature updates. These devices connect directly to the Windows Update cloud service.

For more information, see Integration with Windows Update for Business. Clients need to download the content files for software updates in order to install them. Configuration Manager provides several technologies to support management and delivery of this content.

Or configure software update deployments to allow or require clients to get content directly from the Microsoft Update cloud service. By default, the software update management process in Configuration Manager uses the built-in content management features.

These features include the centralized, single-instance store content library, and the distributed design of the distribution point site system role. You use these features when you download and distribute software update deployment packages. For more information, see Download software updates.

Configuration Manager supports the use of express installation files for Windows updates. Express update files and supporting technologies such as Delivery Optimization can help reduce the network impact of large content files downloading to clients. For more information, see Optimize Windows update delivery.

When you deploy software updates to clients, configure the deployment for clients to download content from the Microsoft Update cloud service. When clients aren't able to download content from another content source, they can still download the content from the internet. You don't have to create a deployment package when deploying software updates.

When you select the No deployment package option, clients can still download content from local sources if available, but typically download from the Microsoft Update service. Internet-based clients always download content from the Microsoft Update cloud service. Don't distribute software update deployment packages to a content-enabled cloud management gateway CMG. Most customers use other third-party applications that also need updates. There are several options to consider for keeping third-party applications up to date.

Use a supersedence relationship with the application management feature in Configuration Manager to upgrade or replace existing applications. When you supersede an application, specify a new deployment type to replace the deployment type of the superseded application.

Also decide whether to upgrade or uninstall the superseded application before the superseding application is installed. For more information, see Revise and supersede applications. You can use the Third-Party Software Update Catalogs node in the Configuration Manager console to subscribe to third-party catalogs, publish their updates to your software update point, and then deploy them to clients. For more information, see Third-party software updates. System Center Updates Publisher SCUP is a stand-alone tool that enables independent software vendors or line-of-business application developers to manage custom updates.

These updates include those with dependencies, like drivers and update bundles. SCUP can also be used for third-party update catalogs that aren't available directly in the console. For more information, see System Center Updates Publisher. This section provides information about the steps to take to successfully plan and prepare for the software update point installation. Before you create a site system role for the software update point in Configuration Manager, there are several requirements to consider.

The specific requirements depend on your Configuration Manager infrastructure. SInce package deployments will likely contain more than just software updates, trying to use the status that returns as a success or failure in a report will require filtering to just focus on the software updates. There also is the option to scan the system for the presence of the deployed update and report back. Again, several ways we could do that — script, file system, Compliance Settings and more.

This WMI class is specifically designed to reflect the presence of all system-wide updates deployed. We also have an added advantage that this class specifically excludes any update supplied by Windows Update - so the result set we get from this WMI class comes pre-filtered with just the supplemental data we want. OK, good. So now that this information is here, how do we collect it?

To do this, modify the client settings. I have chosen to enable everything. At this stage, wait a few minutes and then force a policy cycle on a test client machine. Wait a couple of minutes again and then force a Hardware Inventory cycle. Once the updated hardware inventory reports up you can see the addition of Quick Fix Engineering data by going to a machine in a collection, right-clicking and selecting Start-Resource Explorer.

To build our report we need to have three items. A SQL query to pull our newly collected data. An idea of a report we either want to build or one we want to modify. Report Builder 2. The query is often the most intimidating part of the reporting process — especially for SQL neophytes. The query I use to pull the data is below.

A quick note here, always build your queries using the SQL views. Doing so is easier and is the supported avenue for building reports. The answer is the inclusion of a variable RscID in the query. The variable is necessary to snap into the existing report I will modify — and the variable is declared in the report as you will soon see.

If you wanted to run this directly in SQL you would either need to explicitly declare a value instead of a variable or declare the variable and supply a value. Next we need a report that we want to modify. Remember, the goal is to list all patches deployed to a computer, whether deployed by Software Updates our by Software Distribution. Lets take a look at the standard report. With Report Builder it is possible to build very basic to very complex reports from the ground up or by modifying existing reports — the choice is yours.

In this example we will modify this standard report. What are Parameters? Think back to when you ran your last report. Likely when you launched the report you first had to fill in some information before viewing. In the case of this report we are required to supply the target computer name remember, this is a report that pulls all update for a given system and optionally can supply the Vendor name or Update Classification.

Note that the MachineID parameter is highlighted. This is the parameter that is used to reflect the machine ID that you chose. The list of parameters presented to you is populated by SQL queries that are stored in the DataSets of the report - and the choice you make is stored in the actual Parameter value. So, parameters first collect data that is used to feed the main SQL query also a DataSet — remember that as we will come back to it shortly.

In addition to Parameters we have a Data Source. You must have at least one but could have multiple. A single data source is typical for ConfingMgr reports. The Data Source simply defines what database we want to use for pulling data, where it is located and how to connect. As in this case, a single Data Source can be shared across multiple DataSets. Finally, we have the DataSets. A given report requires at least one DataSet or could have several.

So once I have compile all of the updates into 1 update package, i can still maintain my current multiple SUG correct? Meaning i dont have to recreate a new SUG once I have compile all of the updates into 1 update package correct? As far as the deployment package goes there isn't a limit of how many items can be in the package.

However, the only thing you need to watch our for there is that the bigger the package the longer it will take to distribute the content. Not knowing your DP situation I can't say if bandwidth might be an issue for you or not.

If you have large pipes between your sites and bandwidth is not an issue for you than package size shouldn't be an issue. Basically the system is flexible enough where you can set it up to handle updates in whatever way makes sense to you, outside of the items in a deployment caveat. For instance I have a separate SUG for each year and than I have a deployment package that corresponds to that year. That works for me, but to each his own. But if I checked the BDR option in the package, it should only distribute the updates correct?

Office Office Exchange Server. Not an IT pro? Resources for IT Professionals. Sign in. United States English. Ask a question. Quick access.

Search related threads. Remove From My Forums. Asked by:. Archived Forums. Configuration Manager Current Branch — General. Post questions here that are not appropriate for the other Configuration Manager specific forums, AND after you have already searched for your answer. Sign in to vote.