JetPatch uses Windows Server Update Services (WSUS) for patching Windows endpoints. A few benefits with using WSUS:
- Bandwidth is a major factor as downloading updates from the internet can be bandwidth-consuming.
- Supporting environment without internet connectivity - servers that are not connected to the internet should get their updates from a local source.
- Can be extended in order to distribute patches for third-party applications like Chrome and Java.
|WSUS||Local CAB file||Direct to Windows Update Catalog|
|Bandwith into the organization||LOW||LOW||HIGH|
|Bandwith to Endpoint||LOW||HIGH||LOW|
|No internet connectivity support||YES||YES||NO|
|Third-party applications support||YES||NO||
|Centralized approval system||YES||NO||
|Supported Products and Classifications||All (link)||Only Security Updates, Service Packs, Update Rollups||
JetPatch Interaction With WSUS
Note - WSUS must be configured as a Discovery Source for JetPatch to pull all the information above. (endpoints can be discovered in many different ways).
The first thing JetPatch is doing with WSUS is to pull data on the environment:
- Computers & Computer Groups - List of the endpoints and the computer group they are within. Only endpoints that are communicating with WSUS are applicable for patch activities. JetPatch will convert the Computer Groups to patching groups and will keep the association of the endpoints (if they are already assigned to groups).
- Patches Information - For any patch that is available in the WSUS (based on the Products and updates Classifications configured) JetPatch will pull the title, KB ID, operating systems, superseded, and more.
Note - JetPatch pulls the metadata only and not the binaries if they exist on the WSUS server.
- Patches Status - The understanding of which patches are needed on which endpoints with their status (already installed or needed).
- Environment Information - It includes the WSUS configuration and Replicas/Downstreams if exist.
Some of the information above is consistently pulled via JetPatch in the ongoing.
After activation of a Remediation Plan, JetPatch will change the approval of the selected patches on the selected groups in WSUS.
There are a few types of approvals:
- Install - Approval for Install
- Remove - Approval for Remove
- Decline - Update is removed from the default list of available updates. This operation affects all of the groups regardless of the chosen groups.
Note - If ITSM is configured, JetPatch will approve the patch in WSUS only after change request approval.
When it is time for updating the endpoint, (based on each endpoint Maintenance Schedule) JetPatch application will send the needed commands and information to the JetPatch agent (Connector) which will operate the Windows Update Agent for his need.
Connector actions via Windows Update Agent:
- Check for updates
- Download updates
- Install/remove updates
When done, Connector will send the result to JetPatch (JetPatch does not need to wait for patch installation approval from WSUS)
There are two types of WSUS -
- Main WSUS - WSUS will manage all of the update approvals, settings computers, and groups for the computers that are connected to it.
- Replica WSUS - A replica server mirrors update approvals, settings computers, and groups from its parent (usually Main WSUS). Updates can be approved only on the upstream server. For endpoints that are connected to a Replica WSUS configured for manual groups assignment (see below) - the group assignment must be done in the Replica WSUS.
In some scenarios, WSUS (Downstream) can also synchronize with another WSUS (Upstream) for only pulling the updated information. More information can be found here.
There are many configurations ("Options") to apply to the WSUS. The most important settings are:
- Update Source and Proxy Server - You can choose the Upstream server from which your server synchronizes updates and the proxy to use if needed.
- Products and Classifications - Most Microsoft updates are published on the WSUS and it's important to specify which products (categories) you would like to patch as well as the classifications
- Update Files and Languages - You can specify where to store update files. Storing files locally requires sufficient disk space. More information can be found in Update Files
- Synchronization Schedule - You can synchronize updates manually or set a schedule for daily automatic synchronization.
- Computers - You can specify how to assign computers to groups. This can be done via manual assignment in the WSUS server (Server-Side Targeting) or by specifying a registry setting on the endpoints (Client-Side Targeting). More information can be found in Assigning Endpoints to Groups in WSUS
In the WSUS options, you can select how the update files will be stored and how they will be downloaded to the endpoint.
There are two main options:
- Store update files locally on this server - "Download update files to this server only when updates are approved". After patch approved, the WSUS will download the update files. Endpoints in the environment will download the update from the managed WSUS.
This option is good when:
- In-prem architectures : When the endpoints do not have direct access to the Microsoft Update Center over the internet
- You prefer internal bandwidth, between the endpoints to the WSUS.
- Do not store update files locally; computers install from Microsoft Update - If WSUS is configured with this option the following should happen: After patch approval, the endpoints will receive an indication of which patches should be installed from the WSUS. However, the files themselves will be downloaded directly from the Microsoft Update Center over the internet.
This option is good for On-Cloud architecture (or in cases your environment is mostly 'Work-From-Home') and the endpoints can use their own internet access and bandwidth, without the need to make more traffic between the WSUS to the computers. You can find the instruction in Configure WSUS to Make the Endpoints Download the Patches Directly from MSFT article
Note - for downstream WSUS only, there is another option of storing the update files locally on the server but they will be downloaded from the Microsoft Update and not from the upstream WSUS.
One of the common architectures for WSUS management in an organization is to have a single Primary WSUS located in the main site and multiple Replicas (downstream) for each secondary site.
In a Primary-Replica architecture, the Computer Groups are managed only from the Primary WSUS. The Computer Groups are synced with all the Replicas every time a Replica is synchronized with the Primary.
Although the Computer Groups are managed by the Primary WSUS, the Computer assignments for the Computer Groups are managed by the Replica WSUS*
After changing the Computer assignment it can take some time for the change to appear in the Primary WSUS. You can follow this guide to make it happen as soon as possible,
* Only if the Replica is configured for a Server-Side Targeting.