Calendar Server 7 Patches by Release

Skip to end of metadata
Go to start of metadata

Oracle Communications Calendar Server (Calendar 7) Patches By Release

Use this page to locate build and patch information for Calendar Server releases. If newer patch revisions become available, use the newer ones instead of those shown in the table.

Tip
As a workaround to learning about new patches, you can use the Confluence "watch" feature to monitor this page. When new patches are available, this page is updated with that information. You then receive an email message that this page has been updated. The "watch" feature is available under the Tools menu.

Topics:

Overview

When you perform a fresh installation by using the Communications Suite installer (commpkg install), you install the current patch levels for Calendar Server. You use the commpkg upgrade command to upgrade to newer product releases. For more information, see the commpkg upgrade command, which is provided in the Communications Suite Installer zip file.

As newer patches become available between releases, you install them by using the patchadd command on Solaris, or the rpm command on Red Hat Linux. These patch commands run the related pre- and post-patch scripts to ensure proper patch installation.

If the patch installation fails during the pre-patch phase, you need to correct the problem and re-apply the patch. If the patch installation fails during the post-patch phase, you need to follow the instructions in the error message to manually resolve the problem.

The following table shows the patch history for Calendar Server 7.

Calendar Server 7 Patches

Suite Suite Release Date Calendar Server Version Number Oracle Solaris SPARC Oracle Solaris x86 Red Hat Linux
CommSuite 7 Update 5 New Features 2013-Oct-31 7.0.4.14.0 142785-14
142786-14
142787-14
Problems Fixed in Patch 12 2013-Mar-08 (Patch released 2013-Aug-20) 7 Update 3 Patch 12 142785-12 142786-12 142787-12
Problems Fixed in Patch 10 2013-Mar-08 (Patch released 2013-Apr-14) 7 Update 3 Patch 10 142785-10 142786-10 142787-10
New Features in Patch 9 2013-Mar-08 (Patch released 2013-Jan-06) 7 Update 3 Patch 9 142785-09 142786-09 142787-09
New Features in Patch 8 (Patch released 2012-Oct-17) 7 Update 3 Patch 8 142785-08 142786-08 142787-08
Problems Fixed in Patch 7
(Patch released 2012-Aug-10) 7 Update 2 Patch 7 142785-07 142786-07 142787-07
Problems Fixed in Patch 6 (Patch released 2012-Apr-10) 7 Update 2 Patch 6 142785-06
142786-06 142787-06
CommSuite 7 Update 2 New Features in Patch 5 2011-Dec-15 7 Update 2 Patch 5
142785-05 142786-05 142787-05
CommSuite 7 Update 2 New Features 2011-Oct-06
7 Update 2 (Patch 4)
142785-04
142786-04
142787-04
CommSuite 7 Update 1 New Features 2011-Apr-21
7 Update 1 Patch 3
142785-03
142786-03
142787-03
CommSuite 7 Update 1 New Features 2010-Sep-02 7 Update 1 Patch 2
142785-02 142786-02 142787-02
CommSuite 7 Update 1 New Features 2010-Sep-02 7 Update 1 (Patch 1)
142785-01 142786-01 142787-01

To Install a Calendar Server 7 Patch

Note
If you are upgrading from one Calendar Server update version to another, for example, from Calendar Server 7 Update 2 to Update 3, do not use these patch instructions. Instead refer to Upgrading Calendar Server.
  1. Download the Calendar Server 7 patch.
  2. Back up your Calendar Server back-end database.
    For example, you can use the davadmin db backup command.
  3. (Optional) To prevent users from connecting during the patch application, you might want to disable GlassFish Server from servicing incoming requests.
    See Disabling GlassFish Server During Calendar Server Patch Application for more information.
  4. Run the platform-specific patch command.
    • On Solaris, run patchadd.
    • On Red Hat Linux, run rpm -F.
  5. Run the init-config command to enter the current deployment configuration values.
  6. Run the merge-config command to merge in any other changes that were done to the configuration after the initial configuration, and that are not controlled by the init-config program.
    For example, you might have customized configuration parameters in the davserver.properties file.
  7. (Optional) Resolve any problems.
    1. If the patch installation detects a problem during the pre-patch phase, correct the problem and re-apply the patch.
    2. If the patch installation detects a problem during the post-patch phase with merging configuration files, reconcile the merged files.
  8. Restart GlassFish Server.
