Share This:

We're introducing a new utility to help customers better understand and manage their system.  It is called the Manifest Utility.  This can be used, really for any product, but specifically to build a manifest of the file system of a Remedy system.


Using the Manifest Utility


1. Download the attached Manifest.jar file.

2. Open up a command prompt or terminal and navigate to where you saved the Manifest.jar file.


cd E:\

3. Run the following command:

JAVA -Xmx256m -jar E:\Manifest.jar "E:\BMC" >> E:\Manifest.txt

This will execute the utility, and start scanning the E:\BMC directory, which so happens to be the root install directory of all of my Remedy products (as is probably something like most of yours!)


4. Once the command is complete it will write the output to the .txt file we defined in the command.  This is a complete manifest of all binary files that are in the scan directory you defined.





JAVA -Xmx256m -jar C:\Path\To\Manifest.jar "<DirectorytoScan>" <arguments> >> C:\Path\To\Output.txt


Viewing the Manifest Output


The text file that is output presents each file in this format:

File name


          File Path+Name


The data is first grouped by file name, so that alike file names will appear together.  Then it groups those files by checksum.  The file names appear in alphabetical order, the checksum appear in the order they're scanned.


Here is a example from a Remedy ITSM 20.02 system





That is a fairly straight forward example, but a more advanced example is a file that shows up multiple times in the system.  Here is a example from the same system:


















Notice how this example has the same file, multiple times for each of the different components of the system.  They all share the same checksum, meaning each file contains the same payload.  To learn more about a checksum, please visit this link:


The above example isn't always true though, as you will sometimes have files with the same name, but they're actually containing a different payload.  Here is a example of that scenario:











Notice how in this example we have 4 files in this system with that name, but 3 of them actually contain different data, thus they generate different checksums.  What about the same file with 2 different names?  Here is a example for a situation like that:








In the above example notice how they have two different file names, but they acutally contain the same exact hash value.  This means the actual PAYLOAD of that file is the same.  In this example, I took the build009 file, and simply copied and renamed it to build004.




There are 2 arguments that can be passed to this utility:


-aThis will scan ALL files in a directory.  The utility by default will only scan Remedy binary files.
-cThis will export the data in a CSV format instead of the default TXT format.


Notes About This Utility


  1. Keep in mind that this utility will load ALL binary files that are included in this file structure.  This means if you have a 1GB jar file that you've placed in the scan directory, then it will pick it up and try to read it to get the checksum.  This can cause a out of memory error, if needed please increase the -Xmx value to accommodate for larger environments.  This is especially true if you have large log files and use the -a argument.
  2. In addition, this utility is NOT designed to be run during a high load time.  It will consume CPU resources to complete and it will read files causing IO activity.  If you decide to use this utility, use it when it will have the least impact possible to your end users.
  3. The checksum is calculated by the PAYLOAD of the file, it does not calculate it based on the metadata (name, modified date, etc.) of the file.  If you have two files where you believe the data should be correct, but the checksum is different, you can CONFIRM that without a doubt one file is corrupted.
  4. The utility, by default, is made to write to screen.  So if you do not put the ">> C:\Path\To\Output.txt" then it will only write to screen.  This can be useful if you're just wanting to capture a few files in a small directory, but is not advised for normal use.
  5. This will require you to have at least Java 1.8 installed, and you will need to have both JAVA_HOME and your PATH environment variables correctly pointing to your Java instance.
  6. This utility is PLATFORM AGNOSTIC and can run on any platform that Java can run on.  It is built with both Windows and Unix in mind.
  7. This utility does take time to run.  Running with the default settings, it takes about 2 minutes to scan a clean ITSM environment when it is not under load.  If you have a bunch of extra files in the directory, old backups, or if the system is performing other task, this can take longer to run.


Use Cases For This Utility


This Utility was designed to build a manifest of your system's files, but that is fairly useless all on its own.  Here are a couple of use cases where this can come in handy:


  1. I have 2 servers where one server seems to perform a different function than another.  In this scenario you could build a manifest of both systems, and compare the two to ensure that you're not missing files or that files have became corrupted.  (Hint: Notepad++ offers a Compare plugin which will go through and highlight all differences, check it out!  )
  2. I have a new server I just stood up, and I want to make sure files aren't changed after.  In a scenario like this you can build a manifest of a system, then keep it for later comparisons.  This can also be used to validate that a file was updated during a upgrade/patch or also ensure that a file wasn't modified during a system upgrade that shouldn't have been. (looking at you Windows Update )
  3. I have a group of files I just downloaded or copied - This can also be used to validate the checksum of a group of files


Let us know if you have any questions about this utility or any other use cases we haven't considered!