In my last post, I described the advances made with the cumulative hotfix installer and where you can find the related installation and versioning information on Enterprise Vault servers. This has prompted the question from a community member of ‘What about the old days, pre-CHFs, how do I find out what hotfixes were installed then?’
In earlier releases, hotfix installation was a manual effort by an administrator who would receive a set of binaries that needed changing on a server and instructions to back-up the corresponding files that were to be replaced, then physically overwrite those files with the new ones. As this was simply a copy / replace effort at the file system level, there are no corresponding registry changes or installation log files available on the server to later interrogate for hotfix details. Many companies would track server changes within their own change control workflow, but equally others may just edit and forget, so how can they identify the presence or not of such a point hotfix?
Well, you can still confirm what hotfixes are installed on Enterprise Vault servers prior to 10.0.4, but it is a less scientific approach that requires manual review of the File Version details of the binaries that make-up Enterprise Vault. Here is an example from a 9.0.2 system:
- Check the regkey HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Install\Version to determine the build number of the current installed major version or service pack on this server, as this regkey does still exist in older versions
For my 9.0.2 example, the build number of that release is 9.0.2.1061
- Open the …\Enterprise Vault program directory in Windows Explorer
- Add ‘File Version’ to the displayed columns, by right clicking on the column headers and selecting ‘More…’, then enabling the ‘File Version’ header
- Sort the folder contents by File Version, and scroll down to the end of the files listed with the major / service pack build number identified in Step 1. If any additional files are listed after this with a File Version of x.x.x.yyyy, then this indicates the presence of hotfixes on the server as they are files from a build that occurred after the major / service pack release
So, in my 9.0.2 example above, there appear to be three different build binaries installed, which will usually correspond to three installed hotfixes – one file from build 9.0.2.1175, two files from 9.0.2.1180 and one from 9.0.2.1181
As I mentioned though, this is not a particularly scientific approach for a number of reasons. Firstly, the Enterprise Vault program directory will contain a number of files that do not fit the standard build number File Version pattern as
- Our full build number versioning is only applied to EXEs and DLLs that we produce, there will be many other file types (such a *.config, *.sql, *.txt etc) with no File Version to differentiate on
- The directory will also contain some interop DLLs with a File Version of x.x.x.0 that does not include the actual specific build number, e.g. 9.0.2.0., so if new versions of these files were distributed in a hotfix, they will also not appear with a different File Version
- There are other third party libraries that we use also present which will have their own versioning standards
In addition to this, some Enterprise Vault and third party binaries reside in sub directories of the primary program folder and could also have been changed by a point hotfix.
To cater for these scenarios, there is an additional check that can be made on your server:
- Check the regkey HKEY_LOCAL_MACHINE\SOFTWARE\ KVS\Enterprise Vault\Install\InstallationDate (for 32 bit installs) or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\KVS\Enterprise Vault\Install\InstallationDate (for 64 bit installs) to determine when the current major version or service pack was installed on this server
- Open the …\Enterprise Vault program directory in Windows Explorer
- In the Search box in Windows Explorer, enter the following criteria
datemodified:>InstallationDate AND kind:-Folder AND Name:-*.txt AND Name: -*.log AND Name:-*.InstallLog AND Name:-*.InstallState AND Name:-Vault.msc AND Name:-EvAzStore_Svc.xml
where InstallationDate is the mm/dd/yyyy hh:nn:ss representation of the value in the registry
These search criteria should return all files in the Enterprise Vault program directory and its sub directories that have been modified after the major version / service pack was installed, but filter out any folders, text files, log files, the VAC msc and EV authorization store which all regularly get updated during normal EV processing. So, in short, these criteria will hopefully provide a different, but corresponding, view on binary files that have been changed since installation, most likely due to a hotfix deployment, including any files that have changed in sub directories as well.
In my 9.0.2 example, this search returned the following results:
The results revealed a number of additional file changes in the Converters sub directory to third party libraries, which looking at their ‘Date Modified’ appear to have been deployed at the same time as the change to install the 9.0.2.1175 version of EVConverterSandbox.exe, so most likely were a part of that specific hotfix.
With the two methods above then, you can get a clear view of what has changed on your EV server since the original installation of the major / service pack version, and from that, determine the build number of any new binaries which will correspond to point or even cumulative hotfix installations. That may well be enough if you are simply trying to compare the installation state of two servers and confirm if both have the same hotfixes installed.
However, in the case of point hotfixes where you have no registry keys or installation files to correlate results with, the final piece of this ‘science’ project that may be necessary is to relate the new binaries and their build number to the original point hotfix package itself, just in case you need to get it again. On this front a simple google search on ‘BinaryName AND “BuildNumber”’ should suffice. For example:
quickly gets me to the original source for the point hotfix, and confirmation that this hotfix did indeed include an update to EVConverterSandbox.exe and a number of third party files in the Converters folder. And if google does not provide the answer, our Support team no doubt can.
So, I hope that helps you understand the binary configuration of your Enterprise Vault servers and, if the need arises, how to determine a server’s hotfix state. It is a somewhat painful process, I know, and one of the reasons for introducing the cumulative hotfix installer in 10.0.4 was to ensure that hotfix distribution and identification could be a more automated, transparent and auditable process moving forward, so we encourage all of our customers to try and upgrade to the latest versions as soon as possible to benefit from such product enhancements.
