Install Fix Packs for 8.4.1?

[jeffowentn]

We are in the process of installing both the BI (FP3) and Planning (FP2) fix packs for 8.4.1.  I've already been told by IBM Cognos that there are no issues with different fix packs between the two products in the same environment.

Does anyone know if I can install the fix packs on the servers before updating the thick-client installs and the Contributor client component installs on the users' machines?  Can the users still do what they need to in Analyst, CAC, and Contributor web with the old installs or will installing the fix packs on the servers immediately prohibit the users from using the software?

We currently have DEV, QA, and PROD instances, with varying architectures.  Everything is Windows, although some is 2003 and some is 2008.  SQL 2005 and SQL 2008.

Let me know if you need any more info...thanks for your feedback, in advance.

[jeffowentn]

I've been told by Cognos that I need to install the fix packs on the servers, then the thick-clients (admins), and then the web users (clients).  Once I start the process, users will not be able to access content until I finish installing the fix packs on their machines.

I've also been told that I can install FP3 for BI and FP2 for EP with no problems.  I just thought I would pass along the info.

[jeffowentn]

Have another question, though:

Documentation is essentially non-existent, particularly on the Planning side (Fix Pack 2).

It appears the client install (web users) has the capability of a silent / unattended install.

Does anyone know if the Updater (Admins) install can be installed silently, or in an unattended fashion?  The underlying 8.4.1 Admin install is setup as a software push to our users.  It would be really frustrating/backwards to have to manually install the Fix Pack behind every Admin install.

Any help or documentation you can offer would be greatly appreciated.

[ericlfg]

Hey Jeff,

I don't see why you wouldn't be able to setup a push to get the updater for FP2 pushed out to the end user Admin machines.  Included in the fix is a standard installer executable (issetup.exe) that can likely be wrapped up in an SMS push to the machines.  I've never seen a document that describes the behavior, other than the install and configuration guides.

Sorry can't be more of help, perhaps someone else on here has some thoughts.

Cheers

[jeffowentn]

Eric,

We're working on creating a SMS push as you stated.  We were just hoping for something that was a little more streamlined and less apt to require manually created software pushes on top of manually created software pushes - at some point, something will be missing or not "opened" up as needed. 

[jeffowentn]

Ok, so it appears that we might have an issue related to our upgrades to BI FP3 and EP FP2.  After roughly 2 weeks of everything working fine in our production environment, we had an issue where the web did not appear to be working properly when it came time to open the package.  The first thing I noticed, aside from the nearly blank web page, was the fact that the URL referenced cognos.cgi instead of cognosisapi.dll, when we had clearly configured the environment for congosisapi.dll. 

I started poking around and found that my default.html and index.html files appeared to have been over-written, presumably by the fix pack installs.  I copied those files, and then manipulated the originals to revert back to cognosisapi.dll.

We are working now. 

Can anyone confirm if this is what happens for a fix pack install?

Is there anything else that gets modified that may need to be changed back to the pre-fixpack install state, after concluding the fix pack install?

[MFGF]

It's generally not a good idea to modify the default.html and index.html files for this very reason - changes you make to them can get overwritten during software updates.

Generally I would recommend changing the gateway URI in Cognos Configuration to point to cognosisapi.dll instead of hacking these files. Configuration settings do not get overwritten during software updates.

Just a thought...

MF.

[jeffowentn]

Great idea, but I was instructed by Cognos to modify the file to reflect cognosisapi.dll in these two files.

When I ran into my issue, this morning, and saw cognos.cgi in the URL path during the problem, Cognos Configuration did have cognosisapi.dll in the gateway URI, but the default.html and index.html files reflected cognos.cgi.

I was under the understanding that both pieces were required to make it work properly.  Is there something somewhere else that I should change that would keep us from modifying the default.html and index.html files?

[SomeClown]

Changing it in those locations is standard operating procedure when switching to ISAPI - been doing it that way for years.   It's just one of those things that Cognos never documented very well.

Yes, those get overwritten by the FPs which is why it changed.

They (IBM) tucked away a copy of the isapi version (called something like  cognos.isapi.sample or etc) in a different folder at some point (not sure if 8.4.1 or 10.1).  Supposedly you can copy that over into the webcontent folder and rename it.  It's easier just to edit the default.htm and index.html  (I recommend making a backup copy before editing).

And yes, you are correct: you need the change both in Configuration and in the web folders.  There are no other places to make an appropriate change.

[Rutulian]

Hi Jeff,

2 little notes to add:

I'd always apply fixpacks in date order, and if you have a newer 'secondary product' fixpack than your core BI fixpack, apply it even to your BI-only machines.  This is because there could be changes to core behaviours made by EP/Controller/whichever.  It's rare, but once in a blue moon you get some misbehaviour because all the EP machines are running a newer version of the dispatcher than the BI-only ones.

The index.htm change is required on the gateway(s) and the gateway(s) alone - the reason cognos config doesn't come into play is because these files are where the browser looks when first accessing the gateway.  The request is still in Web Server land at this point, none of the fancy cognos business gets involved until it hits either the .cgi or the .dll (or the mod2, if you need more pain in your life).  Yours is working, but in future upgrades you might also want to check permissions on the file - WinServer2003 and earlier are nice and easy, but I _think_ when the files are replaced in a WinServer2008 install you need to jump through all the annoying hoops in IIS to make the .dll executable again.

Cheers, R

[jeffowentn]

Rutulian,

Thank you for the feedback.  We did the order of the FP installs based on what Cognos instructed us to do.  I logged a ticket with them since there was basically no documentation on the Planning side, and certainly none for environments that use both BI and EP.  Now, we will have more feedback in Cognoise for future reference.