MDM setup: customer-managed

VR devices are typically managed by a mobile device management system (MDM) hosted by the customer in an enterprise setting. Here are the following key use cases for device management:

  • Securely tracking the current-state corporate and non-corporate owned devices used by employees and at various locations

  • Pushing any files, content, and application updates for business-critical applications such as browsers, anti-virus software etc.

  • Enforcing any policies and restrictions for security and privacy reasons

  • Remotely troubleshooting the device as and when needed

  • Conduct remote wipes in cases where the device is lost

Customers can generate enrollment assets which can then be used to enroll the devices into their own MDM system. While doing so, customers should keep in mind the various requirements and prerequisites covered below.

MDM Compatibility

The following table shows the level of compatibility for various MDMs with the headsets supported by Strivr:

Actively Supported Devices VMWare WorkspaceONE Azure Intune SOTI Mobicontrol

Pico Neo 3 Pro

Pico Generic Firmware ✔ ✔ ✔

Strivr Custom Firmware:

  • B1415

  • B1404

✔ ✔ ✗

Pico G2 4K S (Sunsetted)

Pico Generic Firmware

✔ ✔ ✔

Strivr Custom Firmware:

  • B316

  • B368

✔ ✔ ✗
Pico Neo 3 Compatibility VMWare WorkspaceONE Azure Intune SOTI Mobicontrol

Enrollment

Manual Enrollment ✔ ✔ ✔

Headless Bulk Provisioning

 ✔ ✗ ✔

Bulk provisioning w/ Strivr device setup

✔ ✗ ✗

Multi-level device grouping

✔ ✗ ✗

WiFi and Security Restrictions

Automated WiFi enrollment (includes WPA2-PSK, Certificate based, Enterprise)

✔ ✔ ✔

Restricting WiFi changes

✗ ✗ ✗

Disabling USB debugging

✔ ✔ ✔

Disabling Factory Reset

✔ ✔ ✔

Disabling Application installation and uninstallation

✔ ✗ ✗

PIN Locks

✗ ✗ ✗

Timezone configuration

✔ ✗ ✔

Remote Wipe

✔ ✔ ✔

Applications, Files, and Updates

Application deployment and management

✔ ✗ ✔

File deployment

✔ ✔ ✔

Firmware updates

✔ ✗ ✔

API Integrations

✔ ✔ ✔

General Prerequisites and Requirements

MDM Agent Compatibility and Automated/Headless Enrollment

For the customer to enroll headsets within a self-managed MDM instance via a headless (non-GUI) approach while leveraging a third party provisioning partner for bulk enrollment of devices, it is recommended that:

  • The MDM software has a compatible agent that can install, run, and perform headless enrollment on Android 8 or higher, typically via ADB (Android Debug Bridge).

  • MDM client installation and enrollment in the customer’s environment is automated and headless. Any MDM that doesn’t support headless execution or requires any manual intervention is not supported for enrollment via Strivr.

    • Customers ensure that any Terms & Conditions / Disclaimer screens are disabled for the scope of headless enrollment because these may require manual intervention.

Enrollment File / MDM Credentials

To successfully enroll the headsets into the customer’s MDM instance, customers are required to provide / generate:

  • An enrollment file that typically contains an encrypted username / password for the customer’s MDM instance (.bin for example) OR

  • A username/password pair which can be passed as arguments during silent installation/headless execution.

For headsets currently supported by Strivr, VMware supports enrollment of Android (AOSP) devices via the Android Device Enrollment functionality. Furthermore, Strivr recommends VMware customers refer to Android Device Management for Workspace ONE UEM to further understand how the VR devices can be managed once they are fully enrolled on the WSO instance.

The headsets currently supported by Strivr are compatible with VMware Workspace ONE UEM (formerly known as Airwatch). Headless enrollment for Android based VR headsets can be achieved by generating a Sideload staging package within the VMware Workspace ONE UEM Console. While generating this package, Strivr suggests the customer follow the best practices regarding Organizational Group segregation as described in the sections below.

MDM Agent Version and Instance URL

