BACKUP STRATEGY
Before doing the patch upgrade on the server, all necessary files and DataBase backups should been taken as a security measure.
1. Database Backup
DataBase Administrator(DBA), who is administering the database, on which the BO server is mounted, can take backups of CMS DB, Audit DB and Mobile DB. This is called cold backups as all the BO servers should be down while taking these backups.
2. File Repository Backup
Backup of Input File Repository and Output File Repository can be done from respective file locations. Location can be found out from CMC. CMC-> Servers-> Properties of Input File Repository and Output File Repository servers. Uaually these would be as given below:
(E:\FileStore\Input) and (E:\FileStore\Output).
3. Windows AD Authentication Backup
This is one of the main area need to be taken care of while applying the patch. Configuration files like krb5.ini and bscLogin files backup need to be taken. These files are located at D:/Bi Platform/WinAD folder.
The snapshot of Windows AD authentication properties from CMC can be taken and kept for reference. As in cases,the authentication drop down may be missing after installation, it can be retained by backing up all the files Tomcat custom folder. Usually the location is like D:/Bi Platform/Tomcat6/webapps/BOE/WEB-INF/config/custom.
Screenshot of Java options from Tomcat Configuration also can be kept for reference.
4. Trending DB Backup
Trending DB backup can be taken from TrendingDB folder. Usual location will be D:\BI Platform\SAP BusinessObjects Enterprise XI 4.0\Data\TrendingDB.
5. LCM Bair Backup
All objects can be retained by LCM Bair backup and it is a recommended backup strategy.
INSTALLATION PRE-REQUISITES
- Make sure to Turn OFF ALL servers Except the most essential servers such as CMS, File repository servers (FRS) and if applicable Tomcat and CMS Database.
- Ensure that ALL non-essential processes are DOWN by running process explorer (or task manager with the command line showing by selecting it in view | select columns) after stopping them. The path is needed as many of the processes are named java.exe so one can look at the command line and kill those processes which are running in the Business Objects directories.
- Still see any BI 4.0 platform related process or sub processes besides CMS, Input FRS and Output FRS, Terminate them within process explorer (Eg. Crystalras.exe, Java.exe etc)
(this doesn’t include Tomcat and the CMS database processes bundled with BI Platform)
Ensure that all JAVA processes (java.exe) associated with the BI Platform are down. If not, terminate them using the process explorer.
NOTE: This will ensure that there won’t be any issues with missing libraries which is primarily caused by the java processes locking up files causing them to be updated or deleted.
This is an issue due to JVM locking which has been identified in Windows deployments and is scheduled to be fixed in BI Platform Support Pack 05 (SP05).
- PATCH UPDATE ON CLIENT – While installing patch on client, it is recommended to stop Tomcat server and SIA. Thus installation will be fast and as well as while installation is in progress, Crystal and BO share some of the libraries, so if Crystal is trying to update any shared and the same is locked by any service will cause problem.
INSTALLATION STEPS
1. Run the installer.
2. Click next if the prerequisite check is succeeded.
3. Accept the terms and condition and proceed.
4. Provide the existing BI 4.0 CMS Logon details.
5. Click on Next to initiate the installation.
6. Click on finish and reboot the server.
POST INSTALLATION
- If SIA, Adaptive Processing server (APS), Crystal Cache and Xcelsius Cache server processes FAIL to start after applying the patch or behaviour stays the same despite recreating processes , SIA, (repair or ) uninstall and reinstall SP04then check the following:
- check the InstallData logs folder (Eg. D:/Bi Platform/SAP BusinessObjects/InstallData\logs\<install_timestamp>)
- Typically, you will find only 3 files in this folder (InstallManifest.sqllite, setupexe.log and setupengine.log)
- If you see any other log files such as InstallDU-*.log (eg: InstallDU-cvom.java-4.0-core-nu,14.0.4.738.log etc), this indicates that some files or libraries have not been installed properly
This issue is typically caused by the Report Application Server (RAS) performing processing while the update is being run, which causes it to fail to shut down one of its java child processes when requested. This results in a number of files being locked while the patch is being performed, and so binaries are missing when the patch has completed. It can be avoided by following the best practices around shutting down servers and inspecting the processes as listed at the beginning.
Also, we can Run a Repair on the BASE BI Platform 4.0 install by going to Control Panel > Programs > Programs and Features > SAP Business Objects BI Platform 4.0 > Uninstall/Change > REPAIR\\\\. Optionally, if possible, it is recommended to perform an uninstall and conduct a refreshed SP04 full build installation.
BI Launch pad is not loading properly after SP04 patch
Below are the options we can try to recover it:
1. Stop tomcat server, and clear everything from the folder D:/Bi Platform/Tomcat6/tomcat6/work/catalina/localhost and start tomcat server. Tomcat will take some time to come up the usual as it will recreate the Application Cache.
2. Eliminate the keytab entry in global.properties file at D:/Bi Platform/Tomcat6/webapps/BOE/WEB-INF/config/custom folder.
#idm.keytab=D:/BI Platform/WinAD/EGDEVCMS.keytab
(If the SSO is working from outside the DMZ it means that the external DNS is granting TGS ticket to the client for Kerberos authentication. But the internal DNS does not.It is created with AES encryption and uses the SID of the machine in the domain. By joining back the domain SID entry changed for the server in the Domain Database and keytab is not able to get the ticket granted in the Intranet.)
3. Increase Tomcat’s maxHttpHeaderSize
For Tomcat servers it is necessary to increase the default HTTP Header size in the server.xml. Kerberos login requests contain, amongst other things, group information. The more AD groups a user is a member of the larger the http header must be to accommodate the size of the kerberos packet. 16384 is usually large enough but if your mapped users are a member of many groups (50 or more AD groups) you may need to increase this size to 32768, 65536 or more (multiples of 16384).
NOTE: Make a backup copy of server.xml file prior to editing
D:/Bi Platform/Tomcat6/conf/server.xml
Previous entry: <Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" compression="on" />
New entry:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" compression="on" maxHttpHeaderSize="65536" />