Approve fixlets before releasing to administrators

(imported topic written by SY57_Jim_Montgomery)

My organization is just starting deployment with BigFix, and there seems to be a large number of choices with deployment. I’d like to get some feedback on this option that we heard of to see how we could possibly implement it.

Our organization is broken up into about 13 different entities, each with 1K to 7K computers. Let’s call them regions. My group centrally manages standard apps that all 13 regions use, such as BigFix (once its implemented). Each of the regions has its own administrators.

We have a process in place where new patches (MS or otherwise) are tested and approved for installation, after which admins must deploy it to their users. The installation is then reported on centrally to ensure compliance.

So, during a recent call with some BigFix sales techs, we heard that we could have all new patches be put into a specific site, until it was approved by our central administration team. After approval, the regional admins would then have access to deploy it on their respective computers.

How can this be configured? Please don’t say by globally hiding them until approved. :wink: We’re also considering just using one baseline for all computers with the “approved” patches, but I’m still curious how BigFix could accomplish this.

I appreciate any feedback. I couldn’t find anything like this scenario by searching.

(imported comment written by StacyLee)

The way I see this working is “yes” by globablly hiding them.

I am not sure your concern about this approach, but there are 2 ways this could work:

  1. The obvious one, fixlets are published you hide them then you unhide them. This would mean all your NMO would see the fixlets at the same time or they may see them before you get a chance to hide them.

  2. In the BES Admin tool (installed on your main server) under system options. You can change the default fixlet visibility from visible by default to globally hidden by default on sites gathered from external sites. This save the work of you remembering to do it when they become published. However I think this would mean for ALL site content. I don’t see a way to only to do this for one external site. In this case you would go in an unhide them when you are ready for your NMO to deploy the patches.

**If the case is you need to make the fixlets only available to a certain set of NMOs. Individual fixlets could be exported and imported into their custom site. I recommend custom sites for your regions if you don’t have them already. (more on this later). The other thing you can do is add and remove individual operators to each site in the site readers tab. This would be a lot of work though and I don’t reommend it as it doesn’t scale well.

We use custom sites generally for depts with 2 or more NMOs. This way if the NMO for that region or if Master Opertors have something they develop and only need to make available to that region you can publish to their custom site. Also when 1 NMO for a region creates and analyses/fixlet/task etc they can publish it to the custom site and other NMO for that region can see and iuse it. We had issues where 3 NMO for one dept created their own analyses all gathering the same data. This made for 3x the work and querying of endpoints for the same info.

Anyways this is my understanding on how what you are asking can work. The BigFix person may have had some other thing in mind that I am unaware of.

thanks

(imported comment written by SY57_Jim_Montgomery)

Thanks for your thoughts. One of my co-workers mentioned there is a white-paper covering this as well, but I don’t see anything that pertains on the whitepaper page. I mention it in case it may jog someone’s memory.

I think you covered my concerns in your post. One way – the central admins may miss new fixlets, and the other way – central admins must approve everything/anything before admins can use it.

In my situation, our central admins only approve MS patches, so everytime a new fixlet for other apps came in we’d have to approve it. That seems like a lot of overhead. If that’s the options though, we’ll take that in stride.

We do have sites in place for each of our regions. The admins don’t change that often so we’ll be granting rights to individual users to those sites, as they come into production. Currently we’re working on a policy to subscribe computers to the appropriate site, based on a regkey.