who installed your system 9? did you get any documentation?

Beware of who's performing your install of hyperion system 9.

I have a client that has just been swindled by paying for 3 full days of install time for an infrastructure person from a hyperion preferred partner, yet got no documentation. There was material deemed as confidential or proprietary to the firm.

I know for a fact that some config files were changed and also that scripts were run on the sql server side. These scripts created some tables and user id's. These are items that would have been performed during the hyperion installs but these guys chose to write their own scripts. Their install could not be reproduced by the client (me) since these steps and scripts were not provided when asked for.

Due to the fact that no documentation will be forthcoming, the servers are going to be reimaged and I'll perform the installs myself fully documenting all server settings required to get everything up and running.

The environments need to be reimaged for 2 reasons. Our dev environment is coming online and this firm was not going to be used to stage that environment. This would then mean that our 2 environments were not installed in the same manner. There would be inherit differences between them. Future applications of patches would not yield the appropriate comfort level that a patch that worked in dev would also work in production without issue.

Apparently an important discussion to have with your hyperion preferred partner (really any consultant or consulting firm) is:

"Will we get full documentation as to how / what is installed on our servers?"

"Anything that is run on our servers is our (clients) property."

"There will be no running of scripts on our servers that we will not receive."

thoughts or modifications?

I was thinking something short and sweet. Not too much legal stuff to require lawyers.


hj

hyperion system 9.3 patch 1- license server is dead

~July 27 release date.

Before performing any installs / upgrades make sure you take into account the death of the license server. I think anyone who's done any backend Hyperion installs has grown to loathe this tool. It can take weeks to get this configured only to find out you're missing a feature you paid for.

It looks like IE7 is going to make it into this patch level.

hj

hyperion system 9 = enterprise essbase

The good old days of essbase, where you could install, configure, build, test, UAT and implement in 4-6 weeks are long gone with system 9.

The amount of involvement of IT for essbase implementations used to be limited to:

-acquiring a windows server
-provide a daily feed from the ledger
-backing up the server

All too many companies are currently operating under this assumption. It turns out that the backups are worthless 30% of the time anyway based on my experiences (don't forget to stop the service to backup essbase....)

So, while this is a bad situation, companies can get by and get their daily reporting completed.

Now, the new world order with System 9 is that things are much more complicated.

IT is going to have to be involved during the install. The architecture of System 9 essbase is much more complex. There are numerous services (~6-8) that must all be running for even 1 user to be able to log into essbase. The security now leverages the authentication provider of your company (ldap or active directory). This means that when an employee gets terminated they will no longer be able to get into hyperion systems automatically. This make the security auditors smile.

Backups, instead of an afterthought, are now a critical item on the task list. There are additional items that must be backed up correctly other then just the app folder. The penalty for non-compliance is not just losing the data in the cube, it's actually losing all security settings for the entire hyperion environment. This means that no one can log into anything hyperion, not even the excel addin. I've already heard a few stories about clients that didn't have their open ldap backed up and experienced an outtage. Security had to be rebuilt from scratch. This is no small feat given that now security for all hyperion products is managed from one console. So if you had 50 users all getting into essbase, analyzer, and reports you'd have quite a lot of work ahead of you. If you follow the recommended backup process then this should not be an issue but given that hyperion is typically a system that IT wants no part of, extra care should be taken to ensure that the backups are taken correctly and are in fact usable.

Dependencies on the startup of the numerous services. If the services get started in the wrong order no one will be able to log in. This means a special script is going to need to be used when stopping and starting the server and that IT is going to have to kick this off to bounce the server. Given the frequency of microsoft patches and the number of people involved in bouncing servers, does anyone this this will get overlooked?

As with any computer system, if the backup procedures are implemented there should be minor pains felt when such instances do occur. Don't get me wrong, as hyperion moves their products more into the enterprise wide environment these changes are necessary and welcomed.

consulting story:

(

On a recent project I was in charge of security for a hyperion portal that utilized performance suite, essbase, analyzer, and reports. This was on pre-system 9 software. The security hoops to get 1 new user into the new system was mind numbing. Each product had it's own security to maintain. The products for this 500 user system were the following:
-essbase - 65 security filter groups on 6 applications
-reports - 8 security groups
-analyzer - 8 security groups
-performance suite - 15 security groups

So a production transmittal to add 500 users to the system was huge. Not to mention the steps that the help desk had to go through in order to add 1 new user to the system. While each tool had it's own list of users that were scripted, some tasks, like the user assignment to groups in reports could not be automated. The analyzer bulk load (in 7.x) was not the easiest to get working as it was pure java and we didn't have a java coder just lying around. To be expedient, we ended up maintaining the performance suite by hand.

)

This is one example of why system 9 is good for us (us being consultants and customers, especially the help desk) I know there are a whole lot of nasty/messy upgrades out there just waiting to be done and some sleepless nights for some lucky consultants.

It still makes one think about the good old days when our worries were only:
-is essbase up (we'd run it in the foreground to see what's going on)
-keeping track of the latest excel/vba code for your user interface

moving essbase system pag and ind files off of a drive

I have come across many occasions where the essbase system files have to be moved off of one drive onto another.

Some instances are:

• The typical situation is where you need more drive space on your server and additional drives have been purchased. To get to use these new drives the old drives will have to go away.
• SAN configuration- for some reason they need to get your data off and onto a new drive share.

While there are cases where IT claims they can do this for you this is a task you can handle yourself (assuming your a designer for the app in question). I've seen more than once where someone thought they could do something with the SAN but when it came time to doing it, things didn't quite work out so rosy.

The steps are below:

1. go into the database settings and remove the drive spanning settings for the drive you want to move the data from
2. perform an application stop
3. perform an application start
4. go back into the database settings screen and add drive spanning for the drive you want to move the data to
5. initiate a dense restructure. One way of doing this is by adding or taking away a member of a dense dimension then save and keep all data. (warning: dense restructures can tie up the server for an extended period of time depending on how large the page file is)

This is also illustrated via a screencam movie at

http://www.john-assoc.com/2000_Cams/Remove%20Spanned%20Drive%20from%20Essbase.html