Overview
There was a change made in how the various CLM app-specific functional Client Access licenses (CAL) are packaged in CLM v4.0.1 which has caused a problem for staged upgrades to v4.0.1 or greater from versions 3.0.1.x or 4.0 in distributed environments. A staged upgrade is the kind that we have always recommended and it means if you have multiple CLM applications, you should upgrade them one at a time. The issue along with the workaround is described in detail in this workitem: Incorrect documentation for upgrading JTS and apps in a staged fashion when going from pre-4.0.1 to post 4.0.1 CLM release (251460)
Basically, there are functional app-specific CALs such as the CCM Data Collector, QM Data Collector, RQM Connector, Build System, CQ Synch, and CC Synch that used to be packaged with the Required Base License Keys Including Trials package that was installed by Installation Manager along with the JTS and the CLM server packages prior to v4.0.1. In version 4.0.1, a change was made to rename this license package as well as to move these app-specific functional CALs to be contributed by their respective CLM server applications. For example, the CCM Data Collector, CQ Synch, Build System and CC Synch CALs are now being contributed only when the CCM (4.0.1 or greater) server package is installed. Thus, let’s say that you are planning an upgrade from v3.0.1.4 to CLM v4.0.1 and have a distributed CLM deployment with a JTS, CCM and a QM application. You start by staging an upgrade of just the JTS and CCM applications. So, you install the JTS and CCM 4.0.1 install in their respective locations so that you can perform a side by side upgrade. In v4.0.1, the license package is called Trial Keys for Collaborative Lifecycle Management Products. It only contains the Trial licenses. The other licenses needed are now contributed by the applications themselves. Thus, if you upgrade only JTS and CCM to v4.01 and leave QM at v3.0.1.4, you will have some license assignments that refer to licenses that no longer exist such as the QM Data Collector or RQM Connector. This is because QM is still at v3.0.1.4 and these licenses will not be provisioned until QM is upgraded to v4.0.1. If you upgrade all the apps at once, this is not an issue. This is only an issue for staged upgrades.
What is being done about this problem?
A zipfile containing all of the 4.0.x functional CALs is being made available via workitem 251460 above that can be installed via the JTS Admin web UI after the JTS is upgraded. This will allow these functional CALs to be persisted in the database. At the time you subsequently upgrade any of the apps such as CCM, QM or RM, all the functional CALs associated with the application would need to be deleted. This is necessary so that the new CALs contributed by the upgraded app will take effect rather than the ones persisted in the database.
Why do we need to install these 4.0.x functional CALs in the first place?
These functional CALs are assigned to functional users. Since they are now contributed by the applications, once the JTS is upgraded, the older functional CALs are removed so you end up with functional user CAL assignments to licenses that do not exist. This causes problems with the operation of the non-upgraded applications.
Why do we need to delete these 4.0.x functional CALs prior to upgrading a particular application?
If they are not deleted, then these functional CALs persisted in the database repository will take precedence over any CALs contributed by the upgraded app. This is not the state we want to have.
Rosa Naranjo's Blog 