Product:
Cognos TM1 10.2.2 café
Microsoft Windows 2012 R2 server

Symptom:
How setup CAFÉ on server so accessible from workstations?

Solution:
In PMHUB enter the name (server name) of the TM1 server in the HOST value for com.ibm.ba.pm.resource.tm1.dictionary.

This value is shown for the CAFÉ user when they try to login.
Default value is localhost.

To get to PMHUB surf to http://servername.domain.com:9510/pmhub/pm/admin

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

Product:
Cognos TM1 10.2.2 Performance Modeler
Microsoft Windows 2012 R2 Server

Symptom:
After uninstall of TM1 performance Modeler on 2012 server from add/remove programs in control panel. You cannot install PM again — either from the TM1 application web icon or from the MSI file itself.

This issue is caused by default security settings on Windows 2008 and Windows 2012 computers. The User Account Control (UAC) settings specify that non-administrators cannot run Microsoft Installer (.msi) files.

If you get an error like this:
Provagent bootsrap update failed: Could not copy “win32\x86_64\cognosrcp.exe” to d:\program files\ibm\cognos\tm1_64\coginsight
– Please try to install it again, in most cases it works the second try.

Error message:
The system administrator has set policies to prevent this installation

Solution:
When try to install the file from the TM1 application web site, select download and save the MSI file in a folder on your hard disk ( d:\temp)

1. Go to Start > Accessories.
2. Right-click Command Prompt and select Run as administrator.
3. In the command window, use the cd command to go to the directory containing either CognosInsight.msi or PerformanceModeler.msi.
4. Type either CognosInsight.msi or PerformanceModeler.msi.

Product:

Cognos TM1 9.5.2

Windows 2008 R2 server

Microsoft Excel 2003 (11.5612.5606)

 

Symptom:

When from TM1WEB select to slice to excel or snapshot to excel, you select “export rows in current page” and “plan_version” for dimensions titles to export. That give a total of 5 new sheets to be generated. You get a error message after some time.

 

Error message:

Export in process. Please wait…

A problem occurred while resetting culture settings : Old format or invalid type library. (Exception from HRESULT: 0x80028018 (TYPE_E_INVDATAREAD))

 

Possible Solution:

Stop all TM1 services on the Windows server, including the TM1 Excel Service.

For Office 2003 users you must Create a 1033 directory under C:\Program Files\Microsoft Office\Office11. Then, copy excel.exe to the 1033 directory, and rename it as xllex.dll.

For Office 2007 users you must copy (DO NOT CUT) the “xllex.dll” that is in C:\Program Files\Microsoft Office\OFFICE12\1033 into the following directory: C:\Program Files\Microsoft Office\Office12.

For Office 2010 users you must copy (DO NOT CUT) the “xllex.dll” that is in C:\Program Files\Microsoft Office\OFFICE14\1033 into the following directory: C:\Program Files\Microsoft Office\Office14.

Ensure that all TM1 service use the same Windows domain service account.

Start all TM1 service on the Windows server.

Check that your version of Excel is English.

Ensure that Internet explorer uses English (United States) [en-US] as Language Preference,

set in Internet Explorer under TOOLS – INTERNET OPTIONS – GENERAL – LANGUAGES.

Click on ADD to add the English language.

Click on MOVE UP to place English as first language in the list.

Click OK

Close Internet Explorer

 

In some cases you need to ensure that Regional settings on the TM1 server for the Windows service account is set to English.

Go to control panel and click on “region and language” settings.

Select format to be English (United States)

Click APPLY

If you get a new error after above changes that say

“There was a problem sending the command to the program”

when you start TM1 perspective with Excel 2003 then you must in excel do this;

Go to TOOLS – OPTIONS – GENERAL tab

clear the checkbox for “Ignore other applications”

Click OK.

 

For Excel 2007 you need to Bring up the Excel options, go to advanced and then scroll down to the “General” section.  Make sure that

“Ignore other applications that use Dynamic Data Exchange (DDE)” is not checked.

 

Now TM1 perspective will work.

 

 

More information

