Cognos configuration Namespace Name vs Namespace ID

[globalbear]

We are on 8.3 and have different settings in test/production in Cognos configuration:

Production:
Type: Active Directory
Namespace Name: server.domain.se
Namespace Id: server.domain.se
Host and port: server.domain.se:389

Test:
Type: Active Directory
Namespace Name: SERVER.DOMAIN.SE
Namespace Id: SERVER.DOMAIN.SE
Host and port: server.domain.se:389

Both enviornment work independent of each other but when trying to deploy packages between environments we get security problems.

We tried changing the namespace name in test to server.domain.se - that works - but it is not possible to change the namespace id. Cognos configuration seems to think it already exisist since it is just a matter of capitalization. And - of course - the namespace id seems to be the important part...

How do we come around this capitalization problem with the namespace id?
Any ideas?

[Filip.Cuppens]

It seems obvious, but why do you not delete the existing namespace in Cognos Configuration, and afterwards create a new one, with the correct capitalisation ?

[globalbear]

Tried that - didn't work.

The reply was that the namespace id already exists... Cognos configuration doesn't seem to care about the capitalization but the portal/content store do care. Catch 22!  :-\

[timbrelyp]

I am a newbie but does this work? It appears this is going a step further than just removing it (disabling it) in Cognos Configuration.

Personally I am in namespace hades trying to setup LDAP with a Novell server. I cannot get my values between Novell and Cognos aligned. It is basically a vocabulary issue for me I think. BUT I am hoping the steps below completely remove a namespace (since I have several failed attempts)

This comes directly from ug_cra.pdf
Delete an Inactive Namespace
If a namespace was removed from IBM Cognos Configuration and is no longer required, a member
of the System Administrators role can delete it permanently in the directory tool. Deleting a
namespace also deletes all the entries in My Folders that are associated with the namespace.
To access the directory administration tool, you must have execute permissions for the directory
secured feature and traverse permissions for the administration secured function.
Steps
1. In IBM Cognos Connection, in the upper-right corner, click Launch, IBM Cognos Administration.
2. On the Security tab, click Users, Groups, and Roles.
If the namespace you want to delete does not have a check mark in the Active column, it is
inactive and can be deleted.
3. In the Actions column, click the delete button.
If the namespace is active, the delete button is not available.
The namespace is permanently deleted. To use the namespace again in IBM Cognos 8, you must
add it using IBM Cognos Configuration.

[sir_jeroen]

It might be caused by 2 reasons:
1: the namespace Id (the one that is used by cognos in the searchpath) is case sensitive; So uppercase and lower case make a difference
2: From your words I understand that there are 2 seperate AD domains. If so then most likely your solution will never work, because when an AD namespace is used, the searchpath of a user will be built up with it's GUID. With 2 different servers, a user with the same name will still have a different GUID and therefore this will cause errors (e.g. roles will be deployed empty to the other server, because the authorized users can't be found by their GUIDs).
So, the best solution is to make the Namespace ID's identical and have the servers use the same A.D..

[globalbear]

We have only got one AD domain but the setup is different between production and test. They both use the same AD authentication and both environments work independent of each other.

The CAMID in production is server.domain.se but in test SERVER.DOMAIN.SE. They both point to the same AD server but somehow Cognos doesn't like the different capitalizations.

Well, well... The setup of our test environment had to be changed and since we didn't have that many security settings I solved it this way:

* I allowed anonymous access in Cognos Configuration.
* I made all users system admins for a while
* I deleted the AD name space in cognos config
* I restarted cognos from cognos config
* I logged on to the portal as anynomous
* I deleted the old AD namespace (this was now possible since it no longer was active) from the portal
* I setup a new AD namespace in cognos config (with the correct settings)
* I disallowed anonymous access in cognos config
* I restarted cognos from cognos config
* I logged in to the portal again with my AD account (at this point every AD acount is admin)
* I took away the system admin setting for everyone and made the correct users system admins instead
* Now I did have an environment in which I was system admin and nobody else could log into
* Finally I had to setup all the cognos groups/roles again from the portal so that users should belong to the right groups

It worked!

When I now deploy packages between environmnents it works just fine.

Problem is I lost all security setting in the test environment, but in my case that was not so bad.

Another approach would be to deploy the total content store from production to test but as we have several packages and reports that only exist in test that would mean loosing them which was a bigger problem than resetting the security.

[Paddy_K]

I have similar situation, where in two environments (both Cognos 8.1.2) Access Manager namespace id is different. The idea was to be able to identify a user/object clearly across multiple environments from past experience.

I have 7 environments to manage for 2 organizations in our company, say Org_1 and Org_2.

In Org_1, 4 (RND, DEV, TEST, PROD) environments' namespace ids are all named as "Default" since long, which was bit confusing with the English word 'default' and also didn't tell who from where in all the places. Also the users and especially their privileges are different in different environments, like some in DEV with R/W/E/T but in TEST or PROD with only R/E/T. Some exist only in TEST and PROD but not in RND or DEV and such.

To overcome that issue, I decided to name the namespace in Org_2 with more meaningful and specific names like "Org_2_BI_PROD_Series_7".

The 3 other environments DEV, TEST and PROD in the 2nd organization are created new, by cloning the content store at database level (Oracle 10g) cloned from the PROD of first organization. The namespace id in the newly cloned environment is "Org_2_BI_PROD_Series_7", which is different than Org_1's PROD nameapce  "Default". (I don't have regular Cognos Deployments across environments, we do that through separate file server process using Version Manger), so I didn't anticipate portability issues of the new development under different namespace ids.

This worked just fine in the Org_2's new PROD. All the users could access and work fine in the Org_2's PROD.

Then I followed exact same steps while creating Org_2's TEST, as "Administrator" (series 7 Root User Class) and didn't realized till I released the environment to non-admin users that they can't see Cognos Connection portal (the public folders and menu options etc). However, they all can access Report Studio, QS, etc alright. I have made sure that on Cognos Connection, Directory Users Groups Roles tab that "Everyone" has R/E/T privileges (though only Traverse is sufficient).

But don't know beyond that if any record is mismatching at the database level or got inadvertantly deleted while troubleshooting another issue with Metric Store (which is resolved after recreating Metric Store and reinitializing Metric Package).

Error I am getting is
CM-REQ-4158
The search path "storeID("")" is invalid.
DPR-ERR-2082 An error has occurred. Please contact your administrator. The complete error has been logged by CAF with SecureErrorID:xxxxxxxxxxxxxxxxxxxxxxxxxxx

Can someone PLEASE share ideas thoughts or approach I might take now?

An SR is open with IBM-Cognos for more than 2 days without any response at all.