Block Mobile apps that use Exchange Web Services
We all know that with Exchange 2007 and Exchange 2010, ActiveSync is the preferred option for Mobile Devices to connect and synchronize mail. However, some business do not wish ActiveSync devices to connect, preferring to opt for a solution such as BES or Good sync. These businesses will often disable ActiveSync at the user account level, and then allow access to a small number of users who are permitted to use their non-corporate standard mobile device.
However, Some mobile apps use an alternative way to collect their email from the Exchange Environment. They will use Exchange Web Services to pull the email from Exchange, bypassing the security policies and control afforded by ActiveSync.
Disabling EWS isn’t really an option, as quite a lot of Outlook functionality relies on EWS. However, we have a few lesser-known pieces of functionality to block EWS for certain applications, based on their User Agent Strings.
We can control the usage of EWS by using the Set-CASMailbox cmdlet for a single user, or the Set-OrganizationConfig cmdlet to set the settings for the organization.
The Parameters to use with both of these cmdlets are below:
EwsAllowEntourage |
The EwsAllowEntourage parameter specifies whether to enable or disable Entourage 2008 to access Exchange Web Services (EWS) for the entire organization. The default value is $true. |
EwsAllowList |
The EwsAllowList parameter specifies the applications (user agent strings) that can access EWS when the EwsApplicationAccessPolicy parameter is set to EnforceAllowList. |
EwsAllowMacOutlook |
The EwsAllowMacOutlook parameter specifies whether to enable or disable Microsoft Outlook for Mac 2011 to access EWS for the entire organization. |
EwsAllowOutlook |
The EwsAllowOutlook parameter enables or disables Microsoft Office Outlook 2007 to access EWS for the entire organization. Outlook 2007 uses EWS for free and busy information, out of office settings, and calendar sharing. |
EwsApplicationAccessPolicy |
The EwsApplicationAccessPolicy parameter defines which applications other than Entourage, Mac Outlook, and Outlook can access EWS. If set to EnforceAllowList, only applications specified in the EwsAllowList parameter are allowed access to EWS. If set to EnforceBlockList, every application is allowed access to EWS except the ones specified in the EwsBlockList parameter. |
EwsBlockList |
The EwsBlockList parameter specifies the applications that can't access EWS when the EwsApplicationAccessPolicy parameter is set to EnforceBlockList. |
EwsEnabled |
The EwsEnabled parameter specifies whether to globally enable or disable EWS access for the entire organization, regardless of what application is making the request.When the EwsEnabled parameter is set to $false, EWS access is turned off, regardless of the values of the EwsAllowEntourage, EwsAllowMacOutlook, and EwsAllowOutlook parameters. For the EwsAllowEntourage, EwsAllowMacOutlook, EwsAllowOutlook parameters to be meaningful, the EwsEnabled parameter must be set to $true. |
By using these parameters, we can either Allow or Block EWS by default, and turn on/off certain applications. In the case of blocking specific applications from using EWS, we would allow EWS by default, and block these offending apps. Of course, the opposite can be completed as well, Block EWS by default, and allow required apps.
The Block/Allow lists work on the basis of the User Agent Strings generated by the EWS client. So, if you are looking to get a list of strings to block, you can take a look at your IIS logs.
A Log Parser command such as the following can be used:
| logparser.exe “SELECT date,time,c-ip,cs-username,cs-uri-stem,cs(User-Agent) INTO C:\Temp\EWSLog FROM “\\EXCHSERVER01\c$\inetpub\logs\logfiles\W3SVC1\u_ex1207*.log” WHERE cs-uri-stem LIKE ‘/EWS/Exchange.asmx’ AND cs-username IS NOT NULL” –I:IISW3C –o:TSV –headers:Auto –filemode:1 |
Explanation of the LogParser command:
WHERE cs-uri-stem LIKE ‘/EWS/Exchange.asmx’ – Ensures we are dealing with the EWS access parts of the IIS logs.
AND cs-username IS NOT NULL – Ensures we get userIDs back
-o:TSV – outputs to a tab-delimited file
-filemode:1 – overwrites the output file if it exists
If subsequent date from other Exchange Servers is required to be amended to the output file, set filemode to ‘0’
You can then load the resulting TSV into Excel, and create a pivot table showing the User Agents that are accessing EWS.
Interestingly in here, we can see that the BES is using EWS, and a lot of OWA/*Darwin style entries. From research, these appear to be Iphone apps syncing with EWS rather than ActiveSync.
So.. How can we block these?
Well , We can use the EWSBlocklist parameters. And the best bit, The parameters accept WildCard entries 
We can set these at both the individual mailbox level, and at the organization level. It is strongly recommended to do a test with a test user first, and then ensure everything is working before rolling out on an organization wide basis.
By default, the EWS config settings will look like this
To block for instance all the OWA/* apps, you can run the following commands
| Set-CASMailbox –identity “TestMailbox" –EWSApplicationAccessPolicy:EnforceBlockList –EWSBlockList:”OWA/*” –EWSAllowOutlook:$True –EWSAllowMacOutlook:$true –EWSAllowEntourage:$true –EWSEnabled:$true |
At this point, I would recommend running a full suite of tests against this test mailbox. Outlook 2010 access (focusing on Mailtips, OOF and freebusy, which all use EWS) Outlook for Mac (everything uses EWS) Blackberry (calendaring can use EWS).
Then try to connect the offending applications, and see if they are successfully blocked.
If this passes the testing, you can then look to run a wider test, and then when complete, run the Set-OrganizationConfig command to set this for the whole org.
Set-OrganizationConfig –identity “TestMailbox" –EWSApplicationAccessPolicy:EnforceBlockList –EWSBlockList:”OWA/*”
–EWSAllowOutlook:$True –EWSAllowMacOutlook:$true –EWSAllowEntourage:$true –EWSEnabled:$true
When complete, check the following settings with Get-OrganizationConfig
I would strongly recommend a communication to your user community before blocking this, as some users may have a relevant business reason to connect their ActiveSync device to the org. Also, remember that by using ActiveSync rather than EWS, users will be subject to the security policies set, and functionality such as Remote Wipe becomes available.
If you have found this useful, or if you have any questions, please let me know in the comments below!
Many thanks to Ed Crossley for his assistance with the images and some of the great content in this post.
Ed runs his own blog too, which you can find at https://exchangehero.tumblr.com/