Factotum: Documentation Handyman

Reign over?

"Email has had a good run as king of communications. But its reign is over."

I hardly doubt it. I can see the move to a services approach, and an integration of those services. But much too early to claim outright demise.

Nothing too hair-raising, just a few bits of Comms-related information to start the week.

• New: Installing and Configuring Sun Java System Calendar Server 6.3 With Sun Cluster 3.1 Software
• Revised: Sun GDD for Messaging Server doc. The dbhang command has been updated.
• Announced: We have completed testing Messaging Server 6.3 and Sun Cluster 3.2 software, and are announcing support for this combination.

Messaging Server Support Field of Dreams?

Yes, Comms Suite runs on more than Solaris, remember that other OS--Linux? Thanks to Shane H., we now have an 'offical' quick start guide for installing the Comms Suite 5 stack on Linux.

Get the doc here:

• PDF
• HTML

Q. I need to set up SSO for Communications Express. What has changed between Messaging Server 6 2005Q4 (Java ES 4) and Messaging Server/Communications Express 6.3 (Comms Suite 5)?

A. Jhawk writes:

In the prior releases, we needed SSO to maintain authenticated sessions
between two of our HTTP servers. The two HTTP servers are the web
container (web server/app server) for the UWC servlets and the WebMail
server (mshttpd). Going into our Comms Suite 5 (UWC 6.3), we moved the
WebMail server behind the web container.

prior to 6.3
|------- web container(uwc)
web browser ----| (sso between)
|-------webmail server (mshttpd)

in 6.3
web browser----web container(uwc) --- webmail server(mshttpd)

Now in 6.3, we do not require SSO to maintain authenticated sessions
between our internal services. However, we do still support SSO to
co-exist authentication with 3rd Party web applications such as Portal
Server.

If you've been trying to keep track of all the Communications Suite (including Messaging Server, Calendar Server, Instant Messaging, Communications Express, and Connector for Outlook) technical notes, articles, white papers, deployment examples, and the like, look no more. I think that I've finally collected everything CommSuite-ish on the Comms Hub Technical Articles tab, so that you have a one-stop shopping index for this flavor of documentation:

http://www.sun.com/bigadmin/hubs/comms/library/techarticles.jsp

At issue is that we in Tech Pubs haven't always carried forward tech notes on docs.sun.com from release to release, so it would appear that a tech note or two has gotten lost along the way, even though the information might still be applicable. If you use the Comms Hub Technical Articles tab from now on, you should be able to get to all these kinds of docs that we have published, even some 'gems' from the iPlanet Messaging Server days.

Heads up: Both the Sun Java System Messaging Server 6.3 Administration Guide and Sun Java Communications Suite 5 Release Notes were recently updated. Accordingly, I've updated the zip file that contains all the Comms 5 docs (PDF format), located here.

I'm currently participating in a pilot project that I think will be a very cool addition to the Communications Suite knowledge base: a Sun-sponsored wiki that I'm using to create a Communications Suite FAQ, which will be able to be edited by you, the Comms Community.

Plan of record is to use the wiki internally for a few weeks then turn it loose for viewing externally. After a while at the view-only stage, we'll open it up for community participation. Looks like you'll need an SDN login/pwd to participate.

Right now, I'm organizing the FAQ by product (Messaging Server, Calendar Server, Instant Messaging, and so forth). Each product link takes you to the FAQ for that product, which is then organized by technology life-cycle, along the same lines as the Tasks tab on the Communications Suite BigAdmin Hub, for example:

• Evaluating Messaging Server
• Planning Your Messaging Server Deployment
• Installing Messaging Server
• Customizing Messaging Server
• Managing Messaging Server
• Upgrading Messaging Server
• Troubleshooting Messaging Server

If you have ideas on how you'd like to see this FAQ organized, feel free to drop a line or add a comment. I'm open to suggestions.

Additionally, I'm adding a section called "Customer Supplied Solutions" for that type of Q/A where someone asks of the community, how have you implemented X, or what type of server have you used for Y.

Stay tuned for details.

re: upgrading directly from iPlanet Messaging Server 5.2 to Communications Suite 5 (that is, Messaging Server 6.3), the Sun Java Communications Suite Upgrade Guide is clear on the upgrade path:

http://docs.sun.com/source/819-7561/planning.html

To quote:

While it is possible to upgrade all previous releases of Communications Suite software to Communications Suite 5, the only certified upgrades are from Java Enterprise System 2005Q4, Java Enterprise System 2005Q1, and Java Enterprise System 2004Q2. Upgrades from earlier releases are not documented in this Upgrade Guide.

Thus, upgrading directly from iPlanet Messaging Server 5.2 is not a certified way to go. From 5.2, you're supposed to go to 2005Q1 and then from 2005Q1 you can upgrade to 6.3. It's a two-step process. Headache, yes. But that's the certified route to take.

Doctor Doolittle's pushmi-pullyu (pronounced "push-me-pull-you")

Traditional email access (dial-up) was and still is "pull" based. You log in to your mail server, your mail client polls the server to see if there is new mail, and if so downloads it to a mailbox in your home directory. The same process happens at regular intervals afterwards as well.

The IMAP protocol, in effect, introduced clients to "push" email. Through support for polling and monitoring of the server, the IMAP protocol enables clients to become aware of new messages, fetch message data, and choose to dowload the message. Wireless devices were next to become 'instant-on' email clients, but used proprietary protocols to achieve that state of bliss.

