Friday Aug 23, 2013

How the Project Was Documented

I happened today to come across the by-now-familiar-and-classic-to-many cartoon of project management, and have to say, the "How the project was documented" panel once again had me in stitches.

The great advantage of wiki publication, which we use for Communications Suite, is the ability to get beyond that "panel" and continually improve our documentation. With that in mind, I wanted to alert our Calendar Server users that I have completed a revamp of the Calendar Server 7 Command-Line Utilities page. Not only have I described some of the options more accurately now, but I think the page is more usable as I have moved deprecated options to a separate section at the end of the page.

As usual, feel free to leave a comment if  you have a documentation related question or idea for improvement.

Friday Apr 19, 2013

Why Wikis Are Great: UCS Calendar Server Administration Guide Reorganization

Want Documentation Convenience? Try a Wiki.

As a technical writer, I have to say, wikis can sure be convenient at times. Just this week, I was served up a major documentation request: reorganize the Calendar Server 7 Administration Guide, which meant moving sections around, creating new topic links, and so on. Typical writer handy man stuff.

In other writing environments, this could take a while, and then, even after doing the work, you'd have to navigate through a publication process to push the changes to your external repository, which itself, might not even be allowed off-release cycle, so to speak.

In any case, have a look at the newly revamped Calendar Server 7 Administration Guide. I have changed the logical flow somewhat and included a more expanded table of contents. Hopefully, this new arrangement is a better convenience. Still not finding what you are looking for? As always, drop a line or leave a comment here on this blog.

Thursday Jan 31, 2013

Oracle Hosts CalConnect XXVI

Cool. CalConnect XXVI, consisting of CalConnect Interoperability Test Events, and a CalConnect Roundtable Technical Conference (Members Meeting), is going on right now at Oracle.

Friday Oct 19, 2012

Oracle Communications Calendar Server: Upgrading to Version 7 Update 3

It's been some time since I have posted an entry. Now, with the release of Oracle Communications Calendar Server 7 Update 3, it seems high time to jump start this blog again.

To begin with, check out what's new in this release:

The upgrade is a bit more complicated than normal, as you must first apply some new schema elements to your Directory Server(s). To do so, you need to get the comm_dssetup 6.4 patch, patch the comm_dssetup script, and then run the patched comm_dssetup against your Directory Server(s) instances. In addition, if you are using the nsUniqueId attribute as your deployment's unique identifier, you'll want to change that to the new davUniqueId attribute. Consult the Upgrade Procedure for details, as well as DaBrain's blog, before forging ahead with this upgrade.

Additional quick links:

Tuesday Apr 26, 2011

Calendar Server for CALDAV Clients 7 Update 1: New Patch Available

Oracle Communications Calendar Server for CALDAV Clients 7 Update 1 has shipped a new patch (patch 3). The patch IDs by platform are:
  • Solaris: 142785-03
  • Solaris x86: 142786-03
  • Red Hat Linux: 142787-03

To obtain patches:

  1. Log in to
  2. Select the Patches and Updates tab.
  3. Type the patch id in the search box and Search for the patch.
    Selecting the patch will take you to the patch information page.
  4. Click the Download button.

Tuesday Sep 21, 2010

Oracle Communications Calendar Server(s) - Which One For You?

Oracle Communications Unified Communications Suite (formerly Sun Java Communications Suite) has been providing calendaring services for many years. What might have flown under the radar is that the latest version, known first as Calendar Server 7 and then rebranded to Oracle Communications Calendar Server for CALDAV Clients, supports the CalDAV protocol, the calendar access protocol standard. By supporting the CalDAV protocol, Calendar Server 7 enables you to use CalDAV-enabled devices, like the Apple iPhone, as your calendar client.

What this also means is that Communications Suite actually currently contains two calendar servers: the original, Sun Java System Calendar Server 6 (now rebranded to Oracle Communications Calendar Server), and the new, updated version, Calendar Server 7/OCCS for CALDAV Clients. So, when it comes to making your deployment choice, which calendar is best for you?

If you are performing a fresh, greenfield installation of Communications Suite, and you plan on using only CalDAV clients, or the Convergence 2 web client, deploy Calendar Server 7 (the current version is 7 Update 1). The Convergence 2 web client, as of the Communications Suite 7 Update 1 release, is now integrated with Calendar Server 7 Update 1.

If you have an existing Calendar Server 6.3 deployment, you can use the OCCS for CALDAV Clients migration utility to migrate your data to the new format used by Calendar Server 7 Update 1.

