Wednesday Oct 14, 2009

Calendar Server 7: Coexistence with Calendar Server 6

As the Calendar Server 7 docs state:

(you can)...set up Calendar Server 7 (CalDAV Server) in an existing Calendar Server 6 deployment, where calendar users exist on both the Calendar Server 7 and Calendar Server 6 environments. In such a deployment, you enable both freebusy lookup and iCalendar Transport-Independent Interoperability Protocol (iTIP) invitation between the two Calendar Server deployments. That is, users should have the capability to check freebusy 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 iTIP.

Now, Andreas has some more info on this setup, here.

(Photo Credit: muhammad younas)

Wednesday Sep 23, 2009

Calendar Server 7: A Look at Sun's Upcoming CalDAV Release

Hat Tip DougG

It might not be widely known at this point, but Sun has been a leader in the CalDAV community, and our investments are about to pay off with the upcoming shipment of Calendar Server 7, included in the Communications Suite 7 release.

Sun is firmly committed to making CalDAV our calendaring protocol of choice. Sun has been very active in the CalConnect community to make sure that our CalDAV service interacts with other vendors and their services. Project Aries has been the name of Sun's CalDAV effort, and for the past year, we've enabled customers to get a taste of our technology through a hosted preview.

Why the need anyways for a CalDAV server?

The challenge in the calendaring space has always been about getting everyone to agree on a standard protocol that enables data to be exchanged between a calendar client and a calendar server, regardless of vendor. To date, we've been using the iCalendar data format for calendar and task data, as specified in RFC 2445. The good news has been that Sun and others have used this common data format. The bad news with this approach has been that, lacking a standard protocol, you end up using one big file to store all your calendar events. Reading calendar info may be fine, but making changes is not. Because your calendar database is essentially one big flat file, the only way a change can be made is for the client to upload a new version of a user's entire calendar data file and overwrite the copy on the server. That's a lot of data to move, for example, when all you have to do is push out a meeting change of one hour. The situation worsens if multiple users want to update a calendar. The last user to overwrite the copy on the server wins and changes other people have made are lost.

Having a real calendar access protocol would solve these problems and provide other nice features, such as calendar sharing, change logs, and free/busy lookups. The first attempt at such a protocol came in 1999 with the creation of the Calendar Access Protocol (CAP). WCAP, or Web Calendar Access Protocol, is an implementation of CAP over HTTP. Sun Java System Calendar Server 6.3 uses this protocol. Unfortunately, timing is everything. When the dot-com bubble burst, work on WCAP fizzled out. The result: Vendors went back to using their proprietary protocols.

Luckily, the situation did not remain the same. Though it took awhile, a new idea emerged to extend the WebDAV protocol to provide calendar specific support. The result was CalDAV and is documented in RFC 4791.

Of course, having an open protocol buys you nothing if vendors do not implement it in popular products. That is a big reason why CAP didn't take off. Fortunately, CalDAV seems to have gained enough momentum to stick around, as envinced by the CalConnect industry consortium, whose charter is to make sure CalDAV implementations work together and are widely adopted.

Yes, calendaring "nirvana" might still be a long way off, but we are getting closer with Calendar Server 7.

For more information on Calendar Server 7, see the following pages:

Wednesday Sep 03, 2008

CalDAV comes to Comms

Check out Project Aries.
Project Aries is the code-name for Sun's advanced calendar server based on CalDAV. As standards-based calendar usage increases, the ability to share calendars and support multiple calendar clients becomes increasingly important. Aries satisfies this need by introducing a standards-based calendar server that supports Apple iCal, Mozilla Lightning, and other standards-based clients. Project Aries is a key component of Sun Java Communications Suite. This Hosted Preview provides you the opportunity to view and test drive this new calendar server. While not all functionality is implemented yet, we want to share this exciting new product with you for your review and feedback.

Thursday May 31, 2007

Diagnosing and Recovering Calendar Server Database Corruption

Thanks to the Calendar Server engineering team and one of the Comms writers, there's a new article up on BigAdmin titled "Recovering Sun Java System Calendar Server Databases." This article discusses how to diagnose Sun Java System Calendar Server calendar database corruption and describes the best ways to recover a database in various situations. The example at the end offers a cookbook list of steps for recovering a database after it has been corrupted.

