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?
Unlike SOTI (which can use SOTIscript for advanced features), AirWatch only allows changing settings that you can see in the GUI. If it’s not in console GUI – you can’t have it. However, there are a few exceptions.
In this post we will talk about one extremely simple, yet little-known way of extending AW functionality beyond the GUI limitations. Read on if you want to know how to apply any MX setting via AirWatch to your Zebra device.
AirWatch has a powerful Product Provisioning mechanism, which can be used to deliver fine-grained payloads to the device. One of such payloads is called “Apply Custom Settings”. One such “custom setting” can be Zebra MX XML, created with Zebra’s native tools. See where this is going?
Here’s how it works:
- Prepare the XML via Zebra StageNow tool
- Create a File/Action to apply this XML
- Create a Product using this file actions
- Assign the Product to your selected devices and enjoy!
I will only cover #1 and #2 here, since the rest is generic AirWatch Product Provisioning. Feel free to contact me for more details, though.
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 AirWatch console…
2. Create and deploy the payload in AirWatch
This is really easy:
- Navigate to Devices -> Staging & Provisioning -> Components -> Files/Actions (yes, it is really well hidden) and create a new one. Choose the Android platform and give it a name etc.
- In the Files tab, upload your XML file from StageNow.
- In the Manifest tab, add Apply Custom Settings to the Install Manifest and choose your file from the dropdown.
This is it!
Now, include this File/Action into your Product or Product Set, assign, and see it working! There are just a few things to consider…
What should happen, when the File/Action is uninstalled? For instance, should I revert to the previous setting, and how?
If our current File/Action setup gets uninstalled, the MX profile will not be un-applied – the settings are not restored/reverted. You may be fine with that, but what to do if you are not?
One of the ways would be to create another MX profile to un-do your settings and include it into the uninstall manifest. For my Bluetooth setting it would look like this
- Create MX Profile in StageNow that turns BT on (or just edit XML file with value=”1”)
- In the Files tab of my File/Action, upload both BT_off.xml and BT_on.xml
- Apply BT_on.xml in Uninstall manifest (“Apply Custom Settings”).
The only thing you really 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 manifest, 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 AW 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 File/Action is installed.
- The simples one – nothing to do! 😊
- This works nice if your MX profiles are atomic (one setting per File/Action)
- AW does not have nice mechanisms such as “ show me all devices that have File/Action X installed”, so overall this method is very limited.
- 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!
- In AW, custom attributes are complicated, and support is limited. But it is easy to create an XML file, which, when put in the right location, will automatically cause the agent to report the necessary values to the console. All you need to do is to build the XML file and include it in the Files tab of your File/Action (delete/replace during uninstall as well!).
In both cases, however, there is absolutely no guarantee that the setting was not changed by somebody else! So use with caution.
You now should be able to:
- Apply ANY MX setting to Zebra device using AW
- 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 AirWatch!
Was it useful? Do you want a post on Custom Attributes or Product Provisioning? Let me know your thoughts!