Relativity - Upgrade Guide - 9.6 PDF

Upgrade Guide
May 10, 2019 | Version 9.6.202.10
For the most recent version of this document, visit our documentation website.
Table of Contents
1 Relativity upgrade 12
1.1 Addressing custom solutions pre-upgrade 12
1.2 Addressing custom scripts that trigger imaging jobs 12
1.3 Required pre-upgrade steps for all Relativity versions 12
1.3.1 Obtain credentials for service and database accounts 13
1.3.2 Review system and other requirements 13
1.3.3 Apply a trusted certificate for the Analytics server 13
1.3.4 Back up your Relativity environment 13
1.3.5 Reboot machines with Windows updates 14
1.3.6 Download the Relativity installer 14
1.4 8.1, 8.2, or 9.x to 9.6 upgrade workflow 14
1.5 8.0 to 9.6 upgrade workflow 15
1.6 7.x to 9.6 upgrade workflow 15
1.7 6.x to 9.6 upgrade workflow 16
2 Upgrade considerations for Relativity 9.6 17
2.1 9.x to 9.6 Relativity updates 17
2.2.1 Agents 18
2.2.2 Agent service 19
2.2.3 Analytics 19
2.2.4 Applications 20
2.2.5 Audit 21
2.2.6 Authentication 21
2.2.7 Conversion 21
2.2.8 Data Grid 21
2.2.9 Database schema updates 22
2.2.10 ECA and Investigation 22
2.2.11 Fields 23
2.2.12 File share 23
Upgrade Guide 2
2.2.13 Foreign key removal 23
2.2.14 IIS 23
2.2.15 Imaging 25
2.2.16 Installation of a certificate on the database server 26
2.2.17 Instance settings 26
2.2.18 Processing/Invariant 27
2.2.19 Network load balancing 31
2.2.20 New UI framework 32
2.2.21 Production 32
2.2.22 Relativity admin and service account email addresses 34
2.2.23 Relativity Desktop Client (RDC) 34
2.2.24 Relativity installer updates 34
2.2.25 Relativity Processing Console 35
2.2.26 Relativity service bus 35
2.2.27 Required certificates for Relativity 36
2.2.28 Scripts 36
2.2.29 Searching 36
2.2.30 Service Host Manager HTTPS configuration 36
2.2.31 System requirements 36
2.2.32 Telemetry 37
2.2.33 User and group operations 37
2.2.34 Viewer (ActiveX) 37
2.2.35 Viewer (ActiveX and HTML) 38
2.2.36 Windows or Integrated Windows authentication 38
2.2.37 Windows Service Bus 1.1 with TLS 1.2 Support 38
2.2.38 Workers 40
2.2.39 Worker manager queue 41
2.2.40 Worker manager server 41
2.2.41 Workspace upgrade queue 41
2.2.42 Conversion 41
2.2.43 Data Grid 41
Upgrade Guide 3
2.2.44 Database schema 42
2.2.45 Document table trigger removal 42
2.2.48 IIS 43
2.2.49 Imaging 44
2.2.50 Imaging sets 46
2.2.54 Processing 51
2.2.58 Scripts 53
2.2.59 Searching 53
2.2.60 Servers 54
2.2.62 Structured Analytics 54
2.2.64 Telemetry 54
2.2.68 Workers 55
2.2.72 Viewer 56
2.2.73 Workers 57
Upgrade Guide 4
2.2.75 Workspace Upgrade Queue 57
2.2.76 Workspaces 57
2.3.2 Analytics 59
2.3.4 Audit 61
2.3.6 Conversion 62
2.3.7 Data Grid 62
2.3.10 Fields 64
2.3.13 IIS 64
2.3.14 Imaging 66
2.3.27 Scripts 77
Upgrade Guide 5
2.3.28 Searching 77
2.3.31 Telemetry 77
2.3.37 Workers 81
2.3.42 Database schema 82
2.3.43 dtSearch index considerations 83
2.3.46 Imaging 84
2.3.48 IIS 86
2.3.50 License Relativity and Processing 92
2.3.53 RAR upgrade notes 93
2.3.56 Viewer 94
2.3.57 Searching 95
2.3.58 Scripts 95
Upgrade Guide 6
2.3.61 Configure the viewer drawing delay 95
2.3.62 Upgrade custom applications or code 96
2.3.64 Workers 96
2.4.2 Analytics 98
2.4.4 Audit 100
2.4.7 Data Grid 101
2.4.9 Document Table Trigger removal considerations 102
2.4.10 dtSearch index considerations 102
2.4.12 Fields 103
2.4.15 IIS 104
2.4.16 Imaging 105
2.4.19 License Relativity 107
Upgrade Guide 7
2.4.24 Pre-installation steps for web servers 114
2.4.31 Scripts 117
2.4.32 Searching 117
2.4.35 Telemetry 118
2.4.36 Upgrade agents and other components 118
2.4.38 Viewer 119
2.4.43 Workers 122
3 Configuring your conversion agents 124
3.1 Conversion agent considerations 124
3.2 Re-purposing a conversion worker as a conversion agent 124
3.3 Adding conversion agents to an environment with no dedicated conversion workers 125
3.3.1 Adding a conversion agent to an existing server 125
3.3.2 Allocate additional hardware to host a new agent server 126
4 Upgrading your SQL Server 127
4.1 Primary SQL Server upgrade 127
Upgrade Guide 8
4.2 Distributed SQL Server upgrade 131
5 Removing RabbitMQ 134
5.1 Deleting Data Grid agents 134
5.2 Deleting empty processing queues 134
5.3 Uninstalling RabbitMQ Server and Erlang OTP 134
5.4 Closing ports on the Queue Server 135
6 Upgrading your Relativity service bus 136
6.1 Relativity service bus upgrade 136
6.2 Setting properties in the RelativityResponse.txt file 137
6.2.1 Feature selection 137
6.2.2 Common properties 137
6.3 Verifying database table updates for multiple hosts 138
6.4 Troubleshooting the service bus installation 139
7 Upgrading your agent server 140
7.1 Agent server upgrade 140
7.2 Service Host Manager HTTPS configuration 142
8 Upgrading your web server 143
8.1 Web server upgrade 143
8.2 Verifying the machine key settings on the IIS 145
8.3 Upgrading a web server configured for mixed authentication with AD 147
8.4 Service Host Manager HTTPS configuration 148
8.5 SignalR 148
9 Upgrading a worker manager server installation 150
9.1 Upgrade considerations for Relativity 9.6.134.78 150
9.2 Upgrade exceptions 151
9.3 Installing Microsoft Visual C++ Redistributable Packages 151
9.4 Upgrading the Invariant Queue Manager 152
10 Upgrading Relativity to .NET 4.6.2. 153
10.1 All servers 153
10.2 Client machines 153
10.3 Relativity applications 154
Upgrade Guide 9
10.3.1 Backward-compatible applications 154
10.3.2 Custom applications built with the Relativity SDK 154
10.4 Development environment 154
11 Upgrading workspaces 155
11.1 Monitoring upgrades with the Workspace Upgrade queue 155
11.1.1 Populating the Workspace Upgrade queue 156
11.1.2 Workspace Upgrade queue columns 157
11.1.3 Upgrade statuses descriptions 158
11.2 Editing upgrade priority and order for a workspace 158
11.3 Troubleshooting upgrades 160
11.3.1 Viewing upgrade errors 160
11.3.2 Canceling or retrying workspace upgrades 162
11.3.3 Retrying upgrade failures for system secured applications 163
12 Upgrading or installing your Analytics server 164
12.1 Installing / Upgrading Relativity Analytics 164
12.1.1 Installing Analytics for the first time to Relativity 9.6.50.31 and above 165
12.1.2 Upgrading from Relativity 9.3.362.9 (CAAT 3.19) and above 170
12.1.3 Upgrading from Relativity 9.3.332.21 (CAAT 3.17) or prior 173
12.2 Updating the default SSL/TLS certificate 179
12.2.1 Overview of how to update the SSL / TLS certificate 180
12.2.2 1) Deleting the default, unsigned certificate 180
12.2.3 2) Creating a self-signed certificate (no trusted certificate) - optional step 181
12.2.4 3) Importing a certificate (trusted or self-signed) 183
12.2.5 4) Verifying the Analytics server in Relativity 185
12.3 Disabling TLS 1.0 and 1.1 (optional) 186
12.4 Installing Analytics server when SQL Server uses SSL encryption 187
12.4.1 Install a SQL Server certificate in the Analytics server KeyStore 187
12.4.2 Use the CN property of a SQL Server certificate in Relativity 188
12.5 Changing the REST password 188
12.6 Uninstalling the Relativity Analytics server 189
13 Upgrading Data Grid 190
Upgrade Guide 10
13.1 Finding the Elasticsearch version 190
13.2 Upgrading from Elasticsearch 2.1.2 to 2.3.3.x 191
13.3 Preparing the environment for upgrade 191
13.4 Running the upgrade script 192
13.5 Verifying the upgrade 192
13.6 Running a manual upgrade 193
13.6.1 Upgrading a node 193
13.6.2 Verifying the upgrade 196
13.7 Resetting the Shield or Head password 197
Upgrade Guide 11
1 Relativity upgrade
Use the following workflows to upgrade your current Relativity installation to Relativity 9.6. To begin your
upgrade process, address custom solutions and scripts before downloading the Relativity installer. Once
you complete the workflow specific to your upgrade path, we recommend completing the post-installation
verification tests post-upgrade to confirm that your environment has been upgraded properly.
As a best practice, we recommend preparing for your upgrade process by using the Pre-Upgrade
Checklist. You can use this document to discuss an upgrade strategy for your current installation of
Relativity with the Client Services team (support@relativity.com) .
If you are installing Relativity for the first time, contact the Client Services team (support@relativity.com)
for additional information. You may also want to review the information on the Relativity installation page
on the Relativity 9.6 Documentation site.
1.1 Addressing custom solutions pre-upgrade

The Solution Snapshot application helps you identify compatibility issues with custom applications in your
environment so you can resolve them prior to upgrade. Using the Solution Snapshot application, you can
view a list of the applications currently installed in your Application Library and review the application
owner's recommendation for upgrade. For more information, see the Solution Snapshot documentation.
1.2 Addressing custom scripts that trigger imaging jobs

If you plan on upgrading Relativity and you use custom scripts that programmatically trigger imaging jobs
in your current Relativity environment, those scripts will no longer work after you upgrade.
This is because the components that those custom scripts rely upon no longer exist due to the changes
made to the imaging framework, which are listed below. The imaging operations performed by these
custom scripts aren't accounted for in the KCD Snapshot Solution script.
n The Imaging Set Manager and Worker agents have been deprecated.
n The Imaging Set Queue table has been deprecated.
n The Imaging API now submits an imaging job directly to Invariant (worker manager server).
Before you upgrade to Relativity 9.6, contact Client Services at support@relativity.com for instructions on
how to adjust your custom scripts.
1.3 Required pre-upgrade steps for all Relativity versions

Before you begin your upgrade, you must complete the following pre-upgrade steps.
Required pre-upgrade steps for all Relativity versions
Complete the following steps and verify you have the necessary information required for all upgrades of
Relativity. Depending on your upgrade path, you may have additional configuration or other tasks to
perform specific to the version of Relativity you're installing.
Make sure you have the appropriate system admin permissions in Relativity before beginning the
upgrade. . For more information, see Managing security on the Relativity 9 Documentation site.
Upgrade Guide 12
Confirm that jobs aren't running in any of the queues. If the agents are running, they may attempt to run a
job against a database that doesn't have an upgraded schema and cause serious errors in your Relativity
environment.
1.3.1 Obtain credentials for service and database accounts

To upgrade Relativity, you need credentials for the following accounts:
n Relativity Service account (Windows Workgroup/Domain account) - Run the Relativity upgrade
logged in as the Relativity Service account. This account must have local Administrator permissions
on the target server, and SQL sysadmin role privileges on the SQL Server.
n EDDSDBO account (SQL account)
Note: Do not begin the upgrade process until you obtain the credentials for these accounts. They are
required when you run the installer.
1.3.2 Review system and other requirements

Confirm that your environment is configured with the prerequisites before you begin upgrading Relativity.
See the following documents for more information:
n Relativity System Requirements - Includes software and hardware requirements for servers, data-
bases, and other components of a Relativity installation.
n Relativity Workstation Configuration guide - Includes information about setting up workstations for
users and viewer installation instructions.
n Relativity Environment optimization guide - Includes best practices for maintaining and optimizing a
Relativity environment.
n Upgrade path instructions - Contain detailed information about requirements for your specific
upgrade path.
1.3.3 Apply a trusted certificate for the Analytics server

As of Relativity 9.6, a trusted certificate is required for all HTTPS traffic, including the internal traffic for the
Analytics server. We recommend placing the certificate and testing it prior to the day of the upgrade to
Relativity 9.6 or above.
See Pre-upgrade: Update the default SSL/TLS certificate for CAAT ® for more information.
1.3.4 Back up your Relativity environment

Back up your SQL databases and your Relativity IIS websites before you begin the upgrade process. You
should also back up both the structured analytics sets and analytics indexes before your upgrade to
ensure that there is no data loss. This may take a while so it's recommended to run analytics backups
either during the week of or the week prior to your upgrade. Usually this data does not change daily, so this
helps to mitigate any data loss.
Upgrade Guide 13
1.3.5 Reboot machines with Windows updates
After installing Windows updates, reboot your machines before attempting to install Relativity. Complete
this step to ensure that all Relativity components are properly installed. Incomplete Windows updates lock
system files, which may cause silent failures and prevent the proper installation of Relativity components.
1.3.6 Download the Relativity installer

To receive the correct Relativity installer package for your upgrade workflow contact the Client Services
team (support@relativity.com).
1.4 8.1, 8.2, or 9.x to 9.6 upgrade workflow

Use the following workflow when upgrading from Relativity 8.1 or 8.2 to Relativity 9.6.
Note: Never upgrade your Relativity version while there are jobs of any type currently in progress in
your environment. Doing this leads to inaccurate results when you attempt to finish those jobs after your
upgrade is complete. This is especially important for imaging and processing jobs.
Note: Beginning in Relativity 9.4.254.2, processing to Data Grid no longer requires the RabbitMQ
server. You must remove the RabbitMQ from your Relativity environment before installing Relativity
Service Bus server. For more information, see Removing RabbitMQ on page 134.
Notes:
n Before you upgrade, verify that you meet all requirements outlined in the Pre-installation guide.
n Once you've completed upgrading core servers (Secret Store, Primary SQL, Worker Manager, Ser-
vice Bus) all remaining servers can be upgraded in any order or in parallel.
1. Install the Relativity Secret Store and configure all machines in your environment to access it. This
step should be completed before the Relativity upgrade and can be done online without impacting
user review. For more information, see The Relativity Secret Store Guide.
Upgrade Guide 14
2. Stop all agent services.
3. Stop the IIS.
4. Run the Relativity installer on your Primary SQL Server to upgrade the EDDS database and install
the required library applications. You can't access your Relativity environment until you complete
this step. Depending on what version you're upgrading from, this process may start automatically
after the installer is finished running. See Upgrading your SQL Server on page 127.
5. Run the Relativity installer on all distributed SQL servers if present. See Distributed SQL Server
upgrade on page 131.
6. Install the Relativity service bus server. Ensure that the Relativity service bus server is a node in the
Service Bus for Windows Server farm. See Upgrading your Relativity service bus on page 136
Note: You can find additional information in Troubleshooting the service bus installation on
page 139. For general troubleshooting information, see the Relativity Service Bus guide.
7. Run the Relativity installer on the Agent server. See Upgrading your agent server on page 140.
8. Run the Relativity installer on the Web server. See Upgrading your web server on page 143.
9. Restart the IIS.
10. (Optional) Log in to Relativity and click the Workspace Upgrade queue. Set the priority or order on
the workspaces as necessary. You can monitor your workspaces in the Workspace Upgrade
queue. See Upgrading workspaces on page 155.
Note: After you run the installer on at least one agent server, the system begins upgrading
individual workspaces. You can now log in to Relativity to monitor workspace upgrades via the
Workspace Upgrade queue.
11. Upgrade your worker manager server. For more information, see the Worker Manager Server
Installation guide.
Note: If this is your first upgrade to Relativity 9.6 and above, you must upgrade any worker
servers after upgrading your worker manager server.
12. Upgrade Relativity Analytics. See Upgrading or installing your Analytics server on page 164.
1.5 8.0 to 9.6 upgrade workflow

Please contact the Client Services team (support@relativity.com) for more information on upgrading your
8.0 Relativity environment to Relativity 9.6.
1.6 7.x to 9.6 upgrade workflow

7.x Relativity environment to Relativity 9.6.
Upgrade Guide 15
1.7 6.x to 9.6 upgrade workflow
6.x Relativity environment to Relativity 9.6.
Upgrade Guide 16
2 Upgrade considerations for Relativity 9.6
This page explains some of the key changes in Relativity 9.6 that you should be aware of before
upgrading.
In order to upgrade to or install Relativity 9.5 or above, you MUST complete new pre-installation steps.
You now need to install Service Bus for Windows Service 1.1 BEFORE installing or upgrading to Relativity
9.5 or above.For more information, see the Pre-Installation guide.
Note: You must install and configure the Relativity Secret Store before installing any other Relativity 9.6
components. For more information, see The Relativity Secret Store Guide.
Refer to this page to learn more about changes in your environment from a previous version of Relativity
to Relativity 9.6.
2.1 9.x to 9.6 Relativity updates

For changes that occur to your Relativity 9.x environment after you upgrade to Relativity 9.6, see 9.x to 9.6
upgrade considerations on the Relativity 9.6 Documentation site.

Learn more about the changes to your Relativity 8.x environment after you upgrade to Relativity 9.6.
8.x to 9.6 Relativity updates
n Agents on the next page
n Agent service
n Analytics on page 19
n Applications on page 20
n Audit on page 21
n Authentication on page 21
n Conversion
n Data Grid on page 41
n Database schema
n Document table trigger removal on page 42
n File share on page 42
n Foreign key removal on page 43
n IIS on page 43
n Imaging on page 44
n Imaging sets on page 46
n Installation of a certificate on the database server on page 46
Upgrade Guide 17
n Processing/Invariant
n Network load balancing on page 31
n New UI framework on page 51
n Upgrade considerations for Relativity 9.6 on the previous page
n Production on page 52
n Relativity admin and service account email addresses on page 34
n Relativity Desktop Client (RDC) on page 34
n Relativity installer updates on page 34
n Relativity service bus on page 53
n Required certificates for Relativity on page 53
n Scripts
n Searching on page 53
n Servers on page 54
n Service Host Manager HTTPS configuration on page 54
n Structured Analytics on page 54
n System requirements on page 54
n Telemetry on page 54
n User and group operations on page 37
n Viewer on page 56
n Upgrade considerations for Relativity 9.6 on the previous page
n Windows or Integrated Windows authentication on page 57
n Windows Service Bus 1.1 with TLS 1.2 Support on page 38
n Workers
n Worker manager server
n Workspaces on page 57
n Workspace Upgrade Queue on page 57
2.2.1 Agents
With the introduction of the new viewer, the following agents have been removed in Relativity 9.6:
n Imaging set manager

n Imaging worker
Upgrade Guide 18
The work of processing, document conversion, imaging set, image-on-the-fly, and mass imaging jobs are
performed by workers, which you can add in the Servers tab. For more information, see the Servers
section of the Relativity Admin Guide.
2.2.2 Agent service

All Windows services now have Recovery Properties. If the Agent service should ever crash due to an
unhandled exception, it recovers and immediately restarts.
2.2.3 Analytics
2.2.3.1 New Analytics installer
Starting with Relativity 9.5.133.118, the Relativity Analytics engine installer now uses a response file to
install Analytics on a server. You can use the installer for new installations and upgrades. The response
file installer replaces the setup wizard for the Analytics server. See Installing Analytics.
Note: If you are upgrading from Relativity 9.3.332.21 (CAAT 3.17) or lower, first run the Relativity
9.3.362.9 or 9.4 Analytics server installer using the instructions at Running the Relativity Analytics
installer for versions previous to Relativity 9.5.133.118. Contact Support for this installer. After this step,
then run the Relativity 9.6 response file-based installer.
2.2.3.2 Updating the default SSL/TLS certificate for the Content Analyst
You must update the default SSL/TLS certificate on your Analytics server because Relativity requires a
certificate signed by a trusted certificate authority (CA). By default, the CAAT service runs over an
untrusted SSL/TLS certificate. For more information, see Updating the default SSL/TLS certificate on
page 179.
2.2.3.3 Updating RestUriForCAAT instance setting

