10 Creating a Calendar Server 6 and 7 Coexistent Deployment

This chapter describes how to set up Oracle Communications Calendar Server 7 in an existing Sun Java Calendar Server 6 deployment. In this environment, you have some users who have migrated to Calendar Server 7 and some users that still exist on Calendar Server 6. In such a deployment, you enable both free/busy lookup and iCalendar Message-Based Interoperability Protocol (iMIP) invitation between the two Calendar Server deployments. That is, users should have the capability to check free/busy information of users on any server, and the capability to invite any user. Invitations to users on a different server would be delivered by using iMIP.

Note:

In this coexistent deployment, users are either on Calendar Server 7 or Calendar Server 6. They do not have calendars on both Calendar Server 7 and Calendar Server 6.

For more information on performing a Calendar Server 7 migration, see "Migrating to Calendar Server."

Topics:

Calendar Coexistence Overview
Minimum Software Requirements
Configuring the Calendar Server 6 Environment
Configuring the Calendar Server 7 Environment
Workflow Description of This Configuration

Calendar Coexistence Overview

For coexistence to work, each calendar server needs to be able to determine if users are Calendar Server 6 or Calendar Server 7 users.

On Calendar Server 7 servers:

Users are identified as Calendar Server 7 users by the presence in their Directory Server LDAP entry of a particular attribute which is configured as described in "Configuring the Calendar Server 7 Environment." For more information on how Calendar Server uses Directory Server, see the topic on Calendar Server and Directory Server integration in Calendar Server Concepts.
All other users that are part of the deployment but do not have this attribute set are considered Calendar Server 6 users.

On Calendar Server 6 servers:

Users are identified as Calendar Server 6 users if they already have a calendar created in the data base.
All other users are considered Calendar Server 7 users.

For coexistence to function correctly, you must disable user auto-provisioning on all Calendar Server 6 servers.

In addition, the same unique ID attribute that you use for Calendar Server 7 users needs to be present in all Calendar Server 6 users too. This attribute defines the unique value used as the database identifier for each account. This value is used internally to identify a user in other user's access control entries, subscription entries, and so on. The attribute chosen as the unique ID attribute must be present in all user, group, and resource LDAP entries for the deployment.

For example, if Calendar Server 6 uses uid as its unique identifier and you configure Calendar Server 7 to use davuniqueid as the unique identifier, you must add the new unique identifier not only to the users migrated to Calendar Server 7, but also to the users remaining on Calendar Server 6 for co-existence to work.

For information on migrating a Calendar Server 6 deployment to Calendar Server 7, see "Migrating to Calendar Server."

Minimum Software Requirements

Calendar Server 6.3: At least patch level 44.
Calendar Server 7: At least Calendar Server 7 Update 1.

Configuring the Calendar Server 6 Environment

Perform the following steps on the Calendar Server 6 host.

Patch the server to the following:
- 121657-37 - Solaris SPARC
- 121658-37 - Solaris x86
- 121659-37 - Red Hat Linux
Edit the ics.conf file as follows:

For Solaris, edit /etc/CalendarServer_home/SUNWics5/config/ics.conf.

For Red Hat Linux, edit /etc/CalendarServer_home/calendar/config/ics.conf.
- Set service.http.caldavcompatible = "yes".
- Set the option for free/busy redirection to point to the Calendar Server 7 server's free/busy URL. If the Calendar Server 7 servers have a multiple front-end and back-end setup, use any front-end's information. The service.wcap.freebusy.redirecturl parameter must include the port number of the Calendar Server 7 host.
  
  For example:
```
service.wcap.freebusy.redirecturl = "http://cs7u1server.example.com:8080/davserver/wcap/get_freebusy.wcap"
```
- Disable autoprovisioning by setting the value of local.autoprovision, user.invite.autoprovision, group.invite.autoprovision, and resource.invite.autoprovision to no.
  
  For example, the changes resemble the following:
```
service.http.caldavcompatible = "yes"
service.wcap.freebusy.redirecturl = "http://cs7u1server.example.com:8080/davserver/wcap/get_freebusy.wcap"
local.autoprovision ="no" 
user.invite.autoprovision = "no" 
group.invite.autoprovision = "no" resource.invite.autoprovision = "no"
```
  Note:
  In the preceding examples, the service.wcap.freebusy.redirecturl is directed to a Calendar Server 7 host, with a port assignment of 8080.

Restart the Calendar Server 6 server:

cd /opt/sun/comms/calendar/SUNWics5/cal/sbin 
./stop-cal 
./start-cal

