Doing a full install for updating from BI4.0 to BI4.1/BI 4.1 to BI4.2? Think again...

[Matthew_Shaw]

There is much confusion within the market place around the correct update process for updating from BI4.0 to BI4.1, or from BI4.0 to BI4.2. or from BI 4.1 to BI 4.2. (any BI4.x to any BI4.x)

 

The situation is made worse by common misunderstandings resulting in huge amounts of unnecessary “update effort”. This is in addition to BI4 repositories becoming corrupt and all the pain of sorting that out.

 

Sadly there are two tiny, but pretty significant documentation “bugs” which exacerbate the confusion.

 

This blog will address these common misunderstandings. We’ll also talk about those very important documentation ‘bugs’. But first let’s start with how you should update from BI4.0 to BI4.1

 

 

BI4.0 to BI4.1/BI4.2 strongly recommended update process

 

The update to BI4.1 (or BI 4.2) from BI4.0 is the same process as applying a Support Pack. I.e. just apply the ‘patch’ software to update from BI4.0 to BI4.1. There is no need to install BI4.1 on a new machine, nor is there a need to move, or copy content from one repository to another. Indeed it’s vital that the CMS System Repository database is updated as part of the update process.

 

You can update from any version of BI4.0 to any Support Pack version on BI4.1 or BI4.2 directly. There is absolutely no need to go ‘via’ any particular version (unlike XI3 Service Pack updates). I’ve created KBA 1909881 note to explain in more detail. Updating from BI4.1 to BI4.2 is the same, just apply the Support Pack.

 

 

Misconception: To save disk space a full install is needed

 

Many organisations perform a full installation of the ‘next’ product version to avoid too much disk space being consumed. However a full installation is not needed to recover disk space consumed by installing Patches or Support Packs over and over again.

 

Older Patches and Support Packs can simply be uninstalled. Select the ‘older’ product version from ‘Programs and Features’ and select ‘uninstall’. The installer will very cleverly remove the old product from the cache saving disk space. How cool is that! Don’t remove the original base install as that will remove the entire product.

 

 

 

 

Misconception: Full install is needed for new features

 

Unfortunately the BI4.1 update, BI4.1 SP1 update and BI4.1 Patch update documentation will have you incorrectly believe this. The following sentences in those guides are not correct:

 

If you want to use of the expanded set of ERP Drivers available in this release, you will need to perform a full install.

 

And

 

You must do a full installation to get the new features

 

We’re sorry for the confusion and we’re busy correcting the guide for the next release.

 

When the update is applied, only the existing software components are updated. All new features for those existing components will be updated. Any new components available will not be installed. To install new components, simply modify the original base installation and select the new components to install. The patch installer even provides a friendly reminder to do just this at the end of the update.

 

The list of additional components between BI4.0 SP2 and BI4.1 SP1 is:

1. Servers – Platform Services – Sybase SQL Anywhere Database


2. Servers – Platform Services – RESTful Web Service


3. Servers – Platform Services – Insight to Action Service


4. Developer Tools – SAP BusinessObjects Semantic Layer Java SDK


5. Database Access – DataDirect ODBC


6. Database Access – SAP HANA


7. Database Access – SAPBW64


8. Database Access – SAPERP


9. Database Access – XML WebServices


10. Database Access – OData


11. Database Access – Hadoop HIVE


12. Database Access – dbase

The list of additional components between BI4.2 and BI4.2 SP5 is:

1. Administration Tools - Automation Framework


2. Administration Tools - Promotion Management Wizard


3. Database Access – CMS DB Driver

 

Tip!

 

If you’re connecting to BW using the ‘old’ UNV BAPI connectivity, then you’ll benefit from installing SAPBW64 for improved data retrieval performance. See KBA 1930558 for more details. This note also shows the user interface for modifying the original base installation and selecting new components.

 

 

Why is installing a ‘full’ install such a bad idea for updating?

 

Due to one or both of the above misconceptions, many organisations install a ‘full’ installation on another machine and then either ‘move’ the content to it, or they re-point the new ‘full’ installation to the ‘old’ existing repository.

There are two main reasons these workflows are such a bad idea:

 

 

1)     Misconception: Best way to move entire Repository content in one go, is with Promotion Management

 

 

Moving the complete content between two BI4 repositories in one go is not easy if you use the wrong tool. Many attempt to use Promotion Management but struggle since it’s simply not designed for this task.

 

Promotion Management is intended for a relatively small number of objects at a time since the primary use case for Promotion Management is to promote 'developed' content from Development into Test and then Production. The tool for example doesn’t promote the following because these items fall outside of that use-case:

• Users (that only have a 3rd party alias) and all their favourite/inbox content


• Setup of 3rd Party authentication


• Promotion Jobs themselves


• Authentication setup/settings


• Server group to server relationships


• Servers


• Tenants


• Applications (or application Settings)


• License Keys

 

