Knowledgebase

The most likely reason for this problem is a Windows update that has been published by Microsoft recently. We were able to solve this problem in TreeSize version 9.8.1 and UltraSearch version 4.8.2, so if possible, please update your software. If this is not possible, please consider uninstalling Windows update KB5094126.

DataCentral has access control implemented.

Although, there might be files indexed that are not accessible by some users, DataCentral automatically only delivers search results the specific UltraSearch user has access to.

Usually, you need 1 license to run SpaceObServer and DataCentral on a server + n licenses of UltraSearch Professional for n people that can search the DataCentral indexes.

The amount of data in the indexes and the number of searches is unlimited.

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.

The speed of DataCentral depends on many factors.

The speed of the indexing of documents depends on:

• the number of actually indexable files (xlsx and txt are indexable, but exe not)
• the size of the files
• the type of the files (txt files are usually faster than xlsx/pdf)
• the hardware (RAM and CPU, incl. the number of cores)
• the index location (avoid HDD drives or network storage, prefer an attached SSD drive)

For a small drive, DataCentral can be done within minutes, for larger ones, it can take hours and for very large drives with multiple TB of indexable files (exe files, images, ... don't count), it can even take days. Smaller scans lead to smaller indexes, which can usually be searched through faster. The initial creation of the index takes the longest. The repetitive updating of the index should be far faster, becaues only changes on the file system need to be applied on the index then.

SpaceObServer shows a progress and an estimation for the remaining time of the indexing in the "Configure scans" window in the "State" column of the scan.

The performance of a search is usually faster than without DataCentral and depends on:

• the number of the files found by the search
• the search term and its frequency in the index
• the network between the UltraSearch client and the DataCentral server

We aim to execute most of the searches within a few seconds.

If the search results are coming from DataCentral, UltraSearch shows the words "via DataCentral" at the bottom left.

If something does not work and search results cannot be loaded via DataCentral, UltraSearch attempts a "fallback" search, which searches the target folder manually.

For all we know so far, this issue seems to be caused by defects in the system itself. It might affect other applications as well.

To fix it, you might try to (please check the installation after each step):

1. Restart the system.
2. Check for pending/available Windows updates
3. Download and run the Microsoft .NET Framework Repair Tool
4. Download and reinstall .NET Framework 4.8
5. Open a command line prompt (Win+R -> CMD -> Ok) and run
   DISM.exe /Online /Cleanup-Image /RestoreHealth
6. Open a command line prompt (or use the same as before) and run
   sfc /Scannow
7. Uninstall KB5011048 from the system (how to)
8. Check for updates again or install KB5011048 manually again

Please find more information on DISM and SFC here.

The easiest way to see and possibly change the registered preview handler or IFilter (used for the file content search) for PDF files is to install the free version of PDF-XChange Editor which comes with a lightweight separate tool for this exact purpose.

You can find it under "C:\Program Files\Tracker Software\Shell Extensions\XCShInfoSetup.exe" when using the default installation path.

TreeSize and UltraSearch both use the preview handler and IFilter that is registered as default in the system, which is what you can see and adjust in this small tool.

Text-based file types can generally be searched right away and should not cause any issues if the used syntax is correct.

Other file types often require an IFilter to be searched.

Our software uses the corresponding IFilter that is installed and registered within Windows. If the content search does not find any results or gets stuck at some point, the currently used IFilter is the most likely culprit; we see this especially often with PDF files.

For PDF files, we recommend installing the Adobe IFilter as it has been the most reliable one. This does not require installing Adobe Acrobat, it is a separate installer.

It is possible that a new IFilter is installed and automatically registered when installing a new PDF software (or other relevant software for other file formats) on the system. In this case, it is necessary to register the working IFilter again if there are any issues with the new one. This can be done by reinstalling it. For PDF files, there is an alternative way described here.

This is a known error that has been resolved already, but it requires downloading a new installer. You can find it linked in this FAQ entry: https://knowledgebase.jam-software.com/7670