So, what about ActiveSync in Exchange 2013?

Over the years Exchange ActiveSync (EAS) has grown into the standard in mobile mail, calendar and contact synchronization. Even groupware products other than Exchange have implemented this protocol to ensure synchronization with iOS, Android and Windows Mobile/Phone devices.

It has been adopted to almost any mobile device, even BlackBerry has succumbed with (yet to be released) BBOS10. And with Windows 8 and Outlook 2013, also a desktop OS (or whatever) will be able to use the protocol. Check out my blog posts on the Windows 8 EAS implementation here and here. So you could say it’s rather successful!

With every major Exchange release and sometimes with Service Packs, additions where made in the protocol. Adding more features to devices that obviously have to support the newest protocol version.

So, are there any new features in Exchange 2013 Preview Release? If so, what would that be and which devices would support those new features? Well, especially Windows Phone 8 (WP8) comes to mind and not all features of that smartphone OS are yet revealed and the expected release dates of Exchange 2013 and WP8 are close together. Maybe I can learn something new about WP8 via Exchange 2013? Yes, that would be very sneaky. 😉

The new Exchange Administration Center is no help here. There are no new options to be configured, there are even less options than in Exchange 2010’s Exchange Management Console. That doesn’t tell us anything, the Exchange Management Shell had always more configuration options.

So, looking into Exchange Management Shell. Best bet is to look into the New-ActiveSyncMailboxPolicy cmdlet, as it would create a new EAS policy and thus should have new parameters if there are any new features. Checking the cmdlet does not reveal any real changes, see TechNet documentation for the 2010 version and the 2013 Preview version. The differences?

Exchange 2010 SP2 Exchange 2013 PR
IsDefaultPolicy <$true | $false> IsDefault <$true | $false>

Just one parameter name change. Mhhh. That doesn’t look very promising. There was one thing that struck me when reading the TechNet documentation, but I’ll get to that later.

As EAS transport is in fact HTTPS based, I checked the Microsoft-Server-ActiveSync virtual directory in IIS.

Exchange 2013 IIS

Well, in the Xsd subfolder there are several folders of which the folder names correspond with the different EAS protocol versions that are supported since Exchange 2003. No v14.2 or v15 what I would expect with new features.

But I am making an assumption that the new EAS version would have a separate folder. What options do we have? At that time I started digging in the EAS protocol specification. It seems that during connection a protocol version is negotiated between the client and the Exchange server. This is done via the HTTP 1.1 OPTIONS command and the MS-ASProtocolVersions header in the server response lists the versions the server supports and the client then talks with the highest version it supports.

Because EAS traffic is secure by default I used Fiddler2 to intercept HTTPS traffic, decrypt it and see the responses. Basically a Man-in-the-Middle attack, but me being all men in this equation :-). I’ve used Exchange 2013 Preview Release installed on Windows Server 2012 RC. As an ActiveSync client I used Outlook 2013 Preview, it doesn’t make a difference if I used other clients as the response of the OPTIONS command is the only thing we actually need.

So, the OPTIONS command and it’s response (I’ve stripped some irrelevant or non interesting bits):

OPTIONS https://172.16.0.156/Microsoft-Server-ActiveSync HTTP/1.1
Connection: Keep-Alive
User-Agent: Microsoft.Outlook.15
X-MS-WL: Outlook/1.0

HTTP/1.1 200 OK
Cache-Control: private
Allow: OPTIONS,POST
Content-Type: application/vnd.ms-sync.wbxml
Server: Microsoft-IIS/8.0
X-TargetBEServer: lab02-ex2013a.wave15.nl
MS-Server-ActiveSync: 15.0
MS-ASProtocolVersions: 2.0,2.1,2.5,12.0,12.1,14.0,14.1
MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy,
CreateCollection,DeleteCollection,MoveCollection,FolderSync,
FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate,
MeetingResponse,Search,Settings,Ping,ItemOperations,Provision,
ResolveRecipients,ValidateCert
Public: OPTIONS,POST
X-FEServer: LAB02-EX2013A
Content-Length: 0

This is exactly the same as the earlier noted Virtual Directory subfolders. And again, no v15 or even a v14.2. Perhaps some hidden MS-ASProtocolCommands? I’ve checked this again on an Exchange 2010 server. Below is the response:

