Problem:

Summation iBlaze needs to be moved to a new server.  This assumes that the application and data are both moving.

 

Solution:


1. Summation iBlaze is going to be moved to a new server. Do I have to reinstall the program on the new server, or can I just copy the program files?

ALWAYS reinstall the program to the server. In the past, it was sometimes possible to evade this requirement if the new server will have exactly the same name as the old server and the Iblaze installation path will have the same name on the new server as it did on the old server. This might still work, but the MSI installer is specifically designed by Microsoft to detect if you just copied the program files without reinstalling and I suspect that it’s sophisticated enough to tell if the program is running on the same path but on a different physical server. If the new location for Summation Iblaze will have a different path name, then you must reinstall.

 

2. Does this mean I have to reinstall the client software on all workstations?

The MSI installer for the client program stores the Summation Iblaze program location in the workstation’s registry, and it can detect if the program is now in a different location. However, some endusers have reported that you have not had to reinstall the client in this scenario. I don’t know what would cause that. I do know that in this situation users will often get the prompt from the installer to browse to the current Summation Blaze.MSI file, and when you do, these things can happen:

- The error message directs you to browse to the "Summation Blaze MU3.MSI" file on the old Summation Iblaze path, which doesn’t exist anymore.

-  If you browse to the current location of the "Summation Blaze MU3.MSI" file (which is in the root program directory), the MSI program complains and says it’s not the right one.

When these events occur, you have to reinstall the client.

 

3. To install the client, do I have to uninstall the old client installation first?
           
This is not a requirement with the MSI installer. If you look at the properties of the shortcut “NetworkClientInstallation”, the target is as follows:

C:\WINDOWS\system32\msiexec.exe /i "\Summation Blaze MU3.msi" REINSTALL="ALL" REINSTALLMODE="vomus" 

The settings for the last two parameters REINSTALL and REINSTALLMODE tell the installer to install the client program regardless of whether any other version of the client program is already installed on the machine.

 

4. I’m still having problems after I did the installation as directed, and I was recommended to perform a clean reinstallation over the existing installation. How do I do this?

The cleanest possible installation is to an empty directory. If you’re reinstalling to a location where you’ve previously installed iBlaze, it should be sufficient to verify that no files are in use or have the read-only attribute. But if there are problems that persist after reinstalling and I suspect this is because not all of the program files are being correctly updated, I will delete most of the files in the installation directory to ensure that they are properly recreated.

You should always leave the CASES and CASEDATA folders alone in this situation (also remember it is possible to have customized locations for the CI files and the case directories). For the ADMIN subfolder, make a copy of the entire subdirectory to a new folder ADMIN-OLD; if you use "Summation" security and have set up your own user names and groups, you can reuse the SWGROUPS.INF and SWNAMES.INF files in the new installation. But if you use NT security, rebuilt that from scratch in the new installation.

Every other subfolder and the files in the program directory can be removed (but see below). Of course, make a full backup before you start deleting the files.

In some uncommon situations, there will be special files in some of the subfolders that you will need to keep:

• HTML – there is a very rarely-used function in Summation Iblaze that allows you to customize or make your own application home page. If you’ve done this, the files for the page will be in this folder
• PROFILES – If you’ve set up scripts to be used by all users, or if you use the "Alerts" database, you need to keep the All Users subfolder.
• DEFAULTS – any custom default layouts that you have created to be copied to new cases are stored in this subfolder.
• The program root folder:
o If you have set up customized user database defaults for new cases, then you would have customized the DBDEF.INI file
o If you have changed the alphabet file for Blazing or the noise words, these are in the files ENGLISH.ABC and NOISE.DAT respectively.
o If you have customized your standard database, you want to keep the files STDDB.* found at the Iblaze application directory.
o If you have received the 32-bit Form Editor, you should keep a copy of it under a name other than EDITOR.EXE. Recommended: if you have a copy of the 32-bit Form Editor, you should keep copies of both the default iBlaze Form Editor and the new 32-bit Form Editor in the program directory as EDITOR16.EXE and EDITOR32.EXE respectively. The installation program will not overwrite these files.
o If you have customized the default formats used by the Retrieve Format function, you need to keep the FORMATS.INF file.

 

5. None of the above suggestions are working for me. Can I try something else?

If you’ve tried the steps above and you still get the message that the "Summation Blaze MU3.MSI file could not be found, or any other message that suggests the existing installation is damaged, try the following:

Access the registry from the workstation (back it up first) and navigate to \\HKEY_CLASSES_ROOT\Installer\Products\.  At this point you’ll need to scroll through the folders to find the right key.

a. 2.8 and older installs – key with 2E0630 prefix
b. 2.9 installs – key with 2A912D prefix
c. 3.0 install – key with AD35EA prefix

Delete the entire key associated with the install – in the situation below, it would be the 2A912D… key on the left highlighted that would need to be deleted.

 

