MobilityDojo.net

Update – DojoCrypt goes 1.0

0 | November 19th, 2008 | Posted in Updates, Utilities

In a previous post (http://mobilitydojo.net/2008/09/16/windows-mobile-61-how-do-i-encrypt-my-device/) I explained some details regarding encryption of files on Windows Mobile, and I also presented a tool designed to aid in troubleshooting/testing device encryption. I added a few disclaimers regarding known issues with the utility called DojoCrypt though. I have now gotten around to actually do something about some of those shortcomings, and upgraded version number to 1.0 in the hope that it deserves the status

This new version includes a “Check File”-tab where you can test the encryption status of a file. (This is functionality previously found in CheckEncryption.exe which I haven’t really published here, only linked to over at the SCMDM forums. But I have fixed file browsing this time.) This feature is “stand-alone” in the sense that you don’t need to use DojoCrypt’s encryption to test the file. This might come in handy if you are applying include/exclude filters from SCMDM, (or other MDM solutions using the built-in encryption in Windows Mobile), and want to check that you’ve set it correctly. Including folders, and excluding subfolders requires you to be very sure you’ve typed it correctly.

Also the program will now list your current inclusions/exclusions at startup as that was sort of a showstopper previously. There’s also some minor code changes. (And hey, I even made a shortcut on your “Programs”-menu.)

And here’s the interactive part of this post; I am still only releasing a version for WM Professional. I can probably produce a version for WM Standard as well, but I don’t know if there is a demand for it. If nobody is using this utility I’m ok with that, but then it would not make sense to put another version high up on my to-do list. So it’s up to you. Let me know if you are interested in a version for Standard, and I’ll see what I can do

Here’s the download link:
http://mobilitydojo.net/files/DojoCrypt_10.cab

Update – Hosts File Editor – Version 1.0.0.5

1 | November 5th, 2008 | Posted in Updates, Utilities

Maintenance work is tedious, but sometimes it’s a necessary evil So I decided to fix some things in my Hosts File Editor (http://mobilitydojo.net/2008/10/09/using-a-hosts-file-on-windows-mobile/).

Hosts File Editor PPC/Pro:
I noticed a small bug while testing on the Windows Mobile 6.1 Classic that made the app crash. I added a try-catch in the proper place, and I think it’s fixed now.
A commenter on the post said it was not possible to run on devices without a physical keyboard, so I added a checkbox to activate/deactivate the SIP. (Software Input Panel.)

Hosts File Editor Smartphone/Standard:
Marco (http://myitforum.com/cs2/blogs/mnielsen/) asked if I didn’t have a version for Windows Mobile Standard devices. I didn’t, but I decided to make an attempt at providing that So here you go – see if it works for those of you with that flavor of Windows Mobile.

As always – give me feedback if it doesn’t work, or if it’s lacking in any way. I’m not making promises that I can satisfy what you are asking for, but the Smartphone/Standard version would not have existed if there hadn’t been a request made for it

Download:
Windows Mobile Professional: http://mobilitydojo.net/files/HostsFileEditPro.exe
Windows Mobile Standard:http://mobilitydojo.net/files/HostsFileEditStd.exe

System Center Mobile Device Manager 2008 – Distributing Software – Part 2

2 | October 31st, 2008 | Posted in How-to's, SCMDM

After the first part (http://mobilitydojo.net/2008/10/30/scmdm-distributing-software-part-1/), the server “things” should be setup for distribution. But we would still need something to distribute – cue this part of the guide

Creating a cabinet file and signing it
This being a “perfect” little lab we’re not going to develop a large and complex program to test – that’s not necessary for illustration purposes. Maybe it’s just me, but I dislike the “Sliding Sound” the HTC TyTN II has enabled by default (it also applies to some other HTC devices). So as a signing demo we’ll create a quick cab to disable this noise.

This would be the xml we need to perform this task.

<wap-provisioningdoc>
<characteristic type=”Install”>
<parm name=”InstallPhase” value=”install” />
<parm name=”AppName” value=”Disable Sliding Sound” />
</characteristic>
<characteristic type=”Registry”>
<characteristic type=”HKLM\Software\HTC\SlidingSound”>
<parm name=”ActiveSlidingSound” datatype=”integer” value=”0″ />
<parm name=”SlidingSoundEffect” datatype=”integer” value=”0″ />
</characteristic>
</characteristic>
</wap-provisioningdoc>

Create a new file called “_setup.xml”, and copy the xml above to this file. We then need to create a cab.

Open up the command prompt and run “makecab _setup.xml DisableSlideSound.cab”.

If you have Visual Studio installed you already have makecab. If not you’ll need to download it as a stand-alone tool - http://support.microsoft.com/kb/310618

You should now have a cab file, that is ready to be signed. How to verify it’s unsigned?

You don’t have a “Digital Signature” tab in File Properties:

image_thumb13[4]

A few rules regarding signing. You don’t sign every file you want to send out to devices. You only sign executable files. This means .exe, .cab/.cpf and .dll, You don’t sign .mp3, .txt, etc. A cab-file is like a zip-file with more advanced capabilities (cab = cabinet), and can contain both exe-files and dll-files. And this is important – you need to sign the content, and not just the cab. A signed cab with unsigned/untrusted content will be untrusted!

Well, we’ll have to sign it then won’t we.

Open up your command prompt, and change to the directory where signtool.exe is located. (For simplicity I dropped the cab in the same folder.)

Run “signtool.exe sign DisableSlideSound.cab”.

Now there are numerous options to the signtool command, and I’m not going into them here. This is the easiest one, and it works since we only have one code signing certificate, and no advanced needs. You can get a GUI if you like though:

We’ll just verify the file was signed by checking it’s File Properties again:

Deploying Code Signing Certificate to DeviceWe had to configure the DM server to trust the CodeSigning certificate, and the devices are no different. We use Group Policy to deploy the certificate to the device (using the SCMDM GPO templates):

And remember to set the “Action” to “Install”:

Deploying applicationWe can now add this “application” to our suite of WSUS-distributed cabs.

Let’s create a package in the Software Distribution Console. Locating “Software Packages” on your left hand side, and you’ll be able to click “Create” on the right hand side.

It’s pretty much just about following the wizard and clicking “Next”, but I’m showing the screenshots for completeness. (Except for the filename and descriptions everything is left at the default setting.)

Nothing wrong with the package I suppose, so we will approve it right away. (I created a device group called “HTC TyTN II”):

Success:

Checking installation status on deviceIt’s nice to check that the application actually installed itself on the device. This one you can check just by sliding out the keyboard, but there’s no audio in this article so I’ll also show you the other way to tell.

The “Managed Programs” utility under Start->Settings is where the records are kept regarding which applications have been distributed by SCMDM.

Before installing:

After installing:

Details:

It seems like a lot of steps to perform what seems like a very basic task. But when you have performed the steps above once, you don’t have to do them all over again so it’s probably not that bad once you get used to it

System Center Mobile Device Manager 2008 – Distributing Software – Part 1

0 | October 30th, 2008 | Posted in How-to's, SCMDM

If you have either followed my previous guides, or tackled it without my assistance, you should now have a working lab deployment of System Center Mobile Device Manager 2008. Having an MDM solution installed is of course all good, but let’s get around to using it for something useful. You would think the natural thing to start with would be setting policies, etc through Group Policy. And you’d have a good point there. However I decided to create a guide for distributing and installing software instead. Primarily because there are some aspects of it that might be less intuitive than for instance using Group Policy.

I have also seen that not everyone finds it straightforward. There are guides available on TechNet, but I’m still the kind of guy who enjoys testing for myself and documenting the process

To create an end-to-end scenario illustrating the actions involved I’m going to show the following steps:
- A few explanations regarding code signing.
- Preparing the CA.
- Preparing the DM/WSUS Server.
- Creating a small application, and signing it.
- Deploying application to a device.

Code signing and Windows Mobile
I’m not going to go deep into the details of code signing, and it’s intended purpose. It’s not a new concept, and is used on both Windows XP and Windows Vista, but there are a few details that are different on Windows Mobile than on the desktop which makes it useful to be aware of the implications.

If you want to know more about code signing, from a high-level perspective, I recommend the following article: http://www.ddj.com/architect/210004209
Yes, it’s about Adobe AIR, but if you leave out the Adobe-specific details it is just as relevant for Windows Mobile.

The purpose of code signing is not security by itself as some want you to believe. A signed application can be every bit as malicious as an unsigned application, but with a signature you can trace it back to whoever created it. And ideally you should have an idea if the signature belongs to someone you trust. Windows Mobile implements a two-tier authentication scheme regarding code signing. When you try to run a cab-file or an exe-file the signature is always checked. If it’s not signed, or signed by a publisher not in your list of trusted publishers two things can happen depending on whether your device is running one-tier or two-tier lock mode. (Usually decided by your OEM/device provider.)
One-tier: You’ll get a prompt warning you you’re about to run an untrusted app, and a confirmation prompt asking if you want to run it regardless of this fact. (As in “I accept the risk and consequences.”)
Two-tier: You’ll get a prompt telling you this application is untrusted and cannot be executed. In other words you’re stuck.

I haven’t seen a Pocket PC/Professional device with anything else than a one-tier, but on Windows Mobile 5 most Smartphone devices were two-tier. Nowadays most Smartphone/Standard devices are also running in one-tier so it’s not the same issue it used to be.

You can change whether a device is one-tier or two-tier provided you have the access rights to do so. SCMDM also has the ability to modify these settings in a number of ways; accepting untrusted, hide the prompt, modify the trust list, etc. Let’s not go into those details here.

Preparing your Certificate Authority
If you have a functioning SCMDM installation you already have en Enterprise CA installed in your environment as well, so we’ll assume the general properties of the CA are configured already.

If you are only deploying commercial third-party applications these should be signed already with a Mobile2Market-certificate. (Also a larger topic not included in this article.) But what we want to do is deploy our own applications, or re-sign third-party apps for security reasons. This means we must make a few modifications to our CA which by default is not configured to perform signing of applications

Signing applications is called “Code Signing” in the context of a Microsoft Server 2003 CA, and has a predefined template that needs to be enabled. Perform the following steps in the “Certificate Authority” MMC:

Right-click in the right pane and select New->Certificate Template to Issue.

Choose “Code Signing” and press “OK”.

You should have an extra template listed.

The next thing to do is to create an actual certificate to use for signing as well. If you are using Visual Studio for development you could perform this request from the workstation you use, and Visual Studio would do the signing for you. We’ll choose a different approach here as configuring VS is out of the scope, and not necessary for our little lab scenario. Instead we will request a certificate from our DM server (and use it as a “Code Signing Server”).

Preparing your DM Server
As I stated the DM server will be the server where we perform the signing, so the first thing we need to do is to request a certificate for this purpose. I’ll be requesting this through the “certsrv” site of the CA, and this will not provide you with a certificate file. Which means it’s less flexible as you can’t move a pfx file between computers for signing. I am aware that it might make more sense in some scenarios to do this instead, but I’m going with the approach below for this scenario.

Note: unlike previous certificates we have requested this one must not be stored in the local computer certificate store – it must be stored in the user certificate store. (If you think about it, it sort of makes sense, but when you’re used to a different approach it might not be the first thing that strikes you.)

If it installs itself correctly it should look like this in the Certificates MMC:

Having the certificate installed does not magically sign any content, so you will need a tool to do this. We’ll use the signtool.exe utility from Microsoft to do this. There are other tools like Enterprise Mobile’s GUI Cabsign (http://tools.enterprisemobile.com/cabsign/), and these are probably more user friendly, but we want to learn the hard way right? I don’t know if it is my searching abilities that are at fault, but it seems Microsoft wants you to download the entire Windows SDK, (free of charge, but it is 1.3 gigabytes), to get your hands on this utility. Which is silly considering you only need signtool.exe and capicom.dll… I copied these two files from a box with Visual Studio installed, the SDK can be downloaded here:
http://www.microsoft.com/downloads/details.aspx?…..

You just need these two files in a folder – no install necessary. We are almost ready to start signing files, it’s just a minor detail that also needs to be prepared on the DM server. Since the signing certificate was signed by our own CA, we trust the Root CA, but we don’t trust the certificate for publishing purposes. To remedy this, we export the certificate from the user store, and import it into the computer store:

First we export the certificate (from user certificate store):

Then we import the certificate to the “Trusted Publishers” computer store:

Next step – getting a hold of something to sign and push it to a device. And that will be covered in Part 2

Publishing SCMDM Enrollment Server Through ISA Server 2006

4 | October 27th, 2008 | Posted in How-to's, SCMDM

I’m not going to spend a lot of time explaining the “why’s” of this exercise. This is just a quick guide to how you can publish the Enrollment Server of System Center Mobile Device Manager 2008 through ISA Server 2006. It is highly recommended to use some reverse proxy in front of the Enrollment Server – this does not have to be ISA Server, but you should have something in place.

The Enrollment Server can be published at any address you prefer, but devices trying to enroll will always try to look for mobileenroll.domain.com first. If you configure it to be available at enroll.domain.com that is ok, but the user then needs to provide this address instead. Configuration of SCMDM and the Enrollment Server is already covered in previous articles: http://mobilitydojo.net/2008/09/22/system-center-mobile-device-manager-2008-install-guide-no-gateway-part-1/

For the purposes of this article it is assumed you already have certificates installed on both the Enrollment Server and the ISA Server. In my scenario the DNS name is https://mobileenroll.mobilitydojo.net on both servers, and both certificates are issued by my internal CA. (You do not need to purchase a certificate from an external CA.) I’ll also assume you are comfortable with ISA Server as well, and know your way around it’s interface.

Publishing in ISA Server consists of two parts:
- Creating a web listener.
- Creating a publishing rule.

Creating the Web Listener:
It is “just” a matter of following the wizard. The important part is the authentication part which is configured to “No authentication”. This may sound strange, but SCMDM handles this internally, and there is no “secret” info if you should happen to surf to this page. (Remember: this is a basic scenario, you are free to modify it to suit your needs.)

Creating the Web Publishing rule:
Same thing here – follow the wizard. I’ll comment on those points that need an explanation.

If the ISA Server is not able to look up the internal IP address through DNS you should specify it in the “Computer name or IP address”-textbox, but remember that the certificate must match the “Internal site name”.

As it says entering a path in addition to the name is optional. It might be a good a idea to specify the path to restrict access further. If you want to do this the path you will need is “EnrollmentServer/Service.asmx”.

If you entered the path in the screenshot above you probably want to do the same thing externally – enter the same path below.

Select the Web Listener we created in the first part of this procedure.

We don’t use authentication, and thus there is no need to delegate authentication either.

We’ll apply this rule to all users. (Since we’re not authenticating it doesn’t make sense to apply to a group of users.)

Hit the “Finish”-button after using “Test Rule“ to see if there are any errors in your setup.

At this time, hopefully it’s “Hey, it works!” after you’ve applied the settings in ISA Server

To verify that it works:
Open up https://mobileenroll.domain.com/EnrollmentServer/Service.asmx in a browser (from an external IP address), or try to enroll a WM 6.1 device.

What it should look like if it checks out ok in Internet Explorer:

What it looks like in ISA Server Traffic Simulator:
(Service Pack 1 for ISA Server 2006 is needed for this utility.)

Threaded SMS – Making It More User-Friendly

0 | October 22nd, 2008 | Posted in Tweaks

Kudos to the forum at smartmobil.no for providing these tricks (multiple forum posts).

The threaded SMS feature of Windows Mobile 6.1 seems to be one of those features you either love or hate. It makes an SMS conversation resemble an IM chat between two parties. This may or may not feel “right” for you. But even if you like the concept, it may not be as smooth as you like it. For instance you may find that there is not as many lines allocated to you answering an SMS as there are lines presenting the previous dialog. And maybe you think there’s not enough room for text in general. I decided to collect some “hacks” here

Inspired by Marco’s article (http://blog.enterprisemobile.com/2008/10/writing-custom-gpos-for-scmdm-2008/) they are also provided in a GPO-friendly manner

Disabling / Enabling threaded SMS:
This is controlled by the following registry key
HKEY_CURRENT_USER\Software\Microsoft\Inbox\Settings\OEM\
DWORD SMSInboxThreadingDisabled
1 = Disabled, 0 = Enabled (default)

Specifying DPI for the current font (more equals less):
HKLM\ControlPanel\Stylus\192DPI
DWORD CurFont, Min value 600, Max value 1100
This setting is dependent on the resolution your device is running, and may not work on all devices. Most devices upgraded from WM 6.0 to WM 6.1 are running QVGA (320×240) whereas newer devices running WM 6.1 out-of-the-box run VGA (640×480). It will affect your entire inbox, meaning both SMS and mail. The text will become smaller so make sure it’s readable

And if you want it as an ADM-file:
CLASS MACHINE

CATEGORY “Windows Mobile Settings-Extended”
CATEGORY “Threaded SMS”

POLICY “Disable Threaded SMS”
KEYNAME “SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKCU\Software\Microsoft\Inbox\Settings\OEM\”
EXPLAIN “Disable the Threaded SMS feature.”
VALUENAME “SMSInboxThreadingDisabled”
VALUEON NUMERIC 1
VALUEOFF NUMERIC 0
END POLICY

POLICY “DPI”
KEYNAME “SOFTWARE\Policies\Microsoft\Windows Mobile Settings\Registry\HKLM\ControlPanel\Stylus\192DPI”
EXPLAIN “Adjusts the DPI (size) of the font for the inbox (mail & SMS). Note: is dependent on the resolution the device is running.”
PART “DPI Value” NUMERIC
VALUENAME “CurFont”
MIN 600
MAX 1100
DEFAULT 600
END PART
END POLICY

END CATEGORY
END CATEGORY

Allocating lines pr reply (sorry, this one is file-based):
Locate the file \Windows\thread_sms.html, (from a Windows Mobile 61. device), and open it up in your preferred html editor. Notepad will probably suffice for this simple file.
Find the line “Inbox:content id=”COMPOSESUBJECT” width=”98%” height=35” and change the “height”-parameter to something else. 35 is the default value in my case, changing it to 75 gives you 6 lines.

If you want to get creative there’s also an thread_style.css file to change more of the appearance.

There are probably a number of other settings available as well, but I found these to address some of the more annoying aspects of threaded SMS

MDM & “Enterprise Concerns”

0 | October 14th, 2008 | Posted in Device Management

By their very nature salespeople are talkers, and techies are doers. This is not a rant along the lines of “All salespeople should burn in hell”, and actually it’s not really all that much about salespeople either. But like it or not – when someone is trying to sell an MDM solution to you they’ll often start by sending a sales guy over to you. (Indeed you as a techie may not even be present at the initial meetings. And yes, I am making assumptions as to my audience.) You may not be the one with a business need for these products so that’s ok, but you may end up supporting and/or implementing these solutions. This will not be the ultimate “buyer’s guide”, and I will keep it product neutral, and rather try to highlight some things you should keep in mind regarding MDM from an enterprise perspective. Given the fact I have been turning out a few guides based around Microsoft SCMDM maybe you think this is the answer I’ll provide to all your questions, but as much as I enjoy digging into SCMDM it is not a product for everyone at the moment

I’ve had the pleasure, (and sometimes pain), test-driving a number of mobile middleware (PIM & MDM) solutions the last couple of years. Some have been really good, while others have been less good. Now it may sound silly and obvious, but the first thing you need to define is what you want to do with a mobile solution. Are you primarily interested in pushing out PIM data (e-mail, calendar, etc) to devices, or are you looking into deploying Line of Business applications? Or maybe you’d like to start with PIM to get a feel for mobility, and move on to more elaborate scenarios later on?

Just about every solution available can do the basics in some form – disable camera, distribute files, collect inventory. The details are different, but the concept is the same. And in the bigger picture – I really don’t care about knowing all these details when I try to look at it from a higher level perspective.

So what do I care about?
Scalability for one.
What do I mean by saying “scalability”?
I believe in two meanings of scalability. There’s the “hard” side of it, which is all about numbers: “how many devices can one server support”, “how much RAM does a server need”, “how do I ensure redundancy”…

Then there’s the “soft” side of it; “how do I manage 50 devices”, “how do I manage 5000 devices”, “how do I deploy the client component”…

Looking into these two facets of scalability brings up even more questions, but the point of this whole exercise is getting you to ask yourself these questions and trying to work out the answers. (And sometimes prodding a sales guy in the process.) I have however not defined yet what I mean by “Enterprise”. If you have 50 devices to manage, it most likely does not qualify as “Enterprise”, and many of these concerns will not apply to you. If you have 10000 devices that probably qualifies as “Enterprise”. A precise number cannot be affixed to the “Enterprise” label, but I believe you should start at least thinking about a few of these issues already at 3-500 devices.

Hardware is cheap these days. If you buy a server today, it will support 64-bits, it will be multi-core, and it will not have less than 4GB of RAM. That does not mean you should blindly accept “hefty” hardware requirements. Let’s look at some of these components.

CPU does not really matter all that much. MDM should not require “special” processing, so any CPU on the market should do. (You should probably opt for a balance between power and price here.)

64-bits is not always a choice. If a given MDM solution supports 64-bit – go for it. If it only supports 32-bit ask if it will run on 64-bit OS, and what the plans are for supporting 64-bit. I accept the fact that not everybody has had time to port their codebase yet, but it should be on their roadmap. If they try to pass off 64-bits as something you don’t need – be afraid. Be very afraid…

Hard drive should not be a concern, but the key to determining this is the database storage. If the DB is put on the same server box you should most likely keep it on a separate RAID.

RAM… Saved the best for last didn’t I This depends on what kind of MDM solution you look into getting. If it’s a solution doing both PIM and DM it’s perfectly acceptable that this requires more memory pr client. If it’s only DM the footprint pr client should be low. Also keep in mind that with 32-bit you’ll land somewhere between 3-4 GB max in the server. (No, do not bring up the PAE card.) But even with 64-bit the gain above 8GB is limited. The vendor should be able to say something like 4GB & 1 server = 2000 users, or some other randomly chosen number. (And I don’t mean the vendor should choose a number at random… you know what I mean.)

What numbers of devices pr server would I accept? With PIM 1000-2000. Only DM – at least 4-5000 (depending on some aspects covered in the next section). With LOB applications involved – harder to provide a generic number. (If the LOB apps don’t go anywhere near the DM servers it should not make an impact.) And as you probably understand already – don’t confuse the ability of a server to manage a large number of devices with the need for redundancy

An interesting scaling factor on the hardware side that not every vendor cites is the number of concurrent connections handled. Note that this is not the same as the number of devices managed. The network card, and the operating systems insert some constraints. With Windows Server 2003 you are not able to run 10000 concurrent sessions. Depending on how much processing a single connection requires you’re more likely looking at somewhere between 500-1000. And this is the point where you should ask how policies/settings/applications are distributed. If it’s “immediately” it’s some sort of push mechanism, which means you always have a lot of devices connected. Potentially meaning less scalability. (Being able to push for instance a kill instantly is not the same thing as initiating full-blown DM sessions through push.) How big an impact this causes depends on architectural decisions as well – is there a front-end server handling the connections, with a back-end server doing the processing? The other alternative is scheduled connections which means there is some mechanism causing the client to trigger a connection at a predefined interval to the server. This should cause less strain on the server, but it does not help if it is a hard-coded schedule. If you have 5000 devices connecting in at midnight sharp, the server will probably not be able to accept all the connections. So you should have a mechanism that makes sure different devices connect in at different times even though they are on the same schedule.

So, are there any consequences of not having the above in mind when choosing an MDM solution, and scaling it? If you’re lucky you’ll notice from logs and performance monitors that there’s a bottleneck and/or issue, and you just add another box, or upgrade your existing. If you’re unlucky you run into an MDM admin’s worst nightmare; the server is not able to process a connecting device correctly. Something is corrupted on the client, the client never connects back in, and “goes dark”. Suddenly you have 100 managed devices becoming unmanaged, and both you and the user are blissfully unaware of it. Better yet, maybe you are aware of it, but have no clue as to how to make it managed again. And yes, I have seen this happen… (And no, I will not provide product names, or further details.) There are actually solutions to this problem as well in a mature MDM solution – ask the sales guy how to get out of this “situation”, and see if he is more than a talker and actually deserves your money

Well, that’s all for now folks. I know I said there was a soft side to the scalability concern, and I know there are more aspects to knowing an enterprise product when you see one. Those may show up in a future post.

What’s This OMA-DM Thingy All About?

0 | October 10th, 2008 | Posted in Device Management

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

Using a Hosts File on Windows Mobile

14 | October 9th, 2008 | Posted in Utilities

When you are testing and playing around with server solutions you sometimes have the need to control exactly where your requests are going. Maybe the host you’re trying to connect to isn’t registered in your DNS, or maybe you want to access the external IP and not the internal IP your internal DNS resolves to. We’ve all been there, and on our computers we are so happy we can edit our hosts file and take control.

What about Windows Mobile? Sure, we have the same needs here. Maybe even more here sometimes when we’re dealing with SSL certificates and we can’t press “ok” to accept the site that resolves to a different host name than the common name in the certificate. But Windows Mobile does not have a hosts file… Windows Mobile does have the functionality, but it’s buried in the registry. (Really user-friendly.)

It can be found in HKLM\Comm\Tcpip\Hosts. Do the following:
- Add a subkey which is the host name/FQDN.
- Add a Binary value ipaddr containing to hexadecimal notation of the IP address.
- Add a Binary value ExpireTime containing an expiration value. I think this is actually optional, or you can just set it to a large value – say “99 99 99 99 99 99 99”. (As in never expire basically.)

So adding www.mobilitydojo.net, resolving to 192.168.0.1 would look like this:

Unless you’re really good at hex you’ll probably have to get assistance from calc.exe computing the value for ipaddr

Deciding this was a pretty mundane chore, I thought that creating a small utility shouldn’t take too much time. Now I’m not claiming to be the guy who discovered this little gem digging through the registry, and there are other apps out there that will let you add entries to the registry. But that doesn’t prevent me from making my own implementation

There are two simple things you can do in this little utility – you can add hosts, and remove hosts. (I have hardwired the ExpireTime to equal “99 99 99 99 99 99 99”.) Given the simple interface I think you will be able to work it out without further instructions. You might be wondering what “ppp_peer” is, and what kind of record this is. It’s used by ActiveSync, (when you cradle your device), to assign an address to the device itself. Just leave this record as it is.

And as usual I must add the disclaimer that I take no responsibility if an error message occurs (Not that I see much more than the application itself crashing as likely to happen though.)

Download (Updated 05.nov.08):
Windows Mobile Professional http://mobilitydojo.net/files/HostsFileEditPro.exe
Windows Mobile Standard http://mobilitydojo.net/files/HostsFileEditStd.exe

Dimmed Backlight on Login Screen

0 | October 8th, 2008 | Posted in Tweaks

If you have a newer model of a Windows Mobile device you might have had problems with the backlight being dimmed when you’re typing in your password/PIN. (You do have Power-On-Password enabled don’t you?) As long as you’re indoors it’s not a problem, but try seeing anything at all on the screen when you are outdoors.

Sometimes I have no idea what they are thinking when they decide what to make a default setting. (Especially when they don’t provide with a way to change the setting through the GUI.)

If you are affected by this try changing the following registry key:
HKCU\ControlPanel\BackLight\Locklevel\ (DWORD) LockLevel
0 = disable dimmer, 1-10 enable dimmer (varying levels of brightness). Not all devices support all values.

On the HTC Touch Pro I spotted another setting (which is available through the GUI as well), possibly present on other newer HTC models as well. The setting dims the backlight, but turns the brightness up when you touch the screen (which has a nice feeling to it).
HKCU\ControlPanel\BackLight\ (DWORD) DimBKLinUnlockScreen
0 = disabled, 1 = enabled (As in “Disabled = good thing”)

MobilityDojo.net

Update – DojoCrypt goes 1.0

Update – Hosts File Editor – Version 1.0.0.5

System Center Mobile Device Manager 2008 – Distributing Software – Part 2

System Center Mobile Device Manager 2008 – Distributing Software – Part 1

Publishing SCMDM Enrollment Server Through ISA Server 2006

Threaded SMS – Making It More User-Friendly

MDM & “Enterprise Concerns”

What’s This OMA-DM Thingy All About?

Using a Hosts File on Windows Mobile

Dimmed Backlight on Login Screen

Search

Pages

Categories

Archives

RSS Feeds

Meta