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
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.
I’m not the first to check out the available/supported ActiveSync policies – check out the following links for more info:
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.
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.
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
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.)
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:
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.