| Oracle® Beehive 2.0.1.4.0 Cumulative Patch Set Readme For Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0) (All Platforms) |
|
2.0.1.4.0 Cumulative Patch Set Readme
For Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0) (All Platforms)
September 2010
Readme updated October 8, 2010
This Readme accompanies 2.0.1.4.0 Cumulative Patch Set for Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0).
This option installs 2.0.1.4.0 Cumulative Patch Set, for installations of Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0) only. Before applying this patch, you must upgrade your Oracle Beehive deployment to Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, or 2.0.1.3.0). Do not attempt to install this patch set on earlier versions of Oracle Beehive.
Table 1, "Oracle Beehive Upgrade Options for 2.0.1.4.0" shows the upgrade and patch options that are available.
Once you have completed an upgrade according to one of these paths, you can then apply this patch set.
Table 1 Oracle Beehive Upgrade Options for 2.0.1.4.0
| Your current Oracle Beehive deployed version | Your upgrade path option(s) |
|---|---|
|
1.5.1.0.0, 1.5.1.2.0, 1.5.1.3.0, 1.5.1.4.0 |
Either:
|
|
1.5.1.5.0, 1.5.1.5.1, or 1.5.1.5.2 |
Either:
|
|
2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, 2.0.1.3.0 |
Apply 2.0.1.4.0 Cumulative Patch Set |
|
Note: You can determine your version number by running thebeectl version command from any Oracle Beehive Oracle home. |
This Readme contains the following topics:
Our goal is to make Oracle products, services, and supporting documentation accessible to all users, including users that are disabled. To that end, our documentation includes features that make information available to users of assistive technology. This documentation is available in HTML format, and contains markup to facilitate access by the disabled community. Accessibility standards will continue to evolve over time, and Oracle is actively engaged with other market-leading technology vendors to address technical obstacles so that our documentation can be accessible to all of our customers. For more information, visit the Oracle Accessibility Program Web site at http://www.oracle.com/accessibility/.
Accessibility of Code Examples in Documentation
Screen readers may not always correctly read the code examples in this document. The conventions for writing code require that closing braces should appear on an otherwise empty line; however, some screen readers may not always read a line of text that consists solely of a bracket or brace.
Accessibility of Links to External Web Sites in Documentation
This documentation may contain links to Web sites of other companies or organizations that Oracle does not own or control. Oracle neither evaluates nor makes any representations regarding the accessibility of these Web sites.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/support/contact.html or visit http://www.oracle.com/accessibility/support.html if you are hearing impaired.
This Readme includes information on installation, important notes, and known workarounds for the Oracle Beehive 2.0.1.4.0 Cumulative Patch Set for Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0).
Oracle recommends that you read and understand the information in this document before beginning the installation.
Please review the following important notes before installing this patch:
Search Service Refactoring Requires Additional Configuration
Change Notification Service Removed from Coexistence Deployments
If you have not already installed an instance of Oracle Beekeeper, but you think you might want to use Oracle Beekeeper in the future, you must install Oracle Beekeeper before installing the 2.0.1.4.0 Cumulative Patch Set.
Once you install the 2.0.1.4.0 Cumulative Patch Set, you cannot install a new instance of Oracle Beekeeper.
Oracle Beekeeper must be patched to 2.0.1.4.0 to work with Oracle Beehive 2.0.1.4.0. Earlier versions of Oracle Beekeeper will not work with Oracle Beehive instances that have been patched to 2.0.1.4.0.
ROLLBACK of this patch is not supported. If you need to undo a partial or complete installation of this patch, you must restore Oracle Beehive and the database from backup.
Before applying this (or any) patch on Oracle Beehive, always review the latest Oracle Beehive Release Notes for complete information about known issues, workarounds, and new features in Oracle Beehive. You can find PDF and HTML versions of the Release Notes on the Oracle Technology Network website, at the following URL:
Before applying this (or any) patch on Oracle Beehive, ensure there is sufficient hard drive space on the Oracle Beehive server. Oracle recommends at least 10 GB of free space.
The Oracle Beehive 2.0.1.4.0 Cumulative Patch Set includes a refactoring of the Oracle Beehive Search Service (which was added in 2.0.1.2.1). This is a substantial change which may require additional post-configuration steps:
When patching Oracle Beehive Release 2 (2.0.1.2.0) or earlier:
The existing search index is erased during patching. As a result, after the upgrade any search operation on existing data will return no results. You can perform post-installation steps to build a new search index of existing artifacts, using a new beectl command, beectl add_search_recovery_scope.
If you are using Oracle Secure Enterprise Search (SES) with Oracle Beehive, you must take additional steps to configure SES integration.
After the upgrade, the search service is enabled, new objects will be indexed, and default values for partitioning, jobs, and search service parameters are set. Depending on your deployment, you may need to make further configuration changes to tune the search service.
When patching Oracle Beehive Release 2 (2.0.1.2.1 or 2.0.1.3.0):
The existing search indexing process is suspended during patching. If you use a Zero Downtime Upgrade (ZDU) patching method, changes to searchable objects will not be indexed during the patching process. You can perform post-installation steps to update your existing search index with these accumulated changes.
If you do not use the ZDU method (that is, you elect to shut down your Oracle Beehive deployment during patching), then you do not need to perform any additional configurations steps. Your search index will not be affected by the patch.
For a brief summary of post-installation steps, see Search Service Post-Installation Configuration. For a detailed explanation of the new search service and its configuration, see MetaLink note 1135054.1.
The Oracle Beehive 2.0.1.3.0 patch set, included in this Cumulative patch set, removed the Change Notification Service (CNS) component and integrated the functions it formerly performed directly within the Coexistence Connector. This change significantly reduces the complexity of the deployment and the disadvantages of deploying additional coexistence software on existing Microsoft Exchange servers.
If you are applying this Cumulative Patch Set to a 2.0.1.2.1 or earlier deployment, this change will be applied at this time.
After you apply the 2.0.1.4.0 Patch Set to all of your Oracle Beehive Coexistence Connector Oracle homes AND Oracle Beehive Coexistence Change Notification Oracle homes, you can remove CNS components by following the instructions in Remove CNS Components from Coexistence Deployments.
You must conform to each of the following requirements and perform all pre-installation tasks before installing the patch:
Install on Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0) Only
Except When Patching 2.0.1.2.1 or 2.0.1.3.0, Shut Down Oracle Beehive
Patch Required for Upgraded Beehive Instances on Oracle Database 11.2
|
Caution: Failure to carefully read and understand these requirements may cause Oracle Beehive to malfunction, including interruption of service, loss of data, or both. |
Install on Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0) Only
Oracle Beehive 2.0.1.4.0 Cumulative Patch Set can only be installed on Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0). If you have an earlier version of Oracle Beehive, you must first upgrade to Oracle Beehive Release 2, before applying this patch.
Backup your Oracle Beehive Deployment
Before installing 2.0.1.4.0 Cumulative Patch Set, Oracle strongly recommends that you perform a backup of your database and the Oracle Beehive Oracle home.
Install on All Oracle Beehive Application Tiers
You must install this patch in every Oracle Beehive Oracle Home, including Application tiers, Oracle Beehive DMZ Oracle Homes, Oracle Beehive Coexistence Connector Oracle Homes, and Oracle Beekeeper Oracle Homes.
Except When Patching 2.0.1.2.1 or 2.0.1.3.0, Shut Down Oracle Beehive
Unless you are patching an Oracle Beehive 2.0.1.2.1 or 2.0.1.3.0 deployment, before installing this patch set, shut down all processes on all Oracle Beehive Application tiers, including Oracle Beekeeper, Oracle Beehive Coexistence Connector, and Oracle Beehive DMZ Oracle homes. Make sure that all Oracle Beehive processes were started normally prior to shutting them down.
If you are patching an Oracle Beehive 2.0.1.2.1 or 2.0.1.3.0 deployment, you may perform a Zero Downtime Upgrade (ZDU) patch. In this case, you can leave your Oracle Beehive Application tiers up and running, only shutting down one Application tier server at a time when you patch that server. The ZDU method allows you to avoid extensive downtime of your Oracle Beehive deployment.
Each of your Oracle Beehive servers will be started automatically as you apply the patch set to them.
Disable Fast Validation in the Database
You must disable fast validation in the database before installing Oracle Beehive 2.0.1.4.0 Cumulative Patch Set.
Log in to your Oracle Beehive database as SYS using SQL*Plus, and enter the following command:
ALTER SYSTEM SET "_disable_fast_validate"=TRUE SCOPE=BOTH SID= '*';
After you install the Oracle Beehive 2.0.1.4.0 Cumulative Patch Set, you can re-enable fast validation using the following commands:
ALTER SYSTEM RESET "_disable_fast_validate" SCOPE=SPFILE SID='*'; ALTER SYSTEM SET "_disable_fast_validate"=FALSE SCOPE=MEMORY SID='*';
Apply Database Patch in Database Oracle Home
If you have not already done so (such as when applying a previous patch), apply the oneoff patch for Oracle Database Bug 8440319 in your Oracle Beehive database Oracle home before applying this patch set. Review the README in that patch after unzipping for instructions for applying the patch. Perform all post-patch steps as documented in that README. This Oracle Beehive patch will fail if the post-patch steps are not performed.
Patch Required for Upgraded Beehive Instances on Oracle Database 11.2
Bug 10134218. If you have upgraded your Oracle Database to 11.2, you may require a patch in order to successfully install the Oracle Beehive 2.0.1.4.0 Cumulative Patch Set.
If both of the following conditions are true:
You have patched from Oracle Beehive 2.0.1.2.0 to either 2.0.1.2.1 or 2.0.1.3.0
AND, after performing that patch, you upgraded your Oracle Database from version 11.1 to 11.2
Then you must apply a special patch or the Beehive 2.0.1.4.0 patch set will fail during installation.
|
Note: If you do not apply the required patch and you experience the failure during the Oracle Beehive 2.0.1.4.0 Cumulative Patch Set, you can still apply the 10134218 patch at that time, and then complete the 2.0.1.4.0 installation. |
If you need to apply this special patch, contact Oracle Support to get the correct version of the 10134218 patch for your operating system and upgrade scenario.
|
Notes:
|
To install 2.0.1.4.0 Cumulative Patch Set for Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0), perform the following steps on each Oracle Beehive server and Oracle Beekeeper Oracle home in your deployment:
Make sure that the Oracle Beehive Database instance and TNS Listener are UP and running.
If you are applying this Cumulative Patch on Oracle Beehive 2.0.1.2.1 or 2.0.1.3.0, shut down all processes in the Oracle Beehive Application tier where the patch will be applied, before applying this patch set. Other Application tiers (including DMZ installations) can be UP and running when applying the patch on a given Application tier. (Oracle Beekeeper instances must be shut down.)
If you are patching an Oracle Beehive Coexistence Connector instance (any version), you must shut down all processes in the Coexistence Connector Oracle Home before applying the patch.
|
Note: This means that when updating from 2.0.1.2.1 or 2.0.1.3.0 to 2.0.1.4.0, you can perform a rolling patch by patching one Application tier at a time, without shutting down your Oracle Beehive deployment. (You cannot use the rolling patch method when updating from any previous version.) |
Make sure that Oracle Beehive processes were gracefully started and all services were running before shutting down a given Application tier.
|
Note: If you have not deployed Oracle Universal Records Management (URM), the Records Management Service will be disabled. You do not need to enable this service prior to patching.However, all other Oracle Beehive services must be enabled and running before you shut down your Oracle Beehive deployment, including services you may normally leave disabled, such as the Device Management Service. |
Unzip the downloaded package to a convenient location.
For Oracle Beekeeper instances that were previously upgraded from 1.5.1.x to 2.0.1.0, work around a known issue (Bug 9041410) by performing the following steps to extract a custom script:
In the Oracle Beekeeper Oracle home, navigate to the patch storage directory:
cd $ORACLE_HOME/.patch_storage
Extract into this directory the custom script:
unzip <patch_extract_location>/9859346/Beehive_20140/custom/scripts/beepatch/9041410_workaround.zip
On Linux and UNIX only, set your current directory to the directory where the patch is located. For example:
% cd 9859346
(You do not need to take this step on Windows.)
If you are patching an Oracle Beehive server, set the ORACLE_HOME environment variable to your Oracle Beehive Oracle home. For example:
On UNIX and Linux platforms:
% setenv ORACLE_HOME /app/oracle/products/beehive
On Windows:
set ORACLE_HOME=C:\Beehive_Home
If you are patching an Oracle Beekeeper instance, set the ORACLE_HOME environment variable to your Oracle Beekeeper Oracle home. For example:
On UNIX and Linux platforms:
% setenv ORACLE_HOME /app/oracle/products/2.0.1.4.0/beekeeper_1
On Windows:
set ORACLE_HOME=C:\Beekeeper_Home
Use the following commands to apply the patch:
When applying the patch to the first Oracle Beehive (non-DMZ, non-Beekeeper, non-coexistence connector) instance, run the opatch command with the -first_midtier option:
|
Notes:
|
% ORACLE_HOME/OPatch/opatch napply -post -sys_passwd <sys password> -dbconnstr "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<db hostname>)(PORT=<db listen port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<db service name>)))" -first_midtier -opatch_post_end
|
Note: On Windows, omit the double-quotes surrounding the value of-dbconnstr:
patch.bat napply -post -sys_passwd <sys password> -dbconnstr (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<db hostname>)(PORT=<db listen port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<db service name>))) -first_midtier -opatch_post_end |
When applying the patch to additional Oracle Beehive (non-DMZ, non-Beekeeper, non-coexistence connector) instances, run the opatch command without the -first_midtier option:
% ORACLE_HOME/OPatch/opatch napply -post -sys_passwd <sys password> -dbconnstr "(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<db hostname>)(PORT=<db listen port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<db service name>)))" -opatch_post_end
|
Note: On Windows, omit the double-quotes surrounding the value of-dbconnstr:
patch.bat napply -post -sys_passwd <sys password> -dbconnstr (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=<db hostname>)(PORT=<db listen port>))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=<db service name>))) -opatch_post_end |
When applying the patch to a separate Oracle Beekeeper Oracle home:
|
Notes:
|
On UNIX and Linux:
% $ORACLE_HOME/OPatch/opatch napply
On Windows:
patch.bat napply
When applying the patch to an Oracle Beehive DMZ instance Oracle home, use the following command:
|
Note: After applying a patch, Oracle Beehive will attempt to restart a patched instance, including DMZ instances. However, if you have not yet performed the Update hasbind File Ownership post-installation step, a DMZ instance may be unable to use privileged ports. In this case, shut down the DMZ instance, and restart it after performing post-installation steps. |
On UNIX and Linux:
% $ORACLE_HOME/OPatch/opatch napply
On Windows:
patch.bat napply
When applying the patch to an Oracle Beehive Coexistence Connector Oracle home, use the following command:
patch.bat napply -post -password <oc4jadmin password > -opatch_post_end
The value of <oc4jadmin password> is the password initially entered for the OC4J admin account when you installed the Oracle Beehive Coexistence Connector in this deployment
Be sure to repeat all steps in this procedure on each Oracle Beehive server in your deployment.
After performing the installation, perform the steps in the following sections, where applicable:
Apply Patch to Oracle Database 11.1.0.7.x on Certain Locales
Migrate Data from DENY_ALL Groups to Folders With Private Sensitivity
Bug 9948554. Due to database bug 8481520, after installing Oracle Beehive 2.0.1.4.0 patch set, customers using Oracle DB version 11.1.0.7.x who are installing on French, German, Italian, Spanish, or Portuguese (Brazilian) locales should install an Oracle Database patch.
|
Note: If you have already applied this database patch, such as after applying the Oracle Beehive 2.0.1.3.0 Cumulative Patch Set, you can skip this step. |
On Linux x86, x86-64, and Oracle Solaris on SPARC (64-bit), download and install the patch for Bug 8481520.
On Windows or other operating systems, contact Oracle Support for the necessary patch.
On Linux and UNIX Oracle Beehive servers, if your $ORACLE_HOME/beehive/bin/hasbind file was owned by root (in order to use privileged ports) before applying this patch, be sure to change it back to ownership by the root user. For example, you could execute the following commands using an account with superuser privileges:
$ cd $ORACLE_HOME/beehive/bin $ chown root hasbind $ chmod a+x hasbind $ chmod a+s hasbind
|
See Also: For more information about thehasbind file and reasons for modifying it, see "Modifying Oracle Beehive Ports using Privileged Port Numbers" in Chapter 5, "Managing Oracle Beehive Services" in the Oracle Beehive Administrator's Guide. |
After you install the Oracle Beehive 2.0.1.4.0 Cumulative Patch Set, you can re-enable fast validation using the following commands:
ALTER SYSTEM RESET "_disable_fast_validate" SCOPE=SPFILE SID='*'; ALTER SYSTEM SET "_disable_fast_validate"=FALSE SCOPE=MEMORY SID='*';
If, and only if, you installed this patch on Oracle Beehive 2.0.1.2.1 or 2.0.1.3.0, since the patch involves schema cloning, you must run the post_upgrade_db_actions.pl script.
If you installed this patch on Oracle Beehive 2.0.1.2.0 or earlier, you do not need to run this script.
|
Note: When you enter the<CONNECT_STRING> argument for the perl script, you must enclose it in double-quotes. |
For complete instructions, see "Running Perl Script post_upgrade_db_actions.pl," in Chapter 12, "Upgrading Oracle Beehive Overview" of the Oracle Beehive Installation Guide for your platform (Chapter 13 in the Windows guide).
Bug 9722573. After applying this patch, you must run a SQL script to clean up group membership data in UDS. Log in to your Oracle Beehive database using SQL+Plus as the current BEE_CODE user, and run the script uds_post_upgrade_seed.sql. The script is located in the following folder:
BEEHIVE_HOME/beehive/tmp/patch/9859346/db
After the patch is successfully applied, upgrade the inventory version of Oracle Beehive components:
Navigate to the upgrade inventory script in the following location:
<extracted_patch_location>/9859346/Beehive_20140/custom/scripts
Extract the ZIP file containing a script to a folder on your local file system:
In Oracle Beehive instances, extract the files from the following .zip:
BeehiveVersionUpgradeTo20140.zip
In Oracle Beekeeper instances, extract the files from the following .zip:
BeekeeperVersionUpgradeTo20140.zip
A subdirectory will be created containing the script
Run the shell script as follows:
In Oracle Beehive instances:
For Linux and UNIX: % BeehiveVersionUpgradeTo20140.sh <PATH_TO_ORACLE_HOME> or for Windows: % BeehiveVersionUpgradeTo20140.bat <PATH_TO_ORACLE_HOME>
In Oracle Beehive DMZ and Coexistence Connector instances:
For UNIX and Linux: % BeehiveVersionUpgradeTo20140.sh <PATH_TO_ORACLE_HOME> or for Windows: % BeehiveVersionUpgradeTo20140_DMZ_COEX.bat <PATH_TO_ORACLE_HOME>
In Oracle Beekeeper instances:
For UNIX and Linux: % BeekeeperVersionUpgradeTo20140.sh <PATH_TO_ORACLE_HOME> or for Windows: % BeekeeperVersionUpgradeTo20140.bat <PATH_TO_ORACLE_HOME>
Where <PATH_TO_ORACLE_HOME> is the path of the Oracle home (Oracle Beehive or Oracle Beekeeper) that you are upgrading
Repeat steps 1 through 3 on all Oracle Beehive and Oracle Beekeeper instances whose inventories need to be updated to 2.0.1.4.0
To verify that the inventory on an instance has been updated, perform the following steps:
Navigate to the following directory:
% cd <Updated_Beekeeper_ORACLE_HOME>/oui/bin or % cd <Upgraded_Beehive_ORACLE_HOME>/oui/bin
Start Oracle Universal Installer by invoking the runInstaller in this directory:
% ./runInstaller or, on Windows: % setup.exe
In the Oracle Universal Installer interface, click Installed Products. An inventory window will open
In the inventory window, you can see all of the Oracle home names on the current host. Expand your Oracle Beehive or Oracle Beekeeper name by clicking on the plus (+) just before it. Confirm that the version number is now Beehive Release 2 2.0.1.4.0 or Oracle Beekeeper 2.0.1.4.0
To confirm the versions of other subcomponents, expand Oracle Beehive or Oracle Beekeeper 2.0.1.4.0 by clicking on the plus (+) just before it. Traverse through the list of subcomponents and confirm the following upgraded components:
On Oracle Beehive:
Oracle Beehive Release 2 Configuration 2.0.1.4.0 Oracle Beehive Release 2 Database Support 2.0.1.4.0 Oracle Beehive Release 2 Binaries 2.0.1.4.0 Oracle Beehive Release 2 Libraries 2.0.1.4.0 Oracle Beehive Release 2 Services 2.0.1.4.0 Oracle Beehive Release 2 Configuration Wizard 2.0.1.4.0 Oracle Commuication and Messaging Services 2.0.1.4.0 Oracle Beehive Release 2 Oneoffs 2.0.1.4.0
On Windows, also confirm:
Oracle Collaboration Coexistence Gateway 2.0.1.4.0
On Oracle Beekeeper:
Oracle Beekeeper 2.0.1.4.0 Oracle Beekeeper OC4J 2.0.1.4.0 Oracle Beehive Release 2 Oneoffs 2.0.1.4.0 Oracle Beehive Release 2 Configuration Wizard 2.0.1.4.0
The Oracle Beehive 2.0.1.3.0 Cumulative Patch (which is included in this cumulative patch set) included a refactoring of the Oracle Beehive Search Service. This is a substantial change which may require additional post-configuration steps in the following areas:
If you installed this patch on Oracle Beehive 2.0.1.2.0 or earlier, the existing search index is erased during patching. As a result, after the upgrade any search operation on existing data will return no results.
If you installed this patch on Oracle Beehive 2.0.1.2.1 or 2.0.1.3.0 and used the Zero Downtime Upgrade (ZDU) method, search indexing is suspended during the patching process. Changes in the system that occurred during patching are not indexed.
You can build a new search index of existing artifacts, using a new beectl command, beectl add_search_recovery_scope:
beectl add_search_recovery_scope --scope <recovery_scope> [--entity_type <entity_type>] [--start_date <start_date>] [--end_date <end_date>]
Where:
<recovery_scope> is the identifier for a level of scope for the utility to crawl for indexing, such as enterprise, organization, workspace, or folder.
<entity_type> indicates searchable entity types. You can specify this option more than once to indicate multiple entities types to index. If you omit this option, all entity types are searched and indexed.
<start_date> recovers search index for entities modified on or after this date. If not specified, 30 days before the present will be used as the start date. Permitted value is a string in ISO8601 date-time format. Valid formats are yyyy-MM-dd'T'HH:mm:ss.SS'Z', yyyy-MM-dd'T'HH:mm:ss.SS, yyyy-MM-dd'T'HH:mm:ss'Z', yyyy-MM-dd'T'HH:mm:ss, yyyy-MM-dd'Z', yyyy-MM-dd.
<end_date> recovers search index for entities modified before or on this date. If not specified, the present will be used as the end date. Use the same format as for <start_date>.
As soon as you issue an add_search_recovery_scope command, Oracle Beehive starts the background work and immediately returns an operation ID. You can use the operation ID with the beectl list_operation_statuses command to track the progress of the recovery job.
beectl list_operation_statuses --operation_status 1CF3:35AF:opst:6828B43CD3944E06A5CD425F0225CF2500000000004C
The add_search_recovery scope command will immediately add a list of all artifacts identified by the run time options to a queue of items to be indexed. Adding too many items to this queue at once will slow down the system. Oracle recommends reviewing the Recovery Crawler section of Oracle Support Note 1135054.1 prior to running the command.
To minimize performance impact, consider the following strategies:
Run the recovery crawler command during off-peak hours
Create a batch file to recover a few personal or team workspaces or a few days of email data at a time
Monitor the SS_FEEDS load (information in Oracle Support Note 1135054.1)
If you are using Oracle Secure Enterprise Search (SES) with Oracle Beehive, if you have not already done so (such as after installing the 2.0.1.2.1 or 2.0.1.3.0 patch set) you must take additional steps to configure SES integration. The following procedure provides a high-level outline of the actual configuration steps. For complete instructions, see MetaLink Note 1135054.1.
Perform the following steps to configure SES integration:
Perform the complete procedure for basic SES integration as detailed in Chapter 10, "Integrating Oracle Secure Enterprise Search 10g with Oracle Beehive" of the Oracle Beehive Integration Guide
If needed, configure your Identity Management solution with the appropriate host, port, realm, and other connection settings
If needed, create source groups (groupings of data sources, which appear as tabs above the search box)
From the SES Admin console, set up a title URL for Oracle Beehive search results by creating new search attributes, and then modifying the XSL stylesheet to include the new attributes
From the SES Admin console, add Oracle Beehive search result attributes and filtering attributes
The Oracle Beehive 2.0.1.3.0 Cumulative Patch Set, which is included in this Cumulative Patch Set, removed the Change Notification Service (CNS) component and integrated the functions it formerly performed directly with the Coexistence Connector.
At any time after installing 2.0.1.2.1, 2.0.1.3.0, or 2.0.1.4.0 patch sets on all of your Oracle Beehive Coexistence Connector Oracle homes AND Oracle Beehive Coexistence Change Notification Oracle homes, you can perform the following steps to remove CNS components:
Patch ALL Oracle Beehive Coexistence Connector Oracle homes and Change Notification Service Oracle homes. You must not remove CNS components until every Coexistence Oracle home has been patched.
From CNS (or Connector+CNS) Oracle homes, run the following command to clean up CNS registrations:
$ORACLE_HOME\beehive\collabcoex_connector\coexctl.exe remove_cns_registrations
Uninstall CNS-only Oracle homes using Oracle Universal Installer.
To remove the CNS component from Connector+CNS Oracle homes:
Run the following command:
$ORACLE_HOME\beehive\collabcoex_connector\coexctl.exe uninstall_eventsink
Open the following properties file in a text editor:
$ORACLE_HOME/beehive/oobwiz/configWizard.properties
Remove the following line:
Configured=true
Save and close the file.
To provide improved security, with the 2.0.1.3.0 Cumulative Patch Set (which is included in this Cumulative Patch Set), Oracle Beehive has implemented a new access control scheme for restricting access to content at the folder level. Instead of using the DENY_ALL permission on UDS groups, you can now use the 'private' sensitivity directly on a folder. To migrate from the previous method to the new method, workspace owners must re-create affected folders.
To facilitate this process, a SQL script is provided which creates a list of all folders with the DENY_ALL group permission. After installing this patch set, you can find the script at the following location on any patched Oracle Beehive server:
$ORACLE_HOME/beehive/db/accesscontrol/src/sql/upgrades/9761524.sql
Oracle recommends performing the following steps after installing this patch, to implement the improved security model:
Using SQL+Plus, Connect to the current Beehive CODE schema
|
Note: To get the current code schema name, use the commandbeectl list_schemas. |
Run the provided SQL script 9761524.sql. The output lists all folders with access denied to a group. An example of typical output is shown in Example 1, below.
Notify workspace owners (listed in the output loginid and contact fields) of the folder-group combination (listed in the folderpath and groupname fields) for which Oracle recommends using the new OBEO and OBEE feature of using sensitivity to control access.
Workspace owners must re-create the affected folders using OBEO or OBEE, assign the 'private' sensitivity-only sensitivity to each folder, and then move content from the old folders to the new ones. The old folders can then be removed.
Example 1 9761524.sql Script Output
FOLDERPATH GROUPNAME WORKSPACENAME LOGINID CONTACT --------------- --------------- --------------- --------------- --------------- /Mycompany/project/INBOX Analysts April_Projects rsmith rsmith@example.com /Mycompany/reports/INBOX EXECS Executive_wksp rsmith rsmith@example.com /Mycompany/QA/INBOX QA_Engineers EngQA s.ravi s.ravi@example.com
You can write a script to generate e-mails based on this report and send collated e-mail messages to workspace owners. For example, one e-mail can be sent to rsmith@example.com indicating that the Analysts and EXECS workspaces have INBOX folders that should be re-created and assigned the 'private' sensitivity.
Table 2, "Resolved Issues in Oracle Beehive 2.0.1.4.0 Cumulative Patch Set" lists the issues resolved in this Patch Set (new for 2.0.1.3.0 Patch Set).
The issues that were resolved by the Oracle Beehive 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0 patch sets (and are included in this cumulative patch) are listed in detail in the patch readmes for each patch. You can find the readmes on the Oracle Technology Network Website, at the following URLs:
2.0.1.1.0: http://www.oracle.com/technetwork/middleware/beehive/overview/beehive-20110-readme-167644.html
2.0.1.2.0: http://www.oracle.com/technetwork/middleware/beehive/overview/beehive-20120-readme-154855.html
2.0.1.2.1: http://www.oracle.com/technetwork/middleware/beehive/overview/beehive-20121-readme-154694.html
2.0.1.3.0: http://www.oracle.com/technetwork/middleware/beehive/overview/beehive-20130-readme-167628.html
Table 2 Resolved Issues in Oracle Beehive 2.0.1.4.0 Cumulative Patch Set
| Bug Number | Description |
|---|---|
|
7282890 |
E-mail read receipts were always set to the language corresponding to the Beehive server's locale. They will now be translated according to the original sender's locale. |
|
7419106 |
In Beehive Webmail, users can now set a message priority. |
|
8522131 |
Records management policies can now be created at lower levels of scope, including specific folders within a workspace. |
|
8530854, 9508538 |
Oracle Beehive Webmail now supports read receipt notifications. |
|
8625966 |
OBEO now supports Microsoft Outlook's journal tracking feature. |
|
9007446 |
In OBEO, display of a delegate's role could become inconsistent under certain circumstances. |
|
9112142 |
An issue with invalid time zones in resources could occur when the resource was created in Beehive 1.5.x and then upgraded to 2.0 on certain non-English locales. |
|
9260419 |
Using the beectl command |
|
9415044 |
If an e-mail rule configuration contained an invalid value, it could prevent the e-mail service from starting. |
|
9487436 |
Under certain unusual conditions, the Time Management Service could stop pushing new events to the Search service, so they would not be indexed or searchable. |
|
9508538 |
In Beehive Webmail, users can now request read receipt of e-mail messages. |
|
9523464 |
In OBEO, because a blocking issue has been resolved, optimizations to calendar downloading have been re-enabled. |
|
9527695 |
In OBEO, certain 'stale' upload errors that were no longer applicable, could not be removed from the upload errors dialog. |
|
9546181 |
In OBEO, when the network connection was unavailable, the error message was misleading. |
|
9724046 |
In some deployment scenarios the Beehive Conferencing client could erroneously report an untrusted root certificate when the certificate was actually valid. |
|
9729294 |
In the Beehive RESTful Web Services API, the WorkspaceParticipantUpdater.setRoles() object wasn't working correctly. |
|
9744531 |
E-mail messages sent to a disabled user account were being rejected without an appropriate Delivery Status Notification. |
|
9766111 |
In the Beehive RESTful Web Services API, setting an ACL on a folder emptied existing ACLs but did not correctly set new values, even though the response status indicated a successful operation. |
|
9794082 |
A problem with the ASK service for mobile device notifications resulted in multiple identical SMS action responses being generated. |
|
9798693 |
A missing error code resulted in the error log message 'Error code for BEER_06002 does not exist' to be produced by the Search Service. |
|
9811400 |
The Beehive voicemail fax detection sometimes failed to recognize incoming faxes due to the 'branding message' that is played during detection being too short. |
|
9820790 |
User-configured rules that automatically forwarded e-mails containing voice mail messages were not working. |
|
9838114 |
Mobile iPhone support for Apple iPhone iOS4 has been added. |
|
9839723 |
In Beekeeper, custom UDS user properties were not shown when mapping properties for LDAP-based synchronization. |
|
9842444 |
Database reporting views were not accessible to the reporting user on Oracle Database 11g versions. |
|
9849516 |
In Team Collaboration client Wiki pages, when using Internet Explorer, editing a path containing an ampersand (&) didn't work correctly. |
|
9849540 |
In Beehive Webmail, to improve performance, the client will no longer attempt to load an unlimited number of items in the Trash folder. |
|
9856173 |
The log for the XMPP service was being flooded with WARNING-level entries for every buddy no longer in the system on a user's roster whenever the user logged in. |
|
9861139 |
There was an issue with the way beectl modified accessible_by permissions on resources in the Time Management Service. |
|
9862693 |
After consecutively synchronizing disabled status from an LDAP-based user directory for a user account, the user account could not be subsequently deleted. |
|
9867203 |
|
|
9867355 |
When hosting a Beehive Conference over a VPN connection while also using a Cisco IP Phone, the conference client often become unstable or crashed. |
|
9869540 |
In the Team Collaboration client, Wiki page headings were not visible when under advanced tables with 100% width and left alignment. |
|
9873810 |
In the Team Collaboration client, when selecting an existing image in a Wiki page and using the 'Add/Edit image' function, the image name was not populated. Saving changes without adding the image name back would cause it to disappear. |
|
9876242 |
E-mail messages with attachments that are unprocessable by a configured virus scanner could become stuck in the retry queue even beyond the maximum retry period. |
|
9880348 |
In Internet Explorer set to use Italian (only), in Beehive Webmail it was not possible to modify the content when replying to an e-mail with the edit window set to HTML mode. |
|
9881114 |
Out-of-office replies were being sent in response to e-mails even when the recipient was not in the to: or cc: header, which caused problems with mailing lists. Beehive now implements RFC3834 guidelines. In any of the following cases, an out-of-office reply will not be sent:
|
|
9883195 |
In the Team Collaboration client when editing a Wiki page, inserting a table immediately after an ordered list caused the table to appear at the top of the page instead. |
|
9883445 |
In the Team Collaboration client, a workspace with a tab character in the name would not display uploaded workspace icons. |
|
9886155 |
Response time for the Mobile Sync Servlet when synchronizing J2EE applications has been improved. |
|
9886268 |
In OBEO, users who marked more than 40 workspaces as visible in a Release 1 (1.5.x) version, could not update the list after the maximum was set to 40 by upgrading Oracle Beehive to a Release 2 version. |
|
9890029 |
IMIP-based meeting notification responses sometimes appeared offset by an hour from the correct time, due to a time zone rule issue that did not account for daylight saving time offset. |
|
9890057 |
A performance improvement was made to certain CalDAV operations in the Time Management service when synchronizing the iPhone mobile client. |
|
9891141 |
When using the Team Collaboration client with Internet Explorer 8, very wide tables were displayed with a horizontal scroll bar in the wrong place. |
|
9893501 |
A rare condition could prevent participants in a Real-Time Collaboration conference from seeing the presentation after the presenting user was changed. |
|
9897518 |
When uploading a workspace icon that is larger than the maximum size using the Team Collaboration client on Internet Explorer 8, the uploading overlay was not removed, so the user could not see an error message that the upload had failed. |
|
9901359 |
In the Team Collaboration client, after changing the name of a workspace, from the details pane choose links tab, wiki links pointing to non-existent pages no longer redirected to the new page creation function. |
|
9905624 |
In Beehive Central, setting the default reminder for meetings to 0.5 days actually set it to 5 days, which caused the user interface to display the default (1 day) when re-visited. |
|
9915266, 9951664, 9958680, 9964739, 9964772, 9964825, 9965048, 9965059, 10067526 |
Several functionality enhancements were made to the Beehive Mobile client for BlackBerry. |
|
9919036 |
The most recent event with a given string was not returned when searching for workspace creation events with multiple valid results. |
|
9920166 |
The Mobile Data Sync Service includes a profile for the Synthesis SyncML client, allowing users of Android-based phones to synchronize with Oracle Beehive. |
|
9925255 |
Except when it is a wildcard, searches containing only special or reserved characters or words will now return no results, instead of causing an error. |
|
9926042 |
When modifying the default password policy using beectl by exporting, modifying, and re-importing XML, using the --verbose option with the beectl export_policy command is no longer required. |
|
9929153 |
An optimization has reduced the amount of memory consumed by the Beekeeper system model cache. |
|
9937439 |
A new service property of the Wiki service, WikiTextReplace, allows you to specify a list of Perl-like regular expressions that will be applied to the text nodes of Wiki pages. |
|
9941751 |
Some types of delegated calendar permissions, when set using beectl modify_calendar_permissions commands, were not correctly reflected in OBEO. |
|
9942026 |
In Oracle Beehive coexistence with Lotus Domino, under certain conditions modifying a recurring meeting's time while simultaneously adding an invitee caused the meeting to be duplicated with both the old and new start times for coexisting Beehive users. |
|
9942348 |
A recurring processing loop in the Time Management Service could occur in large coexisting environments, which caused high system resource usage. |
|
9944966 |
In deployments with users using non-English localization and multiple e-mail clients, users would have separate Sent folders created by each client, with sent messages split between them. |
|
9946247 |
Under high free/busy lookup activity in large deployments, coexisting Lotus Domino servers were being flooded with too many requests, causing instability or crashes. |
|
9948289 |
In the Time Management Service, a synchronization issue could occur if a meeting invitee declined and then revoked 'can invite' permission, and the meeting organizer subsequently rescheduled the meeting. |
|
9950165 |
In the Team Collaboration client Remote Repository Settings screen, if a user selected and then de-selected a remote repository, the disable button remained active, and clicking it produced an error. |
|
9952802 |
After their local time zone had changes (such as to daylight saving time values), Windows users could not log in to Beehive Webmail. |
|
9953466 |
The beectl export_email_data command could fail when the e-mail data contained messages with certain unusual body structures. |
|
9953992 |
Server-side errors when searching after performing post-upgrade search indexing were identified and fixed. |
|
9955010 |
Performance-related adjustments were made to the Coexistence Service. |
|
9955745 |
NEED TO BE ABLE TO CONFIURE WHICH ACTIONALBLE NOTIFICATIONS TO USE WITH ASK. |
|
9959131 |
In the Team Collaboration client, when uploading files, after selecting a second file to upload, canceling the first file by clicking the red X icon caused an error and, in Internet Explorer and Safari browsers, crashed the browser. |
|
9965397, 10064073 |
An authorization subcomponent on the server was consuming excessive CPU resources. |
|
9966979 |
In the Team Collaboration client, when modifying the property of a remote mount point, if the remote content name contained a single-quote character (') the save button to save changes to the property was missing. |
|
9968369, 9968374, 10025717, 10055969 |
The Help links in the Beehive Central, Team Collaboration, Real Time Collaboration, client headers can now be modified to point to a different URL, to facilitate self-hosting non-English help sets. |
|
9970002 |
In Beehive Webmail, issues with the folder tree display caused some users to only see their Trash folder if an expected folder was named incorrectly. |
|
9973416 |
Beehive users who are not invited to an online conference could not join using a guest URL. |
|
9977337 |
The Olson 2010L time zone package is included in this patch. |
|
9977558 |
ROSTER UPDATE PACKETS SENT WHEN DISCONNECTED ARE NOT SENT WHEN RECONNECT |
|
9977653 |
CHANGE CAPTURE BASED UPON USER WHITELIST |
|
9977670 |
Search Service index optimization was improved, which will improve search query performance. |
|
9978031 |
An optimization was made to improve performance when the Search Service indexes multi-part e-mail messages. |
|
9980810, 9981460, 10034168 |
A new, JavaFX-based Beehive Conferencing client is included in this patch. |
|
9981332 |
At the end of a Web conference, clients would sometimes attempt to reconnect instead of recognizing the session had ended. |
|
10014727 |
Accessibility improvements were made to the OBEO client interface. |
|
10015367 |
In deployments with large numbers of users, the mobile client ASK service took too long to respond to directory lookup commands. |
|
10016487 |
The Team Collaboration client Profile page presence link was not formatted correctly, so it wasn't invoking an IM client session. |
|
10018863 |
A problem was preventing the Synthesis client for Apple iPhone and iPad from synchronizing with the server. |
|
10044485 |
An exception was sometimes thrown on the server when adding a participant to a workspace. |
|
10069697, 10069669 |
In the Real Time Collaboration client, the messages that appear when a random web conference key is generated were not translated for localized versions. |
|
10099628 |
In Beehive Webmail account preferences, the 'Read Receipt Address' field was unused. It has been removed. |
2.0.1.4.0 Cumulative Patch Set for Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0) is available in English only. There are no translations of any English labels and other text.
2.0.1.4.0 Cumulative Patch Set for Oracle Beehive Release 2 (2.0.1.0.0, 2.0.1.1.0, 2.0.1.2.0, 2.0.1.2.1, and 2.0.1.3.0)
Copyright © 2008, 2010, Oracle and/or its affiliates. All rights reserved.
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this software or related documentation is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007). Oracle USA, Inc., 500 Oracle Parkway, Redwood City, CA 94065.
This software is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications which may create a risk of personal injury. If you use this software in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure the safe use of this software. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software in dangerous applications.
Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners.
This software and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.