Customers are typically required to provide the following information while working with an operations partner to conduct headless enrollment:

  • The version of the Android HMD agent that the customer has tested successfully on an Android headset for headless enrollment

  • The enrollment URL for the MDM instance. Furthermore, customers should ensure that the URL is public-facing.

For headless enrollment to VMware Workspace ONE on Android headsets, customers are required to provide the specific version of the compatible Intelligent Hub APK available on the Workspace ONE website.

AOSP Support

Ensure that the MDM supports AOSP devices that are not integrated with Google Mobile Services (GMS).

For VMware Workspace ONE, console administrator will have to conduct Android EMM registration, even though the AOSP VR headsets are not GMS integrated

To ensure that the devices receive compliance policies, firmware updates, applications, files etc. in a timely fashion, Strivr recommends customers enable Airwatch Cloud messaging. More information on AWCM can be found here

Enrollment User - Service Account

Strivr recommends customers use a service account to build enrollment usernames and corresponding enrollment assets for the headsets. This is to ensure that all shared devices are consistently enrolled using a (or a set of) service accounts which makes tracking and user management easier.

Single Enrollment User/File

Note: This requirement only applies to headsets that are provisioned by the Strivr operations team. Customers should work with their respective provisioning partners to understand the specific requirements regarding enrollment credentials.

The Strivr operations team requires that the customer creates a single set of credentials for all headsets within that tenant.

  • Strivr does not recommend sending separate credential files/username-password pairs for separate MDM environments that the customer maintains.

  • In case this is a hard requirement based on the nature and scale of deployment, the customer should work with Strivr’s implementation team to further discuss this. This will be evaluated on a case by case basis.

Once the customer has defined a plan for MDM deployment including the profiles and policies that need to be pushed to the headsets after deployment, Strivr does not recommend making any changes until the headsets are shipped to the customer.

Device Profile Configuration

Strivr recommends the customer perform only the following MDM configuration activities upon initial enrollment of devices.

  • Pushing WiFi profiles for cert-based or PSK (WPA/WPA 2) types.

  • Check for any policies that may prohibit device enrollment on an external network.

  • Pushing minimal group policies/privileges to the devices. In general, Strivr recommends pushing these policies once the customers have received the headsets.

The Strivr Operations team will configure headsets to have access to a WiFi network at the provisioning location, which will be used for enrollment activities including retrieval of the MDM config file.

Strivr does not recommend pushing any large files (such as anti-virus software) which may substantially increase the enrollment time per headset, thus causing delays and potential enrollment failures beyond the stipulated service thresholds.

For detailed information on how to configure Android device profiles via Workspace ONE UEM, please refer to Android Profile Review. Specific information on WiFi profile configuration can be found here.

Android Debug Bridge (ADB)

Android Debug Bridge (ADB) over USB is required to be enabled to conduct headless enrollment processes via relevant scripts, install Strivr apps, and write enrollment success files to the storage on the headsets after the MDM is installed and enrolled in the customer’s environment.

  • In case of Strivr provisioned headsets, Strivr will not be able to start the provisioning process with a disabled ADB setting.

  • Strivr recommends that customers work with the relevant IT stakeholders to enable ADB for the scope of provisioning.

Enabling Non-Market App Installations

Customers are required to configure the MDMs to allow for non-market app installations. This is required to ensure successful installation of any updates for Strivr specific applications which are not listed on the Google Play Store.

Time zone settings for content throttling

For HMDs that are on Android 10 or higher (for example Pico Neo 3), Strivr recommends customers configure the device time zone to match the time zone that is used for content throttling settings within the application configuration (App Config). The application configuration file deployed on the headset is currently set to the UTC timezone.

Strivr also recommends customers work with the device provisioning partner to identify the time zone that is set on the devices at the time of provisioning.

For customers using VMware Workspace ONE UEM, UTC time zone and periodic sync with the NTP server can be conducted using the Date/Time for Android functionality within profile setup.

Enrollment success logging

Note: This is a hard requirement for headsets provisioned by the Strivr operations team

For a provisioning partner to detect that the enrollment process for a device has completed, the MDM should be configured to write a file after the enrollment steps have been completed programmatically to delineate successful enrollment and identify any issues in a scalable manner. For headsets provisioned by Strivr, customers are required to configure the MDM with the following name and path:

