

Relativity services defined within the Relativity.Services application and other applications, such as
The following diagram illustrates how the Service Host Manager is used by Relativity productions:
When you use Relativity productions, the browser user interface calls the services, for example, to create, update, or run productions. If the Service Host Manager is down, you can't interact with productions.
You can view the services associated with a Relativity application using the Resource Files tab. The following example displays the services in the Relativity.Productions.Services.dll.
The services running in the Service Host Manager are hosted as individual processes. Each of these services execute as a separate instance of Relativity.Platform.Service.exe, resulting in improved stability, and greater ease in identifying services that have failed. To minimize downtime experienced by Relativity users, the Service Host Manager now attempts to restart a failed service up to three times, rather than require a full restart of the service host.
To determine the application service running in a process, open the Task Manager, then select the Details tab, and view the Command line column. You may need to right-click on the column headings and then select the Command line column to display it.
You can prevent services from starting by listing them in the ServiceHostExclusionList instance setting. If you add a GUID for a service to this list while the Service Host is running, the service shuts down dynamically. Similarly, if you remove a GUID, the service starts dynamically. Do not suspend required services unless Customer Success or Relativity engineers advise you to do so.
In certain network environments, it may be necessary to customize port settings for the Service Host Manager:
Value - specify the port number to use
Note: The range value must be pipe-delimited (20000|30000). You can look up the port number assigned to a specific service in the EDDS.ApplicationServiceLocation table.
Follow these steps to enable HTTPS for the Service Host Manager:
Note: The values of KeplerServicesUri and KeplerServicesUriForAgents for HTTPS URIs must match the SSL certificate address, so they cannot use localhost or 127.0.0.1.
Note: If the certificate is self-signed, you must add it to both the Personal and the Trusted Root Certification Authorities certificate stores for the Computer Account on all web and agent servers.
The certificate is bound to IP 0.0.0.0 on the machine hosting Service Host Manager (specified in the KeplerServicesUri instance setting), and the URI of the agents server (KeplerServicesUriForAgents instance setting). The port that the certificate is bound to is as follows:
Note: The host name specified in the KeplerServicesUri and KeplerServicesUriForAgents instance settings for each web and agent server must match the host name (“Issued To” value) of the certificate. For example, if the agents server host name is https://rel-agent-server1, the KeplerServicesUriForAgents instance setting must be https://rel-agent-server1:8990/Kepler.
Note: Make sure that you copy the Thumbprint certificate field when retrieving the thumbprint value (it's easy to confuse with the Serial number field). 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.
Relativity unbinds certificates from ports as part of the services normal shutdown cycle. Because abnormal shutdowns can also occur, and Service Host Manager uses a range of ports, it is possible that over time all ports in the range may be bound to certificates. Removing bindings for server maintenance one-by-one can be time-consuming, so the recommended way of clearing them is by using command line. You must shut down Service Host Manager before running this command:
Relativity.Services.ServiceHost.exe --unbindports
The dtSearch service is a self-hosted webservice that runs on any agent server on which the dtSearch Search Manager agent is enabled. Like Service Host, this service is not TLS-encrypted out of the box, but you now have the ability to enable this feature beginning in Server 2022.
To enable HTTPS on the dtSearch service, perform the following steps:
Fully configure Service Host for HTTPS, per the HTTPS configuration steps above.
Set the EnforceHttps instance setting to On. This instance setting can only be set to On if the Service Host has been fully configured for HTTPS.
Install a valid SSL Certificate. We recommend re-using the same certificate used to secure ServiceHost on each agent machine. This is possible because, like Service Host, the agent hostname is used in the URI for all calls to the search service. To confirm this, you can review the KeplerServicesUriForAgents instance setting. If for any reason you are not using agent hostnames, this topic contains best practices for configuring a certificate for each agent by hostname.
Register the SSL certificate to the search service's port. The default port for the dtSearch Search Service is 6870, but this can be overridden via the SearchAgentServicePort instance setting. Unlike Service Host, the search service will not auto-register your certificate on startup. This must be carried out by a server administrator or via automation of your own.
Enable HTTPS for the search service via the toggle kCura.EDDS.Agents.Toggles.EnableHttpsDTSearchToggle. This Relativity toggle, once enabled, will cause the search service to automatically switch to the HTTPS protocol. No manual restart is required.
If an application error indicates that a service did not deploy successfully, start by reviewing the information on the Errors tab. If you are unable to identify the cause on the Errors tab, review the Relativity log. For more information, see Logging.
In most cases, Service Host Manager errors are resolved when the service restarts. Once the Service Host Manager restarts, a new end point is generated and service is redeployed.
If the problems persist, review the Service Host Manager port and HTTPS settings described above.
Why was this not helpful?
Check one that applies.
Thank you for your feedback.
Want to tell us more?
Great!