Common Questions About Moving Summation IBlaze Case Data

Many users have decided that manually copying case directories is the quickest method to move cases to another system. In general, this will be quicker than CopyCase, which is designed to handle the synchronizing of different versions of a case database, and was not designed to handle migration of multiple cases at once.

The following is a list of known Summation Iblaze case items which need to be manually altered when you move a case by copying its case directory:

 

1. Change the CI file(s).

The CI file for the case has to be edited to reflect the new case directory. You can do this manually with any text editor, but you have to run the Verify Case Info Files function afterwards. If you’ve moving all of the case directories, there is a new function in the Admin Console as of v. 2.8 to update all of the CI files at once. In the middle tab “Groups”, click on the Case Options button and select “Update Case Info Files”.

 

This leads you to a dialogue where you specify the path in the CI files that is to be changed, and the new path it is to be changed to.

2. Fixing the Case Explorer.

The Case Explorer tree divides into two basic parts:

- The top part roughly corresponds to the “shared” or “public” aspects of the case: Core Database, OCRBase, Transcripts, Notes, etc. The exception to this rule is the current user’s Personal Document Collections folder. The information for the shared part is stored in the file SWCASE.XML in the folder \Profiles\All Users, except for the items in the current user’s Personal Document Collections folder, which is stored in the file \Profiles\\MYCOLLECTIONS.XML.

- The bottom part, “Case Tools”, roughly corresponds to the aspects of the case that are private to the current user. The exception to this rule is the Case Organizer and its tabs. The information for this part is stored in the file MYCASE.XML in the folder \Profiles\.

 The items in these subfolders need to be checked after moving a case:
- Document Collections
- Slideshow
- Searches
- Scripts
- Layouts

Slideshow, Searches, Scripts and Layouts items are by default stored in a subfolder of the pertinent Profiles folder: either the All Users folder for shared items or the user’s own folder for private items. Thus, you should be able to use the “Reload Folder Items” function to update these items after manually moving a case. I have to say “should” because it is possible to drag the same type of items from a location other than the current case’s Profiles folder. If an item does not appear to be working after the case was moved, you can look at the item’s properties or the reference to it in the appropriate XML file to determine the discrepancy.

Document Collections items need both their reference in the Case Explorer and the associated UDL’s properties corrected. The UDL contains a hard-coded path to the data source and if this location has changed because the case has moved, then this location must be updated.

Sample error message if the Case Explorer reference to the Document Collections item was not updated:

 

Sample error message if the path information in the UDL file was not updated:

 

Using “Reload Folder Items” on a Document Collections folder may not be sufficient to update the subitems in the Case Explorer. It is typically necessary to delete the existing item first. Be very careful when you do this, because Summation IBlaze attempts to delete the Briefcase subfolder when you delete a Briefcase item from the Case Explorer. If the case has moved, then in theory, the location stored in the UDL file is now incorrect, so Summation IBlaze will not be able to find the Briefcase folder to delete it. But there is no method to stop Iblaze from attempting to delete the Briefcase files, so you must be certain that the UDL data is incorrect. A safer but more labor-intensive method is to go to the appropriate Profiles subfolder and rename or delete the UDL files. Then you can delete the Document Collections items in the Case Explorer; since the UDL files no longer exist, Iblaze cannot obtain the Briefcase folder location and thus can’t delete anything. The function “Load Briefcase from Folder” can then be used to reload the Briefcase items.

Note that People and Chronology of Events are both Document Collections-type items, but you can simply delete these two items from the Case Explorer and use the “Make Events-People Table” script under Custom Tools to rebuild them.

Is there a simple and quick way of updating the Case Explorer items all at once? One method is to load all of the three XML files into a text editor and globally update all references to the old path to the new path.

It is possible to get the same result by simply renaming the existing SWCASE.XML, MYCASE.XML and MYCOLLECTIONS.XML files, and then reopening the case to allow IBlaze to generate new versions of these files. This method has several problems, in that certain items in the Case Explorer will not be regenerated. These items are:
- Transcript Groups
- These customized (non-default) Case Explorer folders
o Document Collection Group
o Shared Layouts
o Scripts
o Searches
- Pleadings

3. Image paths

The DEFDIR and IMGFILES fields in the IMGINFO table store the path to the image files, but they can do so with an @I or @V token or with an explicit path reference. If explicit path references exist and are no longer valid because the case directory has moved, then this data must be updated in the IMGINFO table. If the @I token is used in the DEFDIR field, then moving the case directory will move the IMAGES subfolder as well, and nothing further needs to be done.

Note that there are two places where IBlaze itself creates images and stores them outside of the IMAGES subfolder:

- Petrified images – stored under the eDocs folder
- Exhibit images loaded from an SBF created in TranSendCR – stored under the Tran subfolder.

In both cases, the DEFDIR field contains an explicit path reference to the case directory, and there is currently no token for the case directory.

4. eDocs, eMail and eDiscovery

