• Seamlessly embedded Cognos Analytics in SharePoint applications
• More is more – maximize the screen size of Cognos Content
• Less is more – don’t require users to be trained on 11.X

Overview

QueryVision’s Cognos Component SharePoint web part offers options on showing and hiding

• IBM Cognos Analytics UI
  • Navigation bar (left side bar)
  • Application bar (top bar)
• SharePoint UI
  • Hide Page Header bar
  • Hide Navigation Sidebar

3 Reasons to control how Cognos content is displayed in your SharePoint application

Seamlessly embedded Cognos Analytics in SharePoint applications

For a business applications, embedded reports and analytics need to be seamlessly integrated as “just another element” on a page. The application may call for a range of analytics presentation to the user including view only, limited interaction, to full authoring. The techniques and features described here provide the web app developer with the ability to show as much or as little of IBM Cognos Analytics components and UI as required on a web part/web page by page basis

More is more – maximize the space for reports

While Cognos Analytics can be authored to provide reports that adapt to window size and screen resolution, there is a limit to auto-adjusting via “responsive” design techniques.

In addition, many Cognos reports were designed assuming (due to layout or information density) to be viewed at full screen.

SharePoint application design is frequently based on one or more “Master” pages which become a [default] template for all pages in the application. Frequently this includes a page header (at the top) and a navigation sidebar (on the left) which includes site wide navigation and action controls and menus. For the Master page template (e.g. Teams app) the header/nav sidebar consume 50% or more of the screen space!

QueryVision provides SharePoint techniques to show/hide these SharePoint page elements, with optional user control.

Less is more – limit user options

Tailor the embedded Cognos experience to the audience

Ensure users don’t get lost – ensure users use SharePoint vs. Cognos navigation

IBM Cognos can support a range of users, including, email/PDF recipients, reports consumers, interactive business users, ad-hoc analysts, analytics authors, etc.

Our Customers tell us that in SharePoint apps they need to restrict access to the Cognos UI:

• Many of their SharePoint users are not trained on the Cognos application or the organization of Cognos content in the 11.x folder structure – so offering the 11.X UI is potentially confusing.
• A key feature of SharePoint apps to provide navigation with the app pages and control access to external tool, which in many cases means “disabling” 11.X UI navigation
• The desired Analytics behavior on most SharePoint app pages is as report consumer (view only) or where interactivity (e.g. filtering, drill down) is restricted to that built into the report or dashboard.

QueryVision provides the ability to hide or show the 11.X application and navigation toolbar on an individual web part basis

How to…

Show/Hide IBM Cognos 11.X toolbars

IBM Cognos Analytics 11.X supports both the 10.X content  types and the new 11.X types

• 10.X Cognos Content
  • Reports (10.X compatible reports are 11.X reports with ‘interactive’ : false – in the report authoring tool)
  • Analysis Studio, Query Studio, PowerPlay Studio, etc. etc.
  • Portal Pages
  • ..

10.X content can be accessed and presented with the QueryVision Report Viewer Web Part.

• New 11.X Analytics Content
  • Reports (with interactive: true)
  • Dashboards (exploration dashboards)

11.X content can be viewed with the QueryVision Cognos Component Viewer Web Part.

• For how to use the Cognos Component Viewer Web Part see Section 8.9 of the QueryVision Web Parts Installation Guide

For 11.0.13+, both the Dashboard and interactive Reports are presented by capturing the “Share Link” as defined here:

How to find the Share for a report or dashboard

For example – the following is Share link for the sample report “Corporate Website visits”:

https://w16ca111a/ibmcognos/bi/?pathRef=.public_folders%2FSamples%2FReports%2FCorporate%2Bwebsite%2Bvisits

To hide the navbar (left panel) or appbar (top panel), append the following to the Share:

&ui_appbar=false

&ui_navbar=false

For example:

https://w16ca111a/jbmcognos/bi/?pathRef=.public_folders%2FSamples%2FReports%2FCorporate%2Bwebsite%2Bvisits&ui_appbar=false&ui_navbar=false

In the Cognos Component Web Part ensure either of the following:

Report

• Component Type: Analysis Report
• Analysis Report Share: the share link, as defined above

Report

• Component Type: Analysis Dashboard
• Analysis Dashboard Share: the share link, as defined above

