OBIEE 12c - RCU - Create Repository

There are a few dependencies when running the OBIEE 12c RCU, one of which is that the database must be at least 11.2.0.4.

After that the next thing you notice after starting the RCU is the options available.

You now have the ability to generate the RCU scripts and pass them on to a DBA to run in seperately, rather than beg for admin access, organise meetings etc... just to run the RCU.

If you have the permissions already then nothing has changed and the top option System Load and Product Load is for you.

The remaining two options are to generate scripts and then load in the product information

• Select Prepare Scripts for System Load if you are unable to provide login credentials for a user with DBA privileges. RCU will create the necessary SQL scripts for creating the component schema and also update schema_version_registry entry for selected components and change the status to "LOADED." Once the scripts are generated, another user with DBA privileges can run the scripts using SQL*Plus to complete the system load phase. 
• Select Perform Product Load only after the system load phase scripts have been run to update the schema_version_registry and set the status to "VALID." Users with non-DBA privileges are able to select and execute this option. During the system load phase, some components will generate an additional post-data load script that requires DBA permissions. These scripts will also be run during the product load phase.

This means that the DBA gets to keep control, and you get your repository without ruffling too many feathers.

OBIEE Lockdown - Part 1

Security Recommendations in Oracle Business Intelligence Installations

There are three key security recommendations for installing and securing OBIEE in your enterprise environment.

1.       Be serious about password management.

It is important to lock down the OBIEE environment and changing default passwords after installation.

The passwords for weblogic user should not be simple to guess or widely distributed. The best practice is to have different passwords throughout the environments. Moreover, I’d recommend replacing “weblogic user” with another obfuscated username. The username and password combination should be different throughout the environments (at least the password).

Change the default passwords for the RPD, as everyone knows “Admin123.”  If you are promoting an RPD, your password for Dev, Test, and Prod RPDs should be different as well to avoid a possibility of a developer making changes in a wrong environment.

Do not use the administrative account to present reports to the users and avoid providing it to users, there is high risk of breaking/deleting something by accident. Consider automating deployments to avoid having to deal with passwords manually.

2.       Take the authentication and authorization outside of OBIEE

Use whatever is standard in your organization for managing authentication (be it OID, Active Directory, or some other sort of LDAP). Not only does it improve user experience by removing the need to memorize yet another username/password, but it also saves time for the development team. Remember: They are not in the user management business. Another great use case is the ability to push this functionality further by automating users’ authorization by managing LDAP groups’ memberships and mapping them to the OBIEE’s application roles.

3.       RPD Security Objects

Unfortunately, the Administration Tool does not allow development separation within the repository objects (one needs to be an administrator to edit the RPD file – no way around it), hence anyone with the RPD/Admin password can do pretty much anything within the RPD. At this time, there are limited built-in options to audit or keep track of the RPD development changes. One must rely on a custom developed solution if this functionality is important. An easy and practical option is to keep an XLS spreadsheet of the major development milestones. It’s simple; however, its disadvantage is, that there is an overhead associated with maintaining it, especially during active development periods. Another option would be to use an Administration tool utility to create metadata repository document on a regular basis and track deltas. Finally, more advanced options would include MUDE (multi user development environment) projects and XML export.

Validating the Catalog

Over time, inconsistencies can develop in the catalog as links are broken, users are deleted, or NFS file system issues are encountered. These inconsistencies can eventually lead to incorrect behavior, such as the inability to edit an agent's recipient list. You can periodically take the production system offline and validate the catalog, to be informed of and to take corrective action on inconsistencies.

Tasks in the Validation Process

The validation process performs the following tasks:

• Ensures that each object in the catalog is larger than zero bytes.
• Ensures that each item in the catalog has a valid corresponding .atr file.
• Ensures that each link in the catalog is valid.
• Ensures that the files in the account cache are valid.
• Ensures that all XML objects in the catalog pass schema validation.
• Attempts to repair object names that were damaged by ftp programs.

 Important Guidelines for Validating the Catalog

Before you validate the catalog, keep the following guidelines in mind:

• You must refresh the user GUIDs before validating the catalog. If you attempt to validate a catalog whose user GUIDs are not synchronized, then the validation process assumes that all accounts have been deleted and effectively removes all account information from the catalog.
• Use care when validating a catalog in a development environment, if that environment has a different security store from the production environment. If the validation is performed with a different security store, then many accounts might be removed from the catalog.
• When you turn on any validation of the catalog, all ACLs (that is, all privileges and every item's permissions) are "scrubbed," which means that dead accounts are removed from them and any changed items are written to disk. Therefore, even if you simply create a report without fixing any broken items automatically, you might find that the catalog is still extensively "changed."
• Before validating the catalog in a clustered environment, do one of the following:
• Shut down the Presentation Services cluster and run the validation directly against the cluster's catalog.
• Make a copy of the cluster's catalog and run the validation against that copy.
• Before using the 7-Zip utility to make a copy of a catalog, first shut down all nodes in the Presentation Services cluster or put all nodes in that cluster into Maintenance Mode (which is the recommended approach).
• Be aware that any changes that are made to the catalog online concurrently to the validation process are not included in the validation.

While backing up the catalog is always good practice, there is no practical difference between running validate against the catalog directly versus running the validation on a backup copy.

11G authentication failure - Validate Catalog

When you move repositories between machines and copy the catalog it is possible that there will be conflicting permissions between the details in the catalog and details held in weblogic.

I have previously mentioned how to reset the GUIDS - the glue between weblogic authentication and the catalog.

Sometimes this is not enough - usually when you find that have no permission to change settings on your My Dashboard or you cannot change settings in My Account.

A light touch 'refresh' may be something like:
If you add the following to your instanceconfig.xml file
<Validate>OnStartup</Validate>
<ValidateItems>None</ValidateItems>
<ValidateLinks>None</
ValidateLinks>
<ValidateAccounts>Clean</ValidateAccounts>
<ValidateHomes>None</ValidateHomes>
and open a command line in ../instances/instance1/bin
you can use opmnctl to stop and start the services. This may take some time depending on the size of your catalog.
Remove the Validate section from your instanceconfig.xml and stop/start opmnctl.

To force a 'deep clean' you can opt for something like:

<ps:Validate>OnStartupAndExit</ps:Validate>

<ps:ValidateAccounts>Clean</ps:ValidateAccounts>

<ps:ValidateHomes>Report</ps:ValidateHomes>

<ps:ValidateItems>Clean</ps:ValidateItems>

<ps:ValidateLinks>Clean</ps:ValidateLinks>

As always the documentation is available here from Oracle.