Applying Zebra MX advanced device settings via SOTI EMM

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.

The flow

SOTIscript has a command called mxconfig [/path/to/file] to apply any MX XML. All we have to do is:

  1. Prepare the XML via Zebra StageNow tool
  2. Deliver the XML file to the device. Ex: /enterprise/usr/my_mx_baseline.xml
  3. 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.
  4. 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.

StageNow profile Review screen with
StageNow profile Review screen with “Export for MDM” button highlighted

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.

<characteristic version="4.3" type="WirelessMgr">
    <parm name="BluetoothState" value="2" />

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…

Uninstall considerations

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).

Traceability considerations

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…

  1. Just use the fact that the Package is installed or the Rule is assigned.
    1. The simplest one – nothing to do! 😊
    2. This works nice if your MX profiles are atomic (one setting per File/Action)
    3. Easy to use in device search/filter.
  2. Use Custom Attributes
    1. 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!
    2. 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).
      1. 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.

Version considerations

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!

Helpful links:


2 thoughts on “Applying Zebra MX advanced device settings via SOTI EMM

Add yours

  1. Another fantastic post! I suggest always validating the StageNow XML by first creating a barcode and then testing it on a sample device. If the barcode based MX is applied successfully then the XML submission through SOTI should work for the rest of the devices. Otherwise if it fails you may need to adjust the MX version. There are also settings some times depending on the profile that are included in with the XML version that the device doesn’t support because of OSX differences, causing application to fail. You can manually compare the list of available configuration options for the MX and OSX version of your device in order to determine which setting value you need to remove manually from the XML.

    Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

Up ↑

%d bloggers like this: