You must install nsh to use the console.
Here is the documentation for silent install for 8.5:
-Aspecifies the products and features you want to install. You do not have to include all features. However, you must include the NetworkShell feature in addition to the ConfigurationManagerConsole feature.
It is probably installing by default because it has to, even though you are specifically not trying to install it.
Thanks for updates, I referred the same document. I do not want network
shell, I want to install only Bladelogic config manager console.
But when I pass the silent install with only config manager console option
but still it installs nsh.
We are providing access to may users in our env and we dont want those user
get access of network shell, they should only have access to config manager
Is there any flag I can use ??
On Sep 17, 2015 11:30 PM, "Douglas Kloepfer" <email@example.com>
NSH is required for the console install.
As Bill said, NSH is required for the console install.
I did find some documentation about deleting nsh access:
The document is not well written but go to RBAC Manager -> Roles and select the roles that the users are part of and make sure that there is nothing with NSH (such as NSH_Proxy, NSHScript, and NSHScriptJob) and that MIGHT help solve the problem. You might have to configure some of the NSH items to get the config manager console to work.
there's no reason to deny NSHScript and NSHScript job. if you don't want the user to have interactive NSH client access then you can do:
- only allow access from the appservers to the targets (where the nsh proxy will run)
- only grant NSH_Proxy.Connect to the roles you want to have nsh access.
so they will be able to start the nsh shell on their workstation but they won't be able to access any servers using nsh, or run any local custom commands.
Douglas Kloepfer wrote:
The documentation team are very open to suggestions for improvement - please add any comments to the page itself and they will work with you to make any corrections or clarifications
Thanks to all. For now to disable Network Shell from users machine I
thought the below options. Is that ok ?
1. Removing Network Shell shortcut from All programs.
2. Rename of nsh.exe from bin directory to nsh.disable.exe.
3. Updating nsh.disable.exe permission to deny read and execute.
As user's do not have Admin rights to their desktop so I think temporarily
these options are ok ? Any other suggestions please let me know except role
disable from RBAC as in our BL app servers we have below entry in exports
file and due to this entry they may access our app servers data also users
have access to many different deploy roles, so we want they should not be
able to launch Network Shell itself.
On Thu, Sep 17, 2015 at 10:12 PM, Jim Wilson <firstname.lastname@example.org>
Also when you provide authorization to end user then disable NSH authorization.
i'm not sure what the issue is w/ just not granting the NSH_Proxy.Connect and making sure only the appservers can connect to the targets. is there some issue w/ the user starting the nsh exe on their system if they can't connect to any target servers ?
No bill we cant go with that option as our team should have access to nsh
as we didnt give them access to app server with bladmin user.
So at time of troubleshooting they launch network shell from their machine
they acquire creds and acquire the required role except admin role to
access the server.
I mean in our Env Developer/App support also uses Bladelogic for deployment and Build their pacakges so to them we dont want they launch network shell.
But we as Admin team access network shell for agent troubleshooting, so our team should be able to launch network shell from their desktop.
I'm not sure i understand:
- if a role lacks nsh_proxy.connect, then they can't use the nsh proxy and therefore not connect to any target servers
- if the role has nsh_proxy.connect then they can use nsh through the proxy.
so, if you need nsh access, then give the role nsh_proxy.connect. if you don't want a role to have nsh access to the targets, then don't give them nsh_proxy.connect. then allow connections only from the appservers in the exports file on your targets. i would think it's much easier to control the access this way than trying to manage user workstations. why is it a problem if the user can launch nsh but not connect to any servers w/ it ? at that point it's just another local shell on their system like cmd or bash.
why do you have * rw,user=bladmin in the exports file on the appserver? that's terrible security - now anyone can connect to your appserver, as the user running the application, and do whatever they want.