Upgrade Guide. June 18, 2018 Version For the most recent version of this document, visit our documentation website.

Transcription

1 Upgrade Guide June 18, 2018 Version For the most recent version of this document, visit our documentation website.

2 Table of Contents 1 Relativity upgrade Addressing custom solutions pre-upgrade Addressing custom scripts that trigger imaging jobs Required pre-upgrade steps for all Relativity versions Obtain credentials for service and database accounts Review system and other requirements Apply a trusted certificate for the Analytics server Back up your Relativity environment Reboot machines with Windows updates Download the Relativity installer , 8.2, or 9.x to 9.5 upgrade workflow to 9.5 upgrade workflow x to 9.5 upgrade workflow x to 9.5 upgrade workflow 16 2 Upgrade considerations for Relativity x to 9.5 Relativity updates Agent service 18 Analytics Applications Audit Authentication Conversion 25 Data Grid Database schema updates 26 ECA and Investigation 26 Fields File share 27 Foreign key removal IIS 27 Upgrade Guide 2

3 Imaging Installation of a certificate on the database server Instance settings Processing/Invariant Network load balancing New UI framework 36 Production Relativity admin and service account addresses Relativity Desktop Client (RDC) Relativity installer updates Relativity Processing Console Relativity service bus Required certificates for Relativity Scripts Searching Service Host Manager HTTPS configuration System requirements Telemetry Viewer (ActiveX) Viewer (ActiveX and HTML) Windows or Integrated Windows authentication Windows Service Bus 1.1 with TLS 1.2 Support Workers Worker manager queue Worker manager server Workspace upgrade queue x to 9.5 Relativity updates 47 Agents Agent service 49 Analytics Applications 51 Upgrade Guide 3

4 2.2.3 Audit Authentication Conversion 51 Data Grid Database schema updates 52 ECA and Investigation 52 Fields File share 53 Foreign key removal IIS 54 Imaging Installation of a certificate on the database server Instance settings Processing/Invariant Network load balancing New UI framework 62 Production Relativity admin and service account addresses Relativity Desktop Client (RDC) Relativity installer updates Relativity Processing Console Relativity service bus Required certificates for Relativity Scripts Searching Service Host Manager HTTPS configuration System requirements Telemetry Viewer (ActiveX) Viewer (ActiveX and HTML) Windows or Integrated Windows authentication 69 Upgrade Guide 4

5 Windows Service Bus 1.1 with TLS 1.2 Support Workers Worker manager queue Worker manager server Workspace upgrade queue Conversion 72 Data Grid Database schema 73 Document table trigger removal File share 74 Foreign key removal IIS 74 Imaging Imaging sets Installation of a certificate on the database server Processing/Invariant New UI framework Processing 82 Production Relativity service bus Required certificates for Relativity Scripts Searching 84 Servers Service Host Manager HTTPS configuration 85 Structured Analytics System requirements Telemetry Viewer (ActiveX) Viewer (ActiveX and HTML) Windows or Integrated Windows authentication 87 Upgrade Guide 5

6 Workers Worker manager queue Worker manager server Workspace upgrade queue 88 Viewer Workers Worker manager server 89 Workspace Upgrade Queue 89 Workspaces Windows or Integrated Windows authentication x to 9.5 Relativity updates Agent service 91 Analytics Applications Audit Authentication Conversion 94 Data Grid Database schema updates 95 ECA and Investigation 95 Fields File share 96 Foreign key removal IIS 97 Imaging Installation of a certificate on the database server Instance settings Processing/Invariant Network load balancing New UI framework 104 Production 105 Upgrade Guide 6

7 Relativity admin and service account addresses Relativity Desktop Client (RDC) Relativity installer updates Relativity Processing Console Relativity service bus Required certificates for Relativity Scripts Searching Service Host Manager HTTPS configuration System requirements Telemetry Viewer (ActiveX) Viewer (ActiveX and HTML) Windows or Integrated Windows authentication Windows Service Bus 1.1 with TLS 1.2 Support Workers Worker manager queue Worker manager server Workspace upgrade queue Conversion Database schema 115 dtsearch index considerations File share 116 Foreign key removal 116 Imaging Installation of a certificate on the database server IIS 118 Processing/Invariant 119 License Relativity and Processing New UI framework 124 Production 125 Upgrade Guide 7

8 RAR upgrade notes Relativity service bus Required certificates for Relativity 126 Viewer Searching Scripts System requirements Viewer (ActiveX) Configure the viewer drawing delay 127 Upgrade custom applications or code Windows or Integrated Windows authentication Workers Worker manager server x to 9.5 Relativity updates Agent service Analytics Applications Audit Authentication Conversion 133 Data Grid Database schema updates Document Table Trigger removal considerations dtsearch index considerations 134 ECA and Investigation 135 Fields File share 135 Foreign key removal IIS 136 Imaging Installation of a certificate on the database server 139 Upgrade Guide 8

9 Instance settings License Relativity Processing/Invariant Network load balancing New UI framework 143 Production Pre-installation steps for web servers Relativity admin and service account addresses Relativity Desktop Client (RDC) Relativity installer updates Relativity Processing Console Relativity service bus Required certificates for Relativity Scripts Searching Service Host Manager HTTPS configuration System requirements Telemetry Upgrade agents and other components Viewer Viewer (ActiveX) Viewer (ActiveX and HTML) Windows or Integrated Windows authentication Windows Service Bus 1.1 with TLS 1.2 Support Workers Worker manager queue Worker manager server Workspace upgrade queue Configuring your conversion agents Conversion agent considerations Re-purposing a conversion worker as a conversion agent 156 Upgrade Guide 9

10 3.3 Adding conversion agents to an environment with no dedicated conversion workers Adding a conversion agent to an existing server Allocate additional hardware to host a new agent server Upgrading your SQL Server Primary SQL Server upgrade Distributed SQL Server upgrade Removing RabbitMQ Deleting Data Grid agents Deleting empty processing queues Uninstalling RabbitMQ Server and Erlang OTP Closing ports on the Queue Server Upgrading your Relativity service bus Relativity service bus upgrade Setting properties in the RelativityResponse.txt file Feature selection Common properties Verifying database table updates for multiple hosts Troubleshooting the service bus installation Upgrading your agent server Agent server upgrade Service Host Manager HTTPS configuration Upgrading your web server Web server upgrade Verifying the machine key settings on the IIS Upgrading a web server configured for mixed authentication with AD Service Host Manager HTTPS configuration SignalR Upgrading Relativity to.net All servers Client machines Relativity applications 183 Upgrade Guide 10

11 9.3.1 Backward-compatible applications Custom applications built with the Relativity SDK Development environment Upgrading a worker manager server installation Upgrade considerations for Relativity Hosting Invariant Kepler services in HTTPS Upgrade considerations for Relativity Upgrade considerations for Relativity Upgrade exceptions Installing Microsoft Visual C++ Redistributable Packages Upgrading the Invariant Database and Queue Manager Upgrading workspaces Monitoring upgrades with the Workspace Upgrade queue Populating the Workspace Upgrade queue Workspace Upgrade queue columns Upgrade statuses descriptions Editing upgrade priority and order for a workspace Troubleshooting upgrades Viewing upgrade errors Canceling or retrying workspace upgrades Upgrading or installing your Analytics server Installing / Upgrading Relativity Analytics Installing Analytics for the first time to Relativity and above Installing Analytics for the first time to Relativity or prior Upgrading from Relativity (CAAT 3.19) and above Upgrading from Relativity (CAAT 3.17) or prior Updating the default SSL/TLS certificate Overview of how to update the SSL / TLS certificate ) Deleting the default, unsigned certificate ) Creating a self-signed certificate (no trusted certificate) - optional step ) Importing a certificate (trusted or self-signed) 221 Upgrade Guide 11

12 ) Verifying the Analytics server in Relativity Disabling TLS 1.0 and 1.1 (optional) Installing Analytics server when SQL Server uses SSL encryption Install a SQL Server certificate in the Analytics server KeyStore Use the CN property of a SQL Server certificate in Relativity Changing the REST password Uninstalling the Relativity Analytics server Upgrading Data Grid Finding the Elasticsearch version Upgrading from Elasticsearch to x Preparing the environment for upgrade Running the upgrade script Verifying the upgrade Running a manual upgrade Upgrading a node Verifying the upgrade Resetting the Shield or Head password 236 Upgrade Guide 12

13 1 Relativity upgrade Use the following workflows to upgrade your current Relativity installation to Relativity 9.5. 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.5 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. The Imaging Set Manager and Worker agents have been deprecated. The Imaging Set Queue table has been deprecated. The Imaging API now submits an imaging job directly to Invariant (worker manager server). Before you upgrade to Relativity 9.5, 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 13

14 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 Obtain credentials for service and database accounts To upgrade Relativity, you need credentials for the following accounts: 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. 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 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: Relativity System Requirements - Includes software and hardware requirements for servers, databases, and other components of a Relativity installation. Relativity Workstation Configuration guide - Includes information about setting up workstations for users and viewer installation instructions. Relativity Environment optimization guide - Includes best practices for maintaining and optimizing a Relativity environment. Upgrade path instructions - Contain detailed information about requirements for your specific upgrade path Apply a trusted certificate for the Analytics server As of Relativity 9.5, 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.5. See Pre-upgrade: Update the default SSL/TLS certificate for CAAT for more information 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 14

