Cognos Analytic 11.1.6
Microsoft Windows 2016 server

When you browse to http://caservername/ibmcognos you get an error;

Service Unavailable
HTTP Error 503. The service is unavailable.

This is in most cases is this that the application pool is stopped.

Go to IIS manager and start the ICApool.


More Information:

Cognos BI 10.2.2 fix pack 10
C8BISRVR_UPDATE_name=IBM Cognos Business Intelligence Server Update
Microsoft Windows 2012 R2

When you run a report as schedule, the formatting for HTML is lost. If you run the report intermediate it works fine.

Above the scheduled report who is missing formatting

Above the correct report layout, as it looks when you run it intermediate.

Inside Cognos Connection can you create a “job” to schedule the run a report at a defined time.

Change to use cognosisapi, as the default IIS gateway.

On the IBM Cognos 10 Gateway server,

  1. Open \webcontent\default.htm in a notepad. For example, D:\cognos\c10\webcontent\default.htm.
  2. Find the line that reads

    and change cognos.cgi to cognosisapi.dll.


This will make http://<webserver>/<alias> work like http://<webserver>/<alias>/isapi, redirecting to the ISAPI Gateway after showing a splash screen.

Possible the schedule report is saved in the content store database, but when you try to look at it is not showing the correct formatting, because the cognos.cgi process does not get all the data.

More information:

Cognos Analytics 11.0.12
Microsoft Windows 2016 server

The users can not login with SSO, they have to enter name and password at the IBMCOGNOS website.
Only a few Cognos CA11 gateway servers are affected.

Suggested solution:
Go into the Cognos Configuration on gateway servers and click save.
Does it help?

Recommend is to on all Cognos Configuration installation change the “common symmetric key lifetime in days” from 365 to a higher value like 1825 (5 years).

Inside Cognos Configuration on the CA11 servers
Go to Local Configuration -> Security -> Cryptography
Modify the value for: Common symmetric key lifetime in days
Also go to Local Configuration -> Security -> Cryptography -> Cognos
Modify the value for: Certificate lifetime in days
Save the configuration and start the services.
You must start the Content Manager first, then the gateway servers last.

The issue can also be caused by changes to IIS setup for the SSO part.

More Information:
By default, the cryptographic keys are valid for 365 days.

This value is configured inside Cognos Configuration
Specifically, browse to “Local Configuration -> Security -> Cryptography” and modify the value for: Common symmetric key lifetime in days

Each time you open Cognos configuration and click the save button, it resets the clock on your 365 days. Therefore, if you installed the software and didn’t save the configuration for 365 days, they would expire and you’d need to manually regenerate them.

You must restart the services every so often to ensure the new keys are actually being used.

If you think you won’t be opening and saving your configuration at any point in the next year or two, you can change the expiration date to 8 years and re-encrypt everything.

If you miss above, you will get in a years time this error;
“The Cognos gateway is unable to connect to the Cognos BI server. The server may be unavailable, or the gateway may not be correctly configured”

Cognos Analytics 11.0.12
Microsoft Windows 2016 server

How limit the login to Cognos Connection to only to groups in the LDAP (active directory)?

Use the LDAP connector in Cognos Configuration, and limit the users to be able to login only if they belong to two CN.
The “User Lookup” is used when you do not use SSO, and you let the BI (CA11) prompt the user for the user name and password. Change this to include the groups that the person must be part of to be able to login. Below a example how it can be;