As part of upgrading (post-upgrade), you must have a valid URL value entered for the RestUriForCAAT
instance setting. This is the FQDN URL to the web server hosting your Kepler services (e.g.,
https://client.domain.name/Relativity.REST/API).
2.2.3.4 Analytics index enhancements

Starting with Relativity 9.5.196.102, Analytics indexes are now RDO's. There are a few considerations with
this update:
n Indexes will no longer have the default saved searches available to set as the training and search-
able set sources. For legacy indexes that are upgraded, the saved search must be set when editing
the index. If you do not set the searches, you will only be able to build and activate / deactivate the
index (provided it was already populated with the default searches)
n After the upgrade, you will no longer have the option to preserve cluster multiple choice and coher-
ence score fields when deleting the cluster set. They will always be deleted.
n OCR and Go Word filter support has been deprecated from Analytics Indexes. On subsequent pop-
ulations after upgrading, any OCR or Go Word filter set on the Analytics profile will no longer be
applied. If the legacy index was populated with these filters, migrated to an RDO, and then rebuilt or
activated, the filters still apply (they are set on population).
Upgrade Guide 19
n When you upgrade, the Analytics Core install event handlers will create a new RDO for each exist-
ing index and a new RDO for each existing cluster set. These new object types and instances inher-
its permissions from their analogous source objects. For example:
o Analytics Index RDO workspace permissions are copied from Search Index workspace per-
missions
o Analytics Index RDO instance permissions are copied from Search Index instance per-
missions
o Cluster Set RDO workspace permissions are copied from Search Index workspace per-
missions
o Cluster Set RDO instance permissions are copied from the multiple choice cluster field's item
level permissions
2.2.3.5 Email thread visualization

Users must have the Analytics application installed in the workspace, and the Email Author Date ID must
be present for the emails. The Email Author Date ID is only available for emails run through a full analysis
using structured analytics in. The email thread visualization pane will not work for email threads from
previous versions unless a full analysis is run against the structured analytics set containing the emails
after upgrading to Relativity 9.5.41.87 or higher.
2.2.3.6 Multiple structured analytic set results

Beginning in Relativity 9.5.196.102, you can easily store the results for multiple structured analytics sets
and set up views that capture the email threading or repeated content identification results of those
operations.
Consider the following:
n We recommend you set new relational fields (e.g., Destination Email Thread Group, Destination
Email Duplicate ID, and Destination Textual Near Duplicate Group) when creating new structured
analytics sets for email threading or textual near duplicate identification to allow you to easily set up
views that make use of a relational field for each of these sets.
n Upon upgrade, email threading and textual near duplicate results are written to new results fields
that is only created upon running a Structured Analytics Set. These fields can't be manually created
before running the set. This means that it's not possible to create any views, searches, layouts, etc.
that reference these fields prior to completing a set. Additionally, views and searches which ref-
erence these newly created fields don't carry over on workspace creation because Structured Ana-
lytics Sets don't carry over.
Note: This upgrade consideration impacts any Relativity templates that reference the legacy
Structured Analytics results fields.
2.2.4 Applications
Upgrade Guide 20
2.2.5 Audit
Upon upgrade, the Audit application is now available at the instance level to report on admin-level audits.
You must have Elasticsearch installed and configured to use the Audit tab. If you don't have Elasticsearch
installed, you can hide this tab. For more information, see the Data Grid guide.
2.2.6 Authentication
Consider the following for upgrading:
n You no longer see the Authentication Data field in the Users User Information section. You now
enter the information you previously entered here in the individual authentication methods. This per-
mits more versatile and detailed method implementations.
n Note that when you upgrade, Relativity creates a copy of the eddsdbo.User table before making
any modifications. The table is for reference only, and the copy is named based on the Relativity ver-
sion being ungraded from, such as 9_2_AuthenticationUserTableBackupRecord or 9_3_Authentic-
ationUserTableBackupRecord. If after upgrading and making sure all users converted
successfully, you may delete the copy table.
n Use the Authentication Profile system to enable only the protocols you need in an environment. In
some cases the upgrade process may enable more protocols than you want. This is due to the pars-
ing rules for the AuthenticationData column. Specifically, if you are using Active Directory or Client
Certificate authentications in your environment, the upgrade process may also enable Integrated
Authentication. If you don't want the Integrated Authentication, you can remove that provider from
the Authentication Profile after upgrade.
2.2.6.1 User and authentication object permissions

A number of new objects have been introduced, such as Authentication Provider Type, Authentication
Provider, and Login Method. Upon upgrading to Relativity 9.6, permissions are as follows:
n A user, who has the permissions to view the user objects before an upgrade, post upgrade can view
users, authentication provider types, authentication providers, and login methods.
n A user, who has the permissions to edit (or delete, a higher level of permission than edit) the user
objects before an upgrade, post upgrade can edit users and login methods. They can also view
authentication provider types, and authentication providers.
n After upgrade only users in the System Administrators group will have access to view and edit
OAuth2Client objects.
2.2.7 Conversion
Conversion occurs on dedicated conversion agents instead of Invariant workers. You must configure
conversion agents to ensure document conversion works properly in Relativity 9.6. Your agent servers
should also have one conversion complete agent. For more information, see Configuring your conversion
agents.
2.2.8 Data Grid

n If your environment uses Data Grid, you must also upgrade to Data Grid 2.3.3.79 or above when
upgrading to Relativity 9.6. For more information, see Upgrading Data Grid.
Upgrade Guide 21
n Relativity 9.5 introduces the Data Grid Ingestion Management tab to manually retry or cancel Data
Grid write requests that failed as a result of infrastructure problems. This feature includes a new
agent, the Data Grid Worker Agent, that must be installed and configured upon upgrade. There is
also a new instance setting, IngestionTemporaryFileCacheLocation. For more information, see the
Data Grid guide.
n You no longer need to install the DataGridRESTService on the Analytics server to integrate Relativ-
ity Analytics with Relativity Data Grid. If you are upgrading to Relativity 9.6, uninstall the
DataGridRESTService from your Analytics server(s). For more information, see Uninstalling the
Relativity Data Grid service. We also recommend uninstalling the client node from the Analytics
server if that server is only dedicated to Analytics in order to free up resources.
n The Instance Settings table and corresponding Relativity tab now includes the AuditDeleteBatch
Size and AuditMigrateBatchSize instance settings to specify deletion and migration batch sizes for
Data Grid for Audit.
For more information, see the Relativity Data Grid guide
2.2.9 Database schema updates

A number of EDDS and Workspace database tables have been changed, added, or removed to
accommodate new functionality in Relativity. For more information, see Database schema updates for
Relativity 9.6 in the Relativity Community.
2.2.9.1 Deprecated support for EDDSResource database

We have now deprecated the EDDSResource database. Any custom code that writes to the
EDDSResource database is subject to breaking changes in future releases.
If you have implemented any custom code that writes to the EDDSResource database, update it as soon
possible to ensure proper functionality of your applications.
Tables formerly created in this database are now added to the workspace database associated with a
specific operation under the new [Resource] schema. The EDDS and all case databases now include this
new [Resource] schema. It is used for short-lived scratch tables that used to exist on the EDDSResource
database. Additionally, table names haven’t been modified.
Note: Mass Operation handlers that reference tables in this database won’t function properly. You
need to update these handlers to reference the new location under the workspace database with the
[Resource] schema qualifier.
2.2.10 ECA and Investigation

Note the following details:
n A number of processing fields were renamed in the Field Catalog. Renamed fields will cause nam-
ing conflicts.You can address these conflicts through the standard application framework, which is
to either rename the fields or modify their mapping. If you previously processed data into a field that
was renamed, you will have the same data in two different fields. You can address this through a
Mass Replace operation on the affected fields.
n The All Custodians field was renamed to All Custodians_Script in the ECA and Investigation
application. The All Custodians_Script field is a long text field and acts as a another piece of
Upgrade Guide 22
metadata for de-duplicated documents. You should select the new All Custodians_Script field when
running the Update Duplicate Status script, as this will ensure that no de-duplicated documents
make it into review.
2.2.11 Fields
2.2.11.1 Allow HTML fields
Any existing fields with the Allow HTML value set to Yes, you must set the new instance setting
SanitizeHTMLOutput to False in order to add HTML alerts and links when a user opens a document for
review.
2.2.12 File share

Beginning in Relativity 9.5.219.30, file share choices are now file share resource server objects. Upon
upgrade, all file share choices are mapped to resource servers. For more information, see the Admin
guide.
2.2.13 Foreign key removal

In order to improve the performance and usability of document deletion in Relativity, we've removed the
foreign keys from the Document and non-system RDO database tables. This includes artifact, single
object, and multi-object table relationships. Doing this resolves the previous issues involved with globally
locking the Artifact and other tables for the entire duration of a deletion job, which could be lengthy and
could subsequently delay document review. As a result of removing these foreign keys, the delete process
will execute without applying a global lock, and thus no longer interrupts document review in Relativity.
There are three classifications of foreign keys, all of which are affected by this change:
n Keys from the object (Document or RDO) table to the Artifact table.
n Keys on the object table that go to a single object field.
n Keys on multi-object relational f-tables. An f-table stores the link between the objects that are con-
nected by a multi-object field in Relativity. In this way, the only columns in an f-table are those that
store the Artifact ID's of the objects that are linked to each other by that field.
Note: System objects aren't subject to foreign key removal. If the Document object has a foreign
key to the Folder object, that foreign key will remain because Folder is a system object.
2.2.14 IIS
2.2.14.1 HTMLArea application
Relativity Web servers no longer require the HTMLArea Application/Virtual Directory. You can safely
remove the HTMLArea application/virtual directory from IIS on all web servers after the upgrade is
complete.
Upgrade Guide 23
2.2.14.2 SingalR
When running Relativity on IIS 7.5 and older, the SignalR protocol may exhibit performance issues,
including slow responses and connection failures as it falls back to other supported connection protocols.
To resolve this issue, disable dynamic content compression for the Relativity.REST application in the
Compression section in IIS:
Upgrade Guide 24
You can also add the following property to the system.webServer section of the Relativity.REST
web.config file:
<urlCompression doDynamicCompression="false" />
This change will improve SignalR performance on older versions of IIS.
2.2.15 Imaging
Beginning in Relativity 9.5.342.116, the Imaging Request Agent is required to run any imaging job in your
environment. This agent is responsible for performing background tasks when any imaging request is
submitted via mass imaging, image on the fly, or imaging set.
For initial installations of Relativity 9.5.342.116, an Imaging Request Agent is automatically installed and
enabled in your environment. If you're upgrading to Relativity 9.5.342.116 or if at any point you need to
install an additional agent, you need to do so manually.
For more information, see the Imaging guide.

Existing imaging profiles received the following updates based on their imaging method when upgrading
to Relativity 9.6:
If your environment is set up for native imaging, the following changes occur upon upgrade:
n Relativity renames the default imaging profile to Native Default.

n The imaging method is set to Native for all current imaging profiles including Native Default.
Upgrade Guide 25
n Relativity creates a new basic default imaging profile with the following settings:
o Imaging Method: Basic
o Basic Image Output Quality (DPI): 300
o Basic Image Format: TIFF
o Basic Image Height: Original Setting
n For any imaging set with an imaging method set to Basic, the following changes occur:
o The imaging profile previously linked to the imaging set is copied.
o Relativity sets the imaging method for the copied profile to Basic.
o The copied basic imaging profile is linked to the imaging set and Basic is prepended to the
profile name.
If your environment is not set up for native imaging, the following changes occur upon upgrade to
Relativity 9.6:
n Relativity renames the default imaging profile to Basic Default.

n The imaging method is set to basic for all current imaging profiles including Basic Default.
2.2.16 Installation of a certificate on the database server

A certificate called RelativityIdentityCertificate is added to the EDDS database on your primary database
during a first time installation or an upgrade. The authentication framework uses the thumbprint of the
certificate to sign identity tokens, which are JSON web tokens (JWTs). The IdentityCertificateThumbprint
instance setting stores the thumbprint associated with your certificate. For more information, see Instance
setting values on the Relativity 9.6 Documentation site.
You also have the option to use your own authentication token-signing certificate. For more information,
see Optionally configure an authentication token-signing certificate on the Pre-installation page in the
Relativity 9.6 Documentation site.
For a clustered environment, you need to export a copy of your RelativityIdentityCertificate from the
primary database server, and install the certificate to each database server hosting the EDDS. See the
following instructions for more information:
n Import or export certificates and private keys at https://technet.microsoft.com/en-us/lib-

rary/cc754329(v=ws.11).aspx.
n Optionally configure an authentication token-signing certificate on the Pre-installation page in the
Relativity 9.6 Documentation site - These instructions describe the process for configuring your own
custom token-signing certificate, but you can follow these basic steps to install Relativ-
ityIdentityCertificate to each database server in a distributed environment.
2.2.17 Instance settings

If upgrading to Relativity 9.6 from a version prior to 9.3, note that configuration table values are now
referred to as instance settings. Upon upgrade, configuration table values convert to instance settings.
Likewise, the eddsdbo.Configuration table becomes the eddsdbo.InstanceSetting table in SQL Server.
Upgrade Guide 26
Note: If a new 9.6 install or upgrade fails, a back up table, edds.Configuration_backup, exists as a
record of all the instance settings in SQL. Do not use this table for any purpose other than a record in the
event of an install/upgrade failure.
2.2.17.1 Backwards compatibility

For any existing applications that reference the pre-9.6 EDDS.Configuration table, a SQL view,
Configuration, exists to act as a layer on top of the Instance Setting table.
This view contains the same columns as the old Configuration table and you can use it to examine the
information as it was pre-Relativity 9.6.
2.2.18 Processing/Invariant
The following instance settings were modified in Relativity 9.6.202.10:
n The default value of the ProcessingMaxPublishSubJobCountPerWorkspace setting has

changed from 3 to 5.
n The default value of the EnablePublishErrorAutoRetry setting has changed from False to True.
Beginning in 9.6.134.78, the Invariant queue manager requires the Secret Store to be accessible and
unsealed in order to run. Accordingly, you should note the following considerations prior to installation or
upgrade:
n Before running the Invariant installer, you are required to first whitelist and then register any pro-
cessing-related machines for the Secret Store so that those machines can read and write to and
from the store. This includes the Invariant queue manager, all workers, and all machines on which
the RPC is installed. See The Relativity Secret Store Guide for more information on configuring serv-
ers for the Secret Store.
n Once you register all servers, the Invariant installer automatically redacts all username and pass-
word values you enter into the Invariant response file and then populates those values in the Secret
Store. This is the final step of the installation process.
n If the server on which the Secret Store is installed gets restarted, you'll need to unseal the Secret
Store before you run any processing job or run the Invariant installer.
n Upgrading to 9.6.134.78 from an earlier version requires you to run the Invariant installer on your
worker machines one time.
Beginning in Relativity 9.5.309.48, the database installation component has been removed from the
Invariant installer. Accordingly, note the following considerations:
n There is no longer a database install log, and all of the log files that used to be found there are now
found in the queue manager log file.
n The queue manager installation is now responsible for creating the database.
n The queue manager now communicates with the database upgrader to update all databases during
an Invariant upgrade.
n The database directory that was deployed during the installation is no longer needed, so there will
no longer be a database directory deployed on the database server.
Upgrade Guide 27
n The database component no longer holds registry entries; all registry entries that aren't duplicates
are now on the queue manager machine.
n If you previously installed the Invariant database component on its own machine, it's highly recom-
mended that you uninstall the database before upgrading to Relativity 9.5.309.48. If you uninstall
the database after upgrading, you'll delete all Invariant files from the Invariant network share.
n There is a new installation log file called UninstallLegacyDatabasePackage.log, which appears only
once after an upgrade to Relativity 9.5.309.48.
Beginning in Relativity 9.5.253.62, the following changes have been made to processing and should be
noted prior to upgrade:
n You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue man-
ager. Note that the default port for the Invariant Kepler services is 8092. For details, see Enabling
HTTPS for Invariant Kepler Services.
n The Service Bus certificate generation key is required on the queue manager and worker servers as
part of the connection between Invariant and Service Bus. For more information see The Pre-install-
ation Guide in the Pre-installation topic.
n Invariant stores are now deleted automatically when the Relativity workspaces associated with
them are deleted. For more information, see The Relativity Processing Console Guide.
n Publish is no longer a single long-running process and instead is a distributed process that is broken
up into separate jobs, which leads to more stability by removing this single point of failure and allow-
ing the distribution of work across multiple workers. These changes enable publish to operate more
consistently like the other processing job types in the worker manager server, where batches of
data are processed for a specific amount of time before completing each transactional job and mov-
ing on. Note the upgrade-relevant details regarding distributed publish:
o The following instance settings have been added to facilitate the work of distributed publish.
l ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number
of publish jobs per Relativity SQL server that may be worked on in parallel.
l You can't allocate more jobs per workspace than what is allowed per SQL
server. This means that if this value is set to be lower than the value for the
MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity
only allows the maximum of jobs per SQL server.
l The default value is 7. Leaving this setting at its default value will result in
increased throughput; however, we recommend contacting Support before you
upgrade for guidance on what value will be most beneficial to you based on your
environment setup.
l This updates on a 30-second interval.
l If you change the default value, note that setting it too high could result in web
server, SQL server, or BCP/file server issues. In addition, other jobs in Relativity
that use worker threads may see a performance decrease, such discovery or
imaging. If you set it too low, publish speeds may be lower than expected.
l ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish
jobs per workspace that may be worked on in parallel.
Upgrade Guide 28
server. This means that if this value is set to be higher than the value for the
only allows the maximum of jobs per SQL server. For example, if you have a
workspace limit of 4 and a server limit of 8 and all of your workspaces are on the
same SQL server, you will have at most 8 publish sub jobs running concurrently.
environment setup.
o The ProcessingExportMaxThreads instance setting has been deprecated in accordance
with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and Pro-
cessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate
the work of distributed publish.
The following table provides the recommended values for each instance setting per environment
setup:
Envir- Pro- Pro-

onment cess- cess-
setup ingMaxPub- ingMaxPub-
lishSubJobCountPerWorkspace lishSubJobCountPerRelativitySQLServer
Tier 1 3 7
(see the
System
Require-
ments
Guide for
details)
Tier 2 6 12
(see the
System
Require-
ments
Guide for
details)
Relativ- 3 7
ityOne
baseline
Upgrade Guide 29
Beginning in Relativity 9.5.133.118, the following Invariant installation components are new:
n To accommodate multiple communication protocols and to simplify how you configure the worker
manager server in Relativity, the URL field on the Worker Manager Server layout is now called
“Server Name,” and it no longer requires a net.tcp reference that includes a port number. It also
doesn’t require a domain unless the worker manager server and Relativity are on different domain.
For more information, see the Admin Guide.
n You have the option of using the Invariant.Handlers installer to update only the file handlers in your
Invariant instance without having run the entire Invariant installer. The handlers installer is available
for upgrades only. Note that this installer stops and starts workers automatically during the file
syncing process, which means that no manual worker stoppage is required. For more information,
see the Processing installation guide.
Note: A full upgrade to Relativity 9.5.133.118 is required before you can use the handlers
installer to upgrade to a newer set of handlers. Going forward, you won't be required to upgrade
your Relativity version in order to use the handlers installer.
The following changes were made to the worker manager server installation process beginning in
Relativity 9.5.41.87 and should be noted prior to upgrading:
n Each Invariant component has a machine-specific encryption for its connection strings. These are
now found in a folder called LocalSettings, rather than the previous Settings folder, which holds
other config files. The installer now automatically creates the workers’ connection strings, and they
are no longer created in the network share. Note that you will still see a placeholder folder on the net-
work share that doesn’t contain any data.
n There is a new parameter in the Invariant response file called DATABASEINSTALLPATH, which is
the local folder where the Invariant.DBUpdater.exe, Invariant.NIST.InstallUtility.exe, and Invari-
ant.Deployment.exe utilities were automatically installed during database installation. These three
executables have been moved out of the network share to the local machine where the database is
installed.
n After the database and queue manager upgrades are complete, you must run the Invariant installer
on all workers. This is only applicable for upgrades from Relativity 9.4.398.62 (December 21, 2016)
or lower to the full release of Relativity 9.5 (January 25, 2017) and above, meaning all monthly
product updates of 9.5. If you're performing a fresh installation of Relativity 9.5, you will need to run
the installer on each Worker Manager and Worker server; however, any subsequent upgrade will
only require you to run the installer from the Worker Manager server, which will upgrade all worker
servers automatically, thus eliminating the need to run the installer on each server individually.
You can configure the number of concurrent threads dedicated to OCR, which can mitigate CPU
bottlenecks. This is possible through the following changes:
n The MaxConversionThreads column has been removed from the Invariant.dbo.Workstations table,
as it was longer in use since conversion became a separate service.
n The Invariant.dbo.Workstations table now includes a MaxOcrThreads column, which stores the
number of concurrent threads that are allowed to perform an OCR job at a single time. A value of “0”
means unlimited, and any other value limits to that number. The default and recommended value is
0. You should only change this value if the Worker CPU is at 100%, and a performance degradation
during text extraction.
Upgrade Guide 30
The following changes were made to the Invariant installation process:
n The Invariant.DBUodater.exe upgrades both the main Invariant database and RPC stores. It also
handles Relativity stores by setting the stores to Pending, which tells the Workspace Upgrade
Worker agent to pick them up and execute scripts on them. It also produces a detailed XML log file,
which gets created in the install directory and provides information on what happened during the
database upgrade.
n The IDENTITYSERVERURL setting is new in the Invariant response file. This is where you enter the
identity server of the environment used for RPC authentication.
The following processing changes may impact your upgrade experience:
n When you change the URL for the queue manager, you're required to perform an IIS reset on the
Relativity server in order to clear the cache.
n You no longer map processing fields through the processing profile. You now map through a new
Source field on the Field layout, which takes you to a catalog containing the most common fields
that are discovered during processing. Note the following details regarding this change:
o Relativity provides 46 new processing fields, in addition to the 81 fields previously provided,
bringing the total number of fields that are available to map to 127.
o The processing profile no longer contains the Processing Fields associative object list view.
o If you don't install the Processing application, Relativity still allows you to map fields as long as
you've added the worker manager server to the resource pool.
o Relativity transfers any fields mapped in the processing profile named "Default" to the field
mapping table. If the name of the original Default profile has been changed, that profile is still
used. If you haven't mapped any fields on the Default profile in 9.3, and one or more other pro-
files do have fields mapped, Relativity doesn't automatically transfer fields when you upgrade
to 9.5.
n You can now install Microsoft Office 2013 on your worker servers; however, due to a performance
degradation in text extraction when using Office 2013, we recommend that you continue to use
Office 2010 with Relativity 9.5. When you upgrade from Office 2010 to 2013, it's recommended that
you uninstall 2010 and then install 2013. If you don't uninstall 2010 prior to installing 2013, you may
need to do a repair on 2013 in order to get it working properly.
n If you are upgrading from Relativity 9.3 (or a lower version) to 9.5 you may be required to manually
install Visual C++ redistributable packages on the worker servers before running the Invariant
upgrade. For details, see the Worker Manager Server Installation Guide.
n The WebAPI setting in IIS is now set to Anonymous Authentication by default and is no longer set to
Windows Authentication. You must keep this set to Anonymous Authentication in order to publish
documents to a workspace using the worker manager server.
Processing to Data Grid no longer requires the RabbitMQ server. To remove RabbitMQ from your
Relativity environment, see Removing RabbitMQ.
2.2.19 Network load balancing

If you are using cookie-persisted load balancing configurations for Relativity 9.5.162.111 and higher, you
must update the WebClientRequiredCookies instance setting to include the name of the load balancer
Upgrade Guide 31
cookie for the ActiveX viewer.
2.2.20 New UI framework

The 9.6 release provides a single Modernized UI that combines all of the features of the Classic UI, plus
many additional features not available in the Classic UI that make it perform better. For more information,
see Navigation in the Admin guide.
When using the new UI framework, the following Relativity features have been enhanced:
n Cluster visualization
n Dashboards
n Document list and tabs throughout Relativity
n Pivot
n Sampling
n Search panel and search browser
2.2.21 Production
The following section discusses the changes to the Production application on upgrade from Relativity 9.x
to Relativity 9.3+. Certain upgrade changes only affect upgrades from Relativity 9.1 or 9.2 to Relativity 9.6,
and the changes are clearly marked with the affected versions.
Beginning in Relativity 9.3+ you can choose to upgrade only your Production application using a RAP file.
General Production upgrade considerations:
n An upgrade from Relativity 9.x to 9.6 can fail if the workspace you're upgrading already contains a
Relativity field with the name Production. You must rename this field.
n An upgrade from Relativity 9.2 and below to 9.6 can fail if the workspace you're upgrading already
contains a Relativity dynamic object with the name Production Placeholder. You must rename this
object.
n An upgrade from Relativity 9.1 to 9.6 can fail if the workspace you're upgrading already contains a
Relativity dynamic object with the name Production Data Source.
contains a Relativity dynamic object with the name Relativity Color Map. You must rename this
object.
contains a Relativity dynamic object with the name Field Catalog. You must rename this object.
n If you have a full-text index populating the production upgrade stops. Try upgrading again once the
full-text index is finished populating.
n Relativity deduces the First Bates Value and Last Bates Value for all imported and upgraded pro-
ductions.
n If you upgrade from Relativity 9.2 to Relativity 9.6 and you were previously using the Production
Tracker application, review the Production Tracker 9.6 considerations PDF in the Relativity Com-
munity.
Upgrade Guide 32
n Beginning in 9.5.162.111, Productions includes an upgrade step to migrate data from the old
ProductionInformation schema to the new schema introduced in 9.5.162.111.
Changes to agents and objects:
n The Relativity.Core agents for production and branding are upgraded to ADS Deployed agents. The
Relativity.Core agents for production and branding are not available in a Relativity 9.6 environment.
n The Markup Set table is converted to the Markup Set dynamic object.
n The Production Object table is converted to the Production dynamic object.
Changes to pre-existing Productions:
n Any staged or errored productions in an environment are set to a status of New and you must
restage the production before running.
n Productions migrated from Relativity 9.1 and 9.2 receive a legacy placeholder stating, "No Tiff
Included For This Record."
n Productions migrated from Relativity 9.1 to Relativity 9.6 have a data source created containing the
production documents for each produced and errored production.
n If any produced productions contain native files with their Bates numbers previously stored in the
Document table, the Bates numbers for the native files are moved to the Production object, and may
not reflect actual Bates values if those values were overwritten.
n The Production Error field no longer exists on the Production object.
n If you upgrade from an earlier version of Relativity 9.3 and your custom placeholders contain
square brackets, you may see an error the next time you run the production or re-save the custom
placeholder. To correct the error, escape the square brackets using a blackslash and re-run the pro-
duction.
Changes to Production fields and views:
n On upgrade from 9.2 the Produced Documents field exists in the environment, but the field is not
populated.
n The production document view no longer exists.
n The multi-object field Produced Documents is replaced with the Production Information RDO when
upgrading from Relativity 9.2. The field is not deleted from the workspace, but is disassociated from
the production application.
n On upgrade from 9.x to 9.6 the Add Image Placeholder field changes to Use Image Placeholder. If
the Add Image Placeholder field was set to No, it updates to Never Use Placeholders. If the Add
Image Placeholder field was set to Yes, it updates to Always Use Image Placeholders.
Changes to Production permissions:
n Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not auto-
matically gain permissions to the new Production Data Source object, unless they also have the
Manage Object Types permission under Admin Operations. Users need rights to the new Pro-
duction Data Source object to add or edit production data sources after upgrading to Relativity 9.3+.
Upgrade Guide 33
2.2.22 Relativity admin and service account email addresses
Relativity includes the Relativity admin and service account users by default. With the Relativity
9.5.342.116, the default email addresses for these accounts have been updated as follows:
Default user Previous email address New email address

Relativity admin relativity.admin@kcura.com relativity.admin@relativity.com
Relativity service account relativity.serviceaccount@kcura.com serviceaccount@relativity.com
2.2.23 Relativity Desktop Client (RDC)

Beginning in Relativity9.5.292.12, the Relativity Desktop Client uses the same login page process as the
standard website. You must configure the RDC to use a RelativityWebAPI in the Web Service URL
settings. Any legacy Windows-Authentication WebAPIs won't work once the environment is upgraded to
9.5.292.12.
Additionally, if you previously set up an IIS application pool for automatic logins, you no longer need it. You
can configure the RDC to use a /RelativityWebAPI URL set to anonymous authentication in IIS. This will
still pass end users through using Windows Authentication. For more information, see the Desktop Client
Guide.
Note: You can use the RDC downloaded from Relativity 9.5.292.12 with Relativity versions 9.5.41.87 to
9.5.219.30 but you must create a new RDC OAuth2 client to do so. For more information, see the
Desktop Client Guide.
2.2.24 Relativity installer updates

For Relativity 9.5.309.48 and above, you can now set the following options in the RelativityResponse.txt
file used for the primary SQL server during a new installation or an upgrade:
n Email addresses for the Relativity admin and Relativity service accounts - The Relativ-
ityResponse.txt file used for the primary SQL server installation includes the ADMIN_EMAIL and
SERVICEACCOUNT_EMAIL parameters that you can set with these email addresses. If you don’t
specify a value for the Relativity admin or service account, they are set to the default values of
relativity.admin@relativity.com and serviceaccount@relativity.com respectively.
Notes:
o If you want to use a specific email address for the default Relativity admin or service account,
you must enter it for each Relativity upgrade that you perform. If you entered a custom email
address during a previous installation, it is overwritten by current email address that you
entered or by the default email address when this parameter is blank.
o Use different email addresses for the ADMIN_EMAIL and SERVICEACCOUNT_EMAIL para-
meters. If you use the same email address for both parameters, the installation fails.
o The ADMIN_EMAIL parameter functions as the username for the default admin account. If
you leave the ADMIN_EMAIL value blank, this username defaults to relativ-
ity.admin@relativity.com.
n Passwords for the the Relativity admin and Relativity service accounts - The Relativ-
ityResponse.txt file used for the primary SQL server installation includes the ADMIN_PASSWORD
Upgrade Guide 34
and SERVICEACCOUNT_PASSWORD parameters that you can set with new passwords.
Note: To change the ADMIN_PASSWORD or SERVICEACCOUNT_PASSWORD password, you

must also update the associated email address. If you enter a new password but don’t update the
email address, then new password is ignored. For example, if you use an existing or default email
address, then the password remains unchanged. However, you can change the email addresses
for the admin and service accounts without updating the password.
For more information, see the Relativity Installation and Relativity Upgrade guides.
2.2.25 Relativity Processing Console

Beginning in Relativity 9.5, the RPC installer has been reconfigured to request that you enter database
credentials, which it will then validate to create a working connection string.
Specifically, the installer includes a new window in which you'll enter the following:
n Invariant SQL Server name with an optional port number

n Relativity SQL Server name with an optional port number
n EDDSDBO password
2.2.26 Relativity service bus

The Relativity 9.5 infrastructure now includes a new component called the Relativity service bus. This
component uses Service Bus for Windows Service as its underlying framework. Before you upgrade
Upgrade Guide 35
Relativity, you must now install Service Bus for Windows Server on a server or VM that is accessible
throughout your Relativity instance. You must then configure a Service Bus for Windows Server farm in
your environment. For information about prerequisites, see Service Bus for Windows Server in the Pre-
Installation guide.If you have a proxy server or firewall setup in the environment, you must allow
communication to the FQDN of the Windows Service Bus server from the servers you are installing the
Relativity Service Bus or else the installer will fail to upgrade the server.
After installing Service Bus for Windows Server, you can upgrade your primary SQL Server. You can then
install the Relativity service bus by running the upgrade installer on the machine where you installed
Service Bus for Windows Server. Finally, follow the standard instructions for upgrading other Relativity
components. For more information, see the Relativity Service Bus guide.
2.2.27 Required certificates for Relativity

Relativity 9.6 now verifies that all HTTPS services running in your environment have a trusted certificate.
You need to verify the certificates to components of your Relativity installation running HTTPS services to
avoid error messages and insecure-connection icons. For more information, see Required certificates for
Relativity in the Pre-installation guide.
We recommend placing the new Analytics server certificate and testing it prior to the day of the upgrade to
Relativity 9.6. For more information, see Pre-upgrade: Update the default SSL/TLS certificate for CAAT ®
in the Upgrading or installing your Analytics server section.
2.2.28 Scripts
n You must enable the AllowAddOrEditScripts instance setting in order for users to create or edit
scripts. This setting enables or disables the ability to create and edit scripts for all users, including
system admins. For more information, AllowAddOrEditScripts in the instance setting guide.
n Beginning in 9.5.196.102, the Set extracted text size script is no longer available in the Relativity
Script Library. If you have this script installed in a workspace, it is removed upon upgrade. You can
use the Set long text size mass operation in place of this script.
2.2.29 Searching
Upon upgrade to 9.5.133.118, Relativity interprets straight quotes and curly quotes in searching the same.
Previously, if you searched using curly quotes in a long text field using the CONTAINS filter, Relativity
searched for the quote itself instead of grouping terms together. Now, Relativity groups terms between
double quotes together regardless of the quote type. This may mean the number of results in your
searches may change.
2.2.30 Service Host Manager HTTPS configuration

Service Host Manager runs Relativity services on all web and agent servers in your environment. The
services are used by applications like Production and Processing on. If your web and agent servers must
be set up for HTTPS access, special setup is required for Service Host Manager.
For more information, see Service Host Manager on the Relativity 9.6 Documentation site.
2.2.31 System requirements

n As of Relativity 9.5.292.12, we no longer support Internet Explore (IE) 10. Please upgrade to a com-
patible version of IE 11.
Upgrade Guide 36
2.2.32 Telemetry
After you install Relativity 9.6, complete the steps to enable telemetry in your environment. Telemetry
collects metrics for performance, usage, and billing. For more information, see Telemetry on the Relativity
9.6 Documentation site.
Note: Failure to transmit telemetry billing data to Relativity causes Relativity access to be disabled after
seven (7) days. Telemetry lockout is similar to Case Statistics Manager lockout. If your security setup
doesn't allow access to public internet, contact Relativity support to configure offline-billing.
2.2.33 User and group operations

Relativity 9.6.50.31 and above now include enhanced operations for adding users to groups, or removing
them from groups. By default, user and group operations are disabled. Contact Client Services for
information about enabling this functionality in your Relativity environment.
The enhanced user and group operations run as jobs handled by agents. They require that you manually
add the following agents on a first-time upgrade to Relativity 9.6.50.31 and above:
n Distributed Job Manager - add only one of these agents to your Relativity environment.
n Distributed Job Worker - scale the number of the agent as necessary. In general, you may want
to add three agents per 1,000 workspaces.
Be sure to enable the agents after you add them to your environment. For detailed steps, see the Agents
guide.
Relativity can also provide notifications about the status of a completed job using the Relativity service
bus. In environments running an SMTP server, Relativity sends an email message notifying you when a
job is completed. This message contains a link that you can use to retry the job if an error occurs. You
must be logged into Relativity before you click the retry link. Additionally, you can obtain the retry link on
the Errors tab when a job fails.
You must also set the RelativityInstanceURL instance setting if you want to users to receive email
notifications. Ensure that the value for this setting is the URL for your Relativity instance. For example, the
URL would have the format: https://example.relativity.com/Relativity. The user receiving the notification
must have access to this URL. For more information, see the Instance Setting Guide.
Note: To troubleshoot these distributed jobs, see Relativity service bus entities in the Service Bus
guide.
2.2.34 Viewer (ActiveX)

Beginning in Relativity 9.5.196.102, you must install Microsoft .NET 4.6.2 on all of the machines that need
access to the ActiveX viewer. You must also install the new ActiveX viewer installation kit, which includes
the Visual C++ 2015 redistributable, from the Workspace Details tab. You can't use the Relativity
9.5.196.102 viewer with earlier versions of Relativity. Also, earlier versions of the ActiveX viewer aren't
compatible with Relativity 9.5.196.102.For more information, see Legacy viewer installation in the
workstation configuration guide.
Note: If you have a client machine that accesses multiple instances of Relativity that require different
versions of the ActiveX viewer, the corresponding ActiveX viewers must be installed. To ensure proper
viewer functionality, you must close their browsers before they switch from one version to the next.
Upgrade Guide 37
2.2.35 Viewer (ActiveX and HTML)
Beginning in 9.5.309.48, the following Viewer changes were made: The default instance setting called
HideDownloadNativeFileRadioButton disables the native file radio button in the document viewer toolbar.
This setting hides the Native radio button regardless if you have permission to download documents or
not. If you have the right permissions, click the file icon next to the document identifier in the viewer to
download the native file to your device.
For users who haven't upgraded their Relativity version since the general release of Relativity 9.2, note
that, beginning in the Relativity 9.2.337.3 - September 30, 2015 product update, the following is
applicable.
When viewing documents with an .HTM, .HTML, or .XML extension in Native mode, the viewer displays
the raw file markup instead of rendering the content.
Control this option with the TreatHtmlAndXmlAsText instance setting, which is set to True by default.
When set to True, this prevents JavaScript from executing when viewing these documents in the Native
mode in the viewer.
2.2.36 Windows or Integrated Windows authentication

If your Relativity installation currently uses Windows authentication or Integrated Windows authentication,
you must set the UseWindowsAuthentication instance setting to True after upgrading your environment.
For more information, see the Instance setting guide on the Relativity 9.6 Documentation site.
You may want to configure your environment so that some servers use Windows authentication, while
others don't use it. In this case, you need to add another row for this instance setting to the Instance
setting table, update the machine name in this new row, and then set the value to True or False based on
the Windows authentication requirements for the server.
In addition, you can set the WindowsAuthIpRange instance setting, which specifies a group of IP
addresses that Relativity uses to validate the address of the user during login. If a request originates from
an IP address added to the WindowsAuthIpRange instance setting, the server uses Windows
Authentication to log the user in to Relativity. Relativity uses forms authentication to log in the user, when
the IP address is outside the specified range. For more information, see Instance settings on the Relativity
2.2.37 Windows Service Bus 1.1 with TLS 1.2 Support

You can upgrade your Service Bus for Windows Server to use Transport Layer Security (TLS) 1.2. For
more information, see Add support for TLS 1.1 and TLS 1.2 on Service Bus for Windows Server 1.1
(https://support.microsoft.com/en-us/help/4077554/add-support-for-tls-1-1-and-tls-1-2-on-service-bus-
for-windows-server).
2.2.37.1 Prerequisites for Service Bus 1.1 with TLS 1.2 Support
n Verify that .NET 4.6.2 is installed in your environment. You must install .NET 4.6.2 before you begin
upgrading to Service Bus 1.1 with TLS 1.2. This service bus upgrade requires .NET 4.6.2. For more
information, see Upgrading Relativity to .NET 4.6.2.
n Verify that you are running Windows Server (version 2012, 2012 R2, or 2016) and Microsoft SQL
Server (version 2012 or 2016). If your environment, doesn't meet these requirements, see Work-
arounds for Service Bus 1.1 with TLS 1.2 on the next page.
2.2.37.2 Upgrading to Service Bus 1.1 with TLS 1.2 Support

Use the following steps to upgrade to Service Bus 1.1 with TLS 1.2 Support:
Upgrade Guide 38
1. Remove all servers from the farm. For more information, see Leaving a Farm (https://msdn.-
microsoft.com/en-us/library/dn441430.aspx) on the Microsoft site.
2. Uninstall Service Bus for Windows 1.1 CU1. For more information, see Removing the Service Bus
for Windows Server from a Node in a Farm in Uninstalling (https://msdn.microsoft.com/en-us/lib-
rary/dn441431.aspx) on the Microsoft site.
3. Uninstall Microsoft Azure Surface Fabric 1.0.
4. Upgrade the SQL Server to support TLS 1.2. For more information, see TLS 1.2 support for
Microsoft SQL Server (https://support.microsoft.com/en-us/help/3135244/tls-1-2-support-for-
microsoft-sql-server) on the Microsoft site.
5. Delete the following folder from your server, if it exists on it:
C:\Program Files\Service Bus
6. Install Service Bus for Windows Server 1.1 with TLS 1.2 support by using the WebPI. For more
information about WebPI, see the Pre-Installation guide.
7. Run the Invoke-SBFarmUpgrade cmdlet. Open Service Bus PowerShell and run these commands:
$mycert=ConvertTo-SecureString -string myPassword -force -AsPlainText

Invoke-SBFarmUpgrade -SBFarmDBConnectionString 'Data Source=localhost\sqlexpress;Initial Cata-
log=SbManagementDB;Integrated Security=True' -CertificateAutoGenerationKey $mycert
See the following confirmation message:
8. Rejoin all servers to the farm. For more information, see the Relativity Pre-Installation Guide.
2.2.37.3 Workarounds for Service Bus 1.1 with TLS 1.2

If your Relativity environment doesn't meet the recommendations provided by Microsoft for upgrading to
Service Bus 1.1 with TLS 1.2 Support, you may want to consider a workaround. This section discusses
current Microsoft recommendations and possible workarounds.
Microsoft recommends using Windows Server (version 2012, 2012 R2, or 2016), and Microsoft SQL
Server (version 2012 or 2016) with the Service Bus 1.1 with TLS 1.2 Support update. As of February 5,
2018, Relativity has tested the Service Bus TLS 1.2 update with Relativity 9.5 using the following platform
combinations:
n Windows Server 2012 and SQL Server 2012

n Windows Server 2012 R2 and SQL Server 2016
Upgrade Guide 39
While we aren't aware of any issues on these platforms (including SQL Server 2014), Relativity can't
guarantee compatibility outside of Microsoft’s official support matrix. Future updates from Microsoft may
impact the stability of your infrastructure if you aren't running the service bus on a supported OS and SQL
platform.
In this case, you may want to consider one of the workarounds provided in the following sections.
Apply TLS registry settings

You can use the server registry settings to control turning off TLS 1.0 and 1.1 for internet traffic to IIS.
Windows offers the following groups of TLS settings:
n Client communication - determines which TLS protocols are used for outbound connections from
the server that is traffic to the service bus server.
n Server communication - determines which TLS protocols can be accepted that is from internet
traffic to IIS.
The registry settings for these TLS protocols are located under the following key prefix:
HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
For information about the registry keys and testing your environment after applying them, see Disabling
cryptographic protocols for PCI compliance (focused on SSL 3.0 and TLS 1.0) blog post at
https://www.johnlouros.com/blog/disabling-cryptographic-protocols-for-pci-compliance.
You can also use the IISCrypto tool to configure TLS protocols. Clear the Set Client Side Protocols
checkbox when using IISCrypto to configure your web servers. IISCrypto uses the Windows registry keys
listed above to control the available TLS protocols.
Note: For server communication, you must keep TLS 1.0 and 1.1 enabled on the server where
Windows service bus is installed. This approach can't be used in smaller environments where the web
server and the service bus are installed on the same VM. We recommend installing the service bus on
its own dedicated VM if you want to control TLS settings using registry keys.
Use a load balancer

If your primary use of TLS 1.2 would be for internet-facing traffic, you may want to consider using a load
balancer. Relativity server traffic may be a lower concern in these cases. By placing a load balancer (such
as an F5 or NGINX) in front of Relativity, you can restrict all web traffic to TLS 1.2. Many load balancers
provide you with options to choose which TLS protocols that run on the network.
2.2.38 Workers
The LongRunningJobTimeout setting enables Invariant to terminate some stuck jobs. Specifically, this
value determines the amount of time (in milliseconds) that a worker will work on a job before Invariant
terminates that job. The default value is 180,000 milliseconds (30 minutes).
You may want to adjust this value if you have large documents that need additional time for processing, or
if you need a shorter feedback loop. If you need to adjust this value, you can manually go into the
AppSettings table and increase it accordingly. Previously, Invariant workers could get into a state in which
they no longer reported progress and no longer completed work, which then required manual intervention
to terminate those processes. When Invariant uses the LongRunningJobTimeout setting to stop a job,
Relativity provides an error message to the processing user informing them that the timeout limit was
reached.
Upgrade Guide 40
The Conversion Threads in Use column no longer appears on the Worker Status tab. Additionally, on the
worker server page, you can no longer designate a worker for conversion work. To configure your
environment for conversion, see Configuring your conversion agents.
2.2.39 Worker manager queue

Revisions in the queue manager code have led to the following enhancements:
n A reduction in the volume of connections to the SQL Server

n A reduction in lock waits and thread pool waits
n A general increase in queue parallelism
n A reduction in the number of queries per second hitting the SQL Server
There is no reduction or change in actual queue functionality as a result of these changes. Likewise, the
user experience with the queue manager hasn't changed, with the exception of potential performance
increases, depending on the size of your environment.
2.2.40 Worker manager server

Document conversion no longer occurs on the worker manager server. You cannot modify the priority of
the following conversion jobs on the worker manager server: Pre-convert, Conversion on-the-fly, Mass
conversion, and Conversion. Instead, you must install Service Bus for Windows Server and configure
conversion agents. For more information, see Configuring your conversion agents on page 124.
The Worker manager page no longer displays the following conversion fields: pre-convert, conversion on-
the-fly, mass conversion, and conversion.
Beginning in Relativity 9.5.133.118, the URL field on the Worker Manager Server is now called Server
Name and displays the fully-qualified server name as the location of the Invariant API on the server.
2.2.41 Workspace upgrade queue

The Workspace Upgrade Queue includes the following columns:
n Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Work-
space Upgrade Worker agent. The possible values in this column are the same as for the work-
space upgrade. This field is empty if you don't have Processing installed.
n Current Store Version - the version of Invariant you are upgrading to.
2.2.42 Conversion
agents.
2.2.43 Data Grid

Upgrade Guide 41
Data Grid guide.
2.2.44 Database schema


2.2.45 Document table trigger removal

If you're upgrading from Relativity 8.1, note that 8.1 included enhancements that may affect certain areas
of your existing environment when you upgrade. Improvements to the database schema make Relativity
run faster in 9 than in previous versions. If your environment contains custom-developed functionality that
involves the RelationalIndex_X tables or explicitly uses the RI_X columns in the Document tables, then
you should refer to the Document table trigger removal documentation.
2.2.46 File share

Upgrade Guide 42
guide.

2.2.48 IIS
remove the HTMLArea Application/Virtual Directory from IIS on all web servers after the upgrade is
complete.
Upgrade Guide 43
2.2.49 Imaging
Upgrade Guide 44
Existing imaging profiles received updates based on their imaging method when upgrading to Relativity
9.6. If your environment is set up for native imaging, the following changes occur upon upgrade:

n Relativity creates a new Basic Default imaging profile with the following settings:
n For any imaging set with it an imaging method set to Basic, the following changes occur:
o The imaging profile the imaging set was linked to is copied.
o Relativity sets the copied profile's imaging method is set to Basic.
o The copied profile is prepended with Basic to the profile name.
Relativity 9.6:

n The imaging method is set to Basic for all current imaging profiles including Basic Default.
Upgrade Guide 45
2.2.50 Imaging sets
If you upgrade to Relativity 9.6 and your environment contains imaging sets with errors, the Retry errors
button on the Imaging Set console is disabled, and you won't be able to retry those errors in Relativity 9.6.
You will, however, be able to re-run the imaging set that contains the errors after you upgrade to Relativity
9.6.
For more information, see the Imaging section of the Relativity Admin Guide.


Beginning in Relativity 9.5.309.48, the database installation component has been removed from the
Invariant installer. Accordingly, note the following considerations:
n There is no longer a database install log, and all of the log files that used to be found there are now
found in the queue manager log file.
n The queue manager installation is now responsible for creating the database.
n The queue manager now communicates with the database upgrader to update all databases during
an Invariant upgrade.
n The database directory that was deployed during the installation is no longer needed, so there will
no longer be a database directory deployed on the database server.
n The database component no longer holds registry entries; all registry entries that aren't duplicates
are now on the queue manager machine.
n If you previously installed the Invariant database component on its own machine, it's highly recom-
mended that you uninstall the database before upgrading to Relativity 9.5.309.48. If you uninstall
the database after upgrading, you'll delete all Invariant files from the Invariant network share.
Upgrade Guide 46
n There is a new installation log file called UninstallLegacyDatabasePackage.log, which appears only
once after an upgrade to Relativity 9.5.309.48.
Beginning in Relativity 9.5.292.12, the following infrastructure changes have been made to processing
and should be noted prior to upgrade:
n ProcessingMaxPublishSubJobCountPerSQLServer - the new default value of this instance setting

is 7. For information on configuring this setting, see the Processing User Guide.
n ProcessingMaxPublishSubJobCountPerWorkspace - the new default value of this instance setting
n Microsoft Project is no longer a required application to install for Invariant. Processing or Imaging a
project file when it is not installed will result in a detailed error.
n Microsoft Visio is no longer a required application to install for Invariant. Processing or Imaging a
visio file when it is not installed will result in a detailed error.
n The default value of the WorkerFileCheckTimespanInMinutes entry in the AppSettings table has
changed from 2 to 15 (minutes) to reduce how often the Queue Manager needs to check the file
share for changes.
n The DryRun validation doesn't work when you upgrade from a version below 9.5.292.12 to a ver-
sion after 9.5.292.12, and certain folders and files in processing databases might be deleted if you
attempt to run it. For this reason, we recommend that you not run the DryRun validation.
Upgrade Guide 47
environment setup.
environment setup.
setup:
Upgrade Guide 48
Envir- Pro- Pro-
onment cess- cess-
Tier 1 3 7
(see the
System
Require-
ments
Guide for
details)
Tier 2 6 12
(see the
System
Require-
ments
Guide for
details)
Relativ- 3 7
ityOne
baseline
Upgrade Guide 49
database upgrade.
installed.
Upgrade Guide 50
to 9.5.

n Dashboards
n Pivot
n Sampling
2.2.54 Processing
The following infrastructure items are new to processing in Relativity 9.3:
n Processing now uses Invariant 4.3.

Upgrade Guide 51
n For users who haven't upgraded their Relativity version since the general release of Relativity 9.2,
note that, beginning in Relativity 9.2.237.3 (the product update released on 6/24/2015), Invariant
servers require .NET Framework 4.5.1.
n You will now use an installation file to install the worker manager server instead of the install wizard
you previously used. For more information, see the Worker Manager Server Installation Guide.
2.2.55 Production
The following changes occur to existing productions on upgrade:
n On upgrade to Relativity 9.6 the Relativity.Core agents for production and branding are upgraded to
ADS Deployed agents. The Relativity.Core agents for production and branding are not available in a
9.3+ environment.
n Production sets you ran before upgrading to Relativity 9.6 aren't available to select for merging with
new production sets when you select the new Existing production numbering choice. Any custom
production work-arounds break upon upgrade. For more information on new productions func-
tionality, see the Admin guide.
Upgrade Guide 52
n Any preexisting production fields are converted to a production data source upon upgrade.
munity.


You may need to install additional certificates to components of your Relativity installation running HTTPS
services to avoid error messages and insecure-connection icons. For more information, see the Pre-
installation Guide.
2.2.58 Scripts
n Creating or editing scripts is controlled by the AllowAddOrEditScripts instance setting. You must
enable this instance setting to give users the ability to create or edit scripts within a workspace. For
more information, seeAllowAddOrEditScripts in the instance setting guide.
2.2.59 Searching
Upgrade Guide 53
2.2.60 Servers
There are a number of new server types installed automatically with Relativity 9.6:
n Worker manager server - this uses workers to perform imaging, conversion, and all phases of pro-
cessing, including inventory, discovery, and publish. This is a required component of Relativity 9.6.
If you are not licensed for processing, then the worker manager server only handles document con-
version and imaging. For more information, see Worker manager server installation doc-
umentation.
n Worker - this is the machine a worker manager server uses to complete imaging, document con-
version, and processing jobs. Workers are designed to centralize and streamline some of the jobs
that used to be performed exclusively by agents. When you add a worker manager server to your
Relativity environment, you specify the workers that you want that worker manager server to gov-
ern. Thus, it's impossible to add workers without adding a worker manager server. For more inform-
ation, see the Servers section of the Relativity Admin Guide.
n Cache location server - this temporarily stores natives, images, productions, and other file types
the viewer uses. Add cache location servers to the resource pools that are associated with work-
spaces. You must provide a valid UNC path for the location of your cache. For more information,
see the Servers section of the Relativity Admin Guide..

2.2.62 Structured Analytics

If upgrading to Relativity 9.6 from a version prior to 8.2, Relativity automatically updates the Minimum
similarity percentage value for Structured Analytics textual near duplicate identification to the new
minimum value of 80 if it is currently set between 70-79. See Creating a structured analytics set in the
Analytics Guide.

n As of August 31, 2017, we no longer support Internet Explore (IE) 10. Please upgrade to a com-
2.2.64 Telemetry
Upgrade Guide 54

You must download and install the latest version of the Viewer Installation Kit. For more information, see
Legacy viewer installation in the workstation configuration guide.

applicable.
mode in the viewer.

2.2.68 Workers
reached.
Upgrade Guide 55




2.2.72 Viewer
The document viewer has been dramatically improved and you are no longer required to download or
install any browser plug-ins in order to review documents in this new viewer. In addition, there are some
functionality enhancements available in the new viewer. For more information, see the Viewer section of
the Relativity Admin Guide.
Upgrade Guide 56
2.2.73 Workers

Conversion, and Conversion. Instead, you must install Service Bus for Windows Server and configure
2.2.75 Workspace Upgrade Queue

2.2.76 Workspaces
Workspaces include a new required field called Default Cache Location. The default cache location is a
UNC path to the location on your network where the natives, images, productions, and other file types
used by the viewer are temporarily stored. You can select any one of the cache locations included in the
resource pool chosen for the workspace. For more information, see the Workspaces section of the
Relativity Admin Guide.

Upgrade Guide 57

Learn more about the changes to your Relativity 7.x environment after you upgrade to Relativity 9.6. This
section also includes post-upgrade processes you'll need to follow.
n Agent service
n Analytics on the next page
n Applications
n Audit on page 61
n Conversion
n Database schema
n dtSearch index considerations on page 83
n Foreign key removal on page 84
n IIS on page 86
n Imaging on page 84
n Processing/Invariant
n License Relativity and Processing on page 92
n New UI framework on page 92
n Production on page 93
n RAR upgrade notes on page 93
n Relativity service bus on page 94
n Required certificates for Relativity on page 94
n Scripts
Upgrade Guide 58
n Searching on page 95
n System requirements on page 95
n Windows or Integrated Windows authentication on page 96
n Viewer on page 94
n Viewer (ActiveX) on page 95
n Upgrade custom applications or code on page 96
n Workers
n Workspace Upgrade Queue
2.3.1 Agent service

2.3.2 Analytics
Relativity 9.3 includes a Textual Near Duplicate Identification algorithm with the following benefits:
n The new algorithm can greatly improve performance for both large and complex data sets.
n With the new algorithm you can scale your Analytics server by adding CPU cores and RAM in order
to achieve faster performance.
Prior to Relativity 9.3, scaling environments did not impact performance. Without scaling past 8 cores, you
should experience performance comparable to pre-9.3 on most data sets. The Textual Near Duplicate
Identification algorithm in Relativity 9.3 uses different, more efficient methods to obtain similar results.
However, results may differ slightly from pre-9.3 results if a Full Analysis is run against a preexisting
structured analytics set. If you need preexisting results use an Incremental Analysis instead. The
incremental analysis keeps the pre-9.3 results for all preexisting documents, but the newly added
documents use the new algorithm to match with existing groups.
Note the following when upgrading to Relativity 9.6:
n In the Relativity Applications Library, the Analytics application contains the structured data analytics
functionality, and the Analytics Core application contains Analytics profiles, repeated content fil-
ters, and Analytics categorization sets.
Note: On upgrade to Relativity 9.6, you can choose whether or not to include the Analytics
application (structured data analytics). The Analytics Core application deploys automatically.
n Beginning in Relativity 8, Primary Language Identification (PLI) is no longer supported. As a result,

you don't have to import PLI data into Relativity or set up a search index or categorization set to use
Upgrade Guide 59
PLI anymore. Instead, you can use the language identification operation when creating a Structured
Data Analytics set.
n Content Analyst 3.14 is required to use Analytics in Relativity 9.6.
See the Analytics Guide for more information on Language Identification.
2.3.2.1 New Analytics installer

Starting with Relativity 9.5.133.118, the Relativity Analytics engine installer now uses a response file to
install Analytics on a server. You can use the installer for new installations and upgrades. The response
file installer replaces the setup wizard for the Analytics server. See Installing Analytics.
page 179.


this update:
missions
Upgrade Guide 60
missions
missions
level permissions


operations.
2.3.3 Applications
2.3.4 Audit
Upgrade Guide 61

2.3.6 Conversion
agents.
2.3.7 Data Grid

Data Grid guide.
Upgrade Guide 62



Upgrade Guide 63
2.3.10 Fields
review.
2.3.11 File share

guide.

2.3.13 IIS
complete.
Upgrade Guide 64
2.3.13.2 SingalR
Upgrade Guide 65
web.config file:
2.3.14 Imaging

to Relativity 9.6:

Upgrade Guide 66
profile name.
Relativity 9.6:




Upgrade Guide 67

environment setup.
Upgrade Guide 68
environment setup.
setup:
Envir- Pro- Pro-

onment cess- cess-
Tier 1 3 7
(see the
System
Require-
ments
Guide for
details)
Tier 2 6 12
(see the
System
Require-
Upgrade Guide 69
Envir- Pro- Pro-
onment cess- cess-
ments
Guide for
details)
Relativ- 3 7
ityOne
baseline
installed.
Upgrade Guide 70
database upgrade.
to 9.5.
Upgrade Guide 71


n Dashboards
n Pivot
n Sampling
2.3.20 Production
object.
Upgrade Guide 72
object.
ductions.
munity.
duction.
populated.
Upgrade Guide 73



9.5.292.12.
Guide.

Upgrade Guide 74
Notes:



Upgrade Guide 75
n EDDSDBO password


Upgrade Guide 76
2.3.27 Scripts
2.3.28 Searching


2.3.31 Telemetry

Upgrade Guide 77
guide.
guide.


applicable.
mode in the viewer.
Upgrade Guide 78

arounds for Service Bus 1.1 with TLS 1.2 on page 39.

Upgrade Guide 79


combinations:

platform.

Upgrade Guide 80
traffic to IIS.
Use a load balancer

2.3.37 Workers
reached.


Upgrade Guide 81


2.3.41 Conversion
agents.
2.3.42 Database schema


Upgrade Guide 82
2.3.43 dtSearch index considerations

There is a new paradigm to configuring and building dtSearch indexes. Keep these items in mind about
your indexes after you upgrade:
n For indexes built in Relativity 5.9 or below, you must perform a Full Build for them to work normally.
n Any active indexes built in Relativity 6.2 or above continue work normally.
n After upgrading, you must initially perform a full build of a dtSearch index before you are able to run
incremental builds. You can then perform incremental builds, which follow the new paradigm.
n For indexes that are in progress or in an error state when you upgrade, you must perform a Full
Build.
n Indexes with document level errors continue to work normally.
2.3.43.1 Adding dtSearches as choices to resource pools

When upgrading from Relativity 7.x, you need to create a choices with paths to your dtSearch repositories,
and then add these choices to the appropriate resource pools.
Use the following procedure to add dtSearches to resource pools:
1. Log in to Relativity.
2. From Home, click the Choices tab.
3. Click New Choice.
4. In the Field option, select dtSearch Index Share Location.
5. In the Name option, enter the UNC path to the dtSearch repository that is shared with the Relativity
Services Account. The share must give this account read and write permissions.
6. Click Save.
7. Click the Resource Pools tab.
8. Click on the name of the resource pool where you want to add the dtSearch choice.
9. On the details view, locate the dtSearch Index Share Locations section.
10. Click Add to display the Select dtSearch Index Share Locations dialog.
11. Select the checkbox for your dtSearch Index Share Location and click OK. The details view now dis-
plays this share location in the dtSearch Index Share Locations section.
2.3.44 File share

guide.
Upgrade Guide 83
2.3.46 Imaging
Upgrade Guide 84
Existing imaging profiles received updates based on their imaging method when upgrading to Relativity
9.6.

n Relativity creates a new Basic Default imaging profile with the following settings:
n For any imaging set with it an imaging method set to Basic, the following changes occur:
o The imaging profile the imaging set was linked to is copied.
o Relativity sets the copied profile's imaging method is set to Basic.
o The copied profile is prepended with Basic to the profile name.
Relativity 9.6:

n The imaging method is set to Basic for all current imaging profiles including Basic Default.
Upgrade Guide 85

2.3.48 IIS
remove the HTMLArea Application/Virtual Directory from IIS on all web servers after the upgrade is
complete.
Upgrade Guide 86
Beginning in Relativity 9.5.292.12, the following infrastructure changes have been made to processing
and should be noted prior to upgrade:
n ProcessingMaxPublishSubJobCountPerSQLServer - the new default value of this instance setting

n ProcessingMaxPublishSubJobCountPerWorkspace - the new default value of this instance setting
n Microsoft Project is no longer a required application to install for Invariant. Processing or Imaging a
project file when it is not installed will result in a detailed error.
n Microsoft Visio is no longer a required application to install for Invariant. Processing or Imaging a
visio file when it is not installed will result in a detailed error.
n The default value of the WorkerFileCheckTimespanInMinutes entry in the AppSettings table has
changed from 2 to 15 (minutes) to reduce how often the Queue Manager needs to check the file
share for changes.
n The DryRun validation doesn't work when you upgrade from a version below 9.5.292.12 to a ver-
sion after 9.5.292.12, and certain folders and files in processing databases might be deleted if you
attempt to run it. For this reason, we recommend that you not run the DryRun validation.
Upgrade Guide 87
environment setup.
environment setup.
Upgrade Guide 88
setup:
Envir- Pro- Pro-

onment cess- cess-
Tier 1 3 7
(see the
System
Require-
ments
Guide for
details)
Tier 2 6 12
(see the
System
Require-
ments
Guide for
details)
Relativ- 3 7
ityOne
baseline
Upgrade Guide 89
installed.
Upgrade Guide 90
to 9.5.
When upgrading the Processing application from 7.5 to Relativity 9.6, we strongly recommend that you
first complete any outstanding processing sets in 7.5 before upgrading. However, note the following if you
perform an upgrade and outstanding processing sets exist in 7.5:
n All documents published in 7.5 will retain the 7.5 document numbering format of nine digits.
n All documents published or republished in Relativity 9.6 will have the new 10 digit document num-
bering format. This new format extends to the Attachment Document ID, Parent Document ID, and
Group ID fields.
n Documents republished in Relativity 9.6 could potentially be duplicated with the new document num-
bering format.
n Reference fields such as the Attachment Document ID, Parent Document ID, and Group ID on doc-
uments republished in Relativity 8 may not accurately reference the correct documents.
Specific versions of Invariant are exclusively compatible with specific versions of Relativity. For this
reason, don't attempt to upgrade Invariant independent of Relativity, as doing so will result in significant
issues. For example, don't upgrade from Invariant 3.3, which is supported by Relativity 8.2, to Invariant 4.0
without also upgrading to Relativity 9.0. The following table breaks down which versions of Invariant are
supported by which versions of Relativity:
Invariant version Relativity version

Invariant 3.0 Relativity 7.5
Upgrade Guide 91
Invariant 4.0 Relativity 9.0/9.1
2.3.50 License Relativity and Processing

As part of the upgrade to Relativity 9.6, you need to apply a new Relativity and optional Processing license
to your installation.
2.3.50.1 Relativity installations only

If you aren't using Processing in your Relativity installation, run the Relativity Database Upgrader on all
databases, then request a new Relativity license key from Relativity Client Services, and apply the
activation key. For more information, see the Relativity Licensing guide.
2.3.50.2 Relativity installations with Processing

If you are running Processing as part of your Relativity installation, complete the following steps to
upgrade your licenses:
1. Run the Relativity installer on the Primary SQL Server as described in Upgrading your SQL Server
on page 127.
2. Run the Relativity Database Upgrader only on the master (EDDS) database. See .
3. Request a new Relativity license key from Relativity Client Services, and apply the activation key.
For more information, see the Relativity Licensing guide.
4. Request a new Processing license key from Relativity Client Services, and apply the activation key.
Note: You must apply the new Processing license before running the Relativity Database
Upgrader. If you don't complete this step, the Relativity Database Upgrader can't upgrade your
Processing application.
5. Run the Relativity Database Upgrader on your workspace databases.

Upgrade Guide 92
n Dashboards
n Pivot
n Sampling
2.3.52 Production
Relativity.Core agents for production and branding are not available in a 9.3+ environment.
n If you upgrade from Relativity 7.x to Relativity 9.6 and you were previously using the Production
munity.
2.3.53 RAR upgrade notes

You can upgrade an Assisted Review project while review is in progress for a round or between rounds.
No work is required to ensure that Assisted Review operates properly in Relativity 9.6 before or after you
Upgrade Guide 93
upgrade Assisted Review from Relativity 7.5; however, it may be helpful to note the following tasks that
Relativity automatically completes when you upgrade Assisted Review. Relativity:
n Gives old rounds a round type value of 7.5.

n Creates an Assisted Review saved searches folder if it didn't already exist.
n Creates a project-specific saved searches folder.
n Copies the project saved search to the new folder and creates four saved searches if categorization
has already occurred.
n Sets all issues to a Medium Importance level.
n Replaces the Net Change graph in the Round Summary with Volatility. Note that it will take several
rounds to generate volatility information; for example, if you upgrade prior to starting the fourth
round, volatility displays in the report after you finish the fifth round.
Note: When upgrading from version 7.5 to 9, every project that is currently active (in the middle of a
round) will receive an error until you set the positive choice for designation.


You may need to install additional certificates to components of your Relativity installation running HTTPS
services to avoid error messages and insecure-connection icons. For more information, see the Pre-
installation Guide.
2.3.56 Viewer
Relativity 9.6 uses Oracle Outside In version 2016.2. When you upgrade to Relativity 9.6, you can install
the new version of the viewer using the steps described in the Workspace Configuration guide. Previous
versions of the viewer aren't upgraded, but you can run two versions of the viewer concurrently, so there's
no need to uninstall previous versions.
Upgrade Guide 94
2.3.57 Searching
2.3.58 Scripts
n Creating or editing scripts is controlled by the AllowAddOrEditScripts instance setting. You must
enable this instance setting to give users the ability to create or edit scripts within a workspace. For
more information, see AllowAddOrEditScripts in the instance settings guide.

n As of August 31, 2017, we no longer support Internet Explore (IE) 10. Please upgrade to a com-

2.3.61 Configure the viewer drawing delay

If you anticipate multiple users using the same machine at the same time to perform a review, you can use
a registry value to establish a drawing delay in the image viewer. This is only recommended when the
standard refresh rate causes CPU utilization issues,which should only occur in a Citrix environment.
This value represents the number of milliseconds between calls to redraw the screen. In previous versions
of Relativity, the image viewer behaved as though this value were set to 250. Increasing this value will
reduce CPU usage when creating and/or modifying redactions and highlights, but it will also result in a
choppier experience.
Changes to this value are not reflected in real-time, so you'll have to reload the image viewer for changes
to take effect.
To configure the drawing delay, perform the following steps:
Upgrade Guide 95
1. Click the Start button and type regedit in the search box, then click Enter.
2. Navigate to the appropriate location:
n If you're using a 64-bit OS, navigate to HKEY_LOCAL_
MACHINE\SOFTWARE\Wow6432Node\kCura\ImageViewer
n If you're using a 32-bit OS, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\kCur-
a\ImageViewer
Note: If this is your first time using this feature, the ImageViewer registry key won't exist and you'll
have to create it. To create this new key, right-click the kCura folder and hover over New, then
click Key.
3. Right-click the ImageViewer folder and hover over New, then click DWORD (32-bit) Value.
4. Double-click the new value to open the Edit DWORD (32-bit) Value popup.
5. In the Value name field, enter DrawingDelay.
6. In the Value data field, enter the appropriate value for your environment.
2.3.62 Upgrade custom applications or code

If your environment uses custom applications or code, you may also need to upgrade event handlers, and
other components. For additional upgrade information, see the Relativity Developers site.

2.3.64 Workers

Conversion no longer occurs on the worker manager server. You cannot modify the priority of the
following conversion jobs on the worker manager server: Pre-convert, Conversion on-the-fly, Mass
Upgrade Guide 96
Conversion, and Conversion. Instead, you must install Service Bus for Windows Server and configure

Learn more about the changes to your Relativity 6.x environment after you upgrade to Relativity 9.6. This
section also includes post-upgrade processes you'll need to follow.
n Agent service
n Analytics on the next page
n Applications
n Audit on page 100
n Conversion
n Database schema
n dtSearch index considerations on page 102
n Document Table Trigger removal considerations on page 102
n Upgrade considerations for Relativity 9.6 on page 17
n License Relativity on page 107
n Pre-installation steps for web servers on page 114
n Scripts
Upgrade Guide 97
n Viewer on page 119
n Workers
2.4.1 Agent service

2.4.2 Analytics
Relativity 9.3 introduces a new Textual Near Duplicate Identification algorithm with the following benefits:
n The new algorithm can greatly improve performance for both large and complex data sets.
n With the new algorithm you can scale your Analytics server by adding CPU cores and RAM in order
to achieve faster performance.
Prior to Relativity 9.3, scaling environments did not impact performance. Without scaling past 8 cores, you
should experience performance comparable to pre-9.3 on most data sets. The Textual Near Duplicate
Identification algorithm in Relativity 9.3 uses different, more efficient methods to obtain similar results.
However, results may differ slightly from pre-9.3 results if a Full Analysis is run against a preexisting
structured analytics set. If you need preexisting results use an Incremental Analysis instead. The
incremental analysis keeps the pre-9.3 results for all preexisting documents, but the newly added
documents use the new algorithm to match with existing groups.
page 179.

Upgrade Guide 98
2.4.2.3 Upgrading/installing Relativity Analytics 9.6
An install or upgrade of Relativity Analytics 9.6 is required for Relativity 9.6. To install Relativity Analytics
9.6, you must run the Relativity Analytics Server Setup wizard after installing or upgrading your Relativity
instance.
When you run the Relativity Analytics Server Setup wizard, the wizard automatically:
n Installs the CAAT service

n Deploys the Relativity library files
n Configures the java heap size (set by default to half of RAM)
n Set an index path on new install, thus eliminating the need to manually set the location of indexes
n Sets the CAAT Windows service to log in as the Relativity Service Account

this update:
missions
missions
missions
level permissions
Upgrade Guide 99

operations.
2.4.3 Applications
2.4.4 Audit
Upgrade Guide 100


2.4.6 Conversion
agents.
2.4.7 Data Grid

Data Grid guide.
Upgrade Guide 101



2.4.9 Document Table Trigger removal considerations

Relativity 9.0 includes enhancements that may affect certain areas of your existing environment when you
upgrade. Improvements to the database schema make Relativity run faster in 8.1 than in previous
versions. If your environment contains custom-developed functionality that involves the RelationalIndex_X
tables or explicitly uses the RI_X columns in the Document tables, then you should refer to the Document
table trigger removal documentation
2.4.10 dtSearch index considerations

There is a new paradigm to configuring and building dtSearch indexes. Keep these items in mind about
your indexes after you upgrade:
n For indexes built in Relativity 5.9 or below, you must perform a Full Build for them to work normally.
n Any active indexes built in Relativity 6.2 or above continue work normally.
n After upgrading, you must initially perform a full build of a dtSearch index before you are able to run
incremental builds. You can then perform incremental builds, which follow the new paradigm.
n For indexes that are in progress or in an error state when you upgrade, you must perform a Full
Build.
n Indexes with document level errors continue to work normally.
Upgrade Guide 102

2.4.12 Fields
review.
2.4.13 File share

guide.

Upgrade Guide 103

2.4.15 IIS
complete.
2.4.15.2 SingalR
Upgrade Guide 104

web.config file:
2.4.16 Imaging
Upgrade Guide 105

to Relativity 9.6:

profile name.
If your environment is not set up for native imaging, the following changes occur upon upgrade:

Upgrade Guide 106




2.4.19 License Relativity

As part of the upgrade to Relativity 9.6, you need to apply a new Relativity license to your installation. Run
Procuro on all databases, and then request a new Relativity license key from Client Services, and apply
the activation key. For more information, see the Relativity Licensing guide.
Upgrade Guide 107

environment setup.
environment setup.
Upgrade Guide 108

setup:
Envir- Pro- Pro-

onment cess- cess-
Tier 1 3 7
(see the
System
Require-
ments
Guide for
details)
Tier 2 6 12
(see the
System
Require-
ments
Guide for
details)
Relativ- 3 7
ityOne
baseline
Upgrade Guide 109

installed.
database upgrade.
Upgrade Guide 110

to 9.5.


Upgrade Guide 111

n Dashboards
n Pivot
n Sampling
2.4.23 Production
Relativity.Core agents for production and branding are not available in a 9.3+ environment.
n If you upgrade from Relativity 6.x to Relativity 9.6 and you were previously using the Production
munity.
Upgrade Guide 112

object.
object.
ductions.
munity.
Upgrade Guide 113

duction.
populated.
2.4.24 Pre-installation steps for web servers

This section describes pre-installation steps that are required for upgrading Relativity 6.x installations.
They must be completed on all web servers before installing Relativity 9.6.
2.4.24.1 Setting IIS options

Use these instructions to update IIS settings and other configuration options for environments running
Windows Server 2008 or higher with IIS 7.5. These updates must be made on all web servers in your
Relativity installation.
1. Install .NET Framework 4.0 on all web servers.

2. Configure the Legacy Unhandled Exception Policy on all web servers.
a. Browse to the following directory on your web server: C:\Win-
dows\Microsoft.NET\Framework64\v4.0.30319\
b. Open the Aspnet.config file in a text editor.
c. Locate the tag <legacyUnhandledExceptionPolicy>. Set the enabled attribute to true.
d. Save the changes to the file.

Upgrade Guide 114


9.5.292.12.
Guide.

Notes:
Upgrade Guide 115



n EDDSDBO password

Upgrade Guide 116


2.4.31 Scripts
2.4.32 Searching


Upgrade Guide 117

2.4.35 Telemetry
2.4.36 Upgrade agents and other components

Confirm that your environment has all the required agents and other software components added in prior
versions. For more information, see the Relativity Upgrade Guide v6.10 in the Relativity Community.
If your environment uses custom applications, you may also need to upgrade event handlers, and other
components. For more upgrade information, see the Relativity 9.6 Developers site.
Note: For information about recompiling syncs, contact the Client Services team
(support@relativity.com)

guide.
guide.
Upgrade Guide 118

2.4.38 Viewer
Relativity uses Oracle Outside In version 2016.2. When you upgrade to Relativity 9.6, you can install the
new version of the viewer using the steps described in the Workspace Configuration guide. Any previous
versions of the viewer aren't upgraded, but you can run two versions of the viewer concurrently, so there's
no need to uninstall previous versions.


applicable.
mode in the viewer.

Upgrade Guide 119

arounds for Service Bus 1.1 with TLS 1.2 on page 39.


Upgrade Guide 120


combinations:

platform.

traffic to IIS.
Upgrade Guide 121

Use a load balancer

2.4.43 Workers
reached.



Upgrade Guide 122

conversion agents. For more information, see Configuring your conversion agents on the next page.

Upgrade Guide 123

3 Configuring your conversion agents
When you convert a document in Relativity, that conversion job is performed by a dedicated conversion
agent.
Relativity 9.6 and above use Service Bus for Windows Server to submit conversion jobs and communicate
with your designated conversion agents. You must install Service Bus for Windows Server before you run
your upgrade to Relativity 9.6. For more information, see Installing Service Bus for Windows Server in the
Pre-Installation guide.
If you have dedicated conversion workers, it's recommended that you re-purpose the dedicated workers
as agent servers with a single conversion agent. For more information, see Re-purposing a conversion
worker as a conversion agent.
If you have a Tier 1 or similar environment that doesn't have any Invariant workers dedicated solely to
conversion, you can add a conversion agent to an existing agent server. Or you can allocate new
hardware dedicated to conversion. For more information, see Adding conversion agents to an
environment with no dedicated conversion workers.
3.1 Conversion agent considerations

Consider the following about conversion agents when installing or upgrading to Relativity 9.6:
n On a new installation of Relativity 9.6, Relativity automatically creates one conversion agent and
adds it to the default secondary agent server. You should then add the agent server to the appro-
priate resource pool. For more information, see Resource pools in the Admin guide.
n On upgrade to Relativity 9.6 from 9.4 or previous, you must add the Service Bus agent server to the
appropriate resource pool. Then, manually create the conversion agents using a new agent type of
Conversion agent. For more information, see the Agents guide.
3.2 Re-purposing a conversion worker as a conversion agent

If you have existing Invariant workers that Relativity uses solely for conversion, you can re-purpose your
hardware to support conversion agents.
Note: If your worker server handles more than just conversion jobs, do not follow these steps. You still
need Invariant workers for other jobs such as Processing, Imaging, and Save as PDF.
To re-purpose a conversion worker as a conversion agent, perform the following steps:
Note: These steps are only required if you're upgrading from Relativity 9.3 or earlier, since conversion
was performed by a worker in those versions, and only if your worker was designated for conversion.
1. Ensure Service Bus for Windows server is installed in the environment.

2. Uninstall Invariant on the server via Windows Control Panel Add/Remove Programs. Doing this unin-
stalls existing Invariant applications.
Upgrade Guide 124

3. If it's still visible in the Server Management tab in Relativity, delete the old worker from that location.
4. Set up a new agent server for conversion agents. For more information, see Infrastructure con-
figuration in the Upgrade guide.
n This process requires a manual copy of a valid SSL certificate to the agent server.
To set up the second agent server, perform the following steps:
1. Edit the RelativityResponse.txt file to include only the lines enabled (=1).
INSTALLAGENTS = 1 in the feature section.
2. Run the Relativity installer on the machine. For more information, see Agent installation in the
Relativity installation guide.
Note: Service Bus for Windows Server is required only for the first agent server running
conversion jobs.
3.3 Adding conversion agents to an environment with no ded-

icated conversion workers
If your environment doesn't have any Invariant workers dedicated to conversion, you have two options
when setting up conversion for Relativity 9.6.
3.3.1 Adding a conversion agent to an existing server

You can add a conversion agent to one of your existing servers.
If you use this option, add the conversion agent to one of your lesser-used agent servers. You could also
rearrange some of your existing agents between your agent servers, which dedicates more resources to
conversion.
For greater control over the resources you allocate to conversion, you can also install a new agent server
in a virtual machine and host a single conversion agent on that machine. For more information, see Agent
installation in the Relativity installation guide.
Upgrade Guide 125

3.3.2 Allocate additional hardware to host a new agent server
You also have the option of allocating additional hardware to host a new conversion agent server. To
allocate additional hardware, follow these steps:
1. Ensure that Service Bus for Windows Server is installed in the environment.
2. Set up a new, secondary agent server for conversion agents. For more information, see Infra-
structure configuration in the Upgrade guide.
To set up a secondary agent server, perform the following steps:
1. Ensure that Service Bus for Windows Server is installed in the environment.
2. Edit the RelativityResponse.txt file to include only the lines enabled (=1).
INSTALLAGENTS = 1 in the feature section.
3. Run the Relativity installer on the machine. For more information, see Agent installation in the
Relativity installation guide.
Note: Service Bus for Windows Server is only required for the first agent running conversion jobs.
Upgrade Guide 126

4 Upgrading your SQL Server
Follow these steps to upgrade your primary SQL Server. Before doing so, ensure you have completed the
required pre-upgrade steps. For more information, see Pre-installation Guide.
Note: This page also contains steps for upgrading a distributed SQL Server. You must upgrade your
primary SQL Server before proceeding with these upgrades.
4.1 Primary SQL Server upgrade

Note: When you run the installer for the primary SQL Server, it adds the following applications to your
SQL Server: Relativity, Relativity Primary Database, and Relativity Primary Procuro. These applications
are required for optimum performance of Relativity. To avoid issues with registry settings, and the need
for additional reset steps, don’t uninstall these applications.
The master database, called the EDDS database, resides on the primary SQL Server. You must upgrade
Secret Store before updating the primary database. For more information, see Upgrading the Secret
Store.
Additionally, you must install or upgrade the Relativity service bus. You can then run the web and agent
server installations in parallel.
Save the following files to the root directory of any server contributing to the Relativity environment:
n Relativity.exe - The executable file that installs Relativity components determined by the values
entered in the RelativityResponse.txt file.
Notes:
o You must save Relativity.exe on a drive local to the server. Running Relativity.exe from a
shared location results in upgrade or installation failure.
o The Relativity.exe file does not open a user interface. Use Install.bat to proceed with install-
ation.
n Install.bat - The code that prompts Relativity.exe to proceed with the installation process. You must
edit line 11 of the Install.bat file with the exact name of the Relativity installation file.
start /wait "" "INSERT EXACT NAME OF RELATIVITY INSTALLATION FILE" /log InstallLog.txt /re-
sponsefilepath=RelativityResponse.txt
Notes:
o You may need to run this file from an elevated command line prompt to avoid permission
issues.
o You must surround the name of the Relativity installation file with quotation marks.
n RelativityResponse.txt - The text file that determines which components Relativity.exe installs,
uninstalls, or upgrades on the server.
Upgrade Guide 127

Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to
provide instruction.
Open the RelativityResponse.txt file in a text editor and edit the parameters as follows to upgrade
Relativity on the machine that serves the role of the primary SQL Server:
4.1.0.1 Common properties
Note: If you are upgrading to Relativity 9.6, some values in your response file may now be stored in the
Secret Store. These values are identified by the following message: "Value exported to Secret Store."
You don't need to edit these values unless you want to update the Secret Store. For more information,
see Secret Store.
n INSTALLPRIMARYDATABASE - Set this value to one.
INSTALLPRIMARYDATABASE=1
n INSTALLDISTRIBUTEDDATABASE - Verify that this value is set to zero. You can't store the dis-
tributed database on the same machine as the primary database.
INSTALLDISTRIBUTEDDATABASE=0
n INSTALLDIR - Enter the installation directory. This is the target directory for all files related to the
local installation. This path must be local to the machine and accessible by the server. You must use
ASCII characters for this path.
INSTALLDIR=C:\Program Files\kCura Corporation\Relativity
n PRIMARYSQLINSTANCE - Enter the primary SQL instance. If you are installing to a cluster, specify
the cluster and instance name. If you are installing to a named instance, specify the server and
instance name. All features require this input.
PRIMARYSQLINSTANCE=ML12
n EDDSDBOPASSWORD - Enter the EDDSDBO password.
EDDSDBOPASSWORD=MySecretPassword
n SERVICEUSERNAME - Enter the service username. The Windows login must already exist.
SERVICEUSERNAME=example\exampleusername
n SERVICEPASSWORD - Enter the Service password.
SERVICEPASSWORD=MySecretPassword
n USEWINAUTH - Set the value to one to use Windows authentication for the SQL Server.
USEWINAUTH=1
Upgrade Guide 128

Note: If the USEWINAUTH value is set to one, then the user running the installer must be a SQL
sysadmin, and any values entered for SQLUSERNAME and SQLPASSWORD are ignored.
n SQLUSERNAME - Enter the SQL username if you want to use SQL Server login authentication.
SQLUSERNAME=mySqlUserName
Note: This value is ignored if USEWINAUTH is set to one.
n SQLPASSWORD - Enter the SQL password if you want to use SQL Server login authentication.
SQLPASSWORD=myPassword
4.1.0.2 Primary database properties

n DEFAULTFILEREPOSITORY - Enter the default file repository. This path must be a shared folder
to which both the user running the installer and the Relativity Service Account have read and write
permissions.
DEFAULTFILEREPOSITORY=\\yourmachine\FileShare
n EDDSFILESHARE - Enter the EDDS fileshare path. This path must be a shared folder to which both
the user running the installer and the Relativity Service Account have read and write permissions.
EDDSFILESHARE=\\yourmachine\Fileshare
n CACHELOCATION - A valid UNC path for the viewer cache location. The installer ignores this value
during an upgrade. It only uses this value on a new installation of Relativity. This parameter is avail-
able in Relativity 9.5.292.12 and above. For more information, see the Relativity Installation guide.
CACHELOCATION=\\yourmachine\ViewerCache
n DTSEARCHINDEXPATH - Enter the dtSearch index. This path must be a shared folder to which
both the user running the installer and the Relativity Service Account have read and write per-
missions.
DTSEARCHINDEXPATH=\\yourmachine\dtSearch
n RELATIVITYINSTANCENAME - Enter the Relativity instance name. Only set this value during a
first-time installation. The installer ignores this value on upgrade.
RELATIVITYINSTANCENAME=My Relativity Instance
n ADMIN_EMAIL - Enter the email address that you want to use for the default Relativity admin
account. If you don't specify an email address, the installer uses the default value of relativ-
ity.admin@relativity.com. This parameter is available for 9.5.342.116 and above.
ADMIN_EMAIL=relativity.admin@relativity.com
Upgrade Guide 129

n SERVICEACCOUNT_EMAIL - Enter the email address that you want to use for the default Relativity
service account. If you don't specify an email address, the installer uses the default value of ser-
viceaccount@relativity.com. This parameter is available for 9.5.342.116 and above.
Notes:
SERVICEACCOUNT_EMAIL=serviceaccount@relativity.com
n ADMIN_PASSWORD - Enter the password that you want to use for the default Relativity admin
account. This parameter is available for 9.5.342.116 and above.
ADMIN_PASSWORD=myPassword
n SERVICEACCOUNT_PASSWORD - Enter the password that you want to use for the default Relativ-
ity service account. This parameter is available for 9.5.342.116 and above.
SERVICEACCOUNT_PASSWORD=myPassword

4.1.0.3 Common database properties

We recommend that the following database paths are local to the SQL Server and accessible. However,
we also support UNC paths on SQL Server 2012 and above.
n DATABASEBACKUPDIR - Enter the database backup directory.
DATABASEBACKUPDIR=C:\Backup
n LDFDIR - Enter the LDF directory.
LDFDIR=C:\Logs
n MDFDIR - Enter the MDF directory.
MDFDIR=C:\Data
Upgrade Guide 130

n FULLTEXTDIR - Enter the full text directory.
FULLTEXTDIR=C:\FullText
Save your edits to the RelativityResponse.txt file, and launch the Install.bat file to proceed with the
upgrade.
A sample RelativityResponse.txt file for a primary SQL database upgrade using Windows authentication
looks like this:
DEFAULTFILEREPOSITORY=\\yourmachine\FileShare
EDDSFILESHARE=\\yourmachine\Fileshare
CACHELOCATION=\\yourmachine\ViewerCache
DTSEARCHINDEXPATH=\\yourmachine\dtSearch
RELATIVITYINSTANCENAME=My Relativity Instance
ADMIN_EMAIL=relativity.admin@relativity.com
SERVICEACCOUNT_EMAIL=serviceaccount@relativity.com
ADMIN_PASSWORD=myPassword
SERVICEACCOUNT_PASSWORD=myPassword
LDFDIR=C:\Logs
MDFDIR=C:\Data
USEWINAUTH=1
4.2 Distributed SQL Server upgrade

If your Relativity environment uses a distributed SQL Server, then you need to run the installer on a
machine other than the one that hosts the primary SQL database. After you have upgraded the primary
SQL Server, you can upgrade the distributed database server and the web and agent server upgrades in
parallel. Make sure that you review the steps for the database server setup in the Pre-installation Guide,
including those in the Optionally configure an authentication token-signing certificate section.
Relativity on the machine that serves the role of the distributed SQL Server:

n INSTALLPRIMARYDATABASE - Set this value to zero. You can't store the distributed database on
the same machine as the primary database.
n INSTALLDISTRIBUTEDDATABASE - Set this value to one.
Upgrade Guide 131

n SERVICEPASSWORD - Enter the Service password.
n USEWINAUTH - Set this to one to use Windows authentication for the SQL Server.
USEWINAUTH=1
n SQLUSERNAME - Enter the SQL username to use SQL Server login authentication.
n SQLPASSWORD - Enter the SQL password to use SQL Server login authentication.
4.2.0.2 Distributed database properties

n DISTRIBUTEDSQLINSTANCE - Enter the Distributed SQL instance. You can't store the distributed
database on the same machine as the primary SQL Server.
DISTRIBUTEDSQLINSTANCE=ML14
Upgrade Guide 132

4.2.0.3 Common database properties
We recommend that the following database paths are local to the SQL Server and accessible. However,
we also support UNC paths on SQL Server 2012 and above.
n DATABASEBACKUPDIR - Enter the database backup directory.
n LDFDIR - Enter the LDF directory.
LDFDIR=C:\Logs
n MDFDIR - Enter the MDF directory.
MDFDIR=C:\Data
n FULLTEXTDIR - Enter the full text directory.
upgrade.
A sample response file for a distributed SQL database upgrade using Windows authentication looks like
this:
DISTRIBUTEDSQLINSTANCE=ML14
LDFDIR=C:\Logs
MDFDIR=C:\Data
USEWINAUTH=1
Upgrade Guide 133

5 Removing RabbitMQ
Beginning in Relativity 9.4.254.2, processing to Data Grid no longer requires RabbitMQ. To remove
RabbitMQ from your Relativity environment, follow the steps below.
5.1 Deleting Data Grid agents

You can delete the following Data Grid agents as of Relativity 9.4.254.2:
n Data Grid Error Queue Manager

n Data Grid Install Queue Manager
n Data Grid Process Queue Manager
n Data Grid Status Queue Manager
n Data Grid Verify Queue Manager
To delete one or more agents using the mass operation menu, complete the following steps.
1. From Home, select the Agents tab.

2. Select the agents you want to delete, and then select Delete from the drop-down menu.
3. Click Go to flag the agents for deletion from your environment.
When the Agent Manager Windows Service runs, any agents marked for deletion are checked to see if
they're executing a job. If an agent marked for deletion is executing a job, then it's not deleted. The Agent
Manager service will continue to check the agent at five-second intervals, and when the agent is finished
executing its job, it is deleted. For more information on managing agents, see the Agents Guide.
5.2 Deleting empty processing queues

To delete empty processing queues, complete the following steps:
1. Ensure there are no Relativity Processing jobs running.

2. Run the following script using Windows Powershell to delete empty queues.
$cred = Get-Credential
iwr -ContentType 'application/json' -Method Get -Credential $cred 'http://-
localhost:15672/api/queues' | % {
ConvertFrom-Json $_.Content } | % { $_ } | ? { $_.messages -eq 0} | % {
iwr -method DELETE -Credential $cred -uri $("http://localhost:15672/api/queues/{0}/{1}" -f
[System.Web.HttpUtility]::UrlEncode($_.vhost), $_.name)
}
3. Ensure there are no queues leftover. If there are any remaining queues, contact the Client Services
team.
5.3 Uninstalling RabbitMQ Server and Erlang OTP

