It might be possible if you do the following:
1.) Modify the hosts file on the target machine to include an entry for each instance you want to deploy. For example:
NOTE: You will want to make sure each hostname you create is added to DNS so that it can be added to RBAC.
2.) Add each instance into RBAC as a separate server and associate them with the Role you are going to deploy with.
3.) Add the install property for each server, parameterizing them to their respective directories.
4.) Create a deploy job for each server and load them individually into a batch job that executes sequentially. (You don't want one deploy job against all three since it will think they are three separate servers and 'bump heads' when deployed.)
In theory this should work, but I have not personally tried it. Anyone else have comments?
Not sure why you would need the host entries on the targets. And if you want to avoid setting up DNS, you should be able to just add the host entries Greg describes on the application server and do all the other steps he specified. And yes, that should work...
Parameters are tied to the server, so unless you want to alias the different instances so that they can each have their own parameters, then the only way to do this is to execute the job three times and change the parameters in between each run. I've actually seen this automated via the BLCLI before and can probably drum up an example if you want. Assuming the blpackage and job are already created, then the script is simply responsible for executing the job and changing the property n number of times.
OK, I have followed the steps proposed by Aaron and all looks good. There is one small concern. The server has 3 instances on it IDE1, IDE2 and IDE3. If I look at the server properties IDE1 is fine and returns the following:
But on the other two I get:
As you can see, the HOST is correct but the Fully qualified host is always
Is this going to cause any issues and if so how can I correct it?
I don't think this should cause you any problems provided you use the two parameters appropriately.
I have a customer that is using aliases (bogus names) for all their servers that are more meaningful to their NOC staff and maintaining a large hosts file on the app server. As long as the HOST is resolvable from the app server for these aliases, you should be ok.
I'm not sure if there is anything you can do to correct the FQ_HOST, but you could write a quick BLCLI/nsh script to create and set a property called "REAL_FQ_HOST" and parse out the
part of the FQ_HOST and set it to that.
So from where does FQ_HOST derive it's value?