?so this only happens if you have a nsh client running and make the ap change after the nsh client has connected to the target?
i don't see how that would be an issue w/ a job.
I would guess that this is functioning as designed the same way that "chrole" functions. These changes only affect future connections with NSH Proxy Servers. Perhaps the procedure in the example section on the man page for chrole would validate this behavior.
chrole - Change the active role for the current Network Shell session.
The chrole command changes the role preference for the current NSH session. All subsequent NSH commands issued from within that session are executed within the context of the new role. If you do not provide a role preference when entering the chrole command, you are presented with a numbered list of authorized roles and prompted to make a selection from that list.
Entering a chrole command only changes the role for new connections with Network Shell Proxy Servers. To set up a new role for agents with which you already have proxy connections, you must disconnect. See the EXAMPLES section below for a demonstration of the required procedure.
The following example changes the active role to WindowsAdmins, provided the active user is authorized for that role.
$ chrole WindowsAdmins
The following example shows the procedure that is necessary to change roles for existing connections to agents. Because the chrole command does not change the role for the current session, when you have an existing connection, you must specify a new role preference, disconnect from the host where you are currently connected, and then reconnect.
$ cd //host1
# Connect to host1. Your current role is role1.
$ chrole role2
# Change to role2.
$ cd //
# Make no connection the active context.
# Disconnect from all servers. Note that this command will not
# disconnect from host1 if the current working directory is //host1.
$ cd //host1
# Reconnect to host1.
I thought of a way to test it and it looks like it does cause an issue with type1 scripts that run on the target. With a script like:
blcli_execute Server setPropertyValueByName TargetNameHere "ADMIN_AUTOMATION_PRINCIPAL" "Class:/SystemObject/AutomationPrincipal/DomainUserHere"
nexec TargetNameHere foo
The foo process is running with UPM if the job targets 'TargetNameHere'. If i target something else with the nsh script job it runs ( correctly ) on TargetNameHere with the automation principal.
Also, even in this scenario if i run something else first ( e.g. an agentinfo ) against 'TargetNameHere' it retains UPM on the subsequent call which means the automation principal has to be set before anything can be done with TargetNameHere or it will incorrectly use UPM.
Also to note this behaviour is new to 8.7. Our prod system is at 8.6 and does not have the same issue.
how often are you going to be changing the AP in the middle of a job?
Its unlikely to be an issue but we have a number of jobs that look something like
echo BaseScript.ps1 -parameters including Server targets > //ServerWIthScript/oneoffscript.ps1 ( this has the fully qualified and parameterized call to the base script )
chmod 777 //ServerWIthScript/oneoffscript.ps1
set automation principal on ServerWithScript
nexec ServerWithScript /oneoffscript.sh ( basically to avoid having to try to parse the nexec command to escape the characters of the command call so we just create a unique script and call it )
In most cases we use the same automation principal consistently and do not reset it so it shouldn't be an issue but it is something where we may have to modify our existing processes to set the automation principal first going forward since we are starting to use multiple automation principals ( albeit with separate script calls ) on the same target.
there was some session re-use to improve the nsh->nsh proxy performance. i'll guess that is what's causing this problem.
can you try a:
cd //@;disconnect <target>
then your next set of commands ?