15 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 Download the Relativity installer To receive the correct Relativity installer package for your upgrade workflow contact the Client Services team , 8.2, or 9.x to 9.5 upgrade workflow Use the following workflow when upgrading from Relativity 8.1 or 8.2 to Relativity 9.5. 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 , 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 166. Note: Before you upgrade, verify that you meet all requirements outlined in the Pre-installation guide. 1. Stop all agent services. 2. Stop the IIS. 3. 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 Run the Relativity installer on all distributed SQL servers if present. See Distributed SQL Server upgrade on page 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 168 Note: You can find additional information in Troubleshooting the service bus installation on page 171. For general troubleshooting information, see the Relativity Service Bus guide. 6. Run the Relativity installer on the Agent server. See Upgrading your agent server on page Run the Relativity installer on the Web server. See Upgrading your web server on page Restart the IIS. 9. (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 190. Upgrade Guide 15

16 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. 10. 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.5, you must upgrade any worker servers after upgrading your worker manager server. 11. Upgrade Relativity Analytics. See Upgrading or installing your Analytics server on page to 9.5 upgrade workflow Please contact the Client Services team for more information on upgrading your 8.0 Relativity environment to Relativity x to 9.5 upgrade workflow Please contact the Client Services team for more information on upgrading your 7.x Relativity environment to Relativity x to 9.5 upgrade workflow Please contact the Client Services team for more information on upgrading your 6.x Relativity environment to Relativity 9.5. Upgrade Guide 16

17 2 Upgrade considerations for Relativity 9.5 This page explains some of the key changes in Relativity 9.5 that you should be aware of before upgrading. In order to upgrade to or install Relativity 9.5, 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.For more information, see the Pre-Installation guide. Refer to this page to learn more about changes in your environment from a previous version of Relativity to Relativity x to 9.5 Relativity updates Learn more about the changes that occur to your Relativity 9.x environment after you upgrade to Relativity x to 9.5 Relativity updates Agent service Analytics on the next page Applications on page 21 Audit on page 21 Authentication on page 24 Conversion Data Grid on page 25 Database schema ECA and Investigation Fields on page 27 File share Foreign key removal on page 27 IIS on page 27 Imaging on page 29 Instance settings on page 31 Installation of a certificate on the database server on page 31 Processing/Invariant Network load balancing on page 36 New UI framework on page 36 Production on page 37 Relativity admin and service account addresses on page 38 Upgrade Guide 17

18 Relativity Desktop Client (RDC) on page 39 Relativity installer updates on page 39 Relativity service bus on page 40 Required certificates for Relativity on page 41 Scripts Searching on page 41 Service Host Manager HTTPS configuration on page 41 System requirements on page 41 Telemetry Viewer (ActiveX) on page 42 Viewer (ActiveX and HTML) on page 42 Windows or Integrated Windows authentication on page 43 Windows Service Bus 1.1 with TLS 1.2 Support on page 44 Workers Worker manager queue on page 46 Worker manager server Workspace upgrade queue on page 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. Analytics If you're upgrading to Relativity 9.5 from a version earlier than 9.2, note that the Textual Near Duplicate Identification algorithm is in place with the following benefits: The new algorithm greatly improved performance for both large and complex data sets. 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.2, scaling environments did not impact performance. Without scaling past eight cores, you should experience performance comparable to pre-relativity 9.2 on most data sets. The Textual Near Duplicate Identification algorithm in Relativity 9.2 uses different, more efficient methods to obtain similar results. However, results may differ slightly from pre-relativity 9.2 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-relativity 9.2 results for all preexisting documents, but the newly added documents use the new algorithm to match with existing groups. Upgrade Guide 18

19 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 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., New Analytics installer Starting with Relativity , 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 (CAAT 3.17) or lower, first run the Relativity or 9.4 Analytics server installer using the instructions at Running the Relativity Analytics installer for versions previous to Relativity Contact Support for this installer. After this step, then run the Relativity 9.5 response file-based installer Analytics index enhancements Starting with Relativity , Analytics indexes are now RDO's. There are a few considerations with this update: You will no longer get shell indexes when importing an application that contains saved searches with Analytics search index conditions. Instead, the saved search will have the analytics condition stripped from it. A new index can be created, and a new condition can be manually associated with the saved search. Indexes will no longer have the default saved searches available to set as the training and searchable 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) After the upgrade, you will no longer have the option to preserve cluster multiple choice and coherence score fields when deleting the cluster set. They will always be deleted. OCR and Go Word filter support has been deprecated from Analytics Indexes. On subsequent populations 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). When you upgrade, the Analytics Core install event handlers will create a new RDO for each existing index and a new RDO for each existing cluster set. These new object types and instances inherits permissions from their analogous source objects. For example: o Analytics Index RDO workspace permissions are copied from Search Index workspace permissions o Analytics Index RDO instance permissions are copied from Search Index instance permissions Upgrade Guide 19

20 o o Cluster Set RDO workspace permissions are copied from Search Index workspace permissions Cluster Set RDO instance permissions are copied from the multiple choice cluster field's item level permissions thread visualization Users must have the Analytics application installed in the workspace, and the Author Date ID must be present for the s. The Author Date ID is only available for s run through a full analysis using structured analytics in Relativity and above. The thread visualization pane will not work for threads from previous versions unless a full analysis is run against the structured analytics set containing the s after upgrading to Relativity or higher Multiple structured analytic set results Beginning in Relativity , you can easily store the results for multiple structured analytics sets and set up views that capture the threading or repeated content identification results of those operations. Consider the following: We recommend you set new relational fields (e.g., Destination Thread Group, Destination Duplicate ID, and Destination Textual Near Duplicate Group) when creating new structured analytics sets for 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. Upon upgrade, the thread group, duplicate spare group, and textual near duplicate group relational views display just the Control Number and Edit columns. To display the old fields, you must unlock the application and update those views. If you run Structured Analytics with the existing application relational fields, the relational views will only show the Control Number and Edit columns. A way to avoid this is by creating and mapping your own relational fields before run time. Then, you can create your own relational view and map that to the custom relational fields. Note: This upgrade consideration has been addressed in Relativity If you are upgrading to Relativity , disregard this item. Upon upgrade, 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 reference these newly created fields don't carry over on workspace creation because Structured Analytics Sets don't carry over. Note: This upgrade consideration impacts any Relativity templates that reference the legacy Structured Analytics results fields. Upon upgrade, previous inclusive information may change when performing an incremental analysis on an existing threading set due to the newly created structured Analytics results fields. Upgrade Guide 20

21 2.1.2 Applications 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 Audit Upon upgrade to Relativity , 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. Relativity includes a change to the Audit template. Before upgrading to Relativity , complete the following: 1. Take note of any customized settings in your current Audit template found in the ESIndexCreationSettings instance setting. 2. Edit the ESIndexCreationSettings instance setting and replace using the following template. Incorporate any of your customized settings in this template. Click to expand { "template": "audit_*", "aliases": { "{index}_read": { }, "{index}_write": { }, "{index}_verify": { } }, "settings": { "index": { "number_of_shards": 4, "number_of_replicas": 2 }, "analysis": { "analyzer": { "str_search_analyzer": { "tokenizer": "keyword", "filter": ["lowercase", "substring"] }, "str_index_analyzer": { "tokenizer": "keyword", "filter": ["lowercase", "substring"] }, "lwhitespace": { "tokenizer": "whitespace", "filter": ["lowercase"] } }, Upgrade Guide 21

22 "filter": { "substring": { "type": "ngram", "min_gram": 1, "max_gram": 20 } } } }, "mappings": { "audit": { "dynamic_templates": [{ "raw": { "match_pattern": "regex", "path_match": "Details\\.auditElement\\..*", "mapping": { "type": "string", "fields": { "Raw": { "analyzer": "lwhitespace", "type": "string" } } }, "match_mapping_type": "string" } }, { "newvalue": { "match_pattern": "regex", "path_match": ".*\\.newvalue$", "mapping": { "type": "string", "fields": { "Raw": { "analyzer": "lwhitespace", "type": "string" } } } } }, { "oldvalue": { "match_pattern": "regex", "path_match": ".*\\.oldvalue$", "mapping": { "type": "string", "fields": { "Raw": { "analyzer": "lwhitespace", "type": "string" } } } } }, { "analytics_text": { Upgrade Guide 22

23 } } } "match_pattern": "regex", "path_match": ".*\\.#text$", "mapping": { "type": "string", "fields": { "Raw": { "analyzer": "lwhitespace", "type": "string" } } } } }], "_timestamp": { "enabled": true }, "_size": { "enabled": true }, "properties": { "ActionName": { "type": "string", "index": "not_analyzed" }, "UserName": { "type": "string", "index": "not_analyzed" }, "TimeStamp": { "format": "strict_date_optional_time epoch_millis", "type": "date" }, "Details.auditElement.field.@id": { "type": "keyword" } } 3. Delete the template found in the Elasticsearch cluster using the following command: DELETE _template/audit You can also delete the template from Head: Upgrade Guide 23

24 When audit migration continues, the template in Elasticsearch is automatically updated to match the template in the instance setting Authentication Consider the following for upgrading: 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 permits more versatile and detailed method implementations. 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 version being ungraded from, such as 9_2_AuthenticationUserTableBackupRecord or 9_3_AuthenticationUserTableBackupRecord. If after upgrading and making sure all users converted successfully, you may delete the copy table. Upgrade Guide 24

25 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 parsing 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 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.5, permissions are as follows: 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. 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. After upgrade only users in the System Administrators group will have access to view and edit OAuth2Client objects 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.5. Your agent servers should also have one conversion complete agent. For more information, see Configuring your conversion agents Complete Conversion Agent Writes to cache documents converted by the Conversion Agent and notifies the Relativity front end when conversion jobs are ready. This agent is created after a new Relativity installation. Upon upgrade, you must created the agent manually. We do not recommend putting this agent on the Conversion Agent server, as that server should be dedicated to the Conversion Agent, not the Conversion Complete Agent. This agent was released in Relativity and is required where DVS is installed. See. Data Grid If your environment uses Data Grid, you must also upgrade to Data Grid or above when upgrading to Relativity 9.5. For more information, see Upgrading Data Grid. 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. You no longer need to install the DataGridRESTService on the Analytics server to integrate Relativity Analytics with Relativity Data Grid. If you are upgrading to Relativity 9.5, uninstall the DataGridRESTService from your Analytics server(s). For more information, see Uninstalling the Upgrade Guide 25

26 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. 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 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.5 in the Relativity Community 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. ECA and Investigation The ECA and Investigation and Field Catalog applications are now synchronized, which means that when you install the ECA and Investigation application, Relativity automatically maps all of the ECA fields to those 127 corresponding processing fields found in the Field Catalog. For a list of these fields, see the Processing User Guide. Note the following details: A number of processing fields were renamed in the Field Catalog. Renamed fields will cause naming 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. 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 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. Upgrade Guide 26

27 Fields 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 File share Beginning in Relativity , 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. 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: Keys from the object (Document or RDO) table to the Artifact table. Keys on the object table that go to a single object field. Keys on multi-object relational f-tables. An f-table stores the link between the objects that are connected 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 IIS 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 27

28 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 28

29 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. Imaging Beginning in Relativity , the following changes have been made to imaging and should be noted prior to upgrade: The Imaging Response Agent is required to run any imaging job in your environment. This agent is responsible for properly picking up imagine set, mass imaging and image-on-the-fly messages from Service Bus (as published by the workers) and directing them to the proper finalization logic in Relativity. For initial installations of Relativity , an Imaging Response Agent is automatically installed and enabled in your environment. If you're upgrading to Relativity or if at any point you need to install an additional agent, you need to do so manually. For details, see the Imaging guide. The following imaging-related instance settings changes were made: Instance setting Description Change DocumentLimitForMassImaging The maximum number of documents that can be submitted for the Mass Imaging action. If a user attempts to mass image and the number of documents selected exceeds this value, a warning appears to prevent the user from performing this action to suggest creating an Imaging Set as best practice. Added ImagingBatchSize MaxImagingResponseThreads ImagingCompleteMaxThreads Determines the maximum number of documents to submit for imaging at a time. The maximum number of threads for each Imaging Response Agent. If this is 0 or less, defaults to Agent server processor count * 2. Our recommendation is 1 Imaging Response Agent thread per 8 Imaging Worker threads at a minimum. This was removed in accordance with the addition of the MaxImagingResponseThreads instance setting. Added Added Removed Beginning in Relativity , 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 , an Imaging Request Agent is automatically installed and enabled in your environment. If you're upgrading to Relativity or if at any point you need to install an additional agent, you need to do so manually. Upgrade Guide 29

30 For more information, see the Imaging guide. Existing imaging profiles received the following updates based on their imaging method when upgrading to Relativity 9.5: If your environment is set up for native imaging, the following changes occur upon upgrade: Relativity renames the default imaging profile to Native Default. The imaging method is set to Native for all current imaging profiles including Native Default. Relativity creates a new basic default imaging profile with the following settings: o Imaging Method: Basic o Basic Image Output Quality (DPI): 300 o o Basic Image Format: TIFF Basic Image Height: Original Setting 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.5: Upgrade Guide 30

31 Relativity renames the default imaging profile to Basic Default. The imaging method is set to basic for all current imaging profiles including Basic Default 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.5 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.5 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: Import or export certificates and private keys at Optionally configure an authentication token-signing certificate on the Pre-installation page in the Relativity 9.5 Documentation site - These instructions describe the process for configuring your own custom token-signing certificate, but you can follow these basic steps to install RelativityIdentityCertificate to each database server in a distributed environment Instance settings If upgrading to Relativity 9.5 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. Note: If a new 9.5 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 Backwards compatibility For any existing applications that reference the pre-9.5 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 Processing/Invariant To improve performance of worker processes, beginning in Relativity , the default value of the LongRunningJobTimeout entry in the AppSettings table is now 180,000 milliseconds (30 minutes). Beginning in Relativity , ICS/VCF files are deduplicated not as s but as loose files based on the SHA256 hash. Since the system now considers these loose files, Relativity is no longer capturing the -specific metadata that it used to get as a result of ICS/VCF files going through the system's Upgrade Guide 31

32 handler. For a detailed list of all the metadata values populated for ICS and VCF files, see the Processing user guide. Beginning in Relativity , the database installation component has been removed from the Invariant installer. Accordingly, note the following considerations: 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. The queue manager installation is now responsible for creating the database. The queue manager now communicates with the database upgrader to update all databases during an Invariant upgrade. 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. The database component no longer holds registry entries; all registry entries that aren't duplicates are now on the queue manager machine. If you previously installed the Invariant database component on its own machine, it's highly recommended that you uninstall the database before upgrading to Relativity If you uninstall the database after upgrading, you'll delete all Invariant files from the Invariant network share. There is a new installation log file called UninstallLegacyDatabasePackage.log, which appears only once after an upgrade to Relativity For more information, see Installing the worker manager server. Beginning in Relativity , the following infrastructure changes have been made to processing and should be noted prior to upgrade: ProcessingMaxPublishSubJobCountPerSQLServer - the new default value of this instance setting is 7. For information on configuring this setting, see the Processing User Guide. ProcessingMaxPublishSubJobCountPerWorkspace - the new default value of this instance setting is 3. For information on configuring this setting, see the Processing User Guide. 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. 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. 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. Beginning in Relativity , the following changes have been made to processing and should be noted prior to upgrade: You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue manager. Note that the default port for the Invariant Kepler services is For details, see Enabling HTTPS for Invariant Kepler Services. Upgrade Guide 32

33 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-installation Guide in the Pre-installation topic. Invariant stores are now deleted automatically when the Relativity workspaces associated with them are deleted. For more information, see The Relativity Processing Console Guide. 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 allowing 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 moving on. Note the upgrade-relevant details regarding distributed publish: o The following instance settings have been added to facilitate the work of distributed publish. ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number of publish jobs per Relativity SQL server that may be worked on in parallel. 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. 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. This updates on a 30-second interval. 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. ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish jobs per workspace that may be worked on in parallel. 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 higher than the value for the MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity 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. The default value is 3. 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. This updates on a 30-second interval. Upgrade Guide 33

34 o 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. The ProcessingExportMaxThreads instance setting has been deprecated in accordance with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and ProcessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate the work of distributed publish. The following table provides the recommended values for each instance setting per environment setup: Environment setup Tier 1 (see the System Requirements Guide for details) Tier 2 (see the System Requirements Guide for details) RelativityOne baseline ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Beginning in Relativity , the following Invariant installation components are new: 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. 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 Upgrade Guide 34

35 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 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 and should be noted prior to upgrading: 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 network share that doesn t contain any data. 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 Invariant.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. 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 (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: The MaxConversionThreads column has been removed from the Invariant.dbo.Workstations table, as it was longer in use since conversion became a separate service. 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. The following changes were made to the Invariant installation process: 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. 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. Upgrade Guide 35

36 The following processing changes may impact your upgrade experience: 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. 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 o o The processing profile no longer contains the Processing Fields associative object list view. 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. 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 profiles do have fields mapped, Relativity doesn't automatically transfer fields when you upgrade to 9.5. 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 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. 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. 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 Network load balancing If you are using cookie-persisted load balancing configurations for Relativity and higher, you must update the WebClientRequiredCookies instance setting to include the name of the load balancer cookie for the ActiveX viewer New UI framework If you need to disable the new UI framework for the Document list, click Switch to Classic UI from the user drop-down within a workspace. For help using the classic interface, refer to the 9.3 documentation which documents both interfaces side-by-side. For more information, see Navigation in the Admin guide. When using the new UI framework, the following Relativity features have been enhanced: Upgrade Guide 36

37 Cluster visualization Dashboards Document list and tabs throughout Relativity Pivot Sampling Search panel and search browser Production The following section discusses the changes to the Production application on upgrade from Relativity 9.x to Relativity Certain upgrade changes only affect upgrades from Relativity 9.1 or 9.2 to Relativity 9.5, 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: An upgrade from Relativity 9.x to 9.5 can fail if the workspace you're upgrading already contains a Relativity field with the name Production. You must rename this field. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Placeholder. You must rename this object. An upgrade from Relativity 9.1 to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Data Source. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Relativity Color Map. You must rename this object. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Field Catalog. You must rename this object. If you have a full-text index populating the production upgrade stops. Try upgrading again once the full-text index is finished populating. Relativity deduces the First Bates Value and Last Bates Value for all imported and upgraded productions. If you upgrade from Relativity 9.2 to Relativity 9.5 and you were previously using the Production Tracker application, review the Production Tracker 9.5 considerations PDF in the Relativity Community. Beginning in , Productions includes an upgrade step to migrate data from the old ProductionInformation schema to the new schema introduced in Changes to agents and objects: 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.5 environment. Upgrade Guide 37

38 The Markup Set table is converted to the Markup Set dynamic object. The Production Object table is converted to the Production dynamic object. Changes to pre-existing Productions: Any staged or errored productions in an environment are set to a status of New and you must restage the production before running. Productions migrated from Relativity 9.1 and 9.2 receive a legacy placeholder stating, "No Tiff Included For This Record." Productions migrated from Relativity 9.1 to Relativity 9.5 have a data source created containing the production documents for each produced and errored production. 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. The Production Error field no longer exists on the Production object. 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 production. Changes to Production fields and views: On upgrade from 9.2 the Produced Documents field exists in the environment, but the field is not populated. The production document view no longer exists. 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. On upgrade from 9.x to 9.5 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: Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not automatically 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 Production Data Source object to add or edit production data sources after upgrading to Relativity Relativity admin and service account addresses Relativity includes the Relativity admin and service account users by default. With the Relativity , the default addresses for these accounts have been updated as follows: Upgrade Guide 38

39 Default user Previous address New address Relativity admin Relativity service account Relativity Desktop Client (RDC) Beginning in Relativity , 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 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 with Relativity versions to but you must create a new RDC OAuth2 client to do so. For more information, see the Desktop Client Guide Relativity installer updates For Relativity 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: addresses for the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_ and SERVICEACCOUNT_ parameters that you can set with these 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 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 address during a previous installation, it is overwritten by current address that you entered or by the default address when this parameter is blank. o Use different addresses for the ADMIN_ and SERVICEACCOUNT_ parameters. If you use the same address for both parameters, the installation fails. Passwords for the the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_PASSWORD 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 address. If you enter a new password but don t update the address, then new password is ignored. For example, if you use an existing or default address, then the password remains unchanged. However, you can change the addresses for the admin and service accounts without updating the password. For more information, see the Relativity Installation and Relativity Upgrade guides. Upgrade Guide 39

40 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: Invariant SQL Server name with an optional port number Relativity SQL Server name with an optional port number EDDSDBO password 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 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. Upgrade Guide 40

41 Required certificates for Relativity Relativity 9.5 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.3. For more information, see Pre-upgrade: Update the default SSL/TLS certificate for CAAT in the Upgrading or installing your Analytics server section Scripts 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. Beginning in , 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 Searching Upon upgrade to , 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 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.5 Documentation site System requirements Windows Server 2008 R2 (64-bit) is no longer compatible with 9.5. Relativity 9.5 is only compatible with Windows Server 2008 R2 (64-bit) w Service Pack 1. As of August 31, 2017, we no longer support Internet Explore (IE) 10. Please upgrade to a compatible version of IE Telemetry After you install Relativity 9.5, complete the steps to enable telemetry in your environment. Telemetry allows you to collect metrics for performance, usage, and billing. For more information, see Telemetry on the Relativity 9.5 Documentation site. Upgrade Guide 41

42 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 Viewer (ActiveX) Beginning in Relativity , you must install Microsoft.NET 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 redistributable, from the Workspace Details tab. You can't use the Relativity viewer with earlier versions of Relativity. Also, earlier versions of the ActiveX viewer aren't compatible with Relativity 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 Viewer (ActiveX and HTML) Beginning in 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 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. You can 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. See the Instance Setting Guide to learn more about this new value. Pre the Relativity September 30, 2015 product update: Upgrade Guide 42

43 As of the Relativity September 30, 2015 product update: 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.5 Documentation site. Upgrade Guide 43

44 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 9.5 Documentation site 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 ( Prerequisites for Service Bus 1.1 with TLS 1.2 Support Verify that.net is installed in your environment. You must install.net before you begin upgrading to Service Bus 1.1 with TLS 1.2. This service bus upgrade requires.net For more information, see Upgrading Relativity to.net Verify that you are running Windows Server 2012 or Windows Server 2012 R2, and Microsoft SQL Server If your environment, doesn't meet these requirements, see Workarounds for Service Bus 1.1 with TLS 1.2 on the next page 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: 1. Remove all servers from the farm. For more information, see Leaving a Farm ( microsoft.com/en-us/library/dn 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 ( on the Microsoft site. 3. Uninstall Microsoft Azure Surface Fabric Upgrade the SQL Server to support TLS 1.2. For more information, see 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. Upgrade Guide 44

45 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 Catalog=SbManagementDB;Integrated Security=True' -CertificateAutoGenerationKey $mycert See the following confirmation message: 8. Rejoin all servers to the farm. For more information, see the Pre-installation Guide 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 2012 or Windows Server 2012 R2, and Microsoft SQL Server 2012 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: Windows Server 2012 and SQL Server 2012 Windows Server 2012 R2 and SQL Server 2016 Windows Server 2016 and SQL Server 2014 Windows Server 2016 and SQL Server 2016 While we aren't aware of any issues on these platforms, we request that you are cautious when deploying the Service Bus 1.1 with TLS 1.2 Support update. 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: Client communication - determines which TLS protocols are used for outbound connections from the server that is traffic to the service bus server. 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 Upgrade Guide 45

46 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 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 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. 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 Worker manager queue Revisions in the queue manager code have led to the following enhancements: A reduction in the volume of connections to the SQL Server A reduction in lock waits and thread pool waits A general increase in queue parallelism 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. Upgrade Guide 46

47 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 156. The Worker manager page no longer displays the following conversion fields: pre-convert, conversion onthe-fly, mass conversion, and conversion. Beginning in Relativity , 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 Workspace upgrade queue The Workspace Upgrade Queue includes the following columns: Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Workspace Upgrade Worker agent. The possible values in this column are the same as for the workspace upgrade. This field is empty if you don't have Processing installed. Current Store Version - the version of Invariant you are upgrading to x to 9.5 Relativity updates Learn more about the changes to your Relativity 8.x environment after you upgrade to Relativity x to 9.5 Relativity updates Agents on the next page Agent service Analytics on page 49 Applications on page 51 Audit on page 51 Authentication on page 24 Conversion Data Grid on page 73 Database schema Document table trigger removal on page 73 File share on page 74 Foreign key removal on page 74 IIS on page 74 Imaging on page 75 Imaging sets on page 77 Installation of a certificate on the database server on page 77 Upgrade Guide 47

48 Processing/Invariant Network load balancing on page 62 New UI framework on page 82 Upgrade considerations for Relativity 9.5 on page 17 Production on page 83 Relativity admin and service account addresses on page 64 Relativity Desktop Client (RDC) on page 64 Relativity installer updates on page 64 Relativity service bus on page 84 Required certificates for Relativity on page 84 Scripts Searching on page 84 Servers on page 85 Service Host Manager HTTPS configuration on page 85 Structured Analytics on page 85 System requirements on page 85 Telemetry on page 85 Viewer on page 88 Upgrade considerations for Relativity 9.5 on page 17 Windows or Integrated Windows authentication on page 89 Windows Service Bus 1.1 with TLS 1.2 Support on page 69 Workers Worker manager server Workspaces on page 89 Workspace Upgrade Queue on page 89 Agents With the introduction of the new viewer, the following agents have been removed in Relativity 9.5: Imaging set manager Imaging worker 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. Upgrade Guide 48

49 2.2.1 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. Analytics New Analytics installer Starting with Relativity , 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 (CAAT 3.17) or lower, first run the Relativity or 9.4 Analytics server installer using the instructions at Running the Relativity Analytics installer for versions previous to Relativity Contact Support for this installer. After this step, then run the Relativity 9.5 response file-based installer. 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 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., Analytics index enhancements Starting with Relativity , Analytics indexes are now RDO's. There are a few considerations with this update: Indexes will no longer have the default saved searches available to set as the training and searchable 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) After the upgrade, you will no longer have the option to preserve cluster multiple choice and coherence score fields when deleting the cluster set. They will always be deleted. OCR and Go Word filter support has been deprecated from Analytics Indexes. On subsequent populations 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). When you upgrade, the Analytics Core install event handlers will create a new RDO for each existing index and a new RDO for each existing cluster set. These new object types and instances inherits permissions from their analogous source objects. For example: o Analytics Index RDO workspace permissions are copied from Search Index workspace permissions Upgrade Guide 49

50 o o o Analytics Index RDO instance permissions are copied from Search Index instance permissions Cluster Set RDO workspace permissions are copied from Search Index workspace permissions Cluster Set RDO instance permissions are copied from the multiple choice cluster field's item level permissions thread visualization Users must have the Analytics application installed in the workspace, and the Author Date ID must be present for the s. The Author Date ID is only available for s run through a full analysis using structured analytics in Relativity and above. The thread visualization pane will not work for threads from previous versions unless a full analysis is run against the structured analytics set containing the s after upgrading to Relativity or higher Multiple structured analytic set results Beginning in Relativity , you can easily store the results for multiple structured analytics sets and set up views that capture the threading or repeated content identification results of those operations. Consider the following: We recommend you set new relational fields (e.g., Destination Thread Group, Destination Duplicate ID, and Destination Textual Near Duplicate Group) when creating new structured analytics sets for 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. Upon upgrade, the thread group, duplicate spare group, and textual near duplicate group relational views display just the Control Number and Edit columns. To display the old fields, you must unlock the application and update those views. If you run Structured Analytics with the existing application relational fields, the relational views will only show the Control Number and Edit columns. A way to avoid this is by creating and mapping your own relational fields before run time. Then, you can create your own relational view and map that to the custom relational fields. Note: This upgrade consideration has been addressed in Relativity If you are upgrading to Relativity , disregard this item. Upon upgrade, 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 reference these newly created fields don't carry over on workspace creation because Structured Analytics Sets don't carry over. Note: This upgrade consideration impacts any Relativity templates that reference the legacy Structured Analytics results fields. Upon upgrade, previous inclusive information may change when performing an incremental analysis on an existing threading set due to the newly created structured Analytics results fields. Upgrade Guide 50

51 2.2.2 Applications 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 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 Authentication Consider the following for upgrading: 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 permits more versatile and detailed method implementations. 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 version being ungraded from, such as 9_2_AuthenticationUserTableBackupRecord or 9_3_AuthenticationUserTableBackupRecord. If after upgrading and making sure all users converted successfully, you may delete the copy table. 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 parsing 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 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.5, permissions are as follows: 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. 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. After upgrade only users in the System Administrators group will have access to view and edit OAuth2Client objects 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.5. Your agent servers Upgrade Guide 51

52 should also have one conversion complete agent. For more information, see Configuring your conversion agents. Data Grid If your environment uses Data Grid, you must also upgrade to Data Grid or above when upgrading to Relativity 9.5. For more information, see Upgrading Data Grid. 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. You no longer need to install the DataGridRESTService on the Analytics server to integrate Relativity Analytics with Relativity Data Grid. If you are upgrading to Relativity 9.5, 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. 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 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.5 in the Relativity Community 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. ECA and Investigation The ECA and Investigation and Field Catalog applications are now synchronized, which means that when you install the ECA and Investigation application, Relativity automatically maps all of the ECA fields to Upgrade Guide 52

53 those 127 corresponding processing fields found in the Field Catalog. For a list of these fields, see the Processing User Guide. Note the following details: A number of processing fields were renamed in the Field Catalog. Renamed fields will cause naming 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. 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 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. Fields 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 File share Beginning in Relativity , 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. 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: Keys from the object (Document or RDO) table to the Artifact table. Keys on the object table that go to a single object field. Keys on multi-object relational f-tables. An f-table stores the link between the objects that are connected 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. Upgrade Guide 53

54 2.2.8 IIS 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 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 54

55 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. Imaging Beginning in Relativity , 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 , an Imaging Request Agent is automatically installed and enabled in your environment. If you're upgrading to Relativity or if at any point you need to install an additional agent, you need to do so manually. Upgrade Guide 55

56 For more information, see the Imaging guide. Existing imaging profiles received the following updates based on their imaging method when upgrading to Relativity 9.5: If your environment is set up for native imaging, the following changes occur upon upgrade: Relativity renames the default imaging profile to Native Default. The imaging method is set to Native for all current imaging profiles including Native Default. Relativity creates a new basic default imaging profile with the following settings: o Imaging Method: Basic o Basic Image Output Quality (DPI): 300 o o Basic Image Format: TIFF Basic Image Height: Original Setting 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.5: Upgrade Guide 56

57 Relativity renames the default imaging profile to Basic Default. The imaging method is set to basic for all current imaging profiles including Basic Default 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.5 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.5 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: Import or export certificates and private keys at Optionally configure an authentication token-signing certificate on the Pre-installation page in the Relativity 9.5 Documentation site - These instructions describe the process for configuring your own custom token-signing certificate, but you can follow these basic steps to install RelativityIdentityCertificate to each database server in a distributed environment Instance settings If upgrading to Relativity 9.5 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. Note: If a new 9.5 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 Backwards compatibility For any existing applications that reference the pre-9.5 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 Processing/Invariant Beginning in Relativity , the database installation component has been removed from the Invariant installer. Accordingly, note the following considerations: 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. The queue manager installation is now responsible for creating the database. Upgrade Guide 57

58 The queue manager now communicates with the database upgrader to update all databases during an Invariant upgrade. 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. The database component no longer holds registry entries; all registry entries that aren't duplicates are now on the queue manager machine. If you previously installed the Invariant database component on its own machine, it's highly recommended that you uninstall the database before upgrading to Relativity If you uninstall the database after upgrading, you'll delete all Invariant files from the Invariant network share. There is a new installation log file called UninstallLegacyDatabasePackage.log, which appears only once after an upgrade to Relativity Beginning in Relativity , the following changes have been made to processing and should be noted prior to upgrade: You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue manager. Note that the default port for the Invariant Kepler services is For details, see Enabling HTTPS for Invariant Kepler Services. 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-installation Guide in the Pre-installation topic. Invariant stores are now deleted automatically when the Relativity workspaces associated with them are deleted. For more information, see The Relativity Processing Console Guide. 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 allowing 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 moving on. Note the upgrade-relevant details regarding distributed publish: o The following instance settings have been added to facilitate the work of distributed publish. ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number of publish jobs per Relativity SQL server that may be worked on in parallel. 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. 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. This updates on a 30-second interval. Upgrade Guide 58

59 o 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. ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish jobs per workspace that may be worked on in parallel. 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 higher than the value for the MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity 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. The default value is 3. 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. This updates on a 30-second interval. 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. The ProcessingExportMaxThreads instance setting has been deprecated in accordance with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and ProcessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate the work of distributed publish. The following table provides the recommended values for each instance setting per environment setup: Environment setup Tier 1 (see the System Requirements Guide for details) Tier 2 (see the ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Upgrade Guide 59

60 Environment setup System Requirements Guide for details) RelativityOne baseline 3 7 ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Beginning in Relativity , the following Invariant installation components are new: 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. 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 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 and should be noted prior to upgrading: 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 network share that doesn t contain any data. 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 Invariant.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. 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 (December 21, 2016) or lower to the full release of Relativity 9.5 (January 25, 2017) and above, meaning all monthly Upgrade Guide 60

61 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: The MaxConversionThreads column has been removed from the Invariant.dbo.Workstations table, as it was longer in use since conversion became a separate service. 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. The following changes were made to the Invariant installation process: 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. 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: 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. 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 o o The processing profile no longer contains the Processing Fields associative object list view. 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. 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 profiles do have fields mapped, Relativity doesn't automatically transfer fields when you upgrade to 9.5. 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 Upgrade Guide 61

62 you uninstall 2010 and then install 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. 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. 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 Network load balancing If you are using cookie-persisted load balancing configurations for Relativity and higher, you must update the WebClientRequiredCookies instance setting to include the name of the load balancer cookie for the ActiveX viewer New UI framework If you need to disable the new UI framework for the Document list, click Switch to Classic UI from the user drop-down within a workspace. For help using the classic interface, refer to the 9.3 documentation which documents both interfaces side-by-side. For more information, see Navigation in the Admin guide. When using the new UI framework, the following Relativity features have been enhanced: Cluster visualization Dashboards Document list and tabs throughout Relativity Pivot Sampling Search panel and search browser Production The following section discusses the changes to the Production application on upgrade from Relativity 9.x to Relativity Certain upgrade changes only affect upgrades from Relativity 9.1 or 9.2 to Relativity 9.5, 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: An upgrade from Relativity 9.x to 9.5 can fail if the workspace you're upgrading already contains a Relativity field with the name Production. You must rename this field. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Placeholder. You must rename this object. Upgrade Guide 62

63 An upgrade from Relativity 9.1 to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Data Source. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Relativity Color Map. You must rename this object. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Field Catalog. You must rename this object. If you have a full-text index populating the production upgrade stops. Try upgrading again once the full-text index is finished populating. Relativity deduces the First Bates Value and Last Bates Value for all imported and upgraded productions. If you upgrade from Relativity 9.2 to Relativity 9.5 and you were previously using the Production Tracker application, review the Production Tracker 9.5 considerations PDF in the Relativity Community. Beginning in , Productions includes an upgrade step to migrate data from the old ProductionInformation schema to the new schema introduced in Changes to agents and objects: 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.5 environment. The Markup Set table is converted to the Markup Set dynamic object. The Production Object table is converted to the Production dynamic object. Changes to pre-existing Productions: Any staged or errored productions in an environment are set to a status of New and you must restage the production before running. Productions migrated from Relativity 9.1 and 9.2 receive a legacy placeholder stating, "No Tiff Included For This Record." Productions migrated from Relativity 9.1 to Relativity 9.5 have a data source created containing the production documents for each produced and errored production. 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. The Production Error field no longer exists on the Production object. 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 production. Changes to Production fields and views: Upgrade Guide 63

64 On upgrade from 9.2 the Produced Documents field exists in the environment, but the field is not populated. The production document view no longer exists. 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. On upgrade from 9.x to 9.5 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: Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not automatically 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 Production Data Source object to add or edit production data sources after upgrading to Relativity Relativity admin and service account addresses Relativity includes the Relativity admin and service account users by default. With the Relativity , the default addresses for these accounts have been updated as follows: Default user Previous address New address Relativity admin Relativity service account Relativity Desktop Client (RDC) Beginning in Relativity , 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 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 with Relativity versions to but you must create a new RDC OAuth2 client to do so. For more information, see the Desktop Client Guide Relativity installer updates For Relativity 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: Upgrade Guide 64

65 addresses for the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_ and SERVICEACCOUNT_ parameters that you can set with these 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 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 address during a previous installation, it is overwritten by current address that you entered or by the default address when this parameter is blank. o Use different addresses for the ADMIN_ and SERVICEACCOUNT_ parameters. If you use the same address for both parameters, the installation fails. Passwords for the the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_PASSWORD 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 address. If you enter a new password but don t update the address, then new password is ignored. For example, if you use an existing or default address, then the password remains unchanged. However, you can change the addresses for the admin and service accounts without updating the password. For more information, see the Relativity Installation and Relativity Upgrade guides 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: Invariant SQL Server name with an optional port number Relativity SQL Server name with an optional port number Upgrade Guide 65

66 EDDSDBO password 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 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 Required certificates for Relativity Relativity 9.5 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. Upgrade Guide 66

67 We recommend placing the new Analytics server certificate and testing it prior to the day of the upgrade to Relativity 9.3. For more information, see Pre-upgrade: Update the default SSL/TLS certificate for CAAT in the Upgrading or installing your Analytics server section Scripts 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. Beginning in , 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 Searching Upon upgrade to , 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 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.5 Documentation site System requirements Windows Server 2008 R2 (64-bit) is no longer compatible with 9.5. Relativity 9.5 is only compatible with Windows Server 2008 R2 (64-bit) w Service Pack 1. As of Relativity , we no longer support Internet Explore (IE) 10. Please upgrade to a compatible version of IE Telemetry After you install Relativity 9.5, complete the steps to enable telemetry in your environment. Telemetry allows you to collect metrics for performance, usage, and billing. For more information, see Telemetry on the Relativity 9.5 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 Viewer (ActiveX) Beginning in Relativity , you must install Microsoft.NET on all of the machines that need access to the ActiveX viewer. You must also install the new ActiveX viewer installation kit, which includes Upgrade Guide 67

68 the Visual C redistributable, from the Workspace Details tab. You can't use the Relativity viewer with earlier versions of Relativity. Also, earlier versions of the ActiveX viewer aren't compatible with Relativity 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 Viewer (ActiveX and HTML) Beginning in , 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 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. You can 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. See the Instance Setting Guide to learn more about this new value. Pre the Relativity September 30, 2015 product update: As of the Relativity September 30, 2015 product update: Upgrade Guide 68

69 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.5 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 9.5 Documentation site 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 ( Prerequisites for Service Bus 1.1 with TLS 1.2 Support Verify that.net is installed in your environment. You must install.net before you begin upgrading to Service Bus 1.1 with TLS 1.2. This service bus upgrade requires.net For more information, see Upgrading Relativity to.net Upgrade Guide 69

70 Verify that you are running Windows Server 2012 or Windows Server 2012 R2, and Microsoft SQL Server If your environment, doesn't meet these requirements, see Workarounds for Service Bus 1.1 with TLS 1.2 on page 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: 1. Remove all servers from the farm. For more information, see Leaving a Farm ( microsoft.com/en-us/library/dn 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 ( on the Microsoft site. 3. Uninstall Microsoft Azure Surface Fabric Upgrade the SQL Server to support TLS 1.2. For more information, see 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 Catalog=SbManagementDB;Integrated Security=True' -CertificateAutoGenerationKey $mycert See the following confirmation message: 8. Rejoin all servers to the farm. For more information, see the Pre-installation Guide 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 2012 or Windows Server 2012 R2, and Microsoft SQL Server 2012 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: Upgrade Guide 70

71 Windows Server 2012 and SQL Server 2012 Windows Server 2012 R2 and SQL Server 2016 Windows Server 2016 and SQL Server 2014 Windows Server 2016 and SQL Server 2016 While we aren't aware of any issues on these platforms, we request that you are cautious when deploying the Service Bus 1.1 with TLS 1.2 Support update. 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: Client communication - determines which TLS protocols are used for outbound connections from the server that is traffic to the service bus server. 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 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 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). Upgrade Guide 71

72 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. 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 Worker manager queue Revisions in the queue manager code have led to the following enhancements: A reduction in the volume of connections to the SQL Server A reduction in lock waits and thread pool waits A general increase in queue parallelism 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 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 156. The Worker manager page no longer displays the following conversion fields: pre-convert, conversion onthe-fly, mass conversion, and conversion. Beginning in Relativity , 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 Workspace upgrade queue The Workspace Upgrade Queue includes the following columns: Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Workspace Upgrade Worker agent. The possible values in this column are the same as for the workspace upgrade. This field is empty if you don't have Processing installed. Current Store Version - the version of Invariant you are upgrading to 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.5. Your agent servers Upgrade Guide 72

73 should also have one conversion complete agent. For more information, see Configuring your conversion agents. Data Grid If your environment uses Data Grid, you must also upgrade to Data Grid or above when upgrading to Relativity 9.5. For more information, see Upgrading Data Grid. 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. You no longer need to install the DataGridRESTService on the Analytics server to integrate Relativity Analytics with Relativity Data Grid. If you are upgrading to Relativity 9.5, 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. 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 Database schema 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.5 in the Relativity Community 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. 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 Upgrade Guide 73

74 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 File share Beginning in Relativity , 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. 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: Keys from the object (Document or RDO) table to the Artifact table. Keys on the object table that go to a single object field. Keys on multi-object relational f-tables. An f-table stores the link between the objects that are connected 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 IIS 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 74

75 Imaging Beginning in Relativity , 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 , an Imaging Request Agent is automatically installed and enabled in your environment. If you're upgrading to Relativity or if at any point you need to install an additional agent, you need to do so manually. Upgrade Guide 75

76 For more information, see the Imaging guide. Existing imaging profiles received updates based on their imaging method when upgrading to Relativity 9.5. If your environment is set up for native imaging, the following changes occur upon upgrade: Relativity renames the default imaging profile to Native Default. The imaging method is set to Native for all current imaging profiles including Native Default. Relativity creates a new Basic Default imaging profile with the following settings: o Imaging Method: Basic o Basic Image Output Quality (DPI): 300 o o Basic Image Format: TIFF Basic Image Height: Original Setting 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. If your environment is not set up for native imaging, the following changes occur upon upgrade to Relativity 9.5: Relativity renames the default imaging profile to Basic Default. The imaging method is set to Basic for all current imaging profiles including Basic Default. Upgrade Guide 76

77 Imaging sets If you upgrade to Relativity 9.5 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.5. You will, however, be able to re-run the imaging set that contains the errors after you upgrade to Relativity 9.5. For more information, see the Imaging section of the Relativity Admin Guide 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.5 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.5 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: Import or export certificates and private keys at Optionally configure an authentication token-signing certificate on the Pre-installation page in the Relativity 9.5 Documentation site - These instructions describe the process for configuring your own custom token-signing certificate, but you can follow these basic steps to install RelativityIdentityCertificate to each database server in a distributed environment Processing/Invariant Beginning in Relativity , the database installation component has been removed from the Invariant installer. Accordingly, note the following considerations: 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. The queue manager installation is now responsible for creating the database. The queue manager now communicates with the database upgrader to update all databases during an Invariant upgrade. 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. The database component no longer holds registry entries; all registry entries that aren't duplicates are now on the queue manager machine. If you previously installed the Invariant database component on its own machine, it's highly recommended that you uninstall the database before upgrading to Relativity If you uninstall the database after upgrading, you'll delete all Invariant files from the Invariant network share. Upgrade Guide 77

78 There is a new installation log file called UninstallLegacyDatabasePackage.log, which appears only once after an upgrade to Relativity Beginning in Relativity , the following infrastructure changes have been made to processing and should be noted prior to upgrade: ProcessingMaxPublishSubJobCountPerSQLServer - the new default value of this instance setting is 7. For information on configuring this setting, see the Processing User Guide. ProcessingMaxPublishSubJobCountPerWorkspace - the new default value of this instance setting is 3. For information on configuring this setting, see the Processing User Guide. 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. 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. 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. Beginning in Relativity , the following changes have been made to processing and should be noted prior to upgrade: You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue manager. Note that the default port for the Invariant Kepler services is For details, see Enabling HTTPS for Invariant Kepler Services. 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-installation Guide in the Pre-installation topic. Invariant stores are now deleted automatically when the Relativity workspaces associated with them are deleted. For more information, see The Relativity Processing Console Guide. 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 allowing 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 moving on. Note the upgrade-relevant details regarding distributed publish: o The following instance settings have been added to facilitate the work of distributed publish. ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number of publish jobs per Relativity SQL server that may be worked on in parallel. 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. 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 Guide 78

79 o upgrade for guidance on what value will be most beneficial to you based on your environment setup. This updates on a 30-second interval. 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. ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish jobs per workspace that may be worked on in parallel. 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 higher than the value for the MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity 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. The default value is 3. 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. This updates on a 30-second interval. 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. The ProcessingExportMaxThreads instance setting has been deprecated in accordance with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and ProcessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate the work of distributed publish. The following table provides the recommended values for each instance setting per environment setup: Upgrade Guide 79

80 Environment setup Tier 1 (see the System Requirements Guide for details) Tier 2 (see the System Requirements Guide for details) RelativityOne baseline ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Beginning in Relativity , the following Invariant installation components are new: 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. 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 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. You can configure the number of concurrent threads dedicated to OCR, which can mitigate CPU bottlenecks. This is possible through the following changes: The MaxConversionThreads column has been removed from the Invariant.dbo.Workstations table, as it was longer in use since conversion became a separate service. 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 Upgrade Guide 80

81 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. The following changes were made to the Invariant installation process: 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. 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 changes were made to the worker manager server installation process beginning in Relativity and should be noted prior to upgrading: 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 network share that doesn t contain any data. 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 Invariant.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. 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 (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. The following processing changes may impact your upgrade experience: 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. 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 o The processing profile no longer contains the Processing Fields associative object list view. 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. Upgrade Guide 81

82 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 profiles do have fields mapped, Relativity doesn't automatically transfer fields when you upgrade to 9.5. 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 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. 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. 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 New UI framework A new UI framework is turned on by default. If you need to disable the new UI framework for the Document list, click Switch to Classic UI from the user drop-down within a workspace. For help using the classic interface, refer to the 9.3 documentation which documents both interfaces side-by-side. For more information, see Navigation in the Admin guide. When using the new UI framework, the following Relativity features have been enhanced: Cluster visualization Dashboards Document list and tabs throughout Relativity Pivot Sampling Search panel and search browser Processing The following infrastructure items are new to processing in Relativity 9.3: Processing now uses Invariant 4.3. 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 Upgrade Guide 82

83 documents to a workspace using the worker manager server. For users who haven't upgraded their Relativity version since the general release of Relativity 9.2, note that, beginning in Relativity (the product update released on 6/24/2015), Invariant servers require.net Framework 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. Production The following changes occur to existing productions on upgrade: An upgrade from Relativity 8.x to 9.5 can fail if the workspace you're upgrading already contains a Relativity field with the name Production. You must rename this field. On upgrade to Relativity 9.5 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. Any staged or errored productions in an environment are set to a status of New and you must restage the production before running. 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. The Production Error field no longer exists on the Production object. Production sets you ran before upgrading to Relativity 9.5 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 functionality, see the Admin guide. Upgrade Guide 83

84 Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not automatically 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 Production Data Source object to add or edit production data sources after upgrading to Relativity Any preexisting production fields are converted to a production data source upon upgrade. If you upgrade from Relativity 9.2 to Relativity 9.5 and you were previously using the Production Tracker application, review the Production Tracker 9.5 considerations PDF in the Relativity Community. Beginning in , Productions includes an upgrade step to migrate data from the old ProductionInformation schema to the new schema introduced in 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 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 Required certificates for Relativity Relativity 9.5 now verifies that all HTTPS services running in your environment have a trusted certificate. 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 Preinstallation Guide Scripts 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. Beginning in , 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 Searching Upon upgrade to , 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 Upgrade Guide 84

85 double quotes together regardless of the quote type. This may mean the number of results in your searches may change. Servers There are a number of new server types installed automatically with Relativity 9.5: Worker manager server - this uses workers to perform imaging, conversion, and all phases of processing, including inventory, discovery, and publish. This is a required component of Relativity 9.5. If you are not licensed for processing, then the worker manager server only handles document conversion and imaging. For more information, see Worker manager server installation documentation. Worker - this is the machine a worker manager server uses to complete imaging, document conversion, 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 govern. Thus, it's impossible to add workers without adding a worker manager server. For more information, see the Servers section of the Relativity Admin Guide. 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 workspaces. 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 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.5 Documentation site. Structured Analytics If upgrading to Relativity 9.5 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 See Creating a structured analytics set in the Analytics Guide System requirements Windows Server 2008 R2 (64-bit) is no longer compatible with 9.5. Relativity 9.5 is only compatible with Windows Server 2008 R2 (64-bit) w Service Pack 1. As of August 31, 2017, we no longer support Internet Explore (IE) 10. Please upgrade to a compatible version of IE Telemetry After you install Relativity 9.5, complete the steps to enable telemetry in your environment. Telemetry allows you to collect metrics for performance, usage, and billing. For more information, see Telemetry on Upgrade Guide 85

86 the Relativity 9.5 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 Viewer (ActiveX) 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 Viewer (ActiveX and HTML) For users who haven't upgraded their Relativity version since the general release of Relativity 9.2, note that, beginning in the Relativity 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. You can 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. See the Instance Setting Guide to learn more about this new value. Pre the Relativity September 30, 2015 product update: As of the Relativity September 30, 2015 product update: Upgrade Guide 86

87 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.5 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 9.5 Documentation site 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 87

88 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 Worker manager queue Revisions in the queue manager code have led to the following enhancements: A reduction in the volume of connections to the SQL Server A reduction in lock waits and thread pool waits A general increase in queue parallelism 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 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 156. The Worker manager page no longer displays the following conversion fields: pre-convert, conversion onthe-fly, mass conversion, and conversion. Beginning in Relativity , 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 Workspace upgrade queue The Workspace Upgrade Queue includes the following columns: Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Workspace Upgrade Worker agent. The possible values in this column are the same as for the workspace upgrade. This field is empty if you don't have Processing installed. Current Store Version - the version of Invariant you are upgrading to. 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. Beginning in Relativity , you must install Microsoft.NET 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 redistributable, from the Workspace Details tab. You can't use the Relativity viewer with earlier versions of Relativity. Also, earlier versions of the ActiveX viewer aren't compatible with Relativity For more information, see Legacy viewer installation in the workstation configuration guide. Upgrade Guide 88

89 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 Workers 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 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 156. The Worker manager page no longer displays the following conversion fields: pre-convert, conversion onthe-fly, mass conversion, and conversion. Beginning in Relativity , 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. Workspace Upgrade Queue The Workspace Upgrade Queue includes the following columns: Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Workspace Upgrade Worker agent. The possible values in this column are the same as for the workspace upgrade. This field is empty if you don't have Processing installed. Current Store Version - the version of Invariant you are upgrading to. 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 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.5 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 Upgrade Guide 89

90 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 9.5 Documentation site x to 9.5 Relativity updates Learn more about the changes to your Relativity 7.x environment after you upgrade to Relativity 9.5. This section also includes post-upgrade processes you'll need to follow. 7.x to 9.5 Relativity updates Agent service Analytics on the next page Applications Audit on page 94 Authentication on page 24 Conversion Database schema dtsearch index considerations on page 115 File share on page 116 Foreign key removal on page 116 IIS on page 118 Imaging on page 116 Installation of a certificate on the database server on page 118 Processing/Invariant License Relativity and Processing on page 124 Network load balancing on page 104 New UI framework on page 124 Production on page 125 RAR upgrade notes on page 125 Relativity admin and service account addresses on page 106 Relativity Desktop Client (RDC) on page 107 Relativity installer updates on page 107 Relativity service bus on page 126 Required certificates for Relativity on page 126 Scripts Upgrade Guide 90

91 Searching on page 127 System requirements on page 127 Windows or Integrated Windows authentication on page 128 Windows Service Bus 1.1 with TLS 1.2 Support on page 111 Viewer on page 126 Viewer (ActiveX) on page 127 Upgrade custom applications or code on page 128 Workers Worker manager server Workspace Upgrade Queue 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. Analytics Relativity 9.3 includes a Textual Near Duplicate Identification algorithm with the following benefits: The new algorithm can greatly improve performance for both large and complex data sets. 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.5: In the Relativity Applications Library, the Analytics application contains the structured data analytics functionality, and the Analytics Core application contains Analytics profiles, repeated content filters, and Analytics categorization sets. Note: On upgrade to Relativity 9.5, you can choose whether or not to include the Analytics application (structured data analytics). The Analytics Core application deploys automatically. 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 PLI anymore. Instead, you can use the language identification operation when creating a Structured Data Analytics set. Content Analyst 3.14 is required to use Analytics in Relativity 9.5. Upgrade Guide 91

92 See the Analytics Guide for more information on Language Identification New Analytics installer Starting with Relativity , 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 (CAAT 3.17) or lower, first run the Relativity or 9.4 Analytics server installer using the instructions at Running the Relativity Analytics installer for versions previous to Relativity Contact Support for this installer. After this step, then run the Relativity 9.5 response file-based installer. 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 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., Analytics index enhancements Starting with Relativity , Analytics indexes are now RDO's. There are a few considerations with this update: Indexes will no longer have the default saved searches available to set as the training and searchable 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) After the upgrade, you will no longer have the option to preserve cluster multiple choice and coherence score fields when deleting the cluster set. They will always be deleted. OCR and Go Word filter support has been deprecated from Analytics Indexes. On subsequent populations 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). When you upgrade, the Analytics Core install event handlers will create a new RDO for each existing index and a new RDO for each existing cluster set. These new object types and instances inherits permissions from their analogous source objects. For example: o Analytics Index RDO workspace permissions are copied from Search Index workspace permissions o o Analytics Index RDO instance permissions are copied from Search Index instance permissions Cluster Set RDO workspace permissions are copied from Search Index workspace permissions Upgrade Guide 92

93 o Cluster Set RDO instance permissions are copied from the multiple choice cluster field's item level permissions thread visualization Users must have the Analytics application installed in the workspace, and the Author Date ID must be present for the s. The Author Date ID is only available for s run through a full analysis using structured analytics in Relativity and above. The thread visualization pane will not work for threads from previous versions unless a full analysis is run against the structured analytics set containing the s after upgrading to Relativity or higher Multiple structured analytic set results Beginning in Relativity , you can easily store the results for multiple structured analytics sets and set up views that capture the threading or repeated content identification results of those operations. Consider the following: We recommend you set new relational fields (e.g., Destination Thread Group, Destination Duplicate ID, and Destination Textual Near Duplicate Group) when creating new structured analytics sets for 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. Upon upgrade, the thread group, duplicate spare group, and textual near duplicate group relational views display just the Control Number and Edit columns. To display the old fields, you must unlock the application and update those views. If you run Structured Analytics with the existing application relational fields, the relational views will only show the Control Number and Edit columns. A way to avoid this is by creating and mapping your own relational fields before run time. Then, you can create your own relational view and map that to the custom relational fields. Note: This upgrade consideration has been addressed in Relativity If you are upgrading to Relativity , disregard this item. Upon upgrade, 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 reference these newly created fields don't carry over on workspace creation because Structured Analytics Sets don't carry over. Note: This upgrade consideration impacts any Relativity templates that reference the legacy Structured Analytics results fields. Upon upgrade, previous inclusive information may change when performing an incremental analysis on an existing threading set due to the newly created structured Analytics results fields Applications 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 Upgrade Guide 93

94 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 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 Authentication Consider the following for upgrading: 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 permits more versatile and detailed method implementations. 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 version being ungraded from, such as 9_2_AuthenticationUserTableBackupRecord or 9_3_AuthenticationUserTableBackupRecord. If after upgrading and making sure all users converted successfully, you may delete the copy table. 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 parsing 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 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.5, permissions are as follows: 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. 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. After upgrade only users in the System Administrators group will have access to view and edit OAuth2Client objects 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.5. Your agent servers should also have one conversion complete agent. For more information, see Configuring your conversion agents. Upgrade Guide 94

95 Data Grid If your environment uses Data Grid, you must also upgrade to Data Grid or above when upgrading to Relativity 9.5. For more information, see Upgrading Data Grid. 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. You no longer need to install the DataGridRESTService on the Analytics server to integrate Relativity Analytics with Relativity Data Grid. If you are upgrading to Relativity 9.5, 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. 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 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.5 in the Relativity Community 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. ECA and Investigation The ECA and Investigation and Field Catalog applications are now synchronized, which means that when you install the ECA and Investigation application, Relativity automatically maps all of the ECA fields to those 127 corresponding processing fields found in the Field Catalog. For a list of these fields, see the Processing User Guide. Note the following details: Upgrade Guide 95

96 A number of processing fields were renamed in the Field Catalog. Renamed fields will cause naming 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. 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 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. Fields 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 File share Beginning in Relativity , 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. 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: Keys from the object (Document or RDO) table to the Artifact table. Keys on the object table that go to a single object field. Keys on multi-object relational f-tables. An f-table stores the link between the objects that are connected 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. Upgrade Guide 96

97 2.3.8 IIS 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 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 97

98 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. Imaging Beginning in Relativity , 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 , an Imaging Request Agent is automatically installed and enabled in your environment. If you're upgrading to Relativity or if at any point you need to install an additional agent, you need to do so manually. Upgrade Guide 98

99 For more information, see the Imaging guide. Existing imaging profiles received the following updates based on their imaging method when upgrading to Relativity 9.5: If your environment is set up for native imaging, the following changes occur upon upgrade: Relativity renames the default imaging profile to Native Default. The imaging method is set to Native for all current imaging profiles including Native Default. Relativity creates a new basic default imaging profile with the following settings: o Imaging Method: Basic o Basic Image Output Quality (DPI): 300 o o Basic Image Format: TIFF Basic Image Height: Original Setting 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.5: Upgrade Guide 99

100 Relativity renames the default imaging profile to Basic Default. The imaging method is set to basic for all current imaging profiles including Basic Default 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.5 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.5 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: Import or export certificates and private keys at Optionally configure an authentication token-signing certificate on the Pre-installation page in the Relativity 9.5 Documentation site - These instructions describe the process for configuring your own custom token-signing certificate, but you can follow these basic steps to install RelativityIdentityCertificate to each database server in a distributed environment Instance settings If upgrading to Relativity 9.5 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. Note: If a new 9.5 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 Backwards compatibility For any existing applications that reference the pre-9.5 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 Processing/Invariant Beginning in Relativity , the following changes have been made to processing and should be noted prior to upgrade: You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue manager. Note that the default port for the Invariant Kepler services is For details, see Enabling HTTPS for Invariant Kepler Services. Upgrade Guide 100

101 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-installation Guide in the Pre-installation topic. Invariant stores are now deleted automatically when the Relativity workspaces associated with them are deleted. For more information, see The Relativity Processing Console Guide. 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 allowing 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 moving on. Note the upgrade-relevant details regarding distributed publish: o The following instance settings have been added to facilitate the work of distributed publish. ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number of publish jobs per Relativity SQL server that may be worked on in parallel. 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. 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. This updates on a 30-second interval. 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. ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish jobs per workspace that may be worked on in parallel. 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 higher than the value for the MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity 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. The default value is 3. 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. This updates on a 30-second interval. Upgrade Guide 101

102 o 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. The ProcessingExportMaxThreads instance setting has been deprecated in accordance with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and ProcessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate the work of distributed publish. The following table provides the recommended values for each instance setting per environment setup: Environment setup Tier 1 (see the System Requirements Guide for details) Tier 2 (see the System Requirements Guide for details) RelativityOne baseline ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Beginning in Relativity , the following Invariant installation components are new: 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. 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 Upgrade Guide 102

103 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 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 and should be noted prior to upgrading: 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 network share that doesn t contain any data. 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 Invariant.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. 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 (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: The MaxConversionThreads column has been removed from the Invariant.dbo.Workstations table, as it was longer in use since conversion became a separate service. 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. The following changes were made to the Invariant installation process: 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. 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. Upgrade Guide 103

104 The following processing changes may impact your upgrade experience: 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. 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 o o The processing profile no longer contains the Processing Fields associative object list view. 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. 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 profiles do have fields mapped, Relativity doesn't automatically transfer fields when you upgrade to 9.5. 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 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. 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. 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 Network load balancing If you are using cookie-persisted load balancing configurations for Relativity and higher, you must update the WebClientRequiredCookies instance setting to include the name of the load balancer cookie for the ActiveX viewer New UI framework If you need to disable the new UI framework for the Document list, click Switch to Classic UI from the user drop-down within a workspace. For help using the classic interface, refer to the 9.3 documentation which documents both interfaces side-by-side. For more information, see Navigation in the Admin guide. When using the new UI framework, the following Relativity features have been enhanced: Upgrade Guide 104

105 Cluster visualization Dashboards Document list and tabs throughout Relativity Pivot Sampling Search panel and search browser Production The following section discusses the changes to the Production application on upgrade from Relativity 9.x to Relativity Certain upgrade changes only affect upgrades from Relativity 9.1 or 9.2 to Relativity 9.5, 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: An upgrade from Relativity 9.x to 9.5 can fail if the workspace you're upgrading already contains a Relativity field with the name Production. You must rename this field. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Placeholder. You must rename this object. An upgrade from Relativity 9.1 to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Data Source. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Relativity Color Map. You must rename this object. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Field Catalog. You must rename this object. If you have a full-text index populating the production upgrade stops. Try upgrading again once the full-text index is finished populating. Relativity deduces the First Bates Value and Last Bates Value for all imported and upgraded productions. If you upgrade from Relativity 9.2 to Relativity 9.5 and you were previously using the Production Tracker application, review the Production Tracker 9.5 considerations PDF in the Relativity Community. Beginning in , Productions includes an upgrade step to migrate data from the old ProductionInformation schema to the new schema introduced in Changes to agents and objects: 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.5 environment. Upgrade Guide 105

106 The Markup Set table is converted to the Markup Set dynamic object. The Production Object table is converted to the Production dynamic object. Changes to pre-existing Productions: Any staged or errored productions in an environment are set to a status of New and you must restage the production before running. Productions migrated from Relativity 9.1 and 9.2 receive a legacy placeholder stating, "No Tiff Included For This Record." Productions migrated from Relativity 9.1 to Relativity 9.5 have a data source created containing the production documents for each produced and errored production. 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. The Production Error field no longer exists on the Production object. 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 production. Changes to Production fields and views: On upgrade from 9.2 the Produced Documents field exists in the environment, but the field is not populated. The production document view no longer exists. 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. On upgrade from 9.x to 9.5 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: Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not automatically 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 Production Data Source object to add or edit production data sources after upgrading to Relativity Relativity admin and service account addresses Relativity includes the Relativity admin and service account users by default. With the Relativity , the default addresses for these accounts have been updated as follows: Upgrade Guide 106

107 Default user Previous address New address Relativity admin Relativity service account Relativity Desktop Client (RDC) Beginning in Relativity , 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 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 with Relativity versions to but you must create a new RDC OAuth2 client to do so. For more information, see the Desktop Client Guide Relativity installer updates For Relativity 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: addresses for the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_ and SERVICEACCOUNT_ parameters that you can set with these 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 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 address during a previous installation, it is overwritten by current address that you entered or by the default address when this parameter is blank. o Use different addresses for the ADMIN_ and SERVICEACCOUNT_ parameters. If you use the same address for both parameters, the installation fails. Passwords for the the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_PASSWORD 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 address. If you enter a new password but don t update the address, then new password is ignored. For example, if you use an existing or default address, then the password remains unchanged. However, you can change the addresses for the admin and service accounts without updating the password. For more information, see the Relativity Installation and Relativity Upgrade guides. Upgrade Guide 107

108 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: Invariant SQL Server name with an optional port number Relativity SQL Server name with an optional port number EDDSDBO password 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 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. Upgrade Guide 108

109 Required certificates for Relativity Relativity 9.5 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.3. For more information, see Pre-upgrade: Update the default SSL/TLS certificate for CAAT in the Upgrading or installing your Analytics server section Scripts 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. Beginning in , 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 Searching Upon upgrade to , 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 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.5 Documentation site System requirements Windows Server 2008 R2 (64-bit) is no longer compatible with 9.5. Relativity 9.5 is only compatible with Windows Server 2008 R2 (64-bit) w Service Pack 1. As of Relativity , we no longer support Internet Explore (IE) 10. Please upgrade to a compatible version of IE Telemetry After you install Relativity 9.5, complete the steps to enable telemetry in your environment. Telemetry allows you to collect metrics for performance, usage, and billing. For more information, see Telemetry on the Relativity 9.5 Documentation site. Upgrade Guide 109

110 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 Viewer (ActiveX) Beginning in Relativity , you must install Microsoft.NET 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 redistributable, from the Workspace Details tab. You can't use the Relativity viewer with earlier versions of Relativity. Also, earlier versions of the ActiveX viewer aren't compatible with Relativity 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 Viewer (ActiveX and HTML) For users who haven't upgraded their Relativity version since the general release of Relativity 9.2, note that, beginning in the Relativity 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. You can 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. See the Instance Setting Guide to learn more about this new value. Pre the Relativity September 30, 2015 product update: Upgrade Guide 110

111 As of the Relativity September 30, 2015 product update: 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.5 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 9.5 Documentation site 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 ( Prerequisites for Service Bus 1.1 with TLS 1.2 Support Verify that.net is installed in your environment. You must install.net before you begin upgrading to Service Bus 1.1 with TLS 1.2. This service bus upgrade requires.net For more information, see Upgrading Relativity to.net Upgrade Guide 111

112 Verify that you are running Windows Server 2012 or Windows Server 2012 R2, and Microsoft SQL Server If your environment, doesn't meet these requirements, see Workarounds for Service Bus 1.1 with TLS 1.2 on page 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: 1. Remove all servers from the farm. For more information, see Leaving a Farm ( microsoft.com/en-us/library/dn 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 ( on the Microsoft site. 3. Uninstall Microsoft Azure Surface Fabric Upgrade the SQL Server to support TLS 1.2. For more information, see 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 Catalog=SbManagementDB;Integrated Security=True' -CertificateAutoGenerationKey $mycert See the following confirmation message: 8. Rejoin all servers to the farm. For more information, see the Pre-installation Guide 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 2012 or Windows Server 2012 R2, and Microsoft SQL Server 2012 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: Upgrade Guide 112

113 Windows Server 2012 and SQL Server 2012 Windows Server 2012 R2 and SQL Server 2016 Windows Server 2016 and SQL Server 2014 Windows Server 2016 and SQL Server 2016 While we aren't aware of any issues on these platforms, we request that you are cautious when deploying the Service Bus 1.1 with TLS 1.2 Support update. 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: Client communication - determines which TLS protocols are used for outbound connections from the server that is traffic to the service bus server. 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 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 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). Upgrade Guide 113

114 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. 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 Worker manager queue Revisions in the queue manager code have led to the following enhancements: A reduction in the volume of connections to the SQL Server A reduction in lock waits and thread pool waits A general increase in queue parallelism 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 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 156. The Worker manager page no longer displays the following conversion fields: pre-convert, conversion onthe-fly, mass conversion, and conversion. Beginning in Relativity , 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 Workspace upgrade queue The Workspace Upgrade Queue includes the following columns: Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Workspace Upgrade Worker agent. The possible values in this column are the same as for the workspace upgrade. This field is empty if you don't have Processing installed. Current Store Version - the version of Invariant you are upgrading to 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.5. Your agent servers Upgrade Guide 114

115 should also have one conversion complete agent. For more information, see Configuring your conversion agents Database schema 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.5 in the Relativity Community 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. 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: For indexes built in Relativity 5.9 or below, you must perform a Full Build for them to work normally. Any active indexes built in Relativity 6.2 or above continue work normally. 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. For indexes that are in progress or in an error state when you upgrade, you must perform a Full Build. Indexes with document level errors continue to work normally. 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. Upgrade Guide 115

116 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 displays this share location in the dtsearch Index Share Locations section File share Beginning in Relativity , 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. 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: Keys from the object (Document or RDO) table to the Artifact table. Keys on the object table that go to a single object field. Keys on multi-object relational f-tables. An f-table stores the link between the objects that are connected 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. Imaging Beginning in Relativity , 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 , an Imaging Request Agent is automatically installed and enabled in your environment. If you're upgrading to Relativity or if at any point you need to install an additional agent, you need to do so manually. Upgrade Guide 116

117 For more information, see the Imaging guide. Existing imaging profiles received updates based on their imaging method when upgrading to Relativity 9.5. If your environment is set up for native imaging, the following changes occur upon upgrade: Relativity renames the default imaging profile to Native Default. The imaging method is set to Native for all current imaging profiles including Native Default. Relativity creates a new Basic Default imaging profile with the following settings: o Imaging Method: Basic o Basic Image Output Quality (DPI): 300 o o Basic Image Format: TIFF Basic Image Height: Original Setting 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. If your environment is not set up for native imaging, the following changes occur upon upgrade to Relativity 9.5: Relativity renames the default imaging profile to Basic Default. The imaging method is set to Basic for all current imaging profiles including Basic Default. Upgrade Guide 117

118 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.5 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.5 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: Import or export certificates and private keys at Optionally configure an authentication token-signing certificate on the Pre-installation page in the Relativity 9.5 Documentation site - These instructions describe the process for configuring your own custom token-signing certificate, but you can follow these basic steps to install RelativityIdentityCertificate to each database server in a distributed environment IIS 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 118

119 Processing/Invariant Beginning in Relativity , the following infrastructure changes have been made to processing and should be noted prior to upgrade: ProcessingMaxPublishSubJobCountPerSQLServer - the new default value of this instance setting is 7. For information on configuring this setting, see the Processing User Guide. ProcessingMaxPublishSubJobCountPerWorkspace - the new default value of this instance setting is 3. For information on configuring this setting, see the Processing User Guide. 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. 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. 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. Beginning in Relativity , the following changes have been made to processing and should be noted prior to upgrade: You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue manager. Note that the default port for the Invariant Kepler services is For details, see Enabling HTTPS for Invariant Kepler Services. Upgrade Guide 119

120 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-installation Guide in the Pre-installation topic. Invariant stores are now deleted automatically when the Relativity workspaces associated with them are deleted. For more information, see The Relativity Processing Console Guide. 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 allowing 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 moving on. Note the upgrade-relevant details regarding distributed publish: o The following instance settings have been added to facilitate the work of distributed publish. ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number of publish jobs per Relativity SQL server that may be worked on in parallel. 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. 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. This updates on a 30-second interval. 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. ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish jobs per workspace that may be worked on in parallel. 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 higher than the value for the MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity 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. The default value is 3. 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. This updates on a 30-second interval. Upgrade Guide 120

121 o 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. The ProcessingExportMaxThreads instance setting has been deprecated in accordance with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and ProcessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate the work of distributed publish. The following table provides the recommended values for each instance setting per environment setup: Environment setup Tier 1 (see the System Requirements Guide for details) Tier 2 (see the System Requirements Guide for details) RelativityOne baseline ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Beginning in Relativity , the following Invariant installation components are new: 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. 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 Upgrade Guide 121

122 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 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. You can configure the number of concurrent threads dedicated to OCR, which can mitigate CPU bottlenecks. This is possible through the following changes: The MaxConversionThreads column has been removed from the Invariant.dbo.Workstations table, as it was longer in use since conversion became a separate service. 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. The following changes were made to the worker manager server installation process beginning in Relativity and should be noted prior to upgrading: 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 network share that doesn t contain any data. 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 Invariant.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. 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 (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. The following processing changes may impact your upgrade experience: 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. 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. Upgrade Guide 122

123 o o o The processing profile no longer contains the Processing Fields associative object list view. 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. 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 profiles do have fields mapped, Relativity doesn't automatically transfer fields when you upgrade to 9.5. 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 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. 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. 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. When upgrading the Processing application from 7.5 to Relativity 9.5, 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: All documents published in 7.5 will retain the 7.5 document numbering format of nine digits. All documents published or republished in Relativity 9.5 will have the new 10 digit document numbering format. This new format extends to the Attachment Document ID, Parent Document ID, and Group ID fields. Documents republished in Relativity 9.5 could potentially be duplicated with the new document numbering format. Reference fields such as the Attachment Document ID, Parent Document ID, and Group ID on documents 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 Invariant 3.1 Relativity 8.0 Upgrade Guide 123

124 Invariant version Relativity version Invariant 3.2 Relativity 8.1 Invariant 3.3 Relativity 8.2 Invariant 4.0 Relativity 9.0/9.1 Invariant 4.2 Relativity 9.2 Invariant 4.3 Relativity 9.3 Invariant 4.4 Relativity 9.4 Invariant 4.5 Relativity 9.5 License Relativity and Processing As part of the upgrade to Relativity 9.5, you need to apply a new Relativity and optional Processing license to your installation. 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. 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 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 New UI framework A new UI framework, which is now turned on by default. If you need to disable the new UI framework for the Document list, click Switch to Classic UI from the user drop-down within a workspace. For help using the classic interface, refer to the 9.3 documentation which documents both interfaces side-by-side. For more information, see Navigation in the Admin guide. When using the new UI framework, the following Relativity features have been enhanced: Upgrade Guide 124

125 Cluster visualization Dashboards Document list and tabs throughout Relativity Pivot Sampling Search panel and search browser Production The following changes occur to existing productions on upgrade: 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. Any staged or errored productions in an environment are set to a status of New and you must restage the production before running. 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. The Production Error field no longer exists on the Production object. Production sets you ran before upgrading to Relativity 9.5 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 functionality, see the Admin guide. Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not automatically 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 Production Data Source object to add or edit production data sources after upgrading to Relativity Any preexisting production fields are converted to a production data source upon upgrade. If you upgrade from Relativity 7.x to Relativity 9.5 and you were previously using the Production Tracker application, review the Production Tracker 9.5 considerations PDF in the Relativity Community. Beginning in , Productions includes an upgrade step to migrate data from the old ProductionInformation schema to the new schema introduced in An upgrade from Relativity 9.x to 9.5 can fail if the workspace you're upgrading already contains a Relativity field with the name Production. You must rename this field. 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.5 before or after you Upgrade Guide 125

126 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: Gives old rounds a round type value of 7.5. Creates an Assisted Review saved searches folder if it didn't already exist. Creates a project-specific saved searches folder. Copies the project saved search to the new folder and creates four saved searches if categorization has already occurred. Sets all issues to a Medium Importance level. 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 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 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 Required certificates for Relativity Relativity 9.5 now verifies that all HTTPS services running in your environment have a trusted certificate. 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 Preinstallation Guide. Viewer Relativity 9.5 uses Oracle Outside In version When you upgrade to Relativity 9.5, 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 126

127 Searching Upon upgrade to , 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 Scripts 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. Beginning in , 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 System requirements Windows Server 2008 R2 (64-bit) is no longer compatible with 9.5. Relativity 9.5 is only compatible with Windows Server 2008 R2 (64-bit) w Service Pack 1. As of August 31, 2017, we no longer support Internet Explore (IE) 10. Please upgrade to a compatible version of IE Viewer (ActiveX) Beginning in Relativity , you must install Microsoft.NET 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 redistributable, from the Workspace Details tab. You can't use the Relativity viewer with earlier versions of Relativity. Also, earlier versions of the ActiveX viewer aren't compatible with Relativity 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 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 127

128 1. Click the Start button and type regedit in the search box, then click Enter. 2. Navigate to the appropriate location: If you're using a 64-bit OS, navigate to HKEY_LOCAL_ MACHINE\SOFTWARE\Wow6432Node\kCura\ImageViewer If you're using a 32-bit OS, navigate to HKEY_LOCAL_MACHINE\SOFTWARE\kCura\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. 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 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.5 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 9.5 Documentation site Workers 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 Worker manager server 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 128

129 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 156. The Worker manager page no longer displays the following conversion fields: pre-convert, conversion onthe-fly, mass conversion, and conversion x to 9.5 Relativity updates Learn more about the changes to your Relativity 6.x environment after you upgrade to Relativity 9.5. This section also includes post-upgrade processes you'll need to follow. 6.x to 9.5 Relativity updates Agent service Analytics on the next page Applications Audit on page 132 Authentication on page 24 Conversion Database schema dtsearch index considerations on page 134 Document Table Trigger removal considerations on page 134 File share on page 27 Upgrade considerations for Relativity 9.5 on page 17 Upgrade considerations for Relativity 9.5 on page 17 Upgrade considerations for Relativity 9.5 on page 17 Upgrade considerations for Relativity 9.5 on page 17 License Relativity on page 139 Network load balancing on page 143 Upgrade considerations for Relativity 9.5 on page 17 Pre-installation steps for web servers on page 146 Upgrade considerations for Relativity 9.5 on page 17 Relativity admin and service account addresses on page 146 Relativity Desktop Client (RDC) on page 147 Relativity installer updates on page 147 Upgrade considerations for Relativity 9.5 on page 17 Upgrade considerations for Relativity 9.5 on page 17 Scripts Upgrade Guide 129

130 Upgrade considerations for Relativity 9.5 on page 17 Upgrade considerations for Relativity 9.5 on page 17 Viewer on page 150 Upgrade considerations for Relativity 9.5 on page 17 Upgrade considerations for Relativity 9.5 on page 17 Windows Service Bus 1.1 with TLS 1.2 Support on page 44 Windows Service Bus 1.1 with TLS 1.2 Support on page 152 Workers Worker manager server 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 Analytics Relativity 9.3 introduces a new Textual Near Duplicate Identification algorithm with the following benefits: The new algorithm can greatly improve performance for both large and complex data sets. 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. 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 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., Upgrading/installing Relativity Analytics 9.5 An install or upgrade of Relativity Analytics 9.5 is required for Relativity 9.5. To install Relativity Analytics 9.5, you must run the Relativity Analytics Server Setup wizard after installing or upgrading your Relativity instance. Upgrade Guide 130

131 When you run the Relativity Analytics Server Setup wizard, the wizard automatically: Installs the CAAT service Deploys the Relativity library files Configures the java heap size (set by default to half of RAM) Allows you to set an index path on new install, thus eliminating the need to manually set the location of indexes Sets the CAAT Windows service to log in as the Relativity Service Account Note: If you are upgrading from Relativity (CAAT 3.17) or lower, first run the Relativity or 9.4 Analytics server installer using the instructions at Running the Relativity Analytics installer for versions previous to Relativity Contact Support for this installer. After this step, then run the Relativity 9.5 response file-based installer Analytics index enhancements Starting with Relativity , Analytics indexes are now RDO's. There are a few considerations with this update: Indexes will no longer have the default saved searches available to set as the training and searchable 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) After the upgrade, you will no longer have the option to preserve cluster multiple choice and coherence score fields when deleting the cluster set. They will always be deleted. OCR and Go Word filter support has been deprecated from Analytics Indexes. On subsequent populations 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). When you upgrade, the Analytics Core install event handlers will create a new RDO for each existing index and a new RDO for each existing cluster set. These new object types and instances inherits permissions from their analogous source objects. For example: o Analytics Index RDO workspace permissions are copied from Search Index workspace permissions o o o Analytics Index RDO instance permissions are copied from Search Index instance permissions Cluster Set RDO workspace permissions are copied from Search Index workspace permissions Cluster Set RDO instance permissions are copied from the multiple choice cluster field's item level permissions thread visualization Users must have the Analytics application installed in the workspace, and the Author Date ID must be present for the s. The Author Date ID is only available for s run through a full analysis Upgrade Guide 131

132 using structured analytics in Relativity and above. The thread visualization pane will not work for threads from previous versions unless a full analysis is run against the structured analytics set containing the s after upgrading to Relativity or higher Multiple structured analytic set results Beginning in Relativity , you can easily store the results for multiple structured analytics sets and set up views that capture the threading or repeated content identification results of those operations. Consider the following: We recommend you set new relational fields (e.g., Destination Thread Group, Destination Duplicate ID, and Destination Textual Near Duplicate Group) when creating new structured analytics sets for 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. Upon upgrade, the thread group, duplicate spare group, and textual near duplicate group relational views display just the Control Number and Edit columns. To display the old fields, you must unlock the application and update those views. If you run Structured Analytics with the existing application relational fields, the relational views will only show the Control Number and Edit columns. A way to avoid this is by creating and mapping your own relational fields before run time. Then, you can create your own relational view and map that to the custom relational fields. Note: This upgrade consideration has been addressed in Relativity If you are upgrading to Relativity , disregard this item. Upon upgrade, 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 reference these newly created fields don't carry over on workspace creation because Structured Analytics Sets don't carry over. Note: This upgrade consideration impacts any Relativity templates that reference the legacy Structured Analytics results fields. Upon upgrade, previous inclusive information may change when performing an incremental analysis on an existing threading set due to the newly created structured Analytics results fields Applications 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 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. Upgrade Guide 132

133 2.4.5 Authentication Consider the following for upgrading: 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 permits more versatile and detailed method implementations. 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 version being ungraded from, such as 9_2_AuthenticationUserTableBackupRecord or 9_3_AuthenticationUserTableBackupRecord. If after upgrading and making sure all users converted successfully, you may delete the copy table. 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 parsing 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 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.5, permissions are as follows: 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. 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. After upgrade only users in the System Administrators group will have access to view and edit OAuth2Client objects 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.5. Your agent servers should also have one conversion complete agent. For more information, see Configuring your conversion agents. Data Grid If your environment uses Data Grid, you must also upgrade to Data Grid or above when upgrading to Relativity 9.5. For more information, see Upgrading Data Grid. 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. Upgrade Guide 133

134 You no longer need to install the DataGridRESTService on the Analytics server to integrate Relativity Analytics with Relativity Data Grid. If you are upgrading to Relativity 9.5, 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. 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 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.5 in the Relativity Community 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 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 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: For indexes built in Relativity 5.9 or below, you must perform a Full Build for them to work normally. Any active indexes built in Relativity 6.2 or above continue work normally. 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. Upgrade Guide 134

135 For indexes that are in progress or in an error state when you upgrade, you must perform a Full Build. Indexes with document level errors continue to work normally. ECA and Investigation The ECA and Investigation and Field Catalog applications are now synchronized, which means that when you install the ECA and Investigation application, Relativity automatically maps all of the ECA fields to those 127 corresponding processing fields found in the Field Catalog. For a list of these fields, see the Processing User Guide. Note the following details: A number of processing fields were renamed in the Field Catalog. Renamed fields will cause naming 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. 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 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. Fields 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 File share Beginning in Relativity , 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. 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: Keys from the object (Document or RDO) table to the Artifact table. Keys on the object table that go to a single object field. Upgrade Guide 135

136 Keys on multi-object relational f-tables. An f-table stores the link between the objects that are connected 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 IIS 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 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 136

137 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. Imaging Beginning in Relativity , 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 , an Imaging Request Agent is automatically installed and enabled in your environment. If you're upgrading to Relativity or if at any point you need to install an additional agent, you need to do so manually. Upgrade Guide 137

138 For more information, see the Imaging guide. Existing imaging profiles received the following updates based on their imaging method when upgrading to Relativity 9.5: If your environment is set up for native imaging, the following changes occur upon upgrade: Relativity renames the default imaging profile to Native Default. The imaging method is set to Native for all current imaging profiles including Native Default. Relativity creates a new basic default imaging profile with the following settings: o Imaging Method: Basic o Basic Image Output Quality (DPI): 300 o o Basic Image Format: TIFF Basic Image Height: Original Setting 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: Relativity renames the default imaging profile to Basic Default. The imaging method is set to basic for all current imaging profiles including Basic Default. Upgrade Guide 138

139 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.5 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.5 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: Import or export certificates and private keys at Optionally configure an authentication token-signing certificate on the Pre-installation page in the Relativity 9.5 Documentation site - These instructions describe the process for configuring your own custom token-signing certificate, but you can follow these basic steps to install RelativityIdentityCertificate to each database server in a distributed environment Instance settings If upgrading to Relativity 9.5 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. Note: If a new 9.5 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 Backwards compatibility For any existing applications that reference the pre-9.5 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 License Relativity As part of the upgrade to Relativity 9.5, 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 Processing/Invariant Beginning in Relativity , the following changes have been made to processing and should be noted prior to upgrade: Upgrade Guide 139

140 You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue manager. Note that the default port for the Invariant Kepler services is For details, see Enabling HTTPS for Invariant Kepler Services. 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-installation Guide in the Pre-installation topic. Invariant stores are now deleted automatically when the Relativity workspaces associated with them are deleted. For more information, see The Relativity Processing Console Guide. 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 allowing 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 moving on. Note the upgrade-relevant details regarding distributed publish: o The following instance settings have been added to facilitate the work of distributed publish. ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number of publish jobs per Relativity SQL server that may be worked on in parallel. 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. 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. This updates on a 30-second interval. 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. ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish jobs per workspace that may be worked on in parallel. 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 higher than the value for the MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity 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. The default value is 3. 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. Upgrade Guide 140

141 o This updates on a 30-second interval. 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. The ProcessingExportMaxThreads instance setting has been deprecated in accordance with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and ProcessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate the work of distributed publish. The following table provides the recommended values for each instance setting per environment setup: Environment setup Tier 1 (see the System Requirements Guide for details) Tier 2 (see the System Requirements Guide for details) RelativityOne baseline ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Beginning in Relativity , the following Invariant installation components are new: 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. 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 Upgrade Guide 141

142 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 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 and should be noted prior to upgrading: 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 network share that doesn t contain any data. 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 Invariant.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. 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 (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: The MaxConversionThreads column has been removed from the Invariant.dbo.Workstations table, as it was longer in use since conversion became a separate service. 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. The following changes were made to the Invariant installation process: 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. 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. Upgrade Guide 142

143 The following processing changes may impact your upgrade experience: 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. 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 o o The processing profile no longer contains the Processing Fields associative object list view. 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. 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 profiles do have fields mapped, Relativity doesn't automatically transfer fields when you upgrade to 9.5. 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 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. 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. 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 Network load balancing If you are using cookie-persisted load balancing configurations for Relativity and higher, you must update the WebClientRequiredCookies instance setting to include the name of the load balancer cookie for the ActiveX viewer New UI framework If you need to disable the new UI framework for the Document list, click Switch to Classic UI from the user drop-down within a workspace. For help using the classic interface, refer to the 9.3 documentation which documents both interfaces side-by-side. For more information, see Navigation in the Admin guide. When using the new UI framework, the following Relativity features have been enhanced: Upgrade Guide 143

144 Cluster visualization Dashboards Document list and tabs throughout Relativity Pivot Sampling Search panel and search browser Production The following changes occur to existing productions on upgrade: 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. Any staged or errored productions in an environment are set to a status of New and you must restage the production before running. 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. The Production Error field no longer exists on the Production object. Production sets you ran before upgrading to Relativity 9.5 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 functionality, see the Admin guide. Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not automatically 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 Production Data Source object to add or edit production data sources after upgrading to Relativity Any preexisting production fields are converted to a production data source upon upgrade. If you upgrade from Relativity 6.x to Relativity 9.5 and you were previously using the Production Tracker application, review the Production Tracker 9.5 considerations PDF in the Relativity Community. Beginning in , Productions includes an upgrade step to migrate data from the old ProductionInformation schema to the new schema introduced in An upgrade from Relativity 9.x to 9.5 can fail if the workspace you're upgrading already contains a Relativity field with the name Production. You must rename this field. The following section discusses the changes to the Production application on upgrade from Relativity 9.x to Relativity Certain upgrade changes only affect upgrades from Relativity 9.1 or 9.2 to Relativity 9.5, 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: Upgrade Guide 144

145 An upgrade from Relativity 9.x to 9.5 can fail if the workspace you're upgrading already contains a Relativity field with the name Production. You must rename this field. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Placeholder. You must rename this object. An upgrade from Relativity 9.1 to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Production Data Source. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Relativity Color Map. You must rename this object. An upgrade from Relativity 9.2 and below to 9.5 can fail if the workspace you're upgrading already contains a Relativity dynamic object with the name Field Catalog. You must rename this object. If you have a full-text index populating the production upgrade stops. Try upgrading again once the full-text index is finished populating. Relativity deduces the First Bates Value and Last Bates Value for all imported and upgraded productions. If you upgrade from Relativity 9.2 to Relativity 9.5 and you were previously using the Production Tracker application, review the Production Tracker 9.5 considerations PDF in the Relativity Community. Beginning in , Productions includes an upgrade step to migrate data from the old ProductionInformation schema to the new schema introduced in Changes to agents and objects: 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.5 environment. The Markup Set table is converted to the Markup Set dynamic object. The Production Object table is converted to the Production dynamic object. Changes to pre-existing Productions: Any staged or errored productions in an environment are set to a status of New and you must restage the production before running. Productions migrated from Relativity 9.1 and 9.2 receive a legacy placeholder stating, "No Tiff Included For This Record." Productions migrated from Relativity 9.1 to Relativity 9.5 have a data source created containing the production documents for each produced and errored production. 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. The Production Error field no longer exists on the Production object. Upgrade Guide 145

146 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 production. Changes to Production fields and views: On upgrade from 9.2 the Produced Documents field exists in the environment, but the field is not populated. The production document view no longer exists. 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. On upgrade from 9.x to 9.5 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: Users with full permissions to the Production object prior to upgrading to Relativity 9.3 do not automatically 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 Production Data Source object to add or edit production data sources after upgrading to Relativity 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.5. 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:\Windows\Microsoft.NET\Framework64\v \ 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 Relativity admin and service account addresses Relativity includes the Relativity admin and service account users by default. With the Relativity , the default addresses for these accounts have been updated as follows: Upgrade Guide 146

147 Default user Previous address New address Relativity admin Relativity service account Relativity Desktop Client (RDC) Beginning in Relativity , 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 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 with Relativity versions to but you must create a new RDC OAuth2 client to do so. For more information, see the Desktop Client Guide Relativity installer updates For Relativity 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: addresses for the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_ and SERVICEACCOUNT_ parameters that you can set with these 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 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 address during a previous installation, it is overwritten by current address that you entered or by the default address when this parameter is blank. o Use different addresses for the ADMIN_ and SERVICEACCOUNT_ parameters. If you use the same address for both parameters, the installation fails. Passwords for the the Relativity admin and Relativity service accounts - The RelativityResponse.txt file used for the primary SQL server installation includes the ADMIN_PASSWORD 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 address. If you enter a new password but don t update the address, then new password is ignored. For example, if you use an existing or default address, then the password remains unchanged. However, you can change the addresses for the admin and service accounts without updating the password. For more information, see the Relativity Installation and Relativity Upgrade guides. Upgrade Guide 147

148 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: Invariant SQL Server name with an optional port number Relativity SQL Server name with an optional port number EDDSDBO password 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 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. Upgrade Guide 148

149 Required certificates for Relativity Relativity 9.5 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.3. For more information, see Pre-upgrade: Update the default SSL/TLS certificate for CAAT in the Upgrading or installing your Analytics server section Scripts 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. Beginning in , 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 Searching Upon upgrade to , 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 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.5 Documentation site System requirements Windows Server 2008 R2 (64-bit) is no longer compatible with 9.5. Relativity 9.5 is only compatible with Windows Server 2008 R2 (64-bit) w Service Pack 1. As of Relativity , we no longer support Internet Explore (IE) 10. Please upgrade to a compatible version of IE Telemetry After you install Relativity 9.5, complete the steps to enable telemetry in your environment. Telemetry allows you to collect metrics for performance, usage, and billing. For more information, see Telemetry on the Relativity 9.5 Documentation site. Upgrade Guide 149

150 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 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.5 Developers site. Note: For information about recompiling syncs, contact the Client Services team Viewer Relativity uses Oracle Outside In version When you upgrade to Relativity 9.5, 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 Viewer (ActiveX) Beginning in Relativity , you must install Microsoft.NET 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 redistributable, from the Workspace Details tab. You can't use the Relativity viewer with earlier versions of Relativity. Also, earlier versions of the ActiveX viewer aren't compatible with Relativity 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 Viewer (ActiveX and HTML) For users who haven't upgraded their Relativity version since the general release of Relativity 9.2, note that, beginning in the Relativity 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. You can 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. See the Instance Setting Guide to learn more about this new value. Pre the Relativity September 30, 2015 product update: Upgrade Guide 150

151 As of the Relativity September 30, 2015 product update: 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.5 Documentation site. Upgrade Guide 151

152 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 9.5 Documentation site 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 ( Prerequisites for Service Bus 1.1 with TLS 1.2 Support Verify that.net is installed in your environment. You must install.net before you begin upgrading to Service Bus 1.1 with TLS 1.2. This service bus upgrade requires.net For more information, see Upgrading Relativity to.net Verify that you are running Windows Server 2012 or Windows Server 2012 R2, and Microsoft SQL Server If your environment, doesn't meet these requirements, see Workarounds for Service Bus 1.1 with TLS 1.2 on page 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: 1. Remove all servers from the farm. For more information, see Leaving a Farm ( microsoft.com/en-us/library/dn 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 ( on the Microsoft site. 3. Uninstall Microsoft Azure Surface Fabric Upgrade the SQL Server to support TLS 1.2. For more information, see 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. Upgrade Guide 152

153 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 Catalog=SbManagementDB;Integrated Security=True' -CertificateAutoGenerationKey $mycert See the following confirmation message: 8. Rejoin all servers to the farm. For more information, see the Pre-installation Guide 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 2012 or Windows Server 2012 R2, and Microsoft SQL Server 2012 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: Windows Server 2012 and SQL Server 2012 Windows Server 2012 R2 and SQL Server 2016 Windows Server 2016 and SQL Server 2014 Windows Server 2016 and SQL Server 2016 While we aren't aware of any issues on these platforms, we request that you are cautious when deploying the Service Bus 1.1 with TLS 1.2 Support update. 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: Client communication - determines which TLS protocols are used for outbound connections from the server that is traffic to the service bus server. 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 Upgrade Guide 153

154 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 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 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. 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 Worker manager queue Revisions in the queue manager code have led to the following enhancements: A reduction in the volume of connections to the SQL Server A reduction in lock waits and thread pool waits A general increase in queue parallelism 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. Upgrade Guide 154

155 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 the next page. The Worker manager page no longer displays the following conversion fields: pre-convert, conversion onthe-fly, mass conversion, and conversion. Beginning in Relativity , 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 Workspace upgrade queue The Workspace Upgrade Queue includes the following columns: Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Workspace Upgrade Worker agent. The possible values in this column are the same as for the workspace upgrade. This field is empty if you don't have Processing installed. Current Store Version - the version of Invariant you are upgrading to. Upgrade Guide 155

156 3 Configuring your conversion agents Prior to Relativity 9.5, conversion occurred on Invariant workers designated to pick up conversion jobs. In Relativity 9.5 conversion occurs on dedicated conversion agents instead of Invariant workers. Relativity 9.5 uses 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.5. 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.5: On a new installation of Relativity 9.5, Relativity automatically creates one conversion agent and adds it to the default secondary agent server. You should then add the agent server to the appropriate resource pool. For more information, see Resource pools in the Admin guide. On upgrade to Relativity 9.5, 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: 1. Ensure Service Bus for Windows server is installed in the environment. 2. Delete the old worker from the server management page. 3. Uninstall Invariant on the server via Windows Control Panel Add/Remove Programs. Doing this uninstalls existing Invariant applications. Upgrade Guide 156

157 4. Set up a new agent server for conversion agents. For more information, see Infrastructure configuration in the Upgrade guide. 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 dedicated conversion workers If your environment doesn't have any Invariant workers dedicated to conversion, you have two options when setting up conversion for Relativity 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 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: Upgrade Guide 157

158 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 Infrastructure 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 158

159 4 Upgrading your SQL Server Follow these steps to upgrade your primary SQL Server. Before you follow the steps below, you must have completed the required pre-upgrade steps for all Relativity versions. For more information, see Preinstallation 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 The master database called the EDDS resides on the primary SQL Server. You must update the primary database before upgrading any other feature. 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: 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 installation. 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 /responsefilepath=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. RelativityResponse.txt - The text file that determines which components Relativity.exe installs, uninstalls, or upgrades on the server. 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: Upgrade Guide 159

160 Common properties INSTALLPRIMARYDATABASE - Set this value to one. INSTALLPRIMARYDATABASE=1 INSTALLDISTRIBUTEDDATABASE - Verify that this value is set to zero. You can't store the distributed database on the same machine as the primary database. INSTALLDISTRIBUTEDDATABASE=0 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 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 EDDSDBOPASSWORD - Enter the EDDSDBO password. EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME - Enter the service username. The Windows login must already exist. SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD - Enter the Service password. SERVICEPASSWORD=MySecretPassword USEWINAUTH - Set the value to one to use Windows authentication for the SQL Server. USEWINAUTH=1 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. 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. SQLPASSWORD - Enter the SQL password if you want to use SQL Server login authentication. SQLPASSWORD=myPassword Upgrade Guide 160

161 Note: This value is ignored if USEWINAUTH is set to one Primary database properties 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 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 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 available in Relativity and above. For more information, see the Relativity Installation guide. CACHELOCATION=\\yourmachine\ViewerCache 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 permissions. DTSEARCHINDEXPATH=\\yourmachine\dtSearch 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 ADMIN_ - Enter the address that you want to use for the default Relativity admin account. If you don't specify an address, the installer uses the default value of relativity.admin@relativity.com. This parameter is available for and above. ADMIN_ =relativity.admin@relativity.com SERVICEACCOUNT_ - Enter the address that you want to use for the default Relativity service account. If you don't specify an address, the installer uses the default value of serviceaccount@relativity.com. This parameter is available for and above. Notes: o If you want to use a specific 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 address during a previous installation, it is overwritten by current address that you entered or by the default address when this parameter is blank. o Use different addresses for the ADMIN_ and SERVICEACCOUNT_ parameters. If you use the same address for both parameters, the installation fails. Upgrade Guide 161

162 ADMIN_PASSWORD - Enter the password that you want to use for the default Relativity admin account. This parameter is available for and above. ADMIN_PASSWORD=myPassword SERVICEACCOUNT_PASSWORD - Enter the password that you want to use for the default Relativity service account. This parameter is available for and above. SERVICEACCOUNT_PASSWORD=myPassword Note: To change the ADMIN_PASSWORD or SERVICEACCOUNT_PASSWORD password, you must also update the associated address. If you enter a new password but don t update the address, then new password is ignored. For example, if you use an existing or default address, then the password remains unchanged. However, you can change the addresses for the admin and service accounts without updating the password 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. DATABASEBACKUPDIR - Enter the database backup directory. DATABASEBACKUPDIR=C:\Backup LDFDIR - Enter the LDF directory. LDFDIR=C:\Logs MDFDIR - Enter the MDF directory. MDFDIR=C:\Data 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: INSTALLPRIMARYDATABASE=1 INSTALLDIR=C:\Program Files\kCura Corporation\Relativity PRIMARYSQLINSTANCE=ML12 EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD=MySecretPassword DEFAULTFILEREPOSITORY=\\yourmachine\FileShare EDDSFILESHARE=\\yourmachine\Fileshare CACHELOCATION=\\yourmachine\ViewerCache Upgrade Guide 162

163 DTSEARCHINDEXPATH=\\yourmachine\dtSearch RELATIVITYINSTANCENAME=My Relativity Instance ADMIN_PASSWORD=myPassword SERVICEACCOUNT_PASSWORD=myPassword DATABASEBACKUPDIR=C:\Backup LDFDIR=C:\Logs MDFDIR=C:\Data FULLTEXTDIR=C:\FullText USEWINAUTH=1 Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. 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. 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 distributed SQL Server: Common properties INSTALLPRIMARYDATABASE - Set this value to zero. You can't store the distributed database on the same machine as the primary database. INSTALLPRIMARYDATABASE=0 INSTALLDISTRIBUTEDDATABASE - Set this value to one. INSTALLDISTRIBUTEDDATABASE=1 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 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 EDDSDBOPASSWORD - Enter the EDDSDBO password. EDDSDBOPASSWORD=MySecretPassword Upgrade Guide 163

164 SERVICEUSERNAME - Enter the service username. The Windows login must already exist. SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD - Enter the Service password. SERVICEPASSWORD=MySecretPassword USEWINAUTH - Set this to one to use Windows authentication for the SQL Server. USEWINAUTH=1 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. SQLUSERNAME - Enter the SQL username to use SQL Server login authentication. SQLUSERNAME=mySqlUserName Note: This value is ignored if USEWINAUTH is set to one. SQLPASSWORD - Enter the SQL password to use SQL Server login authentication. SQLPASSWORD=myPassword Note: This value is ignored if USEWINAUTH is set to one Distributed database properties DISTRIBUTEDSQLINSTANCE - Enter the Distributed SQL instance. You can't store the distributed database on the same machine as the primary SQL Server. DISTRIBUTEDSQLINSTANCE=ML 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. DATABASEBACKUPDIR - Enter the database backup directory. DATABASEBACKUPDIR=C:\Backup LDFDIR - Enter the LDF directory. LDFDIR=C:\Logs MDFDIR - Enter the MDF directory. MDFDIR=C:\Data Upgrade Guide 164

165 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 response file for a distributed SQL database upgrade using Windows authentication looks like this: INSTALLDISTRIBUTEDDATABASE=1 INSTALLDIR=C:\Program Files\kCura Corporation\Relativity PRIMARYSQLINSTANCE=ML12 EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD=MySecretPassword DISTRIBUTEDSQLINSTANCE=ML14 DATABASEBACKUPDIR=C:\Backup LDFDIR=C:\Logs MDFDIR=C:\Data FULLTEXTDIR=C:\FullText USEWINAUTH=1 Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. Upgrade Guide 165

166 5 Removing RabbitMQ Beginning in Relativity , 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 : Data Grid Error Queue Manager Data Grid Install Queue Manager Data Grid Process Queue Manager Data Grid Status Queue Manager 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 ' localhost:15672/api/queues' % { ConvertFrom-Json $_.Content } % { $_ }? { $_.messages -eq 0} % { iwr -method DELETE -Credential $cred -uri $(" -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 166

167 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 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. Remove -whatif when ready to run. 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. Remove -whatif when ready to run. Delete the file C:\Windows\.erlang.cookie and C:\Users\relativityserviceaccount\.erlang.cookie. 7. Restart your machine. 5.4 Closing ports on the Queue Server Close the following ports on the queue server: Upgrade Guide 167

168 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. Save the following files to the root directory of any server contributing to the Relativity environment: 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 installation. 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 /responsefilepath=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. RelativityResponse.txt - The text file that determines which components Relativity.exe installs, uninstalls, or upgrades on the server. Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. Upgrade Guide 168

169 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: Feature selection 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 Common properties 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 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 EDDSDBOPASSWORD - Enter the EDDSDBO password. EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME - Enter the service username. The Windows login must already exist. SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD - Enter the service password. SERVICEPASSWORD=MySecretPassword USEWINAUTH - Set this to 1 to use Windows authentication for the SQL Server. USEWINAUTH=1 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. Upgrade Guide 169

170 SQLUSERNAME - Enter the SQL username to use SQL Server login authentication. SQLUSERNAME=mySqlUserName Note: This value is ignored if USEWINAUTH is set to one. SQLPASSWORD - Enter the SQL password to use SQL Server login authentication. SQLPASSWORD=myPassword Note: This value is ignored if USEWINAUTH is set to one. Save your edits to the RelativityResponse.txt file, and launch the Install.bat file to proceed with the installation. A sample response file for a service bus only installation looks like this: INSTALLSERVICEBUS=1 INSTALLDIR=C:\Program Files\kCura Corporation\Relativity PRIMARYSQLINSTANCE=ML12 EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD=MySecretPassword USEWINAUTH=1 Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. 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: Missing an FQDN - insert a row with the FQDN into the table. See the following sample command: Upgrade Guide 170

171 INSERT INTO EDDS.eddsdbo.ServiceBusHosts Values('<FQDN of the host>') Incorrect host name - execute an UPDATE statement to add the correct FQDN for the host. 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: In the RelativityResponse.txt file, ensure that you set the INSTALLSERVICEBUS property to 1 before you run the installer. Verify that the following instance settings contain the correct values: o ServiceBusFullyQualifiedDomainName o o ServiceBusHttpPort ServiceBusTcpPort Note: For more information, see the Instance Setting guide. 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 171

172 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 Contact Relativity Client Services to get a copy of the Relativity installer. Save the following files to the root directory of any server contributing to the Relativity environment: 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 installation. 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 /responsefilepath=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. RelativityResponse.txt - The text file that determines which components Relativity.exe installs, uninstalls, or upgrades on the server. Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. To upgrade the agent server: 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 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 172

173 Common properties 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. INSTALLDIR=C:\Program Files\kCura Corporation\Relativity 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 EDDSDBOPASSWORD - Enter the EDDS database object password. EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME - Enter the service username. The Windows login must already exist. SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD - Enter the service password. SERVICEPASSWORD=MySecretPassword USEWINAUTH - Set this to one to use Windows authentication for the SQL Server. USEWINAUTH=1 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. SQLUSERNAME - Enter the SQL username to use SQL Server login authentication. SQLUSERNAME=mySqlUserName Note: This value is ignored if USEWINAUTH is set to one. SQLPASSWORD - Enter the SQL password to use SQL Server login authentication. SQLPASSWORD=myPassword Note: This value is ignored if USEWINAUTH is set to one. 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 agents only upgrade looks like this: INSTALLAGENTS=1 INSTALLDIR=C:\Program Files\kCura Corporation\Relativity Upgrade Guide 173

174 PRIMARYSQLINSTANCE=ML12 EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD=MySecretPassword Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. 7.2 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.5 Documentation site. Upgrade Guide 174

175 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.5 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. Contact Relativity Client Services to get a copy of the Relativity installer. Save the following files to the root directory of any server contributing to the Relativity environment: 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 installation. 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 /responsefilepath=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. RelativityResponse.txt - The text file that determines which components Relativity.exe installs, uninstalls, or upgrades on the server. Upgrade Guide 175

176 Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. 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: Common properties 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. 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. INSTALLDIR=C:\Program Files\kCura Corporation\Relativity 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 EDDSDBOPASSWORD - enter the EDDS database object password. EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME - enter the service username. The Windows login must already exist. SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD - enter the service password. SERVICEPASSWORD=MySecretPassword USEWINAUTH - set this to one to use Windows authentication for the SQL Server. USEWINAUTH=1 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. Upgrade Guide 176

177 SQLUSERNAME - enter the SQL username to use SQL Server login authentication. SQLUSERNAME=mySqlUserName Note: This value is ignored if USEWINAUTH is set to one. SQLPASSWORD - enter the SQL password to use SQL Server login authentication. SQLPASSWORD=myPassword Note: This value is ignored if USEWINAUTH is set to one. 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 INSTALLDIR=C:\Program Files\kCura Corporation\Relativity PRIMARYSQLINSTANCE=ML12 EDDSDBOPASSWORD=MySecretPassword SERVICEUSERNAME=example\exampleusername SERVICEPASSWORD=MySecretPassword Note: Every line in the RelativityResponse.txt file that starts with ### is a comment and meant to provide instruction. 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 dashboard. 3. Double-click the Machine Key icon. 4. Update the following fields for your version of Windows server: 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 177

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

179 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.5 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: Update all servers to use Windows Authentication. Upgrade Guide 179

180 UPDATE EDDS.eddsdbo.InstanceSetting SET value = 'True' WHERE Name = 'UseWindowsAuthentication' 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' 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 servers 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 Windows Authentication. Replace YourSecondServerName with the name of that machine. INSERT INTO EDDS.eddsdbo.InstanceSetting VALUES ('Relativity.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 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.5 Documentation site. 8.5 SignalR 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 180

181 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. Upgrade Guide 181

182 9 Upgrading Relativity to.net As of Relativity , you must upgrade your Relativity environment to.net The updates must be applied to Relativity servers and client machines. Note: Existing custom applications are backward-compatible with Relativity and do not need to be recompiled, but you must upgrade your development environment to use the latest versions of Relativity SDKs. 9.1 All servers Perform these steps on all servers in your Relativity environment: 1. Download the.net installer from download/details.aspx?id=53344.the downloaded file name is NDP462-KB x86-x64- AllOS-ENU.exe. 2. Run the NDP462-KB 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. 9.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 Redistributable already installed, download it from download provides both 32- and 64-bit options. Select an executable depending on your system word size. 2. Run the Microsoft Visual C Redistributable executable and follow the instructions in the installation wizard. 3. Download the.net installer from download/details.aspx?id=53344.the downloaded file name is NDP462-KB x86-x64- AllOS-ENU.exe. 4. Run the NDP462-KB x86-x64-AllOS-ENU.exe executable and follow the instructions in the installation wizard. 5. Turn off applications when prompted by the installation wizard. 6. Restart the machine on completion. 7. Download and install the latest versions of ActiveX viewer, RDC, and RPC. Upgrade Guide 182

183 9.3 Relativity applications Backward-compatible applications Going forward, regardless of current Relativity version, if you install new.net based versions of backward-compatible Relativity applications, you must upgrade your environment to.net as described above. Backward-compatible applications include Data Grid, ARM, Relativity User Import, etc 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 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 The developers must also update their environment to the.net Developer Pack as described below. 9.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 Developer Pack from microsoft.com/en-us/download/details.aspx?id= The file name is NDP462-DevPack- KB ENU.exe. 2. Run the NDP462-DevPack-KB ENU.exe executable and follow the instructions in the installation wizard. 3. Turn off applications when prompted by the installation wizard. 4. Restart the machine on completion. Upgrade Guide 183

184 10 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 version Relativity version Invariant 3.0 Relativity 7.5 Invariant 3.1 Relativity 8.0 Invariant 3.2 Relativity 8.1 Invariant 3.3 Relativity 8.2 Invariant 4.0 Relativity 9.0/9.1 Invariant 4.2 Relativity 9.2 Invariant 4.3 Relativity 9.3 Invariant 4.4 Relativity 9.4 Invariant 4.5 Relativity 9.5 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 Upgrade considerations for Relativity Beginning in Relativity , the following changes have been made to processing and should be noted prior to upgrade: You can now host Invariant Kepler services in HTTPS if you install a certificate on the queue manager. Note that the default port for the Invariant Kepler services is For details, see Enabling HTTPS for Invariant Kepler Services. Upgrade Guide 184

185 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-installation Guide in the Pre-installation topic. Invariant stores are now deleted automatically when the Relativity workspaces associated with them are deleted. For more information, see The Relativity Processing Console Guide. 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 allowing 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 moving on. Note the upgrade-relevant details regarding distributed publish: o The following instance settings have been added to facilitate the work of distributed publish. ProcessingMaxPublishSubJobCountPerRelativitySQLServer - the maximum number of publish jobs per Relativity SQL server that may be worked on in parallel. 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. 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. This updates on a 30-second interval. 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. ProcessingMaxPublishSubJobCountPerWorkspace- the maximum number of publish jobs per workspace that may be worked on in parallel. 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 higher than the value for the MaxPublishJobCountPerRelativitySQLServer instance setting, then Relativity 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. The default value is 3. 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. This updates on a 30-second interval. 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 Upgrade Guide 185

186 o 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. The ProcessingExportMaxThreads instance setting has been deprecated in accordance with the addition of the ProcessingMaxPublishSubJobCountPerWorkspace and ProcessingMaxPublishSubJobCountPerRelativitySQLServer instance settings, which facilitate the work of distributed publish. The following table provides the recommended values for each instance setting per environment setup: Environment setup Tier 1 (see the System Requirements Guide for details) Tier 2 (see the System Requirements Guide for details) RelativityOne baseline ProcessingMaxPublishSubJobCountPerWorkspace ProcessingMaxPublishSubJobCountPerRelativitySQLServer Hosting Invariant Kepler services in HTTPS Beginning in Relativity , if you want to host Invariant Kepler services in HTTPS, you must complete the following steps: 1. Set the EnforceHttps instance setting to On. This will ensure that the QueueManager service attempts to start the Kepler Services in HTTPS after you create the self-signed certificate. 2. Create a self-signed certificate on the QueueManager with the following specifications. See the Preinstallation Guide for the instructions for creating a self-signed certificate in PowerShell. Install the certificate to both the Personal and Trusted Root Certification Authorities certificate stores for the Computer Account on the Queue Manager server. The port that the certificate is bound to is specified in the C:\Program Files\kCura Cor- Upgrade Guide 186

187 poration\invariant\queuemanager\settings\appsettings.config under the ApiPort value. The default port for the Invariant Kepler services is Restart the Queue Manager. Upon initialization, the Queue Manager attempts to automatically configure HTTPS and select the certificate, assuming that the EnforceHTTPS is set to On. Specifically, the Queue Manager does the following: It opens the Personal store for the Computer Account and look for an exact host name match. The host name comes from the fully qualified domain name of the QM server. If there is no exact host name match, it queries the store for all valid certificates and use the one with the largest encryption key. If there are no valid certificates, it looks for a wildcard certificate that would work. If there are no valid wildcard certificates and the scheme is set to HTTPS, it logs an exception. To override the default automatic certificate selection behavior, add the SslCertificateThumbprint instance setting for the server to explicitly specify the certificate to use. Name SslCertificateThumbprint Section kcura.service.servicehost MachineName - the machine name entered in the Invariant AppSettings table. When Relativity searches for the existence of the thumbprint setting, it looks up the machine name in the Invariant AppSettings table (where Category = "QueueManager" and the SubCategory = NULL) and looks for the thumbprint instance setting for this particular machine name. Value the thumbprint of the certificate for SSL bindings. For instructions on retrieving the thumbprint, see o Make sure to copy the Thumbprint certificate field when retrieving the thumbprint value (it's easy to confuse with the Serial number field). o o The thumbprint value must not include spaces (when you copy-paste it from the Windows certificate form, it does includes spaces). You must also remove the leading space because it contains an illegal character that can't be matched when the certificate is retrieved from the store. You likely have different certificates for different machines. To configure the certificate for HTTPS bindings for each machine, use the MachineName field of the instance setting Upgrade considerations for Relativity Beginning in Relativity , you can use the Invariant.Handlers installer to update only the file handlers in your Invariant instance without having run the entire installer. Note that this is available for upgrades only. For details, see the Worker Manager Installation guide. Upgrade Guide 187

188 10.3 Upgrade considerations for Relativity The following changes were made to the worker manager server installation process beginning in Relativity and should be noted prior to upgrading: 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 network share that doesn t contain any data. 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 Invariant.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. 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 (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 Upgrade exceptions For upgrades from Relativity 8.0/Invariant 3.1 or lower, 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 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 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. Upgrade Guide 188

189 Required Microsoft Visual C++ version (Redistributable x86 and x64) Relativity/Invariant version /4.3 (all monthly versions included) 9.4/4.4 (all monthly versions included) / / / / / / / Upgrading the Invariant Database and Queue Manager You'll use the same installation files you used to install the Invariant Database and 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 Database or Queue Manager. Note: If you have an alternative configuration where the Invariant Database and the Queue Manager are on separate servers, you must upgrade the database first. However, this type of configuration is not recommended. Upgrade Guide 189

190 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 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 , 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 192. (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 193. 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 190

191 For configuration information, see Running the Relativity installer and Agents on the Relativity 9.5 Documentation site 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: 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. Workspace Upgrade Manager - queues applications required for installation in workspaces. Application Installation Manage- installs required applications to workspaces. For more information about agents, see Agents on the Relativity9.5 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 Workspace 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 Completed. 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. Upgrade Guide 191

192 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 Workspace Upgrade queue columns The Workspace Upgrade queue displays the following columns: Artifact ID - the Artifact ID of a workspace undergoing an upgrade. Workspace Name - the name of a workspace undergoing an upgrade. Click the name to display the document list in the workspace. 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. Upgrade Status - the status of the workspace upgrade as determined by the current Procuro stage. See Upgrade statuses descriptions on the next page. Workspace UpgradeStatus - the value assigned to the Status field on the workspace details page. See Upgrade statuses descriptions on the next page. Current Relativity Version - the workspace is currently updated to this version of Relativity. Store Upgrade Status - the status of the upgrade of the Invariant store, as completed by the Workspace Upgrade Worker agent. The possible values in this column are the same as for the workspace upgrade. This field is empty if you don't have processing installed. You could see any of the following status values: Status Pending Upgrading Scripts Completed Failed Script Upgrade Canceled NULL What it means The Invariant store have been added to the Workspace Upgrade queue, but the Workspace Upgrade Worker hasn t picked it up yet. The Workspace Upgrade Worker agent is running scripts against the Invariant store. The store is fully upgraded and ready for use. An error occurred while upgrading SQL scripts for the Invariant store, the upgrade failed, and Relativity Processing is disabled in the workspace. 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 197. A Store has not been created on this workspace 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 displays the version you just upgraded to, which is the most current. Upgrade Guide 192

193 Database Upgrade Progress - the percentage of the upgrade process completed for the workspace database and the Invariant database if the Processing application is installed. It uses the following colors to indicate the upgrade status: o Blue - indicates the upgrade is in progress. o o Green - indicates a completed upgrade. Red - indicates an error or failure occurred. Application Upgrade Progress - the percentage of the upgrade process completed for the application. It uses the same colors to indicate the upgrade status as the Database Upgrade Progress bar Upgrade statuses descriptions The following table contains descriptions for the statuses displayed in the Upgrade Status column on the Workspace Upgrade queue: Status Canceled Completed Failed Application Upgrade Failed Script Upgrade Pending Pending Application Upgrade Upgrading Applications Upgrading Scripts Description 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 197. The upgrade of the workspace completed successfully. An error occurred while upgrading applications in the workspace. See Troubleshooting upgrades on the next page. An error occurred while upgrading SQL scripts for the workspace. See Troubleshooting upgrades on the next page. The workspace has been added to the Workspace Upgrade queue, but the Workspace Upgrade Worker hasn t picked it up yet. The Workspace Upgrade Manager populates the application installation queue with any required applications. The Application Installation Manager upgrades the applications in the workspace. The Workspace Upgrade Worker runs Procuro scripts against the workspace database 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. Upgrade Guide 193

194 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 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: To set the priority for only a specific group of workspaces, select their checkboxes. In the mass operations bar, choose Checked. 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: Select the Priority checkbox. Choose Low, Medium, or High from the drop-down menu. 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 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: Upgrade Guide 194

195 Viewing upgrade errors Canceling or retrying workspace upgrades 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 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. 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. Upgrade Guide 195

196 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 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: Locking conflicts - Click the Failed Application Upgrade link to display the detailed error message. Select the Unlock <Application Name> checkbox, and click Retry Import on the error message. Naming conflicts - Click the Failed Application Upgrade link to display the detailed error message. 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.5 Developers site. Upgrade Guide 196

197 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: To retry or cancel the upgrade jobs for only a specific group of workspaces, select their checkboxes. In the mass operations bar, choose Checked. To retry or cancel the upgrade jobs for all workspaces, choose All Items in the mass operations 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 197

198 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.5 on page 17. An upgrade of your Analytics server is required for Relativity 9.5. 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: Installing / Upgrading Relativity Analytics below o Installing Analytics for the first time to Relativity and above on the next page o Installing Analytics for the first time to Relativity or prior on page 204 o Upgrading from Relativity (CAAT 3.19) and above on page 207 o Upgrading from Relativity (CAAT 3.17) or prior on page 211 Updating the default SSL/TLS certificate on page 217 Disabling TLS 1.0 and 1.1 (optional) on page 224 Installing Analytics server when SQL Server uses SSL encryption on page 225 Changing the REST password on page 226 Uninstalling the Relativity Analytics server on page Installing / Upgrading Relativity Analytics You need the following items in order to successfully run the Relativity Analytics upgrade or installation: 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 225 before beginning the Analytics server installation. The Relativity Service Account username and password. All SQL Servers must be active and accessible at the time of the installation. 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 217. We do not recommend self-signed certificates. Upgrade Guide 198

199 Note: 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 , the Windows Service will be called Content Analyst CAAT. In Relativity and higher, 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 downtime spent to fix the problem. This section contains the following content: Installing Analytics for the first time to Relativity and above below Installing Analytics for the first time to Relativity or prior on page 204 Upgrading from Relativity (CAAT 3.19) and above on page 207 Upgrading from Relativity (CAAT 3.17) or prior on page Installing Analytics for the first time to Relativity and above Setting properties in the response-file.properties file (Relativity and above) 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. We recommend using the default folder of C:\CAAT (or C:\ContentAnalyst for a legacy installation). This path must be absolute, and it can t contain spaces or invalid characters. 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. 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. Upgrade Guide 199

200 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. We recommend that you not keep the index directory on the C: drive due to the size requirements. 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. 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. This path must be absolute, and it can t contain spaces, invalid characters, or any Unicode. This value is ignored upon upgrade. caat.single-data-dir= E:/AnalyticsData caat.single-data-dir= E:\\AnalyticsData caat.single-data-dir= //servername/analyticsdata Upgrade Guide 200

201 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 226. 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. Upgrade Guide 201

202 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 back slash, as shown in the examples below. 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 217. 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 Analytics installer considerations (Relativity and above) Note the following before running the Relativity Analytics Server Installer: Run the server setup as the Relativity Service Account. You must have system admin rights to both the Analytics server and the index share path in order to run the installer without interruption Running the Install.cmd file (Relativity and above) 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, lsiapp.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 Upgrade Guide 202

203 specifications 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 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: 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 Analytics installer. If you enter the information correctly, you can successfully save the server. If you receive a not found error on the server, make sure the Analytics service is running and that you used the correct port. 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., Logging (Relativity and above) 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). Upgrade Guide 203

204 The log pattern for each log message is described below: [log-level] [date] [thread-name] message (e.g., [INFO] [ :05:54 [main]: Loading installation options) Note: Log messages will be appended to the same log file on subsequent runs Installing Analytics for the first time to Relativity or prior Analytics installer considerations (Relativity or prior) When you run the Relativity Analytics Server Setup wizard, the wizard automatically: Installs the CAAT service Deploys the Relativity library files 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. Allows you to set an index path on new install, thus eliminating the need to manually set the location of indexes 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 server setup as the Relativity Service Account. You must have system admin rights to both the Analytics server and the index share path in order to 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. Note: If a "Could not configure security for the following directories" warning occurs during your Analytics installation or upgrade, see on page Running the Relativity Analytics Server Setup wizard (Relativity 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: 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. 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. Upgrade Guide 204

205 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>. 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 information, see Servers in the Admin Guide. REST Port - the port that the REST API will use via https. By default, this setting uses port 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. 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. 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 nondefault 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: 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 o This path must be absolute, and it can t contain spaces or invalid characters. If the installer can't find or access the location you specify, it installs the application to the default C:\CAAT folder. 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. Analytics Server Port Number - the port number of the Analytics server. The default port is 8080, but you can configure a different port number. Analytics Index Directory - the directory where indexes and structured analytics sets are stored on disk. Upgrade Guide 205

206 o o o o o We recommend that you not keep the index directory on the C: drive due to the size requirements. 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. 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. This path must be absolute, and it can t contain spaces, invalid characters, or any Unicode. 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. 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 complete. 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. 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 (Optional) Confirm that all components of the Analytics service are running by visiting 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. Upgrade Guide 206

207 11. If this is a new Analytics server, add it to the Servers list. For these steps, see Adding an Analytics 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. If you enter the information correctly, you can successfully save the server. If you receive a not found error on the server, make sure the Analytics service is running and that you used the correct port. If you get an unauthorized error, make sure that you entered the credentials correctly. Content Analyst is now installed in your environment Upgrading from Relativity (CAAT 3.19) and above Setting properties in the response-file.properties file (for upgrading to Relativity or above) Before upgrades or new installations, unzip the Analytics package and open the responsefile.properties file in a text editor. For upgrades, only the following settings are considered: caat.install-dir caat.upgrade-now caat.license-file caat.http-user caat.http-password Upgrade Guide 207

208 For a complete list of settings and descriptions, see Installing Analytics for the first time to Relativity and above on page 199. 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. We recommend using the default folder of C:\CAAT (or C:\ContentAnalyst for a legacy installation). This path must be absolute, and it can t contain spaces or invalid characters. 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. 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 Upgrade Guide 208

209 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 Analytics installer considerations (for upgrading to Relativity or above) Note the following before running the Relativity Analytics Server Installer: Run the server setup as the Relativity Service Account. You must have system admin rights to both the Analytics server and the index share path in order to run the installer without interruption Running the Install.cmd file (Relativity or above) 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, lsiapp.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 specifications 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 Upgrade Guide 209

210 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 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: 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 Analytics installer. If you enter the information correctly, you can successfully save the server. If you receive a not found error on the server, make sure the Analytics service is running and that you used the correct port. 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., Logging (Relativity and above) 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: Upgrade Guide 210

211 [log-level] [date] [thread-name] message (e.g., [INFO] [ :05:54 [main]: Loading installation options) Note: Log messages will be appended to the same log file on subsequent runs Upgrading from Relativity (CAAT 3.17) or prior Note: If you are upgrading from Relativity (CAAT 3.17) or lower, first run the Relativity 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 (CAAT 3.19) and above on page 207) Analytics installer considerations (for upgrading to Relativity or prior) When you run the Relativity Analytics Server Setup wizard, the wizard automatically: Installs the CAAT service Deploys the Relativity library files 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. Allows you to set an index path on new install, thus eliminating the need to manually set the location of indexes 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 server setup as the Relativity Service Account. You must have system admin rights to both the Analytics server and the index share path in order to 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. Note: If a "Could not configure security for the following directories" warning occurs during your Analytics installation or upgrade, see on page Running the Relativity Analytics Server Setup wizard (Relativity 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: 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. Upgrade Guide 211

212 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. 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>. 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 information, see Servers in the Admin Guide. REST Port - the port that the REST API will use via https. By default, this setting uses port 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. 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. 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 nondefault 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: 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 o This path must be absolute, and it can t contain spaces or invalid characters. If the installer can't find or access the location you specify, it installs the application to the default C:\CAAT folder. 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. Analytics Server Port Number - the port number of the Analytics server. The default port is 8080, but you can configure a different port number. Upgrade Guide 212

213 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 o o 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. 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. This path must be absolute, and it can t contain spaces, invalid characters, or any Unicode. 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. 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 complete. 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. 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 (Optional) Confirm that all components of the Analytics service are running by visiting 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. Upgrade Guide 213

214 11. If this is a new Analytics server, add it to the Servers list. For these steps, see Adding an Analytics 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. If you enter the information correctly, you can successfully save the server. If you receive a not found error on the server, make sure the Analytics service is running and that you used the correct port. If you get an unauthorized error, make sure that you entered the credentials correctly. Content Analyst is now installed in your environment 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. 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 directory). Upgrade Guide 214

215 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 permissions on this folder. 6. If the index directory is different from the default (i.e. on another drive or share), ensure the Relativity 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 Upgrading clusters for CAAT and higher from Relativity 9.1 or prior Note: The instructions in this section are only necessary when upgrading from Relativity 9.1 or below. Relativity installs CAAT which includes clustering performance improvements. You must upgrade your existing clusters if they were created using a version of CAAT previous to To upgrade your clusters, use one of the following upgrade methods: Run Create Cluster Upgrade Jobs script below Upgrade clusters on the fly on page 217 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 215

216 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 216

217 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 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 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 (CAAT 3.17) or lower. 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 217

218 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. If it does not, you must either purchase a new certificate or generate a self-signed certificate 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 certificate). 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 ) 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 ). 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 218

219 C:\CAAT\jdk1.8.0_144\bin\keytool.exe -list -keystore C:\CAAT\etc\ssl\server.keystore -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 certificate to be deleted is contentanalyst. 6. To delete the default CAAT certificate, run 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. C:\CAAT\jdk1.8.0_144\bin\keytool.exe -delete -keystore <<PathToKeystore>> -alias contentanalyst ) 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 <<hostname>> 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., CE B02DE058C9CB2C0E64AD79DAFB18CF4). 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 <<pfxcertfilepath>> with the destination filepath for the pfx certificate that will be generated): Upgrade Guide 219

220 Export-PfxCertificate -cert cert:\localmachine\my\<<thumbprint>> -FilePath <<pfxcert-filepath\filename.pfx>> -Password $pwd Example: Export-PfxCertificate -cert cert:\localmachine\my\d660e83a0e84653f27c3d1a9bdffb e92e - 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. Import the self-signed certificate into the keystore. See Importing a certificate (trusted or selfsigned). 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: 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 ). This value is found in the naming of the CAAT install directory. 1. Run the following command from the Analytics server: <PathToKeystore> - this is the file path to the keystore. To find this path, open start.ini and look for the jetty.keystore value. C:\CAAT\jdk1.8.0_25\bin\keytool.exe -genkey -keyalg RSA -alias selfsigned -keystore <<PathToKeystore>> -storepass caat4me -validity 360 -keysize 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.crt -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: Analytics servers Agent servers Primary and distributed SQL servers Web servers Upgrade Guide 220

221 To do so, complete the following: a. Navigate to the endpoint for the CAAT certificate ( 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 ) 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: 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 ). This value is found in the naming of the CAAT install directory. 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 <DestinationPassword> 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. <PathToKeystore> - this is the file path to the keystore. To find this path, open start.ini and look for the jetty.keystore value. C:\CAAT\jdk1.8.0_144\bin\keytool.exe -importkeystore -srckeystore <<Certificate>> -srcstorepass <<CertPassword>> -srcstoretype pkcs12 -destkeystore <<PathToKeystore>> -destkeypass <<DestinationsPassword>> -deststoretype JKS Upgrade Guide 221

222 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 C:\CAAT\etc\ssl\server.keystore -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.5, 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 jetty.keystore.password jetty.keymanager.password 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 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. 7. Depending on whether you have a trusted certificate or a self-signed certificate, proceed as follows: If you are using a trusted certificate, you can proceed directly to Verifying the Analytics server in Relativity. If you are using a self-signed certificate, proceed to step 8. Upgrade Guide 222

223 8. If you have imported a self-signed certificate, import the certificate to the Trusted Root of the following additional servers: Analytics servers Agent servers Primary and distributed SQL servers Web servers To do so, follow these instructions: a. Navigate to the endpoint for the CAAT certificate ( 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.: ) 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: 1. Verify that you 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., 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: (For versions of Relativity prior to , use this format: 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. Upgrade Guide 223

224 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. e. Click Run Script. 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 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> <!-- =========================================================== --> <!-- Create a TLS specific HttpConfiguration based on the --> <!-- common HttpConfiguration defined in jetty.xml --> 3. Restart the Content Analyst (CAAT) Windows service. 4. Update the registry key on all web and agent servers: 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\v ] "SchUseStrongCrypto"=dword: [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v ] "SchUseStrongCrypto"=dword: b. Restart IIS or the agent service on each applicable server. Upgrade Guide 224

225 5. Verify that the connection works by clicking Save in the Analytics Server layout 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: The SQL Server's certificate is installed in the Analytics server KeyStore. See Install a SQL Server certificate in the Analytics server KeyStore below 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 below 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. Note: This step is only required if your Java KeyStore is password protected. Please refer to Oracle for default Java password information 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. Upgrade Guide 225

226 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 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 Changing the REST password Changing the REST password for Relativity and above: 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. 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. Changing the REST password for versions of Relativity previous to If you need to change the REST password, perform the following steps: 1. Rerun the Analytics installer and enter the new password in the REST Password field. 2. Go to the Servers tab in Relativity select the Analytics server. 3. Enter the new password in the now-optional REST API password field and click Save 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 higher 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 higher become unusable. Upgrade Guide 226

227 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 higher unusable. If you still need to uninstall the Relativity Analytics components from the server, complete the following steps: Uninstall Relativity Analytics for Relativity and newer: 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 Windows service. 5. If desired, delete the Analytics installation directory (e.g., C:\CAAT) and the index directory associated with Analytics. Note: Any structured analytics sets created in Relativity 8.2 and above are no longer usable. Uninstall Relativity Analytics for Relativity and prior: 1. Click your Start menu. 2. Select Add or remove programs. 3. Right-click on Relativity Analytics Server and select Uninstall. Uninstalling the Relativity Analytics server automatically: Removes the version key from the registry Unregisters the Windows Service Note: When you uninstall Relativity Analytics server, the indexes aren't deleted. However, any structured analytics sets created in Relativity 8.2 and higher are no longer usable. Upgrade Guide 227

228 13 Upgrading Data Grid The Data Grid Core and Audit applications are updated automatically with Relativity. If you are upgrading to Relativity 9.5 and your environment uses Elasticsearch or below to store audits or search via Lucene search, you must upgrade to Elasticsearch or above when upgrading to Relativity 9.5. Once you upgrade to Elasticsearch , you're unable to use your Elasticsearch clusters with or have a partially upgraded cluster. Before upgrading to Relativity , 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. Upon upgrade, Lucene search is disabled by default. If you want to use Lucene search, you must install Elasticsearch and configure the DataGridSearchIndex instance setting 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 Once you connect to the endpoint, the following page appears which displays, among other things, your Elasticsearch version number. Upgrade Guide 228

229 13.2 Upgrading from Elasticsearch to x If your environment uses Elasticsearch to store audits or search via Lucene search, you must upgrade to Elasticsearch or above when upgrading to Relativity 9.5. Once you upgrade to Data Grid x, you're unable to use your Data Grid clusters with or have a partially upgraded cluster. In order to upgrade Elasticsearch from to x, complete the following workflow: Click to expand instructions for upgrading Elasticsearch. If your environment uses Elasticsearch, you must also upgrade to Elasticsearch or above when upgrading to Relativity 9.5. Once you upgrade to Elasticsearch x, you're unable to use your Elasticsearch clusters with or have a partially upgraded cluster. In order to upgrade Elasticsearch from to x, complete the following workflow: Prepare the environment for upgrade. For more information, see Preparing the environment for upgrade below. 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. 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 Preparing the environment for upgrade Before upgrading Elasticsearch, perform the following: 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. Verify that no reads or writes to Elasticsearch occur during the upgrade process. Disable all Audit migration and deletion agents. Disable all Text migration and deletion agents. Verify that all imports or publishing from Processing have stopped. 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. If you are also upgrading Java versions, open the command prompt and run the following command. This example assumes you are upgrading to Java 8 Update 45 (64-bit). Edit the version number appropriately. SETX /M KCURA_JAVA_HOME "C:\Program Files\java\jdk1.8.0_45" 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. Upgrade Guide 229

230 PUT _cluster/settings { "persistent":{"cluster.routing.allocation.enable": "none"} } o Run the following command to perform a synced flush: POST /_flush/synced 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: datagrid install.zip elasticupgrade.ps1 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: UpgradeFile - enter the file path to the upgrade package. CurrentPath - enter the current location of the installed Elasticsearch service. Url - enter the URL of the local machine's Elastic endpoint. UserName - (optional) enter the service user name that has access to SQL. Password - (optional) enter the password for the server user. 2. Run elasticupgrade.ps Verifying the upgrade After you upgrade all of the nodes on your cluster, complete the following on the cluster to complete the upgrade: Upgrade Guide 230

231 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: PUT _cluster/settings { "persistent":{"cluster.routing.allocation.enable": "all"} } You can monitor the indexes by running the following in Sense: 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: GET _cat/recovery?&v 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 Running a manual upgrade Click to expand instructions on how to run a manual Elasticsearch upgrade In order to upgrade Elasticsearch from to x, complete the following workflow: Prepare the environment for upgrade. For more information, see Preparing the environment for upgrade on page 229. Upgrade your data, master, and client nodes in that order. For more information, see Upgrading a node on the next page. Verify your upgrade completed successfully. For more information, see Verifying the upgrade on page 235. Upgrade Guide 231

232 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 directory in the RelativityDataGrid folder. 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: Initial memory pool Maximum memory pool Upgrade Guide 232

233 Thread stack size 3. Remove the service:.\kservice.bat remove 4. Delete the old lib, bin, sqlauth, modules, and plugin folders from \RelativityDataGrid\elasticsearch-main. Copy the lib, bin, sqlauth, modules, and plugin folders from the Elastic 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: Upgrade Guide 233

234 custom: type: kcurabearerrealm order: 0 publicjwksurl: 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: Initial memory pool Maximum memory pool Thread stack size b. Select the the Log On tab. In the Log on as setting, select This account. Enter a valid Upgrade Guide 234

235 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 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 235