Kannel Integration With Exchange

After this post you might be thinking I’m a one-trick pony when it comes to Kannel, but I promise to move on. I just get all these fun (and sometimes useless) ideas along the way 🙂

In a true case of code reuse I took the C# code for sending SMS through Kannel, and made two more implementations.

The less interesting of the two first – in case you are thinking the title is misleading. I created a client for Windows Mobile that will let you – send SMS from your mobile device! Amazing, right? With a really slick interface and everything:

Ok, you’re thinking that must be the dumbest idea ever. Creating an extra application for something that really is simpler to do through the regular interface. Granted, I don’t expect to make a lot of money selling this application, but it was only a simple proof-of-concept, and didn’t take much time to put together.
Things you might want to use it for include:
– Being able to set arbitrary “from” addresses even though you are sending from a device.
– Sending SMS through GPRS (and converted back to SMS for the receiver of course). This might be handy if your mobile operator is gouging you for sending SMS back home when you’re out of the country. (Presuming it comes off cheaper using a data connection that is.) Actually if you put a little effort into it you can create this as a console app that integrates with the regular user interface. This way the user doesn’t notice if the message is sent one way or the other, but you would for instance check whether the device is roaming and act accordingly in the background.
– I tested the app in the emulator running Windows Mobile Classic. So you don’t need a SIM card or a real device to send SMS with this.
– If I extend the app to sending binary SMS messages in the future it might even do something useful that you can’t do with the built-in SMS facilities on the device.

Another application of the code that might be more worthwhile is integration with Exchange. I’m not going to give a lecture of Exchange architecture, or development in general, (because there are a lot of other resources out there, and many more knowledgable than me), but with Exchange 2007 it’s easy to extend some of the core functionality in Exchange. All mail that is sent through an Exchange server passes through the Hub Transport role, and possibly the Edge role if you are using that. This is where different rules are applied to the mail. For instance throwing out spam, making sure that confidential mail cannot be sent to external recipients, etc. This functionality is implemented as so-called Transport Agents, and if you don’t mind writing some code it’s actually quite simple to create your own agents. (With the definition of simple obviously being dependent on what you are trying to achieve.)

Why not have an agent that will let your Exchange server send out SMS messages based on a set of parameters? For instance tagging a mail as important will send an SMS alert. Mail alerts sent from monitoring systems being converted to SMS instead. Prefixing the subject with “SMS:” for sending it through your Kannel box. You can most likely come up with a good use of your own as well if the above are of no use to your specific scenario.

I’ve created a small example of how this can be done. It’s a “stupid” agent in the sense that it triggers on all mail that is sent, and it has a pre-defined “to address”, and message. You’d probably integrate with AD, and filter the contents in some way if you were to actually use it for something worthwhile on an actual Exchange Server.

I have tested my dll on an Exchange 2010 Beta server, but to my knowledge it should run on Exchange 2007 as well. (RTM & SP1.)

The steps you need to perform are as follows:
Create a new project in Visual Studio. You’ll want a Visual C#->Windows->Class Library. Choose .NET 3.5 if you are testing on Exchange 2010, or .NET 2.0 for Exchange 2007.

Copy off Microsoft.Exchange.Data.Common.dll & Microsoft.Exchange.Data.Transport.dll from your Exchange server to your Visual Studio box. (By default they are located in “C:\Program Files\Microsoft\Exchange Server\V14\Public” on E2K10.) Place it in the “\debug” and/or “\release” folders under your “Projectname\bin” directory.

Add references to your project – more specifically the dll files you just pasted in.

Build your code based on the following sample code, or read more over at MSDN and build from scratch:)

using Microsoft.Exchange.Data.Transport;
using Microsoft.Exchange.Data.Transport.Routing;
using System.Net;
using System.IO;

namespace MobilityDojo.CinnamonExch
   public class SMSRoutingAgentFactory : RoutingAgentFactory
      public override RoutingAgent CreateAgent(SmtpServer server)
         RoutingAgent myAgent = new SMSAgent();
         return myAgent;

