Overcoming sticky logouts with Office 365, Azure, or Windows Intune in a web browser

Written by Keith Tuomi on . Posted in Azure, Internet Explorer, Microsoft, Office 365. Leave a Comment

​As an IT type, I find it required more often than most to be able to log out cleanly from various Microsoft services, or log out so I can then log in as another user.

Typically sessions on services like Office 365 seem “stickier” than most, particularly in NTLM-enabled (Windows Login) browsers such as Internet Explorer escalating through steps like:

– Clicking the logout button
– Clearing your browsers cache
– Closing and restarting your browser
– Cursing through gritted teeth

At the bottom of this post are 5 methods listed on Microsoft Support. You can mix and match and try but between all 5 of these you should be able to achieve a consistent, clean logout. The 1-2-3 steps described directly below should do it for you (not to mention having your Intranet Sites/Trusted Sites security settings configured properly is essential for a bunch of other reasons!)

(my) Winning 1-2-3 logout combo:

What I’ve found works solid every time is the following. The details for the Methods described can be found at the bottom of this post.

1. Perform the steps in Method 2: Add sites to the “Local intranet” and “Trusted sites” zones in the web browser 
2. Using the two links provided in Method 4: “Sign out of all Microsoft Online service”, add a link in your web browser favourites to provide quick access to the logout links. As most people would rather not reset all cookies and close out all browsers all the time, this method is ideal as it simply forces a logout to all Microsoft Online Services.

To install these bookmarklets simply right click and select “Add to Favorites” or drag the link below to your favorites bar to create a bookmarklet that will give you quick access to sign out any time.

Microsoft Online – Sign Out

Microsoft Live – Sign Out

You can also just click “Sign Out” under your username in the top bar of the Office 365 web application.

3. Close all instances of your browser as per Method 3: Close and Reopen all Web Browsers

That’s it, you should have a clean slate as far as authentication against Office 365/Azure/Intune at this point!

*Note: When you are logged into your Office 365 account and click “Sign Out”, it may seem like it does nothing but a page refresh. You may still seem to be logged in. If you close and re-open all instances of your current web browser after you’ve followed the previous 3 steps, this shouldn’t be an issue: once the browser is re-opened you should be kicked back to the login page as desired.
Office 365 logout

Method 1: Sign out and then sign in to https://mail.office365.com (https://mail.office365.com/) to access your mailbox

If you’re receiving the “We’re having trouble signing you in” error message, see the following Microsoft Knowledge Base article:

2912643

