Another example of a late-breaking change in Exchange 2010 SP1 that causes authors to tear their hair out (if they have any) is the new ability to control access to Exchange Web Services (EWS) on an organization-wide or user-specific basis. Organization-wide access is controlled through the Set-OrganizationConfig cmdlet while the Set-CASMailbox cmdlet controls access on an individual basis.
For example, to block access for a user:
Set-CASMailbox -Identity 'Joe Soap' -EWSEnabled $False
A quick description of the available parameters is shown below:
|EWSAllowEntourage||Specifies whether to allow or disallow Entourage 2008 for Mac, Web Services Edition to access Exchange Web Services for the user. Note that Entourage 2008 uses EWS exclusively, so this parameter can be used to block Entourage 2008.|
|EWSAllowList||Specifies the applications as identified by user agent strings that can access Exchange Web Services when the EWSApplicationAccessPolicy parameter is set to EnforceAllowList.|
|EWSAllowMacOutlook||Specifies whether to allow or disallow Outlook for Mac to access Exchange using EWS. Future versions of Outlook for Mac will use EWS exclusively.|
|EWSAllowOutlook||Specifies whether to allow or disallow Outlook 2007 to access Exchange Web Services for the user. Outlook uses Exchange Web Services for free/busy, OOF, and calendar sharing.|
|EWSApplicationAccessPolicy||Specifies which applications other than Entourage, Outlook for Mac 2011 and Outlook can access Exchange Web Services. If set to EnforceAllowList, only applications specified in the EWSAllowList parameter are allowed access to Exchange Web Services. If set to EnforceBlockList, every application is allowed access to Exchange Web Services except the ones specified in the EwsBlockList parameter.|
|EWSBlockList||Specifies the applications (user agent strings) that can’t access Exchange Web Services when the EWSApplicationAccessPolicy parameter is set to EnforceBlockList.|
|EWSEnabled||Specifies whether to globally enable or disable Exchange Web Services access for a user, regardless of which application is making the request.
When the EWSEnabled parameter is set to $false, Exchange Web Services access is turned off regardless of the values of the EWSAllowEntourage parameter.
For example, you could set organization access up so that EWS is only enabled for Outlook, Entourage, and a user agent that presents the string “OurGreatApp”:
Set-OrganizationConfig –EWSEnabled $True –EWSAllowOutlook $True -EWSAllowEntourage $True –EWSApplicationAccessPolicy: EnforceAllowList
SP1 does not expose any UI in EMC or ECP to control EWS access. This may appear in a future service pack for Exchange 2010, or then again, it might not… Now the question is whether I can fit this information into the book or is it just too esoteric to make me want to omit it, given that space is tight anyway…
Learn lots more about how to control Exchange 2010 clients in my Microsoft Exchange Server 2010 Inside Out book!
Other information (24 March 2011) from a correspondent who was struggling with EWS access. He writes:
It was a new consultant who found this document (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=894bab3e-c910-4c97-ab22-59e91421e022), followed it from page 8 onward, and recreated three publishing rules in TMG2010 (and also changed something related to authentication under ”Client Access Server” in Exchange). After that, it looks like everything works, including Outlook 2011 for Mac from outside the office, setting Out of Office replies via iPhone (even reliable Scheduling Assistant and Mail Tips when using Outlook Anywhere in Outlook 2010 for PC!).
We also needed forms based authentication (I think) to work for our OWA since some people need to be able to change their expired passwords via the Web. That was not working earlier, either.