SOTI Connect Configuration Issues
Review the following scenarios for instructions on resolving SOTI Connect configuration related issues.
Unable to Access SATO Printer via Hostname when Using Device Registry
IPv4 mode is static, with a specified static IP and a specified hostname. However, the printer is inaccessible by hostname.
Issue Resolution
Unable to Connect SOTI Identity with SOTI Connect
While attempting to add SOTI Connect to a SOTI Identity tenant, the following errors occur:


- Affected versions: SOTI Connect 2024.0 and later.
Issue Resolution
- If SOTI Connect is already registered to an instance of SOTI Identity, and you are trying to register with another
SOTI Identity tenant.
- Locate the first connection and delete it from the SOTI Identity console.
- Check for certificate issues.
- For example, an expired or invalid GoDaddy certificate on the SOTI Connect MS server.
- Check for the wrong Fully Qualified Domain Name (FQDN) in the SOTI Connect installation.
- For example,
"SotiConnect20"
instead of"SotiConnect20.soticonnect.com".
Note: The FQDN is passed to SOTI Identity and SOTI Identity uses it to call back to SOTI Connect. If the FQDN is wrong, SOTI Identity cannot reach SOTI Connect.
- For example,
Use of Custom Attribute Macros Resulting in Corrupted Certificate Templates
Before SOTI Connect 2025.0, users could delete the custom attribute macro used in the subject alternative name of a certificate template. Following deletion, a corrupted value would appear in the certificate authority template. However, if the custom attribute was not deleted, the macro displayed correctly.
Issue Resolution
Issue with Local Administrator Access
If a SOTI Identity user with Administrator privileges changes the local administrator's role to a non-administrator and the connection between SOTI Identity and SOTI Connect is lost, no administrator remains on the local system.
Issue Resolution
- On the VM with the Management Server (MS) installed, open the PowerShell application in Administrator mode and navigate to the installer folder.
- Run the appropriate command based on your authentication method:
- For SQL
authentication
.\Soti.IoT.SilentInstaller.exe -databaseHost="databaseHost" -databaseUser="databaseUser" -databasePassword="databasePassword" -newadmin "NEW_ADMIN_USERNAME" "NEW_PASSWORD"
- For Windows
authentication
.\Soti.IoT.SilentInstaller.exe -databaseHost="DatabaseHost" -databaseIntegratedSecurity -newadmin "NEW_ADMIN_USERNAME" "NEW_PASSWORD"
Note: In the commands, enter the appropriate details according to your environment. - For SQL
authentication
REST Simulation Unable to Send Alerts to the WebHook Receiver
REST simulator devices are unable to send alerts to the WebHook receiver.
[ERROR] [45] ChannelService - Exception in trying to send alerts System.Net.Http.HttpRequestException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Issue Resolution
- When installing or updating the REST Protocol Adapter (PA) using the silent
installer, the Webhook receiver URL defaults to the private address:
https://+:5551/
- For devices or simulators hosted on different machines than the REST PA
installation, replace the
+
symbol with the REST PA machine's FQDN in the installer configuration XML before running the silent installer.
System Health Displaying Extra File Store (FS) Instance
A known issue has been identified in SOTI Connect 2025.0.2, where one of the File Store (FS) instances may not uninstall. This can result in the System Health page displaying more FS instances than actually exist.
In a cluster environment with only two machines (demo1 and demo2), the FS database might show two File Store installations on the demo1 machine. This issue does not disrupt any processes but does create an extra FS record on the
view.- Access your SOTI Connect database.
- Navigate to the
SotiConnectFileStoreService
database. - Locate and edit the
[dbo].[ServiceInstances]
table.Use the
[InstanceFqdn]
and[RemainingUpdatesCount]
fields to identify the ghost instance.[InstanceFqdn]
should match the value from the System Health page, and[RemainingUpdatesCount]
should be greater than 0. - After removing the extra record, restart the Management Service process to apply the changes.