(http://support.microsoft.com/kb/2912643/ )

“We’re having trouble signing you in” message when you try to access your mail in Office 365

Method 2: Add sites to the “Local intranet” and “Trusted sites” zones in the web browser

  1. Click Start, type Control Panel, and then click Control Panel.
  2. Click Internet Options, and then click the Security tab.Note If Control Panel is set to Category view, click Network and Internet, and then click Internet Options.
  3. Add sites to the “Trusted sites” zone. To do this, follow these steps:
    1. Click Trusted sites, click Sites, and then click Advanced.
    2. In the Add this website to the zone box, for the following addresses, type each address, and then click Add:
      https://*.microsoftonline.com
      https://*.sharepoint.com
      https://*.outlook.com
      https://*.lync.com
      https://*.office365.com
      https://*.office.com
      https://*.microsoftstream.com
      https://*.sway.com
      https://*.powerapps.com
      https://*.yammer.com
    3. Click Close.
  4. Add sites to the “Local intranet” zone. To do this, follow these steps:
    1. On the Security tab, click Local intranet, click Sites, and then click Advanced.
    2. In the Add this website to the zone box, for the following addresses, type each address, and then click Add:
      • *.microsoftonline.com
      • *.sharepoint.com
      • *.outlook.com
      • *.office365.com
      • *.office.com
      • *.lync.com
      • *.microsoftstream.com
      • *.sway.com
      • *.powerapps.com
      • *.yammer.com
    3. Click Close, and then click OK two times.

Note: If you’re using single sign-on (SSO), your SSO addresses should also be added to the “Local intranet” and “Trusted sites” zones.

Method 3: Close and reopen all web browsers

Close all web browsers and then reopen them.To end the task for your browser, follow these steps:

  1. Right-click the taskbar, and then click Task Manager.
  2. Click the Details tab, and then do one of the following:
    • If you’re using Internet Explorer, find iexplore.exe in the list, right-click it, and then click End task.Note Make sure that you end the Iexplore.exe task. Do not end the Explore.exe task.
    • If you’re using Mozilla Firefox, find and right-click firefox.exe in the list, and then click End task.
    • If you’re using Apple Safari, find and right-click safari.exe in the list, and then click End task.
    • If you’re using Google Chrome, find and right-click iexplore.exe in the list, and then click End task.

    Notes

    • If more than one browser is listed, end the task for each browser.
    • If you’re using a different browser than those that are listed here, end the task for that browser

Method 4: Sign out of all Microsoft online services

You may be signed in to another Microsoft online service, and this may be preventing you from signing out. If this is the case, sign out of all Microsoft online services. To do this, follow these steps:

  1. Go to https://login.microsoftonline.com/logout.srf
    (https://login.microsoftonline.com/logout.srf)

    , and then sign out (if you aren’t already signed out).

  2. Go to https://login.live.com/logout.srf
    (https://login.live.com/logout.srf)

    , and then sign out (if you aren’t already signed out).

Method 5: Clear cookies from the web browser

Clear cookies from the web browser, and then try signing out again. The steps for doing this vary, depending on the browser that you’re using. For more information, see the following resources:

 

Browser Back Button History Not Working with SharePoint Managed Metadata menus

Written by Keith Tuomi on . Posted in Internet Explorer, Managed Metadata, SharePoint 2010. Leave a Comment

A client reported user grief in that when users clicked from static hyperlinks they had put on their SharePoint team site page Content Editor Web Part, which pointed to specific nodes on a Managed Metadata treeview menu, subsequent clicks of the browsers back button would not have the normal effect of returning to them from whence they came. In fact the back button in the browser really does nothing at all.

The reason is there is a # symbol at the tail end of the URL. The # symbol is traditionally used to denote anchor tags in HTML. In modern web applications it’s commonly used in AJAX techniques .

In the particular case of links to the nodes in the left-hand managed metadata menu, those links include a tag #serverfilter  with a bunch of parameters after that that tell the web browser to go to the specific node in the menu. Unfortunately, as the client discovered, Internet Explorer and some other browsers do not handle browser history normally when navigating via the # tag. Even though you are apparently loading new page content, the browser disagrees, because you are not actually loading an entire new web page – just a dynamic portion of Javascript that is displaying new content.

An example of such a URL is below – the offending #serverfilter and the variables it delivers are bolded.

https://sharepoint/teams/myTeam/MainLibrary/Forms/View.aspx?RootFolder=%2Fteams%2Fqms%2FMainLibrary&TreeField=Reference%5Fx0020%5FLevel&TreeValue=1522a33d%2D5b55%2D472f%2D970f%2Db09b9e804f3e#ServerFilter=FilterField1=Reference%5Fx0020%5FLevel-FilterValue1=106-FilterLookupId1=1-FilterOp1=In-TreeField=Reference%5Fx0020%5FLevel-TreeValue=1522a33d%2D5b55%2D472f%2D970f%2Db09b9e804f3e-OverrideScope=RecursiveAll-ProcessQStringToCAML=1

One of the biggest problems when using AJAX in web development has always been maintaining application state. In a Javascript heavy site (like SharePoint) one might want to do all sorts of things that alter the state of the user experience. For example, opening up modal dialogs (popups) over the page to request input from the user, etc. Because these state changes are occurring only with Javascript the browser is technically unaware of what is going on. If the user decides to hit the back button thinking they are just going back to before they opened a popup, they’ll be surprised when it takes them several steps backward to the last point where their browser actually made a full request. Similar issues occur when they refresh the page. The dynamic state is totally blown away and a new page request is made.

Since the basics of web navigation have always implied that a “new page” is what forms a single unit of web history, you’re not getting the back action as expected when direct linking to items in the Managed Metadata menu tree.  Unfortunately this is not a SharePoint-specific problem, it is endemic with lot’s of newer web applications online today from various vendors.

While I personally have coded workarounds for this type of problem in the past, it was for very specific, simple application scenarios (not like the huge complexity of SharePoint). In the case of out-of-the-box (mis)behavior like this I would advise simply that this unexpected back button behavior is the way it is and that users will have to adapt to selective back button history response (as they probably have on other online web applications). 

IE10 – Still the Champ

Written by Keith Tuomi on . Posted in Internet Explorer. Leave a Comment

​I had previously linked some independent survey results performed on IE10 Release Candidate. It’s now been updated for the release version:

http://samples.msdn.microsoft.com/ietestcenter/

For developers and consumers alike, successful W3C and Ecma International web standards are important for making the web better. A comprehensive test suite is an important part of a healthy standard, along with a clear specification and great implementations of the standard. Without thorough tests that assess the normative statements in a specification, a proposed standard is just a document on a website.

Any browser can claim to support some or all of a specification. The test results from a comprehensive test suite are the best way to determine which browsers will render the same markup consistently. Web developers have told us that seeing the test results, chapter-by-chapter, spec-by-spec, enables them to spend their valuable time building rich, interoperable web experiences for their customers.

We developed 19 new test cases and updated 46 test cases in conjunction with development of Internet Explorer 10. The IE Testing Center now offers a total of 7589 test cases.  We continue to work closely with these two web standards organizations by submitting these test cases officially within each working group’s official process.

We welcome your continued feedback on the test cases using the appropriate W3C mailing list for each working group. For ES5 test cases please open bugs in the test262 bug database.

The first table below summarizes the test results by specification with Internet Explorer 10 along with each of the major shipping browsers running on the Windows. The second table at the bottom of this page provides links to each of the test cases we submitted to each appropriate working group to help the web become more interoperable.

1