Knowledgebase

Answer / Solution

Please open UltraSearch, navigate to the DataCentral connection configuration settings and press the button Test connection. If the connection check fails, please continue with these options:

1. Verify service availability and network connectivity
   Make sure the "SpaceObServer DataCentral" service is running on the SpaceObServer host system and the REST interface is activated in SpaceObServer.
   Open https://hostname:port/healthz. The endpoint must return "Healthy".
   Make sure the DataCentral connection is not blocked by a firewall. The default port is 5149.
   In SpaceObServer, open Start > Options > Index Service and verify that the DataCentral server is enabled and uses the same port that is configured in UltraSearch.

2. Verify the certificate used by DataCentral
   In SpaceObServer, under Options > Index Service, check which certificate is currently configured for the DataCentral service.
   Compare the certificate thumbprint shown there with the certificate or fingerprint configured in UltraSearch.
   In UltraSearch, certificate settings can only be changed in administration mode.
   If UltraSearch was installed without explicit certificate parameters, it validates the DataCentral certificate by fingerprint by default and stores the fingerprint from the first connection for later communication.

3. Verify authentication and SPN configuration
   Try out the connection to the IP address of the SpaceObServer DataCentral host in UltraSearch. If the connection works with the IP address but not with the server name, the problem is typically related to Kerberos/SPNs. Connections by IP address usually use NTLM, connections by host name prefer Kerberos.
   If the connection check with the host name returns "Cannot establish the connection", you can
   1) use NTLM (use the IP address) as authentication method (not recommended because of security reasons; does not work if NTLM is disabled by group policy)
   2) Reset password of the service account to ensure an AES Key
   3) make Kerberos work by correcting the SPN configuration in your Active Directory (see below).
   
   Which account runs the DataCentral service?
   - Local System / Network Service: usually no SPN configuration is required, the existing HOST/ SPNs of the computer account also cover HTTP/. Do not register HTTP/ SPNs for the server name on any other account, this causes exactly this error.
   - Dedicated domain account: register the HTTP SPNs on that service account (not on the computer account). Note the following warning.
   
   Important: an explicit HTTP/ SPN for the server name affects the whole host.
   As long as no explicit HTTP/ SPN exists, Active Directory resolves HTTP/servername through the HOST/ SPN of the computer account. Once HTTP/servername is registered on the DataCentral service account, clients receive a Kerberos ticket for the DataCentral service account for every HTTP or HTTPS service on this host. Other HTTP-based services that run under the computer account can then no longer authenticate with Kerberos, e.g. Windows Remote Management (WinRM/PowerShell Remoting), IIS websites or WSUS. setspn -S and setspn -X don't warn about this, because no duplicate SPN is created. Services with a different service class, e.g. file shares (CIFS/) or Remote Desktop (TERMSRV/), are not affected.
   If other HTTP-based services run on the host, use a dedicated DNS name for DataCentral instead (see below).
   
   Check and correct SPNs
   Modifying SPNs requires write permissions on the account servicePrincipalName (e.g. Domain Admin or delegated).
   1) Use setspn -L <service account> to review the current SPNs. You need an SPN for every name UltraSearch uses to reach the server, e.g. HTTP/servername and HTTP/servername.domain.tld, plus any DNS aliases. The port (e.g. 5149) is not part of the SPN.
   2) Use setspn -Q HTTP/servername and setspn -Q HTTP/servername.domain.tld to check whether these SPNs are already assigned to another account. setspn -X lists duplicate SPNs in the domain.
   3) If an SPN is assigned to the wrong account, remove it there with setspn -D <SPN> <wrong account>.
   4) Use setspn -S <SPN> <service account> to add a missing SPN. If setspn -S reports a duplicate SPN, it is already assigned to another account (see 2 and 3).
   5) On the UltraSearch client, clear the cached Kerberos tickets with klist purge (or sign out and back in), then repeat the connection check.
   Kerberos also requires the client to be a member of the domain (or a trusted domain) and the clocks of client and server to differ by no more than 5 minutes.
   
   Use a dedicated DNS name for DataCentral (recommended with a domain account)
   With a dedicated DNS name, e.g. sosdatacentral.domain.tld, DataCentral gets its own HTTP/ SPN. The HTTP/ SPN of the server name stays with the computer account, so the other HTTP-based services of the host keep working with Kerberos. In return, the new name must be included in the DataCentral certificate, and UltraSearch must connect to DataCentral using this name.
   1) In DNS, create an A record (not a CNAME) that points to the IP address of the DataCentral server, e.g. with PowerShell on the DNS server: Add-DnsServerResourceRecordA -ZoneName domain.tld -Name sosdatacentral -IPv4Address <IP address>. With a CNAME, the client builds the SPN from the target name, i.e. from the server name again. Check the name resolution on the client with Resolve-DnsName sosdatacentral.domain.tld.
   2) If HTTP/ SPNs for the server name were previously registered on the service account, remove them with setspn -D HTTP/servername <service account> and setspn -D HTTP/servername.domain.tld <service account>.
   3) Register the SPNs for the new name on the service account with setspn -S HTTP/sosdatacentral <service account> and setspn -S HTTP/sosdatacentral.domain.tld <service account>.
   4) Issue a certificate for the new name, e.g. from your enterprise CA. The certificate created by the SpaceObServer installer doesn't contain the new name. The certificate must contain the new name as a Subject Alternative Name (SAN) (sosdatacentral.domain.tld, and sosdatacentral if needed), be valid for server authentication and have a private key. Import it into the certificate store Local Computer > Personal and give the service account read access to the private key.
   5) In SpaceObServer, select the new certificate under Options > Index Service and restart the DataCentral service.
   6) In UltraSearch (administration mode), enter sosdatacentral.domain.tld as the DataCentral server and update the certificate fingerprint.
   7) On the client, clear the Kerberos tickets with klist purge and check the connection. klist should then show a ticket for HTTP/sosdatacentral.domain.tld.
   8) Optional: check that remote management of the host works with Kerberos again with Test-WSMan -ComputerName servername.domain.tld -Authentication Kerberos. Without -Authentication, Test-WSMan sends an anonymous request and says nothing about Kerberos.
   Afterwards, UltraSearch can reach DataCentral with Kerberos only through the new name. Through the server name, the client receives a ticket for the computer account, which DataCentral can't accept while running under the domain account.
   
   

If the connection check works, please follow these steps:

1. Scan/Index existence
   If the search returns no results, verify that the folder you are searching in has already been scanned and indexed by SpaceObServer/DataCentral.
   For content searches, verify that the full text index is enabled for the scan.
   Check whether an UltraSearch exclude filter is active.

2. Check the logs on the DataCentral server
   Check the Windows Event Log for errors from SpaceObServer Agent and SpaceObServer DataCentral.
   If a file should be searchable but is not, the file might not have been indexed because of an indexing problem shown in the Event Log.