Thursday Apr 19, 2007

What the VP Says...

I think you'll all agree that when the VP steps up and says something, we all tend to take his words a bit more seriously. (Seriously, I'm just a lowly tech writer myself.)

So, in case you missed it, tune into Jim Parkinson's latest blog entry to find out everything we'd like to accomplish in Comms going forward.

I think that it's very cool that he's talking about our nextgen client. With that cat out of the bag, I hope to provide some more details to get everyone excited with this new effort. The entire Comms install experience, since Jim mentioned it, is another area I'll blog about soon to clue everyone about what to expect there.

Monday Apr 16, 2007

Delegated Administrator Console User's Guide

If you use the Delegated Administrator Console, you're in luck. One of our writers just put out the following doc:

Delegated Administrator Console: Administrative Tasks

This document describes the tasks you can perform in the Communications Suite Delegated Administrator console. (It contains the same information as the Delegated Administrator console online help.)

Tuesday Apr 10, 2007

Communications Suite: Going Mobile


A few weeks ago, Comms folks assembled for what we call the Communications Software Summit, a nice little four-day event to share and present information across the spectrum (marketing to technology) for Communications Suite products: a where-are-we-now, and where-are-we-going kind of event. We got smart this time and actually video'd the presenters, and thanks to our AV dept, created some tidy Web presos (video + actual hardcopy presentations) that our internal folks, who couldn't make the Summit, are able to view later, at their leisure, over the Internet.

Not having attended in person myself (Sun $ for travel has really shrunk in the past few years), I've started going through these Web presos, and am finding the information quite valuable. Is there a way that we can share this with our customers? (What, sharing information with customers?!?!?!). Well, not exactly, but what I will attempt to do is create some summaries and post them to this blog, omitting the super secret sauce.

First off, then: "Mobility and the Sun Java Communications Suite," a look at how mobile devices such as Blackberrys fit in with Comms Suite. (And thanks Doug, for your info which I am stealing, er, being influenced by.)

What Are Your Mobile Options for Comms?

According to the preso, here are your current options:

Communications Sync. Oriented to those devices that still don't have wireless capabilities, ye old 'cable sync' kind of technology. So we still provide that capability.

Portal Server Mobile Access. In the early days, there was Portal Server Mobile Access to address micro-browser based devices. The value add was a layer of abstraction between the content provider and the content itself. Prior to Comms 5, Portal Server provided portlets for Mail, Calendar, and AddressBook for your mobile devices. Now, with Comms 5/Java ES 5, there is a deprecation of these Comms portlets, and instead, you get Simple Mobile Support with a decoupled portlet.

SyncML. Now we're getting to the good stuff. SyncML is an open standard protocol for data syncing between devices that, until recently, has been more popular in Europe than the U.S. Lots of devices have SyncML built in, or enable you to install SyncML on that device. SyncML is a layer of abstraction between the device and the server, that, if I understood correctly, is a better architected solution (less revving of software on our end to make things happen). In the past, SyncML was a 'pull' method, but now it also supports 'push.'

Sun oftens uses Synchronica (but there are others) as its partner for deploying SyncML solutions. Synchronica provides a SyncML gateway that runs on Sun's Application Server that syncs with our Comms products. (Synchronica also syncs with other vendors' products, enabling you to have a co-existence environment to migrate your legacy environment to Sun.) Newer versions of SyncML work over the air as well as over a cable, do push Email and support IMAP Idle. The Synchronica gateway can also do push email to servers that don't support IMAP Idle. (IMAP Idle support is new in Messaging Server 6.3).

Blackberry, Palm OS (Treo, for example), and Windows Mobile Devices.: Sun's partner Notify provides a push email solution, NotifyLink that grants mobile access to these devices that don't have built-in access. You install the custom Notify email client on these devices to get the capability to do background syncs/pushes of content. The client also leverages built-in apps on the device, for example, on the Treo; another big advantage is built-in support for attachments, enabling you to access the attachment right on the device. This exists on the Treo for MS apps right now, with support for StarOffice apps supposedly on the way.

Of note: RIM has certified Notify as the only certified IMAP or non-BES for Blackberry devices. Like the Treo, the Notify client on the Blackberry interfaces with the native Blackberry Calendar, AB, and Task databases, as well as providing full attachment support.

The Notify solution provides a number of security solutions, including: SSL between the device and Notify server; AES and Triple DES encryption; AES encryption of stored data; SSL/TLS over IMAP4 behind your firewall; and so on.

Mobile Access Architecture

In terms of architecture, you can deploy mobile access for Communications Suite in two fashions:

  • Hosted access, in which you deploy the mobile access solution outside of your company's DMZ/firewall setup, with the mobile access server at the host provider's site. Front-end Comms servers provide access to the Comms back-end data layer hosts. Such a setup is good because you don't have to support the mobile access solution. The downside is that you need open firewall ports for each Comms front end server process.
  • On premise architecture, in which you deploy the mobile access server in your DMZ and manage it yourself.