Show/Hide SharePoint page elements

Showing/Hiding the SharePoint page header and navigation sidebar are part of the QueryVision Autosizing tool-suite, which is covered here:

QueryVision Report Viewer Autosizing

In particular, see the QueryVision Report AutoSizing Guide, Chapter 8 – SharePoint Page Layout Modification Tools and the samples and JavaScript source/libraries in the AutoSizing Samples

In the SharePoint page below:

• The Cognos Components viewer is showing a Dashboard with the 11.x appbar (top) and navbar (left side) hidden
• The SharePoint page header/nav sidebar show/hide scripts have been added via a Script Editor web part, currently showing the buttons “Hide Header” and “Hide Navigation”. The scripts in this state are in “Show” mode for both the header and navigation.

Note the “hide/show” buttons are optional. The source code is available to change as required.

• The SharePoint header and navigation sidebar are visible

The user clicked on “Hide Header” button, which has changed to Show Header. The page header is hidden

The user clicked on Hide Navigation, which hides the SharePoint navbar. In the example below both page header and the side navbar are hidden

QueryVision SharePoint Display options for IBM Cognos Analytics 11.X Dashboards and Interactive Reports

Users who bookmark ICA 11.X interactive reports and dashboards may find they are broken in newer 11.X releases

Web/App Developers – Use “Share” links or embed code  + IBM extensions vs the URL formats ICA 11 puts in the Browser Address bar/field (URL) to run “interactive” Reports and Analytics 11 Dashboards in web applications

Why are Report URLs important?

IBM Cognos has long relied on URLs with a rich collection of query string options to run reports and dashboards, show a specific file format of a saved report and to launch different Cognos tools.

When a user creates a bookmark (in any browser), the bookmark is created using the URL shown in the browser address bar/field.

They are also used by web application developers to link to/launch those reports within applications. QueryVision also makes extensive use of URLs in addition to SDK calls in the QueryVision SharePoint Web Parts for Cognos.

ICA 11.X URL formats are not stable

With 10.x.x, while IBM would introduce new forms of the URLs and introduce new query string parameters, over time, but the existing URLs were stable. And in 11.x, those 10.x.x URLs continue to be supported.

However, the internal URLs that are generated (as seen in the browser address bar after the report or dashboard has executed) have changed substantially from release to release (e.g. 11.0.7 … 11.1.2) and are not forward compatible. This means that a user’s bookmarks for ICA 11 reports and dashboards will break.

While the ICA 11 UI does provide the Share Icon for users:

the ICA UI does not provide a way to turn that into a bookmark. While it is possible to edit a bookmark and insert the Share URL, it’s several extra (Browser specific) steps. And, as a ICA 11.X report bookmark created will work in the current release, the user will not realize the URL is not forward compatible until it fails in the next ICA 11.X release

On the other hand, the URLs provided by the “Share” feature (Share Links are stable URLs) can be extended to create report and dashboard links with options for web applications, which are stable over 11.X releases

What’s changed – how different are the URLs?

However, in testing with ICA 11.0.7 , 11.0.13 and 11.1.2 we have discovered that not only have the URL formats for 11.X interactive report and dashboard generated by Cognos (and shown in the Browser Address bar) changed substantially with each release, but they no longer work in newer releases.

URL formats from 11.0.7 and 11.0.13 to run the same sample report in 11.1.2 resulted in the report authoring tool launching the “Template and themes” panel as if we were building a new report with no data source defined

As illustration, here are the URLs IBM ICA 11.0.7, 11.0.13 and 11.1.2 used to run the “Corporate website visits” sample report. The URLS have been unravelled/expanded for clarity…

// ICA 11.0.7