To uninstall RabbitMQ and Erlang:
Upgrade Guide 134

1. Open the Control Panel.
2. Select Uninstall a program.
3. Right-click RabbitMQ Server, and then click Uninstall.
4. Repeat steps 1-3 to uninstall Erlang OTP 18.
5. Delete the installation directories for RabbitMQ:
Get-ChildItem c:\ -Force -Include *Rabbit* -Recurse | foreach ($_) {Remove-Item $_.fullname -
whatif}
Note: This script will delete all files related to RabbitMQ on C:\. If you are using RabbitMQ for
anything else in your infrastructure, you must modify this script.
n Remove -whatif when ready to run.

n Delete C:\Users\relativityserviceaccount\AppData\Roaming\RabbitMQ.
6. Delete the installation directories for Erlang OTP 18:
Get-ChildItem c:\ -Force -Include *erlang* -Recurse | foreach ($_) {Remove-Item $_.fullname -
whatif}
Note: This script will delete all files related to Erlang on C:\. If you are using Erlang for anything
else in your infrastructure, you must modify this script.
n Remove -whatif when ready to run.

n Delete the file C:\Windows\.erlang.cookie and C:\User-
s\relativityserviceaccount\.erlang.cookie.
7. Restart your machine.
5.4 Closing ports on the Queue Server

