Technically this should be possible, however your server config will still miss the configuration (itsm plugins, slm processes).
You will need to adapt the config files on the new node (armonitor.conf, pluginsvr_config.xml).
I suggest to open a case with BMC if you haven't done that already.
IMHO the 18.05 installer should be able to handle this situation.
Out of curiosity: Do you have pending binary payload for ITSM/etc for the new server in deployment console?
2 of 2 people found this helpful
I did get an answer from BMC:
open 'SHARE:Application_Properties' form on primary AR Server
2. search with below 'Application IDs' one by one,
IM00C04FA081BAUcxmQg% for (Incident Management)
ID00C04F651D063b42125a0454854d for (Change Management)
PM00C04FA081BAp8xmQghBbmEQnAAA for (Problem Management)
KM00C04FA081BAkzXdRAKRHW5AtFIB for (Knowledge Management)
ID00C04F651D063b42125a04548561 for (Asset Management)
3. modify the 'Property Value' from 9.1.06 to "9.1.05" for 'Version' record of each application above
4. clear the "temp" directory on secondary Server and rerun ITSM 1805 installer
5. After all the secondary servers are done with successful ITSM installation these entries can be manually reverted to '9.1.06'.
As for manually copying the binaries, this is not tested / certified method.
Thank you for sharing the information! :-)
Did you also get the information on how the 18.08 ITSM binaries get deployed on the new box? Do you have to redeploy the package(s)?
Mark Walters : I haven't seen anything regrading this issue on the doc page you linked?
After downgrading the version I was then able to run the 18.05 installer from EPD.
Andreas - the docs detail either cloning an existing system and changing the server name references or doing a full install against a new db and then re-configuring to point at the existing db. In both of these cases the 1808 binaries are already present.
Andy Rogers: Yes, but on existing system you have the 18.08 itsm binaries deployed and on new system you have the 18.05 ones after installation. So I assume somehow you need to run ITSM binary deployment on the new system again?
Mark Walters : Thanks for clarification, I thought the page contained something on the d2p issue and therefor I was confused.
Hi Andy Rogers,
seems I have run into the same problem when I wanted to add an additional server to an 18.08 server group.
I have also installed to 18.08.001 Patch for Platform and ITSM components at the existing servers.
I installed the platform components without problems, as they are available as 18.08 installers.
Now the ITSM installer doesn't start due to the above mentioned problem of detecting the higher version.
Even the manual change of version numbers doesn't seem to get it work - I haven't forced it further by changing all the entries back to 9.1.05, but created a support ticket. Unfortunately there is no answer for a long time beside "R&D is working on it".
For me it is still not clear how to manage the "re-deloyment" of the 18.08 and 18.08.001 D2P Packages?
As their status is already "deployed", will there be an option for re-deployment on the single server?
The other problem I fear is the already deployed 18.08.001 Patch... will this cause further trouble?
Even though the documentation linked by Mark Walters only offers the options 1) Copy binaries + adaption and 2) Fresh Install on new DB - support staff seems to be convinced that manually downgrading the versions is the "official" way to go :-/
If there is no experience from anybody in the community, I would head over to copying binaries.
1 of 1 people found this helpful
I deleted and re-applied the patch as needed which seem to work as it skipped the servers that had already been updated.
BMC had this to say about doing a fresh install in future:
Yes, would need to deploy 1808 D2P package over 1805 system... also, yes need to downgrade the version until everything is installed successfully.
Going forward for a server group installation..would be good to remove servers from the group and install 1808 individually on each server..then add them back to server group. This would prevent the manual steps of downgrading the version and similar.
I assume this means setting up a mid tier to point directly at the new server, run the install, patching etc, then add it to the server group.