MindLink Mobile Troubleshooting
|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:|
|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.
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
- 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.
Problem to Solution Decision Flow of Connector Service (MindLink Mobile Broker)
Figure 116- Broker log decision flow
Figure 117- MDS log decision flow
Connector Service Common Issues
|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
|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
|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).
|Usually this means that the device closed the push listener, i.e. the application was closed. Consult the device logs for more details.|
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/.
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 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.
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 & 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
If you experience any issues with the application and cannot find a solution in the troubleshooting documentation, begin by contacting your local IT support team.
If you have subscribed to Support and Maintenance and require additional assistance, please email the Support Team at email@example.com stating the nature of the problem and including your contact details. The more informaion you are able to provide about the issue the better, as this streamlines the identification and solution process. Error codes, logs and/or issue reproduction steps are valuable, if they are available.