public class SMSAgent : RoutingAgent
   public SMSAgent()
      //Trigger whenever a message is submitted
      base.OnSubmittedMessage += 

      new SubmittedMessageEventHandler(SMSAgent_OnSubmittedMessage);

   void SMSAgent_OnSubmittedMessage

   (SubmittedMessageEventSource source, QueuedMessageEventArgs e)
      string kannelServer = "http://kannel";
      string kannelPort = "13000";
      string smsPath = "/cgi-bin/sendsms";
      string username = "";
      string passWord = "";
      string fromAddress = "Exchange";
      string toAddress = "";
      string msgContent = "Hello Exchange";

      string smsPost = kannelServer + ":" + kannelPort + smsPath
         + "?user=" + username + "&pass=" + passWord + "&from="
         + fromAddress + "&to=%2B" + toAddress + "&text=" + msgContent;

      string kannelRes = sendSMS(smsPost);

   string sendSMS(string uri)
      WebRequest kannelRequest = WebRequest.Create(uri);
      kannelRequest.ContentType = "x-www-form-urlencoded";
      kannelRequest.Method = "GET";

         WebResponse kannelResponse = kannelRequest.GetResponse();
         if (kannelResponse == null)
            return null;

         StreamReader sr = 

            new StreamReader(kannelResponse.GetResponseStream());
         return sr.ReadToEnd().Trim();
      catch (WebException ex)
         return ex.ToString();

You’ve now got a dll file that can be copied to your Exchange server. You choose the destination folder.

Open up the Exchange Management Shell. There’s a bug in the Exchange 2010 Beta build so you need to open the “Local Powershell” version of the shell. (Does not apply to Exchange 2007.)

Run the following cmdlet:

Install-TransportAgent -Name “CinnamonExch”

-TransportAgentFactory “MobilityDojo.CinnamonExch.SMSRoutingAgentFactory”

-AssemblyPath “C:\myAgent\CinnamonExch.dll”


Exit the shell, re-enter the shell and enable the agent:

Enable-TransportAgent -Identity “CinnamonExch”


Restart the “Microsoft Exchange Transport” service.


Test it. In my simple agent a mail sent to yourself through OWA should do the trick. (Contents doesn’t matter as I’ve already defined that in the HTTP GET in the code.)


I don’t make any modifications to the original message so the mail should come through as usual with no visible trace client side that an SMS was sent.

Were still doing basic stuff, but you can do some neat stuff nonetheless if you use some imagination. Yes, there are a lot of software out there already that will plug-in to Exchange, custom SMSC integration, and whatnot. Some times it’s cheaper buying off-the-shelf software, but it doesn’t beat the satisfaction it gives to implement it yourself 🙂

Exchange 2010 (Beta) and Mobility

Microsoft has been releasing small nuggets of info related to the next release of Exchange, (also known as Exchange 14, and now Exchange 2010), for a couple of months now but other than the occasional screenshot we haven’t seen much of it hands-on. Last week Exchange 2010 was released to the general population in the form of a Beta release. You can read the announcement and more details over at TechNet: http://technet.microsoft.com/en-us/exchange/2010/default.aspx

Maybe not surprising, but I was interested in learning what this will bring me related to mobility and ActiveSync related features. So I went ahead and installed it. Since the beta requires a Windows Server 2003 domain, and obviously not any existing Exchange servers already installed, I had to bring up a new domain. But other than that installing it was a smooth experience. (There’s a long list of pre-requisites you have to install, but that’s not of relevance in this space.) Unfortunately I’ve been travelling the past few days so I didn’t get around to blogging about it until now – it’s not due to laziness I’m this slow in bringing it out 🙂

So looking into the ActiveSync policies we don’t really see any changes from Exchange 2007, but here’s what it looks like (this is the default policy Exchange configures for you):