/sdcard/Download/Enrollment_success.log

As soon as that file exists, Strivr will write a file in the following name and path to acknowledge that the enrollment has succeeded:

/sdcard/Download/Enrollment_success.ack

The customer should communicate with Strivr on the appropriate timing for pushing any special settings/software, after the success.ack file has been written.

Customers using Workspace ONE can log enrollment in the following way:

  • Use the Files & Actions for Products functionality to upload an enrollment log file and configure it to be dropped in the above mentioned path.

  • Then use the Products functionality within Workspace ONE to package the enrollment file and define a manifest for the staging package to perform a profile push followed by enrollment success logging.

Pin Lock

PIN locks are typically employed for securing headsets during transit from a provisioning location to the final location, or vice versa. Strivr recommends customers not apply PIN locks until the provisioning of the headset has been completed since it may potentially block a user from troubleshooting during the provisioning process. Here is the list of headsets and their compatibility with MDM driven PIN locks:

Headset Model Compatibility
Pico Neo 3 ✗
Pico G2 4KS ✔

Best Practices / Recommendations

Dedicated Resource Allocation for MDM Software Administration

Strivr recommends the customer identify and allocate an IT resource responsible for administering VR devices on their internal MDM instance. This IT resource will work with the respective operations team to provide necessary enrollment assets and information to conduct the process. It is recommended that:

  • The resource has knowledge of the MDM software in scope, specifically with regard to device enrollment, Wi-Fi, group policy, and software update configuration.

  • The resource has access and permissions for creating and editing device profiles, creating and editing organizational groups, configuring various provisioning steps, and editing specific device configuration. This is required for testing changes and enabling fixes as needed, to ensure success in the enrollment phase.

OG Segregation and Mapping for Devices

Strivr recommends customers follow a hierarchical device pool structure to segregate VR devices in their respective MDM systems across the following dimensions

Strivr recommends customers maintain a dedicated device pool that’s clearly segregated from other corporate-owned devices within the organization.

  • This is especially beneficial for the headsets currently supported by Strivr which are based on AOSP (Android Open Source Project).

  • This helps ensure that any security policies, integrations and applications that apply to device types such as laptops and mobile phones aren’t accidentally applied to VR headsets.

Strivr recommends customers segregate device pools across lower / staging environments, pilot and full scale / production fleets. A detailed description of this segregation is covered in the “Recommended Architecture Setup for Device Fleets” section of the Strivr Platform management & maintenance page.

Strivr recommends customers further segregate device pools by individual locations. This can be helpful in the following ways:

  • Customers can bucket specific locations into a pilot or test fleet as recommended below, thus segregating them from the remaining production locations to selectively roll out software, firmware, and third-party content updates.

  • Customers can selectively deploy third-party content by locations, based on the scope and learning objectives for the content in scope.

  • Customers can selectively configure WiFi profiles and other group policies across each of the locations, if applicable.

Strivr recommends customers segregate device pools across different types of devices. An example of this can be segregating device pools for Pico G2 4KS and Pico Neo 3 Pro devices. This can be helpful in the following scenarios:

  • Different device types may contain different versions of operating systems (Android 8 versus 10), thus needing different firmware update versions.

  • Specific device types may support only a particular feature set such as 6 degrees of freedom content versus 3 degrees of freedom content.

Sub-segregation of content within the broader groupings listed above may be required in some of the following scenarios:

  • A single geographic workplace location often contains a variety of business units and employee roles. In cases where work groups or roles require different learning content, subdivisions within the broader geographic locations should be used.

  • Customers may wish to have a mix of test and pilot devices deployed across different locations and teams to evaluate different networking and user scenarios as part of a robust deployment plan.

