The user reads out a build number. Support needs a patch level. Nobody in the room can translate.
In OpenText Enterprise Connect, Programs and Features shows a build number while the Knowledge Center lists patch levels. The two do not sort the same way, one release can carry three different build numbers, and every support call starts with a translation.
It works for you and it does not work for her. That is how these tickets always begin. Two people in the same department, the same document, the same Content Server, and one of them gets an error the other has never seen.
So somebody asks the sensible question, which is what version each of them is running. She opens Control Panel, finds Programs and Features, and reads out 25.4.0.2642. That number is correct, it is the only number her machine will tell her, and it appears nowhere in the Knowledge Center, in the release notes, in the support portal or in any conversation anybody has ever had about Enterprise Connect. What those all use is a patch level, and hers is 25.4 hotfix 1.
The gap between those two facts is where an hour goes, every time. This article closes it, and along the way explains why the obvious shortcut, comparing the numbers, quietly gives the wrong answer.
Why the desktop is the only part with no single version
Everything else in an Extended ECM landscape has one version. There is one Content Server, one Archive Center, one set of servers that somebody patched on a known date. Enterprise Connect is different, because it lives on the desktop, which means it is versioned by whoever last touched the laptop.
A fleet of three thousand machines does not run a version. It runs a distribution: some current, some two hotfixes behind, some on a release that was current when the machine was issued and has not been touched since. That is normal and largely harmless right up until a defect is fixed in one hotfix and not another, at which point it works for me and not for her becomes a completely accurate description of the situation.
Which makes the ability to translate a build number into a patch level an operational requirement rather than a curiosity. Without it you cannot say what your fleet is running, you cannot tell whether a reported problem is already fixed, and you cannot answer the first question support will ask.
Four names for the same software
There is not one alternative vocabulary here. There are several, and knowing which one you are holding is half the work.
| What you have | What it looks like | Where it comes from |
|---|---|---|
| Patch level | 25.4 hotfix 1 | The Knowledge Center, release notes, support conversations |
| EC build number | 25.4.0.2642 | Programs and Features on the desktop, and your asset inventory |
| OE build number | 16.2.1.107 | A second build number carried alongside the first on older releases |
| Patch number | pat162000178, les.ngd:16.2.4.166 | Module level patch identifiers on older releases |
The server side has its own answer too. The Enterprise Connect plug-in module version can be queried directly with ?func=ngd.getversion, which is worth knowing because it is the one number you can obtain without asking a user to open Control Panel and read something out over the phone.
The build number does not sort
This is the part that costs people real time, because the numbers look ordered and are not. Four traps, all of them present in the published mapping.
A newer release can have a lower build number. Enterprise Connect 23.4 hotfix 3 is 23.4.0.1941. Version 24.1 is 24.1.0.1936 and 24.1 hotfix 2 is 24.1.0.1940. Sort those three by the last segment and you conclude that the 23.4 machine is the most up to date one in the building. It is the oldest. The same happens between 24.3 hotfix 2 at 24.3.0.2214 and 24.4 at 24.4.0.2208.
The counter has been reset at least once. The 22.4 line uses 22.4.0.90 and 22.4.0.124, while 22.3 hotfix 18 immediately before it is 22.3.0.1481 and 23.1 immediately after is 23.1.0.1585. Two and three digit builds sitting between two four digit neighbours. Any spreadsheet that sorts the whole estate on the final number will place those 22.4 machines at the very bottom of the list.
One patch level can point at two builds. Version 23.3 hotfix 3 was published as 23.3.0.1722, then replaced by 23.3.0.1760. Both are labelled 23.3 hotfix 3. A machine reporting 1722 is running a withdrawn build, and nothing about the number says so.
The build number does not always agree with the release. Enterprise Connect 16.0.3 hotfix 1 reports a build of 16.0.4.376. The patch label says one release line, the build says the next one.
The rule that survives all four is simple enough to give to a service desk. Compare the release prefix first, 25.4 against 25.3, and only compare the final segment between two builds that share the same prefix. Across release lines the last number means nothing.
The same release, three different build numbers
The sharpest version of this is what happens when the plug-in module and the client are mapped separately. For the 16.2 line the published tables disagree with each other, and both are right, because they are describing different components:
| Patch level | Plug-in module | Second build column | Client mapping |
|---|---|---|---|
| 16.2.1 | 16.2.1.80 | 16.2.1.107 | 16.2.1.129 |
| 16.2.2 | 16.2.2.105 | 16.2.2.123 | 16.2.2.147 |
| 16.2.3 | 16.2.3.204 | 16.2.3.200 | 16.2.3.180 |
Three numbers, one patch level, and in the 16.2.3 row they do not even run in the same direction. This is the practical reason to say which thing you measured whenever you quote a version. "We are on 16.2.2" is not information. "The plug-in module reports 16.2.2.105" is.
It is also the honest root cause behind a good share of it works for me and not for her: the server side module and the desktop client are versioned and deployed independently, and nothing forces them to move together.
The mapping
What follows is the plug-in module mapping from 20.2 onwards, which covers everything anyone is realistically still running. The published source goes back to 10.5.2 if you need archaeology.
| Patch level | Build number |
|---|---|
| 26.1 hotfix 1 | 26.1.0.2772 |
| 26.1 | 26.1.0.2686 |
| 25.4 hotfix 2 | 25.4.0.2652 |
| 25.4 hotfix 1 | 25.4.0.2642 |
| 25.4 | 25.4.0.2621 |
| 25.3 hotfix 2 | 25.3.0.2558 |
| 25.3 hotfix 1 | 25.3.0.2544 |
| 25.3 | 25.3.0.2475 |
| 25.2 hotfix 1 | 25.2.0.2456 |
| 25.2 | 25.2.0.2429 |
| 25.1 hotfix 2 | 25.1.0.2372 |
| 25.1 hotfix 1 | 25.1.0.2369 |
| 25.1 | 25.1.0.2358 |
| 24.4 hotfix 4 | 24.4.0.2280 |
| 24.4 hotfix 3 | 24.4.0.2278 |
| 24.4 hotfix 2 | 24.4.0.2257 |
| 24.4 hotfix 1 | 24.4.0.2246 |
| 24.4 | 24.4.0.2208 |
| 24.3 hotfix 2 | 24.3.0.2214 |
| 24.3 hotfix 1 | 24.3.0.2168 |
| 24.3 | 24.3.0.2122 |
| 24.2 hotfix 2 | 24.2.0.2051 |
| 24.2 hotfix 1 | 24.2.0.2048 |
| 24.2 | 24.2.0.2046 |
| 24.1 hotfix 2 | 24.1.0.1940 |
| 24.1 | 24.1.0.1936 |
| 23.4 hotfix 3 | 23.4.0.1941 |
| 23.4 hotfix 2 | 23.4.0.1931 |
| 23.4 hotfix 1 | 23.4.0.1918 |
| 23.3 hotfix 3 | 23.3.0.1760, replacing 23.3.0.1722 |
| 23.3 hotfix 2 | 23.3.0.1757 |
| 23.3 hotfix 1 | 23.3.0.1747 |
| 23.2 hotfix 2 | 23.2.0.1695 |
| 23.2 hotfix 1 | 23.2.0.1692 |
| 23.2 | 23.2.0.1649 |
| 23.1 | 23.1.0.1585 |
| 22.4 hotfix 1 | 22.4.0.124 |
| 22.4 | 22.4.0.90 |
| 22.3 hotfix 18 | 22.3.0.1481 |
| 22.3 hotfix 17 | 22.3.0.1478 |
| 22.3 hotfix 16 | 22.3.0.1475 |
| 22.3 hotfix 15 | 22.3.0.1472 |
| 22.3 hotfix 14 | 22.3.0.1468 |
| 22.3 hotfix 13 | 22.3.0.1462 |
| 22.3 hotfix 12 | 22.3.0.1455 |
| 22.3 hotfix 11 | 22.3.0.1453 |
| 22.3 hotfix 10 | 22.3.0.1447 |
| 22.3 hotfix 7 | 22.3.0.1439 |
| 22.3 hotfix 6 | 22.3.0.1436 |
| 22.3 hotfix 4 | 22.3.0.1417 |
| 22.3 hotfix 3 | 22.3.0.1399 |
| 22.3 hotfix 2 | 22.3.0.1395 |
| 22.3 hotfix 1 | 22.3.0.1389 |
| 22.2 hotfix 2 | 22.2.0.1353 |
| 22.2 hotfix 1 | 22.2.0.1324 |
| 22.2 | 22.2.0.1286 |
| 22.1 hotfix 2 | 22.1.0.1207 |
| 22.1 hotfix 1 | 22.1.0.1203 |
| 22.1 | 22.1.0.1139 |
| 21.4 hotfix 2 | 21.4.0.1104 |
| 21.4 hotfix 1 | 21.4.0.1092 |
| 21.4 | 21.4.0.1085 |
| 21.3 hotfix 1 | 21.3.0.1007 |
| 21.3 | 21.3.0.987 |
| 21.2 hotfix 4 | 21.2.0.913 |
| 21.2 hotfix 3 | 21.2.0.910 |
| 21.2 hotfix 2 | 21.2.0.908 |
| 21.2 hotfix 1 | 21.2.0.905 |
| 21.2 | 21.2.0.872 |
| 21.1 hotfix 3 | 21.1.0.828 |
| 21.1 hotfix 2 | 21.1.0.825 |
| 21.1 | 21.1.0.791 |
| 20.4 hotfix 2 | 20.4.0.736 |
| 20.4 hotfix 1 | 20.4.0.733 |
| 20.4 | 20.4.0.708 |
| 20.3 hotfix 4 | 20.3.0.622 |
| 20.3 hotfix 3 | 20.3.0.618 |
| 20.3 hotfix 1 | 20.3.0.607 |
| 20.3 | 20.3.0.602 |
| 20.2 hotfix 2 | 20.2.0.561 |
| 20.2 hotfix 1 | 20.2.0.557 |
| 20.2 | 20.2.0.506 |
Two gaps in that list are in the source rather than in the transcription. The 22.3 line jumps from hotfix 7 to hotfix 10, and several early 16.x hotfixes have no build number recorded at all. A patch level with no published build is not a patch level you will ever identify from a desktop, which is worth knowing before you promise anybody a complete fleet report.
The list also ages. Releases are frequent, older lines are not always revisited when a new build appears, and the published mapping carries its own warning that it may be incomplete. Treat it as good guidance rather than as an authority, and check the current version of the source article before you make a decision that matters.
What to do with this
Put the patch level into your asset inventory, not only the build. Whatever collects your software inventory reports the display version, which is the build, so the translation has to happen at ingest. Do it once and every later question about the fleet becomes answerable.
Report the fleet as a distribution rather than as a version. How many machines on each patch level, oldest first. That is the picture that tells you whether a rollout finished, and it is also the picture that explains why one department keeps raising tickets nobody else raises.
And when you open a support case, give both numbers and say which component each came from. The build number identifies the machine. The patch level is what support can search. Supplying one without the other is what turns the first day of a ticket into a conversation about version numbers.
None of this is anybody's fault, and it is not really a defect. Build numbers are for engineering and patch levels are for people, and the two vocabularies collided at the one place in the landscape where an end user has to read a number off their own screen.
The colleague whose Enterprise Connect worked, in the ticket at the top, was on 25.4 hotfix 2. Marieke was on hotfix 1. One number apart in the vocabulary that matters, ten apart in the vocabulary she could see, and invisible in both directions until somebody had a table. It is worth having the same defaults conversation here as anywhere else: most of the difference between two machines is not a decision anybody made, it is where each one happened to stop.
Ruud Palmen — ECM Solution Architect
15+ years of OpenText. More background on the about page, or follow along on LinkedIn.