Cryptography Keys - how often should they be reset?

[jeffowentn]

Cognos 8.4.1 (BI - FP3; Planning - FP2) on Windows (2003 and 2008) and using SQL 2005/2008

I was just told to reset our cryptography keys since it had been months since that had last been done.  Is there any rule of thumb regarding how frequently this should be done? 

Is there anyway to automate this?

[Grim]

This shouldn't have to be done very often at all if everything is humming along smoothly.

However to avoid Crypto Key issues ensure that your end users running FM, Metrics Man, Transformer do NOT use the same install for 2 different Cognos envs. IE. Switching the config between 2 different Cognos servers. They should have a separate install for each instance. This will avoid filling the Crypto tables in the CM/CS with unwanted entries. (This has been an issue in the past that I was involved with.)

That said, there are circumstances when regen'ing the keys is required. Usually this is when they get out of sync. Keep in mind that in a distributed install the Primary CM is where they keys get gen'd first and where all other components/installs grab a copy. Thus the reason for the "Stop last/Start first" rule for the Primary CM comes from.

[jeffowentn]

Grim,

Thank you for your response.  I have a few follow-up questions.  First of all, I have scripts to manage the stop/start of services so that the Primary CM is the last one stopped and the first one started, etc.  So, I don't think that is an issue. 

You mentioned that users should not access different instances from the same install.   Help me understand how to accomplish this.  I am not aware of any way to install the software multiple times on one computer, and using Citrix seems inefficient for users in the same building as the hardware/software on the server side.  Also, I should probably note that currently the primary use of the software is for the Planning applications and not so much on the BI-side, although the BI toolset is increasing in use, now, too. 

The reason for the different instances is DEV vs. QA vs. PROD.  We alternate configuration files depending on which instance to hit, so they are using the same install.  This is done because our "power users," or "modelers" are also the application owners/developers.  Our team is only staffed up to assist with development and to manage the system and support-related issues.  We do not have separate developers from the users.

Lastly, we reboot and recycle the services every Mon/Wed/Fri, but this does not mean the CSK's get reset that frequently at all.  I was just wondering if I should put in my maintenance routine to reset the CSK's every few months or some other frequency...

I appreciate your responses and anyone else's input...

Jeff

[Grim]

Easy to install another version.
1. Run the install and point it to a different directory.
Default location example: C:\Program Files\IBM\cognos
Install to:
C:\Program Files\IBM\Cognos\FM-Dev
C:\Program Files\IBM\Cognos\FM-QA
C:\Program Files\IBM\Cognos\FM-Prod
Or
C:\Program Files\IBM\Cognos\Dev (If you want to install all tools to the same directory, which you can. IE. Framework Manager, Metrics Manager, Transformer).

2. (Not the recommended way, but it works.) Copy the directory and rename it.

Basically you want each install to have it's own config and single set of crypto keys. Every time you change the config and have to "Re-save" you are grabbing a new set of keys and adding entries into the CS Crypto tables. In a large env with many devs this will eventually cause issues. Very bad issues, where you end up regening crypto keys on the server(which should not happen, unless there is an issue/error that calls for it).

I would try to avoid regenerating the crypto keys in the your "maintenance".

What OS/Platform are you running your Cog stuff on? What version?
There a specific reason for a restart 3 times a week?

Side Note: Sometimes people aren't aware but Fix Packs (FP) should also be applied to the modeling tools. In other words, FP4 that was recently released should be applied to your BI servers AND the client modeling installs. The client modeling tools should ALWAYS be at the same patch level as the servers.

[jeffowentn]

Grim,

Thank you for the excellent feedback.

To answer your questions:

1.  We are on Windows - some 2008 and some 2003 boxes, some physical and some virtual (about half of our servers).
2.  We are using SQL 2008/2005.
3.  We were told by IBM Cognos Technical Escalation Services to recycle and reboot the services/servers on a more frequent basis than once/week, to make sure there were know cache, java heap, memory-type issues - this may be specific to Planning and not the BI-side.

Thank you for the note about the developers machines, although I believe that is not relevant in this case since the FP is for BI and the only "developers" that are not on our machine are all Planning developers.  We may have a couple one-off users, but I think they are only working through Cognos Connection for anything BI-related.

Regarding the separate installs, because I feel like I asked a number of people a number of times about this, is there not any issue with the registry, if you install the Planning thick-clients to multiple directories on the same machine?  Maybe that doesn't matter.  Maybe one set of registry entries would apply for three separate installs.

The issue we have is that we have the same business/finance people developing their Planning models in DEV, testing in QA, and maintaining/using in PROD, so I need some way for them to be able to use the Planning thick-client software on their machines and easily switch between their different environments without having to reconfigure everything each time.

This would be great, if Planning works this way, as well.  ?

Jeff

[Grim]

Planning is whole other beast that I know very little about. That said, I know there are issues with Planning and only being able to run 1 single install. So you might be right there.

As for the reboots due to Planning. Well that now makes sense as well.

Then again, I'm no Planning expert.

[smiley]

The issue we have is that we have the same business/finance people developing their Planning models in DEV, testing in QA, and maintaining/using in PROD, so I need some way for them to be able to use the Planning thick-client software on their machines and easily switch between their different environments without having to reconfigure everything each time.

