Web Console Usability

[everets]

Hello everyone,

When the GSS Web Console was first released, we set it up and gave it a try but encountered some problems (permissions being ignored, missing jobs etc.) that prevented us from being able to use it in production.  We engaged support at the time, but were unable to resolve the problems.  So, we've continued using the Win32 app.  Since a fair bit of time has passed, we're wondering:

• How is the console today?  Do you think it's reasonable to replace using the Win32 app with the web console?
• Any major functionality missing in the web console that is only available in the Win32 app?

Thanks!

[Blake Thomas]

For the web console, we're not aiming for 100% feature parity between the two consoles and is not meant to be a replacement, at least for now. The web console is designed to be a worker tool to kick off jobs/tasks from anywhere quickly without having to have them log into the server itself.

Items like the PXE Config Utility or Bootwiz and most backend setup or configuration items won't be available.

Security can be a bit of a hassle, but the help file is good at detailing what is needed in multiple places to allow jobs to be scheduled on computers when logged into a particular user.

[everets]

Thank you for the information Blake!

When it comes to permissions, we're a bit divided up, so we restrict it so certain staff can only see certain computers and run certain jobs on those computers.  Other sets of jobs are shared across the groups.  Primarily our jobs are custom scripts, but we also use some built in ones.  Would it be possible to still do this with the web console?

We could then potentially have our deployment teams use the web console, and the application administrators could logon to the server when needed for the other functionality.

[Blake Thomas]

You can restrict what general functions users or AD groups can perform. Something like checking deny on "Run Script Tasks" would disallow that user from running any task of that type regardless of job/task or target.

You can also separately set permissions on jobs/tasks (and the folders they're contained in) to restrict certain users from running already built jobs. This also applies to the computers list for what can be run on those computers.

However, there is no visibility restriction so all users could see all groups and computers, they would just be restricted from performing actions based on the permissions on those objects and the security settings you have for the users.

In short, Tools > Security is to limit a general action type for a group/user, and Right Click > Permissions on an object (task/job/computer) is to restrict a group/user from performing specific actions with/on that object (and/or child objects).