You may use "post command" feature in bldeploy job to run the command.
The Pre/Post Commands dialog box lets you execute commands on a target
directory before and after a package is deployed to a server. It also lets you execute
commands on a target directory before a deployment is undone and after it is undone.
A pre- or postcommand can consist of a number of commands that can be executed
by the native operating system of a remote host. After you define pre- and
postcommands, they are saved to the file server as script files. When a job runs, it
command to execute the pre- and postcommands. When you
execute a precommand, the target directory is first created (if it does not already
exist) and then the precommand is executed in the target directory. Postcommands
are executed in the target directory.
You can create pre- and postcommands by entering commands in the text box or
importing text from a file on any managed server. here is screen shot for more details.
It will not work, because the blcli commands should be run from the appserver (or client that has nsh and able to authenticate to the appserver). The pre and post commands are executed on the target itself, so the blcli will fail.
Plus, this is set at the Job level, and I think Robert is looking to incorporate this into the BLPackage.
Unfortunately at this time, I believe you have the best method to do this.. I can think of another one, but it will also involve a lot of overhaul, so I'd just stick with yours.
robert - what are you going to do w/ this property?
he just wants to set it to "true" after software is installed. He probably has another Smart Group in Console where he filters by this property to see what servers have this software installed.... standard use case.
Lazar is right, we are using this smart group to determine where we still need to push the software too.
1 of 1 people found this helpful
Here's one way of doing this by only dealing with the NSH Script Job and having the Deploy Job run in the background.
Create NSH Type 2 script with one parameter:
Name - Hosts
Default Value - %h
Here is the script:
TargetList=`echo "$Targets" | sed 's/ /,/g'`
# get already existing deploy job info
blcli_execute DeployJob getDBKeyByGroupAndName "$JobFolder" "$JobName"
# modify the target list of this deploy job with the list of targets set for the nsh script job
blcli_execute Job clearTargetServers $JobKey
blcli_execute Job clearTargetGroups $JobKey
blcli_execute Job addTargetServers $JobKey "$TargetList"
# execute deploy job (aka: install the software on your targets)
blcli_execute DeployJob executeJobAndWait $JobKey
blcli_storeenv JobRunKey # in case you want to store the runKey, but not needed for this purpose
# test each target individually if software is installed, and if yes, then update its server property
for Target in $Targets
nexec $Target [CHECK IF SOFTWARE INSTALLED]
if [ YES ]; then
blcli_execute Server setPropertyValueByName $Target PATROL_INSTALLED True
1 of 1 people found this helpful
another way entirely would be to create your smart group based on component existence. create a discovery job that discovers components based on the existence of your software and then create a server smart group for servers that lack that component.
run your install, run a discover job.
Robert, did you find any of this useful? What process did you end up implementing?