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