Windows Phone 7 – More on Exchange ActiveSync Support

By now Windows Phone 7 has been released on all continents to my knowledge. Not necessarily all countries, and in some countries they aren’t “properly launched” with the devices not having been localized yet (and thus miss out on some Zune features). Nonetheless they are generally available, and you can probably import one if it’s not available at your local device pusher. So, you’re probably thinking I’m more than a little bit fashionably late for not actually getting around to playing with an RTM device until now. (Spending an unhealthy amount of time with Cupertino-based products lately being one of the reasons. But that’s a different story.)

The device I’m using for this article is the HTC Trophy running Windows Phone 7 build 7.0.7004.0. Nothing here should be device specific though and should apply to other WP devices as well.

Now, what is the first thing we check with new devices? Why, it’s Exchange ActiveSync of course Smile

This isn’t a complete investigation of EAS, but serves as a sort of quick guide to a couple of the features related to the protocol.

Security Policies
I’m not the first to check out the available/supported ActiveSync policies – check out the following links for more info:
Brightpoint UK:
http://blog.brightpointuk.co.uk/windows-phone-7-exchange-activesync-support
Tom Basham:
http://refraction.co.uk/blog/2010/11/22/windows-phone-7-and-exchange-activesync/

Needless to say I’m not entirely happy with the current state of affairs, but it’s not like I can solve that on my own. But this got me thinking how can we investigate what a device supports when it comes to ActiveSync policies? Yeah, I know; change policy, sync device, test feature. You pretty much have to switch things on and off in the policy and sync, but you can skip the test part if you like.

You might remember. or you might have tested for that matter, the “Allow non-provisionable devices” setting. This setting blocks devices that report themselves as non-provisionable if you enable them, the meaning of provisionable being “I am able to enforce policies”. In Exchange 2010 you can check what a particular device reports through Outlook Web Access.

A device that is non-provisionable and allowed to sync (I have a mixed language OWA interface at the moment for some unknown reason):
image

A fully provisionable device:
image

A provisionable device that does not support all policies:
image

To produce the third screenshot you need to “Allow non-provisionable” and set a policy that you know Windows Phone 7 does not support.

If you want to test what triggers the partially applied state you can take a look at the EAS traffic on the Exchange Server. (This works on other devices too, possibly with some variations as to how the wbxml looks like.)

I’ve done some sniffing with Wireshark, but Network Monitor should also do the trick. I’m syncing without SSL to do decoding by eye easier. There are multiple requests and responses back and forth, but if you parse through it you’ll notice the client ACKing the policy as shown below. I’ve highlighted the relevant status code.

Device supporting the provisioned settings:
image

Device supporting some of the provisioned settings:
image

Status codes: http://msdn.microsoft.com/en-us/library/ee157700(v=EXCHG.80).aspx

So, if you have the patience flick one switch at a time, and see if it changes from 1 –> 2 to determine which ones are ok, and which ones aren’t. Since Exchange sends out a list with true/false for the policies I would have liked the client responding true/false as well, but it cuts down on the bytes transferred when following this simplified scheme.

If you have a couple of nights available you can run through a couple of different ActiveSync implementations and see what they report Smile

Installing certificates
While technically not an Exchange issue, it is often in regards to setting up synchronization that people find out that the root certificate on the server they’re connected to isn’t trusted by the device. The recommended solution for ActiveSync is using commercial CAs that the device trusts by default, but if you happen to have certificates issued by your own CA you need to install the root and/or intermediary CA certs. Since you’re not able to transfer files directly to the device there’s basically two options:
– Send the certificate as a mail attachment to a non-Exchange mail account on the device.
– Download from a web site. (Preferably a web site protected in some way.)

I found that on my web server (IIS 7.5) I had to add a MIME type to be able to download .cer files:
image

When opening the link you’ll get a prompt asking if you’d like to install the certificate, and it will automatically be installed. You might need to flush/commit to memory by soft resetting the device in some instances. You can also download .p7b files this way which is practical if you have a chain of certificates that should be installed.

