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:
For my 9.0.2 example, the build number of that release is 22.214.171.1241
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 126.96.36.1995, two files from 188.8.131.520 and one from 184.108.40.2061
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
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:
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 220.127.116.115 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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.