Patching sensitive, business-critical production assets

How to utilize Asset Groups and Patching Automation to apply patches to your Dev/Test environment, then apply those same patches to your production environment.


To patch sensitive, business-critical production assets safely and effectively. Maintain the CIA triad by maintaining uptime (availability) and reducing risk of exploit by applying security patches in a timely manner. Achieve all of this with the least amount of manual effort possible. In this guide, we will cover some nuances for achieving multiple common use cases or deployments which fall under this objective.

When to use this: When compared to the more “standard” patching cycles and automation schedules, this method offers an increased level of control which may be necessary for maintaining the uptime of critical production assets. Patch validation/testing workflows can also benefit from this procedure as you will have insight into the effects of a certain patch in your specific environment.

Setup phase:

Asset Groups

A necessary prerequisite to achieving the desired results we will cover in this guide is establishing relevant asset groups. These asset groups will be integral as they will allow us to target the different environments with separate policies not only making this process possible but also very streamlined and targeted.

To create an asset group we must first consider which data point we would like to group based off of. For many business-critical assets, this can commonly  be identified by one of the following:

  • AD Group 
  • Organizational Unit
  • Internal IP range/subnet
  • Certain application installed

All of these data points, and many more, are enumerated and available to group by in vRx right out of the box. If there is a non-standard identifier you would like to use to establish these groups, utilizing our endpoint tags is a great way to achieve this. Below is an outline of how to perform this in the dashboard:

  1. Navigate to the Assets view
  2. Select Create Group
  3. Name your group to something easily recognizable I.E.: Dev, Test, Prod, Current Patch group, N-1, etc.
  4. Select your data point for identifying the group I.E. AD Group, OU, IP, App, etc.
    Tip: The data point you select should be one that allows you to identify the desired assets. You can combine data points, do nested groups by calling an existing group as a filter, and use the funnel icon for a “not” operator - this will grab any asset which does not meet the criteria specified.

You can also reference this KB for a video overview of the process of creating an Asset Group.

Endpoint Tags

In cases where there is no relevant “out of the box” identifier for your assets you can utilize asset tags:

Apply Endpoint Tags at time of agent deployment

Apply Endpoint Tags after deployment / modify endpoint tags

Following the steps in the KBs linked above, you can apply an endpoint tag to an asset at various stages in the pre and post-deployment stages. This can allow you to group assets by criteria that may be proprietary or more difficult to quantify through another filter.

Tip: When creating groups, think about things like assets that share a common maintenance window, assets that share a common business function, or assets that are a part of the same patch cycle I.E. current patch or Current patch minus 1 to name a few.

Policy Phase


Now that we have our asset groups established it is time to set up our automation policies to deploy patches based on the rules and schedule that aligns with our organizational goals. To do this in a way that achieves the objectives described earlier in this document, we will be mostly focused on the automation component of vRx at this stage.

Creating our first policy

  1. Navigate to “Automation” on the left-hand pop-out pane and then click on create new automation. You will need to select an action type to start the automation wizard. For today’s example, we will focus on OS patches but the same concept will apply to Apps as well as OS and Apps in the same Auto-Action.
  2. Next, name your automation policy to something you can easily recognize, this will help with logging and ease of management later on.
  3. Select the target OS(es) and then click next

  1. Now in the update settings, select “Update by Available Updates”. Here you will see a current list of available updates for your selected OS in your environment. 
  2. Select the relevant patches that you’d like to apply. This can be all current applicable patches, patches of a specific severity, or even selecting specific patches.
  3. Before proceeding, determine how you’d like to address patches that need a reboot. For OS patching it is recommended to use vRx’s Auto Reboot function as these patches are more likely to require the reboot.

  1. Next will be the group selection or the target of the policy. In this example, this will be the group you created earlier on in this procedure. Essentially, this first policy should be applied to your current patch group or your Dev/Test group.
  2. Finally, we have the schedule. Chose when you’d like to apply these patches. This should align with any maintenance windows or change/ patch management cycles you may have for your targeted assets.
  3. Once you have completed all of these steps, select Finish, review your selection, and once you are satisfied, select Activate.

Tying it all together

Logging, Testing, and Duplication

By now you should have some patches deployed to your “test” assets. You can easily track the status of patches in vRx in the Activity Log found under the Logs and Alerts folder of the left-hand pop-out pane. Once you have confirmed the patches have been applied to the test group and you have confirmed there are no issues caused by these patches, it’s time to apply them to your business-critical, production environment.

  1. Repeat the steps above to create an Asset Group for the N-1 or Prod assets
  2. Navigate to the Automation view and search for your dev/test automation

Tip: If you set this to run once you should find the automation policy under the “Finished” tab as it has likely completed. If you set it to recur, you should find it in the “Ready” section

  1. Click the 3 vertical dots on the right-hand side of the Automation bar and select “Duplicate”

  1. Rename the Automation to reflect the new target group
  2. Change the target Asset Group to the Production Asset Group
  3. Schedule the patches. Finish and Activate


So what happened here and what makes this approach different? Because we selected the specific patches we have complete control over what is and isn’t applied. 

Utilizing the Asset Groups in this manner allows us to target different areas of the environment, allowing us to do the testing required when applying patches to business-critical assets. 

Duplicating the Automation saves time and allows us to apply the exact same patches that were applied to the test group. Of course, if there happens to be some issue with a particular patch we can also remove that before applying it to the Production group.