Product:
Cognos Analytics 11.0.12
Microsoft Windows 2016 server

Problem:
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”

https://www.ibm.com/support/pages/how-determine-when-cryptographic-keys-will-expire-and-are-cryptographic-key-and-ca-certificate-lifetime-settings-related
https://www.ibm.com/support/pages/cognos-gateway-unable-connect-cognos-bi-server-2
https://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_gateway_iis.html

Product:
Cognos Analytics 11.0.12
Microsoft Windows 2016 server

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

Solution:
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,o=CompanyA.com)(memberof=cn=Cognos_TM1_Modeler,cn=Cognos Groups,cn=UserGroups,ou=Global,o=CompanyA.com)))

“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,o=CompanyA.com)(memberof=cn=Cognos_TM1_Modeler,cn=Cognos Groups,cn=UserGroups,ou=Global,o=CompanyA.com)))

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).

(status=ACTIVE)
Check that the user is active in LDAP

legacyuid=${userID}
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:
https://www.ibm.com/support/knowledgecenter/en/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_ldapauthentication_process-element.html

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.

Product:
Cognos Analytics 11.0.12
Microsoft Windows 2012 Server
TM1 10.2.2

Issue:
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:
https://www.ibm.com/support/knowledgecenter/en/SSEP7J_10.2.1/com.ibm.swg.ba.cognos.c8pp_inst.10.2.1.doc/c_reviewthedefaultsettings.html
https://www-01.ibm.com/support/docview.wss?uid=swg21342592

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

Issue:
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.

Cause:
The root cause, a corruption in the \wlp\usr\servers\cognosserver\workarea for WebSphere Liberty Profile (WLP)
Solution:
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:
http://www-01.ibm.com/support/docview.wss?uid=swg22011841
http://www-01.ibm.com/support/docview.wss?uid=swg21991231
http://www-01.ibm.com/support/docview.wss?uid=swg21347919

http://www-01.ibm.com/support/docview.wss?uid=swg21341113

Product:
Cognos BI 10.2.2 fix pack 7
Microsoft Windows 2012 R2 Server

Problem:
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 namespace.java.lang.RuntimeException: A visa already exists for this namespace.
at com.ibm.cognos.camaaa.internal.auth.PassportImpl.add(PassportImpl.java:102)
at com.ibm.cognos.camaaa.internal.auth.handler.CreateApplicationLogonSession.handleMessage(CreateApplicationLogonSession.java:252)
at com.ibm.cognos.camaaa.internal.common.handler.HandlerWrapper.handleMessage(HandlerWrapper.java:172)
at com.ibm.cognos.camaaa.internal.auth.handler.AuthHandlerChain.invokeHandlersForward(AuthHandlerChain.java:79)…

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.

Product:
Cognos BI 10.2.2 fix pack 7
Microsoft Windows 2012 R2 Server

Problem:
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.

Troubleshoot:
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 10.0.0.78:389 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;
[‘AD’]
User account properties:
defaultName: roger
userName: roger
givenName: roger
surname:
email:
businessPhone:
mobilePhone:
homePhone:
faxPhone:
pagerPhone:
postalAddress:

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  domaincontrollerservername.domain.com  -port  389

The result should be like this:
ComputerName : domaincontrollerservername
RemoteAddress : 10.0.0.78
RemotePort : 389
InterfaceAlias : Ethernet0
SourceAddress : 192.168.254.11
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
https://technet.microsoft.com/en-us/library/cc938655.aspx

Active Directory Explorer (AD Explorer)
https://docs.microsoft.com/en-us/sysinternals/downloads/adexplorer

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.
http://support.microsoft.com/kb/832017#4

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772723(v=ws.10)

Product:
Cognos BI 10.2.2
Microsoft Windows 2012 R2 Server
Problem:
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.
Solution:
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.
https://www.ibm.com/support/knowledgecenter/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_includedomainsusingadvancedproperties.html#IncludeDomainsUsingAdvancedProperties

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.

http://www-01.ibm.com/support/docview.wss?uid=swg21380097

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’.

TIP:

• 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:
http://www-01.ibm.com/support/docview.wss?uid=swg21598533

https://www.ibm.com/support/knowledgecenter/en/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.c8pp_inst.10.2.2.doc/c_enabling_single_signon_between_actdirsrv_and_cog_comp.html

http://www-01.ibm.com/support/docview.wss?uid=swg21341889

http://www-01.ibm.com/support/docview.wss?uid=swg21340833

Product:
Cognos BI 10.2.2
Microsoft Windows 2012 R2 Server
Problem:
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?
Solution:
If you have done advance tuning to the Cognos functions then this files are maybe updated;
…\c10_64\configuration\CQEConfig.xml
…\c10_64\configuration\cclWinSEHConfig.xml
…\c10_64\configuration\rsvpproperties.xml
…\c10_64\webapps\p2pd\WEB-INF\p2pd_deploy_defaults.properties
…\c10_64\webapps\p2pd\WEB-INF\xts.properties
…\c10_64\tomcat\conf\server.xml
…\c10_64\webapps\p2pd\WEB-INF\services\reportservice.xml
…\c10_64\webapps\p2pd\WEB-INF\services\batchreportservice.xml
…\c10_64\webapps\p2pd\WEB-INF\classes\vierwerconfig.properties
…\c10_64\templates\ps\portal\system.xml

You should keep a copy of the original file you change with the ending .org like system.xml.org. 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 system.xml.ibm, 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;

They are in this folders

