If you’re migrating from Exchange 2003 to Exchange 2007 or 2010, you’ll find a new toy to play with. The Exchange Web Service. The EWS was meant to replace older Exchange interface such as WebDav and CDOEX, providing developers an easier way to integrate their software and solutions to Exchange system. In practice, not only software and systems, the EWS is also used for end-user apps syncing method, such the case with Blackbery phones and Outlook for Mac.
Which is bad. Why? Unlike any other end user features such as OWA and ActiveSync which you can assign on per-user basis, EWS is an organization-level feature. It’s either on for all users, or off. So for example, if you turn it on and publish it on the internet, all of your users with cheap BIS plan get to use their blackberry to sync with Exchange.
Now, there are several approach that can be used to work around this problem. The first one, is to setup a filter on EWS.
To be fair, the EWS has some rudimentary per-user basis filtering. You can turn EWS for Outlook or Entourage sync on for certain users, and leave the rest of your user without them. For example, if you have enabled EWS on organization level, you’re supposed to be able to turn off, let say Outlook for Mac by doing this on Exchange PowerShell:
Get-Mailbox -Identity username | Set-CASMailbox -EWSAllowEntourage: $False
Now, The BlackBerry on the other hand, is a quite different story since there isn’t any EWS parameter that can be used to allow or block connection from BIS. The only way to block (or allow) Blackberry BIS connection is setup an EWSBlockList (or EWSAllowList) against the browser user agent used by BIS. Identifying this is quite easy. First enable EWS on organization level, then try to connect to your Exchange 2010 server with a BIS equipped Blackberry handset. Your IIS should now have a log of your successful connection attempt. The logfiles is located on inetpub\Logs\LogFiles\W3SVC1. Open the newest one, and search for the latest entry containing your account name. That line should contain something like this:
Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0)
Which is the user agent string that is used by Blackberry BIS service. Next, to setup a block list.
At this point, we have several options. We can A. block BIS by setting up an EWSBlockList for the above user agent, or B. If you don’t have any other external services that connect to EWS, you can close the whole EWSApplicationAccessPolicy
To do A, you need to create a block list:
Get-Mailbox -Identity username | Set-CASMailbox -EWSApplicationAccessPolicy: EnforceBlockList
..and then create the filter:
Get-Mailbox -Identity username| Set-CASMailbox -EWSBlockList: {"Mozilla*"}
This will block Blackberry BIS, and any kind of systems or apps that masquerade as Mozilla browser.
To do B, you need to create an allow list
Get-Mailbox -Identity username | Set-CASMailbox -EWSApplicationAccessPolicy: EnforceAllowList
And then, create a secret key on the allow list:
Get-Mailbox -Identity username| Set-CASMailbox -EWSAllowList: {"*SecretKey*"}
This way, only a systems or applications with “SecretKey” as user agent can gain access to the EWS, effectively blocking any kind of application from connecting to EWS. If you, somewhere around the line decide to create or adopt a system that will use EWS, all you have to do is to adjust the secret key to match the the new system user agent. Or better yet, edit the system user agent to match your secret key.
The second way to block BIS is to block connections originating from BIS server IP addresses. I will cover this on part. 2 of Blocking Exchange Web Service from Blackberry BIS.
Update 28/01/2013:
Part. 2 is up. Check it here