MobileIron Supports OEMConfig
Webinar transcript - View the full webinar
Host: Good morning and welcome to our webcast titled OEMConfig. We have with us Adrian Kok, Director of Product Management at MobileIron. During this webinar, we will cover how MobileIron supports OEMConfig to simplify device configuration with Android enterprise and speed up new functionality for organizations.
Just a few housekeeping items before we get started. Please direct your questions to the Q&A box as we will answer the questions at the end of the presentation. Do know that this session is being recorded and after the webinar is finished, you will get a link to the recording. Now, let's get started.
Adrian Kok: Thank you. Good morning and good evening to folks. Through this webinar, we will cover the basics about OEMConfig, we tie it into why this is important, and we'll take a few minutes at end to cover some questions.
Before we get started, we want to really review our vision of where the modern work environment is going. At MobileIron, we're really concerned about trying to give people the best enterprise computing experience and part of this is about enabling choice.
Choice for the user, choice for the admins about picking the right device for the right work‑piece and being productive anywhere and anytime. Part of this choice entails allowing users and admins to choose the right tools.
We'll cover this as why Android is really important, but choosing the right tools meaning allowing users to pick the right device with productivity. The native experience is also pretty important because we are no longer in an era where somebody gives you a device, it is popped in a desktop and that's where you become productive.
IT is no longer in that mode where you are only working in a fixed location. We want to be productive anywhere, whether it's at home, whether it's when we are out traveling on the road, whether it's on a factory floor, whether it's on a logistics hub.
Wherever we are, we have more and more devices that we need to be productive with. The privacy part is really important and we'll cover a bit about privacy and why this affects the AppConfig part of it.
When we go to the device choice, what is fundamental to why Android is such an important part of this is that Android as an open‑source operating system has really powered the mobility revolution by making a first‑class mobile experience available across many different device types.
We're not just talking about smartphones and tablets which are really essential for many users and consumers today. Increasingly, what we're seeing is that Android is being used in devices on the shop floor, in the back office, in the warehouse, in the manufacturing plant, everywhere.
This diversity of devices lends itself to interesting problems. When we go back five, six years ago, what happened when enterprises wanted to use a mobile device? They would basically look at, "OK, how can we manage this?"
Each different device manufacturer would then offer a separate API for an EMM like MobileIron to manage device, which is well and good until you come to this explosion and this diversity of manufacturers. At the last count, I think MobileIron customers use devices from more than 200 different manufacturers.
It's going to be impossible and infeasible for this ecosystem to be managed in a consistent manner, which is why we were really happy when Google introduced about five years ago the Android Enterprise mechanism which standardize how enterprises can manage Android devices.
I'm going to give you a brief primer about this. We're not going to go in detail about these different modes, but we will point you to a link to another webinar where you can learn a bit more about this.
What happened about four, five years ago was Android introduced different management modes for Android. It really depends on who the ownership of the device is, whether it's a BYOD or whether this is a corporate‑liable device.
On the work profile side, Android Enterprise comes in different flavors. One of them is called the work profile, where the Enterprise basically manages apps and data in a container that is separate from the device.
There is no ability to manage the device in that mode. That is important because earlier, we talked about protecting the users' privacy.
If I'm having my Enterprise device apps on my device, I don't want the admin to be looking at what my personal app usage is like, looking at what personal apps I have on my device and so forth. That work profile protects the privacy of the user.
Going onto the right‑hand side, you have a managed device where administrators basically control the entire device. Some of you who use iOS will treat this as similar to a supervised device. This is a corporate‑liable device.
I can manage the entire device, I can lock it down to where is suitable for my use. What was more interest recent is this combination of a work profile with the managed device. This is something that MobileIron supported earlier this year.
This is one of the more interesting modes, where with Android 8, you're allowed to separate both the managed device from the work profile.
This is just a five‑minute overview of what Android Enterprise is. This is the mode which Google and the Android community is moving its management modes through. In the Android world, in the past four or five releases of the Android OS, Google has been building an additional functionality, allowing...
For example, in Android 9 that was released earlier this year, Google allowed enterprises to configure an APN, an access point for cellular connectivity. This was not possible before.
What was possible before was through custom APIs from different device manufacturers, but Google builds in the common management functionality that most users will be able to take advantage of this to basically set device policies, to ensure basic encryption to protect the device, to distribute apps and so forth, which is really good because that creates a common ground by which these Android devices from these hundreds of manufacturers can be managed in a consistent fashion.
However, when we go into the mobility experience further, you'll find that there are different devices meant for different use cases. We've talked to some of our customers and prospects.
Some of them, for example, have Android devices that are deployed on manufacturing locations where it's a fixed Android device and it's got unique networking requirements like I need an Ethernet connection. I'm not going to use WiFi because it might be pretty flaky.
I need the device to be connected at all time. A wired connection is the best, so manufacturers might offer an API to configure something as basic as an Ethernet connection, which is not a problem for desktops and Windows and Macs and all that, but on an Android device, this concept is really uncommon.
Google has no APIs to configure Ethernet because most smartphones today don't all carry Ethernet options. Custom encryption. Some of the devices that we come across are intended for diplomacy and heavily regulated industries. Some of these industries or governments may have specific requirements around what kind of encryption needs to be done.
How does Android accommodate that? Instead, what we have is different OEMs offering different APIs to manage these encryption nodes, which becomes really tricky because this is not meant for the mass market, it's meant for specific deployments. How does EMM support all these options that are being offered out there?
Another example will be power management. Some of the ruggedized device manufacturers, for example, are replaceable batteries often provide additional details about defining thresholds by which batteries can be set to be requiring a replacement.
These are some of the examples where there are different use cases which require custom Android devices which is well and good. One of the benefits and strengths of Android is that it allows itself to be used by a wide ecosystem of manufacturers.
We have a challenge here by which manufacturers who choose to build new features for their specific customer base, now have to introduce new APIs and basically, talk to all the customers and all the EMMs to say, "Hey, support this API."
What happens is that there's a huge timeline between when a problem is identified, a manufacturer offers an API, and when an EMM even actually gets to the API. It could be a couple of years before EMMs actually get to support it which really slows down the pace of innovation.
One of the key things we see Android being good at is because of its diversity, many people get options for being able to buy devices that are suitable for them. We want to see that innovation continue unimpeded.
Let's look at how this problem is being solved. This problem is not new. What's happened before is that the enterprise app community has had this problem. Three years ago, the various EMMs and the app developers came together to answer this common problem, "I have got an enterprise app that I'm pushing to my users but I need to configure them."
What had happened before was all this enterprise app whether it's an email app, whether it is a VPN app, or a simple thing that's a browser, a document viewer, they need to be configured with credentials, with servers, and all that.
These have to be integrated for each specific in the EMM independently, whether the EMM will configure to the APIs or whether the app is custom configured for that EMM. That problem was painful. You have an app that had a version for MobileIron, another version for another EMM.
App developer whenever they revise the app, they've got update the MobileIron specific app, update the other EMMs apps. It became a real constraint on the innovation for app developers.
What happened about three years ago was MobileIron with the EMM community and the app developer community, together with Apple and Google, came together and defined a set of specifications called AppConfig, by which app developers can publish and expose a set of configurations that will be available for admins like yourself, to be able to discover and to configure it.
What happens on the Android side is that these app developers basically build a set of configurations. I'll show you a couple of examples in the next slide. I wish you publish it in Google Play.
You can go to Google Play today, you can pick up, let's say a VPN app like Cisco's Ankara, Pulse Secure. A mobilized email app offers AppConfig, Email+ for MobileIron. If you pull that into your EMM console, you will be able to discover a set of configurations that the app expects.
All this is done without the EMM having had pre‑knowledge of what the app does. The app publishes the configurations, the EMM reads it, presents it to the admin, the admin then configure it and this is pushed down to the app. The app gets it and after that, the app is basically able to operate based on your custom configuration.
This is working really well today. With Android Enterprise, we've got large deployments since 2017 and 2018. Right now, a large number of our customers are using Android Enterprise and this has been proven in production for app ecosystem.
Examples of this, for example, Email+. This is a sample from our console. Although this a MobileIron product, but we did not pre‑configure our console to show specific configurations for Email+. Our app can publish its configuration, MobileIron can read it and display it to its admins.
On the right side, you see an example for Google Chrome. Again, we have no special connections with Google Chrome's team. They publish and set a set of common configurations that they allow administrators to modify. They publish it. The administrator can discover it, can configure it, and deploy the app without any special integration effort.
Which is really great because this allows Email+, it allows Chrome, it allows any app to basically add and modify the configurations without waiting for an EMM to support it. That's the real ideal of allowing innovation in the app ecosystem.
What's happening today is that we have OEMConfig. OEMConfig was published by Google about a month in the AppConfig community. What the ecosystem came to realize was that this way of solving the problem from apps could be extended to Android, to device manufacturers.
How is this going to happen? The mechanism that this is going to take place is that the OEM can publish the AppConfig app on Google Play. This is not new.
Google publishes, for example, Google Play services on Google Play itself. It's a utility that manages services on the device. Some of the OEMs are published, updated tools on Google Play itself. OEMConfig will be another app that OEM publishes on Google Play.
What can happen once it's up there is that an EMM like MobileIron can discover this app. You can import it into your console. You can discover a set of configurations that this app produces. For example, you can have an Ethernet configuration is not available in standard Android, the OEMConfig app can support it.
You can have custom encryption options. I want to encrypt the AC card, I want to turn on this fancy encryption algorithm that is proprietary to us that nobody else uses, which is great. You can expose that configuration up there. Once the admin discovers it, he can then configure it. Then, he can push that configuration down to the device where the OEMConfig app is already present on the device.
Some device manufacturers are going to have, eventually, this OEMConfig preloaded on their devices. Some manufacturers have also expressed to us that they want to be able to have the OEMConfig loaded onto the device, including legacy devices that may not have it available in the first place. Both options are supported.
If the app is not yet on the device, it can be pushed onto the device. If the app is already on the device, it can be updated from Google Play. Once it's updated, this set of configurations will be applied to the OEMConfig app on the device.
What's the magic that makes this happen, is that because the OEMConfig app is delivered by the manufacturer and owned by the manufacturer, it's got access to the private APIs for the device. This is something that Yemen sometimes get. We do this with some of our device manufacturers, as well.
The keys to these private apps is really something that the OEM configures. The OEM has the ability to either protect the APIs, with either custom certificates, some licensing mechanism, that by necessity, because they provide the OEMConfig, this app will have custom extended privileges.
When you push that configuration to the OEMConfig app, you will be able to configure the device with the custom policies that you, as an admin, have discovered and applied to the device.
All the steps, from one, two and three...the beauty of this is it is supported today with the whole AppConfig mechanism that MobileIron enables today.
There is still work to be done. For example, one of the things in the future that we are working with the ecosystem on, is this return channel. When you send a configuration to the device, how do you discover that this device has configured, for example, the Ethernet configuration, whether it's been applied successfully or not? That hasn't been baked in yet. We are working with the ecosystem to make sure that that's in place.
Some of the other work in interoperability. As device manufacturers start introducing this, what we are working with actively with device manufacturers is making sure that the configurations that expose, which may be pretty different from a typical app configuration, is able to be rendered and configured successfully by an admin.
The basic principles are there. It is supported today with the AppConfig, and as additional work that's coming up to make this enabled across the board.
There are a couple of caveats, though, to know. The reason why I introduced Android Enterprise at the beginning, and this concept of having a work profile versus the device owner.
This mechanism explicitly works for corporate‑liable devices. If your OEMConfig app is deployed inside a work profile or a BYOD mode, one of the constraints for Google's deployment of BYOD is that you don't want an enterprise app to have access over the device.
You don't want the Enterprise app to, basically, take over the device, because that device really doesn't belong to it, it belongs to the user. For non‑corporate‑liable apps, that deployment will not work. It is designed to work for corporate‑liable devices.
Whether you have a managed device and, in the future, there's a manage device with a work profile, this OEMConfig app will be supported in that mode.
It's pretty exciting. There's a lot of work going into this. We're seeing a lot of interest from the ecosystem. What are some of the next steps?
We support this today. We encourage you to come talk to us, especially if you don't have an Android deployment or you're thinking about expanding an Android deployment. We can provide you more details about this.
If you want to learn a bit more about Android Enterprise, we did spend a lot of time about behalf of webinar from earlier this year that we...I had a webinar with Google to talk about Android Enterprise, well worth your time if you want to get up to speed about it.
Asking your OEM of choice if this support OEMConfig? In a previous webinar, somebody asked me, "Why would an OEM do this? Why would an OEM support this?"
We think that's benefits for both the OEM and the EMM community to support this. For a OEM, specifically, they get to increase the pace of innovation. They can introduce new hardware types and allow these configurations to be exposed to you as an administrator without waiting for the EMM to support it. This is really important.
The second one is that, when they do this, they get control back over the discovery and the configuration of these devices. They get what might be called zero‑day support.
They introduce a new device that has a fancy new, let's say, a 5G network, and they want to allow you, as an administrator, to configure a 5G network. Until that configuration becomes part of Android standard APIs, most EMMs may not be able to get there.
However, with OEMConfig, they can expose a specific configuration utility for you to be able to configure some new feature that they have introduced to your market.
This is all very exciting, and we are pleased to be supporting this. We are really pleased that Google has published this on the AppConfig Community. The spec are actually up on AppConfig Community.
It's a good FYI for you. You're probably not required to understand that. There's more targeted at OEMs and EMMs who have to implement [inaudible 24:11] .
That covers this portion. I'm going to run through some of the questions now. Somebody asked questions about native apps for non‑Android Enterprise devices.
Android Enterprise is actually required as of Android 6. Google has made it a mandatory part of Android devices. I believe, if we look at our own customer base, I think more than 90 percent of the Android devices are capable of Android Enterprise today.
If you enroll your device with Android Enterprise, you get this capability. Native apps, for example. If you have got a native email app...we know some device manufacturers have already started publishing their native email into the Google Play Store, so that you can discover their native email, you can configure it, you can push it to the device.
That's model that we have seen to be successful, and that's addressing the ecosystem.
At this time, are there any more questions? We've going to wait a couple more minutes. Going once. Going twice.
We have the website available there, and if there are no other questions, one of the things we encourage you to do if you are considering an Android deployment, you've got more questions, you have to learn more about how MobileIron can help you with your deployments, reach out to us.
There is one more question that came out. "How do you leverage Android Enterprise and Samsung not mobile?" This is specific to a specific manufacturer. We support Android Enterprise with Knox, and that's being integrated right now.
It's just probably a topic for a separate discussion with our friends from Samsung, but there's a convergence between Samsung Knox and Android Enterprise that we can talk about in a separate discussion.
Another question is, "Is there a list of participating OEMs?" We are in discussions with a number of OEMs right now. I'm not sure if some of them are still testing out the OEMConfig apps. I'm sure in due time they will be making this available.
We're also in discussions with the AppConfig Community. In fact, our CMO, Ojas, has a podcast where he talks with Kurt Russell, who's one of the architects in the AppConfig Community.
There's some interest in growing this list of supporting OEMs, but that's on its way of being made more broadly known.
There are some questions about, again, more about which OEM support this. We know that many OEMs are in discussions right now. We are not in a position to declare when they will turn this on, but this is something that we encourage you to do.
Go talk to your OEM. More likely than not, they probably will have heard about this program. In any case, we are sharing this program with any OEM that we talk about, because it's really advantageous to them. They get the controls back into the hands of what features they want to expose to you.
Going down the list to the questions, there's a question about a managed device with a work profile. A managed device with a work profile today is supported by MobileIron. We push apps today into the work profile.
Coming up in the future, we will enable apps to be deployed into the personal space. This is the mode where the OEMConfig will be enabled. Good question there. It's something that is supported with Android 8, and we are going to be making sure that this works with OEMConfig.
Some questions about the links to this document. This will be sent out, and you will have the links to some of these websites that I've referenced.
"Are there any plans by Android to change their stance for employee‑owned devices with work profile?" I'm not sure. Maybe there could be more clarification, because the employee‑owned device with the work profile is supported as of Android 8. We have just turned this on. In fact, we're one of the first EMMs to enable this.
We've seen some companies start to roll this out, especially in Europe, where concerns for data privacy is pretty important. Stay tuned for this. This is a capability that we expect to be more fully deployed in the near future.
I'm liking the questions. There's a lot of questions over here. I hope I've answered most of your questions. If I haven't, we are hopeful that you will contact us for some of your Android management needs.
If there are no other questions, I think we're going to close this. Deepa.
Host: Thank you, everyone, for joining us for today's presentation. We will be sending out the recording of this event after the session. If you'd like any additional information, please visit us online at mobileiron.com/android, or you can email us at firstname.lastname@example.org.
That concludes our session today. We hope to see you again in the future webcast that we have. Thank you very much and have a wonderful day.