http://w16ca111A:80/thrpntcognos/bi/?
perspective=authoring
&context=%7b%22perspective%22%3a%22authoring%22%2c%22content%22%3a%7b%22module%22%3a%22bi%2fauthoring%2frsContentView%22%2c%22id%22%3a%22http%3a%2f%2fw16ca111a%2fjbmcognos%2fbi%2f%3fpathRef%3d.public_folders%252FSamples%252FReports%252FCorporate%252Bwebsite%252Bvisits%22%2c%22isViewer%22%3atrue%2c%22isNewFromModule%22%3afalse%2c%22isNewFromPackage%22%3afalse%2c%22cmProperties%22%3a%7b%22runInAdvancedViewer%22%3afalse%2c%22executionPrompt%22%3atrue%2c%22permissions%22%3a%5b%22execute%22%2c%22read%22%2c%22setPolicy%22%2c%22traverse%22%2c%22write%22%5d%2c%22modificationTime%22%3a%222016-05-25T19%3a49%3a07.567Z%22%2c%22options%22%3anull%2c%22id%22%3a%22http%3a%2f%2fw16ca111a%2fjbmcognos%2fbi%2f%3fpathRef%3d.public_folders%252FSamples%252FReports%252FCorporate%252Bwebsite%252Bvisits%22%2c%22type%22%3a%22report%22%2c%22defaultName%22%3a%22Customer+satisfaction+and+returns%22%2c%22version%22%3a2%7d%2c%22rsFinalRunOptions%22%3a%7b%22format%22%3a%22HTML%22%2c%22a11y%22%3afalse%2c%22bidi%22%3afalse%2c%22runInAdvancedViewer%22%3afalse%2c%22prompt%22%3atrue%7d%7d%7d

// which decomposes to the following with URL decode

http://w16ca111A:80/thrpntcognos/bi/?
perspective=authoring
&context=<json> 
{
   "perspective":"authoring",
   "content":{
      "module":"bi/authoring/rsContentView",
      "id":"http://w16ca111a/jbmcognos/bi/?pathRef=.public_folders%2FSamples%2FReports%2FCorporate%2Bwebsite%2Bvisits",
      "isViewer":true,
      "isNewFromModule":false,
      "isNewFromPackage":false,
      "cmProperties":{
         "runInAdvancedViewer":false,
         "executionPrompt":true,
         "permissions":[
            "execute",
            "read",
            "setPolicy",
            "traverse",
            "write"
         ],
         "modificationTime":"2016-05-25T19:49:07.567Z",
         "options":null,
         "id":"http://w16ca111a/jbmcognos/bi/?pathRef=.public_folders%2FSamples%2FReports%2FCorporate%2Bwebsite%2Bvisits",
         "type":"report",
         "defaultName":"Customer+satisfaction+and+returns",
         "version":2
      },
      "rsFinalRunOptions":{
         "format":"HTML",
         "a11y":false,
         "bidi":false,
         "runInAdvancedViewer":false,
         "prompt":true
      }
   }
}

//11.0.13

http://w16ca11/ibmcognos/bi/?
perspective=authoring
&id=iCBB313DB6CC745608E590CCB29B51B26
&isViewer=false
&isNewFromModule=false
&isNewFromPackage=false
&isNewDataSetFromModule=false
&isNewDataSetFromPackage=false
&isTemplate=false
&isDataset=false
&UIProfile=Titan
&cmProperties%5Bid%5D=iCBB313DB6CC745608E590CCB29B51B26&rsFinalRunOptions%5Bformat%5D=HTML&rsFinalRunOptions%5Ba11y%5D=false&rsFinalRunOptions%5Bbidi%5D=false&rsFinalRunOptions%5BrunInAdvancedViewer%5D=true&rsFinalRunOptions%5BDownload%5D=false&rsFinalRunOptions%5Bprompt%5D=true&rsFinalRunOptions%5BisApplication%5D=false

// URL Decoded for clarity:

http://w16ca111a/jbmcognos/bi/?
perspective=authoring
&pathRef=
.public_folders/Samples/Reports/Corporate+website+visits
&id=i35A456A7092046B68BCB3D3DBB8D61E9
&objRef=i35A456A7092046B68BCB3D3DBB8D61E9
&cmProperties[id]=i35A456A7092046B68BCB3D3DBB8D61E9
&cmProperties[type]=report
&cmProperties[defaultName]=Corporate website visits
&cmProperties[permissions][]=execute
&cmProperties[permissions][]=read
&cmProperties[permissions][]=setPolicy
&cmProperties[permissions][]=traverse
&cmProperties[permissions][]=write


//11.1.2