Close the following ports on the queue server:
n 15672
Upgrade Guide 135

6 Upgrading your Relativity service bus
To upgrade the Relativity service bus, you run the installer on a machine where it is already installed, or
where the Service Bus for Windows Server is installed. You must include the Relativity service bus server
as a node in the Service Bus for Windows Server farm. For more information, see the Pre-Installation
guide.
When you perform an upgrade, the Relativity installer saves information about the about the farm to the
primary SQL Server database. It also performs setup tasks on farm, so that Relativity can connect to the
service bus.
6.1 Relativity service bus upgrade

The Relativity service bus supports messaging between application components. Before installing or
upgrading the Relativity service bus, upgrade the primary SQL Server. For more information, see the
Relativity Service Bus guide.
Contact Relativity Client Services to get a copy of the Relativity installer.
Notes:
ation.
Notes:
issues.
Upgrade Guide 136

6.2 Setting properties in the RelativityResponse.txt file
Open the RelativityResponse.txt file in a text editor and edit the properties as follows to install Relativity
on the machine that serves the role of the service bus server:
6.2.1 Feature selection

n INSTALLSERVICEBUS - Set this value to one to install the Relativity service bus.
INSTALLSERVICEBUS=1
Note: If the service bus server is already installed on this machine and the
INSTALLSERVICEBUS property is set to zero, the installer removes the previously existing
service bus server.
6.2.2 Common properties

