I’m not quite understanding the concept of sites. I (as a master operator) created a custom site under Manage Sites, assigned the operators. Then created an automatic group and put that new site in the ‘create in site’ drop down box. My assumption is that the users that are members of that site should see that automatic group and the computers but that is not correct is it?
I’ve searched & read posts and doc’s and really haven’t found one that explains how operators and sites work and when/why to use them.
What I’m trying to do is have a group of operators see a group of computers (automatically based on computer name). Also (this is the one I really have no clue where to start) is if an operator in that site creates a custom task, I want everyone in that site to be able to see/edit/deploy that task.
Is there no way to group operators? Is the only way to do this is to right click each operator and “assign user management rights”?
Any assistance in explaining how to do this or links to doc’s is welcome and appreciated.
Operator privileges using “assign operator rights” is how you control which operators see which computers.
Custom sites are used to control which operators can see which Fixlets/Tasks/Baselines/Analyses/groups (they can see these for computers that they manage).
There are no operator groups available currently, but you can assign the same rights of operators to groups of users.
One more question though. If an operator creates a task they are the only ones that can see that task. Is there a way to change that default behavior? I want someone to be able to create a task in a site and have everyone in that site be able to see and edit that task. Is that possible without having to have a master operator create a custom copy in the master operator site?
My organization has implemented something very close to what you describe. We have several divisions of admins that manage that division’s computers.
We created a custom site for each division. Admins are granted read/write for their respective custom site. They are instructed to put new content in that custom site. They must change that drop down every time they create new content. But at least they share with other admins. (If they forget, they can also export/import from their private site to the divisonal custom site.)
We have a single custom site that all computers subscribe to. Let’s call it Custom_CORP. This is important in the next bullet.
We have an automatic computer group for each division. These groups are stored in the Custom_CORP site. All comps evaluate their own group membership and add themselves to the proper group based on a property we created (you could just do it off computer name)
We “scope” admins to only have access to their appropriate divisional computer group.
We also have a name standard for admins, so looking at the name you know which division group and custom site they have rights to.
The trick is: users can assign fixlets to computers through their group scope, but computers can only see fixlets that are in sites they subscribe to. So you have to combine these two to get admins that can apply their own fixlets to their computers. Also remember that groups are kinda like fixlets, and computers just evaluate them and report back T or F (but only if they are subscribed to the site the group is in)
This structure has worked out really well for us so far. BigFix is generally a very centralized management product, but using the sites and groups carefully, you can implement in a distributed environment with great success.