This chapter explains how to upgrade your existing system to the latest release of Oracle Communications Calendar Server. If you are running Calendar Server 6 (also known as Sun Java System Calendar Server 6), you must migrate your data to Oracle Communications Calendar Server. See "Migrating to Calendar Server" for more information.
If your deployment uses document stores, upgrading requires you to also upgrade those document stores at the same time, as described in this chapter.
When performing an upgrade of Calendar Server, you must upgrade all front-end hosts and remote document store hosts (if applicable) to the same version. That is, you cannot have a deployment of mixed Calendar Server versions. Calendar Server upgrades may introduce back-end database schema changes, or the front-end hosts may access the database in a different way. Thus, all hosts must be at the same version.
Note:
If you are already running Calendar Server 8.0.0.4.0 with WebLogic server in front-end and want to upgrade to Calendar Server 8.0.0.5.0, run commpkg upgrade directly.For more information, see "Migrating to Calendar Server".
Each Calendar Server patch or release might require an upgrade to the database schema or structure. For example, a database table might be altered, or data in the database might be changed. This type of upgrade differs from a MySQL Server or Oracle Database version upgrade. If a Calendar Server database schema or structure upgrade is required, allow additional time for the overall Calendar Server upgrade, as the database upgrade can take a while, especially if the database is large.
Topics in this section:
Each database schema and structure has a Calendar Server back-end version number recorded in the database. Each Calendar Server version only runs with a single database schema version.
You cannot reverse or downgrade a database schema version to a previous version. Thus, always ensure that you take a full database backup prior to upgrading. Once a database is upgraded, if you attempt to revert to a previous Calendar Server version, the previous Calendar Server version does not recognize the newly upgraded database. However, not all Calendar Server versions involve a database schema upgrade. When this is the case, you can revert to a previous Calendar Server version without invalidating the databases. Use Table 9-1, "Database Schema Version Changes for Calendar Server Beginning with Release 7 Update 2" to understand which Calendar Server versions use the same database schema.
When Calendar Server starts up in the application server, it connects to each back-end database for which it is configured, one at a time, and attempts to open the database for normal operation.
During this initial opening of each database, Calendar Server checks the database schema version. Calendar Server has the option to either automatically upgrade the database immediately, or issue a logging message in the errors.0 log file explaining the database cannot be opened and needs to be upgraded.
Caution:
Never interrupt or stop either Calendar Server or the application server when the database is being upgraded. If you do, you must restore the database from backup.Calendar Server logs messages in the errors.0 log file when the database was opened but not that it was being upgraded. If the database has a large amount of data, the upgrade can take a long time and appear to resemble a database hang. See "Database Schema Upgrade Patches and Releases" for more information on Calendar Server versions that require a database upgrade.
You cannot reverse a database schema and structure upgrade once it has been performed. This is why, when performing a Calendar Server upgrade, you must make a backup before starting the upgrade process. Once a database is upgraded, it no longer works with a previous Calendar Server version. Use Table 9-1 to understand the Calendar Server database changes that have occurred.
Table 9-1 Database Schema Version Changes for Calendar Server Beginning with Release 7 Update 2
| Calendar Server Release | Database Change | Notes |
|---|---|---|
|
8.0.0.1 |
Automatic upgrade to version 10. |
Fairly intensive, depending on the size of existing data. |
|
8.0 |
No database changes. |
NA |
|
7.0.5.17.0 |
Automatic upgrade to version 9. |
No schema upgrade performance issues. |
|
7.0.4.16.0 |
No database changes. |
NA |
|
7.0.4.15.0 |
No database changes. |
NA |
|
7.0.4.14.0 |
Automatic Upgrade to Version 8. (MySQL Server only) The charset and collation of most tables and fields is changed to utf8mb4.
Column added to CalProp.
|
Fairly intensive for MySQL Server. |
|
7.0.3.8.0 |
Automatic Upgrade to Version 7. Full table scan fixes missing values in Resources.resourcetype = 'CAL_RESOURCE';. |
NA |
|
7.0.2.4.0 |
Automatic Upgrade to Version 6.
|
NA |
How a database performs during an upgrade depends on data size and hardware. Some database operations, such as copying the entire table, are intensive operations and can take a long time to complete. When a database has 4 million rows or 40 gigabytes of data, study the database performance to better understand potential upgrade times.
MySQL Server and Oracle Database have relevant buffer cache settings that can increase performance. Additionally, if the database can fit in the cache completely with extra space, then operations might run faster.
If the database and temporary table operations exceed the database cache, then the disk IO throughput becomes very relevant. Disk IO is also significant when there is plenty of cache because the cache must be loaded at times.
MySQL Server also has memory and cache parameters such as innodb_buffer_pool_size, while Oracle Database has parameters such as sga_target. Refer to the MySQL Server and Oracle Database documentation for more information on performance tuning.
In general, upgrading the database schema should not take a long time. However, there are some exceptions. See Table 9-1, "Database Schema Version Changes for Calendar Server Beginning with Release 7 Update 2" for more information. Additionally, as explained in "Database Performance During Upgrade," other factors can impact the time required to upgrade the database schema, and thus the overall Calendar Server upgrade time.
To increase database upgrade functionality and flexibility, you can use the davadmin db schema_fullupgrade and davadmin db schema_preupgrade commands. Table 9-2 describes these two commands.
Table 9-2 Comparison of schema_fullupgrade and schema_preupgrade
| Description of schema_fullupgrade | Description of schema_preupgrade |
|---|---|
|
The schema_fullupgrade command fully upgrades the back-end database schema. The schema_fullupgrade command performs all upgrade functions on the database, including upgrading the presence and all database tables for charset. The schema_fullupgrade command is the same as starting a new Calendar Server instance, which upgrades the database. Use this command to upgrade multiple back-end databases in parallel instead of one at a time, as happens during the normal Calendar Server upgrade process. For example, if your deployment consists of four back-end databases, instead of going through the normal upgrade process where upgrading a front-end host then initiates the back-end database upgrade, one at a time, you can upgrade the front-end hosts then upgrade all back-end databases in parallel by using the schema_fullupgrade option. After running the schema_fullupgrade command and the database schema upgrade completes, you cannot revert to the previous schema. In addition, Calendar Server front-end hosts that run a prior software version are not able to communicate with the database that has had its schema upgraded. |
The schema_preupgrade command enables you to perform online database DDL changes, as well as a partial offline upgrade, as long as the release contains database schema updates. (Not all releases update the database schema, so schema_preupgrade might not apply.) For example, if your deployment contains a large amount of data, you can save time by pre-upgrading the database schema in advance of the formal Calendar Server software upgrade. The schema_preupgrade command does not change the database schema version, and therefore, Calendar front-end hosts continue to be able to communicate with the pre-upgraded database without having to be upgraded themselves. You specify the function to upgrade by using with the -z preupgradefunction option. See Table 9-3 for a list of functions by release. For example, if a Calendar Server upgrade adds a new column to the database, you can run the schema_preupgrade command to add that column to the current database. The Calendar Server front-end hosts, which have not yet been upgraded themselves, continue to have the capability to run with the pre-upgraded database version. When you later perform the formal Calendar Server software upgrade, the schema update has already been done, and so you save time on completing the overall upgrade process. |
See the davadmin db schema_fullupgrade and davadmin db schema_preupgrade commands in "Calendar Server Command-Line Utilities" in Calendar Server System Administrator's Guide for more information.
The davadmin db schema_preupgrade -z preupgradefunction command enables you to specify which pre-upgrade function(s) to run on the database. Table 9-3 describes the available functions by release.
Table 9-3 schema_preupgrade Functions
| Database Version | Function | Description |
|---|---|---|
|
Version 8 |
v8presence |
Upgrades for presence for both MySQL Server and Oracle Database |
|
Version 8 |
v8charsetresources |
MySQL only. |
|
Version 8 |
v8charsetcalprop |
MySQL only. |
|
Version 8 |
v8charseticalprop |
MySQL only. |
|
Version 8 |
v8charsetxprop |
MySQL only. |
|
Version 8 |
v8charsetcollection |
MySQL only. |
|
Version 8 |
v8charsetowner |
MySQL only. |
|
Version 8 |
v8charsetcontent |
MySQL only. |
|
Version 8 |
v8charsetattachment |
MySQL only. |
|
Version 8 |
v8charset |
MySQL only. Upgrades all tables for charset |
Table 9-4 describes the upgrade dependencies on Java, MySQL Server, application server, and other components for Calendar Server.
Table 9-4 Calendar Server Upgrade Dependencies
| Upgrade Dependency | Introduced in Which Calendar Server Version? |
|---|---|
|
Upgrading to Solaris 11. |
Calendar Server 8 is supported on Solaris 11 only. If you are running Calendar Server 7 on Solaris 10, you must upgrade to Solaris 11 before upgrading to Calendar Server 8. |
|
Deciding if you must change the LDAP attribute used as the unique identifier for your Calendar Server deployment. |
Starting with Calendar Server 7 Update 3, if you initially deployed Calendar Server 7 Update 2 and prior to use the nsUniqueId attribute as your unique identifier, you should switch to using the davUniqueId attribute. |
|
Installing Java 7 on all Calendar Server hosts, including front ends and document store hosts. |
Starting with version 7.0.4.15.0, Calendar Server requires Java 7. |
|
Installing and running the comm_dssetup script against your Directory Server hosts. |
Starting with version 7.0.4.14.0, Calendar Server requires that at least comm_dssetup.pl 6.4.0.25.0 be run against your Directory Servers. |
|
Upgrading MySQL to at least 5.5 (5.5.8 or greater). |
Starting with Calendar Server 7 Update 2, you must use at least MySQL 5.5.8. Note that starting with Calendar Server 7.0.5, MySQL 5.6 is supported. |
|
Making database charset change for installations using MySQL as the back-end database. |
Calendar Server 7.0.4.14.0 and greater requires the MySQL Server default character set be set to utf8mb4. This is to support 4-byte Unicode, which the older MySQL UTF-8 character set does not support. |
|
Creating the iSchedule database and granting permission to caldav user to access the iSchedule database. |
If you are upgrading from Calendar Server 7 or Calendar Server Update 1, you must manually create the iSchedule database. |
|
Installing GlassFish Server 3.1.2 |
Calendar Server 7.0.4.14.0 and greater requires that you use GlassFish Server 3.1.2 as its web container. |
|
Running davadmin account upgrade. |
Starting with version 7.0.4.14.0, Calendar Server requires that you run this command to set the next presence triggers for all existing events in the future. |
The next section describes the actual upgrade procedures and indicates where the preceding dependencies apply.
This section describes how to upgrade to Calendar Server 8.0. Depending on your current Calendar Server version, some steps are not required.
Before upgrading Calendar Server, you must:
Upgrade to Solaris 11, if you are currently running Calendar Server 7 on Solaris 10.
Download the necessary software.
Download the Calendar Server software and Directory Server setup script, comm_dssetup, either as part of a media pack, or as a patch.
Download the media pack from the Oracle software delivery website.
Download a Calendar Server patch or Directory Server setup patch from My Oracle Support.
If upgrading from Calendar Server 7 Update 1 or prior version: download MySQL Server 5.5.8 or later from My Oracle Support.
The MySQL download is available in both PKG and TAR versions. This documentation uses the PKG version to show installation and configuration, so in most cases, choosing the PKG version makes sense.
Starting with version 7 Update 2, Calendar Server requires that you upgrade to MySQL Server 5.5.8 or any later 5.5.x version. As of Calendar Server 7.0.5, MySQL 5.6 is supported. See "Upgrading the Calendar Server Back-End Database".
If you are running a 5.5.x version prior to 5.5.32, you can choose to upgrade but it is not necessary.
Download the GlassFish Server 3.1.2 software from My Oracle Support.
Download the Java 7 software from Java SE Downloads at:
http://www.oracle.com/technetwork/java/javase/downloads/index.html
Place the software on the appropriate hosts.
On Calendar Server front-end hosts, and, if applicable, remote document store hosts, create a temporary directory (for example, /temp/CS8), and extract the Calendar Server media pack zip file or Calendar Server patch zip file in this directory.
If you are upgrading MySQL Server, on the Calendar Server back-end hosts, create a temporary directory (for example, /temp/MySQL), and extract the MySQL Server package in this directory.
If you are upgrading the application server, on the Calendar Server front-end hosts, create a temporary directory (for example, /temp/GF3), and extract the application server zip file in this directory.
On Calendar Server front-end hosts, and, if applicable, remote document store hosts, place the Java 7 software.
The purpose of backing up the database is in case you must restore the previous Calendar Server version and database. However, database backups are not compatible across releases because backups include database internals specific to the version.
For more information, see the topic on backing up and restoring files and data in Calendar Server System Administrator's Guide.
You may be able to upgrade parts of the database schema as a separate step, outside of and in advance of, the formal Calendar Server upgrade process, if pre-upgrade functions exist for the release. (Not all Calendar Server versions update the database schema, so this capability might not apply.) Before upgrading the database schema, ensure that you understand the implications as described in "About Upgrading the Database Schema". Also, review Table 9-1, "Database Schema Version Changes for Calendar Server Beginning with Release 7 Update 2" to confirm if the Calendar Server version upgrades the database schema. See the topic on the davadmin db schema_preupgrade command in Calendar Server System Administrator's Guide for more information.
Calendar Server 7.0.4.15.0 and greater requires that you use Java 7. If you have previously upgraded to Calendar Server 7.0.4.15.0, you should have already performed this step.
Note:
In Calendar Server 8.0.0.4.0 the WebLogic container support is added and it requires Java 8. Therefore, ensure that you have performed the instructions specific to WebLogic Server provided in "Calendar Server Pre-Installation Tasks" and "Configuring Java for Calendar Server".The 32-bit and 64-bit JDKs require manual installation. Install both JDKs, rather than the JRE, on your front-end hosts
Note:
If you changed the Java 6 java.policy file, then you must do the same to the Java 7 file. If you installed Java 6 certificates in the cacerts file, you must also install those certificates in Java 7. See the Java 7 documentation for more information on these items.If you have previously upgraded to Calendar Server 7.0.4.14.0, you should have already performed this step. Calendar Server 7.0.4.14.0 and greater requires that at least comm_dssetup.pl 6.4.0.25.0 be run against your Directory Server hosts. Before you can upgrade to Calendar Server 8.0, you must run the comm_dssetup.pl script (minimum version 6.4.0.25.0) on each Directory Server in your deployment. This version of comm_dssetup.pl applies the required Directory Server index on the davUniqueId attribute for Calendar Server.
To run comm_dssetup.pl:
On each Directory Server host, run commpkg install (or commpkg upgrade if comm_dssetup.pl exists already on the host), and select only Comms DSsetup 6.4.
On each Directory Server host, run the comm_dssetup.pl script to apply the schema updates.
For example:
/opt/sun/comms/dssetup/sbin/comm_dssetup.pl
Respond to the prompts.
For more information, see "comm_dssetup.pl Reference".
This section assumes that you have previously put the Calendar Server software onto each Calendar Server front-end host and remote document store host, if applicable. If instead you are performing an upgrade of the Calendar Server software by applying a patch, see the instructions in "Installing Patches" then return to this chapter to resume the upgrade process.
On the Calendar Server front-end hosts, run commpkg upgrade and select the Calendar Server component.
For more information, see "upgrade Verb Syntax".
If the upgrade detects a problem during the pre-upgrade phase, correct the problem and re-run the upgrade.
If you have remote document stores, continue with the next section.
When upgrading Calendar Server front-end hosts, you must also upgrade the remote document store hosts at the same time. These instructions describe both how to upgrade document stores that are not configured to use SSL, and how to add SSL if you choose. These instructions also assume that you have downloaded and extracted the Calendar Server software zip file or Calendar Server patch zip file onto the remote document store hosts.
Topics:
To upgrade a document store that is not configured for SSL:
Perform the following steps on the remote document store host.
Stop the document store server.
cd CalendarServer_home/sbin
stop-as
Upgrade the Calendar Server software by launching the installer and choosing Calendar Server. If you are applying a patch, see the instructions in "Installing Patches" then return to this chapter to resume the upgrade process.
commpkg upgrade
Configure the document store and set the password.
cd CalendarServer_home/sbin configure-as Do you want to set the document store password (y/n)? [n] y Enter the document store password: password Reenter the document store password: password Do you want to set the document store SSL passwords (y/n)? n Please check the values in /var/opt/sun/comms/davserver/config/ashttpd.properties are correct before starting the server with start-as To stop the server, run stop-as
Start the document store server.
cd CalendarServer_home/sbin
start-as
Perform the following steps on the Calendar Server front-end host after you have upgraded the Calendar Server software.
Set the same document store password that you used during the configuration on the document store host.
cd CalendarServer_home/sbin davadmin passfile modify Enter Admin password: password Enter the Password File password: password Do you want to set the app server admin user password (y/n)? [n] Do you want to set the database password (y/n)? [n] Do you want to set the migration server user password (y/n)? [n] Do you want to set the document store password (y/n)? [n] y Enter the document store password: <Enter the same password that you used when running the configure-as command on the document store host.> Reenter the document store password: password Do you want to set the document store SSL passwords (y/n)? [n] n Set new value for store.document.password.
Restart the application server.
Starting with Calendar Server 7.0.4.14.0, you can configure the Secure Sockets Layer (SSL) protocol between the Calendar Server front ends and back ends, including the remote document store.
To upgrade a non-SSL document store to SSL:
Perform the following steps on the remote document store host.
Stop the document store server.
cd CalendarServer_home/sbin
stop-as
Upgrade the Calendar Server software by launching the installer and choosing Calendar Server. If you are applying a patch, see the instructions in "Installing Patches" then return to this chapter to resume the upgrade process.
commpkg upgrade
Create a self-signed certificate.
keytool -genkeypair -alias alias -keyalg RSA -validity 365 -keysize 2048 -keystore path/keystore_name.jks
Export the certificate and copy it to the Calendar Server host.
keytool -export -alias alias -keystore path/keystore_name.jks -rfc -file path/certificate.cert
Configure the document store.
cd CalendarServer_home/sbin configure-as Do you want to set the document store password (y/n)? [n] y Enter the document store password: password Reenter the document store password: password Do you want to set the document store SSL passwords (y/n)? [n] y Enter the document store SSL keystore password: <Enter the same password that you used when creating the self-signed certificate, that is, the keystore password> Reenter the document store SSL keystore password: password Enter the document store SSL certificate password: <Enter the same password that you used when creating the self-signed certificate, that is, the keystore password> Reenter the document store SSL certificate password: password Please check the values in /var/opt/sun/comms/davserver/config/ashttpd.properties are correct before starting the server with start-as To stop the server, run stop-as Document Store server is now configured
Add the following lines to the ashttpd.properties file.
store.usessl=true store.sslkeystorepath=path/keystore_name.jks
Start the document store.
Perform the following steps on the Calendar Server front-end host after you have upgraded the Calendar Server software.
Import the certificate (the certificate that you copied from the document store host) into the TrustStore on the application server host where you have deployed Calendar Server.
keytool -importcert -alias alias -file path/certificate.cert -keystore /opt/glassfish3/glassfish/domains/domain1/config/cacerts.jks
List the KeyStore to ensure that the alias exists.
keytool -list -keystore /opt/glassfish3/glassfish/domains/domain1/config/cacerts.jks -alias alias
Set the same document store password that you set during the document store configuration.
davadmin passfile modify Enter Admin password: password Enter the Password File password: password Do you want to set the app server admin user password (y/n)? [n] Do you want to set the database password (y/n)? [n] Do you want to set the migration server user password (y/n)? [n] Do you want to set the document store password (y/n)? [n] y Enter the document store password: <Enter the same password that you gave during configure-as on document store host> Reenter the document store password: password Do you want to set the document store SSL passwords (y/n)? [n] n Set new value for store.document.password. A server restart is required for this change to take effect.
Set the store.document.usessl configuration parameter to true.
davadmin config modify -o store.document.usessl -v true
Enter Admin password: password
Set new value for store.document.usessl. A server restart is required for this change to take effect.
Restart the application server.
Ensure that you are running a supported database as described in "Required Software". If you are running MySQL Server 5.1, which was part of the Calendar Server 7 Update 1 version, you must upgrade to at least MySQL Server 5.5.8.
Refer to the appropriate MySQL Server and Oracle Database documentation for instructions about upgrading your database.
Before upgrading your database, always make a full backup, for example, by using the davadmin command:
davadmin db backup -k backup_file
Additionally, you might want to dump the Calendar Server back-end data in case a problem happens during the upgrade and you must reload your data. For example, on MySQL Server, run the following command:
mysqldump --user=caldav --password=mypassword --all-databases > myDataDump.sql
Also, you must stop the Calendar Server front-end services by shutting down the application server domain before starting the database upgrade.
When upgrading MySQL Server, ensure that you make the following changes in the /etc/my.cnf file:
Ensure that the my.cnf file includes the transaction isolation level additional configuration parameter:
transaction-isolation = READ-COMMITTED
If you use replication, use the following ROW binary logging, instead of the default STATEMENT logging. Add the following to the my.cnf file:
binlog-format=ROW
If you use log_long_format, it is no longer supported in MySQL 5.5.8. Remove it from the my.cnf file, otherwise MySQL Server does not start.
If you have previously upgraded to Calendar Server 7.0.4.14.0, you should have already changed the character set. Calendar Server 7.0.4.14.0 and greater requires the MySQL Server default character set be set to utf8mb4. This is to support 4-byte Unicode, which the older MySQL UTF-8 character set does not support.
To set the MySQL Server default character set:
Edit the /etc/my.cnf file.
Change the following line:
character-set-server = utf8
to
character-set-server = utf8mb4
If you have previously upgraded from Calendar Server 7 or Calendar Server 7 Update 1, you should have already created the iSchedule database. Calendar Server 7 Update 1 and greater requires that the iSchedule database exist, even if you do not use it.
Depending on your database, run the appropriate command:
MySQL Server: config-mysql --ischedule
Oracle Database: config-oracle --ischedule
Note:
You cannot use the config-oracle script for an Oracle Database 12c container database (that is, one that uses a pluggable database). Instead, you must manually create the iSchedule database for an Oracle Database 12c container database. See "Preparing Oracle Database 12c Container Database" for more information on the manual steps to create the iSchedule database.For more information, see "Running the config-mysql Script" or "Running the config-oracle Script".
If you are previously upgraded to Calendar Server 7.0.4.14.0, you should have already performed this step. Starting with version 7.0.4.14.0, Calendar Server requires that you use GlassFish Server 3.1.2 as its web container. You do not need to upgrade your current GlassFish 2.1.1 version. Instead, you install GlassFish Server 3.1.2 on another location using either the existing port used by GlassFish Server 2.1.1 or a new port. Then, when you run the Calendar Server init-config command, you enter the new values for the GlassFish Server 3.1.2 installation.
See Oracle GlassFish Server 3.1.2 Installation Guide for instructions on installing GlassFish Server software.
After installing GlassFish Server 3.1.2, enable secure administration.
The GlassFish Server secure administration (secure admin) feature enables you to secure all administrative communication between the server and administration clients such as the asadmin utility and the administration console.
/opt/glassfish3/bin/asadmin enable-secure-admin You must restart all running servers for the change in secure admin to take effect. Command enable-secure-admin executed successfully. /opt/glassfish3/bin/asadmin restart-domain Successfully restarted the domain Command restart-domain executed successfully.
Upgrading to Java 7 requires that you make the following environment variable changes. If you have previously upgraded to Java 7, you should have already performed these steps.
Set the JAVA_HOME environment variable to Java 7 in the login profile of the application server runtime user, or create a symbolic link for /usr/jdk/latest to the Java 7 location.
Stop GlassFish Server.
Set GlassFish_home/glassfish/config/asenv.conf to the Java 7 location.
Restart GlassFish Server.
Note:
If you use WebLogic Server, you must install Java version 8. For more information, see "Installing Java".If you use WebLogic Server, you must install Java 8. You must also set JAVA_HOME and PATH environment variables accordingly to the JDK 1.8.0 latest update version.
Ignore this step if you have already switched to using the davUniqueId attribute. 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, which was introduced in Calendar Server 7 Update 3. For more information on the problems with using nsUniqueId, see "Changing the User Unique Identifier". For information on the davUniqueId attribute, see Communications Suite Schema Reference Guide.
To run the populate-davuniqueid script to populate, in LDAP, calendar users, groups, and resources with the davUniqueId attribute:
You can run the script interactively or with supplied parameters. For more information, see "populate-davuniqueid Examples". Here is a sample populate-davuniqueid session:
/opt/sun/comms/davserver/sbin/populate-davuniqueid Directory host: ds.example.com Directory user bind DN: admin Directory user bind password: Directory search base: o=isp Output to file: popdavunique-output Please check the following information Directory host: ds.example.com Directory port: 389 Directory user bind DN: admin Directory user bind password: as specified Directory search base: o=isp Directory search filter: (|(objectclass=icscalendaruser)(objectclass=icscalendarresource)(objectclass=groupofuniquenames)(objectclass=groupofurls)(objectclass=inetmailgroup)) Output to: popdavunique-output Add daventity objectclass: no Load output LDIF automatically: no Do you want to continue (y/n)?:
Use the davadmin command to modify the davcore.uriinfo.permanentuniqueid configuration parameter to davUniqueId.
You must do this, even though you set davUniqueId when running the Calendar Server configurator, because the merge-config script resets this. For example:
davadmin config modify -u admin -o davcore.uriinfo.permanentuniqueid -v davuniqueid
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:
davadmin config list -u admin -o davcore.uriinfo.subjectattributes davcore.uriinfo.subjectattributes: cn davstore icsstatus mail mailalternateaddress nsuniqueid owner preferredlanguage uid objectclass ismemberof uniquemember memberurl mgrprfc822mailmember kind davadmin config modify -u admin -o davcore.uriinfo.subjectattributes -v "cn davstore icsstatus mail mailalternateaddress davuniqueid owner preferredlanguage uid objectclass ismemberof uniquemember memberurl mgrprfc822mailmember kind"
To perform the Configuration:
Note:
The following steps are applicable only if you use GlassFish Server.Run the init-config script to enter the current deployment configuration values.
That is, when prompted for the Application Server Configuration Details, use the values for your GlassFish Server 3.1.2 installation. Be sure to enter davUniqueId if you chose that as the new unique LDAP attribute.
Run the merge-config script 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 script.
For example, you might have customized configuration parameters in the davserver.properties file.
If necessary, resolve any problems.
If the upgrade detects a problem during the post-upgrade phase with merging configuration files, reconcile the merged files.
If you have previously upgraded to Calendar Server 7.0.4.14.0, you should have already performed this step. The davadmin account upgrade operation sets the next presence triggers for all existing events in the future. You must run davadmin account upgrade after upgrading Calendar Server to set the presence triggers for existing future events.
To set presence triggers after upgrading:
davadmin account upgrade
Currently, davadmin account upgrade does not print a message either while it is running or when it completes. The davadmin account upgrade command could take some time to complete, so allow it to finish. While davadmin account upgrade is running, it does not impact any Calendar Server functionality.
Complete all of the following post-upgrade tasks after upgrading Calendar Server, if necessary. See "Calendar Server Post-Installation Tasks" for more information.