This blog addresses specific use cases and deployment considerations for Android Enterprise Rugged device deployment in enterprises. This can be leveraged by partners and industry experts to successfully deploy Rugged Android devices.
Note: Since all environments and use cases are unique, please use your best judgement. This document only covers most commonly seen use cases and scenarios in the industry today.
Understanding the Solution Stack
- Communication methods: Real-time communication between the console and device happens over either the AWCM (AirWatch Cloud Messaging) or Google’s FCM (Firebase Cloud Messaging) service. We recommend using AWCM for our deployments. Settings are found on the console under Settings > Devices & Users > Android > Hub setting. Note, when set to always running, Hub maintains a constant connection with the AWCM server outbound. In case of no activity or connectivity issue, AWCM can become disconnected. The retry interval value to make active connection to AWCM is two minutes by default in the HUB agent.
- Hub is the management client on the device and is required to be installed in order to manage Android devices. Hub downloads the profiles and applications, pushed as Apps&Books, only from device service server. Products can be delivered from either Device Services server or Relay server, depending on whether or not a Relay Server is active at the OG the device is enrolled. If using relay server, only Application components and File/Action components are delivered by a Relay Server.
- Profiles, applications and products are installed on the device using the native Android APIs. In addition to this, OEM specific capabilities can be set by leveraging App configuration (key-value pairs) on an “OEMconfig” app, published by their respective OEMs on the play store. For example, Samsung has published OEMconfig app called ‘Knox Service plugin’ in the play store. Zebra has published their OEMconfig app called ‘Zebra OEMConfig powered by MX’. This enables zero-day support from EMMs on any new capability offered by an OEM. As soon as OEM releases a new feature, we can add the respective app config value in our assignment page on the UEM console to configure the device.
With Android enterprise, Google has moved away from using OEM service which in the past required EMM to create OEM service for each OEM framework.
Android Enterprise Enrollment
Android devices can be either enrolled as Android Legacy or Android Enterprise. Starting Android 7+, majority of the Rugged OEM manufacturer have met Android Enterprise requirements for their devices. A complete list of requirements for rugged devices is published here by google: Android Enterprise Recommended requirements
Note: We do not recommend using the legacy Android enrollment workflow for your deployments. If the customer is using devices that are not supported, we recommend having the discussion to explain the risk involved with OS upgrade beyond Android Q which will not support legacy DA APIs. If you still go ahead with Android Legacy deployment, it is a good practice to register with Android Enterprise at top OG and then change enrollment restriction to support legacy devices. This will ensure the console is configured for future deployments.
Bulk enrollment Selection Criteria:
Rugged devices are enrolled as Corporate dedicated devices in bulk in majority of the use cases. This blog list down different enrollment methods available today and the selection criteria. For detailed enrollment flow with screenshots, refer Android – Rugged Management on VMTestDrive website.
- QR Code enrollment: All Android Enterprise devices (Including non-rugged) support this method of enrollment. We recommend this method of enrollment when,
- The environment has rugged and non-rugged devices (Samsung, Honeywell & Zebra). This method gives the same enrollment experience for Admins and support teams to manage devices in the future.
- No relay server in the environment. Since this QR code reader is downloaded from the play store followed by the Agent from the play store or a link, no relay server is required. For Android 9+, QR code is shipped with the operating system and there is no need to download the same from google store at the time of enrollment.
- Barcode Enrollment: Use this method of enrollment when,
- Devices support physical scanning hardware and a scanning utility in the operating system natively. Currently, Zebra and Honeywell only support this method of deployment. Zebra uses their native app called StageNow utility.
- Relay Server is present in the environment. Relay server is a local FTP server that will store the enrollment package and post enrollment product packages to be delivered to the device.
- Device setup time is crucial to the roll out. Since this enrollment downloads all the packages from a local Relay Server, time to rollout is less as compared to OR code enrollment.
- Zero Touch Enrollment: Use this method of enrollment when,
- No end user or staging user interaction is required. Device needs to be locked in an EMM.
- Workflow similar to DEP for iOS is required. This ensures devices can never be enrolled as Work Profile or used as personal device.
- This requires a registered reseller to upload a list of devices in zero touch portal. Ask your customer to create a configuration package and assign to appropriate devices. GSuite is not required to leverage Zero touch enrollment.
- Sideload Staging is for Android Legacy devices only.
- The Group ID specified in the QR code configuration page will not take precedence over User Group Mapping. If the user group mapping is enabled, the device will enroll in the OG the staging account user group is mapped to. Once the end user enters credentials to login, it uses the Shared Device settings to determine if it needs to use user group mapping or fixed OG depending on this configuration.
Public and Internal Applications can be deployed under Apps & Book on the UEM console. Internal apps can also be deployed using Product provisioning. Since internal apps can be deployed using both the methods to the same device, selection depends on the use case. If installation of the app depends on any custom parameters such as adapter time, power, battery percentage etc., product provisioning is recommended.
Note: An uninstall of the application pushed as a product, requires creating a new product with Uninstall manifest to remove the application from the device. Unlike, apps pushed from Apps& Books, admin can easily remove the app from the app list page. If user deletes the assigned app from the device, the behavior to re-queue the app install command remains the same across Apps&Books and Products.
Default Systems Apps – managed devices
- Play Store
- EMM app (if bundled in the system image)
Note: If you do not see the system apps on the home screen after enrollment, add the app id in the whitelist app group and push an app control profile to the device with enable whitelist system apps. You can also approve these apps from the admin work store portal and import in Workspace ONE UEM as public app and assign to your device.
For Rugged Enterprise Devices, profile deployment is the same as any Android Enterprise device. For Samsung and Zebra devices, you can enable OEM profile to leverage Zebra specific settings in the profile UI. However, moving forward all the OEM settings will be controlled by OEMconfig app. Apart from that, HUB agent also supports Zebra Stage Now XML to be pushed as custom settings from the console.
StageNow is Zebra’s next generation Android Staging Solution, supporting Nougat, Oreo and built on the MX 7.0,7.1, 7.2, 8.0 ,8.1,8.2 and 8.3 platforms. It allows simple profile creation, and easy device deployment with a simple bar code scan, tag read, or audio file play including:
- Connecting your device to a network
- Configuring device settings and security
- Performing OS updates
- Installing and launching applications
- Wiping and resetting the device
- Enrolling into your MDM
A complete list of MX feature matrix: http://techdocs.zebra.com/mx/
Generate the XML from the StageNow tool, paste the XML as is under custom setting payload from the console to apply to your device.
On Android, profile with credential payload requires a device passcode on the device to install successfully. Android requires certificate database on the device to be encrypted securely. All Android devices since Marshmallow are indeed encrypted out of the box by default, but without a device password, that encryption is not really any benefit. To insert a Certificate into the work KeyStore, it’s a security requirement to add a PIN/Passcode on the device. Once you add a PIN/Passcode, the master encryption key is then re-encrypted and the new key used the PIN/passcode to help derive the new encryption key.
Product provisioning gives the flexibility in delivering components (profile, applications and files) to the device and the sequence of actions on these components as manifest. Customers deciding between pushing profile and Apps using Device>Profile and Apps&Books vs Products, need to evaluate if the installation of these components on the device is dependent on an assignment rule or condition. If yes, they have to use product provisioning instead of standard profile and Apps&Books. Components unlike standard profile and Apps&Books cannot be assigned directly to the devices. You will need to create products to assign and deploy to devices.
Note, certain manifest today in product provisioning is only supported on specific OEM devices with OEM service. VMware publishes OEM service application for each device manufacturer. Please search for the OEM service on resources. A complete list of supported features as per the OEM can be found in Platform OEM Service Overview documentation. As noted, this will change in the future with the introduction of OEMConfig application build by the OEM.
Collecting Product Job Logs:
Once a product is assigned to a device, policy engine checks for the assignment rule criteria before queuing the product. (This usually takes 1-2 minutes) Each product gets a unique job id for each device. In case of relay server, policy engine also checks if product is available at the relay server before queuing the product. If multiple relay servers are created at an OG, it will check for the product transfer complete on all relay servers. Every product installation generates job logs.
You can verbose the logs for either each device or entire OG. Use the below steps:
- Navigate to Settings > Devices & Users > Android > Intelligent HUB settings. Scroll to product provisioning job logs and select DEBUG.
- Navigate to device summary page > More Actions > Job Log level. Change the job log level to Debug.
Once set to verbose, re-push the product and collect the job logs to identify the issue in case of failure. Note, if you are using relay server, verbose job logs will also mention the relay server IP you are connecting. This is useful to troubleshoot in provisioning using relay server.
For SaaS customers, we recommend setting the job logs to verbose only in your test OG or test devices to prevent writing logs in the DB for each device across your environment.
You can also view the product job logs from the HUB application on the device under Products tab.
App upgrade using Product
Applications pushed using products needs the following consideration when upgrading to new version:
- At no instance, you should have 2 products with different version of application assigned to the same device.
- Removing the assignment from a product does not queue an app remove command. You require a separate Uninstall Manifest in the product to perform app removal.
For in place upgrade, with every new version, create a new product and add smart groups to this new product and remove the same smart group from previous version of the App install product. You can also choose to create a new smart group and edit the assignment for previous smart group to achieve the same end state.
Note, the above is not true for profiles. In case of using launcher profile, always ensure you remove the old version of launcher profile when pushing a new launcher profile to the same device.
Reprocess vs Force reprocess
Reprocessing a product will re-queue the product installation command to only failed devices.
Force reprocess will re-queue the product installation to all devices assigned to that product.
Conditions gives the ability to control the execution of the product based on the set parameters or user acceptance. Some condition like defer condition, can cause the devices to check in with the console frequently. Recommended practice is to perform staged role out of products with active conditions and monitor the Device Server health to ensure no CPU spikes.
Relay server act as a content distribution node that provides help in bandwidth and data utilization control. In typical customer environment, every location has a relay server. Devices in that location connect to their respective local relay server instead of Workspace ONE UEM console to receive products. If connectivity to relay server fails, after 5 attempts, it defaults to the device service server to receive the package.
The relay server can be deployed as Pull or Push type relay server. Pull relay server has an AirWatch Pull Service running which makes an outbound connection over port 443 to Workspace ONE UEM SaaS to receive all the active products created and assigned to the device in that specific OG. In Push Relay server, Workspace ONE UEM pushes the products created in the console to the local relay server. Since this requires an inbound connection to the relay server, we recommend using Pull Relay Server for all SaaS customers.
Since Pull relay service makes an active connection to the console and policy engine checks for the products to be present on all relay server before queuing the jobs, sizing the environment is very critical. Please contact your VMware EUC representative before sizing this for your customer specially for large environments (<500). Assignment of products with such large number of relay servers must be staged in batches.
Note: Only Apps and File/Action are deployed through relay server. Profiles do not get pushed from relay server.
Relay server troubleshooting:
- Check the console server is accessible from the relay server. You can use the following command to confirm for SaaS Customers:
curl -Is http://www.CNXXX.awmdm.com | head -1
This should give a 200 OK response. If no response, check with the networking team.
- Check the config file on the relay server under Pull Service > Conf > App properties. The URL should match the console URL/pullcontent.
- Once console connection is established, all the products that have an active assignment created in the console should get copied to the file path provided in the relay server configuration under console connection field. Check if apps are copied in APPS folder, file/action in PFILES folder. Under JOBS folder, you will see product manifest XML.
- If no files, check the logs. For Pull type relay server, the service writes logs to the AirWatch > Pull Relay Service > Logs folder.
- On Linux server, pull service is called ‘awpullservice’. Use the below commands to restart: Sudo service awpullservice restart.
- On the console, you can also create a new product and check if the product is queued for the relay server under Devices > Provisioning > relay server > List View. Select the active relay server and navigate to More Actions > Advanced info. Check the content delivery info. If it is working as expected, queued count value should be 0. If you see a value other than 0, and it stays on this, check the relay server logs or folder location to confirm.
Note: Remote Viewing Files is only a feature for Push Relay Server.
Custom attributes enable administrators to extract specific values from a managed device and return it to the Workspace ONE UEM console. You can also assign the attribute value to devices for use in product provisioning or device lookup values.
A very common use case, custom attributes can be used as assignment rule parameter for Product Provisioning. This enables admins to create a rule using custom attribute name and value to control the assignment of a product to only devices which meet the criteria as set in the rule.
Note, Custom attributes can only be created at Customer OG. There is no limit on how many custom attribute and values you can create today in the system.
Custom attributes are stored either as XML files on the device or in the custom attribute database on the Workspace ONE UEM console server. Intelligent HUB on the device reads in the enterprise folder for any XML and reports back to the console. Admin can create these XML locally on the device or make API calls to the console to set the value for this specific device.
Custom Attribute values cannot return the following special characters: / \ ” * : ; < > ? |. If a script returns a value which contains these characters, the value is not reported on the console. Trim these characters from the script’s output.
For latest updates on Android, please follow VMware End User Computing Youtube Channel.