why are you trying to do this? i thought you set the automation prinicpal at the role level, not the server level...
We don't want to really commit to using only automation principals (i.e. for the role) but have some times where it would be helpful to be able to use them with the role for a specific job. Our first choice would be to script changing a server property that is read for the role from a default of null (i.e. fall back to using user impersonation) to a temporary value prior to running a deploy job (typically a deploy in which some portion of the job requires AD access that we don't want to give to a local bladelogicrscd user). The last stage of the script would be to reset the server property to null so that any other jobs would not use the automation principal and would instead use user impersonation.
As an example, we typically use BLAdmins for most task and this is mapped to a server property named ADMIN_AUTOMATION_PRINCIPAL. This property is null on all but a few test servers so for all other servers user impersonation is used. We would like to be able to set ADMIN_AUTOMATION_PRINCIPAL for a target server temporarily, run a job, and then reset it so that user impersonation was used.
Our ghetto solution would be to create a new role for the job, set the role to always use an automation principal, and use an execution override so that the job is always run using that role. However, I believe this would require giving the role some kind of access to the blade server objects which is always a hassle.
why don't you just always map the role w/ the AP ? is that much different than the local acct you are mapping them to in terms of access?
We are facing a very similar problem here. How did you finally resolve it?
Thanks in advance.
can you use the blcli to change the AP setting for the role and then change it back ?
Unfortunately, that is not an option, since the role is being used by many users at the same time. The problem is exactly as explained by Jim.
I think you should create a new role for this. trying to flip around the security settings could have unintended consequences, like what happens if you set the AP and another job runs by another user in the same role that should not run w/ the AP ?
what about using the execution override on the jobs you need - run as a different role that uses the AP.
It's going to be quite complicated that two different users run a job against same target, since in the way our customer works is like every user "owns" a group of servers. Nevertheless, I agree with you in that technically is like you say.
Anyway, I like your idea of creating a new role plus using execution override. I'll further explore that option, since there are some other issues (like using the same job at the same time against two servers that will requiere different APs)