Hi Folks
Anyone having this issue ?...
Background : upgraded from 11.0.3 to 11.0.4 (single server in place upgrade), rebooted server, cleared browser cache
Issue : when logging into CA from the browser it takes approx 15 seconds to get the logon / splash screen, once the logon screen appears it takes a further 15/20 seconds to logon.
(Previous version would take 1-2 seconds max).
Also things like:
- My Preferences
- Admin - My Content
- Admin - Data sources
- Admin - Configuration
all take excessive amounts of time to appear in the browser (chrome and IE)
Has anyone had similar slow response issues ?.
Cheers
Nick
Have you tried with different browsers (Chrome/Firefox) and differerent IE versions? In earlier C11 versions I saw that especially older IE browsers were a lot slower than Chrome/Firefox or latest IE11 .
In 11.0.4 IE support has changed slightly because IE10 did work with 11.0.3 portal. However, 11.0.4 portal seems to render web pages completely wrong (alignment of UI elements are wrong).
Hi ZenCog
As I mentioned in the post - i've tried both Chrome and IE browsers which were working perfectly with v11.0.3 before the upgrade.
Having spoken to IBM support today - they also identified the same issue when you upgrade over the top of v11.0.3.
I have this morning uninstalled v11.0.4 completely and reinstalled to see if the problem disappears and surprise surprise the issue has gone !.
Yet another example of the in-place upgrade process not working properly !.
Every FP release i've tried causes issues and i've ended up installing each FP from scratch to resolve the issues (see previous posts).
Another poor release with no proper QA !!!.
N
Aaah. Okey. Thanks for sharing that mystery with us. So far I have upgraded couple 11.0.3 environments to 11.0.4 and I have been just lucky to avoid that problem simply because I have indeed installed 11.0.4 in a parallel folder (and merging config files to this new folder). However, I have used the old contentStore database content directly in the new installation. Seems to work. More safe way might be to do it via export-import packages but haven't gone through that effort.
Some IBM documents (but couldn't find links to those docs at this point) say that it is okey to install 11.0.y on top of old 11.0.x folder but I just wanted to keep the old installation until the new one has proven to be functional. In the future I will just stick to that plan.
Hi ZenCog
I agree - installing into separate directories and moving content between versions definitely is my way going forward.
I took IBM at their word when they said (and marketed this release) that you could install over the top of a previous version and things would *just* work.
I've seen plenty of posts previously where people have done this without issue - so let's hope that in subsequent releases they make this feature more robust and do more testing around this.
Cheers
N
Quote from: ZenCog on 20 Sep 2016 10:54:28 AM
Aaah. Okey. Thanks for sharing that mystery with us. So far I have upgraded couple 11.0.3 environments to 11.0.4 and I have been just lucky to avoid that problem simply because I have indeed installed 11.0.4 in a parallel folder (and merging config files to this new folder). However, I have used the old contentStore database content directly in the new installation. Seems to work. More safe way might be to do it via export-import packages but haven't gone through that effort.
Some IBM documents (but couldn't find links to those docs at this point) say that it is okey to install 11.0.y on top of old 11.0.x folder but I just wanted to keep the old installation until the new one has proven to be functional. In the future I will just stick to that plan.
Hello ZenCog,
have you got SSO working with 11.0.4 using IIS?
I did a clean install and having various issues.
Would mind sharing installation of 11.0.4 and also what configuration files to copy from old one to new one
Thanks
Quote from: hardstep on 20 Sep 2016 11:12:55 AM
Hi ZenCog
I agree - installing into separate directories and moving content between versions definitely is my way going forward.
I took IBM at their word when they said (and marketed this release) that you could install over the top of a previous version and things would *just* work.
I've seen plenty of posts previously where people have done this without issue - so let's hope that in subsequent releases they make this feature more robust and do more testing around this.
Cheers
N
Hi Hardstep,
Are you using cognos 11.0.4 with IIS?
Can you please share what content need to be moved from previous versions to new versions?
Any help would be greatly appreciated.
Thanks
Quote from: prince9 on 21 Sep 2016 12:48:44 PM
have you got SSO working with 11.0.4 using IIS? I did a clean install and having various issues.
Would mind sharing installation of 11.0.4 and also what configuration files to copy from old one to new one
No, we are having IIS and SSO login problems in all those upgraded 11.0.4 Cognos portals. Like we know, the sso/iis login configuration changed between C10 and C11. Now it has changed a bit more between 11.0.3 and 11.0.4 versions.
Following page explains what should be done in 11.0.4 version, but SSO doesn't seem to work or some IIS proxy re-write rule is missing in this document.
http://www.ibm.com/support/knowledgecenter/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_sso_actdirserver.html
IBM tech support is looking at this issue and don't know yet if this is just a documentation bug or software bug or environment specific configuration error (for example we have more than one authentication data sources in Cognos configurations so it might have something to do with this problem). Waiting for IBM's reply.
The funny thing is that if you enter http://cognosbox/ibmcognos/sso/cisapi/v1/login URL and then type in http://cognosbox/ibmcognos/bi/ URL, the SSO login works. Almost like the new 11.0.4 IIS/SSO configuration doc is missing some IIS re-write or re-direct rule.
If anyone here has manged to get IIS/SSO login working in C11.0.4 version then please share your experience and did you follow the instructions shown in the web doc linked above or tweaked something else?
If you want to migrate C11.0.3 configuration to C11.0.4 version then you have to export the existing configuration in Cognos Configurator tool, copy the exported XML file as c1104\analytics\configuration\cogstartup.xml file and open the new Configurator. The first time you open the Configurator the cogstartup file will be upgraded to support the new version.
I got the same link as you have and now I got SSO working but having other issues like
Can open report studio but not able to use it (all options disabled)
already created dashboard is saying that it cannot access Data module...
Thanks
Hi,
With my 11.0.4 installation the SSO stopped working. When I enter the url http://cognosserver/cognosfolderalias/ - We get prompted for a windows logon screen where we enter the id and password - after 3 items it crashes the IIS application pool and website returns a 503 Service unavailable. Has anyone else faced this ? This is a 2 server install. IBM support has not been very helpful. BTW This was 11.0.4 installed on top of a working 11.0.3 environment. :(
Prince9. Got SSO working with the new info in the web page linked above (looks like IBM updated and modified the content yeasterday). If someone there is fighting with IIS/SSO then check at least these after following the instructions in the web page:
- /ibmcognos/ folder needs to be APPLICATION folder in IIS, not a virtual directory if /ibmcognos/sso/ application folder is not using the default application pool. And in that case both ibmcognos and sso app folders must use the same application pool.
- /ibmcognos/ folder needs to use "Windows Integrated auth" IIS security option also, not just sso app folder (in C10 it used to be so that cgi-bin app folder or cognosisapi.dll file there had to be WinIntegrated but /ibmcognos/ didn't have to).
>having other issues like Can open report studio but not able to use it (all options disabled)
Don't have that problem here. RStudio seems to be working fine and all properties and options available. At first I did have some weird HTML rendering problems but after clearing local browser cache things started to work OK.
Quote from: rayden0123 on 22 Sep 2016 09:04:31 AM
With my 11.0.4 installation the SSO stopped working. This was 11.0.4 installed on top of a working 11.0.3 environment.
See comments from Hardstep. He installed on top of 11.0.3 and got all sort of weird login problems. After installing 11.0.4 on a new fresh folder problems were gone. I have done handful of 11.0.4 upgrades here and always used a new separate folder, but re-using the old content store database and configuration file (of course after taking backups of originals).
Also. In some of those 11.0.4 servers we have an old C10.2.2 also running there at the same time. Those versions must use different application pools in IIS. At one point I accidentally re-used the old app pool and this caused weird problems when the same app pool had two different versions of cognosisapi.dll file.
Just to add to the conversation thread...when I spoke to IBM support the other day they mentioned there were some SSO issues with 11.0.4.
They didn't mention specifics - but it was clearly causing them a few headaches.
My advice (for what it's worth) - install clean version of 11.0.4 and remove any previous IIS configs !... at least then you can rule out any over the top gremlins !.
Cheers
Nick
Quote from: ZenCog on 22 Sep 2016 09:33:27 AM
See comments from Hardstep. He installed on top of 11.0.3 and got all sort of weird login problems. After installing 11.0.4 on a new fresh folder problems were gone. I have done handful of 11.0.4 upgrades here and always used a new separate folder, but re-using the old content store database and configuration file (of course after taking backups of originals).
Hi - I just did a fresh install and facing a new error after following the steps in the posts above. I get the ERR: 403 - looking for help !!
Quote from: rayden0123 on 22 Sep 2016 12:13:56 PM
I just did a fresh install and facing a new error after following the steps in the posts above. I get the ERR: 403
I have seen the same error if those /ibmcognos/bi/ URL-rewrite rules in IIS config are wrong. Just go through them and make sure that
- If the fresh install and configuration uses the same IIS virtual app folder names then the new ibmcognos/bi folder may remember old re-write rules. Remove /ibmcognos/sso and /ibmcognos folders in IIS configuration and when you re-add them and see old rules in /ibmcognos/bi/ re-write list then delete these rules and just write them again.
- No extra whitespaces, missing chars or other typo errors in rules
- Order of rules must be correct (use the order listed in the below linked web page).
- Check"stop processing the subsequent rules" checkbox option per rule. The first one must be "FALSE" unticked and rest of the rules "TRUE" ticked (if that option is available because redirect action doesn't have this option at all because it will be treated as "TRUE" automatically).
- Both /ibmcognos/ and /ibmcognos/sso/ folders are application folders in IIS and use the same application pool. Both IIS folders must have "Intergrated Windows Authentication" authentication option enabled and anonymous disabled.
- /ibmcognos/sso/ application folder uses cisapi request name in a handler mapping configuration even when the actual file reference is still cognosisapi.dll.
The C11.0.4 SSO/IIS configuration steps: http://www.ibm.com/support/knowledgecenter/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_sso_actdirserver.html
And make sure that IIS service and application pool identity has a permission to read those webcontent and cgi-bin Cognos folders. As a temporary test you could try to change the application pool identity in IIS config to use your own AD domain account. If it works this way then check file permission (normally IIS app pool identities should have read access).
There is another thread going on regarding SSO issues here :
https://community.watsonanalytics.com/discussions/questions/24040/cognos-analytics-1104-sso-will-not-work.html
With references to the detail that ZenCog mentions above ! (nice work ZenCog !).
Thnx Zencog.
@Zencog :got the SSO working now but having a strange issue like not able to see contents inside folders like datamodules/reports or folder properties.
When I hit dispatcher on 9300/bi and login then I can see everything..
ZenCognos - Believe me i have tried all these steps multiple times - including uninstalling all versions on the server and re-installing and re-configuring. But am still being prompted for a windows security screen and does not take my ad / password.
Quote from: prince9 on 26 Sep 2016 03:51:30 AM
@Zencog :got the SSO working now but having a strange issue like not able to see contents inside folders like datamodules/reports or folder properties.
When I hit dispatcher on 9300/bi and login then I can see everything..
Worked with IBM - they changed the URI For Dispatcher to http://Servername:9305/bi/v1 instead of the original 11.0.3 which was http://Servername:9305/p2pd/servlet/dispatch/ext and the SSO worked. But I have the same problem with SSO working. Can't access packages / create new reports or modify anything. Cant say what the problem is. Everything works fine if we use the Gateway URI which is http://servername:9305/bi/v1/disp
Quote from: rayden0123 on 27 Sep 2016 03:05:47 PM
Worked with IBM - they changed the URI For Dispatcher to http://Servername:9305/bi/v1 instead of the original 11.0.3 which was http://Servername:9305/p2pd/servlet/dispatch/ext and the SSO worked. But I have the same problem with SSO working. Can't access packages / create new reports or modify anything. Cant say what the problem is. Everything works fine if we use the Gateway URI which is http://servername:9305/bi/v1/disp
Hi,
That Cognos11 Configuration issue is something I forgot to mention earlier. IF you copy the old C10 exported cogstartup.xml configuration file to C11 environment then gateway and dispatcher URIs may be in the old C10 format. I used "reset to default" in C11 configurator to set gatewayURI and external dispatcher URI values to C11 format and set correct hostname and port numbers.
At the moment I used following syntax in URI values in C11 configuration (couple of them use different syntax than C10, so be careful if you import the old confgi file):
Gateway Settings Gateway URI=http://mycognosboxname:9300/bi/v1/disp
Gateway Settings Dispatcher URIs for gateway=http://mycognosboxname:9300/bi/v1
Dispatcher Settings External Dispatcher URI=http://mycognosboxname:9300/p2pd/servlet/dispatch
Dispatcher Settings Internal Dispatcher URI=http://mycognosboxname:9300/p2pd/servlet/dispatch
Other URI Settings Dispatcher URI for external applications=http://mycognosboxname:9300/b1/vi/disp
Other URI Settings Content Manager URIs=http://mycognosboxname:9300/p2pd/servlet
And now to the "non-working Dashboard/DataModeling" components and random blank properties screens. I have seen that problem also and it turn out to be missing MIME types in IIS. Please make sure that you have added following MIME type in IIS either in top iis server level or at least in /ibmcognos/ virtual directory level:
.json=application/json
.template=text/html
.woff=application/font-woff
.woff2=application/font-woff2
.svg=image/svg+xml
If you don't have template and json MIME types then the behaviour is exactly what you described (ie. C11 portal seems to be working just fine except the new dashboard fails to retrieve any data and properties windows are blank).
The IBM "11.0.4 SSO/IIS" web page lists woff=application/x-font-woff mime type but it is an old unofficial mime type defined by W3C consortium and woff2 is listed in the IBM's web page as font/woff2. However, if you do Google search then most of other places document them as application/font-woff and font-woff2 mime types. See https://en.wikipedia.org/wiki/Web_Open_Font_Format web page (this page mentions that font/woff might work in some browsers, but it recommends to use application/font-woff format).
Quote from: ZenCog on 28 Sep 2016 01:51:37 AM
Hi,
That Cognos11 Configuration issue is something I forgot to mention earlier. IF you copy the old C10 exported cogstartup.xml configuration file to C11 environment then gateway and dispatcher URIs may be in the old C10 format. I used "reset to default" in C11 configurator to set gatewayURI and external dispatcher URI values to C11 format and set correct hostname and port numbers.
At the moment I used following syntax in URI values in C11 configuration (couple of them use different syntax than C10, so be careful if you import the old confgi file):
Gateway Settings Gateway URI=http://mycognosboxname:9300/bi/v1/disp
Gateway Settings Dispatcher URIs for gateway=http://mycognosboxname:9300/bi/v1
Dispatcher Settings External Dispatcher URI=http://mycognosboxname:9300/p2pd/servlet/dispatch
Dispatcher Settings Internal Dispatcher URI=http://mycognosboxname:9300/p2pd/servlet/dispatch
Other URI Settings Dispatcher URI for external applications=http://mycognosboxname:9300/b1/vi/disp
Other URI Settings Content Manager URIs=http://mycognosboxname:9300/p2pd/servlet
And now to the "non-working Dashboard/DataModeling" components and random blank properties screens. I have seen that problem also and it turn out to be missing MIME types in IIS. Please make sure that you have added following MIME type in IIS either in top iis server level or at least in /ibmcognos/ virtual directory level:
.json=application/json
.template=text/html
.woff=application/font-woff
.woff2=application/font-woff2
.svg=image/svg+xml
If you don't have template and json MIME types then the behaviour is exactly what you described (ie. C11 portal seems to be working just fine except the new dashboard fails to retrieve any data and properties windows are blank).
The IBM "11.0.4 SSO/IIS" web page lists woff=application/x-font-woff mime type but it is an old unofficial mime type defined by W3C consortium and woff2 is listed in the IBM's web page as font/woff2. However, if you do Google search then most of other places document them as application/font-woff and font-woff2 mime types. See https://en.wikipedia.org/wiki/Web_Open_Font_Format web page (this page mentions that font/woff might work in some browsers, but it recommends to use application/font-woff format).
Thanks @ZenCog. I have everything setup the way you have described above. But for some reason - my Package/ Report Permissions are not flowing through when I am using SSO. That is the reason - I cant use the packages to create a new report and get errors related to missing packages when i am opening an existing report. On the other hand - if I login to the dispatcher directly - all my security permissions are being shown and everything seems to be working.
Any suggestions why this is happening ? Thanks much for everyone's assistance.
@ZenCog - sorry i meant gateway directly (http://servername:9305/bi/v1/disp)
Quote from: rayden0123 on 28 Sep 2016 09:01:52 AM
Thanks @ZenCog. I have everything setup the way you have described above. But for some reason - my Package/ Report Permissions are not flowing through when I am using SSO
Really strange. Shouldn't be the case of wrong namespaceID in the new configuration because in that case things wouldn't work even via dispatcher URL.
One note about my existing gateway URI settings. I think I should use http://mycognosboxname/ibmcognos/bi/v1/disp Gateway URI instead of "Gateway Settings Gateway URI=http://mycognosboxname:9300/bi/v1/disp" value as I mentioned above. Both values work when using browser to consume Cognos content but externally referenced Cognos links would use this GatewaySettings-GatewayURI value, so it better be SSO compatible URL instead of direct dispatcher port.
Back to your problem. Very strange. One more thing you might wanna try is to tweak IIS request filtering settings. IIS has a security feature where IIS can reject URL request if the url or queryString parameter list is too long. This used to cause problems already in C10 administration screens if the server had lots of dynamic cubes (dynamiccube admin screen somehow posted the whole list of cube properties back to the web server).
Anyway. Solution to this problem was to increase this IIS request filtering values:
- IIS admin manager
- Choose "Default Web Site"
- Choose "Request Filtering" icon
- Click "Edit Feature Settings..." link on the right side of the window
- Increase "Maximum URL length (bytes)" and "Maximum query string (bytes)" values. I have set both to 8192 bytes.
Also, check IIS caching option. Maybe your browser is caching something it is not supposed to do.
- IIS admin manager
- Choose "HTTP Response Headers"
- Click "Set common headers" on the right side
- Make sure that "HTTP Keep alive" is selected.
- I have also set "Expire web content after 3 days" option to increase performance (ie client browser caches static URL content for X days before re-loading it from a server).
Anyway. Try to unselect this "expire web content" option AND then clear browser cache. If you use IE browser then remember to UNTICK "preserve favourites web site data" option in delete dialogbox. Otherwise IE won't clear local cache if you have Cognos web address in favourites links.
And do you get the same behaviour both in IE and Chrome browsers? If other browser works then it would tell us that problem is probably in local browser settings and not in server side. If both browsers have the same problem then there is still something wrong in the server side.
I was wondering if people could post what the server configuration is for SSO that they have working.
I'm trying to get SSO working on Windows Server 2012 / IIS 8.5 but have had no luck with the suggestions in this thread. We're trying both the REMOTE_USER / NTLM approach and Kerberos Authentication.
Quote from: Jeff H. on 28 Sep 2016 12:16:19 PM
I was wondering if people could post what the server configuration is for SSO that they have working.
COGNOS 11.0.4 Configurator Options for SSO/IIS authentication.
ENVIRONMENT:
GATEWAY SETTINGS:
Gateway URI=http://caserver/ibmcognos/bi/v1/disp
Gateway namespace=
ContentManager sAMAccountName=
Allow namespace override=false
Dispatcher URIs for the gateway=http://caserver:9300/bi/v1
DISPATCHER SETTINGS:
External Dispatcher URI=http://caserver:9300/p2pd/servlet/dispatch
Internal Dispatcher URI=http://caserver:9300/p2pd/servlet/dispatch
OTHER URI SETTINGS:
Dispatcher URI for external applications=http://caserver:9300/bi/v1/disp
Content Manager URIs=http://caserver:9300/p2pd/servlet
SECURITY:
AUTHENTICATION:
Allow session information to be shared=false
Restrict access to members of builtin namespace=false
Automatically renew trusted crendential=Primary namespace only
Advanced properties defaultNamespace=MYAD (this is required if env has more than one authentication namespaces and you want to authenticate users by default against a certain namespace. Although, it doesn't hurt to have this option even if you have only one namespace)
COGNOS:
Allow anonymous access=false
MYAD (ie. ActiveDirectory type of namespace):
Namespace ID=MYAD (this value should match the advancedProperties.defaultNamespace option above)
Host and Port=MYAD.FI:389 (ie. binds to domain name so Cognos queries DNS nameserver for active AD controller names)
Advanced properties singleSignonOption=IdentityMapping (ie. use NTLM instead of Kerberos with browsers and IIS. Leaving this blank works IF you register kerberos service name in a domain)
Everything else shouldn't have anything to do with SSO login.
Internet Information Services (IIS) settings are listed in the IBM web page linked above. The key points are
- Create a new applicationPool, for example "CA11Pool"
- Add "cgi-bin/cognosisapi.dll" in "allowed ISAPI extensions" list and select "allow for execution" option in server level
- Create "/ibmcognos" folder as an APPLICATION, not as virtual directory. Set it to use "CA11Pool" you created above
- Create "/ibmcognos/sso" folder as an APPLICATION and set it to use the same "CA11Pool" application pool
- Disable anonymousAccess option in "/ibmcognos" folder and enable "Integrated Windows Authentication" option.
- Sometimes I have seen environments where this "Integrated Windows Auth" option has required an additional step by moving NTLM provider in the top of the provider list. But usually it is not necessary.
- Add "cisapi" handler in /ibmcognos/sso folder and link it to cgi-bin/cognosisapi.dll isapi handler file
- Remember to choose "execute" from "Request Restrictions/Access" tab page of this handler properties
- Remember to select "execute" option from "Edit feature Permissions..." screen of HandlerMappings in /ibmcognos/sso folder
- Make sure cisapi handler is listed as "Enabled" handler in the "Handler mappings" list. If not then check the last three steps.
- Set re-write rules in "/ibmcognos/bi" folder. Follow the steps listed in IBM's web page (single typo error here and SSO doesn't work)
- Remember that the first rule does NOT have option for "stop processing for subsequent rules". Other rules does have this option enabled.
- The order of these rules is important
I believe these tweaks are the primary options having something to do with SSO/IIS login. In the client browser side there are few things you might wanna check
- Make sure http://caserver is listed in IE/Options/Security/LocalIntranetZones host list (in some environments IE browser doesn't send SSO login information to anywhere else but to intranet sites). Check zone custom configuration options and at the end of the list there should be something like "Automatic logon only in intranet sites" option enabled.
- Make sure compatibleView option is NOT set for CA11 web site address (in browser or via domain policy)
- IE EnterpriseMode should not be enabled for CASERVER web address. If it is then ask your domain admins to remove caserver address from a domain "IE EnterpriseMode" policy list.
Also try installing CA11.0.4 into a fresh targer folder instead of overwriting CA11.0.x folder. Some people here have reported strange bugs if CA11.0.4 was installed on top of old CA installation folder. You can use the existing contentStore database so using fresh folder is not too much extra work.
If SSO still doesn't work after checking these options then it must be some very strange corner case. If/When you solve it then please share the solution here.
Thanks, ZenCog.
Followed the instructions refered to from the community.watsonanalytics article you mentioned (http://www.ibm.com/support/knowledgecenter/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_sso_actdirserver.html#t_sso_actdirserver) and am now verifying that we caught the rest of your instructions. What is missing in both places is the actual URL to use to take advantage of SSO. In Cognos 11.0.2 this was http://servername.domain.com/alias/cgi-bin/cognosIsapi.dll?b_action=xts.run&m=portal/main.xts&m_redirect=/alias/bi/. If something else was used (like http://servername.domain.com/alias) I got either a 404 error or a logon screen appeared, so the exact URL was important.
In Cognos 11.0.4, I still get a logon screen. What URL should the user use to get into Cognos Analytics 11.0.4?
Also, I'm not an IIS expert, so I'm having trouble finding some of the settings you mention. For example, your second bullet under IIS uses the terms "allowed ISAPI extensions" and "allow for execution". I don't see those anywhere on the screen when creating an application pool. Where do I find these settings?
Quote from: dougp on 03 Oct 2016 01:21:05 PM
What is missing in both places is the actual URL to use to take advantage of SSO. In Cognos 11.0.4, I still get a logon screen. What URL should the user use to get into Cognos Analytics 11.0.4?
Also, I'm not an IIS expert, so I'm having trouble finding some of the settings you mention. For example, your second bullet under IIS uses the terms "allowed ISAPI extensions" and "allow for execution". I don't see those anywhere on the screen when creating an application pool. Where do I find these settings?
IIS/SSO works using the alias root URL directly, for example http://my-caserver/ibmcognos/. Those IIS proxy re-write rules and cisapi handler name makes this work without explicit references to the old C10 style cgi-bin/cognosisapi.dll URL name. If you use /ibmcognos/bi URL then make sure to add trailing slash because I have seen cases where /ibmcognos/bi doesn't work but /ibmcognos/bi/ does work. Anyway, after setting up all required re-write rules then /ibmcognos/ URL should work.
There are two places in IIS admin screens where you have to enable cognosisapi.dll handler.
- First one: Server name node (ie. the level above your "Default Web site" item) and "ISAPI and CGI restrictions" icon. Here you should have a link to C11.0.4 cognosisapi.dll file and listed as "allow extension path to execute" (ALLOW).
- Second one: /ibmcognos/sso/ application item and "Handler Mappings" icon and "Add module mapping" screen there.
These last two config steps are pretty much the same you did with C10 cognosisapi.dll handler also. Just make sure that in "Handler Mappings" screen you use "cisapi" value in Request Path option because proxy re-write rules use that path name and not the original cognosisapi.dll path name. Of course executable path value still refers the the c11 cgi-bin/cognosisapi.dll file path.
Also, re-check that you have disabled anonymous authentication access and enabled WindowsIntegratedAuth from both /ibmcognos and /ibmcognos/sso/ application folders and are using the same application pool (well, sub folders should inherit it from parent IIS folder unless you have overridden something).
My problem has been solved. The problem was with the first URL Rewrite rule. I had not included the parentheses.
The documentation could delineate the value better. For example, in documentation I produce anything that I would expect the user to cut and paste I put in a shaded box. That eliminates the age-old question, "Do I include the quotes, or just what's between them?"
I finally managed to get Integrated Authentication (NTLM) using the cognosisapi.dll for 11.0.4.
The documentation on the URL rewrite rules is correct. I had these issues:
Windows 2012 R2 – there are 2 features in IIS which need to be configured at the server node. Select "feature delegation" and set read/write to "Authentication – Windows" and "Module". These are set to read/write in Windows 2008 by default but in 2012 R2 they have to be explicitly set to read/write.
IIS Application pool – leave "Enable 32 bit applications" set to false. If it's enabled the cognosisapi.dll will not work.
ARR 3.0 – I had to manually download these and I had only 2 of the 4 components installed. I was seeing error 441 which said it was attempting to use ARR components when it was failing. This prompted me to uninstall, reboot and reinstall.
Cheers and thanks everyone for the help,
Jeff
Has anybody got SSO working in 11.0.6?
I'm not seeing "cognosisapi.dll" anywhere in my installation, despite having the optional gateway installed.