Strivr recommends that customers segregate devices that are being provisioned / staged from the devices that are already present within the fleet. This can be achieved by creating separate device pools and ensuring that any newly enrolled devices are automatically added to the provisioning group and do not get mixed with the core production device pool.

  • This enables the customer to apply different settings / software versions to these devices such as Strivr in-headset software versions and default network setup.

  • This is especially important for customers who disable ADB connections once the devices are shipped to the actual locations for security reasons. Strivr recommends that customers work with the corresponding IT stakeholders to disable ADB, if it is a mandatory requirement per organizational security standards. However, in specific troubleshooting circumstances, ADB may have to be enabled again and thus Strivr recommends the customer work with the corresponding IT stakeholders to perform this troubleshooting.

For customers using Workspace ONE UEM, the above recommended segregation can be achieved in a hierarchical way using a mixture of organizational groups and smart groups.

Default Network Setup

Strivr recommends that the customer configures the network profile push event in their MDM instance such that it adds that network profile to the list of WiFi networks in the HMDs, but connects to it only if the specific SSID is in range. This will ensure that the network profile push doesn’t disconnect the device from the initial WiFi SSID that the device is connected to at the point of provisioning.

Bluetooth Settings

Headsets currently supported by Strivr use bluetooth to pair with the controller(s) which are used to point and select in Strivr’s in-headset software. It is thus recommended for the customer to enable both outgoing / incoming bluetooth connections for the VR headset. Disabling bluetooth may cause controllers getting unpaired or not functioning properly.

Enabling Camera

Headsets that support 6 degrees of freedom typically require cameras that are plugged into the front of the headset for boundary setting/spatial positioning. Regardless of whether a training experience is 6DoF or 3DoF, these cameras are crucial for the general functioning of the headset and are required for supporting boundary setting and detection. Thus, it is highly recommended customers not configure their respective MDM system to disable cameras. If cameras are disabled, customers may face issues with general functioning of the headset.

Customers using Workspace ONE UEM can ensure that cameras are enabled by checking the “Allow Camera” setting within the “Restrictions” section on the Android profile creation functionality.

Unblocking Core Headset Launcher App

In scenarios where Strivr Player as an application is run in kiosk mode and set as the default launcher for the headset, it is recommended customers ensure that the base launcher for the headset is not blocked by the MDM. If the base launcher for the headset is blocked, this may create issues with the general functioning of the headset.

For Pico Neo 3, Pico VR Launcher is the core launcher that supports key functionality such as boundary setting, switching WiFi, re-pairing controllers etc. Regardless of whether Strivr Player is run in kiosk mode or is set as the default launcher, blocking Pico VR launcher might create issues with general functioning of the headset and yield a black screen, making the headset non-functional. Strivr recommends the following application packages not be blocked via MDM configuration:

  • Pico VR Launcher: com.pvr.launcher

  • Pico VR Shell: com.pvr.vr shell

Customers can manage allow-listed devices and deny-listed devices using the Application Group Configuration Functionality within Workspace ONE.

Single App Mode

To add an extra layer of security in order to prohibit the user from breaking out of the Strivr Player application, Strivr recommends the customer configure VMware Workspace ONE to run the device in single application mode, if the MDM supports this functionality.

Android Application Restrictions

Customers may be able to configure specific restrictions within the MDM instance to prohibit a learner from exiting the Strivr application. These are as follows:

  • Disabling a user from uninstalling an existing application such as Strivr Player.

  • Disabling a user from installing an external application.

  • Disabling a user from modifying application settings such as Force Stop, Default Application settings. etc.

  • Disabling a user from conducting a factory reset which wipes the device, thus allowing the user to break out of the Strivr Player app as well as the MDM-enforced restrictions.

For more detailed information on how to configure these restrictions, please refer to documentation for the MDM.

For customers using Workspace ONE UEM, customers can configure the above-mentioned restrictions using Restrictions profile setup for Android devices.

Scalable Distribution Mechanism for MDM

Strivr recommends that the customer have a scalable distribution mechanism to accommodate enrollment, content distribution, and software distribution to all headsets in scope. This becomes particularly important after a certain number of headsets, based on the type of MDM. Thus, Strivr recommends the customer check MDM-specific requirements to determine and procure necessary infrastructure.

For customers using Workspace ONE UEM, relay servers are the recommended mechanism for scaling an MDM solution. Strivr recommends you work with your VMware account team to define the appropriate architecture based on the specific use case and scale.