n SERVICEPASSWORD - Enter the service password.
n USEWINAUTH - Set this to 1 to use Windows authentication for the SQL Server.
USEWINAUTH=1
Upgrade Guide 137

installation.
A sample response file for a service bus only installation looks like this:
INSTALLSERVICEBUS=1
USEWINAUTH=1
6.3 Verifying database table updates for multiple hosts

If you have optionally installed Service Bus for Windows Server on multiple hosts, verify that installer has
updated the ServiceBusHosts table on the EDDS database.
Note: For more information, see Service bus PowerShell cmdlets in the Relativity service Bus guide.
Use the following procedure to verify the FQDN in the ServiceBusHosts table:
1. Obtain FQDN for each of the service bus nodes. If you don't know the FQDNs, run the Get-SBFarm
command and copy the FQDNs for the hosts from the output.
2. Log in to Microsoft SQL Server Management Studio on your primary SQL Server.
3. Run the following SQL command to obtain the list of hosts added to the ServiceBusHosts table:
Select * From EDDS.eddsdbo.ServiceBusHosts
4. Verify that the entries returned from this command match the FQDNs of your service bus nodes
obtained in step 1 or contain only a single value that matches the FarmDns. Complete the following
tasks if the entries don't match:
n Missing an FQDN - insert a row with the FQDN into the table. See the following sample com-
mand:
Upgrade Guide 138

INSERT INTO EDDS.eddsdbo.ServiceBusHosts Values('<FQDN of the host>')
n Incorrect host name - execute an UPDATE statement to add the correct FQDN for the host.
n Extraneous host name - execute a DELETE statement to remove the names of hosts not
currently used in your environment.
6.4 Troubleshooting the service bus installation

Use the following information to troubleshoot issues that may occur during the service bus installation:
n In the RelativityResponse.txt file, ensure that you set the INSTALLSERVICEBUS property to 1
before you run the installer.
n Verify that the following instance settings contain the correct values:
o ServiceBusFullyQualifiedDomainName
o ServiceBusHttpPort
o ServiceBusTcpPort
Note: For more information, see the Instance Setting guide.
n To troubleshoot connection errors with multiple hosts, verify that installer has properly updated the
ServiceBusHosts database table. You should also confirm that you have used the fully qualified
domain name for each of the machines hosting the Service Bus for Windows Server. For more
information, see Verifying database table updates for multiple hosts on the previous page.
Note: For general troubleshooting information, see the Relativity Service Bus guide.
Upgrade Guide 139

7 Upgrading your agent server
This section provides the prerequisites and the steps required to upgrade your agent server to a new
version of Relativity. For more information, see Pre-installation Guide.
Before you begin upgrading your agent server, confirm that you have upgraded the SQL Server and have
started the SQL service. Additionally, you must install or upgrade the Relativity service bus.
7.1 Agent server upgrade

Notes:
ation.
Notes:
issues.
To upgrade the agent server:

Relativity on the machine that serves the role of the agent server:
Note: The following settings assume that the same machine does not host the agent server that hosts
the primary or distributed SQL database servers.
Upgrade Guide 140

local installation. This path must be local to the machine and accessible by the server. You can't use
unicode special characters for this path.
n EDDSDBOPASSWORD - Enter the EDDS database object password.
n SERVICEPASSWORD - Enter the service password.
n USEWINAUTH - Set this to one to use Windows authentication for the SQL Server.
USEWINAUTH=1
upgrade.
A sample RelativityResponse.txt file for a agents only upgrade looks like this:
INSTALLAGENTS=1
Upgrade Guide 141

7.2 Service Host Manager HTTPS configuration

Upgrade Guide 142

8 Upgrading your web server
This section provides the prerequisites and the steps required to upgrade your web server to a new
version of Relativity. For more information, see Pre-installation Guide.
Before you begin upgrading your web server, confirm that you have upgraded the SQL Server, started the
SQL service, and that IIS is stopped. Additionally, you must install or upgrade the Relativity service bus.
Note: When you install Relativity, it is configured to use HTTPS by default. If you decided not to use
HTTPS in your environment, you must set the CookieSecure instance setting to False before logging in
to Relativity, or you receive an error message. For more information, see Instance setting on the
Relativity 9.6 Documentation site. If you later decide to use HTTPS in your environment, you can find
information about how to set up this functionality in the section called Configuring SSL on a web server
on the Pre-installation page.
8.1 Web server upgrade

The web server hosts Relativity and its services, such as the Services and Web APIs. After you have
installed the primary SQL Server, you can run the web and agent server, as well as the distributed
database server installations in parallel.
Notes:
ation.
Notes:
issues.
Upgrade Guide 143

The following settings assume that the same machine does not host the web server that hosts the primary
or distributed SQL database servers.
Open the RelativityResponse.txt file in a text editor and edit the parameters as follows to install Relativity
on the machine that serves the role of the web server:

n INSTALLWEB - set this value to one.
INSTALLWEB=1
Note: If the web server is already installed on this machine and the above value is set to zero, the
installer removes the previously existing web server.
n INSTALLDIR - enter the installation directory. This is the target directory for all files related to the
local installation. This path must be local to the machine and accessible by the server. You can't use
unicode special characters for this path.
n PRIMARYSQLINSTANCE - enter the primary SQL instance. If you are installing to a cluster, specify
n EDDSDBOPASSWORD - enter the EDDS database object password.
n SERVICEUSERNAME - enter the service username. The Windows login must already exist.
n SERVICEPASSWORD - enter the service password.
n USEWINAUTH - set this to one to use Windows authentication for the SQL Server.
USEWINAUTH=1
Upgrade Guide 144

n SQLUSERNAME - enter the SQL username to use SQL Server login authentication.
n SQLPASSWORD - enter the SQL password to use SQL Server login authentication.
Save your edits to the RelativityResponse.txt file, and then launch the Install.bat file to proceed with the
upgrade.
A sample RelativityResponse.txt file for a web only upgrade looks like this:
INSTALLWEB=1
8.2 Verifying the machine key settings on the IIS

When setting up the IIS for a Relativity installation, you need to verify that the machine keys are configured
to use the appropriate methods for the encryption and decryption of forms authentication data.
Use these steps to set the machine key for the IIS:
1. Open the IIS Manager.

2. Highlight your Relativity website to display configuration options in the Feature View on the IIS dash-
board.
3. Double-click the Machine Key icon.
4. Update the following fields for your version of Windows server:
n Windows Server 2008 R2 - select SHA1 for the Encryption method and AES for the
Decryption method.
Note: You could also select Auto for the Decryption method, but we recommend setting it
to AES.
Upgrade Guide 145

n Windows Server 2012 R2 - select SHA1 for the Validation method and AES for the
Encryption method.
Upgrade Guide 146

5. Save your changes.
8.3 Upgrading a web server configured for mixed authentication

with AD
Use the following steps to upgrade a web server configured for mixed mode authentication with Active
Directory (AD). For information about setting up a web server configured for mixed authentication with AD,
see Authentication on the Relativity 9.6 Documentation site.
To update the UseWindowsAuthentication instance setting:
1. Open SQL Server Management Studio on your Relativity database server.

2. Connect to the EDDS database.
3. Execute one of the following SQL statement to set the WindowsAuthentication instance setting to
True:
n Update all servers to use Windows Authentication.
Upgrade Guide 147

UPDATE EDDS.eddsdbo.InstanceSetting SET
value = 'True' WHERE
Name = 'UseWindowsAuthentication'
n Update a specific server to use Windows Authentication. Replace YourServerName in the

WHERE clause to the name of your machine, which you want to configure for Windows
Authentication. You only need the machine name if you want to set this setting per server.
UPDATE EDDS.eddsdbo.InstanceSetting SET

value = 'True' WHERE
Name = 'UseWindowsAuthentication' and MachineName = 'YourServerName'
n Add a new row to the instance setting table for each additional machine that you need to
enable AD authentication. Use this option when you want AD enabled on multiple web serv-
ers in your Relativity environment, but not on all of them. You need to execute the following
SQL statement with the name of the additional machine, which you want to configure for Win-
dows Authentication. Replace YourSecondServerName with the name of that machine.
INSERT INTO EDDS.eddsdbo.InstanceSetting

