Jump to content
[[Template core/front/profile/profileHeader is throwing an error. This theme may be out of date. Run the support tool in the AdminCP to restore the default theme.]]

Community Reputation

0 Neutral

My Information

  • Location
    USA
  • Agent Count
    < 500 Agents

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. We're in the process of implementing Automate as an MSP, and I'm trying to sort out how best to segregate out Internal workstations/servers from our customers. Generally, my Operations Manager wants to restrict access to our internal devices to a select few users, while still permitting our NOC/Help Desk use the product to it's full capabilities. The concern he has is for an internal employee to have unfettered access to someone like HR, Finance, or the CEO and he's trying to be preventative in blocking access rather than just relying on audits. I'm fairly confident in being able to lock down most access to the average users, i.e. preventing your average NOC or Help Desk user from accessing the internal site and Internal help desk from accessing the customers. However, when dealing with System level tasks, many of those protections and limitations seem to disappear. For instance, I've discovered that there are a few check boxes like Clients > Show All, Computers > Show All, Super User, etc that supercede any client/location limitations placed on the user. I'm curious how other people handle this separation/segregation. I'm also trying to fathom what system-level configuration tasks need to happen on a regular, ongoing basis - is there one or two Super User accounts that only gets touched with a new client? Or is there a continuous need to be logged in as a Super User to execute day-to-day functions? Do people stick with the default user classes? Or remake/create their own (and for what roles)? Many thanks in advanced.
  2. Thanks for this, really appreciate it!
  3. Good morning all, We're in the process of configuring CW Automate and wanted to see if anyone has had experience or luck with creating tickets from a script failure - our specific goal is to schedule updates to run on Macs, and should an update fail to run, create a ticket indicating some degree of information regarding the failure so a tech can subsequently look at the applicable machine for additional troubleshooting. Has anyone seen or implemented something along these lines? Any help would be greatly appreciated. Thanks!
×
×
  • Create New...