Well, ok for now I guess being a beta and all 🙂 The policy settings that aren’t available here, and are supported on existing devices, would still need SCMDM or another MDM platform. I do not know if they will include more settings as Windows Mobile 6.5 comes around. I don’t expect Exchange to become a full-blown MDM platform either, but everyone loves new features regardless of whether they are needed or not don’t they?

Logging into Outlook Web Access there are some changes. If you bring up “Options” they clearly want you to configure a mobile device:

Clicking brings up a new window stating that content will be provided at a later time. But I’m guessing it will be aimed at non-technical first-time users detailing the basic steps.

There is a new tab called “Phone” in “Options” as well giving you an overview of your devices and the possibility to do SMS in OWA.

I believe I read about sending and receiving SMS being a possibility in OWA, but cannot find any reference in the GUI to a feature like that. The “Text Messaging” is apparently only used for notifications to your device currently:

Which brings you to the settings:

I can see the use case for this feature, but I don’t find it terribly useful. That might be a personal preference though, and if someone else loves the feature that’s perfectly acceptable. At any rate I am not able to test it myself as you’re limited to using either a US or Chinese mobile operator at the moment.

I don’t know if it’s possible to “hack” this to support other operators or your own SMS gateway for that matter. I’m not so eager to test it that I’ll be looking into it at the moment.

There are of course lots of other improvements to Exchange, and while I’m interested in the mobile bits I realize that there are other features that might rank higher on the importance list for many others 🙂 I’ll continue experimenting, and share my what I learn. (Exchange Web Services is something I’ve played with before, and you can do lots of neat stuff with that from your device so maybe I’ll look into that.)

Personal Certificates and Exchange ActiveSync

By now you might have been playing around with enrolling certificates on your own, either through use of my little utility or typing your own xml, or making your own utility for all I know. I mentioned previously that Exchange ActiveSync (EAS) was one candidate for doing something useful with a personal certificate. There are a couple of use cases for certificates relating to EAS:

  • Authentication to Exchange instead of username/password combo.
  • Encrypting messages.
  • Signing of messages.

Signing and encryption is more commonly referred to as S/MIME.

We’ll start with authentication. Which also happens to be a nice and tricky thing to research 🙂 I’ll make a few assumptions – I’m running Exchange 2007 SP1, but things should be similar on Exchange 2003. I’ve done my testing running Exchange on Windows Server 2008, but Server 2003 should behave similar even though IIS7 has some differences from IIS6. Since ISA Server unleashes a troubleshooting scenario of it’s own with Kerberos Constrained Delegation I’ve left that out of the scope for now. Actually the server side setup warrants a dedicated article so I’ll just assume you’ve got the server configured and working with client certificates. (Don’t know yet if I will provide my take on how to configure this, or if I’ll leave it to Google to provide reference material.)

Quick tip: To verify ActiveSync functionality (without involving a device) open up https://exchangeserver/Microsoft-Server-ActiveSync on your computer. You should be prompted for credentials and receive an error – “501 – Header values specify a method that is not implemented.” This works for both basic/integrated authentication and client certificates.

Microsoft also has a handy tool called “wfetch” that will allow you to skip the browser, and specify how you want to authenticate.
Link: https://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=…9210

Working out how to configure this using official Microsoft documentation is..well.. It didn’t give me every answer I wanted. Official documentation tells us two main things: you need to connect your device to ActiveSync/Windows Mobile Device Center to enroll for a certificate, and you need to perform the initial sync through the desktop as well. (Your computer also needs to be domain-joined, and you need to establish a partnership between desktop ActiveSync and device ActiveSync. It will not work in “Guest” mode.) And this procedure works, nothing wrong with that. But I think I’ve already touched upon the “Going Mobile” aspect of things before. I don’t like being tethered if I don’t have to. The problem is that setting up ActiveSync on the device the wizard prompts you to enter a password, and the device is hard-wired to attempt basic authentication first. After doing that you should be informed that certificates is the preferred way to go, and that your computer will set this up for you. (A registry value called “EnrollForCertOnNextCradle” is flipped to 1.) This means that depending on how you configure the rest of your servers, (for instance the already mentioned ISA box), you might have to configure Exchange to accept both basic, and certificate-based authentication.

