Troubleshooting general licensing client connectivity

If your software is unable to communicate with SOLO Server, the user may be prompted with an error such as 9101 or 9105. This generally means the web service was unreachable, and this is usually a networking issue on your customer's end due to a firewall or proxy server that may be blocking communication with the server. Configuration changes to allow communication to the licensing server would fix the issue in this case.

Quick reference: read the error text before changing firewall rules. A message about a name that could not be resolved is a DNS problem. A message about a server that could not be reached is a port or firewall problem. These need different fixes.

What the error message tells you

The wording of the failure narrows the cause considerably. Protection PLUS 5 SDK reports these:

Error	Message text	What it usually means
9101	Web service call failed. Please check Internet connectivity.	A general web service failure. The underlying cause is usually appended to the message, so read the rest of the text.
9105	The server could not be reached. Verify that the computer is connected to the Internet, and that the firewall/proxy is set-up properly.	The host resolved, but the connection was refused or blocked. Check outbound port 443 and proxy policy.
9106	The server could not be located. Verify that the computer is connected to the Internet, and that the firewall/proxy is set-up properly.	The host name could not be resolved. This is DNS.

A 9101 often carries the real cause in the appended detail. In particular:

"The remote name could not be resolved" is a DNS resolution failure. The application could not translate the host name into an IP address, so it never reached the point of opening a connection, selecting a port, or negotiating TLS. Blocking a port or a protocol produces a different error than this one. Check DNS resolution first, not firewall port rules.
A proxy authentication failure (HTTP 407) means the workstation reached the proxy but was not authenticated. See Web proxy support, proxy authentication, and troubleshooting.
A certificate or TLS error often means a proxy or firewall is inspecting TLS traffic and re-signing certificates. The inspecting device's root certificate has to be trusted on the workstation, and any certificate pinning on that device will break when the server's certificate is renewed.

Why does a DNS error suggest the proxy is not being used?

When an application is routed through an explicit web proxy, the proxy resolves the destination host name on the application's behalf, and a failure at that stage names the proxy. If the error names the SOLO Server host itself, the application is most likely attempting a direct connection rather than going through the proxy. In that situation the fix is usually on the client side, getting the application to use the proxy, rather than on the network side.

Troubleshoot connection to SOLO Server

Have the user close all browser tabs and windows, open a fresh browser window, and navigate to:

https://secure.softwarekey.com (or your own server address if using SOLO Server Dedicated URL or SOLO Server Self-Hosted)

If the user can reach SOLO Server, they should simply see the text OK in the web browser.

If they do NOT see the OK text, then something on their end is blocking the connection to SOLO Server. Our licensing clients use the same underlying technology as web browsers for activation, so activation uses the standard web ports: 443 for HTTPS and 80 for HTTP.

With Protection PLUS 5 SDK, an application configured with https:// web service URLs activates over HTTPS only, so allowing outbound port 443 is sufficient and no activation traffic uses port 80. See Client activation ports and SOLO Server IP address for the address to allow in firewall rules, and for what applies to the other licensing clients.

Commands to narrow it down on the affected machine

These three commands in Windows PowerShell separate DNS, port, and application problems:

<code>nslookup secure.softwarekey.com
Test-NetConnection secure.softwarekey.com -Port 443
Invoke-WebRequest https://secure.softwarekey.com/ -UseBasicParsing

If nslookup fails, it is a DNS problem.
If nslookup succeeds but Test-NetConnection fails, outbound 443 is blocked, or traffic must go through a proxy.
If all three succeed but the protected application still cannot connect, the network policy is not the problem. The application is most likely not picking up the proxy configuration.

Substitute your own server address if you are not using the shared SOLO Server URL.

Activate manually

If the user can connect through the browser but cannot activate through your software, a temporary solution to get them licensed is a manual activation, if you have enabled that option in your software.

For Instant Protection PLUS 3, this is the Users may activate my application from another computer option, which adds the Activate From Another Computer choice to the activation dialog.
For Protection PLUS 5 SDK, this is the manual activation process for PLUSManaged or PLUSNative.

Protection PLUS 5 SDK can also add proxy server support, documented for PLUSManaged and PLUSNative.

The user can complete a manual activation on the same computer if they can reach SOLO Server through a web browser. Note that if you require your software to periodically validate with SOLO Server, that validation attempt will still fail while the application cannot connect automatically.