Get the article.

Tuesday May 01, 2007

Calendar Protocol Faceoff

For those interested in calendar developments, head over to arnaudq's blog, where you'll find a great comparison of WCAP (Web Calendar Access Protocol,Sun's proprietary calendar protocol), and the proposed standard calendar protocol CalDAV. As Jim Parkinson pointed out here, we're looking at a "a calendar server based on the latest CalDAV standard."

Wednesday Apr 25, 2007

New in Calendar Server 6.3: Event Organizers Can Receive Reply Notifications

The question came up recently about whether the new version of Calendar Server, 6.3, could email notifications to organizers when an attendee replies to an invitation. The answer is YES.

How do you enable this feature? By configuring the ics.confparameter ine.reply.enable. Set it to "y" to enable the feature for the entire system. Set it to "n" to disable the feature. The feature is enabled by default.

The three reply types are: accept, decline, tentatively accept. The notification indicates whether the reply is to a single invitation or to an recurring event. The following new message format file parameters were added. The corresponding format files were also added:

  • calmail.imipeventacceptnotification.fname= "mail_eventacceptnotification.fmt"

  • calmail.imipeventdeclinenotification.fname= "mail_eventdeclinenotification.fmt"

  • calmail.imipeventtentativeacceptnotification.fname= "mail_eventtentativeacceptnotification.fmt"

  • calmail.imipeventacceptnotificationrecur.fname= "mail_eventacceptnotificationrecur.fmt"

  • calmail.imipeventdeclinenotificationrecur.fname= "mail_eventdeclinenotificationrecur.fmt"

  • calmail.imipeventtentativeacceptnotificationrecur.fname= "mail_eventtentativeacceptnotificationrecur.fmt"


Note –

This feature is not a user preference. That is, it is a system wide configuration parameter, so it applies to all users who send invitations.


For more information about configuring Calendar Server for email notifications, see To Enable Email Notifications in Sun Java System Calendar Server 6.3 Administration Guide.

Tuesday Apr 24, 2007

Calendar Server 6.3: csstored Now a Required Process

A heads-up to those of you who will be running Sun Java System Calendar Server 6.3: the csstored process has changed in the new 6.3 release. Whereas it used to be a PERL script that could be enabled and disabled at will to implement automatic backups, and could be stopped and started at will, now in version 6.3, csstored is a required daemon that is started and stopped automatically by the start-cal and stop-cal scripts, along with other required daemons.

The csstored daemon manages the various Calendar Server databases. Because each service that accesses the store depends on the successful start of this store service, it should remain running on all servers, both front-end and back-end, whenever the Calendar Server system is running.

It is no longer optional to run this daemon, whether you decide to configure automatic backups or not. Previously, you could disable the script from running by setting the ics.conf parameter local.store.enable to "no", but now the local.store.enable parameter must be set to "yes", which is the default.

The Calendar Server 6.3 Administration Guide will be re-released shortly with this updated information (Chapter 9).

Friday Apr 06, 2007

More on Installing a Comms 5 Calendar Server 6.3 Deployment (Front End and Back End)

Update, 4/9/07:

A co-worker has correctly pointed out in the comments that I have this not quite right. It is the configurator.sh script itself that is causing the problem. You do not have the option while running the script to choose between IP address and hostname. The script basically choose the IP address rather than the hostname. But again, the fix is afterwards to manually update the ics.conf file for the parameter mentioned below.

- Factotum Management

4/6/07:

As I mentioned in a previous post this week, there's a Calendar Server 6.3 install issue that I want to make folks aware of.

When you use the configurator.sh script to configure your Calendar Server front end, in a front end/back end deployment, as described here, your are supposed to use a fully qualified domain name for the back-end host the front end is pointing to that you will use DWP to commmunicate with. If by mistake you put in an IP address of the host instead, which evidently the script lets you do, the configuration will not work. And then you'll have to manually go back and enter the FQDN of the host instead of the IP address for caldb.dwp.server.backend.ip in the ics.conf file.

And yes, we do have a bug (CR) filed for this.

Thursday Apr 05, 2007

Communications Suite Odds and Ends

As usual, lots to scrape off the Comms windshield. Here are some interesting factoids that have turned up in the past few days:

  • Installing a Comms 5 Calendar Server deployment, front end and back end (where the front end is using the DWP protocol to communicate with the back end): when you use the csconfigurator.sh program on the front end to configure Calendar Server, you are prompted to use the IP address of the back end to point to. Unfortunately, this needs to be the host name, so you'll have to correct that manually. (Bug has been filed.)
  • When deploying Connector for Outlook with Calendar Server/Communications Express, realize that Connector needs to access calendar in WCAP (a calendar protocol encapsulated in HTTP) and communicate directly to a calendar process that 'speaks' WCAP (cshttpd). In a multi-tier deployment, that means installing a Calendar Server front-end on your host running Communications Express. This calendar front-end prowides the WCAP services necessary for Connector, and then communicates to the back-end host using the DWP protocol (port 57779 by default; thus, be carefull with you firewall rules between front-end and back-end host). For more information on this kind of deployment:

    http://docs.sun.com/app/docs/doc/4439/6n4udv3em?a=view
    http://docs.sun.com/app/docs/doc/4439/6n4udv3cg?a=view

  • I pushed a new tech note to docs.sun.com today, should be available by tomorrow: Using Sun StorageTek 53xx NAS with Messaging Server Message Store.
  • Our deployment team says that you need an expert to install Comms, and even then, don't expect a problem-free time. Question: Is this news to anyone? I do hope, at least, that our customers have been seeing some improvement in this area from at least the docs standpoint. If not, you know you can always drop me a line and let me know.
  • Found this interesting tech note from our Access Manager brethren: Sun Java System Access Manager ACI Guide. Personally, I'd rather have to eat peanut butter and crackers stranded in the desert without water than to have to deal with AM ACIs, but here you have a new peek into what the heck's going on there.

Tuesday Apr 03, 2007

The Secret Life of Calendar Groups in Calendar Server 6.3 and Communications Express 6.3

We've been having an internal discussion about a 'new' feature in Calendar Server 6.3, namely, Calendar Groups, and how all this fits in with Calendar Server and Communications Express. According to the Calendar Server Release Notes:

Support for LDAP Groups in Calendar Server 6.3

It is now possible to create LDAP groups using Delegated Administrator. Groups have the following functionality:

  • A group is a list of users. The group does not “contain” the listed users. It is not a container.

  • A group can have a group calendar.

  • Invitations sent to a group reside on all the members' calendars, as well as the group calendar.

  • All members of the group share the same access rights to the group calendar.

  • There is no primary owner for a group calendar.

    - This should be corrected to: The group calendar does have an owner, and can have co-owners too.

Clarifying these points, then, with some discussion that took place today:

  • The group calendar that you create through Delegated Administrator is a Corporate Group--different from your usual Personal Group (created through the Communications Express Addressbook).
  • When subscribing to a group calendar through the Communications Express interface, you subscribe to the Personal not Corporate group. That is, the CE interface does not access the group calendar created in the LDAP directory (by using DA).
  • The cscal command manages calendars in the Calendar Database not the LDAP directory. Thus, if you go looking for your LDAP group calendar with cscal, you won't find it initially (see below for more info).
  • When you invite the LDAP group calendar, member calendars added to the group get the events. There is no 'physical' calendar for the group calendar but the individual user's (member's) calendars.
  • To manage a group calendar, you actually manage the member's calendars (in Comms Express).
  • Calendar Groups can be used for limited functionality, including invite to event, check availability, compose mail to group, and view calendar from Addressbook (in Comms Express).
  • Currently, when you create the group calendar, you must then access it the first time (use it in an invite, for example) before it 'shows up' using the cscal command. Unfortunately--and this is a big unfortunately--currently there is no client today with which you an invite the calendar.