The additional workaround for Office 2007 & Office 2010 is slightly different for Office 2003 which is listed in the “KB 320369” article.

 

Product:

Cognos TM1 9.5.2

Windows 2008 R2 server

 

Symptom:

When you are inside TM1 Contributor web site and click on “update application” icon you get a error message.  You can start the TM1 application, it is only the Admin dialog that does not work.

 

Error message:

Connecting to server application error

Could not open specified application

 

Cause:

The TM1 application have not been successfully installed to the new TM1 contributor server

 

Solution:

You need to do this steps if you want to move a complete TM1 application between servers.

 

How to export a TM1 contributor application from PROD server:

Open the TM1 Contributor Portal.

  1. Mark the application to export.
    2. Click Export button.
    3. Click Save on the File Download dialog box.
    4. Navigate to the directory where you want to save the export file.
    5. Click Save.

This create a zip file of your TM1 Contributor application.

 

Go into TM1 Architect and open you TM1 application – select SAVEALL.

Exit TM1 Architect.

Stop the TM1 windows service.

 

Zip the datafolder for your TM1 application on the PROD server.

 

Copy the ZIP files over to the other TM1 server.

 

How to import  a TM1 contributor application to DEV server:

 

We assume you already have a TM1 application here, that you only want to update with data from the other TM1 server.

 

If you allready have a application in the TM1 Contributor application with the same name, you need to delete it first as Administrator in the TM1 Contributor Portal on the DEV server.

 

Stop the TM1 windows service.

Unzip the datafolder files to the TM1 application folder on the DEV server.

Make any changes needed to tm1s.cfg file ( e.g. change server name)

Start the TM1 windows service.

 

  1. Open TM1 server from architect.
  2. Run the following TM1 control TI Process: “}tp_admin_delete_all”
  3. Click OK on Provide Parameters Values dialog.
  4. Exit TM1 Architect program.

Import the TM1 Contributor application as an Administrator in the TM1
Contributor Portal
Steps:
1. Open the TM1 Contributor Portal.
2. Click import button.
3. The Application Import window opens.
4. Select the TM1 Server onto which you want to import the application.
5. Click Browse next to the Application file field.
6. Navigate to the application (.zip) file, then click Open.
7. Select the Import application security option if you want to import security
settings with the application.

  1. Select the Import application properties option if you want to import
    property settings with the application.
  2. Click Import.

 

Now you should be able to click on the UPDATE APPLICATION icon.

 

Any status indicators of the TM1 contributor nodes can be lost during the process.

Product:

Cognos Planning 10.1.1

Windows 2008 R2 server

Symptom:

How do I upgrade my analyst folders from Cognos Planning version 8.4 ?

 

Solution:

Create a file share on the new planning 10.1.1 server.

In our example we call it \\newplanserver\cognosplanning

Make everyone have full access to the share

(later change that to only allow planning administrators and service accounts to have access)

Copy you analyst models folders over to the new share from the old Cognos planning server.

(check inside Cognos Planning Analyst for the path to the files – under File -Administration – Maintain Libraries and Users)

Copy the LIBS.TAB file from the old planning filesys.ini share to the new share.

Disconnect from the old Cognos planning server, so you are not mapped to it any more.

Start New Cognos Analyst on the New Cognos planning server.

Select File – Administration – Upgrade – Existing Libraries

Browse to your local LIBS.TAB file.

Click on OPEN.

“Some of the libraries you are about to import has the same library number as libraries that already exists in analyst.

These libraries cannot be imported.

You can manually copy existing libraries to a different library number, and them manually connect to the old libraries via the Add Library functionality in the Admin screens.”

Click OK.

Now you have the Analyst libraries in the list of Maintain Libraries and Users.

But they have the old path, that is wrong and need to be changed.

Right click on a library in the list and select “Change Library Path…”

In the Find string you enter the part of the path you want to replace

can be \\oldservername\analystshare

In the replace with string you enter the new path to your librarys

in our case that is \\newplanserver\cognosplanning

Click Replace

“The path will be changed for xx libraries.

