Separate Dev, Test & Prod as Automatic Groups Options

Usage and Config
1

Looking to use a custom field on computers to separate them into separate Dev, Test & Prod. Do I have to use the fields already there or can I create a field named something “Patching” with values I could use relevance with? Is that possible? Any ideas?

2

Many organizations use distinct hostnames to indicate environment (Dev/Test/Prod). You can leverage that convention to build automatic groups.

If hostnames aren’t reliable, identify another consistent attribute (e.g., subnet, tag, or owner field) that differentiates Dev, Test, and Prod and group on that.

As a fallback, set a client setting on those devices (e.g., Environment=Dev|Test|Prod) and use it to drive automatic group membership.

1 Like
3

What we do is pull data related to the device from our CMDB and then use that to create custom client settings that contain patching related data. For example patch tier (dev, non-prod, prod), patch day, patch region, etc. Then we have automatic groups that use those fields to determine membership.

We have a policy that creates these custom client settings once a device starts reporting to BigFix.

For example:
Relevance: not exists setting "_PatchTier" of client
Action: setting "_PatchTier"="" on "{now}" for client

4

We do the exact same thing.

Apply a client setting to every computer/server as a policy (action reapplying daily from a site level JSON file we import). We then have the Environment, and can target deployments as needed. In the event the computer/server is not tagged, we default to Production so that we ensure no computer/servers are missed for a deployment.

5

That does sound like a good solution! How do you exactly “set a client setting”? Like where do I go to ‘set’ the field name and value?

6

Setting the client setting manually is easy, just a right mouseclick on the computer, Edit settings, and add a new key/value pair.

From the client setting you need to create a property.

Assuming you have more than a fistful of computers it makes sense to automate this task.

There a several ways to get the data from cmdb into BigFix (maybe you want more information, like the responsible guy for the server, maintenance windows etc.).

  1. if the data is available on the server, eg. in a txt oder csv file you can create the property by using the data in the file
  2. Use the BigFix API: BigFix REST API Tutorial | BigFix Developer
  3. if the data is readable from computer name like @vk.khurava mentioned it’s also a good idea

I would strongly recommend to run intensive test, espicially for 2. on a dedicated BigFix Test server to avoid unwanted influence on production systems.