I hope this explanation helps in how to use (or not use) the current implementation of group calendars in Calendar Server and Communications Express. Questions anyone?

Monday Apr 02, 2007

Minor Discrepancy: Clarifying Calendar Attachments in Comms Suite 5

We noticed this slight discrepancy in the Communications Suite 5 Release Notes:

In the Communications Express 6.3 section:

The Calendar component of Communications Express allows users to include attachments to an event or task.

However, in the Calendar Server 6.3 release section, we have:

While Communications Express, the Web user interface, does not support attachments yet, users of the Connector for Microsoft Outlook can now put attachments in their events and tasks, and can send attachments with invitations.

The answer is that the Communications Express 6.3 interface does indeed support calendar attachments, but the older Calendar Express interface does not. In fact, with respect to the Calendar Express interface, we are now saying (quote from Releaase Notes):

"The Calendar Express graphical user interface (GUI) has been deprecated in favor of the Communications Express GUI and will be removed from the distribution in the the next major feature release. Move to Communications Express as soon as possible.

Tuesday Mar 20, 2007

Calendar Server Pop-ups: Not Just For Breakfast Anymore

Ya know, it's actually kinda cool when we use our own products. I'm talking about getting pop-up reminders on your desktop for your Calendar Server appointments. As long as you're running both Calendar Server and Instant Messaging, you can make this happen. And believe it or not, we actually do just that at Sun. Here's how.

