Exchange Team Blog: OWA Forms Based Auth Logoff Changes in Exchange 2013 Cumulative Update 8 – And Good News for TMG Customers

Back at the release of Exchange Server 2013 CU1 we made some necessary changes to the way OWA logoff works. Those changes had the unfortunate side-effect of breaking the way TMG spotted a user’s attempt to logoff, thereby breaking that scenario.

Well, we have some more changes in mind for OWA logoff once again, and we’re taking the opportunity this time to FIX the TMG logoff issues at the same time. A better result all around we are sure you will agree.

And one more thing, this is a heads up, as we’re delivering this change in CU8.

So what are we changing? Well simply put, instead of sending you back to the logon form when you log out, we’re sending you to a new static logoff page, recommending you close your browser.

Why would we want to do that? Well, it means we have a more consistent logoff experience now whether the authentication used is FBA, Basic or Integrated Windows, the message gets presented for all. It also means we decouple log on and logoff, which means each can potentially be changed in some way without impacting the other.

So here’s the old, pre-CU8 way;

When using OWA, and when you click on sign out:

1. The client initiates logoff with the request to “/owa/logoff.owa”


2. Client then gets a 302 redirect to “/owa/auth/logon.aspx”

And you’re back at the logon page.

When using ECP, and the user clicks on sign out:

1. The client initiates logoff with the request to “/ecp/logoff.aspx”


2. Client gets a 302 redirect to “/owa/logoff.owa”


3. The client then gets another 302 redirect to “/owa/logon.aspx”

And you’re back at the logon page again.

Now here’s how we’re doing it in CU8 by default.

When using OWA, and when you click on sign out:

1. Client initiates logoff with the request to “/owa/logoff.owa”


2. The server sends to client a 302 redirect to the landing page “/owa/auth/signout.aspx”

Now you’re at the new signout.aspx page.

When using ECP and the user clicks on sign out:

1. Client initiates logoff with the request to “/ecp/logoff.aspx”


2. Client gets a 302 redirect to “/owa/logoff.owa”


3. Client gets a 302 redirect to the landing page “/owa/auth/signout.aspx”

And again you’re at the new signout.aspx page.

So now that you understand what we changed and why, why do you care? And why are we telling you now? We expect a large portion of our customers likely don’t need to care too much as the changes will be invisible to you, but some of you may need to (as our KB articles say) ‘consider the following’ scenarios;

You are using TMG and have it configured to watch for logoff.owa to signify a user was logging off. If you have that configuration today it will simply start to work again. That’s great news, isn’t it?

Regardless of TMG, it still might be important to you to know about this if you have any third party applications integrated into Exchange. We know of a few that have come to depend upon the behavior we introduced with CU1, and we know at least one (as they are participants in our TAP which makes them very smart fellows) who has already made the changes they needed to make to accommodate this in preparation for CU8 being publically available.

So what if the third party vendor solution you have wasn’t aware of this change, and once you install CU8 things break? Well, there are two things you can do;

1. Ask your vendor why, if they develop third party add-in apps for Exchange are they not reading our blog…. J And ask them when they will be fixing their app so it works with your CU8 or later deployment.


2. You can put in a temporary reversion to the older (CU1 and later) behavior. This change is only supported with CU8 or later, and the ability to make this reversion will potentially be removed from future updates – so don’t get used to using it, and don’t forget CU9 or later will wipe any web.config changes you make.

The legacy logoff mode can be enabled (disabling redirect to signout.aspx) by changing 3 web.config files.

On servers with the Client Access role;

• %ExchangeInstallPath%\FrontEnd\HttpProxy\OWA\web.config

On servers with the Mailbox Role;

• %ExchangeInstallPath%\ClientAccess\OWA\web.config


• %ExchangeInstallPath%\ClientAccess\ECP\web.config

Modify the following line (make sure you make a backup of web.config before you do this):

<add key="LogonSettings.SignOutKind" value="LegacyLogOff" />

To look like this (the !- - and trailing - - ‘s ensure it is treated as a comment line and not acted upon):

<!-- add key="LogonSettings.SignOutKind" value="LegacyLogOff" /-->

AppPools will recycle automatically on the change unless that has been disabled, in which case it will need manually recycling.

If the entry is not present, or the value is “DefaultSignOut” or any other value then logoff ends on signout.aspx page (default).

And don’t forget, the next Cumulative Update will reset this manual modification, so be prepared to do it again if you must after CU9 releases. Ideally though, if the reason you are doing this is to allow some third party app to work, that app should be updated to live with the new behavior.

The final, and perhaps the most important scenario is that this change introduces an install order dependency, something we thankfully have quite rarely, but something you need to pay attention to on this occasion.

Simply put, if a user’s mailbox is on a CU8 Mailbox server but connecting through a CU6 or earlier CAS, they will see an issue at OWA logoff due to this change. What about if you have CU7 CAS you ask? Well we made enough code changes in CU7 that this situation doesn’t crop up. So to put it simply once again, if your CAS is on CU7, or CU8, or if you have only multi-role servers at CU7 or later, no problem, none, not at all.

So, what’s the best way to make sure you won’t hit an issue? Keep up to date of course, as that means all your servers are already at CU7, so you have nothing to worry about.

What if on the other hand you are coming from CU6 or earlier and you expect users might be using OWA during the window in which you plan to install CU8?

Well if you have separate CAS/MBX roles (and if you do… why?) then we recommend you update all the CAS first. Then you can update the Mailbox servers in any order you like. That’s the simplest solution by far.

If, on the other, other hand, you have all multi-role servers (well done you, we like you), and they are CU6 or earlier, then you have three choices;

• Upgrade them all to CU7 before you begin your CU8 rollout.


• Accept there may be some funky issues during that upgrade window and simply decide you want to live with it.


• Do a rolling upgrade and be smart with your load balancing pool so all incoming connections hit only upgraded CU8 CAS. If you don’t have any idea what that means or how to do it, it’s not the option for you. Take the first option.

We hope this gives you what you need to successfully get your servers to CU8 and hope you TMG stalwarts are once again happy and pleased the logoff experience is properly working again.

Greg Taylor

Principal PM Manager

Office 365 Customer Experience

from Exchange News Full Article