These are already good reasons not to use Promotion Management since manual effort is required to ‘recreate all these’, additionally:

• Since Promotion Management is a web based tool when a large number of objects are defined within a Promotion Management Job ‘web timeouts’ occur creating or managing the job.


• The ‘Check_out’ folder used for the integration with the Version Management System requires a little planning. See KBA 1802390

 

For the overwhelming majority it’s quite unnecessary to perform a ‘full’ installation, but for those that do and need to move the complete contents between two repositories it’s actually so much easier if the correct method and tool is used: Copy the CMS Repository database and FRS file system and point the ‘other’ installation at the copied content. You need to be sure you’re using the same Operating System, ‘install path’ and exactly the same product version. For very thorough and detailed steps you can follow the instructions within the Administration Guide Chapter 14 “Copying your Business Intelligence platform deployment”. We’d prefer for you to use a firewall to stop the two installations from clustering with each other but if you can’t, use the workaround in KBA 1275068 with caution (I really don’t want to promote removing rows from the CMS database but it is a good workaround!)

 

There are plans to improve the performance for creating and importing Promotion Jobs containing a large number of objects in BI4.1 Support Pack 2. We’ll have more details on that nearer the time. The recommendation now and for the future, is to use the LCM command line interface to create and import large jobs, since there will be no web based timeouts. However the recommendation will remain that Promotion Management should not be used to copy the entire contents from one repository to another, or use it as a sole backup mechanism.

 

2)     Misconception: Repointing a newer Product Version to an older Repository version is valid

 

 

The best way to explain a commonly misunderstood workflow is by example: Let’s say you have installed BI 4.0 Support Pack 6 and all your content is held within it. You’ve installed BI 4.1 Support Pack 1 on a completely new machine which you want to ‘migrate’ content to. You then stop the BI4.0 machine (Step 1) and point the BI4.1 machine at the CMS database (and FRS file-store) the BI4.0 machine used to use (Step 2).

 

However this workflow is not supported and you’ll run in a whole manner of issues, including but not limited to:

 

• HTTP 500 and 'null' pointer exception when logging into Central Management Console for the first time


• CMS process does not start


• "?????? dummy ?????" placeholders appear within the User Interface rather than the correct name


• Missing Applications, Application Settings, Security rights, icons


• 'Old' Applications, Application Settings, Security rights do not work as expected and cause various errors.

 

Why? Because when you update to a new version (Minor or Support Pack level) you not only update the software on the disk, but you also update the repository with ‘default objects’ (called DFOs). These DFO’s define ‘object types’ such as a ‘folder’, ‘user’, ‘application’ and just about anything the BI Platform hosts. Many ‘got away’ with this workflow in XI3.1, but this only because there were hardly any new or updated ‘default objects’ introduced in Service Packs in XI3, unlike BI4.

 

I’ve created KBA 1882363 to explain this in more detail with resolutions.

 

 

 

Feel free to post your feedback here or via Twitter (@MattShaw_on_BI); I’d very much welcome questions/comments to ensure a smooth update to BI4.1/BI4.2

(This blog updated to additionally refer to BI4.2, since the same applies for an update to BI4.2 as it does for BI4.1)

[Matthew_Shaw]

HI Mark,

That's seems fine. But there's no need to really 'copy the DB and FRS'. They stay where they are. Its just that your new Linux install will connect to the existing CMS database and will create a new node(s). You should define a pair of Input/Output FRS servers on Linux pointing to the very same FRS file store.

So at one point in time, you'll see in the Central Management Console, both nodes on Windows and on Linux. You can then delete your old nodes (defined on the Windows machines)

Whilst you can (and should) build a 'parallel' installation for Linux, you won't be running two separate systems live from an end users point of view. There will be no 'delta' differences between the two systems, since you will only have 1 CMS database and 1 FRS file store, both of these will be used by both Windows and Linux.

Thus there's no need to 'move' content with UMT/BIAR files or anything else.

Makes sense?

Regards

Matthew

[former_member149175]

I think maybe a bit of both,

If we are delivering a new architecture into the organisation it will need to be validated and signed off. We would also need to DR test the new architecture in isolation to the current productive environment.

So...I think maybe we could try this

- Take a copy of CMS and FRS

-  Build Linux 4.1 SP2 pointing at copies above

-  UAT Test and DR Test (no impact on live Production)

-  Post completion of above then re-point Linux BI4.1 SP2 servers to Production CMS/FRS and create cluster as you mention previously

-  remove Windows servers from cluster

Sound feasible?

[Matthew_Shaw]

Hi Mark,

Yes that works for me.