Labels:
patches patches Delete
caldavserver caldavserver Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Oct 19, 2012

    There's a change within the revision 14278?-08 of the patch that should be clarified. I think it's important if you already have a running installation.

    This patch revision requires installing comm_dssetup.pl revision 24+ beforehand because that applies some important modifications to the LDAP scheme. That's being utilized through enabling a new LDAP attribute davuniqueid. It doesn't mind for the fresh installations, however, the existing users are using nsuniqueid. A new script is included with this patch revision: /opt/sun/comms/davserver/sbin/populate-davuniqueid. It adds davuniqueid attribute to each user and fills it with the value read from the user's nsuinqueid attribute.

    The question is: for existing installations, is running this script mandatory or not? If it is, then that might have been mentioned within the README file assigned to the patch.

    1. Oct 19, 2012

      "This patch revision requires installing comm_dssetup.pl revision 24+ beforehand because that applies some important modifications to the LDAP scheme. That's being utilized through enabling a new LDAP attribute davuniqueid."

      Not just that attribute, this patch also adds two attributes to enable the ability to authenticate against external Directory Servers. See New Schema Objects for more information.

      "The question is: for existing installations, is running this script mandatory or not?"

      A Calendar Server deployment requires the use of a unique identifier. That unique identifier can be a deployment defined one or davuniqueid, which is added by the Comms schema. Per our dev team, when you upgrade to Calendar Server 7 Update 3 (patch 8), you need to switch to using davuniqueid if you initially selected to use nsuniqueid in your Calendar Server deployment. For reasons described here, nsuniqueid has issues. The populate-davuniqueid script can help with this change.

      HTH,

      Joe

      1. Oct 19, 2012

        I will recommend our customer to install this patch and switch to using davuniqueid. I understand we'll have to run populate-davuniqueid (a very fine script, thought, I tried it on test server).

        I felt a bit confused (the patch README should be mentioning the need to modify LDAP user entries) but your explanations cleared it all. Thanks for the clarification and for the provided links, Joe.

        All the best,
        Ivan

  2. Sep 05, 2013

    I'm about to patch Calendar Server on several machines. I see the necessity to manually run "init-config" after "patchadd" and provide it with current configuration. Is there any way to create a saveState file so I can run "init-config" silently? That might save me a lot of time.

    I ask because I saw Convergence has a similar patching technique, except that it silently performs "init-config" with temporarily created saveState file.

    Thanks,

    Ivan

  3. Sep 05, 2013

    I saw that, but I also saw a comment elsewhere in Wiki (can't remember exact place). It was about undocumented "-id" parameter for "init-config". One could just change the id-string within the previously made saveState file and use it in patching. But it was advised against that, since a patch might introduce new parameters which cannot be left unspecified in (new version of) saveState file.

    Still, I did patched one of the servers and run "init-config" manually with saving new saveState file. Then I compared it with previous one (4 patch revisions older) and the only difference was this id-string. So, that probably meant this method will work after all, although I agree we cannot be certain what configuration paremeters changes new patches might bring.

    Thanks for the tip :-)

    Ivan

    1. Sep 05, 2013

      Hi Ivan,

      If you have confirmed that there is no other changes between the savestate file you have and one generated by the latest patch, it is ok to use the silent config. We do have an internal wiki on how to do that. We haven't made it public because it might lead to issues if used for upgrades where there are changes in init-config.

      Send me an email and I can share the internal wiki with you if you want.

      Ciny (ciny.joy@oracle.com)

    2. Sep 05, 2013

      The Calendar Server patching used to behave the same like the Convergence patching where it will find the most recent saveState file, generate a new id from the current configurator, replace the id in a copy of the saveState file and use that to run silent init-config.  This behavior was abandoned when the ischedule database was introduced and the patching failure was creating much confusion.  In any case, please note that the configurator in the upcoming patch release is going to change, and the saveState file in previous releases will no longer work.  The new silent install file format is simplified with just name-value pairs with no specific ID that ties the file to a specific build of the configurator.

  4. Sep 06, 2013

    Ciny, Chiu,

    Thank you both for replies. I have seen in the patch README that silent run on init-config was abandoned with patch revision -04. Your explanations clarified it further.

    As for these machines, I'll continue patching them by using silent configuration.

    I would like to see that that Wiki, Ciny, thank you very much. I'll send you an e-mail soon.

    All the best, Ivan

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.