We have a fairly large deployment of TEM (over 5,000). We use the tool to do a lot of software distribtuion. Our helpdesk staff has access to the console and all workstations. They are able to query computers and distribute softare by request. We have had a couple of instances now where someone from the help desk accedently selects ALL computers when meaning to deploy a piece of software to just one. This can cause messages being displayed for everyone, unwanted/needed software gets deployed to everyone, network performance problems, etc.
I’m looking for a way to minimize this risk. I like the idea of allowing the helpdesk staff permissions to deploy software, but the permission comes with high risk. Does anyone have any ideas how I can minizie this risk? Is there a way to limit an operator to how many computers they can deploy a single action to? Any ideas would be helpful.
I think this is a great concept, but there is a lot left to be desired. It would not work in our environment.
Here are my issues with 4 eyes approval:
This is the biggest. The approver has to physically walk up and enter their password on the operators computer. If there are no approvers available the operator is stuck waiting, what can you do for remote staff? It would be great if the action was placed into a queue that the approver could review/verify from their own console at their convince.
I wish that you could make certain fixlets/task require or bypass the approval process. This process could then be used for licensed software requiring procurement to approve certain tasks(Office, or Adobe Acrobat, etc.).
There is no way to require approval only if an action is targeting a set amount of computers.
A lot of this just comes from having people actually think about what they’re doing and be responsible for when it goes wrong. By creating arbitrary ‘limits’ mean that lazy/distracted/irresponsible/tired/etc. people can still mess up the wrong machines, just fewer than they might otherwise. And what about the risk of targeting a partner/director’s machine, or their assistants/staff machines. Or a person with the same/similar name/machine ID? Do you need to also control whether they can only send to the right ‘level’ or groups of staff, thus ensuring they don’t send an update requiring a reboot to someone in the wrong time zone (rebooting their machine in the middle of the day)?
I suppose I wouldn’t mind having roles that would restrict some people to only be able to have single-target activities. But given the time/money/effort relationship, I’m not sure how well that could work out in practice.
Some ideas:
Make them type in the target machine ID’s in the list of machines for the update, rather than select from the tree. They might type it wrong, but they can’t type in 5k of peoples machine ID’s.
Have a simple interface/app available to the user to select the item(s) they want, which creates a stub entry on the machine for which there is relevance that will add it to a ‘group’ of machines that are waiting for any software packages (or that specific one). Have packages set to automatically trigger on the setting or have the service desk person target the machine once they can see the machine is visible (having become relevant for the package).
Have the service desk send an initial task that writes the ‘stub’ entry to a file on the machine. (Maybe it will popup to confirm it’s the right machine, which the user can confirm?) Have the same (or another) service desk person send the real install package and target the machine via the appropriate relevance, which will only show those machines that have recently requested the package.
Just some ideas off the top of my head, but I’m sure there are plenty of permutations which would help alleviate some of the risks (except for the fact that it’s an extremely powerful/dangerous tool and they should learn to appreciate that).
If it was a 10 ton digger, or a heavy-duty chainsaw, or a set of explosives, they wouldn’t be let near it. But a tool with a GUI that you can just click on things - why not? It’s not ‘dangerous’.