To get pop-up reminders, you must have Instant Messaging installed on your network and you must be logged into Instant Messenger. (Instant Messenger can be iconified if you like). With Sun Java Communications Suite 5, the IM configuration wizard configures the iim.conf file for pop-up notifications and there is nothing you need to add to the iim.conf file, unless you want to define an optional password. You still need to modify the Calendar Server ics.conf file and enable calendar reminders in the IM client.

How to do it:

  1. Edit the Instant Messaging iim.conf file as shown below, and restart Instant Messaging. (Only required for versions of IM prior to IM 7.2. You can skip the iim.conf configuration steps if running IM 7.2 or later.)
    ! calendar event config
    jms.consumers=cal
    
    jms.providers=ens
    jms.provider.ens.broker=.domain:57997
    jms.provider.ens.factory=com.iplanet.ens.jms.EnsTopicConnFactory
    !
    jms.consumer.cal.destination=enp:///ics/customalarm
    jms.consumer.cal.provider=ens
    jms.consumer.cal.originator=.domain
    jms.consumer.cal.type=topic
    jms.consumer.cal.factory=com.iplanet.im.server.JMSCalendarMessageListener
    jms.consumer.cal.param="eventtype=calendar.alarm"
    iim_agent.enable=true
    iim_agent.agent-calendar.enable=true
    agent-calendar.jid=calimbot..domain
    agent-calendar.password=
    iim_server.components=agent-calendar
    
    \*Note: .domain is the fully qualified hostname of the calendar server such as megademo.demo.iplanet.com
    
  2. Edit the Calendar Server ics.conf as show belown, and restart Calendar Server.
    caldb.serveralarms = "yes"
    caldb.serveralarms.dispatch = "yes"
    caldb.serveralarms.url = "enp:///ics/customalarm"
    caldb.serveralarms.contenttype = "text/xml"
    caldb.serveralarms.dispatchtype = "ens"
    
  3. Click the "Show Calendar Reminders" checkbox in the Instant Messenger client. This is contained in the "Alerts" tab in the Instant Messenger "Settings" popup.

Thursday Mar 15, 2007

Calendar Server: Saving the Daylight Update

Update to Download the Calendar DST Fix Tool
Get this Sun tool (and instructions) to correct timings of events and tasks in Sun Java System Calendar Server, related to the DST switchover in US and Canadian timezones.

There is now a new version of this tool, which was released to SunSolve on 3/14. Per the Change Log on the DST Hub:

[2007-03-14] Added updates for DST Fix Tool Version 2, released 3/14.

Friday Mar 09, 2007

Calendar Server: Saving the Daylight

New!  Download the Calendar DST Fix Tool
Get this Sun tool (and instructions) to correct timings of events and tasks in Sun Java System Calendar Server, related to the DST switchover in US and Canadian timezones.

Thursday Feb 15, 2007

Calendar Server - Get Yer Appts Emailed To You

I like it when I can say, here's some new information for you. As I mentioned yesterday, we were close to getting out a cool article (and it's actually the script that is cool) for generating an automatic email to your Calendar Server users, containing that day's appointments and tasks. Have at it:

Receiving a Daily Summary of Sun Java System Calendar Server Events and Tasks by Email

Thanks to Mike d. for contributing this info.

About

Reporting about Unified Communications Suite Documentation, including news, Comms 101, documentation updates, and tips and tricks.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today