Skip navigation

Importing Installation Components with same version and change Monitoring Solution Version in Monitoring Profile (Policy)

score 110
You have not voted. Below Review Threshold

When developing and testing your own KM it can happen that you make several times a small code change but you don't want to change the version of KM all the time.

Importing a KM into the CMA also works with an existing version. At least you get a message that the import was successful.

However, this is not true. Only KM, KML and XML files were imported correctly but not the.gz files. Accordingly, the KM distribution to the patrol agent worked, but there where not the correct, current files distributed.


The answer from BMC was the following:


1. TSPS side – when you import the same version into the repository, it will not be effect and you will not get the update solution, this
    is the design. Or you import it with higher level of the version or remove the custom solution from the repo and then import it again.


2. CI + PA  - CI (common installer) is working very similar, meaning if customer will try to install the same version that is already
    installed on the patrol agent and all the version are the same, it will not be overwritten and it will be left with the old files.
    In this case customer can, or uninstall the KM from the patrol agent or install the KM using the -force in the RunSilentInstall script


If the current mechanism is designed in such a way that it is not possible to import the same version, then an error message should be displayed instead of a success message.


BMC's proposal to delete the customer solution from the repository and then re-import it with the same version is theoretically possible but not really feasible in practice. The reason for this is that the customer solution can only be deleted if there is no connection to existing packages and the KM version to be deleted is not used in any policy.

This means that we have to assign a new KM version for every minor code change. As a consequence, however, this also means that we have to adapt the version in the policies. Since we're not talking about 1-10 but hundreds of policies, that's quite a lot of work.

That brings us to the next problem. You cannot simply change the version of the monitoring solution in a policy. This topic has already been taken up and addressed in 2 other ideas.


By the way, the problem described above does not only apply to KM written by yourself but also to all KM written by BMC. Especially the part about the correct version in the policies is also a problem with the BMC OS KM. It is quite time consuming to keep them up to date and consistent.


I am aware that this is a very complex topic and since I do not know which components are involved (e.g. TSPS, Common installer, PatrolAgent) and what exactly their criteria are, it is difficult to suggest a solution. The fact is, however, that with today's solution the usability is not really given. The time savings we had hoped for with an automatic KM distribution and the distribution of configurations via policies are now cancelled out by the time-consuming maintenance of the policies.

As already mentioned I do know it's not an easy topic and the developers probably have a slightly different focus on this topic, but the usability and economy should also be taken into account.


Only as an idea, perhaps should BMC design this topic a little more open which means to allow more and in exchange delegate more personal responsibility to the customer.

For example, one could allow the version to be changed within a policy and the customer must ultimately be aware whether or not this works in a specific case. However, in order to make this decision as a customer, BMC must also provide information regarding of changes and compatibility (as suggested in the idea


Vote history