There’s a topic related to Exchange ActiveSync I’ve been meaning to cover for a long time. But through a combination of procrastination and lack of technical testing I haven’t gotten past the draft stage. I’m still not entirely done with that stage, but since I was already playing eagerly with Exchange 2010 RC I might as well cover one of the techniques now.

It’s ironic, but previously your main concern regarding the availability of ActiveSync was that it was a Windows Mobile exclusive feature. Then Microsoft started licensing it to other companies. DataViz released RoadSync for a number of devices which was a clean and nice implementation of the client bits. Nokia released Mail4Exchange. Even Apple who aren’t big fans of the company from Redmond knew they had better support it for the iPhone.

And the really impressive part is now other companies are implementing it server side as well. IBM announced a few months that Lotus Domino would use ActiveSync for doing push mail meaning that any device implementing ActiveSync could sync with Domino without third-party software. And the last thing I heard is that Novell is running a beta program currently implementing it for GroupWise.

I think you won this one Microsoft. I’ll give you that.

But with this backdrop set – this leads to a new problem. Whereas you had a limited device pool to choose from before now you have devices all over being able to sync. But they are not necessarily able to implement all security features, and not necessarily manageable. So, this creates a new challenge. You only want to allow a subset of devices, and only the subset you can have some level of control over.

With Exchange 2007 came the ability to define a security policy, and enforce that non-provisionable devices would not be able to sync. This feature has a couple of problems though:
- They apply on the user-level, not device-level. (You apply the policy to user accounts.) So if a user has two devices you have to either block both, or allow both.
- You have to be really good to keep track of which devices support which policies. (The quick answer is that only Windows Mobile 6.1 and 6.5 supports all policies at the time of writing this.)
- And you know what? It’s a matter of trust from the server perspective. The previous firmware on iPhone was able to report “yes, I support device encryption” even though only the iPhone 3GS actually does.

Apparently it’s not only me complaining about this. I’m getting more and more requests asking how can we block all these non-approved devices? And Microsoft seem to have been listening to someone. Exchange 2010 has features that allow you to have more control. Possibly not unsurprising I’m having a look at these settings today

I do not know if these features can be controlled to the Exchange Management Console – I couldn’t find them, but maybe it’s just me. I had to dig into the Exchange Shell to configure them.

First off – you can define the default action when a new device tries to establish a sync partnership (regardless of whether the device supports any policies). You can either allow, block, or quarantine devices. A quarantine means an admin will have to approve it before it can perform a sync.

You have the following two cmdlets to control this:
Get-ActiveSyncOrganizationSettings
Set-ActiveSyncOrganizationSettings

Get- is just a read-out of the current setttings. To set a policy execute something like the following:
Set-ActiveSyncOrganizationSettings –DefaultAccessLevel Quarantine –AdminMailRecipients admin@contoso.com

You’ll get a mail like this in your inbox:
Subject: “Your mobile phone is temporarily blocked from synchronizing with the server while permission to access is being verified.”

Body:

The admin you specified will receive the following mail:
Subject: “The mobile phone that belongs to contoso\andreas has been quarantined. Synchronization with the server via Exchange ActiveSync is blocked until you take action.”

Body:

So to allow the device the admin must fire up their Exchange Shell and execute something along the lines of this:
Set-CASMailbox –Identity andreas@contoso.com –ActiveSyncAllowedDeviceIDs 123456789ABCDEF

I believe this has scaling issues. Who on earth wants to be typing in horribly long device GUIDs every time a user fires up a new device. But it’s a start.

Taking it to the next step we have four more cmdlets for you:
New-ActiveSyncDeviceAccessRule
Get-ActiveSyncDeviceAccessRule
Set-ActiveSyncDeviceAccessRule
Remove-ActiveSyncDeviceAccessRule

Ok, they all work in conjunction to control the same feature. But this one is more interesting. You can create access rules, and limit access based on the following characteristics:
- Device Model
- Device Type

(Edit 22.04.2010: As pointed out by Hans in the comment section only Device Model and Device Type are valid characteristics. Device OS and User Agent removed.)

As an example the Windows Mobile 6.5 Professional emulator would result in the following values:
Device Type: PocketPC
Device Model: Microsoft DeviceEmulator
Device OS: Windows CE 5.2.21234
User Agent: MSFT-PPC/5.2.5001

Filtering based on the OS down to specific build numbers probably wouldn’t be your first choice, but filtering on model and type might make sense. The complete cmdlet would look like this if you wanted to block all PocketPC devices:
New-ActiveSyncDeviceAccessRule –QueryString PocketPC –Characteristic DeviceModel –AccessLevel Block

When I try to to do the initial synchronization on my emulator I’m told that I am not allowed to do this:

And an email in case you missed it:
Subject: Your mobile phone has been denied access to the server via Exchange ActiveSync because of server policies.

Body:

I believe this is definitely taking steps in the right direction as far as putting some restrictions in place. It’s not too admin-friendly at the moment being limited to the shell, but it’s probably not too unrealistic to expect something in SP1 whenever that comes around.

You also have some work with how you want to approach this – create access rules to allow specific known good devices, and block the rest? Or allow all by default and specifically blocking other devices? And you can still define and enforce security policies through the console.

I mentioned a few paragraphs back that there were other methods for restricting access, and even with these new features in Exchange I believe there’s still reasons to consider these alternatives. I still haven’t gotten around to finishing that original post I have been working on, but it’s never too late is it? I’ll see if I can put it some effort, and see what I can come up with