Note: Sun IT has actually deployed examples of both these types of architectures.

Lastly, if you aren't familiar with the Comms Partners List, check them out here:

Monday Apr 09, 2007

Messaging Server: When Things Go Bump, er, Bounce in the Night

There was an interesting conversation on the Info-iMS alias last week concerning "bounced email" that caught my eye. Ah, another learning opportunity! To recap, then, here is another installment of Comms 101, courtesy of our Comms experts.

The specific error sited was:

nsmail Illegal host/domain name found (Too many failures to this host during this run; skipping this host: No such host/domain)

The short reply as to what's going on is fairly intuitive: the remote domain in question failed to resolve to a legal result, meaning that almost certainly this is a DNS issue (and not a Messaging Server MTA issue). Note that "other mail" will continue to make it through to your system (expected behavior), so don't be mystified by that activity. In addition, the error message is communicating that the problem has happened multiple times during the current operation (run) of the channel. The message bouncing is thus occurring because of an underlying DNS problem. To troubleshoot this problem, you would need to enable debugging (such as on LOG_CONNECTION) to determine the specific issue. Very likely, such a problem is transitory in nature but it is clearly not an MTA issue. Of final note: fancy configuration workarounds to such a situation are typically more work than troubleshooting and fixing the real problem.

The full detail on this thread can be found here:

Friday Apr 06, 2007

Sun Security Blog

I just stumbled across this in the Sun blogosphere: Sun Security Blog

There was a recent alert and workaround posted (March 30) on NSS and SSL clients and servers, with a potential affect on Messaging Server:

Security vulnerabilities in the Network Security Services (NSS) implementation of SSL2 may affect both SSL clients (such as browsers) and SSL servers which make use of this library. As a result, the client or server may exit unexpectedly, which is a type of Denial of Service (DoS). For servers running on Microsoft Windows, they may present a remote code execution vulnerability.

In any case, this seems like a potential blog to follow on a regular basis.

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 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:

  • I pushed a new tech note to 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.

Wednesday Apr 04, 2007

Heads Up: Communications Suite New Info on the Way

Just a quick update to describe some of the new information coming your way regarding Communications Suite:

  • Tuning the Messaging Server MMP - I'm working with one of our support engineers on this tech tip type doc, which describes tuning recommendations for Sun Java System Messaging Server 2005Q4 Messaging Multiplexor (MMP). The tuning information applies to the Sun Java System Messaging Multi-Plexor (MMP) software provided with the Java ES 4 (2005Q4) release (118207-56/118208-56 patch release or above).
  • Comms Single Host Deployment Example for Linux - Yes indeed, one of our more successful docs (by all reports) will now be available for the Linux platform as well, to help with what one reader described as the "opaque incantations" of the Comms install process. (And thanks go again to the same support engineer mentioned above for putting this together.)
  • Patch Information - I'll be using the Downloads > Updates tab on the Comms Suite BigAdmin Hub to post patch information for both Comms 5 and Comms 2005Q4.
I'll be sure to alert the Comms blogosphere when these items make their way live.

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
    \*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.

Friday Mar 16, 2007

Communications Suite 5 and Java ES: The Parting of the Ways

Just a heads-up about the forthcoming Communications Suite 5 release, in case you've missed it: Comms in no longer part of Java ES. So, all the Comms Suite 5 products--Messaging Server 6.3, Calendar Server 6.3, Instant Messaging 7.2--aren't part of the Java ES 5 bundle, and they won't be part of a Java ES bundle going forward. You'll download a separate Comms software bundle now, once we make it available. In addition, there will be separate Comms Install and Upgrade Guides. In the past, this information was included in the Java ES docs.

Here's the official statement that will appear in the docs:

Change in Availability of Communications Suite Products

Beginning with this release of Communications Suite 5, communications products are being removed from the Sun Java Enterprise System entitlement. Communications products are available as part of the Communications Suite or as individual products. Communications products will no longer be installed through the Java Enterprise System installer. Communications product components continue to interoperate with Java Enterprise System components.

This change in entitlement does not affect the communications products in Java Enterprise System 2005Q4. If you have communication products installed, no change will occur to your entitlement.

Thursday Mar 15, 2007

Communications Suite 5 Q&A: Access Manager, Delegated Admin, and Schema

There continues to be a fair amount of confusion (or miscommunication on our part) around Access Manager, Delegated Administrator, and schema choice. And the same confusion potentially could exist when it comes to deploying Comms Suite 5. So, here in a nutshell, are what I think are the basic questions and answers surrounding these products. I'll try and keep track of these issues going forward and continue to post them.

  1. In Communications Suite 5, does Delegated Administrator 6.4 still require you to deploy Access Manager?
    Yes, Delegated Administrator 6.4 still requires you to deploy Access Manager.
  2. In Communications Suite 5, does Communications Express 6.3 require you to deploy Access Manager?
    Starting with the Communications Suite 5 release, this dependency on Access Manager for Schema 2 has been removed.

    In previous releases, Communications Express used the following APIs and libraries to establish connections and fetch information from an LDAP store:

    • Domain MAP API (which a part of Communications Express) if Communications Express was deployed using Schema 1 mode.
    • Access Manager SDK if Communications Express was deployed using Schema 2

    This made Communications Express dependent on Access Manager in Schema 2 mode even though Access Manager is not mandatory for it to work apart from just connecting and fetching information from the LDAP store.

  3. When do I need to deploy Schema 2? Do I only need Schema 2 in an Access Manager/Delegated Administrator situation?
    Delegated Administrator currently supports only Schema 2. Other situations requiring Schema 2 include integration with Portal Server, and with Access Manager (for SSO).