Now the IETF, in the form of the 'Lemonade Profile,' has provided a standard way to use the existing IMAP IDLE command along with SMTP modficiations for push email.

Communications Suite 5 (released March 2007) supports IMAP IDLE (aka push email). Support for the IMAP and SMTP extensions described in the Lemonade Profile, RFC 4550, is planned for the next major Communications Suite release.

The advantages of IMAP IDLE are:

• Mail clients do not have to poll the IMAP server for incoming messages.
• Eliminating client polling reduces the workload on the IMAP server and enhances the server's performance. Client polling is most wasteful when a user receives few or no messages; the client continues to poll at the configured interval, typically every 5 or 10 minutes.
• A mail client displays a new message to the user much closer to the actual time it arrives in the user's mailbox. A change in message status is also displayed in near-real time.
• The IMAP server does not have to wait for the next IMAP polling message before it can notify the client of a new or updated mail message. Instead, the IMAP server receives a notification as soon as a new message arrives or a message changes status. The server then notifies the client through the IMAP protocol.

To configure IMAP IDLE in Messaging Server 6.3, see To Configure IMAP IDLE.

Just announced:

AXS-One Inc. today announced the release of AXS-Link for Sun JMS, a policy-driven archiving and management solution for Sun Java System Messaging Server.

The Communications Suite 5 release includes support for Windows Mobile 5, to keep email and and calendar information in-synch. (Note: Even I found it a bit hard to find this in our docs; you have to go to the Communications Sync 3.0 Release Notes to find out that, yes, we do indeed support Windows Mobile 5.0.) When you install the new release, the Comms installer takes care of presence of only one data sync path between Connector for Outlook and Calendar Server, enabling your PDA with Windows Mobile and Communications Sync to sync email/calendar/contact info with Microsoft Outlook.

If necessary, you can download just the updated Communications Sync tool from the following download page:

http://www.sun.com/download/products.xml?id=45f95b76

On this page:

1. Click Download.
2. Log in with your SunSolve user ID/password.
3. Download the SunJava_CommsSyncTool_Suite5_Windows.zip file.

Every day I come across questions that ought to be in our Super Comms FAQ. That way, customers would be able to easily and quickly locate that kind of frequently-asked-for-information and get on with the task at hand. Where is that Super Comms FAQ located, you might ask? Well, right now, it's still an idea that I have, but believe it or not, I'm working on it. So stay tuned for details.

In the meantime, I'll be posting these faqable items to this blog, in hopes that such information is at least getting out to the community.

Today the question came up about cluster product support, including our own Sun Cluster software and Veritas Cluster Server, for Messaging Server and Calendar Server. I had to do some digging myself before I found it in the C5 Release Notes, but even that wasn't totally complete. So, here's the definitive matrix on this question, cluster products supported by both Messaging Server and Calendar Server:

Release	Sun Cluster (32-bit)	Veritas Cluster Server (32-bit)	Operating System
Java ES 2005Q4 and Communications Suite 5	SPARC : SC 3.1, SC 3.0 X-86 : SC 3.1 U4 Linux : Sun Cluster does not support Linux.	SPARC only: VCS 5.0, 4.x,3.x	Solaris OS 9 and 10

One of my fellow writers informed me that the Communications Suite 5 Release Notes have undergone small but worthy changes, and have been re-released today, with the following enhancements:

• Calendar Server: Added more information to the What's New topic about the changes to the csstored process.
• Communications Express: Added more description about problem number 6546795.

Get the Communications Suite 5 Release Notes here.

With regards to my previous post, where I discussed using Messaging Server and its SMS capabilities as an emergency notification system, there have been some interesting and insightful comments on other approaches. Here is a summary of those comments.

1. Create a directory attribute in your schema which you use to designate an email to your SMS address. Many mobile providers have such entities (for example, AAAEEENNNN@mobile.att.net). For employees with company phones, you pre-populate the emergency notification list. In addition, you could provide the capability for those you wish to notify to add themselves to the notification list through a web interface.

   In terms of best practices on the user side in LDAP (constructing or "building" email addresses using attribute values that aren't themselves directly email addresses), see the item in the JES MS 6.3 Release Notes discussing the new-in-JES-MS-6.3 LDAP_URL_RESULT_MAPPING option.dat option.

   Two downsides to this approach are:

   • You will get mixed results as each carrier will have different mechanisms for churning email to SMS: length restrictions, and so on.
   • Worse yet, if 3,000 messages from, say, campus-safety@stateu.edu arrive at a particular provider all at once, the provider could decide that the messages are spam and delete them all.
2. Conduct advance planning to be able to put up banners on key web interfaces and web sites, indicating the emergency.
3. Use a well-known URL to disseminate information.
4. Use a shared IMAP folder.
5. At the lowest level, Messaging Server could certainly broadcast email messages to the entire population. This functionality exists as a simple email mailing list.
6. Use Instant Messaging accounts. In a university setting, you could enable students to use these IM accounts either throughout the school year or they could exist for the term of the class. Using IM enables you to maintain a single community that still allows co-existence with 3rd Party IM accounts from MSN/Yahoo/GTalk. The IM Account would also provide real-time information broadcasts on events, even providing Chat Rooms for discussions.
7. Use integration with phone switch information. Each employee would receive "universal" telephone numbers. (Sun uses AccessLine technology.) These universal numbers would all use call routing to an employee's phone numbers: work phone, home phone, cell phone, and so on. During emergency situations, the organization could set up "automated dialers" to call out each employee to notify them of emergency situations and appropriate course of action.