In the previous installment in this series we looked at how security policies are pushed down to our Exchange ActiveSync clients, and how to deal with them, or for that matter circumvent them. Thus I thought that it would be suitable to cover a topic highly related to implementation of security policies – how to handle remote wipe

When dealing with the “wipe” concept there are two kinds of wipes we need to be aware of; local wipe and remote wipe.
(…)
I take a look at the low level details of the remote wipe process, along with some sample C# code that will get you started on your own.

I hope you’ve all been following along and gained a deeper understanding of the Exchange ActiveSync protocol, and possibly had time to play with coding something yourself if you are so inclined. We should at this time be able to do the initial FolderSync with Exchange, and handle most errors thrown at us.

There are of course tons of things ActiveSync I haven’t covered yet, and it is a “one step at a time” journey.

If you’re testing against an Exchange Server where you do not have direct access to the admin console, and it is under the control of an Exchange admin who doesn’t permit just about anyone to sync you might have run into issues related to provisioning already, so the next step for us is to cover this very topic.

Provisioning is the mechanism which ensures that ActiveSync clients implement a given set of security policies. If necessary; Exchange Server will block devices that don’t implement the policy set.

(…)

Follow along as I show in code how to perform the provisioning process, or bypass it for that matter

I have referred to WBXML a couple of times in this series, but so far not going into any detail other than generically describing it as “ActiveSync language”. I’m not attempting to make this seem like “magic” or anything, but when I started hacking around with the Exchange ActiveSync protocol myself I felt that I had to get comfortable with the basic concepts before going into this.

If you recall when we made our first sync attempt with the FolderSync command in a POST I included the following variable as the content of the POST:
(…)
I have no idea why I thought it logical to define the bytes with their decimal value rather than the hexadecimal value (which I have used in later WBXMLs). Still; this is a rather short and sweet snippet of WBXML so we should be able to decode it manually by using a lookup table. I’ve converted the values to hex, and “translated” each byte to the plain xml representation.

Read on for more fun with binary xml.