Managing XR Devices: 3 Challenges Companies Face with Legacy MDMs
- Last updated: August 24, 2022
In this article, we will unpack three of the biggest challenges companies face using legacy MDMs for XR headsets.
Challenge #1
- File restrictions that limit support for large file sizes.
- Limited app version management.
- No or limited differential updating.
- No simple way for content creators & app developers to share content.
- Minimal visibility into issues with app deployments.
- No or minimal visibility into app usage.
Challenge #2
- Confusing web interface.
- Features built for tablets and smartphones but are usually not relevant for XR devices.
- Initial device enrollment: often with multiple manual steps that require putting on an XR headset.
Challenge #3
- Most MDMs don't offer in-VR Single Sign-On (SSO).
- Most MDMs have no ability to control what users see and do in VR with a launcher.
Quick Links:
We’re regularly hearing from XR teams at companies that legacy MDMs aren’t working for them. The issue is that MDMs are made for phones, tablets, and laptops––not VR & AR headsets.
We’ve helped almost a thousand organizations worldwide, including dozens of Fortune 500 companies, manage fleets of headsets. Some teams are setting up and managing thousands of devices. We hear the same challenges over and over.
Most MDMs have no ability to lock down the headset with a VR launcher, which means users can browse the web or download apps without oversight. Setting up XR devices on legacy MDMs typically involves time-consuming setup processes.
Confusing web interfaces can make for a poor admin experience. Another frustrating headache admins face: VR apps and file sizes are much larger than most mobile apps. Legacy MDMs have file restrictions that make it impossible to deploy large VR apps and 360 video.
All of these limitations (and others) add up over time. As organizations scale, it becomes increasingly painful to use legacy MDMs that aren’t truly designed for XR devices.
It’s certainly appealing for IT administrators to use the same MDM they’ve always used with new XR devices. Unfortunately, legacy MDMs do not offer much functionality for XR devices, making it incredibly difficult to manage headsets at scale.
A recent example?
Client X (who asked to remain anonymous) had 4,000 XR devices in over 30 locations. As a healthcare provider, they were excited to get XR headsets into the hands of clinicians and patients to improve patient care.
They deployed their fleet of XR headsets with a legacy MDM platform. But unfortunately, their legacy MDM had minimal app support for XR and no way to lock down the in-headset experience for users. And with all their devices already shipped, admins couldn’t effectively deploy content, manage devices, or control what users see and do in VR.
Shipped every single device back to their IT department at the cost of $10,000.
Invested countless hours to manually factory reset thousands of XR headsets and installed ArborXR, an XR MDM.
Spent another $10,000 to ship all of the XR devices back to their original locations.
Can you imagine spending all that time and money just to start over with the right tools? Can your organization afford to make the same mistake?
Disclaimer: UEM, MAM, EMM, MCM, MIM… There are too many enterprise acronyms to keep track of! Each of these relate to the solutions companies use to manage their devices. For the purposes of this article, we chose to focus solely on MDM features for XR devices. We define MDM for XR simply as solutions for managing XR devices, content, and the in-headset experience.
Let’s take a look at three key components that make managing XR devices very different from phones or tablets.
Challenge #1:
Issues Installing and Managing Apps
File Size Restrictions
Legacy MDMs typically have file size restrictions on their platform, often maxing out at 2GB. This limitation means their software can’t reliably handle the file sizes needed for XR. While file sizes for MDMs on phones and tablets measure in megabytes, VR apps and files measure in gigabytes. For enterprise and education, many XR apps are over 2GB, and 360 video ranges from 500MB to 15GB. Plus, we expect immersive VR/AR experiences to only get larger in the years to come. A 2GB file restriction is unworkable for modern XR deployments, which is why ArborXR has no limits on file sizes.
But the challenges for legacy MDMs don’t end there.
App Version Management
App developers often push new builds to fix bugs and provide new features. For example, suppose there is a new app build to test. Admins may want to select a handful of devices to test with the new app version while keeping the rest of the deployment on the stable app version. Unfortunately, using different versions of an app often isn’t possible with legacy MDMs because they do not offer app version management.
Most MDMs only allow one version of an app on the platform at a time. Every time a new app build is available, the new version replaces the old one, so you can’t easily roll back to a different app version in case of unexpected issues.
In ArborXR, app version management enables admins to upload all builds of an app to one central location in the MDM and deploy specific builds to certain devices (or groups of devices).
Differential Updating
As mentioned above, most MDMs may require the app to be completely replaced with a new version for every update. Then once the new build is uploaded, it will need to be re-deployed in its entirety, adding even more time to the process.
Now, multiply the above process by hundreds or thousands of devices. Imagine downloading gigabytes of data over Wi-Fi for a fleet of a thousand headsets. Updating apps quickly becomes a painful, time-consuming process that won’t work for most IT administrators.
ArborXR enables differential updating to significantly reduce the time of updates between app versions. The benefit of differential updating is that only the portion of the app that is new to the build installs. For example, let’s say a new version of a 1.2GB app comes out, including roughly 100MB of changes. With differential updating, only 100MB of changes push to the headsets. At scale, this saves admins significant amounts of time.
Content Sharing
Legacy MDMs also have poor solutions for Independent software vendors (ISVs) and content creators.
The legacy MDM process for managing content is painful and time-consuming:
- The only way for an Independent Software Vendor (ISV) to share content is to send their APK via a filesharing platform (like Dropbox or Google Drive).
- After downloading the APK, admins manually upload the file to the MDM.
- Each update to the app requires the above two steps. And due to the VR file sizes, this will take hours each time there’s a new update.
- Legacy MDMs do not have app version management. Only one app version can be on the MDM platform at a time.
- When admins deploy an updated app version to headsets, the entire app package will have to download again since legacy MDMs do not have differential updating.
All this together means admins will be spending incredible amounts of time and network bandwidth every time an update comes through.
On the other hand, organizations can get content sent from ISVs directly through an XR MDM. “Content sharing” in ArborXR gives creators a simple way to deliver content to organizations and update it as needed.
Content sharing with an XR MDM like ArborXR is easy & efficient. No sending filesharing links. No manual uploads or updates on every device for every new version.
The ISV gives (or revokes) access to apps and can easily manage updates. When there is a new app version, ISVs upload it to their library, and admins have immediate access to it.
In ArborXR, app updates are automatic once a new build is uploaded. No additional actions are needed. ArborXR also lets you determine when updates push to XR devices with options including scheduled, plugged-in, plugged-in + scheduled, or automatic.
Minimal Visibility on App Deployments
Legacy MDMs do not have many tools to help you track the progress of app deployments. Once admins have remotely deployed apps and files to XR devices, it’s essential to see if the content is installing, pending, completed installing, or if any errors have occurred. To check the status of an app with most MDMs, admins have to put on the XR headset and launch the app to see if the app is installed correctly.
Unfortunately, putting on every headset to check the status of an install and troubleshoot is unworkable for most administrators. And even more so when they are managing devices at multiple locations. As admins add more devices to an XR fleet, it becomes increasingly important to have an overview of the status of devices.
For most MDMs, admins have to put on each headset to ensure apps have been installed correctly. In ArborXR, the status of app installation shows in real-time. Admins can see which apps are installed correctly and any headsets that have errors in the “Deployment Status Page.” The status page reports on all deployments across all devices in an organization. Admins can search or filter by app or file name, group, date, etc.
This visibility makes it easy to see which devices are ready for use and which have errors to address. ArborXR also gives the option to opt-in to email alerts any time there is an error deploying an app so that admins always know immediately when there is a problem.
Challenge #2:
Poor UI Experience for Admins
Confusing Web Interface
Most MDMs’ web interfaces are confusing and difficult to use. Plus, many MDMs require training and certifications before an admin can use their platform. IT admins often want to stick with their legacy MDMs because they have invested significant time and resources into their MDM solutions. So, it is understandable that admins are reluctant to consider alternatives because it involves learning a new user interface, even if it is simpler.
However, admins will struggle to use their existing software solution because many features are irrelevant for XR devices or simply do not work. There is no indication of which features will or will not work for XR devices, leaving admins guessing. Legacy MDMs’ fall short for organizations because they don’t solve the unique pain points for VR/AR. Most MDMs are built for phones, tablets, and laptops–not AR and VR devices. To manage XR devices effectively, organizations need an MDM designed for XR.
“Trying to use a legacy MDM for XR deployments is hell.”
– Fortune 500 Client
Initial Device Enrollment
Setting up devices for the first time is often more complicated than it needs to be on a legacy MDM. Here is one specific example that illustrates the initial device setup. The process of enrolling just one device is time-consuming and inefficient:
- Download MDM client APK (app) to PC.
- Install the client app via adb command (through terminal on Mac or command line on PC). This means admins must plug in each individual headset one at a time, then type and run a specific command.
- Next, set the MDM client app as the “device owner” via another adb command.
- Put on the headset and slowly type in VR a username and password, using controllers and a virtual keyboard.
This process isn’t so bad for a few headsets, but imagine how frustrating this is when you are dealing with a fleet of hundreds or thousands of devices! It’s a deal-breaker for most IT departments.
In comparison, ArborXR’s setup process is simple and quick:
- Download the ArborXR Device Setup App.
- Plug in one or multiple devices and enroll with a click. The process takes about ~20 seconds for most XR headsets and ~80 seconds for the Meta Quest.
- Now admins can remotely manage, configure, and deploy content on enrolled devices from ArborXR.
ArborXR also offers alternative enrollment options, such as batch configuration support for the VIVE Focus 3 and QR code enrollments coming soon for devices that support this (i.e., VIVE Focus 3, Magic Leap 2, and Vuzix devices).
We recently announced a strategic partnership with Qualcomm with the shared vision to provide “zero touch provisioning” by working with their OEM partners. Our goal is to make it easier than ever to set up and remotely manage all your devices at your fingertips.
Challenge #3:
No Control Over the In-Headset Experience
No VR Launcher
We hear from customers daily asking us how to set up an XR headset with kiosk mode or a VR launcher.
While some MDMs have a version of kiosk mode for laptops and tablets, the functionality can be limited for XR headsets
Most MDMs don’t provide a VR launcher, which means you won’t be able to customize the experience and you’ll have no control over what users see and do in VR.
What’s the difference between kiosk mode and a VR launcher?
Kiosk mode restricts the headset to a single app. So, when a user boots up a headset and puts it on, the designated kiosk app automatically launches. Users won’t be able to access any other apps, the web browser, or the app store.
A VR launcher is a customizable enterprise environment in the headset where the user can launch multiple apps. Admins can fully control what apps and settings users have access to. Brand the environment with company logos, custom background environments, while locking down native web browsers and app stores.
Even many of the most well-known legacy device management platforms haven’t included kiosk mode for popular XR devices. For example, according to VMWare, while they are working on a launcher, they don’t currently offer kiosk mode on any XR device.
Without these features, admins are stuck with gaming devices that aren’t designed for a professional setting.
Kiosk mode and ArborXR Home (a VR launcher) help admins lock down the device, limit distractions, and create a more focused user experience.
Kiosk mode is easily managed from ArborXR’s web portal, where admins can select one single app and designated settings that users have access to.
With ArborXR Home, admins can customize what apps are available to users, prevent access to web browsers and app stores, and even configure the launcher with a company logo and 360 background.
VR Single Sign-On (SSO)
No legacy MDMs offer VR Single Sign-On (SSO). SSO allows admins to know who is in the headset. VR SSO requires an MDM provider to build a VR environment where users input their login credentials before accessing any content. Once authenticated, users can open and exit only the apps IT admins have given access to without re-authentication.
Authentication expires when the headset is powered off or when a user logs out, securing the apps and data behind SSO once again. Locking access to shared devices and knowing who is in the headset is critical for many universities and large companies.
Final Thoughts
Simply put, legacy MDMs aren’t the right tool for organizations wanting to get into AR and VR.
Legacy MDMs offer broad support for many mobile devices but they are missing critical support for XR devices.
Organizations don’t want to find themselves in the same position as Client X, spending thousands of dollars and hundreds of team hours to switch to a new system.
| Legacy MDMs | ArborXR | |
|---|---|---|
| Hardware Inventory | ||
| Wi-Fi Configuration | ||
| Policy Management | ||
| Easy to Use | ||
| Easy Setup / Enrollment | ||
| Reliable Installs of Large Apps | ||
| Version Management | ||
| Differential Updating | ||
| Visibility on App Deployment | ||
| Content Sharing | ||
| Manage User Experience In-Headset | ||
| Session Data / App Usage | ||
| User Authentication In-VR |
A dedicated XR MDM, like ArborXR, lets you confidently manage XR devices with faster setup, better management, flexibility with deploying apps and (most importantly) control over the user experience in the headset.
Learn more about the technical differences between legacy MDMs and XR MDMs by following the link below:
Subscribe to stay in the know!
