Is it necessary to have a separate Microsoft IIS server for every IBM TRIRIGA application server?
It is not a requirement to have a separate Microsoft IIS server for every IBM TRIRIGA application server. Your IT team should determine if this is something that they want or need to do.
[Admin: To see other related posts, use the IIS tag.]
Several TRIRIGA users are receiving HTTP 413 errors (“Entity too large” from IIS) under Internet Explorer 10 (IE10). The problem may be caused by a very large page that is exceeding the size of the browser’s cache…
In an effort to fix this issue, the uploadReadAheadSize (IIS) was increased from the default of 48K up to 128K, and the responseBufferLimit (webconfig) from the default of 4M to 16M. We also attempted to clear the browser cache. None of these changes resolved the problem. Finally, we identified a very large page that was exceeding the size of the browser’s cache limitation.
To resolve the problem, increase the size of the browser cache. For Internet Explorer 10, navigate to Settings > Internet Options, select Settings in the “Browsing History” section, then select the “Caches and Databases” tab. The default value might be 10 MB. After increasing it to 25 MB, there were no further problems.
[Admin: To see other related posts, use the Internet Explorer tag or Browser tag.]
We are encountering an odd issue with TRIRIGA SSO and Active Directory with Personal Identity Verification (PIV) cards for authentication. The issue occurs after a session timeout, when a Windows Authentication dialog box would prompt a user to enter either their pin code or their Active Directory login, in which the Windows security does not accept their credentials, even though the right pin code or username/password is used…
Upon clicking on the Cancel option in the Windows Authentication dialog box, a second window with a “401 – Unauthorized Access” error is displayed to the user with a link that allows the user to regain access to the REMS application. We do not see any significant errors regarding authentication on the TRIRIGA side. At this point, I am not sure if this is a IIS, Active Directory, or a TRIRIGA configuration issue, but any suggestions would be great…
The issue is that the user’s old session on the app server is invalid, and the app is passing a 401 header back through IIS, and onto the browser. The solution is to tell the app server not to send the 401 header. In TRIRIGAWEB.properties, set:
This change in functionality was an enhancement made in TRIRIGA 3.5.2.x The change is not in 22.214.171.124… So, the options for you right now are to test out 3.5.2. In 3.5.1 and below, enable the session expiration warning setting and extend the session timeout in the web server to something like 8 hours (normal working day):
Does anyone know how to configure IIS and SSO on TRIRIGA Platform 3.4.2 with WebSphere Liberty Profile (embedded)? We have just upgraded our TRIRIGA Platform to 3.4.2 and run into difficulty in configuring IIS. Our application and process servers are on Windows Server 2012 and our database is on SQL Server 2012.
[Admin: This post is related to the 07.22.15 post about an issue with IIS SSO, WAS Liberty, and TRIRIGA 3.4.2.]
WebSphere Liberty is a lightweight version of traditional WebSphere. It does not have nearly as much overhead, nor does it require a dedicated team to install, run, and support, like its bigger brother. The beauty of Liberty is that comes with TRIRIGA and is very easy to install! Not to mention it does not take long to install compared to traditional WebSphere. The TRIRIGA installer includes Liberty so when you run the TRIRIGA install, you have the option to install Liberty without any additional files. When you select Liberty in TRIRIGA, it makes the process seamless. There is no console to worry about. Liberty has all that TRIRIGA needs to run. After the install is complete, all you do is start up a batch file and you are up and running.
I bet you might be wondering: I need to use traditional WebSphere because we are using SSO and I may not be able to use Liberty. Not so! You are able to configure TRIRIGA 3.4.2 and greater on Liberty with Microsoft IIS and Active Directory. For details on that, let me direct you to this wiki page: TRIRIGA on WebSphere Liberty — SSO with IIS and AD.
Can Liberty be set up as a service like traditional WebSphere? This is a bit more complicated and I encourage you to check out a colleague’s blog entry on this subject: TRIRIGA and the WAS Liberty Profile that does not want to be a service.
In the end, you need to decide what will best suit your needs. In some rare cases, traditional WebSphere may be the way to go, for example, if your company has a dedicated WebSphere team. But in most cases, Liberty will work best. It’s good to have options and know what the benefits are. To help you understand the benefits, you may want to look at this wiki page: Choose Liberty over Traditional WAS.
[Admin: This post is related to the 04.28.16 post about running Liberty profile as a Windows service, and the 03.15.16 post about the best practice for choosing an application server.]
There is a path “/tririga/remote” which I understand is for BIRT report development. What are the ways to stop access to this path for the production environment? We are using IIS as the web server. I have tried using the Rewrite rule for IIS to block this, but the path is still accessible. Any suggestion is appreciated.
With IIS, it is not possible to use a rewrite or blocking rule because of the way IIS is structured. It is possible with IHS or Apache. See this page for some samples with Apache/IHS: Forcing the WAS plugin to decline/handle a request.
The IBM TRIRIGA single sign-on (SSO) troubleshooting guide is found on the Troubleshooting SSO wiki page, under the SSO parent wiki page, in our IBM TRIRIGA developerWorks wiki.
Troubleshooting single sign-on
The single most important resource to use from the TRIRIGA Platform perspective is the requestTest.jsp page. This is a page internal to the TRIRIGA platform that will display the different areas of the HTTP header, and allow you to debug and set the third-party configuration correctly… Here are some issues that are known to occur with single sign-on, for example, if it is not configured properly.
- Invalid username or password error…
- Map labels are shown only in English…
- HTTP requests are no longer forwarded to TRIRIGA…
- Adding SSL/HTTPS into the mix…
- CA SiteMinder…
- CAD Integrator error reporting with IIS 7…
[Admin: This post is related to the 05.29.15 post about the latest information on TRIRIGA single sign-on (SSO), and the 04.06.16 post about performance issues seen with SSO-enabled environments. To see other related posts, use the SSO tag.]