OBIEE 11G – Important Security Considerations (SSL) if using external LoadBalancer

In OBIEE enterprise topology, make sure the external load balancer used should be able to terminate SSL requests at the load balancer and forward traffic to the back-end real servers using the equivalent non-SSL protocol (for example, HTTPS to HTTP).

For security purposes, and because the load balancer terminates SSL requests (Oracle HTTP Server routes the requests as non-SSL to WebLogic Server), after SSL is configured for the load balancer, turn on the WebLogic Plugin Enabled flag for the domain. To do this, follow these steps:

1. Log in to the Administration Console.
2. Click the domain name in the navigation tree on the left.
3. Click the Web Applications tab.
4. In the Change Center, click Lock & Edit.
5. Select WebLogic Plugin Enabled.
6. Click Save, then click Activate Changes.
7. Restart the Administration Server and Managed Server.

Tip: WebLogic Plugin Enabled: Specifies whether or not the proprietary WL-Proxy-Client-IP header should be honored. (This is needed only when WebLogic plugins are configured.)

In additon to above, make sure Oracle HTTP Server (OHS) to add the following SSL directives in each <location> section to the ORACLE_BASE/admin/instance_name/config/OHS/component_name/mod_wl_ohs.conf file:

WLProxySSL ON

WLProxySSLPassThrough ON

Tips: Set WLProxySSL parameter to ON to maintain SSL communication between the plug-in and WebLogic Server when the following conditions exist:

An HTTP client request specifies the HTTPS protocol
The request is passed through one or more proxy servers (including the WebLogic Server proxy plug-ins)
The connection between the plug-in and WebLogic Server uses the HTTP protocol
When WLProxySSL is set to ON, the location header returned to the client from WebLogic Server specifies the HTTPS protocol.

Reference: https://blogs.oracle.com/pa/entry/obiee_11_1_1_important1

Thanks,
Shiva

 

IS OBIEE 11G/FMW supported on VMware?

Virtualization or Raw Metal?

(Orginal link: http://blogs.oracle.com/proactivesupportEPM/entry/virtualization_or_raw_metal)

With the growing number of customers who want to run the Oracles EPM/BI (or other Fusion Middleware Software) in a virtualized environment, we face a growing number of people asking if running Oracle Software within VMware is supported or not.

Two KM articles reflect Oracles policy towards the use of VMware:
249212.1 and
1063937.1.

The bottom line is: “you may use it at your own risk, but Oracle does not recommend it”.

So far we have seen few problems with the use of VMware (other than performance and the usual limitations) but Oracle does not certify its software for the use in VMware (and specifically for RAC Software actively refuses any support) and any issue that may occur will be fixed for the native OS only.

It is on the customer to prove that the issue is NOT due to VMware in case that an issue is encountered.

See: “Oracle Fusion Middleware Supported System Configurations page”

And also

“Supported Virtualization and Partitioning Technologies for Oracle Fusion Middleware”

Thanks,
Shiva

 

How to increase slider value limit in OBIEE 11.1.1.5?

By default OBIEE 11G has slider value limit of 50. But most of the cases we got to change this setting to 100 or more(at least in my case). To change the default set limit, update your instanceconfig.xml file as explained below.

1. Open Instanceconfig.xml file from the location <MW_HOME>\instances\instance1\config\OracleBIPresentationServicesComponent\coreapplication_obips1
2. Make a backup copy of this file before making any changes as you may risk not being able to start BI service
3. Add the following parameters

<Charts>
<SectionSliderDefault>5</SectionSliderDefault>
<SectionSliderLimit>100</SectionSliderLimit>
</Charts>

4. Restart all BI services either from EM or using commands
<MW_HOME>\instances\instance1\bin\opmnctl stopall
<MW_HOME>\instances\instance1\bin\opmnctl startall.

For more information refer http://docs.oracle.com/cd/E14571_01/bi.1111/e10541/prescatadmin.htm. It covers many more parameters, that may be needed to do other, additional customizations, too.

 

Thanks,
Shiva

 

RCU Schema Configuration failed with the error “The specified prefix already exists”

We all know that we need to create RCU schemas before starting OBIEE 11G (In fact, for any Fusion Middleware application) Installation. Because it is the base store for FMW.

Recently I came across a scenario where my customer created RCU schemas with Oracle Repository Creation Utility (RCU) version 11.1.1.3.0 and Installed OBIEE 11.1.1.3.0. Now after new OBIEE 11.1.1.5.0 release he wants to upgrade his application from 11.1.1.3.0. But he is not interested at the In-place upgrade. So we uninstalled weblogic and OBIEE 11.1.1.3.0 and started RCU 11.1.1.3.0 to drop the _BIPLATFORM and _MDS schemas.

The RCU shown up with successful message and so we thought everything is cleaned up and it’s good to create schemas again. I started RCU 11.1.1.5.0 and selected Oracle Business Intelligence component and given prefix as DEV. But am not able to assign this prefix and got a message like “The specified prefix already exists”.  Though I got successful dropped schemas message, just for cross check I looked at database for the DEV_BIPLATFORM and DEV_MDS schemas. There I am not seeing any of them.

Then I checked at dropped schemas log generated by RCU and realized that there is an entry in System.SCHEMA_VERSION_REGISTRY$ table which is stopping me to assign the same DEV prefix which we used for earlier version schemas.

Actually the RCU should drop schemas using mdsschemamanager.pl script. This script has capability to do cascade delete and will delete entries in System.SCHEMA_VERSION_REGISTRY$ table.

To make sure this log into RCU DATABASE as sys and run the following SQL Query:

Select * from System.SCHEMA_VERSION_REGISTRY$;

If this query returns any record then it means the RCU didn’t drop the schemas properly.

Actually what happened in this case is the RCU schemas were not dropped using mdsschemamanager.pl script, it’s just dropped with normal schema delete and the resulting repository record for the schema is not clean. Keep in mind, this is just in case if you want to use same prefix. Otherwise RCU will let you proceed to create new prefixed Schemas.

If the RCU schemas have been deleted incorrectly using the RCU drop user command, then We need to clean these entries before starting new repository schemas creation.

To do this, run the following SQL*Plus command as sys to complete the removal of the RCU schemas records in the repository database:

delete from System.SCHEMA_VERSION_REGISTRY$;

Once you confirmed there are no entries in System.SCHEMA_VERSION_REGISTRY$  table and start the RCU to create repository schemas with the prefix (DEV in my case). The RCU will go smooth and wont complain with any error.

Hope this helps you in your RCU issues troubleshooting.

 

Thanks,

Shiva