How does CUCM "system version" relate to patch versions?
I am writing code to verify that the version I retrieved from CUCM (e.g. 184.108.40.206900-7) includes a security fix found in a particular patch/update (e.g. 7.1(5b)su6a). Given that the patch versions found in bullitins are not in the same format as what I appear able to retrieve, this has given rise to much confusion and a few questions.
Is there a strict 1 to 1 relationship between the versions I can retrieve from CUCM (available on the home page, e.g. "System version: 220.127.116.1100-10") and the versions listed in bulletins (e.g. 8.6.2SU3)? In other words, will there ever be a single "system version" that will relate to more than one "CUCM version" or the otherway around? There is a document that goes over upgrade compatibility that has a table mapping "system version" to "CUCM version", and I have been using that to look up correspondances.
I read here that the format of the system version is Major.Minor.Release.Build-InHouseBuild. The article also states that the "build" part can increment by 1,000 for non-CUCM patches (i.e. OS security patch). The example they gave (which may or may not be real) is 18.104.22.1680 and 22.214.171.1242. The claim is that the latter contains CUCM patches that former does not. Do I need to ignore the "thousand" digit then when comparing? Or will this not occur in the wild with CUCM security updates?
Bonus question! Is it possible to retrieve the version in the format that I see in the bulletins and updates (e.g. 8.6.2SU3)?
Basically there is the long form and the short form.
7.1(3) = 126.96.36.19900-11
Usually the 7.1(3) maps to the first three . separated digits, and then the initial version would have a number like 10000 followed by a build number or something... 3a would have 20000, 3b 30000.
7.1(3a) = 188.8.131.5200-2
7.1(3b) = 184.108.40.206000-1
Of course, anything after the 7.1.3 bit in these numbers is liable to pretty random (in initial 'a/b' releases and especially on anything in between such as service updates), so you can look up the version numbers in a couple of places:
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.