This chapter describes how to set up Oracle Communications Calendar Server in an existing Sun Java Calendar Server 6 deployment. In this environment, you have some users who have migrated to Oracle Communications Calendar Server 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 Oracle Communications Calendar Server or Calendar Server 6. They do not have calendars on both systems.For more information on performing a Calendar Server migration, see "Migrating to Calendar Server".
For coexistence to work, each calendar server needs to be able to determine if users are on Calendar Server 6 or Oracle Communications Calendar Server.
On Oracle Communications Calendar Server servers:
Users are identified as Oracle Communications Calendar Server users by the presence in their Directory Server LDAP entry of a particular attribute which is configured as described in "Configuring the Oracle Communications Calendar Server 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 Oracle Communications Calendar Server 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 Oracle Communications Calendar Server 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 Oracle Communications Calendar Server to use davuniqueid as the unique identifier, you must add the new unique identifier not only to the users migrated to Oracle Communications Calendar Server, 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 Oracle Communications Calendar Server, see "Migrating to Calendar Server".
Calendar Server 6.3: At least patch level 44.
Oracle Communications Calendar Server: At least version 7 Update 1.
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 Oracle Communications Calendar Server server's free/busy URL. If the Oracle Communications Calendar Server 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 Oracle Communications Calendar Server 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 an Oracle Communications Calendar Server 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:
Delete Calendar Server 6 calendars by using cscal delete -o uid.
Set the LDAP attribute icsAllowedServiceAccess to -http:all. The setting ensures that Calendar Server 6 users no longer log in by mistake and cause calendars to be autocreated.
Perform the following steps on the Oracle Communications Calendar Server 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 an Oracle Communications Calendar Server 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 Oracle Communications Calendar Server 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.
This section contains the following topics:
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 Oracle Communications Calendar Server 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.
When a scheduling invitation or free/busy request comes to an Oracle Communications Calendar Server 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 Oracle Communications Calendar Server 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 Oracle Communications Calendar Server host. If a user is on a Calendar Server 6 host, for scheduling an invitation, an iMIP invitation is sent by the Oracle Communications Calendar Server host.