If you have an existing deployment depending upon Connector for Microsoft Outlook clients, you'll need to continue to use the older calendar product, SJS Calendar Server/OCCS 6.3. Eventually, you want to deploy the new OCCS for CALDAV Clients, as Calendar Server 6.3 has been deprecated.  However, to support Connector for Microsoft Outlook, Connector needs to come out with support for the WCAPbis protocol. OCCS for CALDAV Clients includes WCAPbis support as of the current release (7 Update 1). Now we have to wait for Connector to do the same.

For more information, see the following documentation:

Tuesday Oct 27, 2009

daBrain Scripting Export/Import of Calendar Server Data for Mac iCal

Why get bored with exporting/importing your calendar? From daBrain:

Export and Import is an easy way to get your Mac iCal up to date. But doing it manually is boring, therefor I thought it would be nice to have this scripted ...My result so far now is a small shell script which export your calendar from the Calendar Server, save it as export.ics and open iCal with the exported.ics file, you only have to click OK for the import.

Thursday Oct 22, 2009

CalDAV Support for Symbian OS

Sun Microsystems working on CalDAV support for Symbian OS.

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)

Thursday Oct 08, 2009

Calendar Server 7 Installation Experience

Interesting write-up by one of our TSC engineers, who just completed a Comms 7 Installation. Focus of the writeup is on our new product, Calendar Server 7.

Note: The single host deployment example (for SPARC), referenced in the above blog entry, is not yet publicly available. There is, however, this document for Red Hat Linux, that is available.

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:

Monday Dec 01, 2008

Calendar Server: Updated cscapture Utility

The Calendar Server cscapture utility collects all parts of Sun Java System Calendar Server environment that are useful for debugging, such as log files, database, host environment, config and more. It will also gather core files and debugger data for core analysis.

An updated version of cscapture (1.1) is now available with the following changes:

  • Detects just the current version of the Calendar Server and not the original version that was initially installed prior to upgrading. The previous way of detecting the version was not ideal and was confusing when reading the summary file.
  • Handles relative path names so it won't include the absolute path in the cscapture tar file. Running ./cscapture /var/crash will not longer cause /var/crash/cscapture-xxx to be present in the tar file. Instead the file path will be relative for more easier untar'ing of the data.
  • Includes the system messages files from /var/adm in the cscapture archive.
  • Uses the version 3 of the pkgapp script. This has been included with cscapture v1.1 for recommended use.

    Get the updated cscapture utility here:

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.

Friday Jun 13, 2008

Calendar Server 6: Long Awaited Patch

A new Calendar Server 6 patch was made available this week on SunSolve. Patch IDs are:

  • Solaris OS: 121657-28
  • Solaris x86: 121658-28
  • Linux: 121659-28

This is the first patch since -25, when the l10n requirements were unified. If you use non-english l10n patches, you now no longer need them. However, be sure to read the README before installing this patch.

And, if you are patching a Calendar Server deployment on Solaris x86, you must read the README before upgrading for a required procedure. This procedure is required only for x86 deployments. If you are running Calendar Server on SPARC OS or Linux, you do not need to follow this procedure. You need only perform this procedure one time. Following is the applicable text from the README:

CR 6642958 - Bad data representation with 121658-19 patch in x86
version of 6.3 calendar server (x86 ONLY)
With 121658-20 and later, calendar server uses new berkeley db library
which is incompatible with the db created by earlier versions. In
order to use the DB created by 121658-19 (or prior) with this patch,
the data needs to be updated by following the below procedure.

1> Make sure the calendar installation is 121658-19 or prior.
2> Take a copy of the current DB
3> Check to make sure the DB is in good condition by running db_verify
and csdb check
4> Dump the data using db_dump
	Set LD_LIBRARY_PATH to /SUNWics5/cal/lib
	eg: ./db_dump -r -f /var/opt/SUNWics5/dump/ics50alarms.db.txt
	Do the same for all the DBs.
5> Apply this patch (121658-24 or later)
6> Load the data dumped in the above step to the DB files using the
cs_dbload provided in this patch.
	Set LD_LIBRARY_PATH to /SUNWics5/cal/lib
	Run cs_dbload to load files dumped in step <4>
	eg: ./cs_dbload -f /var/opt/SUNWics5/dump/ics50alarms.db.txt
	Do the same for all the DBs
7> Run csdb check or csdb rebuild on the db files created in the above step.

Friday Feb 15, 2008

Configuring Cloudmark with Sun Java System Messaging Server

We just posted a new technical article on how to install, configure, and verify Cloudmark Anti-Abuse Client (CAAC) with Sun Java System Messaging Server.

The component products covered by this technical article are:

  • Sun Java System Messaging Server 6.3 and Sun Java System Messaging Server 6 2005Q4
  • Cloudmark Anti-Abuse Client (CAAC)
Get the article.

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


« December 2016