Zebra devices have a cool set of extensions called MX. It can do tons of things. But, can we expect every EMM vendor to timely implement them natively in their consoles?
SOTI EMM/MDM is one such good example, as UI there is quite limited. However, SOTI has a very powerful tool called SOTIscript. I have already covered, for example, how SOTIscript allows changing virtually any standard Android OS setting.
Similarly, we can use SOTIscript to apply MX settings on Zebra devices, extending the level of control over the device.
SOTIscript has a command called mxconfig [/path/to/file] to apply any MX XML. All we have to do is:
- Prepare the XML via Zebra StageNow tool
- Deliver the XML file to the device. Ex: /enterprise/usr/my_mx_baseline.xml
- Execute a script with mxconfig /enterprise/usr/my_mx_baseline.xml command in it. This can be done in two ways
- Create a Package that would deliver a file and run a post-install script. This works well if you want this to be a part of your baseline, and be traceable.
- Create a File Sync Rule that would deliver a file and run a post-sync script. This is probably easiest for a one-time manual push.
- In both cases: Profit!
I will only cover #1 in-depth here, since the rest is a fairly standard SOTI thing (and I still haven’t recovered my console).
1. Prepare the XML
This step is actually simple. Just create a staging profile using Zebra’s free device staging tool called StageNow. The tool is extremely straightforward, but has a few caveats. I had written a training on it, when I was working for Zebra Learning Centre, you can watch it here.
So, launch StageNow and build a profile to change whatever settings you want. Once the profile is completed, click the Export for MDM button in the Review screen and save the XML file.
Here’s my simple demo XML that turns Bluetooth off. For testing you want something that is easy to control. Of course, you can change multiple settings at the same time – the entire MX Profile will be applied.
<wap-provisioningdoc> <characteristic version="4.3" type="WirelessMgr"> <parm name="BluetoothState" value="2" /> </characteristic> </wap-provisioningdoc>
That was it! Now, proceed to the SOTI console, create your Package/FileSync Rule and a script with mxconfig /path/to/my/file.xml in it. Push it to the device and enjoy!
There are just a few things to consider…
If you went the Package path, what should happen, when the Package is uninstalled? For instance, how can you revert the setting (if you have to, see below)?
There is no mxconfig-undo command, but it is easy to create another MX profile (to un-do your settings) and include mxconfig /path/to/my-undo-file.xml in the uninstall script.
What you cannot do (well, you can, but it is too complicated to bother in most cases) is to preserve original setting value and the restore it. But in most cases you don’t need that, as you push configuration baselines – previous setting states should not matter.
For that sake, in many cases you would not even bother with uninstall at all, since your new baseline will dictate BT status anyway. It may be useful for other cases, however (deleting files, etc).
Now that you are pushing settings that SOTI does not know about, how do you know they exist on the device? There is a number of ways to achieve this, all out of scope of this article, but I may write something later…
- Just use the fact that the Package is installed or the Rule is assigned.
- The simplest one – nothing to do! 😊
- This works nice if your MX profiles are atomic (one setting per File/Action)
- Easy to use in device search/filter.
- Use Custom Attributes
- I am a big fan of attributes ever since the days of MSP (~2009). If you know how to use them, and have EMM system that supports them well – you will rule your deployment with ease and grace!
- You can create file-based Custom Data in SOTI, which would reflect the state of your setting (your package or file sync rule would just drop the correct file onto the device).
- Now you can fully leverage the status of your setting in a lot more places!
In both cases, however, there is absolutely no guarantee that the setting was not changed by somebody else! So use with caution.
mxconfig is present in SOTI manuals since 12.x, but it only reliably works in 13.3+.
You now should be able to:
- Apply ANY MX setting to Zebra device using SOTI
- Explain how simple the process really is
- Consider factors such as uninstall behaviour and traceability in your deployment
- Tell others how cool and advanced you are with SOTI!
Was it useful? Should I have just combined this with my similar AW post? Let me know your thoughts!