http://w16ca111a/jbmcognos/bi/?
perspective=authoring
&id=i35A456A7092046B68BCB3D3DBB8D61E9
&objRef=i35A456A7092046B68BCB3D3DBB8D61E9
&cmProperties%5Bid%5D=i35A456A7092046B68BCB3D3DBB8D61E9
&cmProperties%5Btype%5D=report
&cmProperties%5BdefaultName%5D=Corporate%20website%20visits&cmProperties%5Bpermissions%5D%5B%5D=execute
&cmProperties%5Bpermissions%5D%5B%5D=read
&cmProperties%5Bpermissions%5D%5B%5D=setPolicy
&cmProperties%5Bpermissions%5D%5B%5D=traverse
&cmProperties%5Bpermissions%5D%5B%5D=write

“Share” links are stable URLs

The “Share” feature creates URLs that are compatible between 11.X releases and can be extended with optional parameters.

How to find the Share for a report or dashboard

Finding the Share option in the ICA 11 UI App Bar

Finding the Share option in the ICA 11 UI for a Report or Dashboard

Selecting the Share “link” to use the raw URL, “embed” if you want to drop directly into your HTML page

The following is an example of a Share “Link”

// ICA 11.1.2 example 

http://w16ca111a/jbmcognos/bi/?pathRef=.public_folders%2FSamples%2FReports%2FCorporate%2Bwebsite%2Bvisits

// URL decoded

http://w16ca111a/jbmcognos/bi/?pathRef=.public_folders/Samples/Reports/Corporate+website+visits

Starting with the Share link as provided from the UI, the can be extended.

IBM information on URL formats for extending Share “links” and “embed code”

IBM does provide information on using URLS:

Creating custom URLs to display and run Cognos Analytics content

While this has not not been updated since 11.0.7, they appear to be valid in 11.1.2

IBM Analytics 11.X Report URLs – they are a changing…

Discovered in our support of IBM Cognos Analytics 11.0.9 is a a buggy Microsoft IIS module to avoid and a tool to automate IIS configuration.

Avoid Microsoft Application Request Routing (ARR) module 3.0.1988

To support the IIS configuration for Single Sign On/and or use of an IBM Cognos Gateway requires the addition of the IIS module: Application Request Routing.

The latest version can be found here as a Web Platform Installer (WPI) installation. As of 25-Jan-2018, this will install version 3.0.1988 (despite the fact that the download page says 3.0.1952), which – as we found out the hard way – causes an HTTP 500.50 (rewrite fail) error. This problem does not occur with the previous version 3.0.1952.

If you are installing the ARR for the first time, you can download the previous version (3.0.1952) from IExpress x64 installation

Unfortunately, if you have already installed 3.0.1988 – you may have more work to do – see our KB article – Install or update the IIS Application Request Routing module

New Tool

Setting up ICA 11 with a Gateway and in particular for Single Sign On (SSO) requires much more complex configuration of Microsoft IIS, which is prone to missing steps or miss-typing.

And, IBM appears to be constantly updating the configuration details, as the current instructions for ICA 11.0.4+ have changed since 11.0.5 (currently 11.0.9)

QueryVision recently learned of a script which greatly simplifies the process.

For details on use of the script – see our KB article – Automating ICA 11.X configuration for IIS

Warning and tools for SSO support for IBM Cognos Analytics 11.X

With the release of IBM Cognos Analytics 11.X, IBM has dropped support for the use of portlets (Portal Services), including support for SharePoint integration.

This can be confirmed by the fact that the  Supported Environments for ICA 11.X no longer includes a “Portal Servers” section under “Supported Software”.

In addition, with ICA 11 has updated the Internet Explorer 11 rendering requirements to be IE=EDGE, which is not supported (without customization) by SharePoint 2010, 2013 or 2016 – see Understanding Cognos, Internet Explorer and SharePoint

QueryVision continues to update and support IBM Cognos 10.X and 11.X, which includes support for 11.0.9 (as of 16 Feb 2018) and is committed to supporting future versions as well

IBM Cognos Analytics 11 – support from IBM for Web Parts/Portal Services

Microsoft released [Internet Explorer] “Enterprise Mode” in the spring of 2014 to provide Workstation Administrators with a central, comprehensive tool to manage compatibility mode for web sites in Internet Explorer 11.

This is fully supported by QueryVision with the following recommendations:

