HealthCast

Following are known issues for this ExactAccess Server release. They have been logged in HealthCast’s internal issue-tracking system. The number assigned to the issue is listed, along with a brief description of the issue. If additional information, including a workaround, is available, it is also provided.

KSI-061518—Disk space usage or out of disk space

Observed:

If XA Server has frequently been terminated outside of the SCM or has crashed, disk space appears to be used and not re-claimed. This may also be the case if the SSO service has been running a long time without a restart and you have a large active directory.

Workaround:

Ensure the following directory is cleaned up when stopping/restarting the ExactAccess Server Service (SSO service)

c:\users\<service account user>\appdata\local\temp (for instance c:\users\xaservice\appdata\local\temp - if the service has been configured to logon as user xaservice)

Any file with file name like the following may be deleted:

NexusDB_TemporaryStorage_ <pid>_<ts> .tmp

The file name contains a process ID (pid) and timestamp (ts) which will be different every time the service is restarted.

During normal shutdown operations, the temporary storage file is deleted, and re-created on startup. If sufficient RAM is allocated to the (virtual) machine, this file will be 0 bytes, however, it can grow to several gigabytes depending on load and other available data, large AD, other processes on the system using available RAM, etc.

It is possible to delete these files while the service is running - just check the currently running PID and delete files that do not match the current PID as part of the file name.

Workaround:

Another possibility to reduce disk space usage is to increase the amount of RAM installed on the (virtual) machine. While the disk space will still be used in the event of abnormal program termination, if more data is retained in RAM, the less likely the file is to contain any data at all. This would simply leave a 0 byte filename in the temp directory, but does not otherwise consume disk resources. The amount of additional RAM necessary is dependent on the size of the AD being SSO enabled in your environment. The only way to gauge what the RAM capacity should be is to increase available resources, then monitor the temporary directory over time - increasing RAM until the file remains 0 bytes for three to four weeks.

It may also be necessary to create the following registry key to indicate how much memory may be used by the internal block cache:

HKLM\Software\HealthCast\ExactAccess\Override

MAXInternalDBCacheSizeInMB: reg_dword = <megabytes of RAM to use for cache>

DE#1833—XA Server starts before SQL Server when both are installed on the same machine

Observed:

If XA Server is installed on the same computer as the SQL Server it is possible that after a reboot, XA Server will start before the SQL Server. If this occurs, the XA Server will fail.

Workaround:

Make the following registry changes to resolve this issue:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HCExactAccessServer

DependOnService (REG_MULTI_SZ) = MSSQLSERVER

Repeat these steps for each of the other active services that depend on SQL server:

ProxCard Service: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hchidserverservice

HCI Deploy Service: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\hcideployservice

auditSERVER Service: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HCAuditServerService