(Just for others reading this: this approach works because the update to BI4.1SP5 is not part of this process. The update to BI4.1SP5 need to happen AFTER the process Mark has described. This is because the CMS database contents needs to go through the 'update'. You can't point a BI4.1 SP5 'installation' at a BI4.1 SP2 CMS database.)

Regards

Matthew

[ragove]

Hi Mark,

I read your "post" twice, but I never read all the long running "comments" before- after  I read the “comments” I find they are even more detailed, elegantly - it counts 104 after I reply you.  Only Mark Cooper comments about heterogeneous systems.

Throughout your post, I see you are focusing more towards copying the cms (for obvious reasons) and FRS, than running UMT/Promotion Management GUI or CLI (for FRS) which really helps getting rid of all complexities especially when it is big business with large amount of objects. 

Your approach of clustering was really an amazing idea - I never thought that cool way of approaching towards a cross-platform upgrade.  Also, super feasible approach by Mark Cooper helps really well. 

and when you say Mark's approach works - I have a query here, if Marks approach works that means he is copying the FRS from different Operating system - (Windows) then Mark will use the same copied FRS (folder), may be through WinScp tool etc. to dump it on DIFFERENT Operating system i.e. Linux and he is not using UMT/ Promotion Management GUI or CLI to copy the FRS (If I got it right, anybody can correct me here)

But when I read this link where I talk about Windows to Linux move I reach a paragraph which says the following:

“For the overwhelming majority it’s quite unnecessary to perform a ‘full’ installation, but for those that do and need to move the complete contents between two repositories it’s actually so much easier if the correct method and tool is used: Copy the CMS Repository database and FRS file system and point the ‘other’ installation at the copied content. You need to be sure you’re using the SAME Operating System, ‘install path’ and exactly the same product version"

This was really my original doubt and maybe I should have re-framed my question - that's why I thought of asking your advice as I could test it but your reply could have helped me time wise.  I never tried copying the FRS of one type of OS and using the same FRS at another type of OS and the business requirement may not require the FRS to stay / be referenced with the old platform or OS. 

I would need clarity here as to how do you view copying FRS from a DIFFERENT Operating System, in case you had any chance doing this before?  What I think is - it should not impact because the FRS contains only folder and files which are BOBJ readable and the only dependency for BOBJ will be the path of the FRS.

If this question stays here, it helps readers too.

[Matthew_Shaw]

Hi Rahul, I think you meant to address me rather than Mark! 😉

Thanks for your comments. I hope these will answers will help:

If I got it right, anybody can correct me here

You have got it right.

I see where you're getting confused. You are confusing two quite different things. Lets start with that paragraph you mentioned I wrote:

“For the overwhelming majority it’s quite unnecessary to perform a ‘full’ installation, but for those that do and need to move the complete contents between two repositories it’s actually so much easier if the correct method and tool is used: Copy the CMS Repository database and FRS file system and point the ‘other’ installation at the copied content. You need to be sure you’re using the SAME Operating System, ‘install path’ and exactly the same product version"

This paragraph is referring to is when you are copying the whole system, kit and caboodle, so you end up with an exact copy.

Why is the same OS necessary: Because the CMS database contains 'servers' (really server definitions') and these are OS specific.

Why is the same 'install path' necessary: Because the server definitions and product install path is held within the CMS database.

Why is the same product version necessary: Because things called 'Default Objects' (DFO) are 'held' in the CMS database and they are upgraded (and new ones added) between product versions (major, minor, SP). If you like, this what makes a CMS database 'have' a version. Pointing a software installation of one version against a CMS database of another will cause issues.

Now, why is the above a different thing to switching the OS of the FRS?

Because you are not re-creating a 'node' (SIA) and all its servers. (If you where then you would need all the above things to remain the same: OS, install path, product version).

You are doing nothing more than adding a pair of FRS servers (Input and Output), it just so happens that the OS these FRS servers are using, is on a different OS than the existing (Windows) ones. This (Linux) pair of FRS servers could well be using a different FRS 'file path' than the Windows FRS pair, but so long as they point to the same place (or a full copy of), that's all that matters.

A file system can be access by both Windows and Unix/Linux, given the file system supports the required protocols. Thus the FRS file store contents themselves don't necessarily need to be moved anywhere (though for your organizations needs, it might).

Windows will communicate to the FRS file store using a different protocol compared to Linux/Unix (CIFS/NFS) but this is completely abstract to the BI Platform. The Input and Output FRS servers will use the Operating System they are 'on' to read/delete/write to a file, it is this part that is abstract to the BI Platform and is platform independent from that perspective.

I hope this helps.

You can 'like' a comment too! I forget myself that feature!

Regards Matthew

Twitter: @MattShaw_on_BI

[ragove]

Hi Matthew,

The clarification helps readers -  and yes I meant to address it to you.  Thank you m.cooper and matthew.shaw for your valuable inputs.

I have already rated, bookmarked, liked the post.  I will like the comment too ! 🙂

[Former Member]

Hi Matthew,

I'll make an upgrade of BO 4.0 SP7 patch 8 to 4.1 SP2. My question is: I have to install all the patches, one by one?

BO 4.1 SP 00 Patch 1

BO 4.1 SP 00 Patch 2

BO 4.1 SP 00 Patch 3

.

.

.

BO 4.1 SP 02 Patch 7

or I can just download the last an install?

Thanks

Oscar López

[Matthew_Shaw]

Hello Oscar

No. The KBA 1909881 I wrote perhaps isn't as clear as it could be? Do I need to make it clearer? I think I do!

All Support Packs are cumulative, meaning you only need to apply the last Support Pack (SP).

All Patches are cumulative, meaning you only need to apply the last Patch to a Support Pack.

For example if you're on BI4.0 SP1 and you want to go to BI 4.1 SP3, then you just apply the 'BI 4.1 SP3'. Once and only once you are on 'BI 4.1 SP3' can you apply any of the patches for 'BI 4.1 SP3'. (these will be patches called BI 4.1 Patch 3.1, Patch 3.2, Patch 3.3 etc...).

So for you, you apply 'BI 4.1 SP2', then apply Patch 2.7.

Let me know about the KBA as I'd like to make sure its as clear as we can make it.

Regards

Matthew

[Former Member]

Hello Mathew,

Thanks a lot, onother question I saw  news SP for 4.1 in the marketplace:

• SP03
• SP04

Do you recommend that install a SP newest?

Regards

Oscar

[Matthew_Shaw]

Hi Oscar,

Generally speaking yes, applying the latest and greatest Support Pack (SP) is a good idea, since it will contain all the latest code corrections and performance optimisations. However a different SP may require perhaps more testing that just applying a Patch to the existing SP level you are on.

Why? because we tend to add some new functionality into a Support Pack. A Patch is almost always just contains code corrections and nothing else. When new functionality is added (into a SP) sometimes this introduces new security commands, report calculation engine changes or other unforeseen "side effects". What we expect to change will appear in our release notes/what's new documentation, so do read those before applying the last SP 'blindly'. There's also good documentation around report calculation engine changes on the wiki at Calculation Engine Changes for Web Intelligence BI4 and XI3 - Business Intelligence (BusinessObjects...

Patches are provided by SAP on a regular 4 week basis for each Support Pack level. So if SP3 was first issues in March, then patch will be produced for about a year starting from March. Worth knowing this since if you need a code correction.

Regards, Matthew (Twitter: @MattShaw_on_BI)

[Former Member]

Thank you Matthew :smile:

[Former Member]

Hi Matthew,

With regard to the scenario for switching from windows to linux.

An important note in the admin guide:

"Note: While it is possible to use a mixture of Windows and Unix or Linux platforms, it is recommended that you do not mix operating systems for Central Management Server (CMS) processes."

Given the feedback, on which also Mark picked in:

"You could consider changing OS as just adding other servers into your cluster. It's just that those servers are running on a different OS and after a while (perhaps a very short time) you remove/delete your original servers on your original OS."

This makes sense for adding eg. (linux) processing tier servers.

But isn't this a problem for the CMS server?

At a certain moment a linux CMS needs to be activated, but you can only do this when a windows CMS is running (which conflicts with the above note from the admin guide)

What would be the scenario for switching over these processes?

Regards,

Raf

[Matthew_Shaw]

Hello Raf,

It's not a problem, but its a consideration that needs to be planned. (I mentioned this in an earlier comment, that you can't run the CMS on different OS's at the same time.)

So you can certainly have multiple CMSs within one cluster on different OS's, but you need to make sure they aren't running at the same time, or you might get some odd behaviour. Now there's a couple of workflows that you can follow:

Workflow A) You install the BI Platform and select 'expand the cluster' during the install. To prevent your new CMS from starting up, just de-select the check box "Start servers upon installation"

Workflow B) You install the BI Platform and select 'new install' and install with a new 'empty' repository. Once installed stop the product everywhere! Then create a new SIA to point to your existing CMS database and start it up. (don't re-create a SIA for this workflow) Trash the repository you used for the install as its no longer needed.

Now I've not tested these workflows myself but in principal I think they should be just fine. Why not report back your experience.

If you were to run 2 CMS process on 2 different OSs at the same time, my guess is, it would be ok for a short term 'fix', but something you wouldn't want to do permanently (either in development or production).

Hope this helps?

Regards

Matthew Twitter:@MattShaw_on_BI

[Former Member]

Hi Matthew,

To start of: very useful blog on an essential topic! Great work (also keeping up with the replies)!!!

Never tried to mix a CMS over OS's.

A CMS in any case is created "enabled" (only server which can't be disabled) and at a certain point in time - even if this is briefly - both CMS's will become running (become a cluster?).

If we would ever need support in case of issues here, I would expect a "not supported" to be a (highly?) potential response.

This brings me to the essence point of your blog (took the weekend to let it sink in). We also (as I understand many others) have (and are) working with repointing an "older" repository to a newer product version. Mark Cooper has listed strong arguments, in his initial reply, why this is so important (especially in a bigger setup).

If I understand you correctly, the only reason why this workflow is "not supported", are updates to the repository database (insert and update's of default objects - DFO's), right? The changes to the DB's data are done by the installation program(s).

Wouldn't it be possible to have this step, scripted separate from installation?

Do you see issues to applying this script to the repository before installing?

Next to "keeping" the repointing option, we also keep "full build" that way (also for major updates). Even assuming product installation is flawless, it just now and then "feels" good to start clean ...

Regards,

Raf

[Matthew_Shaw]

Thank you Raf

A CMS in any case is created "enabled" (only server which can't be disabled) and at a certain point in time - even if this is briefly - both CMS's will become running (become a cluster?).

If we would ever need support in case of issues here, I would expect a "not supported" to be a (highly?) potential response.

Whilst a CMS process can not be disabled, it can be stopped. The check box "Start servers upon installation" will simply not start the CMS once the install is complete. During install the CMS will need to start, to configure it as part of the cluster. But the product needs to do this. Don't worry about that. We've done this many times in house and have had no problem.

Whilst the documentation does say something like "You should not run CMS on different OS's at the same time" it should really read something like "You should avoid running CMS on different OS's at the same time where possible, however there are some configuration workflows that require this for a short period of time".

This brings me to the essence point of your blog (took the weekend to let it sink in). We also (as I understand many others) have (and are) working with repointing an "older" repository to a newer product version. Mark Cooper has listed strong arguments, in his initial reply, why this is so important (especially in a bigger setup).

If I understand you correctly, the only reason why this workflow is "not supported", are updates to the repository database (insert and update's of default objects - DFO's), right? The changes to the DB's data are done by the installation program(s).

You are 100% correct.

There are serious consequences if you have the wrong or different DFO's in the repository for the 'binaries' you have installed. The issues are many, various and widespread.

Wouldn't it be possible to have this step, scriptedseparate from installation?

Sadly not, though there are some aspects that are 'scripted' its very complicated and not 100% reliable. We are hoping for the BI Support Tool to be developed and show if there are any missing DFO's in the repository, since we see a lot of customers with many and various issues, with missing DFO's as the root cause.

Do you see issues to applying this script to the repository before installing?

Sorry no script to apply.

Next to "keeping" the repointing option, we also keep "full build" that way (also for major updates). Even assuming product installation is flawless, it just now and then "feels" good to start clean ...

Yes I understand the feeling and this would had been right for XI3.1 but not needed for BI4 as the installer has improved a lot. When you install with BI4 and apply an SP or Patch you're always using the latest and greatest installer, even if your base version was older. There's really no need to a full install anymore. You can uninstall intermediate product updates to save space. In fact with BI4 you're more likely to be more successful with the 'patch' installer compared to a full install. Strange, but true!

[Matthew_Shaw]

I will be on annual leave from 18th July until Monday 11th August - so feel free to post a comment but please also expect a delay in my reply until then.

I will delete this comment when I return (all relaxed ;-))

[torsten_wirth]

Hello Matthew,

Have a nice break / vacation!

I have a question concerning this passage:

Misconception: To save disk space a full install is needed

Many organisations perform a full installation of the ‘next’ product version to avoid too much disk space being consumed. However a full installation is not needed to recover disk space consumed by installing Patches or Support Packs over and over again.

Older Patches and Support Packs can simply be uninstalled. Select the ‘older’ product version from ‘Programs and Features’ and select ‘uninstall’. The installer will very cleverly remove the old product from the cache saving disk space. How cool is that! Don’t remove the original base install as that will remove the entire product

Up to now (we are coming from 4.0) we have installed all new upgrade versions without uninstalling the previous ones. Which results in a long history of installed versions. And it wastes some diskspace. I'm not sure if this is also a question of performance (e.g. time which is needed for installation of an upgrade).

One reason why we have done that is that all changes which are resulting in additional fields for entering parameters are potentionally lost after removing the upgrades. I'm not sure about that but I think that settings which are made in fields / tabs / windows which are removed during an uninstallation because the previous version didn't had them are lost (that's an experience which we made with AO Add in after uninstalling it the way you describe it above). That means that you have to know which settings you have made in which version or which settings are new / additional in which version because you have to do it again after uninstall the previous patch und install the latest patch. Which makes the list of settings which have to be restored from patch to patch longer every time you install an upgrade.

Furthermore we are a sceptical that we really get the same result after e.g. uninstalling 15 patches that we had at beginning (before installing this patches).

This is resulting from the experience that base version A + patch 1 + patch 2 + patch 3 was not the same result then base version A + patch 1 + patch 3. In the first case a function in version management was not working, in the second case the same function did work. That was the result of a suppurt ticket where we have adviced to uninstall the previous patch and install the latest instead of only install the latest patch.

Furthermore there are some bugs like "lost settings for audit database" from one patch to another where it's difficult to know what happens if you remove the latest version which brings you back to the version where the error occured.

All this results in the idea that it is maybe a good idea to doing a full install for every major version. But up to now we have not done it and we are not shure what amount of work this will be. What do you think about these experiences and concerns?

Regards,

Torsten

[former_member138263]

Dear Matthew,

You wrote:

Whilst the documentation does say something like "You should not run CMS on different OS's at the same time" it should really read something like "You should avoid running CMS on different OS's at the same time where possible, however there are some configuration workflows that require this for a short period of time".

I'm worried that people might think they can easily switch the OS of their CMS.

I'm afraid that's not the case because of several platform dependencies:

• SSO support might be showing different behaviour (mainly when using Windows AD)
• Native connectivity for SQL Server on Windows
• Printer support
• Custom fonts

Feel free to complete the above list. 😉

Basic message is that switching the repository will always cause some complications, even when the database wouldn't have DFO issues (which I very much regret).

Sorry no script to apply.

I don't understand why SAP is forcing us to apply a complete patch as an "all-in", instead of providing the necessary steps in separate blocks (updating database, installing software, deploying the webapps...). I prefer taking full ownership instead of depending on a hidden process...

In fact with BI4 you're more likely to be more successful with the

'patch' installer compared to a full install. Strange, but true!

I'm sorry, but my personal experience is different... I'm actually running 2 servers in a complete identical cluster. The original (first) machine has been patched (and upgraded the repository from 4.0.7 to 4.1.3), while the new (2nd) machine is based on a full build install. We rarely encounter issues on this new build, while the original machine is frequently causing problems. We're even considering a re-installation because of that.

Best regards,

Jo

[Former Member]

HI Matt,

Is it okay to do a in place upgrade from BO4.0 SP5 Patch6 to BI4.1 SP3 directly?

If not, please suggest the jump path.

Regards,

Prakhar T

[Henry_Banks]

Hi,

You need to check the forward fit rules : https://websmp110.sap-ag.de/~sapidb/011000358700001430852011   (see link to xls in the footer of this page)

The answer is YES - in place upgrade is safe. 1 step.  Because of this logic :

Fixes forward fitted to

release	contains fixes from
BI 4.0   Patch5.6	BI 4.0 Patch   5.1 - 5.5	BI 4.0   Patch6.1    BI 4.0 Support Pack 7    BI 4.1 Patch0.1    BI 4.1 Support Pack 1

Regards,

H

[Former Member]

HI Henry,

Thanks for the answer.

I did visited forward fit sheet and saw this, but not able to comprehend whether I have do:

BI4.0 SP5 Patch6 -> BI4.1 SP1 -> BI4.1 SP3

or

BI4.0 SP5 Patch6 -> BI4.1 SP3

[Because SP3 is cumulative and contains all fixes of SP2; and same with SP2 which will contain all fixes of SP1]

Apologies but I am getting a little confused here.

Regards,

Prakhar T

[Former Member]

Interesting and effective way of putting it!

Thanks for sharing Matthew.

[torsten_wirth]

If AP has not implemented it a really bad way. It should not be possible to do a wrong order because of check steps in the beginning of Installation process.

Regards,

Torsten

[Henry_Banks]

Hi,

as confirmed above, this is 1-step for you.

regards,

H

[pavan_k11]

Hi Prakhar,

You can update from  BI4.0 SP5 Patch6  to BI4.1 SP3. There is no need for SP01 and then SP03

[pavan_k11]

Hi  matthew.shaw

I would like to add following points:

1     We could always use Command line version of promotion management (LCM CLI)  as web version has issues.

2     "Copy data source" has a few prerequisites which might not b suitable for every project hence LCM CLI could be helpful here.

Cheers,

[pavan_k11]

Hi Prakhar,

You can take a look at this doc:

http://service.sap.com/~sapidb/011000358700000491852013E/sbo41_bip_update_en.pdf

[Former Member]

Thanks Pavan and Henry for confirmation.

I feel comfortable now :smile:

[Former Member]

This content is going to My Favourites.

Very well explained. Thanks.

[Former Member]

Thanks Matthew. Informative.

[Former Member]

Great article and certainly resolves some of the misconceptions in this sphere.  Thanks Matthew

[kevin_joyner]

What it comes down to for me is that there should be built-in functionality in SAPBO for backing up and restoring content (not to mention scheduling) or cloning servers.  In 3.1 you could clone servers but that went away with the import/export utility as it was replaced by a UMT/LCM and UMT doesn't work between 4.x versions.  It's a case of "you shouldn't get less functionality with an upgrade".  Sure there's the copy database/FRS and delete the servers method but that doesn't lend itself to a stable environment.  

Now with the latest revision the LCM command line is touted as the answer but the script provided in the latest administrator guide that says it does a "full environment copy" didn't work for me(I won't go so far as to say it doesn't work at all).   I ended up with half of the expected content.  When you check the support articles for the LCM method there are some sample queries but there's also the proviso in bright bold red that it is not support's job to write queries.  How can you say something is the answer and then not provide explicit documentation or a working script and then say support can't help? 

I know there's money to be made from folks interpreting the cryptic nature of querying the CMS database but when you are saying that LCM queries are necessary for what should be considered a core function of the product it should brought out of the shadows and fully documented with working scripts for various content moving scenarios, including a full system copy.  Also the LCM needs to be able allocate enough resources to handle 100,000+ objects.  I let one query run for a week before terminating it.  Even with 32GB of memory allocated it still lacks power.  With the -noversion_check the UMT can export the whole environment to biar files in a few hours (even though they error on import), the tool that SAP wants us to use needs to have that power.

It shouldn't take me weeks to clone a 300GB SAPBO environemnt when the database guys can clone their 6TB database server in a two days.  

Sorry for the /rant but it's a tad bit frustrating.

[Former Member]

Kevin,

There is the functionality provided by using the noversioncheck command line at startup.  Certainly comes in handy.

Regards,

Steph

[kevin_joyner]

Thanks, yes I did try this.  I was able to get the biar files to export.  However on import it errors out with an odd error about expecting a value but receiving a string.   It appears the UMT is limited on what it can move.   As it's unsupported I don't expect much help but it would be nice if it became supported.

[Former Member]

Hi Kevin,

If you can provide details of the error I can hopefully assist.  Due to the limitations of LCM we have employed various workflows to manage this.  Failing that email me the details and we can take this offline.

Steph

[Former Member]

I agree and i had experienced it with no version check parameter only.

[Former Member]

Currently we are BI4.0 SP7 Patch 11.

Can we perform in place upgrade directly to BI4.1 SP5 with software available at download section of “Support Packages and Patches”  in SAP Support Portal?

If No then please let us know either we should go with BI4.1 SP4 or BI4.1 SP3.

I tried to look forward fit rules excel document but it has no information about BI4.1 SP5.

-Thanks,

  Deepu.

[vamshidharmitta]

Hi,

No need to install Bi 4.1 SP04 or SP03. You can directly go for BI 4.1 SP05. Try it on a test machine and before proceeding take necessary backups.

For more information on the upgrade refer:

Update workflow - Business Intelligence (BusinessObjects) - SCN Wiki

It covers update of SAP BusinessObjects BI 4.0 SP04 environment into SAP BusinessObjects BI 4.1 SP04.

Thanks,

Vamshidhar

[Former Member]

Thank you

Is there any other document like Forward fit rules document which explains that BI 4.1 SP5 has all fixes forwarded from BI 4.0 SP7 ?

-Thanks,

  Deepu.

[vamshidharmitta]

Hi,

Please refer to below link.

https://websmp108.sap-ag.de/~sapidb/011000358700001430852011

Also refer to below screen shot for the excelsheet link. Highlighted at the bottom of the image.

[Former Member]

Thanks once again

I already went through it as I specified on my first post ("forward fit rules excel document ") . I was looking for other document like Forward fit rules document.

However now I realized that it has BI4.1 SP5 Information.

Contains Fixes From: "BI 4.0 Patch 7.10 - 7.11" and Fixes Forward Fitted To: "BI 4.1 Support Pack 5 (scheduled)".

Now I feel more confident to upgrade from BI 4.0 SP7 Patch 11 to BI 4.1 SP5.

Thank you

[torsten_wirth]

I think the official SAP statement is:

Note: The forward information will no longer be maintained in this document for releases that are released after July 18 2014.

Please refer to the issue SAP notes for their associated forward fit information. 

Which means you have to check every single note if it is included or not.

[Former Member]

Hello Matthew,

Thanks for the great article.

I followed the article and upgraded from SAP BO 4.0 sp6 to SAP BO 4.1 Sp5 patch 2. To do this, I installed the 4.1 sp5 update followed by sp5 patch 2 on the same machine where I have 4.0 sp6. I have not uninstalled the older 4.0 version yet.

I see a number of issues after I did the upgrade.

* The log off seems to be broke for BI Launchpad. If I click it, it does nothing.

* I cannot run any WebI documents in BI Launchpad.

-- When I look at the services in CMC:

-- the connectionserver32 does not run

--  if I try to change the property of any server, it comes back with an error: http status 500 - javax.servlet.servletexception: java.lang.null pointer exception while trying to invoke the method....................

........apache tomcat/7.0

I did not have any errors during the install. Have I overlooked something or does 4.1 Sp5 Patch 2 have all the issues/did I make a mistake in going for the very latest SP/Patch?

Thanks!

[Henry_Banks]

Hi sounds like you might need to redeploy your web apps, also is your license key ok? 

IMO the best route for this enquiry would be via technical support helpdesk

regards,

H

[Former Member]

Thank you. The license key is same as what was used for 4.0. Shouldn't that hold good? I am able to login tin BI Launchpad, CMC etc and see everything and it does tell me I have a certain number of NUL and CC which is same as before.

I will try the redeploy webapps

[Former Member]

I have a strange issue now. Once I upgraded to 4.1 SP5 Patch 2, the html mode for view/modify does not work. Just gives a blank page. If I set the view and modify to applet, it works fine and I can view/run/edit reports.

Have any of you who upgraded from 4.0 to 4.1 sp5 by doing an in place install seen this? I have tested in both IE and chrome and have the same issue. Any suggestions?

I did not have this issue on another server where I had 4.1 Sp3 and installed Sp5. So I assume the html issue would not be a bug in 4.1 Sp5.

[Former Member]

We didn't faced such issues in different upgrade approaches viz:

1. BI4.0 SP05 to BI4.1 SP03

2. BI4.0 SP05 to BI4.1 SP05

3. BI4.1 SP03 to BI4.1 SP05 Patch2

4. BI4.1 SP05 to BI4.1 SP05 Patch2

As Henry B suggested above you would need to redeploy webapps.

In case, that doesn't fix your problems; verify if the other working system (which you upgraded from 4.1 SP03 to SP05) is also on SP05 Patch2. if it is copy the war files from that server; deploy them in problematic server; modify xml and properties for webapp to show correct system names on login screens.

Good luck.

[jino_jose]

Hi Matthew,

Thanks for the great article.

We have upgraded from  BI 4.0 SP2  to BI 4.1 SP5, we faced below issue on Webi.

In the existing report the mandatory prompts from Bex are populated with values are disabled using the set variable option on Webi query panel. After migration we noticed, the set variable are not hidden on the initial refresh, but the subsequent refresh the set variable got hidden. I understand this is due to the difference on the workflow followed for the  Bex -> Webi between 4.0 & 4.1. The first refresh creates the transient universe then the set variables are enabled.

Is there any option/tool to update the Webi document metadata in one shot along with the upgrade.

Thanks,

Jino.

[Former Member]

good information. need you inputs on below queries

1) We have the BI 4.0 SP9 clustered set up on AIX server. There are 2 nodes - one per server. Each server is BOBJ full install. The repository and audit database is default sql anywhere 12 and resides on first server. Now we would like to change the default database to oracle and also would like to upgrade to latest 4.1 version. Please provide your recommendation on which one should be taken first.

2) also could you please elaborate on "To install new components, simply modify the original base installation and select the new components to install. "

[Matthew_Shaw]

Hello Kiran

A1) To change your CMS database from one vendor to another then you need to use tool cmsdbsetup.sh. Please see section 27.1.1.2 of the BIP Admin Guide.

You need to use the option "Copy data from another data source".

A note for others: if you're changing operating system for the database that is hosting your CMS/audit db, but you are keeping the 'vendor' the same, then there is NO need to use this cmsdbsetup.sh. Instead, just backup/restore the databases using native database tools. As Kiran is changing database vendor then this tool is necessary as there's no easy way to move the content from one database vendor to another (well unless you buy some nice tool). So this tool 'cmsdbsetup.sh' will copy each object one by one and it typically slow as it does it one by one. But there's no other way.

You need to do the CMS database move either before or after your upgrade. Don't forget to backup!

A2) sure. Please see section 6.7.1 of the sbo41_bip_install_unix_en.pdf. Where it says 'language' it also really should say 'language and other components that were not part of the original base install':