(&(|(legacyuid=${userID})(uid=${userID}))(status=ACTIVE)(|(memberof=cn=Cognos_TM1_Contributor,cn=Cognos Groups,cn=UserGroups,ou=Global,,cn=Cognos Groups,cn=UserGroups,ou=Global,

“External identity mapping” is only used when you use SSO from IIS, to login to the BI server (CA11). You should change this to cover the same groups as the other one to make it act the same if it is using SSO or not.

(&(|(legacyuid=${replace(${environment(“REMOTE_USER”)},”CompanyA\\”, “”)})(uid=${replace(${environment(“REMOTE_USER”)},”CompanyA\\”, “”)}))(status=ACTIVE)(|((memberof=cn=Cognos_TM1_Contributor,cn=Cognos Groups,cn=UserGroups,ou=Global,,cn=Cognos Groups,cn=UserGroups,ou=Global,

In above lines, the user that is part of group Cognos_TM1_Contributor or Cognos_TM1_Modeler in LDAP, can login to Cognos. Good if you have a CA11 server setup, that only authenticate users that should use TM1(Planning Analytics 2.x).

Check that the user is active in LDAP

Compare the userid with the LDAP field Legacyuid

You have to change cn= and ou= values to match your LDAP setup.

Base Distinguished Name, should be the root of the LDAP directory.

How setup LDAP  (from the web)
In every location where you installed Content Manager, open IBM Cognos Configuration.
In the Explorer window, under Security, right-click Authentication, and then click New resource > Namespace.

In the Name box, type a name for your authentication namespace. LDAP
In the Type list, click the appropriate namespace and then click OK.

The new authentication provider resource appears in the Explorer window, under the Authentication component.
In the Properties window, for the Namespace ID property, specify a unique identifier for the namespace. Should be same as namespace name.
Specify the values for all other required properties to ensure that IBM Cognos components can locate and use your existing authentication provider.
If you want the LDAP authentication provider to bind to the directory server by using a specific Bind user DN and password when you perform searches, then specify these values.

If no values are specified, the LDAP authentication provider binds as anonymous.

If external identity mapping is enabled, Bind user DN and password are used for all LDAP access. If external identity mapping is not enabled, Bind user DN and password are used only when a search filter is specified for the User lookup property. In that case, when the user DN is established, subsequent requests to the LDAP server are run under the authentication context of the user.
If you do not use external identity mapping, use bind credentials for searching the LDAP directory server by doing the following step:
Ensure that Use external identity is set to False.
Set Use bind credentials for search to True.
Specify the user ID and password for Bind user DN and password.

If you do not specify a user ID and password, and anonymous access is enabled, the search is done by using anonymous.
Check the mapping settings for the required objects and attributes.

Depending on the LDAP configuration, you may have to change some default values to ensure successful communication between IBM Cognos components and the LDAP server.

LDAP attributes that are mapped to the Name property in Folder mappings, Group mappings, and Account mappings must be accessible to all authenticated users. In addition, the Name property must not be blank.
From the File menu, click Save.
Test the connection to a new namespace. In the Explorer window, under Authentication, right-click the new authentication resource and click Test.

You are prompted to enter credentials for a user in the namespace to complete the test.

Depending on how your namespace is configured, you can enter either a valid user ID and password for a user in the namespace or the bind user DN and password.

More information:

To bind a user to the LDAP server, the LDAP authentication provider must construct the distinguished name (DN). If the Use external identity property is set to True, it uses the External identity mapping property to try to resolve the user’s DN. If it cannot find the environment variable or the DN in the LDAP server, it attempts to use the User lookup property to construct the DN.

Cognos Analytics 11.0.12
Microsoft Windows 2012 Server
TM1 10.2.2

The IBM Cognos Windows service look like it is started in Windows, but when you try to login you get a message that the page can not be shown. When starting Cognos from Cognos configuration you get message CFG-ERR-0106 … did not receive response from the IBM Cognos service in the time allotted. You can not surf to http://servername:9300/p2pd/servlet
The firewall is not blocking the connection.

Possible solution:
A other software was installed on the Cognos BI server, that uses JAVA and have set JAVA_HOME, JDK_HOME and JRE_HOME as windows variables. You can see this by enter SET at a CMD prompt on the server. This have given that Cognos have used the wrong java version.

Adjust JAVA_HOME to point to the Cognos java folder.

More information:

Cognos BI 10.2.2 (or Cognos Analytics 11.0.x)
Microsoft Windows 2008 Server

You have not access to the Cognos Connection. The IBM Cognos service is running, what it looks like in Windows Services. The cogserver.log is empty since last restart.

Error message:
IBM Cognos gateway can not connect to IBM Cognos BI server.

The root cause, a corruption in the \wlp\usr\servers\cognosserver\workarea for WebSphere Liberty Profile (WLP)
Stop the IBM Cognos Windows service.
Backup the “workarea” folder.
Delete the “workarea” folder at  C:\Program Files\ibm\cognos\analytics\wlp\usr\servers\cognosserver\workarea
Start IBM Cognos service again.

More information:

Cognos BI 10.2.2 fix pack 7
Microsoft Windows 2012 R2 Server

When user in IE surf to Cognos Connection to login they get a AAA-SYS-0001 error.

Error Message:
AAA-SYS-0001 : An internal error occurred.
java.lang.RuntimeException: A visa already exists for this A visa already exists for this namespace.

Suggested Solution:
Inside Internet Explorer, clear the cache and try again.
Press CTRL+SHIFT+DELETE to bring up the “delete browsing history” dialog.
Press Delete.
Restart Internet Explorer and try again.

Cognos BI 10.2.2 fix pack 7
Microsoft Windows 2012 R2 Server

Slow or no login at all to a new namespace in Cognos Connection. The user surf to http://servername/cognos8 and then waits.
The other namespace setup in Cognos BI works fine.

Instead of set the domain name in Cognos Configuration Namespace Host and port, try with the IP to the closest Microsoft Windows Domain Controller in that domain. Change to if your Domain Controller uses that IP address.

You can test a change in namespace host without saving Cognos Configuration, if you right click the namespace name (under authentication in left panel) and select test, Cognos will do a authentication test to that DC on the lower IP layer and not use the Cognos dispatcher or Cognos Gateway.
When the dialog comes up for username and password, enter the user name as DOMAIN\username.
The details will show that Cognos first checks that the user exist, and there after ask for a list of all AD groups that user belongs to.
If this test take long time, the login for the Cognos user at the Cognos Gateway (iis) will take at least the same time or more.

Close Cognos Configuration without save, and your test values is gone, and your are back to the previous setup in Cognos.

The result from a test in Cognos Configuration;
User account properties:
defaultName: roger
userName: roger
givenName: roger

Group membership:
Domain Users

Tenant ID:
No associated tenant ID.

Tenant bounding set:
No associated tenant bounding set.

To see if you have network contact with your DC, start a PowerShell prompt on your Content Manager server.
Enter this command: tnc  -computername  -port  389

The result should be like this:
ComputerName : domaincontrollerservername
RemoteAddress :
RemotePort : 389
InterfaceAlias : Ethernet0
SourceAddress :
PingSucceeded : True
PingReplyDetails (RTT) : 4 ms
TcpTestSucceeded : True

If you get a PingSucceeded : False
then you should ask your NETWORK team to check routers and firewalls and ACL tables between the networks.

You can download a network monitor to get more information on what goes on;
Network Monitor

Active Directory Explorer (AD Explorer)

Cognos Content Manager will bind to the DC schema to obtain the list of all “known” DC’s based on the AD Structure.

More information:
UDP Port 88 for Kerberos authentication
UDP and TCP Port 135 for domain controllers-to-domain controller and client to domain controller operations.
TCP Port 139 and UDP 138 for File Replication Service between domain controllers.
UDP Port 389 for LDAP to handle normal queries from client computers to the domain controllers.
TCP and UDP Port 445 for File Replication Service
TCP and UDP Port 464 for Kerberos Password Change
TCP Port 3268 and 3269 for Global Catalog from client to domain controller.
TCP and UDP Port 53 for DNS from client to domain controller and domain controller to domain controller.

Cognos BI 10.2.2
Microsoft Windows 2012 R2 Server
In a Active Directory Domain and Forrest, when we try to add AD groups to the internal Cognos groups in Cognos Connection – Administration – Security, we can not see all groups.
AD Domain Local Groups can only be seen if they are in the same sub-domain as the Cognos Content Manager server. If the Cognos CM server is in a different domain than the DLGroup, it is not visible.

You should create a Cognos security group for your function, then to that Cognos group add AD groups from the different namespace you have created to allow users of different forest have access to the Cognos solution.

When you configure an authentication namespace for IBM® Cognos®, users from only one domain can log in. By using the Advanced properties for Active Directory Server, users from related (parent-child) domains and unrelated domain trees within the same forest can also log in. There is no cross-forest support; there must be a namespace for each forest.
If you set a parameter named chaseReferrals to true, users in the original authenticated domain and all child domains of the domain tree can log in to IBM Cognos. Users from a parent domain of the original authenticated domain or in a different domain tree cannot log in.
If you set a parameter named MultiDomainTrees to true, users in all domain trees in the forest can log in to IBM Cognos.

If you specify Binding Credentials (i.e. if you fill in this section), then:
• (in some environments) it can lead to performance problems. This is because it causes Cognos to ‘unbind’ its original user and re-bind as the ‘specified’ user
• You must ensure that the password (of the user that you choose) does not change/expire

=> Therefore, only fill in the ‘Binding credentials’ section if your “test” (see later) fails. If authentication fails, specify a Windows user ID and password for the Binding credentials property.
• Use the credentials of a Windows user who has at least ‘search’ and ‘read’ privileges for that server.
• This should be a domain user who can ‘see’ the folders inside the AD where the users are located.

In order to setup SSO in a multi-domain Active Directory environment, follow these steps:

1. Launch “Cognos Configuration”
2, Create a new namespace
3. Make sure that this is set to “Active Directory” (not LDAP)
4. Use the root domain as the hostname
5. Locate “Advanced properties” and click edit/modify button
6. Enable either ‘ChaseReferrals’ or ‘MultiDomainTrees’.


  • ChaseReferrals – This will allow users from ‘child’ domains (i.e. domains below the domain that your namespace is connected to) to logon
    • This is often the best choice (for performance reasons).
  • MultiDomainTrees – Allows users from ALL domains (inside the forest) to logon
    • If you are unsure where your users will be located, ‘MultiDomainTrees’ can be the best option (to ensure that all users are able to logon, wherever they are located).
    • However, this means that searches will traverse the entire forest, leading to performance slowdowns.

Once you have chosen, add one of the following entries:

  • chaseReferrals: True
  • multiDomainTrees: True

6. Decide on whether to use NTLM (“REMOTE_USER”) or KERBEROS authentication.
If you want to use NTLM/REMOTE_USER, then also add the following entry:

  • singleSignOnOption: IdentityMapping

Do not use this entry if you want to use Kerberos (which is the preferred option for many environments).
7. Perform a test on this namespace to make sure a connection can be made
8. Restart the service


From the web:
– universal group membership is replicated to all Global Catalogs (i.e. it has forest-wide replication scope). This can be beneficial (since it provides efficient way to retrieve group members) – but has its drawbacks (it increases volume of replication traffic).
– domain local groups do not have any limitations regarding their membership – i.e. they can contain accounts the same domain/forest or any trusted domain/forest. This does not apply to  domain global groups (they can contain only accounts from the same domain) or universal groups (they can contain only accounts from the same forest).
– universal group is a security or distribution group that contains users, groups, and computers from any domain in its forest as members. You can give universal security groups rights and permissions on resources in any domain in the forest.
– global group is a group that can be used in its own domain, in member servers and in workstations of the domain, and in trusting domains. In all those locations, you can give a global group rights and permissions and the global group can become a member of local groups. However, a global group can contain user accounts that are only from its own domain.
– domain local group is a security or distribution group that can contain universal groups, global groups, other domain local groups from its own domain, and accounts from any domain in the forest. You can give domain local security groups rights and permissions on resources that reside only in the same domain where the domain local group is located.

More information:

Cognos BI 10.2.2
Microsoft Windows 2012 R2 Server
What files should I save in a backup folder, before I apply a fix pack or do a upgrade of a Cognos BI 10.2.x installation?
If you have done advance tuning to the Cognos functions then this files are maybe updated;

You should keep a copy of the original file you change with the ending .org like Then you should copy your updated file with a ending like .ibm – then if the fix pack overwrites your system.xml file you have a copy of the file in, that you can copy back after the updated.

If you have done report customization then there is this files you need to make a copy off;

GlobalReportStyles.css 8.x styles Classes that were used in IBM Cognos 8 BI
GlobalReportStyles_none.css Simplified styles Classes that have minimal styling defined, useful for financial reports
GlobalReportStyles_1.css 1.x styles Classes that were used in IBM Cognos ReportNet
GlobalReportStyles_10.css 10.x styles Classes in the default style sheet for IBM Cognos 10 BI

They are in this folders

<c10_install>\bin\ The file in this location is used by Report Server for PDF and Microsoft Excel spreadsheet software outputs.
<c10_install>\webcontent\schemas\ The file in this location is used by IBM Cognos Viewer for HTML output.
<c10_install>\reportstyles\ The file in this location is not currently used.
<c10_install>\webcontent\reportstyles\ The file in this location is used by Report Studio.

Then you also may backup this files if you made changes there:

You should also export a unencrypted cogstartup.xml file from each servers Cognos Configuration. Save this file in a separate folder like d:\temp\cogstartup backup 20171124.xml

Include the date, when you saved the file, in the filename.

More information: