Troubleshooting Client Connection Problems

Locate the failing stage first

An offline device can result from the wrong package, a stopped service, an unreachable endpoint or a server-side failure. A connected device with an empty report is a different symptom. Work through the checks below in order and record what changes.

Start with one affected endpoint. Record the time, deployment model, package version, operating system, expected organization and visible error. Keep passwords, connection strings, license identifiers and private device details out of public screenshots.

1. Verify the package and service

Confirm that you installed Agent rather than Admin or Portable, and that its Cloud or On-Premise deployment matches the organization. In Windows Services, check GoMyid for a Cloud Agent or GoMyit for an On-Premise Agent.

If the service is missing, inspect the installer result and protection history. If it starts and then stops, capture the relevant Windows event and package error before repeatedly reinstalling. Do not change the service account or disable endpoint protection as a first response.

2. Verify the configured destination

For On-Premise, compare the package endpoint with the assigned server hostname or IP. A hostname must resolve correctly from the affected device, including its VPN or branch network. A hostname that works on the server itself may not resolve the same way on a client.

If the organization or endpoint is wrong, obtain a correctly generated package through the approved setup process. Do not manually copy another customer’s configuration.

3. Test the actual TCP listener

Ask the deployment administrator for the active server port. From the affected Windows device, a PowerShell connectivity check can help separate a network failure from an application failure:

Test-NetConnection -ComputerName <server-hostname> -Port <configured-port>

Replace both placeholders before running the command. If TcpTestSucceeded is false, check DNS, routing, VPN, the server listener and scoped firewall rules. If it is true, continue checking the application configuration and organization; TCP success does not prove enrollment or authentication.

4. Check the server and database

For On-Premise, confirm that the server is running and listening on the expected interface. Review startup or connection errors and verify its database connection using the actual runtime identity. A missing or inaccessible Sql.udl file can affect the native server even when SQL is available to a DBA.

Check GoMyidServer and GoMyidCore separately from the endpoint Agent. Setup tests both the login and registration/database pages. A login response alone does not prove the database works. See the illustrated setup walkthrough.

5. Distinguish missing reports from missing connections

If the device is connected but a report is empty, verify the selected organization, group, user, date range, reviewer permissions and enabled collection settings. Allow for the configured collection interval and compare a recent known event. Do not interpret an empty filtered report as proof that installation failed.

Symptom-to-check reference

What to send to support

Send the release and package type, Windows version, timestamp with time zone, exact error, service state, whether DNS and TCP checks succeeded, and sanitized relevant logs. Include which step last worked. Share organization-specific identifiers only through the approved private support channel.