VALUES ('Relativ-
ity.Authentication','UseWindowsAuthentication','True','YourSecondServerName','Determines
whether Relativity uses Windows Authentication. Set this value False if you want to disable
WinAuth. Set it to True if you want to enable WinAuth and require the user to log in to
Relativity from the current machine.')
8.4 Service Host Manager HTTPS configuration

8.5 SignalR
Upgrade Guide 148

web.config file:
Upgrade Guide 149

9 Upgrading a worker manager server installation
You can use these instructions for upgrading the Invariant Database, Queue Manager, and Worker. When
you upgrade to a new version of Invariant, the installer removes any components from the previous
version installed on the local machine before it replaces them with the upgraded version. You must be
logged in as the Relativity Service Account to perform the upgrade.
Specific versions of Invariant are exclusively compatible with specific versions of Relativity. For this
reason, don't attempt to upgrade Invariant independent of Relativity, as doing so will result in significant
issues. For example, don't upgrade from Invariant 3.3, which is supported by Relativity 8.2, to Invariant 4.0
without also upgrading to Relativity 9.0. The following table breaks down which versions of Invariant are
supported by which versions of Relativity:

Invariant 4.0 Relativity 9.0/9.1
If you're performing separate upgrades for the Invariant components, you must upgrade the Invariant
database first, and then the Queue Manager. Invariant workers automatically upgrade when the database
is upgraded.
If the Invariant Worker Network File Path you specified during installation is not stored on the same SQL
Server as the Invariant database, instead of upgrading, you should uninstall Invariant and perform a fresh
installation of Invariant. When you install the new version, be sure to select a folder that's stored on the
same SQL Server as the Invariant database. If this folder is not stored on the same server, you could lose
all your data and be unable to uninstall or upgrade.
Note: When you apply a new processing license in your Relativity environment, all jobs in the
processing queue must complete before Relativity identifies any additional worker manager servers that
you may have purchased as licensed.
9.1 Upgrade considerations for Relativity 9.6.134.78

Beginning in 9.6.134.78, the Invariant queue manager requires the Secret Store to be accessible and
unsealed in order to run. Accordingly, you should note the following considerations prior to installation or
upgrade:
Upgrade Guide 150

n Before running the Invariant installer, you are required to first whitelist and then register any pro-
cessing-related machines for the Secret Store so that those machines can read and write to and
from the store. This includes the Invariant queue manager, all workers, and all machines on which
the RPC is installed. See The Relativity Secret Store Guide for more information on configuring serv-
ers for the Secret Store.
n Once you register all servers, the Invariant installer automatically redacts all username and pass-
word values you enter into the Invariant response file and then populates those values in the Secret
Store. This is the final step of the installation process.
n If the server on which the Secret Store is installed gets restarted, you'll need to unseal the Secret
Store before you run any processing job or run the Invariant installer.
n Upgrading to 9.6.134.78 from an earlier version requires you to run the Invariant installer on your
worker machines one time.
9.2 Upgrade exceptions

For upgrades from Relativity 8.0/Invariant 3.1 or earlier, you must first manually install the required
.NET 4.5 on all of your pre-existing Invariant Database, Queue Manager, and Worker machines before
running the installer. Similarly, you must install the required Microsoft Visual C++ Redistributable on all of
your pre-existing Worker machines before running the installer.
The 3.2 and above installers only validate whether .NET 4.5 is installed; they don't install the software. For
brand new Worker installations, the installer verifies that .NET 4.5 is installed. Installing a new Worker will
automatically install MS Visual C++ 2012 for you.
For upgrades from Relativity 7.3/Invariant 2.0, you must first upgrade to a later Invariant version (2.1,
3.0, 3.1, 3.2, or 3.3) before you upgrade to Invariant 4.0.
9.3 Installing Microsoft Visual C++ Redistributable Packages

The following table breaks down which versions of Microsoft Visual C++ are required for which versions of
Relativity/Invariant. Note that you’re required to install each version of Microsoft Visual C++ only if you’re
upgrading to the Relativity/Invariant version listed and not if you’re installing it for the first time.
Required Microsoft Visual C++ version (Redistributable x86

and x64)
Relativity/Invariant version 2010 2012 2013 2015
9.3/4.3 (all monthly versions √ √
included)
9.4/4.4 (all monthly versions √ √ √
included)
9.5.41.87/4.5.32.2 √ √ √
9.5.69.85/4.5.60.2 √ √ √
9.5.133.118/4.5.126.16 √ √ √
Upgrade Guide 151

Required Microsoft Visual C++ version (Redistributable x86
and x64)
Relativity/Invariant version 2010 2012 2013 2015
9.5.162.111/4.5.132.8 √ √ √
9.5.196.102/4.5.188.20 √ √ √ √
9.5.219.30/4.5.189.29 √ √ √ √
9.5.253.62/4.5.245.54 √ √ √ √
9.5.292.12 √ √ √ √
9.5.309.48 √ √ √ √
9.5.342.116 √ √ √ √
9.5.370.136 √ √ √ √
9.5.411.4 √ √ √ √
9.6.50.31 √ √ √ √
9.4 Upgrading the Invariant Queue Manager

You'll use the same installation files you used to install the Invariant Queue Manager to upgrade them. To
access the steps for performing an upgrade, see the Worker Manager Installation guide. These
installation files upgrade both the Invariant and Relativity Imaging databases. During an upgrade, you
can't modify the SQL Instance name, the Queue Manager Service Username, or the installation location of
the Queue Manager. If you need to change the any of these settings, you need uninstall and reinstall the
Invariant Queue Manager.
Upgrade Guide 152

10 Upgrading Relativity to .NET 4.6.2.
As of Relativity 9.5.196.102, you must upgrade your Relativity environment to .NET 4.6.2. The updates
must be applied to Relativity servers and client machines.
Note: Existing custom applications are backward-compatible with Relativity 9.5.196.102 and do not
need to be recompiled, but you must upgrade your development environment to use the latest versions
of Relativity SDKs.
10.1 All servers

Perform these steps on all servers in your Relativity environment:
1. Download the .NET 4.6.2 installer from https://www.microsoft.com/en-us/-

download/details.aspx?id=53344.The downloaded file name is NDP462-KB3151800-x86-x64-
AllOS-ENU.exe.
2. Run the NDP462-KB3151800-x86-x64-AllOS-ENU.exe executable and follow the instructions in
the installation wizard.
3. Turn off applications when prompted by the installation wizard.
4. Restart the server on completion.
10.2 Client machines

Perform these steps on all systems running Relativity and Invariant client applications (ActiveX viewer,
Relativity Desktop Client, and Relativity Processing Console):
1. If you don't have the Microsoft Visual C++ 2015 Redistributable already installed, download it from
https://www.microsoft.com/en-us/download/details.aspx?id=53840.The download provides both
32- and 64-bit options. Select an executable depending on your system word size.
2. Run the Microsoft Visual C++ 2015 Redistributable executable and follow the instructions in the
installation wizard.
3. Download the .NET 4.6.2 installer from https://www.microsoft.com/en-us/-
download/details.aspx?id=53344.The downloaded file name is NDP462-KB3151800-x86-x64-
AllOS-ENU.exe.
4. Run the NDP462-KB3151800-x86-x64-AllOS-ENU.exe executable and follow the instructions in
the installation wizard.
6. Restart the machine on completion.
7. Download and install the latest versions of ActiveX viewer, RDC, and RPC.
Upgrade Guide 153

10.3 Relativity applications
10.3.1 Backward-compatible applications

Going forward, regardless of current Relativity version, if you install new .NET 4.6.2-based versions of
backward-compatible Relativity applications, you must upgrade your environment to .NET 4.6.2 as
described above.
Backward-compatible applications include Data Grid, ARM, Relativity User Import, etc.
10.3.2 Custom applications built with the Relativity SDK

Custom applications that Relativity does not own or maintain can continue to target their current .NET
version and will work in the new .NET 4.6.2-based Relativity. You can continue developing with older
versions of the Relativity SDKs if you don't need the new features in latest version.
To develop using the latest Relativity SDK, you must update the applications' projects to target .NET 4.6.2.
The developers must also update their environment to the .NET 4.6.2 Developer Pack as described
below.
10.4 Development environment

If you develop custom Relativity application, you must update your development environment to use the
latest version of the SDK:
1. Download the Microsoft .NET Framework 4.6.2 Developer Pack from https://www.-
microsoft.com/en-us/download/details.aspx?id=53321. The file name is NDP462-DevPack-
KB3151934-ENU.exe.
2. Run the NDP462-DevPack-KB3151934-ENU.exe executable and follow the instructions in the
installation wizard.
4. Restart the machine on completion.
Upgrade Guide 154

11 Upgrading workspaces
You can use the Workspace Upgrade queue to monitor the progress of scripts as they update workspace
database schemas. In addition, you can also monitor upgrades to applications currently installed in
workspaces. It also provides you with the ability to view detailed error messages when a script or
application upgrade fails. You can use the advanced mass operations on the queue to edit the priority and
order of workspace upgrades, as well as retry failed upgrades, and cancel upgrades.
11.1 Monitoring upgrades with the Workspace Upgrade queue

You can view the Workspace Upgrade queue from Home. Select the Queue Management tab, and click
Workspace Upgrade Queue. The Workspace Upgrade queue displays the current status and the
progress of the upgrade for each workspaces.
Beginning in Relativity 9.4.398.62, the Workspace Upgrade Queue also displays the current status and
version of the processing store upgrade process, which the Workspace Upgrade Worker agent completes
in addition to upgrading the workspace.
For descriptions of the columns, see Workspace Upgrade queue columns on page 157.
(Click to expand)
Procuro is a utility used to upgrade the schema for all Relativity databases using scripts. As part of the
database upgrade process, the Procuro utility automatically runs on your database server. It is also known
as the Database Upgrade tool. Procuro makes updates to database schemas by adding, and removing
columns in tables, creating new tables, re-naming table /columns, changing the types of data; adding or
removing indexes and statistics to ensure functionality with Relativity. It is also required so Relativity can
perform upgrades for future iterations created.
Procuro automatically sets the Upgrade Status of the workspaces to Pending in the Workspace Upgrade
queue. This status indicates to the upgrade agents running in your environment that they can begin
upgrading the workspaces immediately. You can use the advanced mass operation options to change the
upgrade priority and order of workspaces or to prevent workspaces from upgrading. For more
information, see Editing upgrade priority and order for a workspace on page 158.
The workspace upgrader uses agents that run jobs for upgrading the workspace database schemas and
installing applications. You must configure these agents through the Agents tab in Relativity. See
Populating the Workspace Upgrade queue on the next page.
If you don't see any activity in the Workspace Upgrade queue, these agents haven't been configured. An
alert message lists the agents that you need to configure.
Upgrade Guide 155

For configuration information, see Relativity upgrade and Agents on the Relativity 9.6 Documentation site.
11.1.1 Populating the Workspace Upgrade queue

The Workspace Upgrade queue continually populates with status information by the upgrade agents as
they run scripts to update workspace databases and installed applications. The following agents run the
scripts and the application upgrades:
n Workspace Upgrade Worker - picks up pending jobs in the queue for script updates.
Note: On an SQL Server profile, you can edit the Workspace Upgrade Limit field, which
controls the number of agents accessing the server during an upgrade. The setting entered in
this field can’t exceed the setting in the GlobalWorkspaceUpgradeLimit instance setting value.
If you enter a number that exceeds this instance setting value, an error occurs that cancels your
update. For more information, see Instance setting values and Upgrading workspaces.
n Workspace Upgrade Manager - queues applications required for installation in workspaces.

n Application Installation Manager - installs required applications to workspaces.
For more information about agents, see Agents on the Relativity9.6 Documentation site.
During a Relativity upgrade, the agents complete the following tasks and then update the statuses
displayed on the Workspace Upgrade queue:
1. Set upgrade status to Pending. Procuro runs and sets the status on workspaces in the Work-
space Upgrade queue to Pending.
2. Pick up pending jobs. The Workspace Upgrade Worker sees a pending job in the queue, picks it
up, and begins upgrading the workspace.
3. Run upgrade scripts. The Workspace Upgrade Worker sets the status of the workspace to
Upgrading scripts and runs the SQL scripts to update the workspace database schema. When the
scripts complete, the upgrade status on the workspace is set to Pending Application Upgrade.
4. Set upgrade status to Upgrading Applications. The Workspace Upgrade Manager queues
applications required for installation in workspaces in the Application Install table, and it sets the
upgrade status to Upgrading Applications.
5. Install applications. The Application Installation Manager installs the required applications.
6. Complete installation. When the application upgrades have installed successfully, the Workspace
Upgrade Manager checks the application status, and then sets the status of the workspace to Com-
pleted.
During an Invariant upgrade, the agents complete the following tasks and then update the statuses
displayed on the Workspace Upgrade queue:
1. Set store upgrade status to Pending.The Invariant.DBUpdater runs and sets the store status on
workspaces in the Workspace Upgrade queue to Pending.
2. Pick up pending store upgrade jobs. The Workspace Upgrade Worker sees a pending store
upgrade job in the queue, picks it up, and begins upgrading the store.
3. Run upgrade scripts. The Workspace Upgrade Worker sets the status of the workspace to
Upgrading scripts and runs the SQL scripts to update the store database schema.
Upgrade Guide 156

11.1.2 Workspace Upgrade queue columns
The Workspace Upgrade queue displays the following columns:
n Artifact ID - the Artifact ID of a workspace undergoing an upgrade.

n Workspace Name - the name of a workspace undergoing an upgrade. Click the name to display
the document list in the workspace.
n Priority - the upgrade order assigned to the workspace. Priorities include Low, Medium, and High.
See Editing upgrade priority and order for a workspace on the next page.
n Upgrade Status - the status of the workspace upgrade as determined by the current Procuro
stage. See Upgrade statuses descriptions on the next page.
n Workspace UpgradeStatus - the value assigned to the Status field on the workspace details page.
See Upgrade statuses descriptions on the next page.
n Current Relativity Version - the workspace is currently updated to this version of Relativity.
space upgrade. This field is empty if you don't have processing installed. You could see any of the
following status values:
Status What it means

Pending The Invariant store have been added to the Workspace
Upgrade queue, but the Workspace Upgrade Worker hasn’t
picked it up yet.
Upgrading Scripts The Workspace Upgrade Worker agent is running scripts
against the Invariant store.
Completed The store is fully upgraded and ready for use.
Failed Script Upgrade An error occurred while upgrading SQL scripts for the Invariant
store, the upgrade failed, and Relativity Processing is disabled
in the workspace.
Canceled The user canceled the upgrade when it had the status of
Pending, Pending Application Upgrade, Upgrading Scripts, or
Upgrading Applications. See Canceling or retrying workspace
upgrades on page 162.
NULL A Store has not been created on this workspace
n Current Store Version - the version of Invariant you are upgrading to. This field always displays
the most current version of Invariant available. This is because if the upgrade fails, it displays the
version of Invariant you were attempting to upgrade to, and if the upgrade was successful, it dis-
plays the version you just upgraded to, which is the most current.
n Database Upgrade Progress - the percentage of the upgrade process completed for the work-
space database and the Invariant database if the Processing application is installed. It uses the fol-
lowing colors to indicate the upgrade status:
Upgrade Guide 157

o Blue - indicates the upgrade is in progress.
o Green - indicates a completed upgrade.
o Red - indicates an error or failure occurred.
n Application Upgrade Progress - the percentage of the upgrade process completed for the applic-
ation. It uses the same colors to indicate the upgrade status as the Database Upgrade Progress
bar.
11.1.3 Upgrade statuses descriptions

The following table contains descriptions for the statuses displayed in the Upgrade Status column on the
Workspace Upgrade queue:
Status Description
Canceled The user canceled the upgrade when it had the status of Pending,
Pending Application Upgrade, Upgrading Scripts, or Upgrading
Applications. See Canceling or retrying workspace upgrades on
page 162.
Completed The upgrade of the workspace completed successfully.
Failed Application Upgrade An error occurred while upgrading applications in the workspace.
See Troubleshooting upgrades on page 160.
Failed Script Upgrade An error occurred while upgrading SQL scripts for the workspace.
See Troubleshooting upgrades on page 160.
Pending The workspace has been added to the Workspace Upgrade queue,
but the Workspace Upgrade Worker hasn’t picked it up yet.
Pending Application Upgrade The Workspace Upgrade Manager populates the application install-
ation queue with any required applications.
Upgrading Applications The Application Installation Manager upgrades the applications in
the workspace.
Upgrading Scripts The Workspace Upgrade Worker runs Procuro scripts against the
workspace database.
11.2 Editing upgrade priority and order for a workspace

You can set order and priority on workspaces for upgrades. Relativity always upgrades ordered
workspaces before unordered workspaces regardless of their priority. Relativity uses priority to determine
which of the workspaces to upgrade first when you don’t assign an order.
In addition, if you assign the same order to a group of workspaces, Relativity uses their Artifact ID to
determine the upgrade order. It follows a similar process if you assign the same priority to a group of
workspaces.
The priority and order options provide you with the flexibility needed to control the workspaces that
Relativity upgrades first and those that are upgraded later. For example, you might upgrade workspaces
Upgrade Guide 158

in high demand, so that they are available to users sooner than those less frequently accessed
workspaces. The default priority for workspaces is Medium and the default order is blank.
Note: Your users may notice decreased Relativity performance if they are using a workspace on the
same SQL Server where you are upgrading other workspaces. However, if you are upgrading
workspaces on another server in a distributed environment, users shouldn't notice any change in
performance.
Use this procedure to change the priority and order:
1. Perform one of these tasks to select the workspaces:

n To set the priority for only a specific group of workspaces, select their checkboxes. In the
mass operations bar, choose Checked.
n To set the priority for all workspaces, choose All Items in the mass operations bar.
2. Select Edit Priority in the mass operations bar.
3. Click Go to display the Edit Upgrade Priority dialog.
4. Perform one or both of the following tasks:

n Select the Priority checkbox. Choose Low, Medium, or High from the drop-down menu.
n Select the Order checkbox. Enter a value in the text box. You use this value to specify the
order that you want used for workspace upgrades. Relativity upgrades workspaces with a
smaller order values before those with a larger values. The default value for Order is blank.
5. Click Ok to save your changes.
If you want to revert from and ordered priority to an unordered priority, use this procedure:
1. Select the Priority checkbox. Choose Low, Medium, or High from the drop-down menu.
2. Select the Order checkbox. Leave the value blank.
3. Click Ok to save your changes.
Upgrade Guide 159

11.3 Troubleshooting upgrades
From the Workspace Upgrade queue, you can view script and application errors, which may have
occurred during an upgrade. You can also use the mass operations for retrying a workspace upgrade
from the queue or canceling an upgrade. For more information, see the following sections:
n Viewing upgrade errors

n Canceling or retrying workspace upgrades
n Retrying upgrade failures for system secured applications on page 163
11.3.1 Viewing upgrade errors

When an application or script fails to upgrade properly, the Upgrade Status column displays a link that you
can use to view additional information about the error that occurred.
Note: You can also view errors, upgrade status, script details, and other information on the History of
Workspace dialog. To display this information, click the Workspace Details tab, and then click the View
Audit button.
11.3.1.1 Script or other non-application upgrade fails

When a script upgrade fails, click the Failed Script Upgrade link to display the Error Information dialog,
which includes a detailed error message, server, source, and other information.
Upgrade Guide 160

You can't access a workspace when a script or other upgrade non-application error occurs. If you attempt
to open a workspace with these upgrade errors, you receive a message indicating that the workspace is
inaccessible. Click the Return to Home link to display the default Home tab.
Note: If you only want to display workspaces that are fully upgraded and accessible, add a condition on
the workspace view where the Workspace Accessibility field is set to Enabled. This setting filters only
upgrade accessible workspaces, and hides any workspaces that users can't interact with.
When a script error occurs during an upgrade, review the details of the failure in the error message
available from the Failed Script Upgrade link. You may also want to rerun the upgrade using the Retry
Upgrade option. See Canceling or retrying workspace upgrades on the next page.
11.3.1.2 Application upgrade fails in a workspace

When an application upgrade fails, click the Failed Application Upgrade link to display the Application
Errors dialog. If multiple applications failed to upgrade, click this link to display a pop-up with links to the
error pages for these applications.
When an application error occurs, review the details of the failure in the error message available from the
Failed Application Upgrade link. You can resolve locking conflicts that occur when a locked application
prevents an upgrade, and naming conflicts that occur when an object type in an application shares the
same name as another object type in the workspace. To resolve these errors, perform one of the following
tasks:
Upgrade Guide 161

n Locking conflicts - Click the Failed Application Upgrade link to display the detailed error mes-
sage. Select the Unlock <Application Name> checkbox, and click Retry Import on the error mes-
sage.
n Naming conflicts - Click the Failed Application Upgrade link to display the detailed error mes-
sage. Select Rename from the drop-down box, enter a new name for the object in the text box, and
click Retry Import on the error message.
In addition, you can perform these tasks for resolving locking and naming conflicts through the Application
Library tab.
You can continue accessing a workspace when an application that it contains fails to upgrade successfully
for additional troubleshooting. From the Relativity Applications tab, you can view the application details to
resolve application errors. When a workspace contains an application in this failed upgrade state,
Relativity displays an orange message bar across most of its pages, which contains with a warning
indicating that workspace upgrade isn’t complete.
For more information, see Troubleshooting application errors in the Relativity 9.6 Developers site.
11.3.2 Canceling or retrying workspace upgrades

You can cancel an upgrade job on a workspace or retry an upgrade job as necessary. After you cancel a
job, the workspace remains in a partially upgraded state so it is no longer accessible. You must attempt to
complete a successful upgrade in order to access the workspace.
Use this procedure to cancel or retry an upgrade job:
1. Perform one of these tasks to select the workspaces:

n To retry or cancel the upgrade jobs for only a specific group of workspaces, select their check-
boxes. In the mass operations bar, choose Checked.
n To retry or cancel the upgrade jobs for all workspaces, choose All Items in the mass oper-
ations bar.
2. Select Retry Upgrade or Cancel Upgrade in the mass operations bar.
3. Click Go to display a confirmation dialog.
4. Click OK if you want to continue with your selected action.
Upgrade Guide 162

11.3.3 Retrying upgrade failures for system secured applications
System secured applications are installed in the Application Library and hosted at the instance level. You
can resolve upgrade failures for system secured applications by manually retrying them through the
Application library tab. The following resolution for upgrade failures applies only to these applications.
11.3.3.1 Retrying system secured application upgrade failures in the Application Library
You can manually retry upgrading system secured applications through the Application Library tab.
1. Navigate to the Application Library tab.

2. Click the name of the failed application to display its detail view.
3. Click Install in the Workspace Installed section.
4. Click and select the Admin Case workspace in the pop-up picker.
5. Click Save. If the application fails to install, contact the Client Services team (sup-
port@relativity.com) team for additional help.
Upgrade Guide 163

12 Upgrading or installing your Analytics server
Note: Make sure you review the Analytics upgrade considerations before upgrading Analytics. For
more information, see Upgrade considerations for Relativity 9.6 on page 17.
An upgrade of your Analytics server is required for Relativity 9.6. Follow these steps to upgrade your
analytics server(s). Before upgrading the Analytics server(s), make sure you've completed the steps
contained in the following sections:
1. Install or upgrade your Relativity instance by performing the required steps.

2. Perform a See Analytics server setup in the Pre-Installation Guide.
This topic contains the following sections:
n Installing / Upgrading Relativity Analytics below

o Installing Analytics for the first time to Relativity 9.6.50.31 and above on the next page
o Upgrading from Relativity 9.3.362.9 (CAAT 3.19) and above on page 170
o Upgrading from Relativity 9.3.332.21 (CAAT 3.17) or prior on page 173
n Updating the default SSL/TLS certificate on page 179
n Disabling TLS 1.0 and 1.1 (optional) on page 186
n Installing Analytics server when SQL Server uses SSL encryption on page 187
n Changing the REST password on page 188
n Uninstalling the Relativity Analytics server on page 189
12.1 Installing / Upgrading Relativity Analytics

You need the following items in order to successfully run the Relativity Analytics upgrade or installation:
n The primary database server instance name and corresponding EDDSDBO password. If your SQL
Server uses SSL encryption, see Installing Analytics server when SQL Server uses SSL encryption
on page 187 before beginning the Analytics server installation.
n The Relativity Service Account username and password.
n All SQL Servers must be active and accessible at the time of the installation.
n A self-signed or a trusted SSL certificate with the certificate's private key is required by Relativity
Analytics. If you do not have a SSL certificate, see Updating the default SSL/TLS certificate on
page 179. We do not recommend self-signed certificates.
Upgrade Guide 164

Notes:
n Before attempting an upgrade, stop all Relativity Analytics engine processes (i.e., ensure that all
Java and Postgres processes are stopped). In versions previous to 9.5.133.118, the Windows Ser-
vice will be called Content Analyst CAAT. In Relativity 9.5.133.118 and above, the service will be
called Relativity Analytics Engine. After you do this, back up the CAAT install directory and the
CAAT data directory. If something goes wrong with the upgrade, this will greatly reduce any down-
time spent to fix the problem.
n The Analytics Index Share houses all of your Analytics data for a particular Analytics server, and it
can grow to be very large. We have found that NTFS file systems work for small environments, but
if you anticipate running sets of 10 million or more documents through your Analytics Engine, you
should use a file system that supports larger files such as exFAT or ReFS. We do not have a recom-
mendation for either file system, so you must determine which is the better fit for you.
This section contains the following content:
n Installing Analytics for the first time to Relativity 9.6.50.31 and above below
n Upgrading from Relativity 9.3.362.9 (CAAT 3.19) and above on page 170
n Upgrading from Relativity 9.3.332.21 (CAAT 3.17) or prior on page 173
12.1.1 Installing Analytics for the first time to Relativity 9.6.50.31 and above
12.1.1.1 Setting properties in the response-file.properties file

Before new installations, unzip the Analytics package and open the response-file.properties file in a text
editor. Complete the below Common Properties settings in the input file.
Note: For first time installs, all settings are considered and you must specify all response file values.
Check to make sure the provided default works with your environment.
The following are available properties in the response-file.properties file:
caat.install-dir
In former versions of the installer, this was called “Analytics Server folder.” This is the path to the folder
containing the Analytics installation files. This value is required for upgrades.
n We recommend using the default folder of C:\CAAT (or C:\ContentAnalyst for a legacy installation).
n This path must be absolute, and it can’t contain spaces or invalid characters.
n If the installer can't find or access the location you specify, it installs the application to the default
C:\CAAT folder.
A forward slash ( / ) or a double back slash ( \\ ) should be used as a path separator, rather than a single
back slash, as shown in the examples below.
caat.install-dir=C:/CAAT
caat.install-dir=C:\\CAAT
Note: Spaces cannot be present within the file path.
Upgrade Guide 165

caat.license-file
This is the file path to the license key file that will be installed to run the Analytics engine. Keep the default
of caat-license.jar. This value is required for upgrades.
caat.license-file=caat-license.jar
caat.http-port
In former versions of the installer, this was called “Analytics Server Port Number.” This is the HTTP port to
be used for requests to the Analytics engine. The HTTP port will default to 8080 for new installations, but
you can configure a different port number. For upgrades, the value entered will only be used to ensure
that the CAAT server is not running on that port.
caat.http-port=8080
caat.upgrade-now
Set this option to true. This value is required for upgrades.
caat.upgrade-now=true
caat.as-windows-service
This option should be set to true. Please note that this option is ignored upon upgrade.
caat.as-windows-service=true
caat.windows-service-name
This is the Windows service name. The service name will default to Relativity Analytics Engine if a service
name is not provided. Please note that the service name will not change upon an upgrade, and this value
is ignored upon upgrade.
caat.windows-service-name=Relativity Analytics Engine
caat.single-data-dir
In former versions of the installer, this was called “Analytics Index Directory.” The Analytics data directory
must also be created before installing Relativity Analytics. A forward slash ( / ) or a double back slash ( \\ )
should be used as a path separator, rather than a single back slash, as shown in the examples below.
This is the directory where indexes and structured analytics sets are stored on disk.
n We recommend that you not keep the index directory on the C: drive due to the size requirements.
n We recommend you use locally-attached storage referenced by a drive letter, i.e. E:\CAATindexes,
rather than a UNC path. For more information, see Index directory requirements in the Environment
optimization guide.
n Do not create a local drive map to a UNC. For example, do not open \\servername\CAAT1 and map
it to drive Z:. This is because drive mappings are specific to each Windows user and may not be
available to the Relativity Service Account.
n This path must be absolute, and it can’t contain spaces, invalid characters, or any Unicode.
n This value is ignored upon upgrade.
Upgrade Guide 166

caat.single-data-dir= E:/AnalyticsData
caat.single-data-dir= E:\\AnalyticsData
caat.single-data-dir= //servername/AnalyticsData
caat.single-data-dir= \\\\servername\\AnalyticsData
caat.min-heap-size
This is the minimum Java Heap size in megabytes. If this is left blank, the default will be used. The default
is 1/8 of total physical memory installed on the machine. It is recommended to leave this blank. This value
is ignored upon upgrade.
caat.min-heap-size=
caat.max-heap-size
This is the maximum Java Heap size (-xmx) in megabytes (e.g., 4096). If this is left blank the default will be
used. The default is 1/2 of total physical memory installed on the machine. This value should not be set
between 32 to 47 GB.
caat.max-heap=
caat.http.authentication-status
This value must be set to true.
caat.http.authentication-status=true
caat.http-password
In former versions of the installer, this was called “REST Password.” This is the password you create for
the REST API user. This can be any password that you choose, but for ease of use, you may want to enter
your Relativity Service account password. Whatever you enter here corresponds only with the REST API
password field on the Analytics server that you will add in Relativity after you install the Analytics server
here. This value isn't related to any pre-existing part of the system, meaning that it isn't the password for a
SQL login, Windows Domain user, or Relativity user. This value is required for upgrades.
Note: The caat.http-password value entered here must be 20 characters or less.
caat.http-password=SuperSecretPassword
Note: It is not possible to change an existing password with this entry. In order to change the password,
see Changing the REST password on page 188.
caat.http-user
In former versions of the installer, this was called “REST Username.” This is the username that a system
admin or Relativity uses to authenticate with the REST API. This can be any username that you choose,
but for ease of use, you may want to enter your Relativity Service account username. Whatever you enter
here corresponds only with the REST API username field on the Analytics server that you will add in
Relativity after you install the Analytics server here. This value isn't related to any pre-existing part of the
system, meaning that it isn't a SQL login, Windows Domain user, or Relativity user. This value is required
for upgrades.
Upgrade Guide 167

Note: It is not possible to change an existing username with this entry.
caat.http-user=AnalyticsUser
caat.ssl-status
This value needs to be set to true. This value is ignored upon upgrade.
caat.ssl-status=true
caat.ssl-certificate-key-path
This is the file path to the existing valid PKCS12 certificate-key file. This value is ignored upon upgrade. A
forward slash ( / ) or a double back slash ( \\ ) should be used as a path separator, rather than a single
caat.ssl-certificate-key-path=C:/CertPath/AnalyticsCert.pfx
caat.ssl-certificate-key-path=C:\\CertPath\\AnalyticsCert.pfx
Note: This value is required. The Relativity Analytics engine accepts both self-signed and trusted
certificates. To create a self-signed certificate, see Updating the default SSL/TLS certificate on
page 179.
caat.ssl-password
This is the SSL certificate password. This value is ignored upon upgrade.
caat.ssl-password=CertificatePasswordHere
Note: This value is required before performing a first time install.
12.1.1.2 Analytics installer considerations

Note the following before running the Relativity Analytics Server Installer:
n Run the server setup as the Relativity Service Account.

n You must have system admin rights to both the Analytics server and the index share path in order to
run the installer without interruption.
12.1.1.3 Running the Install.cmd file

1. Stop the Content Analyst CAAT Windows Service.
Note: This service may be named “Relativity Analytics Engine” depending on your version of
Relativity.
2. Open Task Manager and ensure all analytics processes have stopped. This includes java.exe, lsiap-
p.exe, postgres.exe, and booleng.exe. If the processes do not disappear after a few minutes, right
click them and kill the processes.
Upgrade Guide 168

3. After configuring the response-file.properties file (see Setting properties in the response-file.-
properties file), right-click on the Install.cmd file and select the “Run as administrator” option to
start the Analytics Installation. This can take several minutes to complete. The installation spe-
cifications will be displayed in the command line window. Do not close the command prompt until the
installation is complete.
4. (Optional) Monitor the status of the installation. The installation is finished after “The installation is
complete” message is displayed in the command prompt:
5. Once the installation is complete, change the Content Analyst CAAT (or Relativity Analytics Engine)
Windows service to run under the Relativity Service Account.
6. Relativity requires a certificate signed by a trusted certificate authority (CA). If you did not specify a
valid PKCS12 certificate-key file during installation or the certificate expired, you will need to update
the certificate. By default, the Analytics service runs over an untrusted SSL/TLS certificate. For
steps to modify, see Updating the default SSL/TLS certificate on page 179.
7. Start the Content Analyst CAAT (or Relativity Analytics Engine) Windows Service.
8. (Optional) Confirm that all components of the Analytics service are running by visiting: http://<Ana-
lytics Server Hostname>:<REST Port>/nexus/services
Check the Available Services list. Make sure to specify your Analytics server host name and REST
port in the URL.
9. If this is a new Analytics server, add it to the Servers list. For these steps, see Adding an Analytics
server in the Admin guide. If the server has already been added, navigate to the Servers tab and
activate it. Make sure to enter the information on the server layout the same as you did in the Ana-
lytics installer.
n If you enter the information correctly, you can successfully save the server.
n If you receive a not found error on the server, make sure the Analytics service is running and
that you used the correct port.
n If you get an unauthorized error, make sure that you entered the credentials correctly.
10. Verify that you have a valid URL value entered for the RestUriForCAAT instance setting. This is the
fully qualified domain name (FQDN) URL to the web server hosting your Kepler services (e.g.,
Upgrade Guide 169

12.1.1.4 Logging
During the installation or upgrade of the Relativity Analytics Engine, the process will log to a file (i.e.,
installer.log) in the logs directory (i.e., CAAT-win64-kcura-[Version].GA\logs).
The log pattern for each log message is described below:
n [log-level] [date] [thread-name] message (e.g., [INFO] [2017-01-18 19:05:54 [main]: Loading
installation options)
Note: Log messages will be appended to the same log file on subsequent runs.
12.1.2 Upgrading from Relativity 9.3.362.9 (CAAT 3.19) and above
12.1.2.1 Setting properties in the response-file.properties file (for upgrading to Relativity

9.6.50.31 or above)
Before upgrades or new installations, unzip the Analytics package and open the response-
file.properties file in a text editor.
For upgrades, only the following settings are considered:
n caat.install-dir
n caat.upgrade-now
n caat.license-file
n caat.http-user
n caat.http-password
For a complete list of settings and descriptions, see Installing Analytics for the first time to Relativity
9.6.50.31 and above on page 165.
Complete the following Common Properties settings in the input file.
caat.install-dir
In former versions of the installer, this was called “Analytics Server folder.” This is the path to the folder
containing the Analytics installation files. This value is required for upgrades.
n We recommend using the default folder of C:\CAAT (or C:\ContentAnalyst for a legacy installation).
n This path must be absolute, and it can’t contain spaces or invalid characters.
n If the installer can't find or access the location you specify, it installs the application to the default
C:\CAAT folder.
A forward slash ( / ) or a double back slash ( \\ ) should be used as a path separator, rather than a single
caat.install-dir=C:/CAAT
caat.install-dir=C:\\CAAT
Note: Spaces cannot be present within the file path.
Upgrade Guide 170

caat.upgrade-now
Set this option to true. This value is required for upgrades.
caat.upgrade-now=true
caat.license-file
This is the file path to the license key file that will be installed to run the Analytics engine. Keep the default
of caat-license.jar. This value is required for upgrades.
caat.license-file=caat-license.jar
caat.http-user
In former versions of the installer, this was called “REST Username.” This is the username that a system
admin or Relativity uses to authenticate with the REST API. This can be any username that you choose,
but for ease of use, you may want to enter your Relativity Service account username. Whatever you enter
here corresponds only with the REST API username field on the Analytics server that you will add in
Relativity after you install the Analytics server here. This value isn't related to any pre-existing part of the
system, meaning that it isn't a SQL login, Windows Domain user, or Relativity user. This value is required
for upgrades.
Note: It is not possible to change an existing username with this entry.
caat.http-user=AnalyticsUser
caat.http-password
In former versions of the installer, this was called “REST Password.” This is the password you create for
the REST API user. This can be any password that you choose, but for ease of use, you may want to enter
your Relativity Service account password. Whatever you enter here corresponds only with the REST API
password field on the Analytics server that you will add in Relativity after you install the Analytics server
here. This value isn't related to any pre-existing part of the system, meaning that it isn't the password for a
SQL login, Windows Domain user, or Relativity user. This value is required for upgrades.
Note: The caat.http-password value entered here must be 20 characters or less.
caat.http-password=SuperSecretPassword
Note: It is not possible to change an existing password with this entry. In order to change the password,
see Changing the REST password on page 188.
12.1.2.2 Analytics installer considerations

Note the following before running the Relativity Analytics Server Installer:

run the installer without interruption.
Upgrade Guide 171

12.1.2.3 Running the Install.cmd file
1. Stop the Content Analyst CAAT Windows Service.
Note: This service may be named “Relativity Analytics Engine” depending on your version of
Relativity.
2. Open Task Manager and ensure all analytics processes have stopped. This includes java.exe, lsiap-
p.exe, postgres.exe, and booleng.exe. If the processes do not disappear after a few minutes, right
click them and kill the processes.
3. After configuring the response-file.properties file (see Setting properties in the response-file.-
properties file), right-click on the Install.cmd file and select the “Run as administrator” option to
start the Analytics Installation. This can take several minutes to complete. The installation spe-
cifications will be displayed in the command line window. Do not close the command prompt until the
installation is complete.
4. (Optional) Monitor the status of the installation. The installation is finished after “The installation is
complete” message is displayed in the command prompt:
5. Once the installation is complete, change the Content Analyst CAAT (or Relativity Analytics Engine)
Windows service to run under the Relativity Service Account.
6. Relativity requires a certificate signed by a trusted certificate authority (CA). If you did not specify a
valid PKCS12 certificate-key file during installation or the certificate expired, you will need to update
the certificate. By default, the Analytics service runs over an untrusted SSL/TLS certificate. For
steps to modify, see Updating the default SSL/TLS certificate on page 179.
7. Start the Content Analyst CAAT (or Relativity Analytics Engine) Windows Service.
8. (Optional) Confirm that all components of the Analytics service are running by visiting: http://<Ana-
lytics Server Hostname>:<REST Port>/nexus/services
Check the Available Services list. Make sure to specify your Analytics server host name and REST
port in the URL.
server in the Admin guide. If the server has already been added, navigate to the Servers tab and
activate it. Make sure to enter the information on the server layout the same as you did in the Ana-
lytics installer.
Upgrade Guide 172

fully qualified domain name (FQDN) URL to the web server hosting your Kepler services (e.g.,
12.1.2.4 Logging
During the installation or upgrade of the Relativity Analytics Engine, the process will log to a file (i.e.,
installer.log) in the logs directory (i.e., CAAT-win64-kcura-[Version].GA\logs).
The log pattern for each log message is described below:
n [log-level] [date] [thread-name] message (e.g., [INFO] [2017-01-18 19:05:54 [main]: Loading
installation options)
Note: Log messages will be appended to the same log file on subsequent runs.
12.1.3 Upgrading from Relativity 9.3.332.21 (CAAT 3.17) or prior

Note: If you are upgrading from Relativity 9.3.332.21 (CAAT 3.17) or earlier, first run the Relativity
9.3.362.9 or 9.4 Analytics server installer using the below instructions. Contact Support for this installer.
After installation, run the response file-based installer (see Upgrading from Relativity 9.3.362.9 (CAAT
3.19) and above on page 170).
12.1.3.1 Analytics installer considerations (for upgrading to Relativity 9.5.89.76 or prior)

When you run the Relativity Analytics Server Setup wizard, the wizard automatically:
n Installs the CAAT service

n Deploys the Relativity library files
n Configures the java heap size (set by default to half of RAM)
o If you re-install the Analytics server after already adjusting the java heap size settings, the
new installation will overwrite the java heap adjustments you made.
n You can set an index path on new install, thus eliminating the need to manually set the location of
indexes
n Sets the CAAT Windows service to log in as the Relativity Service Account
Note the following before running the Relativity Analytics Server Setup:

run the installer without interruption. If you don't, the installer informs you that the directories can't
be configured and that you must check to make sure that your permissions are correct.
Upgrade Guide 173

Note: If a "Could not configure security for the following directories" warning occurs during your
Analytics installation or upgrade, see on page 176.
12.1.3.2 Running the Relativity Analytics Server Setup wizard (Relativity 9.5.89.76 or prior)
Follow these steps to run the Relativity Analytics Server Setup:
1. Open the Relativity Analytics Server Setup package. Right-click and click Run.
2. Click Next on the Relativity Analytics Server Setup welcome dialog.
3. Enter values for the following Primary Database Server Configuration fields and click Next:
n Primary Database Server Instance - the primary database server to which you want to
install the Content Analyst service. The value you enter must match the Name value recorded
on the Servers tab in Relativity.
n EDDSDBO Password - the password to the EDDSDBO account of the primary database. If
you change the password to your primary database server instance, you must re-run the
Relativity Analytics Server Setup wizard.
n Relativity Service Account - the service account of the Relativity instance that is using this
installation of Content Analyst. You must use the following format for the service account
name: <domain>\<user>.
n Relativity Service Account Password - the password for the Relativity instance.
4. Enter values for the following REST API configuration fields, and then click Next. These values must
match those of the corresponding fields on the Analytics server object in Relativity. For more inform-
ation, see Servers in the Admin Guide.
n REST Port - the port that the REST API will use via https. By default, this setting uses port
8443.
n REST Username - the username that a system admin or Relativity uses to authenticate with
the REST API. This can be any username that you choose, but for ease of use, you may want
to enter your Relativity Service account username. Whatever you enter here corresponds
only with the REST API username field on the Analytics server that you will add in Relativity
after you install the Analytics server here. This value isn't related to any pre-existing part of
the system, meaning that it isn't a SQL login, Windows Domain user, or Relativity user.
n REST Password - the password you create for the REST API user. This can be any
password that you choose, but for ease of use, you may want to enter your Relativity Service
account password. Whatever you enter here corresponds only with the REST API password
field on the Analytics server that you will add in Relativity after you install the Analytics server
here. This value isn't related to any pre-existing part of the system, meaning that it isn't the
password for a SQL login, Windows Domain user, or Relativity user.
n Confirm REST Password - retype the password you created for the REST API user.
5. Check, edit, or enter the values for the following RelativityAnalytics Server Installation fields,
and then click Install. These are automatically populated and are editable only if there is no existing
installation of Content Analyst. If there is an existing installation of Content Analyst that has a non-
default service name, Relativity isn't able to detect that installation. Thus, you must enter the correct
values for these fields to successfully upgrade your installation of CAAT:
Upgrade Guide 174

n Analytics Server folder - the path to the folder containing the Analytics installation files.
o We recommend using the default folder of C:\CAAT (or C:\ContentAnalyst for a legacy
installation).
o This path must be absolute, and it can’t contain spaces or invalid characters.
o If the installer can't find or access the location you specify, it installs the application to
the default C:\CAAT folder.
n Analytics Server Service Name - the Windows service name of the Analytics instance. We
recommend leaving this as the default value. This can't contain any invalid characters and it
can't exceed 80 characters.
n Analytics Server Port Number - the port number of the Analytics server. The default port is
8080, but you can configure a different port number.
n Analytics Index Directory - the directory where indexes and structured analytics sets are
stored on disk.
o We recommend that you not keep the index directory on the C: drive due to the size
requirements.
o We recommend you use locally-attached storage referenced by a drive letter, i.e.
E:\CAATindexes, rather than a UNC path. For more information, see Index directory
requirements.
o Do not create a local drive map to a UNC. For example, do not open \\server-
name\CAAT1 and map it to drive Z:. This is because drive mappings are specific to
each Windows user and may not be available to the Relativity Service Account.
o This path must be absolute, and it can’t contain spaces, invalid characters, or any
Unicode.
o Always use the installer to make changes to your Analytics configuration, including the
index directory. If you need to specify a new folder path, see Moving Analytics indexes
and structured analytics sets in the Admin Guide.
n Postpone upgrading data elements until accessed at runtime - When this is checked,
structured analytics data is not upgraded until it's accessed for the first time (recommended).
When this is unchecked, structured analytics data is upgraded as part of the overall CAAT
upgrade process (this may cause the upgrade to take a much longer time).
Note: If using a UNC path for the Analytics Server Folder and (Optional) Analytics Index
Share Folder fields, the path must point to a Windows server directory.
When you first click Install, Relativity unzips the Analytics installer. This can take several minutes to
complete.
6. (Optional) Monitor the status of the installation. You don't have to click next once this process is com-
plete.
7. (Optional) Note the installation specifications in the command line window. Do not close this during
installation. It closes automatically when installation is complete and the final step of the wizard
appears.
Upgrade Guide 175

8. Click Finish to complete the installation.
9. Relativity 9.3 and above requires a certificate signed by a trusted certificate authority (CA). By
default, the CAAT service runs over an untrusted SSL/TLS certificate. For steps to modify, see
Updating the default SSL/TLS certificate on page 179.
10. (Optional) Confirm that all components of the Analytics service are running by visiting http://<Ana-
lytics Server Hostname>:<REST Port>/nexus/services and checking the Available Services list.
Make sure to specify your Analytics server host name and REST port in the URL.
server on the Documentation site. If the server has already been added, navigate to the Servers tab
and activate it. Make sure to enter the information on the server layout the same as you did in the
Analytics installer.
Content Analyst is now installed in your environment.
12.1.3.3 Addressing "Could not configure security" installer warning

The following warning message may occur when upgrading or installing Relativity Analytics:
Could not configure security for the following directories:
Please confirm that the Relativity Service account has full control on them.
Upgrade Guide 176

This warning that indicates that the user account running the installer failed to update the permissions on
the listed directories for the Relativity Service account . After you acknowledge the warning, continue and
complete the installation or upgrade of Analytics. The installation is still valid.
After finishing the Analyics installation or upgrade, complete the following steps to ensure the Relativity
Service account has appropriate access to the directories listed in the warning message:
1. Stop the Content Analyst CAAT Windows service if it's running.

2. Add the Relativity Service Account user to the Administrators and Users groups.
3. Grant the Relativity Service Account Full Control permissions on C:\CAAT (the installation dir-
ectory).
4. Grant the Users group Full Control permissions on C:\CAAT\pgsql\data.
5. If the installation contains a C:\CAAT\data-default folder, grant the Users group Full Control per-
missions on this folder.
6. If the index directory is different from the default (i.e. on another drive or share), ensure the Relativ-
ity Service Account has Full Control permissions on the index directory.
7. Restart the Analytics server after updating the user and group permissions.
8. Verify the Relativity Service Account is running the CAAT Content Analyst Windows Service.
12.1.3.4 Upgrading clusters for CAAT 3.17.2 and above from Relativity 9.1 or prior
Note: The instructions in this section are only necessary when upgrading from Relativity 9.1 or below.
Relativity 9.2.271.9 installs CAAT 3.17.2 which includes clustering performance improvements. You must
upgrade your existing clusters if they were created using a version of CAAT previous to 3.17.2.
To upgrade your clusters, use one of the following upgrade methods:
n Run Create Cluster Upgrade Jobs script below

n Upgrade clusters on the fly on page 179
Run Create Cluster Upgrade Jobs script

Complete the following steps to automate the cluster set upgrade process by creating upgrade jobs for
one workspace or all workspaces using the Create Cluster Upgrade jobs script:
1. Navigate to Home.
2. Click the Relativity Script Library tab.
3. Locate and click the Create Cluster Upgrade Jobs script.
4. Click Run Script.
5. Select the workspace that contains the clusters you want to upgrade from the Workspace Name
drop-down menu or select <All Workspaces> to upgrade all clusters in all of your workspaces.
Upgrade Guide 177

6. Click Run followed by OK.
7. Close the Create Cluster Upgrade Jobs script dialog.
Cluster upgrade jobs added by the Create Cluster Upgrade Jobs script are managed by the Cluster
Upgrade Worker agent. See the Agents guide for more information regarding the Cluster Upgrade Worker
agent.See the Admin Guide for additional details regarding the Create Cluster Upgrade Jobs script and
script results.
Monitor cluster upgrade jobs

The Monitor Cluster Upgrade Jobs script checks and reports the status of all Analytics cluster upgrade
jobs added using the Create Cluster Upgrade Jobs script.
Complete the following steps to view a count of clusters that are upgraded and not upgraded by
workspace:
1. Navigate to Home.
2. Click the Relativity Script Library tab.
3. Locate and click the Monitor Cluster Upgrade Jobs script.
4. Click Run Script.
5. Click Run. With the Monitor Cluster Upgrade Jobs dialog still open, click Run again to refresh the
list.
Upgrade Guide 178

6. Close the Monitor Cluster Upgrade Jobs script dialog.
See the Admin Guide for additional details regarding the Monitor Cluster Upgrade Jobs script and script
results as well as steps to identify failed cluster upgrades.
Upgrade clusters on the fly

If you have any clusters created using versions of Content Analyst previous to CAAT 3.17.2 that weren't
upgraded using the Create Cluster Upgrade Jobs script, the system automatically calculates and stores
the cluster distance data on the fly when a user first clicks to view a cluster's nearby cluster visualization.
The on the fly upgrade and calculation require anywhere from a few seconds to a number of minutes
depending on the size and complexity of the data. While the system upgrades a cluster and calculates the
distance data, the cluster can't be accessed using cluster visualization, and a notification message informs
the user the cluster data is being updated.
When the upgrade and calculation processes complete for a cluster, users can access the cluster using
cluster visualization with the performance improvements in effect.
12.2 Updating the default SSL/TLS certificate

Note: The below section is required if you are installing Relativity for the first time or if you are
upgrading from Relativity 9.3.332.21 (CAAT 3.17) or earlier.
As of Relativity 9.3, Relativity requires a trusted certificate for all HTTPS traffic, including the internal traffic
for the Analytics server. We recommend placing the certificate and testing it prior to the day of the upgrade
to Relativity 9.3. By default, the Content Analyst (CAAT ®) service runs over an untrusted SSL/TLS
Upgrade Guide 179

certificate. There are several options for getting a trusted certificate in place. You most likely already have
a certificate for your externally facing web servers. However, it’s likely that the domain name for that
certificate doesn’t match the internal fully qualified domain name (FQDN) of the Analytics server(s). If it
DOES match, you may use the same certificate currently on your web server.
For example, if the external certificate is *company.com but your domain is *.company.corp, then this does
not match and cannot be used. If it does not, we strongly recommend purchasing one from a trusted
certificate authority and placing it on the Analytics server before the upgrade. If you choose not to
purchase a certificate, it is possible to use a self-signed certificate as a temporary measure. Should you
choose to do this, we recommend using the fully qualified domain name when creating the self-signed
certificate so that it can be swapped for a real certificate from a trusted authority later on.
To check the fully qualified domain name (FQDN) of the Analytics server:
1. Open the Control Panel.

2. Navigate to Control Panel\System and Security\System.
3. Under the Computer name section, find the entry for Full Computer Name.
4. If you have an existing certificate, verify that it matches the FQDN of the Analytics server.
n If it does not, you must either purchase a new certificate or generate a self-signed certificate.
12.2.1 Overview of how to update the SSL / TLS certificate

Perform the following steps to use a certificate. The detailed substeps under each major step are outlined
in the section below.
1. Delete the default, unsigned certificate.

2. If you have a trusted certificate (that uses the FQDN), proceed directly to step 3 (importing a cer-
tificate). Otherwise, Create a self-signed certificate first before proceeding to step 3.
Note: It is recommended that you use a certificate from a trusted authority (if possible). For
workgroup environments, a self-signed certificate is necessary.
3. Import a certificate (trusted or self-signed) that uses the FQDN.

4. Verify the Analytics server in Relativity.
12.2.2 1) Deleting the default, unsigned certificate

Complete the following steps to delete the default, unsigned certificate:
Note: Replace the jdk1.8.0_144 noted in the instructions for the sections below with the relevant
Revision Number of the Java Virtual Machine for the SSL / TLS certificate command lines (if you are
using a version prior to 9.5.196.102). This value is found in the naming of the CAAT install directory.
1. Log in to the analytics server as the Relativity Service Account.

2. Open a command prompt window.
3. View a list of all certificates in the keystore by running the following command:
<PathToKeystore> - this is the file path to the keystore. To find this path, open start.ini and look
for the jetty.keystore value.
Upgrade Guide 180

C:\CAAT\jdk1.8.0_144\bin\keytool.exe -list -keystore <<PathToKeystore>> -v
Note: These commands assume that the CAAT installation directory is C:\CAAT. They may need
to be modified to account for differing installation drive letters or installation folder names.
4. You will be prompted to enter a keystore password. The default password is caat4me. Type this
into the command prompt and then hit Enter.
Note: The password will not appear on the screen while typing.
5. Take note of the certificate(s) listed in the keystore. The alias name for the default CAAT® cer-
tificate to be deleted is contentanalyst.
6. To delete the default CAAT certificate, run the following command:
C:\CAAT\jdk1.8.0_144\bin\keytool.exe -delete -keystore <<PathToKeystore>> -alias contentanalyst
12.2.3 2) Creating a self-signed certificate (no trusted certificate) - optional

step
Complete the following steps to create a self-signed certificate in Powershell:
1. Copy the internal fully qualified domain name (FQDN) of the Analytics server(s) in a text file for use
later in this process. You can determine this value by running the following command in a command
prompt window on your Analytics server:
echo %COMPUTERNAME%.%USERDNSDOMAIN%
2. Run PowerShell as an administrator.

3. Create your self-signed certificate in PowerShell using the following command (replace <<host-
name>> with the output of the command from step 1):
New-SelfSignedCertificate -certstorelocation cert:\localmachine\my -dnsname <<hostname>>
Running that command will add the self-signed certificate to the local certificate store and generate
a thumbprint (e.g., CE0976529B02DE058C9CB2C0E64AD79DAFB18CF4).
4. Copy the thumbprint for use later.
5. In the PowerShell window, enter the following command to populate a variable with a password
you'll use when exporting the certificate from the local certificate store (replace <<password>> with
a password of your choice):
$pwd = ConvertTo-SecureString -String "<<password>>" -Force -AsPlainText
6. Export the certificate from the local certificate store to a directory of your choosing accessible to the
keystore (replace <<thumbrint>> with the output of the command in step 4 and replace <<pfxcert-
filepath>> with the destination filepath for the pfx certificate that will be generated):
Upgrade Guide 181

Export-PfxCertificate -cert cert:\localMachine\my\<<thumbprint>> -FilePath <<pfxcert-file-
path\filename.pfx>> -Password $pwd
Example:
Export-PfxCertificate -cert cert:\localMachine\my\D660E83A0E84653F27C3D1A9BDFFB6258392E92E -

FilePath c:\selfsigned.pfx -Password $pwd
Note: Note: Do not export the cert as a *.cer file. A *.cer file does not include the certificate’s
private key and will not work in CAAT.
7. If this is an upgrade, import the self-signed certificate into the keystore. See Importing a certificate
(trusted or self-signed) for more information. If this is a new installation, update the response.-
properties file as follows:
n caat.ssl-certificate-key-path - use the certificate you generated in Powershell in step 3.
n caat.ssl-password - use the <<password>> value you generated in step 5.
Note: In some cases, you may have a security policy in pace that prevents the export of the cert's
private key. CAAT must have the certificate's private key in order for SSL to function. You must
either override your security policy or generate a new SSL certificate with a new private key and
export this new certificate and private key.
Complete the following steps to create a self-signed certificate in command prompt:
1. Run the following command from the Analytics server:

C:\CAAT\jdk1.8.0_25\bin\keytool.exe -genkey -keyalg RSA -alias selfsigned -keystore <<PathToKey-

store>> -storepass caat4me -validity 360 -keysize 2048
2. You will be prompted several times. Enter the FQDN of the Analytics server for all prompts except
the last, which is just the country abbreviation.
3. Use the same keypass as the keystore when prompted. You can either hit return or type in
caat4me.
4. Export the certificate using the following command:
C:\CAAT\jdk1.8.0_25\bin\keytool.exe -export -alias selfsigned -file C:\selfsigned.pfx -keystore

C:\CAAT\etc\ssl\server.keystore
5. Restart the Content Analyst CAAT windows service.

6. Import the certificate to the Trusted Root of the following servers:
n Analytics servers
n Agent servers
Upgrade Guide 182

n Primary and distributed SQL servers
n Web servers
To do so, complete the following:
a. Navigate to the endpoint for the CAAT certificate (https://<server-

name.FQDN>:8443/nexus/r1/).
b. A warning will appear indicating there is a problem with the website’s security certificate. Click
"continue to this website (not recommended)".
c. Upon clicking continue, you will be prompted to enter your REST account credentials.
d. Click on the certificate error in the address bar.
e. Click View Certificates.
f. Click Install Certificate.
g. Import the certificate to either the Current User or Local Machine store location.
h. Select "Place all certificates in the following store" and browse for "Trusted Root Certification
Authorities".
i. Click Finish.
j. Test that the import was successful by navigating to the REST site again.
k. Repeat this process for each server listed above.
7. Proceed to 4) Verifying the Analytics server in Relativity on page 185.
12.2.4 3) Importing a certificate (trusted or self-signed)