Then you also may backup this files if you made changes there:
<c10_install>\webcontent\schemas\GlobalReportStyles_10.css.
<c10_install>\webcontent\pat\res\templates.xml.
<c10_install>\webcontent\pat\res\Resources.xml.
<c10_install>\webcontent\pat\res\reportstudio_en.xml.
<c10_install>\webcontent\pat\res\TableStyles.xml.
<c10_install>\webcontent\pat\res\ChartTemplates.xml.
<c10_install>\webcontent\pat\res\ReportPresets.xml.

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:

https://www.ibm.com/support/knowledgecenter/en/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.c8pp_inst.10.2.2.doc/t_installfixpacksunix.html

https://www.ibm.com/developerworks/library/ba-pp-infrastructure-cognos_specific_page702/index.html

Product:
Cognos BI 10.2.2
Microsoft Windows 2012 R2 Server
Problem:
How update the toolbar with links?
Solution: (copied from ibm website) http://www-01.ibm.com/support/docview.wss?uid=swg21694761

You need to update the system.xml file. This is found in folder C:\Program Files\ibm\cognos\c10_64\templates\ps\portal\system.xml on the Cognos BI report (dispatcher) server and on the Content manager server. It is the Cognos Presentation service that create the web-page, so where this is running (true) there the files will be read. Best  is to update it on all Cognos instances.

More information on customization of reports from here
https://www.ibm.com/developerworks/library/ba-pp-infrastructure-cognos_specific_page702/index.html

As shown in picture, the style of a Cognos report or report object can be affected by many sources such as:

Properties
Global Cognos style sheet such as GlobalReportStyles_10.xml
Templates
Local Classes
Layout Component References
TableStyles.xml
ChartTemplates.xml
RAVE visualizations
ReportPresets.xml

If we want to create and modify classes that apply to all reports, we can modify the global Cognos style sheet. This is a useful strategy if we only have one corporate style for all reports.

There are four versions of the global Cognos style sheet as shown in Table below.

 Four versions of the global Cognos style sheet

The exact CSS file used will be chosen based on how the report style is set for a given report. The default setting for IBM Cognos BI 10 is 10.x styles, as shown in Figure 8. You can open this dialog by selecting Report Properties from the File menu in IBM Cognos Report Studio.

Report Properties dialog above.

Each of the four CSS files identified above is installed by Cognos in four different locations, as shown in Table below.

Files are on both gateway and dispatcher (app) servers.

Update the file GlobalReportStyles_10.css in all above folders.

In the following example we will modify the IBM Cognos 10 BI global style sheet GlobalReportStyles_10.css. This style sheet is used by Cognos Viewer for HTML output.

The following steps are a simple modification where we will modify GlobalReportStyles_10.css to increase the font size.

1. On your IBM Cognos BI 10 server, find the file named <c10_install>\webcontent\schemas\GlobalReportStyles_10.css.
2. Copy this file and save it as GlobalReportStyles_10_BU.css.
3. Open the original GlobalReportStyles_10.css in a text editor.
4. Find the text .ls /* list */.
5. Scroll down to font-size: 8pt; and change it to font-size: 28pt;.
6. Save the file and close it.
7. Clear your browser’s cache and restart Report Studio.
8. Create a new List report with any data source.Select the List object and view its properties. You will notice that the Font property is empty.
9. Click the Run Report toolbar button to preview the HTML output in Cognos Viewer. It will pick up the new 28pt font size at runtime.

More information:

http://www-01.ibm.com/support/docview.wss?uid=swg21339054

http://www-01.ibm.com/support/docview.wss?uid=swg21694761

Product:
Cognos BI 10.2.2 fix pack 7
Microsoft Windows 2012 R2 Server
Issue:
When a user from a different domain than the servers are in, try to login to Cognos Connection, they get this error message.
Error:
CAM-AAA-0064
The function ‘bindToBestGCServer’ failed.
Solution:
There are two Microsoft Windows domains, Domain A and Domain B, that have a forest trust. In Cognos Configuration you have setup two namespace – one for Domain A and one for Domain B. The Cognos servers are in Domain A.
On the Microsoft Windows server IIS manager you have set Windows authentication on the CGI-BIN folder for the Cognos Gateway.
The user selects the namespace he want to login to first when he reach the cognos connection webpage.
Inside Cognos Configuration you only need:
+ In the Value – Advanced properties window, click Add.
+ In the Name column, type singleSignonOption (Case sensitive)
+ In the Value column, type IdentityMapping (Case sensitive)
+ Click OK.
+ Save configuration and restart Service for the setting to take effect

…to make the login work.
If you have also enter multiDomainTree=true you get above error.
If you only have ONE namespace setup in Cognos, then if all domains are the same Active Directory Forest, you need to add this values
chaseReferrals = True
MultiDomainTrees = True

Solution is very depending one your network infrastructure setup, you need to test different configurations.

Authentication in One Domain Tree
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 Cognos. Users above the original authenticated domain or in a different domain tree cannot log in.

Authentication in All Domain Trees in the ‘Forest’
If you set a parameter named MultiDomainTrees to true, users in all domain trees in the forest can log in to Cognos.

More information
http://www-01.ibm.com/support/docview.wss?uid=swg21341889

https://www.ibm.com/support/knowledgecenter/en/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.c8pp_inst.10.2.2.doc/c_enabling_single_signon_between_actdirsrv_and_cog_comp.html#stp_SSO_active_drctry
http://www-01.ibm.com/support/docview.wss?uid=swg21339641