Exchange 2013 OWA logoff via TMG

OWA Forms Based Auth Logoff Changes in Exchange 2013 Cumulative Update 9 – And Good News for TMG Customers

Update - 2/9/15: Since publishing this blog we made a decision to push one aspect of this change to CU9 to allow some partners a little more time to adapt to this new behavior. The new signout.aspx code is still shipping in CU8, but we are not changing to the new logoff behavior, that is sending the user logging off to signout.aspx until CU9. To be clear, CU8 will actually contain the new signout.aspx page, but the code will continue to send users logging off to logon.aspx.

So all references to CU8 in the post below have been changed to CU9. All references to CU9 changed to CU10, and so on. Hopefully that’s not too confusing.

Now just between us, if you really want to take advantage of this new code in CU8 you can! As the code snippet below indicates (in which we have also corrected a small mistake), you can remark the line in web.config to ‘LegacyLogOff’ (or indeed set it to any value except “LegacyLogOff”, even removing the line completely has the same effect) and you will send users logging off to signout.aspx. Just be careful when you make these changes, and remember the upgrade order comments further down, they all still apply. Here’s a small table to make this all a little easier to grasp:

	<=CU6	CU7	CU8	CU9
Default Web.config files contain	n/a	<add key="LogonSettings.SignOutKind" value="LegacyLogOff" />	<add key="LogonSettings.SignOutKind" value="LegacyLogOff" />	<!-- add key="LogonSettings.SignOutKind" value="LegacyLogOff" /-->
Default logout goes to	Logon.aspx	Logon.aspx	Logon.aspx	Signout.aspx

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 CU9.

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-CU9 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 CU9 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 CU9 being publically available.

So what if the third party vendor solution you have wasn’t aware of this change, and once you install CU9 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 CU9 or later deployment.

2.       You can put in a temporary reversion to the older (CU1 and later) behavior. This change is only supported with CU9 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 CU10 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 (remove the !- - and trailing - - ‘s):

<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 anything other than “LegacyLogOff” or any then logoff ends on signout.aspx page (the new 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 CU10 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 CU9 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 or CU8 CAS you ask? Well we made code changes in CU7 such that this situation doesn’t crop up. So to put it simply once again, if your CAS is on CU7 or later, 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 or later, 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 CU9?

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 or later before you begin your CU9 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 CU9 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 CU9 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