• Use IE 11 – While MS Edge has tested well for ICA 11.X stand alone and in testing in SharePoint with QueryVision for Cognos/SharePoint integration, Edge is not officially supported by IBM Cognos
• Recommended Enterprise Modes – any of the following can be used:
  • Default Mode
  • IE8 Enterprise Mode
  • IE 7 Enterprise Mode

This includes IBM Cognos 10.2.X, Analytics 11.X, SharePoint 2010, 2013 or 2016 in any combination using QueryVision’s SharePoint Web Parts for IBM Cognos.

For more details, see Understanding Microsoft Enterprise Mode

Using Microsoft Enterprise Mode for IBM Cognos, SharePoint and QueryVision

The IBM Cognos Analytics 11 (ICA 11) user interface and platform functionality were not designed with Portal Pages and Portal Tabs in mind.

However, by using Reports with HTML items, the new UI “Extensions” capability and the “Legacy Portal” we can effectively emulate the Portal Page of IBM Cognos 10.X functionality in ICA 11.0.5+.

This includes setting a Portal Page as a Home page, including setting them by user Role in the ICA 11.0.5 Admin interface.

The screen shot, below shows a portal page shown in the ICA 11 UI as the Users home page, along with a Portal Tabs folder in the Nav Bar (which can be used select other portal pages).

For details see this “How To” in our Knowledge Base

Supporting Portal Pages/Tabs in IBM Cognos Analytics 11.X

QueryVision’s 2016.1 version of SharePoint Web Parts for IBM Cognos adds support for IBM Cognos Analytics 11 on SharePoint 2010, 2013 and 2016, in addition to continued support for all IBM supported versions of IBM Cognos 10.

For more information:

• Video: Announcing 2016.1 QueryVision SharePoint Web Parts for Cognos
• What’s New for 2016
• Embedding IBM Cognos Analytics 11 in SharePoint

Integrating IBM Cognos Analytics 11 with SharePoint 2013 & 2016

Summary

In testing with the Windows 10 “[2016] Anniversary Update”,  QueryVision has  found that direct access to IBM Cognos (including IBM Cognos Analytics 11) or access via QueryVisions Web Parts for Cognos may be blocked for IE 11 without updating the new Group Policies for IE 11 introduced by the Windows 10 “Anniversary Update”

See:  Windows 10 Anniversary Update will improve interoperability between Microsoft Edge and IE 11

Windows 10 Browsers

Windows 10 provides both IE 11 and the new Microsoft Edge.

A critical factor for both IE 11 and Edge are the ability to pass domain credentials to IBM Cognos and  – for QueryVision’s SharePoint Web Parts for Cognos – through SharePoint to Cognos.

Edge, by design, does not support Integrated Windows Authentication in the same way as IE, relying on prompting users and saving credentials for sites that require authentication using the Win 10 Credential Manager. As this is questionable to many Corporate users, it is generally recommended to continue to use IE 11 for access to Cognos for Windows 10. This is underlined by IBM Cognos not offering support for MS Edge.

Why is this important?

Standard practice for IIS for Cognos is to protect access to the Virtual Directories (e.g. http://<cognos server>/ibmcognos/) via disabling anonymous access and enabling Windows Authentication (Windows Integrated Authentication) for the ibmcognos virtual directory and any sub-directories.

If the user’s “domain”/Windows credentials are not passed, when accessing ibmcognos/* via a URL, the user will be challenged by the browser for their windows credentials – otherwise access is denied.

For IE (including IE 11) on Windows 7/8/8.1 and 10 before the Windows 10 “Anniversary Update”, Integrated Windows Authentication (IWA) worked without issue. Chrome and Firefox will challenge for credentials, but they can be configured to support IWA. And they work fine on Windows 10 pre and post “Anniversary Update”. But after application of the Win 10 “[2016] Anniversary Update”, IE 11 effectively stops passing credentials, even with identical “user” settings to IE 11 on Win 7/8/8.1 and even Win 2012 R2. We also note that additional Internet Options appear in IE 11 on Windows 10 post “Anniversary Update” that do not appear on other Windows platforms. Effectively IE 11 on Windows 10 is now a specialized version.

What has Changed?

Microsoft is increasing taking steps to promote Edge, encouraging customers to use a combination of IE 11 and Edge with use of IE 11 only when absolutely required.

With the Windows 10 “Anniversary Update” they have further integrated IE 11 and Edge including new Group Policies which impact IE access to Windows Authentication protected sites. Microsoft says:

Starting with the Windows 10 Anniversary Update, we are introducing a new Internet Explorer group policy to restrict IE11 usage to only sites on the Enterprise Mode Site List: “Send all sites not included in the Enterprise Mode Site List to Microsoft Edge.” Enabling this setting automatically opens all sites that are not included in the Enterprise Mode Site List in Microsoft Edge. We recommend setting Microsoft Edge as the default browser when enabling this policy.

This feature works with both the v.1 and v.2 XML schemas. If you also have the “Send all intranet sites to Internet Explorer 11” Microsoft Edge group policy enabled at the same time, then all intranet sites will continue to open in IE11.

Symptoms

The symptoms of the problem are that when accessing IBM Cognos Analytics 11 using the SSO URL

http://w12r2ca111/ibmcognos/cgi-bin/cognosisapi.dll?b_action=xts.run&m=portal/main.xts&m_redirect=/ibmcognos/bi/

The page gets a “can’t display page” error, even with “Enable Integrated Windows Authentication” IE 11 Internet option.

Windows 10 access to Cognos

A Service Account allows a SharePoint site or sub-site displaying one or more Cognos based dashboards or reports to use a single Cognos account to transparently authenticate for all users.

This can be useful in several scenarios:

• Unrestricted Public site – users can access all content, including Cognos
• “Registered” Public site – users have to register to get access to “high value” content, such as Cognos reports. This allows tracking of who is using the site (and Cognos content) and what they are accessing, while transparently controlling which Cognos account is used
• Multi-client/customer external facing sites – one per customer. Either a single Service Account is used for all visitors from that customer or a small number of sub-sites and Service Accounts for different (SharePoint defined) groups within that customer

Is my application a candidate for Service Accounts?

While external facing sites are obvious candidates for Service Account use, Intranet applications can also qualify.

SharePoint applications that access Cognos BI have to manage both SharePoint access, rights and privileges and Cognos access, rights and privileges. If SharePoint users are also Cognos users and if the SharePoint authentication authority (e.g. Active Directory) is also the Cognos authentication authority, then Single Sign On simplifies life by only having a single account for both SharePoint and Cognos.

However, there are cases where SharePoint and Cognos use different authentication authorities, which would require separately managed accounts for each user (one for SharePoint and one for Cognos) and require that the user log in twice or use a more sophisticated SSO technique (e.g. Quervisions Dynamic SSO).

An alternative is to manage access to SharePoint sites and sub-sites by the User or (preferred) SharePoint Group membership and use Service Accounts for Cognos to provide what feels like “Single Sign On” to the user, but is in fact using a transparent hidden Cognos account which is decoupled from SharePoint authentication.

Service Account Candidate

• One or more relatively large (application) groups of people which share the same access rights (Cognos Group) and privileges (Cognos Role) within Cognos
• High (SharePoint Application) user churn, but stable SharePoint Groups and SharePoint Group to Cognos Group mapping

Use an Individual Account (SSO, Challenge/Response)

• Many groups of users with different Cognos access rights and privileges
• Users can belong to multiple Cognos Groups

Start a Free Trial I have a Question…

Service Accounts Simplify Cognos Authentication for SharePoint

Last Updated: 18-Jan-2017

This information still applies as as background information, but IE 11’s “Enterprise Mode”, Windows 10 and the addition of Windows Edge has added to this story.

For more details see TBD

With IE 8, Microsoft introduced compatibility options to allow IE to act as if it were IE7 to allow users to view both fully compliant sites and “compatibility view”ing of web content which required IE 7.

This has been extended up to and including IE 11, with Microsoft giving notice that IE 11 may be the last version to support “compatibility” – or at least “Document Mode”.
This includes ways that web applications, application, web servers and Windows Group Policy can all manipulate IE. Which makes answering the question “how do I fix my mangled web page (or web page in an iframe)” difficult – to say the least.

Here is what we pulled together to understand how all the tools, techniques and components interact.

It starts with understanding: Document Modes on MSDN

Officially, the rules on how to render a web page are evaluated in order by IE:

1. IE Developer Tools settings – manually setting Browser Mode (User agent string in IE11) and Document mode overrides all other settings
2. Web content/document is in an iframe – the rendering/compatibility mode for the page and any contained iframes is set by the page. iframe settings are ignored (e.g. iframe specific X-UA-compatible)
3. X-UA-Compatible meta tag – specified in the web application generated page header, or inserted by the web server or application server can select IE’s ?”Document Mode”
4. “Compatibility View” setting – if X-UA-compatible is not specified, then users local browser “Compatibility View” setting will apply. This is equivalent (for non-standard pages) to X-UA-Compatible “EmulateIE7”.
5. <!DOCTYPE> setting – finally, if none of the above mechanisms are used, the <!DOCTYPE> tag selects rendering of “Standards” (or “Almost Standards”) or “IE 5 Quirks” mode.

However, that’s not the entire story. We discovered that web pages in iframes which otherwise require “IE 5 Quirks” or IE7 mode will render quite differently for different actual versions (vs. emulation) of X-UA-compatible settings for the page containing the iframe (see The unofficial story: Compatibility modes and iframe behavior)

IE Developer Tools

In IE, if you press F12 when viewing a web page, IE will present a set of developer tools either at the bottom of the current window or can be pushed to a separate window.

The IE 8/9/10 version of the Developer Tools window is show below, outlined in red and the key compatibility properties (Browser Mode and Document Mode) outlined in blue.

For E 11, Development Tools interface and capabilities have changed, outlined in red, with the equivalent (User agent string, Document Mode) compatibility properties outlined in blue. Note that IE 11 will tell you what mechanism has set the document mode – e.g. “Via X-UA-compatible meta tag”.

Both Browser Mode (User agent string) and Document Mode can be changed interactively (which also causes the page to re-render) to assist in debugging compatibility issues. As suggested by the rules, these settings override any other mechanism for setting IE compatibility.

Document Mode vs. Browser Mode/User agent string

At first glance, the drop down options for Document Mode vs. Browser Mode/User agent string look essentially identical – so what’s the difference?

This blog provides a clear, simple explanation: IE – Browser Mode vs. Document Mode to which we have added some additional details:

• Document Mode provides the ability to manually select IE Document Mode (e.g. IE 8), which otherwise can be set using the X-UA-compatible meta tag or by the Compatibility View setting.
  Notes:
  • IE11’s Developer Tools Emulation tab will tell you how Document Mode was set, including “Via X-UA-compatible meta tag”  and “Via intranet compatibility settings”
  • The Document Modes are a sub-set of those available via X-UA-compatible
• Browser Mode (IE8/9/10) – User agent string (IE11) sets the information sent to the web server as part of a page request to inform the server as to what the users browser and version is. This does not directly determine how IE renders, but if the web server page uses the “user agent string” to determine what HTML and JavaScript to render, then yes, it will change the HTML, etc. sent to the browser and will impact how the page is rendered – but only indirectly.You can’t set the Browser Mode programmatically – e.g. from the web server or by JavaScript– which, if you think about it, wouldn’t make much sense even if you could. The recommended solution is to parse the User agent string and other properties to adjust the HTML, etc. generated into the HTTP Response.What is true is that IE does its best to hide what actual version of IE is being used, instead doing its best to tell the server based that it is the browser represented by the IE document mode it’s trying to emulate (e.g. IE 11 in IE 9 mode). However, there is enough raw information in the “User agent string” to detect not only the emulation mode/setting, but also the actual IE version.An example of a user agent string from IE 11 is the following:

userAgent =  Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.0; SLCC2; .NET CLR 2.0.50727; .NET4.0C; .NET4.0E; .NET CLR 3.5.30729; .NET CLR 3.0.30729)

Which informs you that it is emulating IE 7.0 (MSIE 1.0), but the fact that it is Trident/7.0 informs you that this is actually IE 11.
And to complicate things further, in “edge” [document] mode for IE11, the user agent string changes to be compatible with FireFox:
userAgent = Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko

For strategies on programmatic detection see the following: Internet Explorer 11 detection on server side

Web content in an iframe

Web content in an iframe (e.g. from a different site, such as embedding Cognos content in an iframe in a SharePoint 2013 web page) is subject to the document mode of the containing page. An X-UA-compatible tag within the header of a web page within an iframe will be ignored.

In reality what this really means is that web content in an iframe is limited to modes within Document Mode the topmost page – e.g. if the topmost page is set at IE=9, then the iframe will be rendered within the capabilities of IE=9 (or IE=9 emulation in, say, IE 11). However, that’s not the whole story…

X-UA-compatible

X-UA-compatible allows the web application or server to programmatically set the Document Mode for a page. It can be done in a META tag in the header or HTTP Response Header – the difference is subtle and is best explained here: How to use X-US-Compatible

One catch is that you can’t set X-UA-compatible in JavaScript on the page itself. X-UA-compatible must be set as early in the header as possible – before any JavaScript can be declared or executed. And it can’t be set/reset after page rendering has started (e.g. after document ready).

Control over the browser/emulation mode is extensive. There are no-less than 12 different rendering modes including IE=IE7 and IE= EmulateIE7.

You can also specify multiple X-UA settings that can apply across some or all IE variations, which the specific browser will intelligently select which one to apply. For example:

<meta http-equiv=”X-UA-Compatible” content=”IE=7,IE=9″ >

This will set Document Mode for IE8 to IE7 and for IE 9 and later to IE=9
Additional details on the behaviour in each mode can be found here: What’s the difference if <meta http-equiv=“X-UA-Compatible” content=“IE=edge”> exists or not?

Compatibility View

Users can select “Compatibility View” via their IE menu “ToolsCompatibility view settings” and can also be deployed by Administrators by Group Policy.

Several options:

• Microsoft provided list of sites
• Automatically enable for all intranet sites
• Specify which (base) URLs to deal with as compatibility sites

Officially Compatibility View is the same as X-UA-Compatible setting IE = EmulateIE7 which is IE = IE7, but can further degrade to IE5 Quirks mode if no valid <!DOCTYPE> is detected.

<!DOCTYPE>

<!DOCTYPE> is the first line in the HTML of a page. It declares the HTML standard used on the page (e.g. HTML 4.1 vs. XMHTML 1.0). An example (from SharePoint 2013) is:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

For IE, <!DOCTYPE> assists in defining whether to use “Standards” mode (e.g. IE 10 “Standards”), or “Almost Standards” or for much older DOCTYPE definitions (or the <!DOCTYPE> is missing) use “IE5 Quirks” mode

X-UA-compatible “EmulateIE<x>” includes using the DOCTYPE to determine emulation mode. For example:

EmulateIE7 means use IE 7 Standards (or Almost Standards) for supported DOCTYPES  otherwise use IE5 Quirks

The following is an in depth discussion of DOCTYPE and X-UA-compatible: Activating Browser Modes with Doctype

The unofficial story: Compatibility modes and iframe behavior

While Microsoft does state that the content of an iframe can’t have its own compatibility mode settings and that the level of compatibility can’t be “higher” than that of the containing page, it doesn’t say what happens if the content of the iframe requires a “lower” level of compatibility.

In embedding an iframe from an application that otherwise requires IE 7 or IE 5 Quirks mode when rendered in a separate window, we discovered that changing the X-UA-compatible setting for the containing page could change the rendering of the iframe contents.
In testing with SharePoint 2013, which requires IE8 or higher (and for which the default master page X-UA-compatible value is IE=IE10), and “older browser” iframe content, we found that setting X-UA-compatible setting of IE=8, IE=9 or in some cases “IE=edge” would allow the iframe content to render correctly – and that how it rendered for a given X-UA-compatible setting could be radically different. That was NOT expected given that those pages default to IE5 Quirks or IE 7 mode when they are not in an iframe. Additional testing against Cognos Connection directly confirmed that most Cognos web components do render correctly with multiple values of X-UA-compatible.

And, as Microsoft warns – the X-UA-compatible (e.g. IE=iE8) behavior (in say, IE 9 or IE 10) was not the same as behavior in the actual browser (e.g. IE 8).

What we also found is that different X-UA-compatible settings were required based on the actual version of IE – not the Microsoft’s “MSIE” value in the User Agent String. Fortunately we found we could parse the User Agent String in various ways to detect the actual browser installed on the user’s machine.

Of course this “side affect” is only useful if you directly control what web content is being embedded in an iframe – not as a general solution.

Understanding Internet Explorer “Compatibility” modes