The certificate you import must be a PKCS12 certificate with the certs private key.
When you have a valid certificate (trusted or self-signed) matching the FQDN of the analytics server,
complete the following steps to import it to the keystore:
1. Run the following command, replacing <Certificate> with the file path, name, and extension of the
certificate (i.e., C:\folder\RelativityCert.pfx) and replace <CertPassword> and <Destin-
ationPassword> with the relevant passwords.
<CertPassword> - this is the password of the certificate. (For a self-signed certificate, this
password was set when exporting the cert from the local certificate store. For a trusted certificate,
this must be provided to you by the CA or your IT admins.)
<DestinationPassword> - this is a value you are setting now, it will be used while modifying start.ini
in step 4.
Upgrade Guide 183

C:\CAAT\jdk1.8.0_144\bin\keytool.exe -importkeystore -srckeystore <<Certificate>> -srcstorepass
<<CertPassword>> -srcstoretype pkcs12 -destkeystore <<PathToKeystore>> -destkeypass
<<DestinationsPassword>> -deststoretype JKS
2. When prompted for the keystore password, enter it again.
Note: The default password for the keystore is caat4me. The password for the certificate must
match the password for the keystore. The password will not appear on the screen while typing.
3. Verify that the certificate is in the keystore by running the following command to list the certificates:
C:\CAAT\jdk1.8.0_144\bin\keytool.exe -list -keystore <<PathToKeystore>> -v
4. Modify the start.ini file as detailed below (C:\CAAT\start.ini).
Note: If you are upgrading from a version before Relativity 9.6, you may find the start.ini file in the
following folder: C:\CAAT\start.d\ssl.ini .
a. Ensure that --module=ssl is uncommented

