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

Why get bored with exporting/importing your calendar? From daBrain:
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)
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.
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.
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.
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.
This blog copyright 2009 by mb