I configured my Exchange to require client certificates, and to accept no other tokens of authentication. I then used my own utility to enroll a personal certificate. Since I could not configure ActiveSync through the wizard I wrote a configuration xml that I pushed through via RapiConfig.
Look up the Sync CSP on MSDN: http://msdn.microsoft.com/en-us/library/bb737700.aspx

Using only a minimum of configuration I applied the following provisioning document:

  <characteristic type="Sync">
    <characteristic type="Connection">
      <parm name="Domain" value="MobilityDojo.net" />
      <parm name="Server" value="exchange" />
      <parm name="User" value="andreas" />
    <characteristic type="Mail">
      <parm name="Enabled" value="1" />

I omitted the password (since this is part of what we are trying to achieve), but I did type in the username. I haven’t tested what happens if you omit the username, but you should probably do some testing and establish a process as to how you handle this when rolling out for production use. This is all standard procedure for provisioning the settings from a server and should be doable. Here comes the undocumented part – under the ActiveSync registry key on the device HKCU\Software\Microsoft\ActiveSync\Partners\{GUID} are two registry values I provided with a value:

EmailAddress I configured this with my email address, which is also defined in my personal certificate. (I’m thinking there might be some match checking between the two.) You can have multiple addresses as long as you separate them with semi-colons.

ClientAuthCertRequired I set this to 1 (as in required) as opposed to the default of 0.

The part that makes this hard to pre-provision is that these two keys are found under the GUID unique to each ActiveSync partnership. And you can’t guess this GUID before you have provisioned the sync settings.

I then proceeded to fire up ActiveSync on the device. It said there was an Exchange partnership, but that it had never been synchronized. I hit “Sync”, and the “green wheel” started spinning. I was never prompted for a password, and didn’t get to choose a certificate to use either, but after churning away for a while the device stated everything was in place and working like it should.

Now there might be a “hidden” reason Microsoft states you cannot do this, and there might be a flaw in my approach, but it sure does seem nice to do it like this. I’ll admit though that Microsoft are correct in the sense that it did require some tweaks to get this working and it wasn’t exactly available out of the box. (I have heard the argument before that coding is cheating because then you can do “everything”. Maybe, but MSFT could have provided some pointers even if it requires some legwork on your own.) If you are enrolling on the order of 10-20 devices you’re probably better off using the cradling procedure, unless you have a special interest in doing it different. This doesn’t pay off until you have an amount of devices that can justify that you configure and test provisioning xml, writing utilities, etc.

The manual tweaks yes…Allow me to elaborate on that part. It doesn’t seem very accessible the way I just described it. You probably don’t want to do all this xml thing for other than testing anyways. Your MDM solution of choice should probably provide you with options for setting things like server name, domain, etc. It’s probably not that much effort making it set the ClientAuthCertRequired to 1 either. Setting user name, and email address may or may not be supported depending on the scripting capabilities available to you. The approach I might be taking is to extend the certificate enroller utility I posted two weeks ago. I haven’t worked out the details for that however so for the moment I don’t have a new release available, and I’m not making any promises either 🙂 If you’re comfortable with Visual Studio you should be able to work it out though based on the bits I’ve provided in the sections above.

I’ll only briefly touch upon signing and encryption of messages. You cannot configure this before completing the first sync. This primarily being that you need to be running SP1 for Exchange 2007 server side, so the device needs to “negotiate” the capabilities before enabling this. The user then gets a new option enabled in his mail configuration due to the fact that he’s got a certificate on the device to sign and encrypt individual messages. Or you as MDM admin guy can configure that one or both of these is always a requirement for sending a message. There are already policies/settings for managing this in SCMDM, and most likely other MDM platforms handle this equally good. But then you have to choose signing and encryption algorithms and everything. You’re probably just as well looking up the official documentation on this topic, and make your own decisions:

I don’t know about you, but I think things are starting to shape up now, and we’re getting somewhere with the whole personal certificates concept 🙂