The role ‘GlobalReportAdmins’ does not have the Server.Read permission on the server you are trying to decommission, and it probably lacks Server.Decomission as well.
You should run this command as a role that does have those permissions on the server object, perhaps BLAdmins.
I even Tired with the BLAdmin GLO which has all the rights but, no luck. When I try to verify the server from the console, it says no such device or address.
The BLAdmins ROLE, not BLAdmin user. though BLAdmins may not have the necessary permissions on the server object. I would look at the server object and see what role has Read and Decomission. (or *)
As Bill said, you should check the Server.Decommission authorization is available for that particular user. Then only your command will execute successfully.
I would like to chime in here namely because Abin is on my team and I can shed more light on this.
The BLAdminsGLO role is essentially a BLAdmin account (all Authorizations with .*) that is limited to a certain subset of servers.
While Abin would obviously have errors when trying to decom a box through GlobalReportAdmins, I can back him up with decommissioning concerns. I am currently decomming about 10 servers. I am doing this three different ways on three different servers:
1. As a user logged in as BLAdmins role in NSH, and using Server.decommissionServer <ServerName> true
2. As the same user logged into the console, using the traditional administration menu item for server decom with no automatic licensing update.
3. As BLAdmin itself, logged into the console to a different GUI server, using the traditional administration menu item for server decom with no automatic licensing update.
The end results are all identical at the moment.
I have an NSH window that is hanging... waiting for the command to execute.
I have 2 console windows at 0% progress on Decommissing Servers... and the Progress window shows "Undefined" and an empty progress bar.
Normally I wouldn't be too worried, but these three servers have been trying to decommission for over 5 minutes now.
We are seeing the occassional error message in the app server:
[30 Mar 2011 11:55:17,249] [Client-Connections-Thread-2] [WARN] [BL.11021899:BLAdmins:172.20.31.27] [Client] Unexpected exception while handling request.com.bladelogic.model.server.ServerService_decommission(int, boolean) com.bladelogic.mfw.util.BlException: Unexpected exception while handling request .com.bladelogic.model.server.ServerService_decommission(int, boolean)
But this is after 10 or 15 minutes of waiting for a single server decommission.
So, given that we have 2 GUI/NSH servers and 6 JOB only (no NSH) servers, how are decommissions handled? Are they handed to the database and a job server picks up the request? Or is it handled by the GUI server itself? We are trying to figure out how to fix the horrible response times for this.
ACS, a Xerox Company
Thanks Travis. It was my mistake. Earlier the roles order was different and bladmins glo was the first in the list. The order got changed and keeping that in my I was entering 1 but it was for globalreports admin role. Its just a mistake but, I am really ashamed on that becoz of my carelessness.
Sent from BlackBerry® on Airtel
Does BLAdmins have the Server.DecomissionServer or Server.* authorization on the target servers?
What version/sp of bladelogic?
BLAdmins has * rights to all authorizations… and we’re getting the same response from BLAdmin itself (which still has carte blanche access to all objects). The strange thing is once the 10 or 15 minutes is up, the server does decommission successfully.
We’re currently running 8.0 SP4.
All the ACLs/Authorizations are role-based so it won't matter what user runs this, just the role.
Are you getting the same 10-15 min times when you do the decommission and don't do the de-licensing as well?
Are there any components associated w/ the servers? The dependency resolution could be causing this.
Correct… the timeout between doing the de-licensing and not is negligible. I mentioned the roles because even though the BLAdminsGLO role has full auths to a subset of servers, BLAdmin:BLAdmins still has full rights to the entire BladeLogic environment.
I am sure there are components associated with most of these servers… they were in the tool and had compliance templates run against them. Is the dependency resolution normally that slow?
it could be. if you have a server to test w/ try deleting all the associated components first, then decomission and compare the times.
I am running into the same issue on 8.1.03. I have a BL job that gets executed with my role (not BLAdmin), but script inside the job calls the blcli Server decommissionServer command as the local BLAdmin account.
But this is not enough to remove any associated components with the server. Even if the blcli command is run as BLAdmin, it appears that the role that ran the job is the one that tries to remove the components.
Is there a way to run the blcli decommissionServer command AND ignore any dependencies, or another way to get around this permission issue?
Even if the decommission runs as BLAdmins, BLAdmins might not have the required permissions on the objects to remove them. if you want to run the job as BLAdmins, set the execution override on the job as BLAdmins. I’m not sure how you try to change to BLAins in the script, but you should take that bit out as it won’t work.
Yes, that seems to be the problem in my case. Even BLAdmins doesn't have permissions to some of the components. The long-term answer is ensure a proper ACL policy is applied to all new components that are created. We run a blcred command at teh beginning of our decommission job that grabs BLAdmin credentials for the blcli commands (using the user_info.dat file), so we didn't need the execution override option. Good to know for future reference though. Thanks!