What’s This OMA-DM Thingy All About?

I’ve mentioned briefly in the SCMDM forum posts, and will mention further in upcoming posts, the word OMA-DM. But it might not be familiar for everyone. I’ll try to explain 🙂

The computer biz is fond of the word “standards”, but they don’t always implement them properly or agree upon how they should be implemented. And sometimes they’re just ignored. I will not go into that discussion, but rather make a short summary of some standards involved with mobile devices, more specifically OMA. (Like other standards not everyone adheres to it.) For those of you that already understand the OMA standards forgive me for my simplified treatment of the topic. I’m aiming for an introductory approach here.

Hit the following links for more details on OMA:
http://en.wikipedia.org/wiki/Open_Mobile_Alliance
http://www.openmobilealliance.org/

It’s actually a family of standards, but for now, it’s two of these standards we care about for this article; OMA-CP, and OMA-DM. One often refers just to “OMA”, or “OMA-DM” if the context is given. Some functionality is overlapping, and if your device supports OMA-DM it’s implied that OMA-CP is also supported. (For so-called smartphones this is usually not an issue. But not-so-smartphones often support just OMA-CP.)

OMA-CP, Client Provisioning, is the “easy stuff” like setting GPRS settings, APNs, etc.

OMA-DM, Device Management, is controlling settings on the device; disabling camera, changing registry keys (on Windows Mobile), etc.

Another standard that is in the works, but not in widespread use yet, is SCOMO which enables application install/uninstall and managing software on the device. (SCMDM uses WSUS for this purpose at the moment.)

It is a common misconception among many people that Windows Mobile doesn’t support the OMA-DM standard, and that you are “forced” to use Microsoft-specific approaches. This is not entirely true. WM does support OMA-DM, and have done so for some time now, but Microsoft does have it’s own proprietary extensions. So do Nokia on their Symbian devices. And that’s not really a bad thing either. There are differences in the platform and what the OS provides, and I don’t see anything wrong in the device supplier enabling me to take advantage of the benefits of their specific platform. Would you really expect MS to not provide you with an ActiveSync-interface, (which is one if the killer features in a business perspective), when it is so tightly integrated into the OS?

But Microsoft did one thing “wrong” with their OMA-DM bits. There never really was an easy way to use it, as the OMA-DM server would need to be trusted for security reasons (you wouldn’t want a random server to disable your camera would you), and there isn’t an easy way for a user to establish this trust. It could be bootstrapped by the operator if you’re using operator-branded devices. But then AT&T devices would only trust the OMA-DM server of AT&T, T-Mobile devices only trusting T-Mobile server…You get the picture. And in my part of the world we usually buy HTC-branded devices not tied to a specific operator so these devices don’t trust any server at all 🙂

Sure, you can trust all the servers you want if you have physical access to the devices before they reach the end-users, or if you create custom ROM images for the devices. But this is sort of against the intended purposes of a standard like OMA-DM, and is a workaround at best.

How does Nokia solve this you say? Ok, say you have Nokia OMA DM installed (a part of the Intellisync Mobile Suite, which Nokia abandoned last week). You create the device server side. Then your device receives an SMS with the OMA-DM server settings. You need to supply a PIN-code, (provided through a different channel), to store these settings (including GPRS/APN if you don’t have network connectivity), and when you connect to the server you type in the first four characters of the thumbprint of the SSL certificate on the server. It works, is secure, but hardly user-friendly.

Microsoft worked their way around this in WM 6.1 with their SCMDM client-parts known through the “Domain Enroll”-icon. Instead of a PIN-code you have the enrollment password, and you must have GPRS connectivity to perform the enrollment. But the underlying process is pretty similar. If you have used “clean” Windows Mobile devices, you will have seen they don’t necessarily have GPRS configured out of the box, and it’s a real hassle to do manually, but lately device manufacturers have started including applications that will provision settings based on the SIM-card you insert so the situation has improved.

For apparent reasons Microsoft created their client to specifically work with their server, but OMA-DM is a generic standard. So theoretically there’s no reason a Nokia device can’t connect to SCMDM and enroll, and a Windows Mobile device connecting to a different server than SCMDM. In practice there are details of course that complicates the picture, and different solutions to the challenges. Not going into them in detail here, but roughly it goes like this:
– Nokia can create a client for their devices that is able to follow the same enrollment procedure as a WM device against SCMDM. This would still require SCMDM on the server side, and might not work against other solutions.
– Create a server that exposes the same interface as SCMDM meaning that a Windows Mobile device basically perceives it as SCMDM. Still the need for a Symbian client though…
– Create your own server, and create clients for the devices you intend to support. (Remember the tricky part is establishing the client-server relationship, once you’ve done that OMA-DM is able to roll and follow the standards.)

So far most software publishers choose the last option. We really need to adopt a standard for establishing the relationship, while maintaining security – the standards work fine once this is accomplished 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

*