Also known as “Building A Simple Helpdesk Tool – Part I”

I’ve been doing some experimentation in my lab recently performing enrollments, and when I was going through the pre-enrollment wizard yet again I thought – “This doesn’t make sense – it’s got to be a better way!” Yes, I know, I could resort to PowerShell, but I was thinking something that was really easy

And a couple of other things occurred to me at the same time… We’re not going to have the poor SCMDM admin guy create all enrollment requests in a real environment are we? Yes, there is the self service page, but picture this: User is traveling, loses phone, calls helpdesk to wipe/block device, buys new phone, calls helpdesk again to enroll the device.

There’s bound to be a few of those calls. So I decided to create a small helpdesk application to solve these small issues. Ok, to be honest, the motivation that made me actually create this application was learning more about the web services in SCMDM 2008. If it was just annoying I could have lived with it If someone ends up using it for actual helpdesk purposes that’s just an added bonus.

At this point maybe you’re thinking “what about customizing the self service portal from the resource kit?”. Good point. I have looked at the self service portal, and tested using it. I have not however tried customizing it yet. Maybe that is a better solution than what I’m trying to do here. I don’t know yet…Maybe we’ll try that avenue later.

Still being a sucker for the learning-by-doing approach I thought combining the web service walkthrough with creating this utility might make for interesting reading.

So what should this tool be able to do? I’m having the following features in mind to start with:
- Create Pre-Enrollment Requests.
- List current Pre-Enrollment Requests.
- Cancel Pre-Enrollment Requests.
- Wipe device.

So I did a quick mock-up of the UI, and I’m thinking something like this (I’ll work on the design elements later):

This could obviously be created as a web app instead of a stand-alone app, but as a personal preference I like creating prototypes as stand-alone.

To answer a question up-front right away; you will notice that there are no downloads at the end of this article. There are a couple of reasons for this:
- I have not written all the code yet that is needed behind this “sophisticated” GUI.
- Service Pack 1 for SCMDM is right around the corner, and I will not make a release available of this tool until I have tested it with SP1.
- Since I have only performed some simple tests so far I might run run into problems later that needs some extra work to solve

Maybe you’re also thinking “I’m not a programmer so I’ll just skip this until the tool is released”. Well, obviously everything I type on to this little site of mine is voluntary reading But I will try to both show some of the code required, and show some of the details that could be of interest to those who just wants to get to know SCMDM a little better. (Let me know if I’m failing these objectives.)

The first thing we need to understand is what we mean by web services in this context, and what it means to SCMDM. A web service is a way to expose methods/functions in a program publicly through an HTTP interface. This means that you can interact with whatever language you choose across different platforms, and if implemented properly (by those providing the web service), you can extend the functionality of a program with very little fuss. Hit http://en.wikipedia.org/wiki/Web_service for a more detailed (and possibly more understandable) explanation.

SCMDM 2008 follows a trend Microsoft has showed the past couple of years where interaction between different components are exposed as web services, and the bits and bytes are based on managed code (C#). So when you are enrolling your device – you’re using a web service. When creating a new enrollment – you’re using a web service. Wiping a device? Yes, there’s a web service for that as well.

Obviously there are some background processes not exposed publicly – interacting with the SQL database, doing some work that needs to be done in C++, doing “secret” things. But that’s the great thing; if I execute a device wipe I don’t need to know the details, I just want to have this available to me as an option.

When you are using the SCMDM Admin Console you are essentially viewing a GUI interacting with the SCMDM web services in the background. So what web services do we have access to? Here’s a screenshot of IIS Manager on an SCMDM server running the Enrollment and Device Management roles.

The SCMDM web services are EnrollmentAdmin, Enrollment, MobileDeviceManagerAdmin, and MobileDeviceManager.

And there’s a web service on the Gateway Server as well:

If we browse to the “Enrollment” web service it might look like this:

We see from this that there are three operations exposed in this web service. Let’s look at “ShouldEnroll”:

This one is easy to test in the web browser, and does not need any programming. When you try to enroll a device this is the first thing the device checks to see if it is eligible for enrollment. (After you have entered your e-mail address, and the server is located, e-mail is provided as ownerIdentity. See my previous article The Enrollment Process in SCMDM2008 – A Closer Look for further details regarding enrollment.)

So we provide “1.0.0.0”, (applies to SCMDM 2008 RTM), in the version field, and “andreas@mobilitydojo.net” in the ownerIdentity field.

XML is returned indicating a true or false value (located in the hr tag element):

The other web services work in a similar way, but some of them you will only be able to use programmatically.

An important detail that might not be clear from the screen shots above is that there are access controls in place. Most of the web services requires you to authenticate, and be a member of a specific security group (the Enrollment service is a special case). And through IIS restrictions most of them are not accessible outside of the LAN.

The title of this post included the word “Introduction”. I had a “worklog posting” sequence in mind, and I’ll delve into more of the details in upcoming posts. Stay tuned for more web service adventures