During the upgrade, java_jre is deployed, extracts itself into the nimsoft\jre folder, then removes the older version (8u282b08).
However it then proceeds to remove its own newly extracted folder (8u332b09), as per this partial log extract below. The 7z archive is still present, but no java binaries
2022-08-13 14:10:55,881 DEBUG util.DeleteOlderJreFolders:recursiveDelete:48 [Thread-40] - Deleted file/folder: E:\Nimsoft\jre\jre8u282b08\LICENSE
2022-08-13 14:10:55,881 DEBUG util.DeleteOlderJreFolders:recursiveDelete:48 [Thread-40] - Deleted file/folder: E:\Nimsoft\jre\jre8u282b08\THIRD_PARTY_README
2022-08-13 14:10:55,881 DEBUG util.DeleteOlderJreFolders:recursiveDelete:48 [Thread-40] - Deleted file/folder: E:\Nimsoft\jre\jre8u282b08
2022-08-13 14:10:55,881 DEBUG util.DeleteOlderJreFolders:recursiveDelete:48 [Thread-40] - Deleted file/folder: E:\Nimsoft\jre\jre8u332b09\ASSEMBLY_EXCEPTION
2022-08-13 14:10:55,881 DEBUG util.DeleteOlderJreFolders:recursiveDelete:48 [Thread-40] - Deleted file/folder: E:\Nimsoft\jre\jre8u332b09\bin\awt.dll
2022-08-13 14:10:55,881 DEBUG util.DeleteOlderJreFolders:recursiveDelete:48 [Thread-40] - Deleted file/folder: E:\Nimsoft\jre\jre8u332b09\bin\dt_shmem.dll
Subsequently, the deployment of new ADE probe fails, and setup halts, as ADE cannot locate the new jre folder
Aug 13 14:11:17:026 [13196] Controller: Probe 'automated_deployment_engine' FAILED to start (command = ../../../jre/jre8u332b09/bin/java.exe -Xmx512M -Xms64M -Dfile.encoding=UTF-8 -Dsun.net.client.defaultConnectTimeout=1200000 -Dsun.net.client.defaultReadTimeout=1200000 -Dlog4j.configurationFile=./lib/log4j2.xml -Djava.library.path=dlls -jar ./lib/automated_deployment_engine_v2-20.41.jar) error = (3) The system cannot find the path specified.
Release : 20.3.3 /20.4 CU3/CU4
Component : UIM - INSTALL
UIM Installer will in some cases, delete the java_jre versions present in the Nimsoft folder other than the one getting installed by the installer.
In this use case, it was found that there was a higher version of the java jre present in the archive than the one included/present in the 20.4 installer.
When the 20.4 upgrade installer is triggered, installation is installing the version of the java_jre present with the installer and deleting the same (this is the bug) as it is treating the higher version present in the archive as the one which has to be present already.
When the higher version of the java_jre pkg present in the archive is removed, and then the upgrade installer is triggered, the installation is then completed successfully.
Workaround
The workaround is to remove all the java_jre package versions from the local archive and proceed with the upgrade installation.
This issue is resolved in 20.4 CU5 and newer.