Depending on how they were originally loaded, eDiscovery values may need to be modified. When we say that a record was loaded containing ‘eDiscovery’, this generally means that the eDiscovery console was used to load the electronic documents or email or there was an eDII load file supplied by some source along with the electronic documents.  Media field and the Doclink or Storeid fields are seen to be populated in the Core Database.  Following are examples of what one can expect to find there:

 

4a. Media field:

Contains the value “eDoc”, “eMail” or “Attachment”.

4b. Doclink field:  

When Media contains “eDoc”*, this field by default contains a path relative to the default eDocs Dir value seen in Case -> Customize, e.g.:

\eFiles\Session001\BATES00001^Test iBlaze Notes.pdf.

If it contains a hard path (mapped drive or UNC path), then that path will need to be corrected.

When Media contains “Attachment”*, like the eDoc example, this field by default will also contain a path relative to the default eDocs Dir value seen in Case -> Customize, e.g.:

\eMail\Session002\BATES00045^Test WebBlaze Notes.doc.

FYI, when Media contains “eMail”, there is not a path populated by default.

*NOTE: The above path examples are only expected defaults.  It may be that someone has, for whatever reason, altered the path to be an absolute (or hard) path, or, perhaps that someone has just coded the Doclink field by hand.  This is all fine as long as the document referenced can simply be found via ALT-L.

4c. Storeid field:
Created by default in the manner of [PST Name]_[MMMDD]_[4 digit year], e.g.:
271_Oct8_2010, signifying the name of the PST and the date the PST was originally loaded.

The biggest issue associated with moving a case containing loaded eMails from a PST or NSF is the fact that one will typically lose the ability to view the loaded eMails natively through IBlaze.  There are a few places that will need to be checked.  In the event of a complex situation – e.g. multiple non-default repository pathings indicated in the repositories.xml file and multiple pst.map files in non-default pathings - a detailed ‘bread crumb’ list should be created.

  • Repositories.xml:  Stored in the root Profiles folder of each Summation Iblaze case, this file should be checked and corrected first.  Backup the original file and adjust the paths in the tag as appropriate.  This is a good time to evaluate whether the repositories referenced actually exist at the path indicated, e.g. is there at least one PST.map file at that location?
  • PST.map files: Once the Repositories.xml file has been looked at, open each PST.map file associated with the paths in the repositories.xml file.  Each and every pst.map should contain a reference to a valid Storeid value in the IBlaze case and should also contain a valid path to each Storeid’s respective PST.  NOTE: The PST location in the "pst.map" file is to a copy of the PST and NOT the location of the original PST.  The format should be similar to:

MapFile Version 2
Storeid ([PST Name]_[MMMDD]_[4 digit year]),[unique value string for the load],[Full path to the PST]

e.g.: MapFile Version 2

271_Oct8_2010,0000000038A1BB1005E5101AA1BB08002B2A56C200006D737073742E646C6C00000000004E495441F9BFB80100AA0037617A6533315C43617365446174615C50535420464F52204D41524B5C65446F63735C566F6C756D653030335C3237312E70737400,\\Testserver1\Summation\iBlaze31\CaseData\PST TEST\eDocs\Volume003\271.pst

  • Xml files related to the already loaded and parsed PST:  Each correctly loaded PST referenced in pst.map will have a separate xml reference file at the same directory location that has the same exact name as the pst.  Each xml file will have a reference tag that should reference back to its corresponding pst.map file (aren’t you glad you started a list?)

4d. Msg files

MSG files, if they are loaded as ‘loose’ files (e.g. are not included as a part of a PST), are treated as eDocs (Media will = “eDoc) and the suggestions pertaining to the Doclink pathing above apply.

Be aware that certain fields, such as "Doclink", are read-only by-design to assist in defensibility of this type of data.  You will need to unset the read-only attribute in the Form Editor for these fields before you can modify them.

5. Other places where Iblaze stores an explicit path reference to a case element

  • Pleadings. The Pleadings location(s) is/are stored with an explicit path reference. If this has changed because the case directory has moved, you need to update the Pleadings directory references. 
  • Video transcripts. If the location of the video file has changed because the case directory was moved, then the first time thereafter that the video file is played, Iblaze will prompt the user to browse to the new location.
  • DOCLINK in the core database. Although this field is now primarily used by the eDocs feature, the field was originally intended to allow a user to link to any Window file, anywhere. If there are any explicit paths in DOCLINK that have changed because the case data has been moved, then these paths must be manually updated. 
  • Links to external files. These are stored with an explicit path in three places, and thus would have to be manually updated if they are affected by the moving of the case files. 

o Image annotations
o Transcript links
o Case Organizer links

 

Note: Additional details regarding edits that may be needed can be found in this help article.

https://support.accessdata.com/hc/en-us/articles/204114985-Moving-Cases-and-CaseData-folders-iBlaze

 

Applies To

Summation IBlaze