The earlier described multi directory trick only works for BI, not for planning.

For planning you're stuck with creating some batch files to prepare each environment.
Start with a config towards the DEV. Then save the directory "encryptkeypair, signkeypair and csk" and the cogstartup.xml and all cogstartup_timestamps.xml from that install in a seperate dir.

Flush the content of the "encryptkeypair, signkeypair and csk", and reconfigure cognos configuration for QA
Save the "encryptkeypair, signkeypair and csk" dirs, the cogstartup.xml, and all  cogstartup_timestamps.xml files that got a new timestamp with your latest save, and store in a fresh directory.
Repeat the last step for prod.

Now restore what you need, depending on the environment you need to start via a batch script.

Not supported in any way by cognos, but works like a charm.

[Grim]

Check for the freshness file as well.

<cognos>/temp/cam/freshness

It's a file not dir.

[jeffowentn]

Smiley - thanks for the great feedback.  I'll test that out and see what we can do on the scripts side to make it happen.  Do you ever have to update CSK's for the users?  If so, what do you do to update their CSK's, or will they automatically be updated, as normal, when they access each instance?

Grim - what needs to be done with the freshness file?  Copy it for each instance, as well, blow it away, etc.

Jeff

[Grim]

Depends what your doing. If your refreshing the crypto keys from scratch, blow it away(I always back things up first, regen, then if everything works delete the old files, but that's just me).

If your copying off all the files and folders, then logically you'll copy it off with everything else.

[jeffowentn]

Smiley,

Now that I have created separate instances of the encryptkey and signkey folders (no csk folder, as this is just a thick-client install and not the server installs) as well as the cogstartup.xml and cogstartup_timestamp.xml, and put those in separate folders, I need some clarification on the process.

When I copy those directories/files back into the Configuration folder, what do I do with the cogstartup_timestamp.xml file(s)?  The reason I ask, is b/c simply dropping the correct files back in the directory will not necessarily overwrite the one that already exists in the Configuration folder since the timestamp will cause the files to be unique.  Do I need to come up with some way to delete any cogstartup_timestamp.xml files, each time, or is it ok if any previous ones do not get removed?

Let me know if my question is not clear.

Jeff

[jeffowentn]

Smiley,

In case this answers "my" question to you, I've done some testing with simply copying the folders/files from one instance back into the Configuration folder, which overwrites all but the cogstartup_timestamp.xml file.  It appears, that leaving the "timestamp" files in the Configuration folder from different instances does not cause a problem.

At some point when we do have to reset the cryptography keys, will that cause a problem for the files that have already been copied off for each of the different instances?

Also, any reason why I should not take the DEV, QA, and PROD versions of these files and distribute them to each one of our Modeler licensees (have the thick-client installs) to use on their own machines?

Thanks, again.

Jeff

[Grim]

1. Bad practice to copy files from other servers. Really bad if you are running distributed. This is due to the cogstartup.xml being UNIQUE to each install. I can't stress this enough, DO NOT COPY cogstartup.xml from one server to another.

2. The timestamp files are only backup files for troubleshooting purposes. Everytime you do a save in Cog Config it creates a backup of the cogstartup.xml (to the timestamped file).

[jeffowentn]

Grim,

I agree on the bad practice.  I don't do this on the servers.  This is all about the end-users.  We have "power" users who create and maintain their own planning applications and run data through their models.  Consequently, they will use the DEV instance when they are either creating new content or making significant changes to existing content.  Then, when they are ready, we go through the process of promoting the content through to PROD.  The cogstartup.xml is unique to a desktop with the thick-client software installed.

Based on your feedback, I configured for PROD, and then copied the appropriate files.  Then, I cleared the files, reconfigured for QA, and saved the files.  Then, I did the same thing for DEV.  These files were the ones I was considering bundling and pushing to the roughly 20 power users we have in the organization.

The reason for packaging all of this is that, while most of our users are in the same building as our team, not everyone is.  There is a fair amount of turnover in the finance positions (promotions and lateral moves to get diverse experience).  Between the turnover, and the refresh of user PC's, a simple software package to install would be much more efficient than to have someone walk through the install and configurations, manually, every time.

How have you addressed these issues in your experience?

Anyone else have suggestions?

Jeff

[jeffowentn]

Anybody have any further thoughts on this?  Currently, the only thing that is changing for our power users when they switch between DEV, QA, and PROD, is the cogstartup.xml file.  The versions of the cogstartup.xml file that they have for DEV, QA, and PROD, are based on ones I created on a thick-client install on a desktop.  Then, I deployed those cogstartup.xml files with the thick-client install on each of the power users' machines.

What has been suggested above, is to create separate encryptkey and signkey folders as well as the cogstartup.xml and cogstartup_timestamp.xml for each instance (DEV, QA, and PROD).  I would do this on a thick-client install on a desktop machine, and then those files for each instance would be deployed with the thick-client install to each of our power users' machines.

Does this improve anything for us with cryptography key issues, or is this just a different way of doing the same "wrong" thing?

It seems that IBM Cognos just assumes we will have separate computers/people for each instance in the environment (separate people to work only in DEV, separate people to work only in QA/TEST, and separate people to work only in PROD).  For Planning, this is often not reality.  So, I am trying to figure out the best way to support this need, unofficially.

Thank you for your help.

Jeff