Taking the certificates one step further you can also install pfx files – which brings me to the next point on the list.

Client certificate authentication
There are secure ways for enrolling client certificates on both Windows Mobile 6.x and iPhones. Either you cradle the device, or provided you’re on the same network as the CA you can do requests directly from the device. Windows Phone 7 does not offer the same choices. However my tests indicates that the client certificate support for Exchange ActiveSync is still there – you just need to get the certificate installed through other means.

First enroll for a user certificate on the desktop. Open up the certificates MMC snap-in (for “Current User”). Right-click the certificate and choose “Export”.

Excerpts shown below:

Include private key.
image

Include the root cert in the same export.
image

Use a suitably long password.
image

The resulting pfx file can be distributed over a web page as mentioned in the previous section. If you’re not using client certs for your SharePoint it could possibly be uploaded there from your desktop, and downloaded on your mobile device. Well, there’s lot of options really I guess, just remember to not leave those files unprotected on a a public web site. The “mail through alternate account” approach probably works here too – I didn’t test it. When downloading the pfx you will be prompted for the password to install it.

Yeah, I know, there’s still a way to go before Windows Phone 7 is what you would call Enterprise ready, but at least it’s better than nothing. And the EAS implementation itself is solid as far as I can tell.

7 thoughts on “Windows Phone 7 – More on Exchange ActiveSync Support”

  1. Interesting stuff. I’d really love to know why Exchange 2010 SMS sync has been pulled from the initial release. Do you have any thoughts?

  2. Well, I can offer some speculations, but I do not know the actual reason. The thing is that the first release of WP7 is targeted at consumers, and MSFT has said for a long time that it would not include all “Enterprise” features that we were used to on WM 6.x. Since a Windows Live account is required for doing anything on WP7 integration with Microsoft’s cloud and the MyPhone service seems like a more likely choice at the moment.
    While some customers were thrilled to see the SMS sync feature, some has said that syncing the SMSs is not something the company should be concerned with. So going forward I don’t know how MSFT will approach this feature…

  3. I’ve been battling some with getting client certificates working with WP7, TMG and EAS.

    I have a (Mobile User Signature) certificate issued by my own internal CA.

    I load the root.cer onto my WP7 so that I will trust the user certificate (pfx), reboot the device, then install the user certificate and reboot the device again (if I don’t reboot the device between each certificate install, it fails even worse).

    I set up the WP7 device to connect to my TMG. The TMG verifies the certificate and then sends the user/pass to the Exchange CAS, which is then verified there.

    Now, what I experience is that the first setup will fail with wrong user/pass (100% certain it is correct). Supplying password again does nothing. Going to the setup and deleting the configuration, and setting it up again, will work.

    Hurray, now the device syncs. For now. Approx. 2 hours later the device fails again with incorrect user/pass.

    Troubleshooting have led me to believe that the certificate is only sent at setup, since sync. will fail when the session expires on the TMG.

    So was wondering if you’ve had certificate auth + user/pass working with TMG involved? And if so, how.

    Thanks in advance, and great site, good information 🙂

  4. I’ve had certificates working on WP7 before, but I’m having some problems getting it working on my device now. (The TMG setup should be good since I just tested client certs with a Samsung Galaxy Tab.) But I’m running Mango on the device now, so maybe there’s an issue. (I’ll need to investigate this.) Are you running NoDo or Mango on your WP7 device?

    What kind of rules are you running on your TMG? Are you using SSL Client Cert on the listener with or without fallback mechanism? And have you checked anything in the “Advanced” dialog box?

    What kind of authentication are you running on Exchange (on the EAS dir)?

    Are you trying to achieve the use of both username & password (basic auth) and client certificates as well?

    If you have any input to these questions I’ll run over a couple of tests in the mean time on my device to verify my assumption that it should work 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

*