Let’s be honest. I have been focusing pretty much only on managing Windows Mobile devices so far. There are however other devices out there in the market as well, and some people prefer these over WM devices. But we can’t let users run around with unmanaged devices just because they are running other operating systems. So today I thought I’d take a closer look at managing a Nokia E75, which to my knowledge is the latest enterprise device coming out of Finnland.

I have previously covered some of the high-level aspects of OMA DM (What’s This OMA-DM Thingy All About), but this time I’ll try to go deeper into the details.

Why OMA DM you say? Well, it is the standard for mobile device management isn’t it? Ok, that’s not the only reason Most MDM solutions will have you install a client of some sorts on the device, and even if that’s not a big issue it would be better if we didn’t have to. It also means that once a new device comes out your MDM platform should in theory be able to support it immediately without tweaking, or waiting for an updated version of the client. And for those of you who have been following my SCMDM articles; that product also uses OMA DM as the “engine”. Microsoft has however created a friendly wrapping on top hiding the details. As more and more platforms become available it would be great if you could deploy the same XML to all devices and have them apply the policies. We still have a distance to go as iPhone and Android currently does not support OMA DM, but I don’t find it unlikely they will add support at a later time. (And given the process of deploying third-party apps to those devices it’s really the only way to get MDM for those devices unless Apple and Google change their strategy.)

As I already stated I’ll be using the E75 from Nokia. Nokia has two main device series – E (as in Enterprise), and N (as in eNtertainment) in the smartphones department. They also have some other “dumb” devices, but those aren’t interesting from an MDM perspective. Both E and N are based on Symbian Series 60, third edition, with Feature Pack 1 & 2 having slightly different internals. Series 60 fifth edition is available in a few devices, and the whole open sourcing of Symbian might bring other interesting stuff in the future. We’ll focus on what is available today though And let me state this clearly right off the bat – if you want to deploy N-series in an enterprise setting because they’re basically an E-series device with better mp3 player and better camera support… Don’t! Yes, they are similar. Yes, some of the Ns are more “sexy”. Yes, I understand why some people prefer them (and I like them myself as well). They just aren’t made for enterprise use. They lack some features you should have in the enterprise, and they are generally tricky to manage through OMA DM (even though OMA DM is supported – more on that later). If you choose the proprietary client approach you may be able to use them, but double-check that all features you need are available.

Now I’m certainly not going to write an MDM server from scratch so I’ll also be using an ready-made OMA DM server. SCMDM is based on OMA DM, but with some MSFT specific implementation details so I can’t use that for this scenario. Instead I’ll be using Afaria from Sybase for this little lab exercise. Installation and configuration of Afaria is out of the scope for this article, but it’s not really relevant either. You may assume it’s just a generic OMA DM server. There are other offerings on the market as well: the discontinued Nokia OMA DM (the sibling of Intellisync), Funambol, FromDistance, etc. Depending on exactly how the different servers implement the standard there might be slight differences in the steps you need to take, but the principles are the same.

There are a couple of different phases involved in taking control of a device and connecting it to a server:

- Bootstrapping.
- Enabling trust.
- Enabling TARM.
- Provisioning policies.

Let’s look at these steps in sequence.

Bootstrapping
The first thing you need to do is bootstrap the device. This consists of sending out a binary SMS to the device containing the server address, user id, shared secret, etc. I configured the server to use an SMS gateway for this purpose, but using an SMS modem is also an option. I then create a new device server side providing a user id (can be arbitrary or linked to AD/LDAP), provide phone number and IMEI of the device. Optionally you can provide a PIN the user needs to enter on the device to open the SMS as a security measure.

Enabling Trust
Once the device has received the SMS, and you open it the device will connect to the server. And here’s another important fine point – the communication requires SSL and you can only “hack” parts of OMA DM to work over plain HTTP. This also means your root certificate must be trusted on the device. You can import the certificate on the device, but using a commercial CA is easier. When connecting you need to type in the first four digits of the leaf certificate thumbprint to acknowledge/authenticate the server. (I agree, slight hassle, but we do want some security mechanisms.) This should establish the trust relationship between the server and the device, and depending on what you want to do you’re ready to start managing your devices.

Enabling TARM
But if you want to do security related stuff there’s an extra step you need to take. You need to enable TARM on the device. What is TARM you say? It’s an acronym for Terminal Access Rights Management, and this is the module that enables you to manage features like power-on-password and encryption. TARM is only available on E-series as far as I know. (If you know of any other devices please correct me.) And this means that even if the N-series have OMA DM, and power-on-password, you are not going to be able to manage this from your server… You should send out this xml before you attempt to do more magic to the devices (My experience was that forgetting this step would result in the server logs reporting “ok”, and the device reporting “ok”, but no policies actually applied. No errors/warnings given.)

Provisioning Policies
Ok, we’re ready to actually perform some modification of the config of the devices. I’ve chosen the approach of manully typing in xml to do this. What xml you say? The devices take their instructions in form of commands specified in an xml format. What to type into these xml documents can be found through googling. Try “OMA DM encryption DDF” for instance, (DDF stands for Device Definition File), and you’ll find a pdf on Nokia’s site. This documents commands, values, features, etc related to the encryption feature. So why not have a crack at typing up some xml.

<?xml version="1.0" encoding="utf-8"?>
<Package primaryaction="Replace">
  <Action action="Replace">
    <Node>
      ./DevEnc/PhoneMemoryCmd
      <Value>1</Value>
    </Node>
  </Action>
  <Action action="Replace">
    <Node>
      ./DevEnc/UIState
      <Value>3</Value>
    </Node>
  </Action>
</Package>

This will enable encryption of the internal storage, and prevent the user from turning off encryption. I have not enabled encryption of the memory card, and as it stands the user cannot enable it either.

The curious thing about encryption on Nokia is that you can enable encryption without defining a password, which is different than Windows Mobile 6.1 where you are required to provide a password when enabling encryption. It sort of defeats the purpose though to use encryption without access control so you’ll probably want to enable some policies regarding password and lock period as well while you’re at it. A sweet thing about these devices is that they include a dedicated chip to handle on-the-fly encryption/decryption so there’s no big performance hit. It’s not included in every E-series device though, so you should check that before buying lots of devices.

Microsoft also has DDFs documented on MSDN, so you’re free to experiment on Windows Mobile too if you like, but as I said I wanted to have a look at another platform for once.

Moving on from here you’d probably want to look into setting other polices, deploying software to the devices, retrieving inventory information, etc. I believe I’ve covered some of the basics here, and if you are looking at managing Symbian devices you are encouraged to experiment on your own. (As per usual I do not know what I might be covering in the future on this blog.)