RPS Patch Management Workflow

Last updated on April 21, 2021.

Last Reviewed and Approved on PENDING REVIEW

The RPS patch management workflow is described in 19 steps, in the following figure:

Figure 1: RPS Patch Management Workflow.

Patch Workflow

The workflow begins at the parent node, from users, who build package streams and packages using the RPS website or PowerShell.

1. Patch and folder-to-target resource assignments are made by approving a Patch Stream, stored as resource assignments in the RPS Configuration Management Database (CMDB).

2. RPS Sync service: This windows service (Sync service) detects an updated resource assignment in the CMDB.

3. The Sync/CDN Services work to transmit resource assignments to RPS child nodes.

4. The Child Node RPS server windows Sync Service updates the local CMDB with new resource assignments.

5. Clients (that run RPS services including the DSC) query a child node's CMDB and register its Target Item ID in the database.

6. Child node REST endpoints query the CMDB for all resource assignments of type Package for the specified Target ID.

7. CMDB: Returns requested Resource Assignment objects to the REST endpoint.

8. Child nodes return a list of patch name/version, ensure states, and deploy attempt counters to the RPS Client.

9. Client then sends a request for specific metadata to the REST endpoint.

10. REST endpoints provide metadata to clients and clients perform a state check.

11. Clients request missing patches needed to reach the desired state and also requests maintenance windows pertinent to the client.

12. Child node REST endpoints provide patches and maintenance windows to the client.

13. If target is within the Maintenance Window, then the patch is deployed to the Target.

14. Clients send state reports to the REST endpoint.

15. REST endpoints update resource assignment's states (InDesiredState, DeployedOn, PackageIsInMaintenanceWindow, DeployedStatus) based on received report data.

16. Child Node Sync services detect the updates occurring in the CMDB.

17. Updates are detected by the parent node Sync service.

18. Parent node CMDB is updated.

19. GUI telemetry data is updated for each package and target.

RPS Components

RPS is similar to systems management suites in that it has a parent-child infrastructure of RPS servers, databases, and Windows services. In this way, target clients that need software packages communicate with locally or geographically distributed RPS child servers, who in turn communicate with RPS parent node servers. RPS users who build packages interact with the Parent Node website user interface (or PowerShell) and child nodes are updated automatically. Clients register with RPS, scan for needed updates, and RPS provides needed packages to each target client for install, via maintenance window.

RPS Servers: Parent node RPS servers and child node RPS servers that communicate with each other primarily with the RPS Sync and CDN (Content Delivery Network) services. Child node RPS servers have a REST API endpoint listening for RPS clients that need to communicate with the child CMDB.

CMDB Configuration Management Database: A parent/child set of databases that run on RPS parent and child servers, a sort of "brain" for RPS.

Child Node: Child RPS servers communicate with RPS parent servers for packages and resource assignments, as well as with clients via REST API endpoint.

Client: Target endpoint Windows computers or other devices that need RPS packages.

DSC Desired State Configuration: a service running on RPS clients (targets) that can scan, query, and remediate to the desired configuration, via RPS users from the parent node.

Resource Assignment: The method that RPS uses to assign the packages to RPS-registered clients (targets).

Target ID: A unique identifier of the RPS registered computer client or endpoint.

Sync Service: A windows service running on RPS servers that communicates with other sync services and the CMDB.