Cognex provides two methods for deploying new firmware upgrades to MX devices with SOTI's MobiControl:
Before performing a firmware update with MobiControl, consider the following:
When updating the MX firmware from a URL (web server), you must provide the full path to the firmware file. If your MX devices have full Internet access, you can use the Cognex server, otherwise you must host the firmware file on a server your devices can access. The following FAQ provides more information on obtaining the Cognex link or firmware file: How to obtain firmware files for MX-1000 and MX-1502 series?
Once you have the URL for the firmware file you wish to deploy, follow these steps:
Once you have retrieved the appropriate firmware file from the Cognex repository, follow the steps below:
Update the value of the uriString parameter with firmware filename you sent to the mobile device. The example above shows the path to the Download directory.
Cognex provides two methods for deploying configuration changes to MX devices with SOTI's MobiControl:
Before deploying an MX configuration with MobiControl, consider the following:
When updating the MX configuration from a URL (web server), you must provide the full path to the configuration file. You must host the configuration file on a web server your devices can access. The following FAQ provides more information on retrieving a configuration file from the setup utilities: How to create a configuration file for MX-1000 or MX-1502 mobile terminal?
Once you have the URL for the configuration file you wish to deploy, follow these steps:
Once you have retrieved the appropriate MX mobile terminal configuration file, follow the steps below:
Update the value of the uriString parameter with the configuration filename you sent to the mobile device. The example above shows the path to the Download directory.
The main features of the MX Connect application are:
In the UPDATES section of the main screen the app shows the configured firmware and MX configuration. If these configurations are installed properly, a checkmark is displayed in the rows, respectively. Although the configuration XML sent by the MDM contains URLs, MX Connect only displays the last component of these URLs. Use file names in the URLs that reflect the version of their content.
Check the log to review the history of the attached MX mobile terminal. You can check what configuration the app received, and if the updating processes were successful.
Tap the row in the history list and check the disclosed page for more detailed information on a particular event.
The following terms are used throughout this document:
Follow these steps to successfully perform firmware and configuration updates:
Enroll your iOS device in your MDM and make it supervised.
You have to enroll your iOS device in the MDM system to let your MDM system manage your iOS device. If the device is supervised, MDM can have more control over the device and perform additional tasks. If the iOS device is supervised, MDM can launch an application (by Single App Mode). This is required for MX Connect updating workflow.
You can make an iOS device supervised by using the Apple Configurator desktop application on a Mac or by using Apple's DEP program.
Perform some required setting steps to allow device enrollment in MDM in your JAMF instance, such as allowing JAMF to communicate via Apple's Push Notification Service. Make sure it is set properly.
Enable the required URLs during enrollment.
Apple Configurator Enrollment Settings
Supervise the device before enrolling it in JAMF. To supervise a device, you can use the Apple Configurator 2 desktop application. Tick the supervising option during the preparation of the device.
Prepare a device manually in Apple Configurator on Mac
After supervising, enroll the device.
User-Initiated Enrollment for Mobile Devices
You can combine supervising and enrolling by using a supervising identity.
For more information about device enrollment, refer to Enrollment of Mobile Devices.
Note that you have to perform some required settings to allow device enrollment in your SOTI instance, such as allowing SOTI to communicate via Apple's Push Notification Service. Make sure it is set properly.
Using the Apple Push Notification Service
You have to supervise a device before enrolling it to SOTI. To supervise a device, you can use the Apple Configurator 2 desktop application. Tick the supervising option during the preparation of the device.
Prepare a device manually in Apple Configurator on Mac
Enroll the device.
You can use the enrollment URL of your "Add Devices" rule.
There are multiple ways to enroll a device in MobileIron. You can read two examples below (for more options please check MobileIron's User's manual).
Install MX Connect app with your MDM system from the App Store.
Add MX Connect to JAMF by an App Store URL.
Set the distribution method to "Install Automatically" to let JAMF deploy it without user interaction.
To learn more about app distribution in JAMF, read the App Distribution document.
EMPTY
Click Add button.
Create a Single App Mode Configuration Profile for MX Connect.
Launch the application by putting it to Single App Mode (SAM). To let your MDM put the application to SAM, create a configuration profile in your MDM that is sent out to devices in the right time. If a device receives a Single-App-Mode configuration profile for MX Connect app, the iOS device launches the app and keeps it on screen until the MDM system revokes the configuration profile.
You can create a Single-App-Mode configuration profile at Mobile Devices or Configuration Profiles.
You can create a Single-App-Mode configuration profile at Profiles / Add.
You can create a Single-App-Mode configuration profile at Configurations.
Create a new configuration and select the Single App Mode type.
To associate the MX Connect app configure the restriction by selection your hosted MX Connect app.
Please note that this is only a preparation step so please leave "Enable this configuration" option unchecked:
Create an Autonomous Single App Mode Configuration Profile for MX Connect. There is a very similar functionality to Single-App-Mode that lets the MX Connect app to lock to the iOS device's screen and unlock when it is no longer needed. It is called Autonomous Single App Mode (ASAM).
Select Restrictions to create an Autonomous Single App Mode configuration profile.
Select the Applications tab and MX Connect's bundle ID: com.cognex.MXConnect
Select Restrictions to create an Autonomous Single App Mode configuration profile.
Select the Applications tab and add MX Connect's bundle ID (com.cognex.MXConnect) to the list.
In the configuration section you have to add MX Connect to the appropriate field.
To send ASAM configuration to a particular device click on Push button on the device's Configuration tab.
Prepare a server to access firmware and configuration update files by URL.
During a firmware or configuration update MDM sends only the URLs of the update files to the MX Connect app, which downloads the update files using these URLs. Make sure that your update files are accessible by a URL, and set up a server to accomplish this requirement, if necessary. You can use Cognex' firmware storage to distribute upgrades. For more detail, refer to the FAQ
Install MX Connect app (with your MDM system) from the App Store.
If the MX Connect app is already installed on all iOS devices managed, skip this step.
Once you have added MX Connect to your JAMF instance, apply two settings to automatically install to you device.
App install is automatic:
Add your iOS device to the app's scope:
Once you have added MX Connect to your SOTI instance, apply two settings to automatically install to you device.
Installing the app is automatic:
Add your iOS device to the app's scope:
Launch MX Connect. To launch MX Connect, send a Single App Mode configuration profile to the iOS devices.
To launch MX Connect, put it to Single-App-Mode by adding your device to the SAM configuration profile's scope.
To launch MX Connect, put your device to Single-App-Mode by adding it to the SAM configuration profile's scope.
Please note that you have to uncheck this option after the installation process to terminate the Single App Mode.
If you revoke the Single App Mode configuration during an upgrade process, the app keeps the SAM until the installation is done.
Send updates to the MX mobile terminal.
To send firmware or MX configuration updates, compose an XML text containing the URLs of the update files. The XML has to be provided to your MDM, which sends it to each MX Connect instance. MX Connect starts the update process upon receiving the XML configuration.
The XML composed is not a command but a configuration. The XML resides at MX Connect until the next XML configuration overwrites it. MX Connect will try to install the firmware and configuration using the defined URLs each time when the application starts. Firmware update is performed once and MX Connect checks whether the installed firmware matches with the firmware available on the MX mobile terminal. MX configuration update is performed multiple times when the application is opened, which takes only a few seconds.
To send new updates to MX Connect, edit the App Configuration text at MX Connect's page. Use the proper form of the XML to perform a successful update.
To send new updates to MX Connect, edit the App Configuration text at MX Connect app's "Application Catalog Rule". Use the proper form of the XML to perform a successful update.
Click on Add button and create a new configuration as indicated below.
Edit the configuration XML.
Use the following template to compose a configuration XML:
<dict>
<key>firmwareURL</key>
<string>https://myserver.com/firmwares/firmware_file_name</string>
<key>configurationURL</key>
<string>https://myserver.com/configs/config_file_name</string>
</dict>
Revoke Single App Mode from MX Connect to remove devices from SAM.
A company owning and operating many Cognex Mobile Terminals may want to remotely collect up-to-date information about battery level, battery health, installed firmware, etc. An iOS application using the cmbSDK framework can report status information of the attached Mobile Terminal to an MDM instance. Cognex mobile apps (MX Connect, Cognex Quick Setup...) can be also configured to report MX data.
Any iOS application is capable of reporting Mobile Terminal status information if it embeds and uses the cmbSDK framework.
1. Update cmbSDK framework in you app to use at least 2.4.0 version.
2. Configure reporting for the app in your MDM.
Reporting is done by an iOS application towards an MDM instance. The app has to be managed by the MDM instance and can only report to that MDM instance. There are a few configuration options the MDM administrator has to properly set to let the reporting feature work for a certain application. These settings are done by creating a proper Managed App Configuration including key-value pairs as the configuration of reporting. Please refer to your MDM's administration guide to learn how to edit Managed App Configuration of a managed mobile app.
As described above the MDM's administrator has to compose a Managed App Configuration to define settings of the reporting. This Managed App Configuration is sent to the mobile app by the MDM to let the app process it and behave accordingly. Please note that providing a proper Managed App Configuration is mandatory to enable the reporting. Without that the cmbSDK (in the app) won't start reporting.
The mandatory configuration fields are the following.
| Key | Type | Description |
|---|---|---|
| mxReportingEnabled | Bool | It has to be set to true to enable reporting. |
| mxReportingURL | String | This URL has to point to your MDM instance including port number if necessary. |
| mxReportingIntervalMinutes | Integer | Reporting frequency in minutes, minimum value is 1. |
| mdmType | String | The type of your MDM. Currently "SOTI" and "Jamf" are supported. |
| mdmDeviceID | String |
This field is a technical field that has to be set with a constant depending on your MDM type. SOTI: %DeviceIdentifier% Jamf: $JSSID MobileIron: ${devicePK} |
It is possible to turn on/off the reporting from the source code of your application by changing MDMReportingEnabled property of your CDMDataManSystem instance. Please note that the default value is false for MDMReportingEnabled. Please be aware that the mandatory fields still needs to be configured in MDM.
For cmbSDK connecting to your MDM instance will most likely require authentication credentials. Beside the mandatory configuration fields you also have to provide these in the Managed App Configuration as indicated in the following table.
| Key | Type | SOTI | Jamf | MobileIron | Description |
|---|---|---|---|---|---|
| mdmReportingClientID | String | x | Application needs to be added as API client and generate this ID | ||
| mdmReportingClientSecret | String | x | Application needs to be added as API client and generate this secret | ||
| mdmReportingPassword | String | x | x | x | Password |
| mdmReportingUsername | String | x | x | x | User name |
Please note that you have to provide a registered user's credentials that has the right to use the MDM's API for reporting. Refer to your MDM's administrator guide to learn more.
If you don't want to provide authentication credentials via Managed App Config for some reason these can be set by the cmbSDK's API from your app's code. It gives you full flexibility to retrieve authentication credentials in the way your company's policy requires. To do so you have to set the defaultMDMAuthCredentials property of CDMDataManSystem class.
var authCredentials: MDMAuthCredentials = MDMAuthCredentials()
authCredentials.username = "usr"
authCredentials.password = "pwd"
authCredentials.clientID = "myClientID"
authCredentials.clientSecret = "myClientSecret"
self.dataManSystem.defaultMDMAuthCredentials = authCredentials
self.dataManSystem.MDMReportingEnabled = true // if you want to start reporting
MDMAuthCredentials *authCredentials = [MDMAuthCredentials new];
authCredentials.username = "usr";
authCredentials.password = "pwd";
authCredentials.clientID = "myClientID";
authCredentials.clientSecret = "myClientSecret";
self.dataManSystem.defaultMDMAuthCredentials = authCredentials;
self.dataManSystem.MDMReportingEnabled = true; // if you want to start reporting
Please note that if you set authentication credentials both in the Managed App Config and via defaultMDMAuthCredentials property the fields in the Managed App Config will overwrite the fields in the defaultMDMAuthCredentials property per field basis. This precedence allows your MDM administrator to make some fix/change without rebuilding and deploying your application.
The following data of the attached Mobile Terminal is collected:
| Attribute name | Type | Format | Description |
|---|---|---|---|
| MX Device Variant | Text | MX-1XXX VARIANT | Example MX-1502 ER is shown for extended range MX-1502 mobile terminals |
| MX Device Name | Text | MX-1XXX-YYYYYY names are used by default, but it may be different according to configuration | |
| MX Serial Number | Text | 14 character | |
| MX Pistol Grip Battery Level | Number | X | -1 means no battery is available |
| MX Flat Battery Level | Number | ||
| MX Pistol Grip Battery Health | Number | ||
| MX Flat Battery Health | Number | ||
| MX Firmware Version | Text | A.B.C_D | Example: 5.7.9_sr3 |
| MX Status Date | Date | Depends from you MDM local settings | Contains the timestamp (in case of SOTI only date) for the last report. |
| MX Status Timestamp | Text | YYYY-MM-DD HH:MM:SS (24H) | Contains the exact timestamp for the last report. Available only on SOTI. |
The reported data fields appear as custom/extension attributes in MDM.
These custom attributes are global attributes and they are assigned to all enrolled devices. By default the custom attributes are not present in an MDM instance, the properly configured mobile app creates the custom attributes automatically via the MDM's API and neither the app developer nor the MDM administrator has to take care of it.
Preparing custom/extension attributes require two steps: