Upgrading to Oracle Communications Calendar Server 7 Update 3

Skip to end of metadata
Go to start of metadata

Upgrading to Oracle Communications Calendar Server 7 Update 3

This information describes how to upgrade from Calendar Server 7 Update 2 to Calendar Server 7 Update 3. If you need to upgrade from Calendar Server 7 to Calendar Server 7 Update 2, see upgrading to Calendar Server 7 Update 2. If you need to migrate to Calendar Server 7 from Calendar Server 6, see Migrating From Sun Java System Calendar Server 6 to Calendar Server 7.

Notes
  • Upgrading to Calendar Server 7 Update 3 requires that you first upgrade your LDAP schema with some new elements required by Calendar Server. To do so, you need to apply the comm_dssetup 6.4 patch and run the updated comm_dssetup script against your Directory Server instances, as explained later in these instructions.
  • Calendar Server 7 Update 3 is the product version attained by applying Calendar Server 7 patch 8 (patch ID 142785/142786/142787-08).
  • If your deployment uses document stores, upgrading to Calendar Server 7 Update 3 requires you to also update those document stores at the same time, as documented in these instructions. This upgrade contains a new authentication mechanism and a new shared secret (password) for the server and the document stores and must be created.

Topics:

Prerequisites for Upgrading to Calendar Server 7 Update 3

  1. Decide if you want to change the attribute used for the unique identifier for your Calendar Server deployment.
    If, when you initially installed Calendar Server 7, you chose to use nsUniqueID as your unique identifier, you should change to davUniqueId. For more information, see How Does Calendar Server Use a Unique Identifier?.
  2. Download the necessary software.
    1. Download Calendar Server 7 Update 3 (patch 8) and the Communications Suite comm_dssetup 6.4 patch from https://support.oracle.com:
      Patch Download Links
      Patch Download Link
      Calendar Server 7 Update 3 (Solaris) 142785-08
      Calendar Server 7 Update 3 (Solaris x86) 142786-08
      Calendar Server 7 Update 3 (Linux) 142787-08
      comm_dssetup (Solaris SPARC) 118245-24
      comm_dssetup (Solaris x86) 118246-24
      comm_dssetup (Linux) 118247-24
  3. Place the software on the appropriate hosts.
    1. On Calendar Server 7 Update 2 front-end hosts, and, if applicable, remote document store hosts, create a temporary directory (for example, /temp/CS7U3), and unzip the Calendar Server 7 Update 3 patch zip file in this directory.
    2. On the Directory Server hosts, create a temporary directory (for example, /temp/commdssetup), and unzip the comm_dssetup zip file in this directory.

Upgrading comm_dssetup

Before you can upgrade Calendar Server 7 Update 2 to Calendar Server 7 Update 3, you need to upgrade the comm_dssetup.pl script by applying the 6.4 patch and then run the upgraded comm_dssetup.pl script on each Directory Server in your deployment. This new version of the comm_dssetup.pl script applies new schema elements that are required for Calendar Server 7 Update 3. For more information on new schema in Calendar Server 7 Update 3, see New Schema Objects.

To upgrade comm_dssetup.pl and the Directory Server schema:

  1. On each Directory Server host, apply the comm_dssetup.pl script patch.
    For example:
  2. On each Directory Server host, run the comm_dssetup.pl script to apply the schema updates.
    For example:
  3. Respond to the prompts.
    For more information, see Communications Suite Directory Server Setup Script (comm_dssetup.pl).
  4. Continue with the next section, Upgrading to Calendar Server 7 Update 3.

Upgrading to Calendar Server 7 Update 3

If you initially deployed Calendar Server 7 Update 2 to use the nsUniqueId attribute as your unique identifier, you should switch to using the davUniqueId attribute, new in Calendar Server 7 Update 3. For more information on the problems with using nsUniqueId, see Changing User uuid. For information on the davUniqueId attribute, see davUniqueId in the Communications Suite Schema Reference Guide.

Topics in this section:

To Upgrade to Calendar Server Update 3 for Deployments that Are Using nsUniqueId as the Unique Identifier with 7 Update 2

For an upgrade from Calendar Server 7 Update 2 to Update 3, and to use the davUniqueId attribute:

  1. Apply the Calendar Server 7 Update 3 patch.
    See To Install a Calendar Server 7 Patch to upgrade from 7 Update 2 to Update 3 by applying the Calendar Server 7 Update 3 patch 8 (142785/142786/142787-08).
  2. Run the populate-davuniqueid tool to populate, in LDAP, calendar users, groups, and resources with the davUniqueId attribute. You can run the tool interactively or with supplied parameters. For more information on running the populate-davuniqueid tool, see populate-davuniqueid Usage. Also, see this known issue when existing LDAP entries already have the davEntity object class: 14781101.
    Here is a sample populate-davuniqueid session:
  3. Use the davadmin command to modify the davcore.uriinfo.permanentuniqueid configuration parameter to davUniqueId.
    You need to do this, even though you set davUniqueId in the configurator, because the merge-config command resets this. For example:
  4. Use the davadmin command to both obtain the value of and modify the davcore.uriinfo.subjectattributes configuration parameter to add davUniqueId to its list of attributes value.
    For example:
  5. Restart GlassFish Server.
    For example:
  6. If you have remote document stores, see Upgrading the Calendar Server Document Store.

To Upgrade to Calendar Server Update 3 for Deployments that Are Not Using nsUniqueId as the Unique Identifier with 7 Update 2

For an upgrade from Calendar Server 7 Update 2 to Update 3, without any change to the current unique identifier:

  1. On each Calendar Server front-end host, apply the Calendar Server 7 Update 3 patch.
    See To Install a Calendar Server 7 Patch to upgrade from 7 Update 2 to Update 3 by applying the Calendar Server 7 Update 3 patch 8 (142785/142786/142787-08).
  2. If you have remote document stores, see Upgrading the Calendar Server Document Store.

Upgrading the Calendar Server Document Store

Use this procedure if your deployment contains a remote document store.

  1. On each remote document store host, perform the following steps:
    1. Stop the document store.
    2. Change to the directory where you unzipped the Calendar Server 7 Update 3 software, for example, (/temp/CS7U3) and apply the Calendar Server patch.
    3. Start the document store:
  2. Set the remote document store passwords.
    Starting in Calendar Server 7 Update 3, the remote document store requires password authentication. See To Configure Remote Document Store Authentication for more information.
Labels:
calendarserver calendarserver Delete
cs73 cs73 Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Nov 13, 2012

    I would have appreciated a note, that frontend and document store need to be patched/updated at the same time (which is a rather unexpected necessity)  since the introduction of the feature to set a custom password for document store access does not seem to preserve the former (hardcoded) password.

  2. Nov 13, 2012

    Jens,

    Would a note at the top of the page that read, "If your deployment uses document stores, upgrading to Calendar Server 7 Update 3 requires you to also update those Document Stores at the same time, as documented on this page." be sufficient or do we need more guidance with each of the steps?

    Erwin

  3. Nov 14, 2012

    Hi Erwin,

    I think that will help people like me to identify it as a must requirement. Maybe one should mention the most prominent reason, namely the mandatory need to establish a new shared secret (password).

    Thanks

    Jens

    1. Nov 15, 2012

      Jens, Erwin:

      See the additional info I have added to the note at the beginning of these instructions.

      Thx,

      Joe

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.