b. Ensure that jetty.keystore and jetty.truststore match the keystore path specified in step 1.
c. Ensure that the following Jetty passwords match the value set in step 1 while importing the
cert into the keystore
n jetty.keystore.password
n jetty.keymanager.password
n jetty.truststore.password
Note: Optional: For instructions on how to change and obfuscate the default Jetty
passwords, refer to the Relativity Community.
5. Restart the Content Analyst CAAT windows service.
Note: The endpoint for the CAAT certificate is https://<servername.FQDN>:8443/nexus/r1/.
6. Test the certificate by opening a browser from the Analytics server and at least one other server and
navigating to the endpoint above. You should not get a certificate error when navigating to the URL.
Upgrade Guide 184

7. Depending on whether you have a trusted certificate or a self-signed certificate, proceed as follows:
n If you are using a trusted certificate , you can proceed directly to Verifying the Analytics server
in Relativity.
n If you are using a self-signed certificate, proceed to step 8.
8. If you have imported a self-signed certificate, import the certificate to the Trusted Root of the
following additional servers:
n Analytics servers
n Agent servers
n Primary and distributed SQL servers
n Web servers
Note: For Relativity 9.6.202.10 and above, import the certificate to the Trusted Root of the
following servers: Agent servers, Web servers, Service Bus, and Secret Store.
To do so, follow these instructions:

a. Navigate to the endpoint for the CAAT certificate
(https://<servername.FQDN>:8443/nexus/r1/).
b. A warning will appear indicating there is a problem with the website’s security certificate. Click
"continue to this website (not recommended)".
Upon clicking continue, you will be prompted to enter your REST account credentials.
c. Click on the certificate error in the address bar.
d. Click View Certificates.
e. Click Install Certificate….
f. Import the certificate to either the Current User or Local Machine store location.
g. Select "Place all certificates in the following store" and browse for "Trusted Root Certification
Authorities".
h. Click Finish.
i. Test that the import was successful by navigating to the REST site again.
j. Repeat this process for each server listed above.
9. Proceed to Verifying the Analytics server in Relativity.:
12.2.5 4) Verifying the Analytics server in Relativity

Verify in Relativity that the Analytics server URL uses the FQDN and not the server name or IP address.
Navigate to the Servers tab, and check the URL of the Analytics server. If it does not contain the FQDN,
then follow these steps:
FQDN URL to the web server hosting your Kepler services (e.g., https://cli-
ent.domain.name/Relativity.REST/API).
Upgrade Guide 185

2. Add a new Analytics server from the Servers tab in Relativity. See Adding an Analytics server in the
Admin Guide for more information.
When entering the URL:
a. Use this format: https://<servername.FQDN>:8443/. (For versions of Relativity prior to
9.4.361.1, use this format: http://<servername.FQDN>:8080/nexus/services/)
b. Duplicate all other settings from the original Analytics server.
3. Add the new Analytics server to all of the same Resource Pools as the original server.
4. Add the Analytics Move script to the Relativity Script Library and run the script.
a. Navigate to the Relativity Script Library tab.
b. Click New Relativity Script.
c. Select and copy the contents of the Analytics Move script file. Paste the script text into the
Script Body field, overwriting the default script body text.
d. Click Save.
5. Test functionality by creating a small structured analytics set or index.
6. Run the Analytics Move script to swap all references from the original server to the new server just
created.
7. Delete the old Analytics server from the Servers tab in Relativity.
12.3 Disabling TLS 1.0 and 1.1 (optional)

1. Open C:\CAAT\jetty\etc\jetty-ssl.xml.
2. Insert <Set name="ExcludeProtocols"> item in the configuration file as shown below at the end of
Configure a TLS (SSL) Context Factory.
<Item>SSL_RSA_EXPORT_WITH_DES40_CBC_SHA</Item>
<Item>SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA</Item>
<Item>SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA</Item>
</Array>
</Set>
<Set name="ExcludeProtocols">
<Array type="String">
<Item>TLSv1</Item>
<Item>TLSv1.1</Item>
</Array>
</Set>




3. Restart the Content Analyst (CAAT) Windows service.

4. Update the registry key on all web and agent servers:
Upgrade Guide 186

a. Create or update the following registry keys on each server as shown below. You should be
able to create a *.reg file out of the snippet below.
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
b. Restart IIS or the agent service on each applicable server.
5. Verify that the connection works by clicking Save in the Analytics Server layout.
12.4 Installing Analytics server when SQL Server uses SSL

encryption
When your primary SQL Server uses SSL encryption, you must satisfy the following additional
environment requirements in order for the Analytics server to communicate with SQL Server:
n The SQL Server's certificate is installed in the Analytics server KeyStore. See Install a SQL Server
certificate in the Analytics server KeyStore below
n The Common Name (CN) property of the SQL Server's certificate matches the server name value
recorded for the SQL Server in Relativity. See Use the CN property of a SQL Server certificate in
Relativity on the next page.
12.4.1 Install a SQL Server certificate in the Analytics server KeyStore

Complete the following steps to install a SQL Server's certificate in your Analytics server KeyStore:
1. Export the SQL Server's certificate in X.509 DER format and place a copy of the certificate on the
Analytics server.
2. Note the CN property value recorded in the certificate.
3. Open the following directory in a command prompt on your Analytics server :
<CAAT install drive>\jdk1.x\jre\lib\security
The <CAAT install drive> reference represents the Analytics server installation folder, and x
represents the version of the JDK installed on your Analytics server. Browse to the security
directory using Windows Explorer first to ensure you use the correct Analytics server installation
path.
4. Run the following command from the command prompt:
..\..\bin\keytool.exe -import -alias <CN> -keystore cacerts -file <path to cert file from Step
1>
Replace <CN> with the CN property recorded in the SQL Server's certificate and replace <path to
cert file from Step 1> with the path location of the certificate file you copied to the Analytics server.
5. Enter your Java KeyStore password followed by yes when prompted to install the certificate.
Upgrade Guide 187

Note: This step is only required if your Java KeyStore is password protected. Please refer to
Oracle for default Java password information.
12.4.2 Use the CN property of a SQL Server certificate in Relativity

When running an Analytics server with a SQL Server that uses SSL encryption, the name of the
SQL Server recorded on the Servers tab in Relativity and the name entered during Analytics server
installation must match the CN value recorded in the SQL Server's security certificate. When running the
Relativity Analytics Server installation, enter the CN property value from your SQL Server's certificate in
the Primary Database Server Instance field on the Primary Database Server Configuration dialog.
Note: If your SQL Server's Name value recorded on the Servers tab in Relativity doesn't match the
CN property in the SQL Server's security certificate, contact support@relativity.com for assistance with
updating the SQL Server name in Relativity. Change the SQL Server's Name value in Relativity after you
complete the Analytics installation.
12.5 Changing the REST password

Changing the REST password
If you need to change the REST password, perform the following steps:
1. Navigate to the C:\CAAT\etc folder on the Analytics server. Open the realm.properties file in a text
editor.
2. The REST Username displays on the left and a BCrypt Hash Password displays on the right side:
You'll need an encryption tool to encrypt a new BCrypt Hash Password. We recommend using
BCrypt Calculator.
3. Once you have encrypted a new BCrypt Hash Password, copy and paste your newly encrypted
password in the C:\CAAT\etc\realm.properties file (replacing the old password).
4. Save the realm.properties file.
5. Restart the Relativity Analytics Engine / Content Analyst Windows service.
Once the password is updated on the Analytics server, you must update it in Relativity.
6. Navigate to Relativity.
7. Navigate to the Servers tab, and then select Edit next to the Analytics server.
8. Update the REST API password, and then click Save.
Upgrade Guide 188

12.6 Uninstalling the Relativity Analytics server
We don't recommend uninstalling the Relativity Analytics Server application for any reason as it causes
data loss. If you uninstall the Relativity Analytics Server application from the analytics server, all structured
analytics sets created in Relativity 8.2 and above can't be used with another installation. There is no way to
merge a previous Relativity Analytics Server installation with a new installation. As a result, structured
analytics sets created in Relativity 8.2 and above become unusable.
You shouldn't uninstall the application from the server unless you're certain you won't use the server for
Analytics functionality in the future, and you understand that uninstalling Relativity Analytics renders
structured analytics sets created in Relativity 8.2 and above unusable.
If you still need to uninstall the Relativity Analytics components from the server, complete the following
steps:
Uninstalling Relativity Analytics
1. Open Windows Services and stop the Content Analyst CAAT or Relativity Analytics Engine Windows
service if it is running.
2. Open Task Manager, and check to see if Java is running. If it is, right click it, and then select End
process tree.
3. Navigate to the Analytics directory (e.g., C:\CAAT).
4. Run the C:\CAAT\bin\unregisterWinService.cmd file as an Administrator to unregister the Win-
dows service.
5. If desired, delete the Analytics installation directory (e.g., C:\CAAT) and the index directory asso-
ciated with Analytics.
Note: Any structured analytics sets created in Relativity 8.2 and above are no longer usable.
Upgrade Guide 189

13 Upgrading Data Grid
The Data Grid Core and Audit applications are updated automatically with Relativity. If you are upgrading
to Relativity 9.6 and your environment uses Elasticsearch 2.3.3.58 or below to store audits, you must
upgrade to Elasticsearch 2.3.3.79 or above when upgrading to Relativity 9.6. Once you upgrade to
Elasticsearch 2.3.3.79, you're unable to use your Elasticsearch clusters with 2.1.2 or have a partially
upgraded cluster.
n If you are upgrading to Relativity 9.6 from a version prior to Relativity 9.5.219.30, you must move
your long text data out of Elasticsearch and import to SQL. After upgrade, reimport the data to Data
Grid. Only then will you be able to access your long text in Data Grid. For more information contact
Relativity Support.
13.1 Finding the Elasticsearch version

To find the version of Elasticsearch installed, you must connect to your client node endpoint. The client
node is a member of a Relativity Data Grid Elastic cluster. The client nodes stores no data itself; rather, it
communications to and from Relativity agent and web servers and the Data Grid Elastic cluster.
The client node is the value in the AuditDataGridEndPoint and/or DataGridEndPoint instance setting.
To connect to the client endpoint, enter the following URL into Chrome or Firefox, substituting the name of
your client node. Internet Explorer won't properly display the page.
Note: You may be prompted for a username and password. If you are not sure of the username and
password, see Resetting the Shield or Head password on page 197.
http://nameofclientnode:9200/
Once you connect to the endpoint, the following page appears which displays, among other things, your
Elasticsearch version number.
Upgrade Guide 190

13.2 Upgrading from Elasticsearch 2.1.2 to 2.3.3.x
In order to upgrade Elasticsearch from 2.1.2 to 2.3.3.x, complete the following workflow:
Click to expand instructions for upgrading Elasticsearch.
n Prepare the environment for upgrade. For more information, see Preparing the environment for
upgrade below.
n Run the upgrade script on data, master, and client nodes in that order. For more information, see
Running the upgrade script on the next page.
n Verify your upgrade completed successfully. For more information, see Verifying the upgrade on
the next page.
If you want to manually upgrade Elasticsearch, see Running a manual upgrade on page 193.
13.3 Preparing the environment for upgrade

Before upgrading Elasticsearch, perform the following:
n Ensure that the Elasticsearch service is running under a user account that has access to SQL
Server, and specifically has read, write, and bulk permissions for all workspace databases.
n Verify that no reads or writes to Elasticsearch occur during the upgrade process.
n Disable all Audit migration and deletion agents.
n Disable all Text migration and deletion agents.
n Verify that all imports or publishing from Processing have stopped.
n Save a backup of the current lib and bin folders from any node and the data folder from the master
node to mitigate the risk in possible restoration. Don’t save the backup files to the installer folder.
n If you are also upgrading Java versions, open the command prompt and run the following com-
mand. This example assumes you are upgrading to Java 8 Update 45 (64-bit). Edit the version num-
ber appropriately.
SETX /M KCURA_JAVA_HOME "C:\Program Files\java\jdk1.8.0_45"
n Disable shard allocation:

o Run the following command in Sense to turn off re-balancing and set the cluster to persistent.
The persistent state ensures that re-balancing stays off when the cluster restarts.
PUT _cluster/settings
{
"persistent":{"cluster.routing.allocation.enable": "none"}
}
o Run the following command to perform a synced flush:
POST /_flush/synced
Upgrade Guide 191

13.4 Running the upgrade script
Note: If you run the script on Powershell versions earlier than 5.1, the script displays an error during
back up but will continue with the upgrade.
Extract the contents of the upgrade package, and make sure the following files are in the folder:
n datagrid-2.3.3.58-install.zip
n elasticupgrade.ps1
n upgrade.psd1
You must run the upgrade script on each node. We recommend the following order when upgrading your
nodes:
1. Data nodes
2. Master nodes
3. Client nodes
To upgrade a node, complete the following:
1. Open the upgrade.psd1 file in a text editor. Update the following configurations:
n UpgradeFile - enter the file path to the upgrade package.
n CurrentPath - enter the current location of the installed Elasticsearch service.

n Url - enter the URL of the local machine's Elastic endpoint.
n UserName - (optional) enter the service user name that has access to SQL.
n Password - (optional) enter the password for the server user.
2. Run elasticupgrade.ps1.
13.5 Verifying the upgrade

After you upgrade all of the nodes on your cluster, complete the following on the cluster to complete the
upgrade:
1. Run the following command in Sense:
GET /_nodes/jvm?filter_path=**.jvm.gc_collectors
Ensure the result shows "ParNew", "ConcurrentMarkSweep".

2. Enable shard allocation to rebalance the cluster:
{
"persistent":{"cluster.routing.allocation.enable": "all"}
}
You can monitor the indexes by running the following in Sense:
Upgrade Guide 192

GET _cat/recovery?&v
3. Verify the cluster status by running the following command in Sense.
GET _cat/health
Once the cluster is GREEN, your node restart is complete.

If the cluster status remains RED for an extended period, run the following in Sense to identify which
indexes are RED:
Note: If you are using Kibana, ensure your version of Kibana is compatible with your version of
Elasticsearch.
Note: With Shield on by default, other plugins like Marvel or Head are not supported. In order to use
your other plugins, you need to provide the Kibana server with credentials so it can access the .kibana
index and monitor the cluster. See the Relativity Data Grid guide for more information.
13.6 Running a manual upgrade

Click to expand instructions on how to run a manual Elasticsearch upgrade
n Prepare the environment for upgrade. For more information, see Preparing the environment for
upgrade on page 191.
n Upgrade your data, master, and client nodes in that order. For more information, see Upgrading a
node below.
n Verify your upgrade completed successfully. For more information, see Verifying the upgrade on
page 196.
13.6.1 Upgrading a node

Perform the following steps on each node in the cluster. We recommend the following order when
upgrading your nodes:
1. Data nodes
2. Master nodes
3. Client nodes
To upgrade a node, complete the following:
1. Shut down the node.

a. Open a Windows command prompt as an administrator, and then navigate to the bin dir-
ectory in the RelativityDataGrid folder.
Upgrade Guide 193

c:\RelativityDataGrid\elasticsearch-main\bin
b. Stop the Elasticsearch service by running the following command:
.\kservice.bat stop
Note: If the service doesn't shut down after being stopped, end the process using Process
Explorer.
2. Save your current Java settings.

a. Run the following:
.\kservice.bat manager
b. On the Java tab, take note of the values for the following settings:
n Initial memory pool
n Maximum memory pool

n Thread stack size
3. Remove the service:
.\kservice.bat remove
Upgrade Guide 194

4. Delete the old lib, bin, sqlauth, modules, and plugin folders from \Relativ-
ityDataGrid\elasticsearch-main.
n Copy the lib, bin, sqlauth, modules, and plugin folders from the Elastic 2.3.3.x extracted
zip file to \RelativityDataGrid\elasticsearch-main.
5. Configure the elasticsearch.yml file (\RelativityDataGrid\elasticsearch-main\-
config\elasticsearch.yml) with the following:
a. Add .security to the action.auto_create_index values. This is required when Shield is
enabled and auto create is set to false.
# This disables automatic index creation

action.auto_create_index: false,.security
b. Configure the Shield settings as follows:
Note: To disable Shield, remove the number sign (#) in front of shield.enabled:false.
#shield.enabled: false
shield.authc.realms:
custom:
type: kCuraBearerRealm
order: 0
publicJWKsUrl:
https://<RELATIVITY_IDENTITY_SERVER>/Relativity/Identity/.well-known/jwks
esusers1:
type: esusers
order: 1
Note: The URL must point to the Relativity installation where Identity Server can be found.
This should be the same URL used to log in to Relativity.
6. Install the service:
.\kservice.bat install
7. Verify the Java settings:
.\kservice.bat manager
a. On the Java tab, make sure the values for the following settings for each particular node
match the settings you took note of above:
n Initial memory pool
n Maximum memory pool

n Thread stack size
b. Select the the Log On tab. In the Log on as setting, select This account. Enter a valid
Upgrade Guide 195

Relativity service account domain name and password and confirm the password.
8. Restart the service:
.\kservice.bat start
If the service fails to restart, navigate to C:\RelativityDataGrid\elasticsearch-main\logs and

troubleshoot any errors in the logs.
9. Run the following command in Sense to monitor the progress of your node. Wait for the node to go
to YELLOW before upgrading the next node.
GET _cat/health
13.6.2 Verifying the upgrade

After you upgrade all of the nodes on your cluster, complete the following on the cluster to complete the
upgrade:
1. Run the following command in Sense:
GET /_nodes/jvm?filter_path=**.jvm.gc_collectors
Ensure the result shows "ParNew", "ConcurrentMarkSweep".
Upgrade Guide 196

2. Enable shard allocation to rebalance the cluster:
{
"persistent":{"cluster.routing.allocation.enable": "all"}
}
You can monitor the indexes by running the following in Sense:
3. Verify the cluster status by running the following command in Sense.
GET _cat/health
Once the cluster is GREEN, your node restart is complete.

If the cluster status remains RED for an extended period, run the following in Sense to identify which
indexes are RED:
Note: If you are using Kibana, ensure your version of Kibana is compatible with your version of
Elasticsearch.
Note: With Shield on by default, other plugins like Marvel or Head are not supported. In order to use
your other plugins, you need to provide the Kibana server with credentials so it can access the .kibana
index and monitor the cluster. See the Relativity Data Grid guide for more information.
13.7 Resetting the Shield or Head password

When navigating to Head or Sense on any node, you may be prompted for a username and password. If
you are unsure of the password, or if the password is not set, you can use the esusers tool in the shield
folder. This tool can list users, change passwords, and create REST users on the node. The tool is node-
specific, meaning you create a user and password only on that node.
1. Run PowerShell as an administrator, and then navigate to C:\RelativityDataGrid\elasticsearch-

main\bin\shield.
2. Enter the following command to list the users on the node.
.\esusers list
3. If no user exists, create a user using the following command.

.\esusers passwd esadmin -p password123 -r admin
Note: This example creates a new user, esadmin, with the password password123 and the role
of admin. Substitute the user name and password for the user you want to create.
Upgrade Guide 197

4. To change the password on the node, use the following command:

.\esusers passwd esadmin -p newpasswordhere
Upgrade Guide 198

Proprietary Rights
This documentation (“Documentation”) and the software to which it relates (“Software”) belongs to
Relativity ODA LLC and/or Relativity’s third party software vendors. Relativity grants written license
agreements which contain restrictions. All parties accessing the Documentation or Software must: respect
proprietary rights of Relativity and third parties; comply with your organization’s license agreement,
including but not limited to license restrictions on use, copying, modifications, reverse engineering, and
derivative products; and refrain from any misuse or misappropriation of this Documentation or Software in
whole or in part. The Software and Documentation is protected by the Copyright Act of 1976, as
amended, and the Software code is protected by the Illinois Trade Secrets Act. Violations can involve
substantial civil liabilities, exemplary damages, and criminal penalties, including fines and possible
imprisonment.
©2019. Relativity ODA LLC. All rights reserved. Relativity® is a registered trademark of Relativity
ODA LLC.
Upgrade Guide 199

Relativity - Upgrade Guide - 9.6 PDF

Uploaded by

Copyright:

Available Formats

Relativity - Upgrade Guide - 9.6 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Relativity - Upgrade Guide - 9.6 PDF

Uploaded by

Copyright:

Available Formats

Upgrade Guide

May 10, 2019 | Version 9.6.202.10

1.1 Addressing custom solutions pre-upgrade

1.2 Addressing custom scripts that trigger imaging jobs

1.3 Required pre-upgrade steps for all Relativity versions

1.3.1 Obtain credentials for service and database accounts

1.3.2 Review system and other requirements

1.3.3 Apply a trusted certificate for the Analytics server

1.3.4 Back up your Relativity environment

1.3.6 Download the Relativity installer

1.4 8.1, 8.2, or 9.x to 9.6 upgrade workflow

1.5 8.0 to 9.6 upgrade workflow

1.6 7.x to 9.6 upgrade workflow

2.1 9.x to 9.6 Relativity updates

2.2 8.x to 9.6 Relativity updates

n Imaging set manager

2.2.2 Agent service

2.2.3.3 Updating RestUriForCAAT instance setting

2.2.3.4 Analytics index enhancements

2.2.3.5 Email thread visualization

2.2.3.6 Multiple structured analytic set results

2.2.6.1 User and authentication object permissions

2.2.8 Data Grid

2.2.9 Database schema updates

2.2.9.1 Deprecated support for EDDSResource database

2.2.10 ECA and Investigation

2.2.12 File share

2.2.13 Foreign key removal

<urlCompression doDynamicCompression="false" />

This change will improve SignalR performance on older versions of IIS.

For more information, see the Imaging guide.

n Relativity renames the default imaging profile to Native Default.

n Relativity renames the default imaging profile to Basic Default.

2.2.16 Installation of a certificate on the database server

n Import or export certificates and private keys at https://technet.microsoft.com/en-us/lib-

2.2.17 Instance settings

2.2.17.1 Backwards compatibility

n The default value of the ProcessingMaxPublishSubJobCountPerWorkspace setting has

Envir- Pro- Pro-

2.2.19 Network load balancing

2.2.20 New UI framework

Default user Previous email address New email address

2.2.23 Relativity Desktop Client (RDC)

2.2.24 Relativity installer updates

Note: To change the ADMIN_PASSWORD or SERVICEACCOUNT_PASSWORD password, you

2.2.25 Relativity Processing Console

n Invariant SQL Server name with an optional port number

2.2.26 Relativity service bus

2.2.27 Required certificates for Relativity

2.2.30 Service Host Manager HTTPS configuration

2.2.31 System requirements

2.2.33 User and group operations

2.2.34 Viewer (ActiveX)

2.2.36 Windows or Integrated Windows authentication

2.2.37 Windows Service Bus 1.1 with TLS 1.2 Support

2.2.37.2 Upgrading to Service Bus 1.1 with TLS 1.2 Support

C:\Program Files\Service Bus

$mycert=ConvertTo-SecureString -string myPassword -force -AsPlainText

See the following confirmation message: