Blocking OWA access for a user is a problem for Exchange 2013 CU1

Some people like to track the stream of knowledge base articles as they are released by Microsoft. I do not, possibly because there always seems to be better things to do such as write blog entries. So I am grateful to those of you who pointed out KB2835562, otherwise known as “You can't disable Outlook Web App (OWA) access for users in Office 365 or on-premises Exchange Server”.

Exchange 2007, 2010, and 2013 all support the ability to block user access to the various protocols supported by the server. The same is true when running Exchange on-premises or Exchange Online and is true for both BPOS (in the past) and Office 365. KB2573225 explains how to use the Set-CASMailbox cmdlet to enable or disable access to POP, IMAP, ActiveSync, MAPI, and OWA. It’s pretty simple to do but a highly effective method of controlling protocol access on a per-mailbox basis.

Exchange 2013 changes the rules of the game in that server roles are reduced to two: mailbox and client access (CAS). The CAS has been reduced to only providing authentication and proxy/redirection services, leaving the mailbox server to handle all protocol access and rendering.

Change is the way of the world and we are all accustomed to it. Unfortunately, problems can creep in when software changes. In this case, the Exchange developers have made some pretty fundamental changes to server roles and I expect that the problem that surfaced with controlling OWA access is symptomatic of what can happen when software evolves. It’s hardly a serious problem when viewed in the context of the overall landscape of Exchange, but it’s annoying that the issue has not been detected until now.

Microsoft prides itself on the build and test process that is used to verify software development does not introduce regression and this problem is a prime example of feature regression, which then makes you wonder just how effective the testing suite really is at detecting problems. Actually, I think that Exchange testing is pretty good overall. The reality is that the scale of use that the product gets magnifies any bug that sneaks through. This is not an excuse, merely an observation.

The bug is also present in the RTM version of Exchange 2013.  I expect that the fix for the problem will appear in the next cumulative update for Exchange 2013. CU2 should make its appearance in late June or early July.

In the interim, if you need to disable access to OWA for a particular user whose mailbox is on an Exchange 2013 server, you might be out of luck. The suggested workarounds in KB2835562 are not attractive. For Office 365, the workaround is to disable user access by setting the user’s sign-in status to “Blocked”, while for on-premises Exchange the equivalent is to disable their Active Directory account. Yikes!

I guess that the workarounds are appropriate if OWA is the only protocol used to access Exchange. However, if the user also has a mobile device that connects to Exchange via ActiveSync or even uses Outlook (MAPI) on an occasional basis, blocking access is a one-size affects all protocols solution that will cause the user to be unable to get to their mailbox, which might not be what you intend to do.

As I mentioned in my post about the Outlook soft-delete bug last week, Microsoft produces individual fixes for bugs that are reported and it is possible that if you have a support contract you will be able to get a fix by contacting Microsoft. On the other hand, if you run without support, you will just have to wait...

Follow Tony @12Knocksinna