For more information on these topics, see my previous entry.

Monday Mar 12, 2007

Locking Down a Sun Java System Instant Messaging Deployment

Occasionally, someone at Sun actually reads the documents that I write. (Just kidding.) And when they do, they just might not find what they were looking for. So, like good little Sun people, they file a documentation bug. And through the miracle of modern email, that bug ends up in my inbox, alerting me to the dire crisis in the doc.

Don't get me wrong, doc bugs are a good thing, a necessary thing, it's just that I might have an opinion if it's the most important priority that I should be addressing in my Sun life, or if it can wait until some time when I'm not dealing with the usual fires.

That's what happened around the following body of information for Instant Messaging. Some group within Sun, which is tasked with ensuring that we are providing the proper security planning information on all our software products, nailed me for lack of information on Instant Messaging. Here, then, is a summary of what you'll find in the forthcoming Sun Java Communications Suite 5 Deployment Planning Guide.

Overview of Instant Messaging Security

Instant Messaging supports the following levels of security:

  • No Security. Communication is all plain text from client through the multiplexor to the server.

  • Legacy SSL. Secure communication between client and multiplexor, and plain text between multiplexor and server. (This is only relevant if you are using the multiplexor).

  • startTLS. End-to-end secure communication between client and server. If you enable the multiplexor, it does not process any data but instead passes it on to the server.

The startTLS option enables end-to-end encryption (the communication between client-multiplexor-server is all in encryption form), while legacy SSL enables encryption between the Instant Messenger client up to the multiplexor: the communication between multiplexor and server is in plain text (though in a proprietary protocol). Use startTLS if you require a higher level of security. If you use startTLS, you do not need an alternate means of securing the multiplexor-to-server communication (it will be secure).

Protecting Instant Messaging Server and Multiplexor

Instant Messaging supports TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) for secure communications. Instant Messaging uses a startTLS extension to the Transport Layer Security (TLS) 1.0 protocol for client-to-server and server-to-server encrypted communications and for certificate-based authentication between servers. In addition, Instant Messaging supports a legacy implementation of the SSL protocol (version 3.0) for encrypted communications between the Instant Messenger client and the multiplexor.

The Instant Messaging default installation supports only SASL Plain. If you require a higher level of security, use the Instant Messaging public Service Provider Interface. SASL Plain and jabber:iq:auth are two forms of plain text authentication. That is, in both, the password is sent in the clear (encoded perhaps, but still clear text) and so both are insecure forms of authentication. Nevertheless, this is an issue only if end-to-end encryption (through startTLS for direct socket connection, and HTTPS for httpbind) is not enabled. If end-to-end encryption is enabled, the password is not “seen” in the clear on the network.

Alternatively, if you do not want to transmit passwords in the clear (even if over an encrypted stream), use the Instant Messaging SPI for plugging in authentication mechanism's at the server side through SASLRealm. You can implement custom SASL mechanisms as implementations but you will then need an Instant Messaging client that supports this custom mechanism. The Sun Java System Instant Messaging client supports only SASL Plain, jabber:iq:auth (both insecure).

Providing Instant Messaging Client Access Through a Firewall

The XMPP/HTTP Gateway (httpbind) provides Instant Messaging access to XMPP-based clients, such as HTML based clients, and clients that are behind firewalls that allow HTTP traffic only and don't permit XMPP traffic. The gateway proxies Instant Messaging traffic to the XMPP server on behalf of HTTP clients.

Protecting the Instant Messaging Archive

Instant Messaging has the capability to archive instant messages for later retrieval and searching. If you enable the email archive, you need to decide which administrators will receive email containing archived instant messages. You can configure a separate list of administrators to receive polls, news, conference, alerts, or chat sessions. You can also configure Instant Messaging to use the extended RFC 822 header. Doing so allows mail clients to filter messages based on the header content. If you do enable the Portal archive, you can decide which administrators can access the Portal archive database.

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.

Friday Mar 02, 2007

Communications Suite: Drat that winmail.dat

Q. My Communications Express users are getting winmail.dat attachments to email received from sender's on Microsoft Exchange. Is this a Communications Express issue?

A. No, the Microsoft Exchange server needs to be properly configured. For more information, see:

How to Prevent the Winmail.dat File from Being Sent to Internet Users

(It's always nicer when the problem is another vendor's.)


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


« June 2016