To modify SAP BusinessObjects Business Intelligence platform These instructions describe the process to modify your SAP BusinessObjects Business Intelligence (BI) platform installation by adding or removing installed features.

It is recommended that you back up the CMS system database before modifying the BI platform.

Note:

The CMS must be running in order to modify an installation.

1. Change directory to the <BIP_INSTALL_DIR> folder.

2. Run the command:

./modifyOrRemoveProducts.sh

Note:

Log files, configuration files for web applications, and web applications will not be removed by the removal program. Folders left after removing a corresponding feature can be removed manually later with the rm command.

3. Select the installation to be modified.

4. Select Modify.

5. On the "Select Language Packs" page, select any languages you want to install; unselect any languages you want to remove. Click Next to continue.

6. Ensure that all features you want available are selected. Ensure that features you do not want installed are deselected.

Expand the highlighted feature in the selection tree by pressing the keyboard spacebar. Use the arrow keys to navigate up or down. Toggle feature selections with the X key.

When you are satisfied with the selected features, press Enter.

7. If you are modifying a server with a CMS installed, press Enter to apply the changes. If you are modifying a server that uses a remotely installed CMS, enter the hostname, port, and an administrative account username and password.

8. When the changes have been made, press Enter to return to the command-line.

The installation has been updated.

Regards

Matthew