You can press Cancel to abort the operation.

OK to continue.”

Click OK

Now all the path are updated – they are shown in CAPITAL LETTERS.

 

To validate the path afterwards, just click Properties for each library since that will report if there are any problems.

 

IMPORTANT: We do not guarantee this process, you need to make sure you have valid backup of your Cognos planning files before starting the upgrade process.

Product:

Cognos Planning 10.1.1

Windows 2008 R2 server

 

Symptom:

You want to move Cognos planning deployment files (macro) from one server in test to another server in prod environment. You have copied the macro folder to the new servers deployment folder. When you have many Cognos servers in the same environment it is recommended to have them all point to the same file share for deployment files.

When you run the Cognos planning deployment wizard get error when you select import.

 

 

Error message:

There was a problem running the Deployment Wizard.

null

 

There was a problem running the Planning Network Transfer Wizard. Please see the error log for more information.

 

Cause:

Strange characters like – and space are not allowed in server name or share name (folder name) for the deployment folder.

 

You can test if the servername is bad, by change in Cognos Configuration to use the IP address instead of the servername in the field for deployment.

 

E.g. \\192.168.1.10\deployment

 

If the IP address works, then you know it is the planning server name that make the deployment not to work.

 

Solution:

Go in to Cognos Configuration

Select Environment

Go to value for Deployment files location in Environment – Group Properties.

Change from \\server-name\deployment to

\\192.168.1.10\deployment

 

(default value is ../deployment)

(default value will look for the cognos planning files in folder c:\program files (x86)\ibm\cognos\c10\deployment.)

 

Click on Save

Click Stop on services

Click Start on services (check Details for error messages, should not be any).

Exit Cognos Configuration

 

or place the share on a windows server that have a short name with only letters in it.

Product:

Cognos BI 10.1.1 (64 bit installation)

Windows 2008 R2 Server (64 bit server)

Oracle 11g on Linux server

Oracle client version 11.2.0.1.0

Java jre version 1.6

 

Symptom:

Inside Cognos Connection you test a data source to Oracle database, you get error on the DQM (dynamic query mode JDBC ) connection, but the CQM (compatible query mode Native Client) works fine.

 

Error message:

XQE-GEN-0002 An unexpected exception occurred: ocijdbc11 (F:/Program Files/ibm/cognos/c10_64/bin64\ocijdbc11.dll is not a valid Win32 application. )

 

Cause:

The path is pointing to the wrong folder containing the wrong oracle client files.

 

Solution:

Install both Oracle 64 bit client and Oracle 32 bit client, on the Cognos BI server.

Update then Windows PATH to include the Oracle client folders.

 

Ensure that path is first to the Oracle 64 bit client,

c:\oracle\instantclient11g\

there ocijdbc11.dll file is 135 Kb in size

 

Ensure second path is to the Oracle 32 bit client,

c:\oracle\instantclient11g\bin

there ocijdbc11.dll file is 100 Kb in size

 

Ensure that you have put the ocijdbc11.dll with size 135 Kb in the c:\program files\ibm\cognos\c10_64\bin64 folder.

 

Ensure that you have put the ojdbc6.jar with size 2102 Kb in the c:\program files\ibm\cognos\c10_64\v5dataserver\lib folder.

 

You need to restart the SERVER to make the changes take affect.

 

More information:

You can download the Oracle client from here:

http://www.oracle.com/technetwork/database/enterprise-edition/downloads/112010-win64soft-094461.html

Cognos DQM uses 64 bit database drivers, and Cognos CQM uses 32 bit database drivers. If you want both to work, you need to have both version of database drivers on the Cognos BI server.

 

More information

https://www-304.ibm.com/support/docview.wss?s=3442&uid=swg21516706

Product:

Cognos Controller 8.5.1

Windows 2008 R2 server

Cognos BI 8.x

 

Symptom:

When user run a standard report inside Cognos Controller client they get a login dialog from Cognos Connection inside.  Cognos Controller is working in other areas. But when you select “Verify Account Structure” and run the report – you get a login dialog asking for you User ID and Password for the data source: SQLNCLI.1:… instead of the report result in HTML format.

 