For migrated Calendar Server 6 users, perform the following steps on the Calendar Server 6 host:
1. Delete Calendar Server 6 calendars by using cscal delete -o uid.
2. Set the LDAP attribute icsAllowedServiceAccess to -http:all. The setting ensures that Calendar Server 6.3 users no longer log in by mistake and cause calendars to be autocreated.

Configuring the Calendar Server 7 Environment

Perform the following steps on the Calendar Server 7 host.

Change to the CalendarServer_home/config directory and either edit or create the ischeduledomainmap.properties file.
Add a line that contains your domain name and the Calendar Server 6 URL to connect to for Calendar Server 6 user inquiry. If the Calendar Server 6 host is set up for multiple front ends and back ends, you can use any front-end server information.

For example:
```
example.com=http://cs6server.example.com:8080/ischedule/
```
Set davcore.scheduling.localuserattr parameter, which identifies an LDAP entry as that belonging to a Calendar Server 7 account. The recommended value is davstore.

For example:
```
./davadmin config modify -o davcore.scheduling.localuserattr -v davstore
```
Add the same value that you used for the davcore.scheduling.localuserattr parameter to the davcore.uriinfo.subjectattributes parameter.

For example:
```
./davadmin config modify -o davcore.uriinfo.subjectattributes -v davstore
```
If you are using an attribute other than davstore for the davcore.scheduling.localuserattr parameter, add it to the davcore.uriinfo.subjectattributes parameter too. Use the davadmin config command to first retrieve the current value of davcore.uriinfo.subjectattributes, then add the new attribute at the end of the list.

For example:
```
./davadmin config -o davcore.uriinfo.subjectattributes
davcore.uriinfo.subjectattributes: cn davstore icsstatus mail

./davadmin config -o modify davcore.uriinfo.subjectattributes -v "cn davstore icsstatus mail xcs7user"
```
On the Directory Server, use an LDAP client to verify that the LDAP attribute defined is present for all users who are on the Calendar Server 7 server. Also verify that the attribute is not present for users on the Calendar Server 6 host. If using davStore and it is a simple single back-end deployment, populate it with the value defaultbackend.

Workflow Description of This Configuration

This section contains the following topics:

About the Calendar Server 6 Configuration
About the Calendar Server 7 Configuration

About the Calendar Server 6 Configuration

On a Calendar Server 6 host, setting the service.http.caldavcompatible configuration parameter to yes, enables the capability to handle iSchedule style free/busy requests from the Calendar Server 7 host for users still on Calendar Server 6. The value for the service.wcap.freebusy.redirecturl configuration parameter specifies the free/busy redirect URL returned by the Calendar Server 6 host for an invitee not found in its local database. Setting the automatic provisioning configuration parameters to no (local.autoprovision, user.invite.autoprovision, group.invite.autoprovision, and resource.invite.autoprovision) ensures that on a scheduling invitation request, if the invitee calendar is not found on the local database, an iMIP invitation is sent instead of creating an account in the database.

About the Calendar Server 7 Configuration

When a scheduling invitation or free/busy request comes to a Calendar Server 7 host, the server performs a directory lookup to determine if each of the invitees is local. If the server option davcore.scheduling.localuserattr is set, the server additionally checks if the attribute specified by that option is set for each of the invitees found in the directory. If the attribute is set, the user is considered local to the Calendar Server 7 host. If the attribute is not set, the user is assumed to be on the Calendar Server 6 host.

If a user is on the Calendar Server 6 host, for scheduling free/busy lookup, the server uses the Calendar Server 6 host information in ischeduledomainmap.properties and contacts the Calendar Server 6 host to make an iSchedule free/busy request.

Sample request:

>> Request <<
 
   POST /ischedule/ HTTP/1.1
   Host: cs6server.example.com
   Content-Type: text/calendar
   Content-Length: xxxx
 
   BEGIN:VCALENDAR
   VERSION:2.0
   PRODID:-//Sun Microsystems/Sun Calendar Server 7.0-0.13//EN
   METHOD:REQUEST
   BEGIN:VFREEBUSY
   DTSTAMP:20040901T200200Z
   ORGANIZER:mailto:cs7user@example.com
   DTSTART:20040902T000000Z
   DTEND:20040903T000000Z
   UID:34222-232@example.com
   ATTENDEE;CN=Cal7 User:mailto:cs7user@example.sun.com
   END:VFREEBUSY
   END:VCALENDAR

The response is incorporated into the scheduling free/busy response made by the Calendar Server 7 host. If a user is on a Calendar Server 6 host, for scheduling an invitation, an iMIP invitation is sent by the Calendar Server 7 host.