MindLink Anywhere Troubleshooting

Error messages will be displayed if the application encounters any problems. The error message can be used to determine what the problem is. See Figure 114 for an example error dialog.

Login error

Figure 114: An error message

Login Errors

When login is not successful, the application will display error messages to inform the user of the cause of the problem. The following is a list of login problems which will cause an error message to be displayed:

  • Invalid username or password
  • Password has expired
  • Missing username or password
  • Missing SIP address
  • Unable to contact connector service
  • Unable to connect to messaging server
  • Encountered a server error
  • Received invalid data from the server
  • An unrecognized error

Connection Errors

A connection problem will occur when the application is disconnected from the server, the session has expired, or has an associated error. When this happens, the application will attempt to reconnect several times (with increasing delays). If reconnection is successful, the application will continue to operate as usual. If reconnection is unsuccessful, an error will be displayed, which will prompt the user to login again.

When reconnection can be established without re-login, the presence of the user will not change and they will appear online all the time. Messages will be retrieved when the user reconnects. However, if the reconnection fails and the user is required to re-login, they will appear offline and messages sent or received during that time will be lost without any explicit notification to the sender of the message.

Other Errors

A Service fails to start

Check the logs. If there is no logging directory, ensure the service account has write access to the install directory. Ensure the service account has full rights on the database.

Check that your load balancer or proxy is forwarding requests correctly (to the correct ports, etc.). Ensure that the certificates are bound correctly on the Connector service hosts.

The Connector Service fails to start with a 407 Proxy Authentication Required error

This typically happens when the environment is configured to run with a web proxy. The connector service must be configured to use the web proxy. Add the following config to the root element of the


Connector Service's configuration file (MindLink.Core.Host.exe):

Connector service fails to start with the following error

Microsoft.Rtc.Internal.Sip.TLSException: CertificateInfoNative::AcquireCredentialsHandle() failed; HRESULT=-2146893043

Most often, it means that the process does not have permission to access the certificate you are using to authenticate for transport layer security (TLS). This can be resolved by giving the service account read access to the correct certificate key file located at 'C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys'.

On logging in, the loading screen hangs

It is likely that the Connector service is failing as it tries to log you in.

Look at the Connector service logs to diagnose the problem. Check that the configured underlying chat system server and ports are correct.

An 'Unspecified Error' occurs during login

Use Firebug in Firefox (or a similar diagnostic tool) to confirm that the login AJAX request is successful - i.e. that the response is not a 401 or other HTTP code.

If the response is returning with error code 404, the Connector service is probably not running. Ensure that it is.

If it is returning with another error code, ensure that the certificate is bound correctly on the Connector service machines (use httpcfg or netsh), and that it is configured properly in the Connector service config files. Observe the Connector service logs to confirm that the request is reaching the Connector Service properly.

If it is not returning an error code, it is likely that an error is occurring on the Connector service. Check the Connector service logs to diagnose the fault. If connecting to Microsoft Group Chat Console, SSO is set to true and the error is 'Tls failure exception', make sure that in the Connector settings in the Administration Console server port is set to 5061 and transport type to 'Tls'.

This error also occurs when the type of connector (gcc or ma) is changed and the MindLink Anywhere services are not restarted. Ensure that ALL MindLink Anywhere services are restarted (only restarting the Connector Service will not do) when the connector type is changed.

An 'Unable to contact Messaging Server' error occurs during login

Confirm that the Connector Service is configured to talk to the underlying chat system correctly - check the sever name, port, transport type and sip address.

An 'Unable to contact Connector Service' error code occurs during login

It is likely that the Connector service is not running, or a firewall is blocking requests. Use Firebug in Firefox (or similar diagnostic tool) to ascertain what the HTTP response code of the login AJAX request is.

If the error is 404, the Connector service is probably not running, or it is listening on the wrong port or path. If the error is 401 or 500, the certificate may not be installed correctly. Ensure that it is installed on the Connector service machines, that the Connector service machine has the certificate bound to the appropriate port (use httpcfg query ssl), and that the Connector service is configured to use the certificate and HTTPS in its config files.

Observe the Connector service logs to confirm that the request is reaching the Connector service properly.

JavaScript errors are encountered

Enable debug mode by changing the client.debug setting to true in the Administration Console. Use Firebug in Firefox (or similar diagnostic tool) to examine the logs. Report logs to Formicary.


Acronym Definition
APNS Apple Push Notification Service – responsible for push notifications for iOS clients
rimpublic.property This is a file installed with every MDS instance that specifies some MDS instance-specific settings. You can find it on the MDS server at: image004
MindLinik MindLink Anywhere – The collective term for the Route, Connector and Configuration and Monitoring service.

General Points of Failure

MindLink Mobile has various potential points of failure as shown in Figure 3a.

Mobile Broker

Figure 115- MindLink Mobile Failure

These points of failure can be categorized as follows: 1. Device - Affects communication at 'a' and 'b'. 2. MDS - Affects communication at 'a', 'b','c' and 'd'. 3. Connector Service (Mobile Broker) - Affects communication at 'c' and 'd'.

Determining Failure Origin

It is best to identify a point of failure one-at-a-time, starting with failures closest to the device first i.e. if the mobile broker and the MDS are failing, handle the MDS failure first. In order to identify a point of failure successfully you should start with the Mobile Broker logs and follow the process in Figure 115.

Essentially you will investigate the causes of failure by looking at the following log files: 1. The Mobile Broke Logs : %Program Files%\MindLink Software\ConnectorService\Logs\Connector.log

  1. The Device Logs : accessed using the shortcut alt+l, alth+g, alt+l, alt+g on the device

When debugging any issue, it is best to start with the Mobile Broker logs. This will tell you whether the issue is device-side or MindLink-side.

All issues are almost always configuration problems. If you identify that a problem is MindLink-side, consult the MindLink Anywhere troubleshooting guide, otherwise this guide should contain all known problems and their solutions.

Once you can get a device logging in, you have confirmed that the device, MDS and MindLink Mobile Broker are able to communicate. Any further issues will be general MDS/Broker/MindLink problems that will need to be individually investigated using the available logs.

Always look at the 'Common Issues' section before using the decision flow diagrams as it is likely to lead to a faster resolution.

image121 Figure 116- Broker log decision flow

Figure 117- MDS log decision flow

Connector Service Common Issues
Problem Solution
No device pin in requests This has the following causes:
1. The MDS is not set to forward device pin in http headers. Fix this by setting the application.handler.http.header key value in the rimpublic.property file to email,pin.
2. The MDS is set to forward device pin, but the header domain regex does not match the Broker host. Fix this by setting theapplication.handler.http.header.domain key value in the rimpublic.property file to a regex that will successfully match the Broker host (this is case sensitive and must match the host name that appears in the MindLink Mobile formicary.MindLink Mobile.server_address IT Policy rule).
Device requests are to the correct host but a ridiculous port This has the following causes:
1. The MindLink Mobile formicary.MindLink Mobile.server_port IT Policy rule value is set to an incorrect port. Adjust the port, wait for the change to be pushed to the device, and retry.
2. The formicary.MindLink Mobile.server_port IT Policy rule type is not set to integer. Usually it defaults to string, and this then causes the device to interpret the port as the sum of the ASCII character codes. Change the type to integer and retry.
MDS Deployment Common Issues
Problem Solution
Device reported general error. Try deploying the same version of the software using JavaLoader preferably to the failing device or an identical OS version. The failure should be reported in more detail. If the failure is an invalid Java header, this means that a newer version of the rapc compiler and rim_api.jar files were used when building. A new build is required using an earlier version of the rapc compiler matching the device OS version. Note: We support OS 4.6 and above.
Controlled Access Exceptions Caused by unsigned cod files. This requires rebuilding, resigning, and redeployment.
Initialisation fails showing “invalid URL or security settings” Usually caused by specifying an invalid URL for the “server_address” IT Policy setting. It must be a full URL of the identification service and the protocol must be lowercase e.g. Correct: “http://mlm.domain.com:7074/Identification/Details” Incorrect: “HTTP://mlm.domain.com:7074/Identification/Details”
General Communication Common Issues
Problem Solution
:/notify/, pushId = , destination = , result code = 400 time - out> This could be one of the following reasons:
1. The Mobile Broker host time is out of sync with the MDS host time. This will cause the push-expiry time set by the Broker to be triggered too soon. Correct this by synchronizing the clocks and extending the Push Notification TimeoutMindLink Mobile configuration value (see Section 3.8).
2. The device is out of coverage and the failure was legitimate.
3. The communication between the device and the MDS is suffering from high latency. If this happens a lot and the device is in coverage, it indicates that the network is slow. You can reduce the occurrence of the issue by extending thePush Notification Timeout MindLink Mobile configuration value (see Section 3.8).
:/notify/, pushId = , destination = , result code = 400 push connection aborted by device> Usually this means that the device closed the push listener, i.e. the application was closed. Consult the device logs for more details.

Device Logs

iOS Devices

By going to 'application settings' on your iPhone, you can 'enable logging'. By enabling logging, it is possible to receive an internal log to your device console. The internal log can be viewed by downloading a console app from the app store.

If the application crashes, the logs for this are transmitted to Formicary's TestFlight account. For more information on TestFlight, see: https://developer.apple.com/testflight/.

Android Devices

For Android users, the logs are located on the SD card of the device in MindLink\log.txt (if an SD card is not present then the logs will log to the device memory - sdcard\MindLink\log.txt)Performance Counter Logs


The WebPart writes diagnostic messages to the SharePoint ULS log, which generally writes to files in: %ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS


If you experience any issues with the application, in the first instance contact your local IT support team. If you have subscribed to Support and Maintenance and require additional assistance from the Formicary Collaboration, please email the Support Team at support@mindlinksoft.com stating the nature of the problem and including your contact details.

The MindLink Server writes log messages to a text-based log file. The location of this file is configurable via the Management Center.

Each log is written at one of the log levels:

  • Verbose - Detailed information about each action being processed, for diagnostics and troubleshooting.
  • Info - Post-mortem information about significant completed operations, for usage reporting.
  • Warning - Notifications of environmental, configuration, or operation abnormalities that may indicate problems - immediate, or in the future - for health monitoring.
  • Error - Information about erroneous application behaviour for troubleshooting and health monitoring.

The minimum log level - as ordered above - of logs that will be written to the log file is configurable in the Management Center. All logs below this level will be discarded.

Logging at Info is recommended for production.

Skype For Business Logging

The MindLink Server uses the Microsoft UCMA SDK and Persistent Chat SDKs to integrate with Skype for Business. Each of these SDKs emit Event Tracing for Windows (ETW) logs that can be captured by the SFB Centralized Logging Service or Debugging Tools (OCS Logger) etc. The SfB core component or debugging tools must be installed on the MindLink host server, respectively.

For OCS 2007 R2 integration, MindLink uses the Group Chat SDK. This does not emit ETW logs but instead can be enabled to write to a text-based log file, distinct from the standard MindLink log file. The Management Center can be used to configure whether logging from the SDK is enabled and to what location.

These logs can be used to diagnose and troubleshoot integration problems between SfB and MindLink.

Service Status

The MindLink Server runs as a Windows Service. Any environmental or configuration problems encountered during startup will cause the service to abort startup and stop immediately. Once started, further errors - environmental or otherwise - will not cause the service to stop.

The MindLink Server exposes an HTTP health-check Info Service that can be used by external monitoring systems or load balancers to verify that the service is started, healthy and operation.

By default, this service is available at http://:9081/infoservice/status. Making a GET request to that request will return an HTTP status code of 200.


When the MindLink Mobile Server is deployed in a pool, each node must be configured to connect to a Microsoft SQL Server database layer. When a node loses connectivity to the database for any reason it will declare itself unavailable and remove itself from the pool, until database connectivity is restored. While unavailable, the node will reject new logon requests and hence should be disregarded as a candidate node by the load balancer.

The Info Service will return HTTP status code 503 while the node is disconnected from the database. This status code can be used by the load balancer to maintain the set of candidate pool members, and by any external monitoring systems to detect database connectivity failure.

User Administration (Anywhere, SharePoint, Mobile)

A MindLink session will be interrupted if any of the following administration changes is made to the user account:

  • The SIP address of the user is changed.
  • The user is moved to a different pool.
  • The user is removed from SfB.

The user will be notified that their session has ended and they will be required to re-logon

This content is licensed under the terms of the Terms of Service