Error message when you test the data source link in Cognos connection:

QE-DEF-0285

OE-DEF-0321

RQP-DEF-0068

UDA-SQL-0031

UDA-SQL-0129

UDA-SQL-0564 [Microsoft OLE DB provider for SQL server] Login failed

for user ‘cognos’ (SQLSTATE=42000, SQLERRORCODE=18456)

 

Cause:

The REPAIR button has not worked in Cognos Controller Configuration Report Tab. Can be because the user running Controller Configuration program is not system administrator in Cognos Connection. Data source connections have been manually updated in Cognos.

The correct password is not entered in the Cognos Connection data source connections.

 

Possible Solution:

Manually update the login value in Cognos Connection for the controller database.

Click on Launch – IBM Cognos Administration

Click on Configuration tab

Click on the data source connection you want to edit, starts mostly with SQLNCLI.1

Click on more time on the SQLNCLI name to go into the login object.

then click on the “SET PROPERTIES” icon on the right side of the login object.

Click on Signon tab

Click on Edit the signon… link

Here you can enter the correct password for the controller data source.

Click OK

Click OK

Click on the SQLNCLI link in the top next to the cognos link, so you are back on the data source connection and not in the signon object.

Click on the “Test the connection” icon at the right side of the data source.

Click the TEST button

If it display “Succeeded” then you are good to go.

Click Close

Click Close

Leave Cognos connection and start Cognos controller client and test the report again.

Product:

Cognos Controller 10.1 FAP

 

Symptom:

I do not see the trickle of data in the FAP log dialog.

 

Problem:

Correct log level, not set at startup of FAP process.

 

Solution:

When you setup the Controller FAP process, you must active HIGH logging level to allow the trickling steps to be written to log table.

 

Go into Cognos Controller FAP Manager.

Edit the source (the controller database) you are using

Set the Log Level to High.

Click Save.

 

Edit the data mart  (the tm1 connection) you are using.

Set the Log Level to High.

Click Save.

 

You need to stop the Data marts

You need to stop the Source

Then you need to start the Source

and start the Data mart again

to active your change in logging.

(this will make a intial publish – who may take long time)

Then you will see a line like;

-Start trickling data

-Finished trickling data.

 

Then you should be able to see when the trickling is done.

Product:

Cognos Controller 10.1.395   (integration version 10.1.408)

IBM Cognos Controller Financial Analytics Publisher

TM1 10.1

Windows 2008 R2 (64 bits)

Symptom:

In FAP logs show error after the New Active source detected and added to scheduling: controller.

Error message:

Could not login to TM1, host: tm1servername, server name:  tm1servicename, user name: AD\service_account

 

Background information:

All windows server is in one domain called SRV

All users accounts are in one domain called EU

On TM1 server have only installed Cognos TM1 version 10.1 64 bit.

All tm1 service use the a service account in the EU domain.

The FAP service use a service account in the EU domain.

CCR_JAVA_HOME is set to \program files (x86)\ibm\java60\jre, where you have unpacked the jre.zip file that comes with the Cognos Controller media.

A 32 bit ODBC connection called FAP is created to the Controller FAP SQL database.

The Cognos Controller Batch service and COM service use a service account in the SRV domain.

Cognos Configuration for BI have namespace advanced properties set to:

singleSignOnOption      IdentityMapping

multiDomainTrees         True

 

 

Solution:

Restart of the Cognos BI service and change of the DC server that Cognos BI authenticate against.

From a DC server for the SRV domain, change to a DC server in the EU domain.

This is made inside Cognos Configuration under the namespace settings.

Host and port:  DC2EU.corp.company.com:389

The FAP service need to use a service account in a domain that Cognos BI service is authentication against.

 

Other possible solutions:

Install of TM1 32 bit client on the server where the FAP service is installed.

Update the PATH with the folder to the 32 bit TM1 client.

 

Erase the TM1 cube used for FAP, and start over. It can have become corrupted so the FAP service can not update it.