Patch management, custom sites and performance

(imported topic written by F6D8_Nate_Marks)

I manage patches for a bunch of different organizations who are in turn supported by a bunch of engineering resources. I’d like to have a baseline for each organization so that compliance reports are easy to figure out for the engineering resources who have fairly narrow interaction with TEM. The problem is that it would create a LOT of duplicate baselines. I think I can mitigate that by having a custom site for each organization, subscribing the org’s machines to their custom site and placing the baselines there. That seems obvious enough.

  1. Is that correct

  2. I can’t seem to create groups or actions in the custom site. they just get created in the operators site Am I doing something wrong?

If that’s the way its supposed to work, I’m ok with it because it seems to meet the primary need which is separate access to the baselines. It just seems a little counter-intuitive from a user standpoint.

(imported comment written by BenKus)

Hi Nate,

Yes… If different organizations need different baselines, then Custom Sites are probably the way to go. The downside is the maintenance if you want to make a change to all the baselines… In general, the agent performance is likely going to be fine because even though you have many baselines, it is unlikely to have many agents subscribed to many of the custom sites, correct?

You can consider using the

BigFix APIs

with simple scripting to try to automate some tasks…

For question #2, custom sites only contain baselines, fixlets, tasks, etc. and can’t contain actions (the actionsite and opsites are used for actions).

Ben