Wednesday Nov 28, 2007

Calendar Server: Required User Attributes

Need to know what attributes Calendar Server requires in Directory Server for an end user? The following sample for a newly created user using the commadmin user create command to create a mail/calendar user should get you there. (Hat tip Deb)

# cd /opt/SUNWcomm/bin
# ./commadmin user create -D admin -w password -F New -l nuser -L User \\
-n -p 80 -W password -X -S \\
mail,cal -E -H

# cd /opt/SUNWdsee/dsee6/bin/ # ./ldapsearch -D "cn=directory manager" -w password -b o=isp uid=nuser version: 1 dn: uid=nuser,ou=People,,o=isp icsFirstDay: 2 userPassword: {SSHA}RMn5bkqZRlLOI03vnmutikGAcvRgVdlvk2lGfQ== uid: nuser iplanet-am-modifiable-by: cn=Top-level Admin Role,o=isp icsTimezone: America/Denver givenName: New mail: mailUserStatus: active sn: User cn: New User mailDeliveryOption: mailbox icsStatus: Active icsCalendar: mailDeferProcessing: No mailHost: objectClass: userpresenceprofile objectClass: icscalendaruser objectClass: top objectClass: iplanet-am-managed-person objectClass: iplanet-am-user-service objectClass: organizationalperson objectClass: inetadmin objectClass: person objectClass: sunamauthaccountlockout objectClass: inetuser objectClass: inetlocalmailrecipient objectClass: iplanetpreferences objectClass: ipuser objectClass: inetorgperson objectClass: inetsubscriber objectClass: inetmailuser inetUserStatus: Active


  • The icsFirstDay and icsTimeZone attributes are not absolutely required and will be created when a user first logs in. However, the others are required and if using DWP, setting icsDWPHost to the Calendar backend host may be necessary (though this should also get set upon first login).
  • Also, creating users using the above commands, make sure the domain is also enabled for mail and calendar, for example:

    # ./commadmin domain modify -D admin -w password -X -n \\ -p 80 -d -S mail,cal -H

    So the domain entry in LDAP looks like:

    objectClass: inetdomainauthinfo
    objectClass: sunismanagedorganization
    objectClass: top
    objectClass: sunnamespace
    objectClass: sundelegatedorganization
    objectClass: sunmanagedorganization
    objectClass: maildomain
    objectClass: icscalendardomain
    objectClass: organization
    objectClass: nsManagedDomain
    mailAccessProxyPreAuth: no
    icsTimezone: America/Denver
    sunRegisteredServiceName: DomainMailService
    sunRegisteredServiceName: GroupMailService
    sunRegisteredServiceName: GroupCalendarService
    sunRegisteredServiceName: UserMailService
    sunRegisteredServiceName: iPlanetAMAuthService
    sunRegisteredServiceName: UserCalendarService
    sunRegisteredServiceName: iPlanetAMAuthLDAPService
    sunRegisteredServiceName: DomainCalendarService
    sunNameSpaceUniqueAttrs: uid
    mailDomainStatus: active
    nsNumUsers: 1
    icsStatus: active
    icsExtendedDomainPrefs: domainaccess=@@d\^a\^lsfrwd\^g;anonymous\^a\^r\^g;@\^a\^s\^g
    icsExtendedDomainPrefs: calmasterUid=calmaster
    inetDomainStatus: active
    sunOrgType: full
    sunNumUsers: 18

Wednesday Sep 26, 2007

Sun Java System Calendar Server: Calling All Best Practices

Someone was asking recently about Calendar Server best practices information on one of the support aliases. So I went searching the Calendar Server documentation, and discovered this best practice tip:

Note –

Duplicate parameters are allowed in the ics.conf file. The system takes the value of the last instance of the parameter in the file.

Best Practices: To avoid confusion, add your customizations to the end of the file in a section you create for that purpose. For example, you can create a comment line with the following text: ! My ics.conf Changes. Then add any new parameters or any parameters that you are modifying, and their values. Add comments to each parameter describing why the change was made and add the current date. This will give you a history of the changes made to the system for later reference.

If you make extensive customizations, to improve processing efficiency, you might consider commenting out the original parameter that you are replacing. Also, periodically review the file, commenting out obsolete duplicate parameters.

Other BP tips that folks suggested include:

Take nightly backups then run csdb check on the backup DP, to capture any DB corruption.

Implement the Calendar Server automatic backup facility.

These were just a few tips that came up. Have a Calendar Server best practice? Feel free to add to this entry by posting in the Comments.

Friday Sep 14, 2007

Software Upgrades: Feeling the Pain

Our internal Sun Java System Calendar Server hosts (yes, we do use our own products) recently went through an upgrade, but alas, an error was encountered where email reminders were not getting sent out. As a Calendar Server end user, I was left to my own devices to discover this: and along the way, I found out just how much I've come to depend on this seemingly trivial technology to help drive my corporate life. Yes, I need those email reminders about upcoming meetings and events!

Now, granted this was a fairly trivial post-upgrade situation, and our IT folks quickly remedied the situation. Nevertheless, for all those who have had an upgrade bite you in the \*\*\*, I feel your pain.

Monday Jul 02, 2007

Gather a Better Fix on Calendar Server Problems: cscapture

Wouldn't it be great to have a Mr. Fixit handy, when problems on your server arise? (Just kidding, I know today's software is a wee bit more complicated than say your in-house plumbing.)

Well, the next best thing for Calendar Server issues anyways might just be the cscapture utility, developed by the folks at the Sun GDD project. Compared to its predescesor capture_environment, cscapture can collect alot more information, including:

  • All Calendar Server configuration files
  • Calendar logs
  • Calendar database
  • Core files, pstack's, and pmap's
  • Execute multiple gcores on hung or spinning processes
  • Gather pkg_app data for core analysis
  • General host information with performance and resource statistics
  • Provides a summary overview of server setup and problems

The cscapture utility is available from BigAdmin here:

For more information on the Sun Gathering Debug Data program, check it out here:

Note:The cscapture utility is only currently available for Solaris OS; for other OSs, continue to use the capture_environment utility.

Thursday Jun 28, 2007

Developing a New Calendar Client w/ Swing

Jhawk is showing how to use Swing to develop a new client for Sun Java System Calendar Server. Check it out.

Wednesday Jun 27, 2007

Lightning Strikes Again

Lightning brings the Sunbird calendar to the popular email client, Mozilla Thunderbird. Since it's an extension, Lightning is tightly integrated with Thunderbird, allowing it to easily perform email-related calendaring tasks.

A new release of Lightning, 0.5, was recently made available. If you're a Lightning user, you should check it out.

The latest public build is at:

Calendar Server users should get the WCAP build. WCAP is Sun's calendar access protocol that is publicly documented if you wanted to write your own tools to access the data.

The plugin developers also have a calendar blog that's worth checking out:

You'll find additional instructions at:

Friday Jun 08, 2007

Lookout: Connector for Outlook & Multiple Calendars

Old Lookout on Mount Spokane During Winter

Quick note: If you want to be able to create and share multiple calendars with an Outlook client and the Sun Java System Calendar Server, you'll need the following components:

  • Sun Java System Connector for Outlook 7.2
  • Sun Java System Calendar Server 6.3 (AKA Communications Suite 5)

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 29, 2007

Exchange Changing Freebusy Access Model?

ArnaudQ has an interesting post up on Microsoft supposedly changing its Exchange/Outlook freebusy access model toward using a "web service" instead of relying on public folder synchronization.

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 to "no", but now the 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).

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?

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
    \*Note: .domain is the fully qualified hostname of the calendar server such as
  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.


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


« July 2016