HTTP/1.1 200 OK
Cache-Control: private
Allow: OPTIONS,POST
Content-Length: 0
Server: Microsoft-IIS/7.5
MS-Server-ActiveSync: 14.16
MS-ASProtocolVersions: 2.0,2.1,2.5,12.0,12.1,14.0,14.1
MS-ASProtocolCommands: Sync,SendMail,SmartForward,SmartReply,GetAttachment,GetHierarchy, CreateCollection,DeleteCollection,MoveCollection,FolderSync, FolderCreate,FolderDelete,FolderUpdate,MoveItems,GetItemEstimate, MeetingResponse,Search,Settings,Ping,ItemOperations,Provision, ResolveRecipients,ValidateCert
Public: OPTIONS,POST

Nope, nothing hidden. Both commands are the same on Exchange 2010 and 2013. There are some headers previously not present, such as X-TargetBEServer and X-FEServer. I’m fairly certain these refer to the Front-End and a Back-End architecture in Exchange 2013. They both refer to the same server, which has both the Client Access and Mailbox role. But as far as these responses go, I would say that Exchange 2013 PR has the same function set regarding ActiveSync as Exchange 2010SP1+.

So… you remember the Exchange 2013 New-ActiveSyncMailboxPolicy I mentioned earlier? If you look at the TechNet documentation you can see an ominous warning:

The New-ActiveSyncMailboxPolicy cmdlet will be removed in a future version of Microsoft Exchange. Use the New-MobileMailboxPolicy cmdlet instead. If you have any scripts that use the New-ActiveSyncMailboxPolicy cmdlet, update them to use the New-MobileMailboxPolicy cmdlet.

 

Yeah, New-ActiveSyncMailboxPolicy will be replaced by New-MobileMailboxPolicy. Mhhhkay… the cmdlet is already implemented in the Exchange 2013 Preview, so let’s compare it! In this table only the differences are shown. If a parameter exists in both cmdlets, it is not shown.

New-ActiveSyncMailboxPolicy
(2010 SP2)
New-MobileDeviceMailboxPolicy
(2013PR)
AllowSimpleDevicePassword
<$true | $false>
AllowSimplePassword
<$true | $false>
AlphanumericDevicePasswordRequired
<$true | $false>
AlphanumericPasswordRequired
<$true | $false>
DevicePasswordEnabled
<$true | $false>
PasswordEnabled
<$true | $false>
DevicePasswordExpiration
<Unlimited>
PasswordExpiration
<Unlimited>
DevicePasswordHistory
<Int32>
PasswordHistory
<Int32>
IsDefaultPolicy
<$true | $false>
IsDefault
<$true | $false>
MaxDevicePasswordFailedAttempts
<Unlimited>
MaxPasswordFailedAttempts
<Unlimited>
MaxInactivityTimeDeviceLock
<Unlimited>
MaxInactivityTimeLock
<Unlimited>
MinDevicePasswordComplexCharacters <Int32> MinPasswordComplexCharacters
<Int32>
MinDevicePasswordLength
<Int32>
MinPasswordLength
<Int32>

Although the name of the cmdlet creating new ActiveSync Mobile policies has changed, no new parameters are present. All that are new can be related to similar Exchange 2010 parameters with another name; almost everywhere the word “device” has been omitted.

Conclusion

I think we can safely assume that there is no new EAS version or hidden ActiveSync features in the Exchange 2013 Preview. That means we can’t say anything new about features in Windows Phone 8 or the Windows 8 Mail app.

The question is if this will be the same for the RTM release or perhaps a 2013 Service Pack 1. But I’m a bit pessimistic about that. The new cmdlet, does not hint to any new features and is basically the same as the old cmdlet and actually more a name change than anything else.

The renaming of the cmdlet and it’s parameters and omitting “device” in almost all parameters suggests… well what does it suggest? What’s the significance? Could be just reminding people that not just devices can connect to Exchange, but also programs like Outlook 2013 and the Windows 8 Mail App? Why would you change the name of cmdlet and annoy anyone who has used this in scripts just for that?

Rebranding of ActiveSync? De-emphasis of ActiveSync? What’s up, Microsoft?

Thanks to Michael Van Horenbeeck and John A. Cook for the Fiddler tip!

Leave a Reply

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