Mobile Troubleshooting
Definitions
| 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:  |
| MindLink | 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:
- Device - Affects communication at 'a' and 'b'.
- MDS - Affects communication at 'a', 'b','c' and 'd'.
- 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:
-
The Mobile Broke Logs : %Program Files%\MindLink Software\ConnectorService\Logs\Connector.log
-
The Device Logs : accessed using the shortcut alt+l, alt+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
| Problem | Solution |
|---|---|
| No device pin in requests | 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 the application.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). |
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 |
|---|---|
<LAYER = SCM, EVENT = Notifying to URL = http://mobile_brooker_host>:< notification_port>/notify/, pushId = , destination = , result code = 400 time - out> | 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). | |
<LAYER = SCM, EVENT = Notifying to URL = http://mobile_brooker_host>:< notification_port>/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
MindLink Logging
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 etc. The SfB core component or debugging tools must be installed on the MindLink host server, respectively.
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.
Mobile 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.