Monday Apr 23, 2007

Patches?!? - We Don't Need No Stinkin' Patches!!

Cool development on the Communications Suite BigAdmin Hub: I'm readying the Downloads > Updates tab to include actual patch numbers. (Which means, of course, I'll have to keep this up-to-date going forward.) I'm starting with the upgrade patches for Communications Suite 5, for each component. As base patches become available for Comms 5, I'll start listing those as well. Note that for Messaging Server:

Upgrade patches will be available in May, 2007. If you need to upgrade sooner, please contact Support. Support will contact Engineering and work with your schedule to see if early access to the upgrade patch is feasible.
I just this morning requested to have this hub tab updated by the BigAdmin gatekeeper, so it should be visible to the external world in a day or so.

Sidebar, per Wikipedia:

"Badges? We ain't got no... stinking badges!" is one of the most frequently quoted, misquoted and parodied movie quotations in history. In 2005, it was chosen as #36 on the American Film Institute list, AFI's 100 Years... 100 Movie Quotes.

Thursday Apr 19, 2007

Communications Suite and Emergency Notifications - Using SMS

Short Message Service (SMS) Support in Messaging Server
The topic of Short Message Service (SMS) has come up within the Comms community as a means to quickly notify users with a more real-time, "push" style of communications, for example, to let users know of emergency conditions that require their prompt action.

I'm no expert on the topic by any means, but I did some digging around and came up with the following bits of information that may help you decide if SMS is something your site should look into.

Quick SMS Overview
From Wikipedia:

Short Message Service (SMS) is a telecommunications protocol that allows the sending of "short" (160 characters or less) text messages. It is available on most digital mobile phones and some personal digital assistants with onboard wireless telecommunications. The individual messages which are sent are called text messages, and more colloquially SMSes,texts, or even txts (in "text speak").

SMS gateways exist to connect mobile SMS services with instant message (IM) services, the world wide web, desktop computers, and even landline telephones (through speech synthesis). Devices which can connect to mobile phones and PDAs through protocols such as Bluetooth can also sometimes use that link to send SMS messages over the wireless network. SMS arose as part of the widely deployed GSM protocol, but is now also available with non-GSM systems.

The most common application of the service is person-to-person messaging, but text messages are also often used to interact with automated systems, such as ordering products and services for mobile phones, or participating in contests. There are some services available on the Internet that allow users to send text messages free of direct charge to the sender, although users of North American networks will often have to pay to receive any SMS text message.

SMS Support in Messaging Server
The short of it is that yes, Messaging Server does support SMS as a channel.

Messaging Server implements email-to-mobile and mobile-to-email messaging using SMS. You can configure SMS as either one-way (email-to-mobile only) or two-way (both email-to-mobile and mobile-to-email). To enable one-way service only, you must add and configure the SMS channel. To enable two-way service, you must add and configure the SMS channel, and in addition, configure the SMS Gateway Server.

For both one- and two-way SMS, the generated SMS messages are submitted to a Short Message Service Center (SMSC) using the Short Message Peer to Peer (SMPP) protocol. Specifically, the SMSC must provide a V3.4 or later SMPP server that supports TCP/IP.

The following figure shows these configurations:

Graphic shows logical data flow of one- and two-way SMS.

One-way SMS: To enable one-way service, the Messaging Server implements an SMPP client (the MTA SMS channel) that communicates with remote SMSCs. The SMS channel converts enqueued email messages to SMS messages as described in C.2.2 The Email to SMS Conversion Process of multipart MIME messages as well as character set translation issues. Operating in this capacity, the SMS channel functions as an (SMPP) External Short Message Entity (ESME).

Two-way SMS: Two-way SMS enables the mail server not only to send email to remote devices, but allows for receiving replies from the remote devices and for remote device email origination. Enabling two-way SMS service requires both the MTA SMS channel (SMPP client), as explained in the previous topic, and the SMS Gateway Server. Sun Java System Messaging Server installs an SMS Gateway Server as part of its general installation process, which you must then configure.

For more information, see Appendix C, Short Message Service (SMS) in the Messaging Server 6.3 Administration Guide.

SMS Mailbox Access and Calendar Gateway
In addition to the SMS functionality built-in to Messaging Server, a couple of Sun Professional Services folks independently developed an SMS Gateway solution for use with Messaging Server and Calendar Server. Dubbed SMS Mailbox Access and Calendar Gateway, this solution is primarily targetted at service providers to add value for their subcriber base, though other types of organizations could certainly also use the gateway.

The SMS Gateway provides the following functionality:
  1. SMS Notification. Receiving SMS information about each email delivered to the subscriber's mailbox. Depending on user-configured settings, the following information can be sent in the SMS body: sender, email subject, date and time, size attachment information, and more. Furthermore, the subscribers can read emails using their mobile phones. It is just a matter of responding to the SMS notification and the first part of the email body will be received as another SMS on the mobile device shortly thereafter. To receive another part the subscriber has to respond with SMS to the first one, to receive third - respond to the second, and so on, until the whole body has been transferred.
  2. Mailbox management via SMS. This enables support for basic email services. Subscribers can use SMS messages to reply to, forward, or delete the mail stored in their mailbox to receive mailbox status information (for example, the number of messages, how many have been read, and so on), as well as detailed attachment data (filename, type, and size). Mailbox management features also include the ability to send emails using SMS messages and to change notification parameters.
  3. Calendar Event Information. SMS Gateway sends SMS messages containing information on events in the subscriber's calendar (Calendar Server) to the subscriber's mobile phone (depending on user-configured settings). These can include reminders for pending appointments, invitations to meetings, and so on.
The SMS Gateway requires Messaging Server, Calendar Server, Directory Server, and custom components developed by Sun.

Comparison of Messaging Server SMS Channel and SMS Mailbox Access and Calendar Gateway
It's interesting to note that the built-in SMS functionality to Messaging Server and the SMS Gateway do not compete, but are in fact complimentary. Here is a summary of features in both:

SMS Channel
  • General-purpose email/SMS and SMS/email gateway
  • SMS notification sent as email passes via the channel, mailboxes are not involved
  • Provides historical record of the messages sent, so mobile users can respond to notifications to reply to email messages
  • Supports DSNs

SMS Gateway
  • SMS Gateway sends notifications when emails are delivered to mailboxes, so they can contain backward references to messages
  • Mailboxes must be involved if you want to interact with mailbox but you can think of  the Gateway as a general purpose tool for changing some user parameters in LDAP by means of SMS messages sent
  • SMPP connectivity is through the Messaging Server SMS Channel but also SEMA-OIS, UCP, and CIMD2 connectivity independently if needed as not all SMSC devices use SMPP
Very briefly: Use SMS Channel if you want to configure your Messaging Server to be an SMTP to SMS converter, so mail messages transferred through are converted to SMS messages and sent to mobile users, regardless of whether they have mailboxes on your server. Use SMS Gateway if you want your Messaging Server users to be notified with SMS about messages that arrive in their mailboxes and to be able to manipulate them with the means of SMS messages.

Another Alternative: Multimedia Messaging Service (MMS) Support in Messaging Server
MMS, like Short Messaging Service (SMS), is a way to send a message from one mobile device to another. The difference is that MMS can include not just text, but also sound, images and video. It is also possible to send MMS messages from a mobile phone to an email address.

While Messaging Server has supported SMS for some time, it does not provide built-in support for MMS. Instead, Sun has partnered with companies such as Logica CMG to provide the additional functionality required.

For More Information
For more information on this SMS Mailbox Access and Calendar Gateway, contact Andrzej Zagrodzinski or Wojciech.Chemijewski.

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.

Wednesday Apr 18, 2007

Comms Suite 5 MEM - It's a Front End...No, It's a Back End...No, It's Gone Completely...No, It's Still There

Sometimes we're are own worst enemy, creating confusion rather than developing understanding that makes deploying Communications Suite easier. Case in point: In the Messaging Server 6.3 docs, we've communicated that the Messaging Express Multiplexor (MEM) is "no longer used." We could have done a better job describing what this means. For example, in the Release Notes we wrote:

The webmail server, also known as mshttpd (Messaging Server HTTP Daemon), provides email services to the Messenger Express and Communications Express clients. Now, the webmail server accesses the message store through the IMAP server. This provides several advantages:
  • Messenger Express and Communications Express clients are now able to access shared folders that are located on different back-end message stores.
  • The webmail server no longer must be installed on each back-end server.
  • The webmail server can serve as a front-end server performing the multiplexing capabilities previously performed by Messenger Express Multiplexor (MEM).
  • MEM is no longer used. See Deprecated and Removed Features for Messaging Server.

Also, in the Communications Suite 5 Deployment Planning Guide:

Webmail Server or mshttpd daemon. Provides email services to the Messenger Express and Communications Express clients by using HTTP. In previous versions of Messaging Server, the Webmail Server accessed the Message Store directly. Now, the Webmail Server accesses the Message Store through the IMAP server. Such an architecture enables Messenger Express and Communications Express clients to access shared folders that are located in different back-end Message Stores. Additionally, there is no longer a requirement to install the Webmail Server on each back-end server. The Webmail Server can act as a front-end server performing the multiplexing capabilities previously performed by Messenger Express Multiplexor (MEM).

So, what's really going on?

Let's see if we can put this together more clearly. Prior to the Messaging Server 6.3 release, the MEM served as the HTTP proxy for Communications Express and Messenger Express. That HTTP proxy is the part that has been removed in Messaging Server 6.3. As a result of reengineering mshttpd as an IMAP client (instead of accessing the store locally), you no longer need to install mshttpd on the back end. Thus, you don't need need MEM. However, other than that, the Webmail Server is still the same. One could then say that the MEM functionality is now part of the main server. But it's really the MEM that's gone.

In retrospect, then, if MEM had been separate from the mshttpd daemon, like the mmp and httpd daemons are, this would have all been clearer that it's the proxy function that has been removed.

Deployment implications:

  1. You run Webmail Server on your front-end machines (rather than back end).
  2. Communications Express can now communicate to mshttpd on other systems.
  3. You should typically (recommended from an operational deployment standpoint, rather a functional standpoint) combine Webmail Server with Comms Express on the same machine on the access layer.

Monday Apr 16, 2007

Comms Suite 5 - Docs to Go (Installing on Linux)

Unfortunately, our internal pubs processes are very weighty. That's not always a bad thing, we need to ensure quality, technical accuracy, and so on. But for some docs, it doesn't make sense to make you wait while the wheels of Sun Pubdom grind slowly on.

But I'm starting to look at this blog as the ultimate cheepo publishing system, for some information at least: a docs-to-go kind of place.

Bottom line: Customers want information quickly. So I'll experiment a bit with a doc that a support expert has readied: Deployment Example: Sun Java Communications Suite 5 on a Single Host (Linux). I know some of you have requested this already, (the doc is really an updated version of the same example on Solaris) and so I'm making a decision: rather than pipe this through the normal (slowww) pubs channels and wrap the info in near-Nirvanic Sun formatting, I'm redirecting it as is to this blog.

Doc Summary: This deployment example describes how to install Sun Java Communications Suite 5 software on one Linux computer for a functioning deployment. This document is intended for any evaluator, system administrator, or installation technician who wants to install and evaluate the services delivered by these components.

Get the Deployment Example

As an experiment, I'll leave it up to this community to let me know if you find any corrections and I'll take the responsibility to keep the doc up-to-date if you find something that needs fixing. Who knows, perhaps this could become a new and faster way to get certain kinds of information into your hands.

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.)

Friday Apr 13, 2007

Renaming UIDs in Communications Suite - Don't

When it comes to renaming UIDs of Communications Suite users--a common request--the old adage, "Don't Try This at Home," or even, "Don't Try This at All," surely applies.

You all know the story: one of your existing users has had a name change (whether by marriage, divorce, divine intervention, or some other reason), and now you need to rename the user. The quick and dirty advice is to not even considering renaming the UID, but instead, to rename other aspects of the user's entry, such as cn, mail attribute, and other 'visible handles' to the mailbox, calendar, and address book. You can configure Comms servers to enable users to authenticate using email address or any other per-user attributes instead of the default UID. But leave that UID alone, unless you want to get snake-bit.

There's lots of history on this topic and lots of folks much-well versed in it than I am. This is definitely a topic upon which we could--and should--create a definitive white paper. However, be that as it may, we're stuck with this situation. And lest you think this is just Sun as usual, it turns out we're not the only company suffering from it. According to our experts, some others include Ipswitch IMail, Lotus Domino, Novell Netware, qmail, and SAS LDAP. This is an industry-wide problem.

The bottom line is that we do recognize this is a huge issue (there are RFEs filed), lots of products face this issue, and you can't use or depend upon UID as a unique identifier. Given time, I'd like to see what I could do to document this labyrinth for our customers. No promises exactly, but this strikes me as a topic that would serve everyone well and prevent some headaches if we took some time to capture it once and for all.

Wednesday Apr 11, 2007

Communications Software Summit, Part Deux: Comms Suite & Zones

Per my previous post, I described how the Comms practice recently held a Communications Suite Softwware Summit, and how I was going to summarize some of the talks that took place. So, here's our second installment, titled "Deploying Communications Suite in Solaris OS 10 Zones." (And a big thanks to Jhawk, from whom I am stealing this info outright.)


This summary covers:

  • Review of Solaris Zones
  • Using Zones with Communications Suite
  • Backing up and restoring Zones
  • Patching Zones
Review of Solaris Zones

A typical installation of the global zone resembles the following, consisting of two resources (NIC and file systems), and the Solaris packages:

Your data, including configuration and user/groups info, lives on the file system.

Sidebar: All systems that run Solaris 10 contain a master zone, called the global zone. The global zone is the original Solaris OS instance. It has access to the physical hardware and can control all processes. It also has the authority to create and control new zones, called non-global zones, in which applications run. Non-global zones do not run inside the global zone—they run along side it—yet the global zone can look inside non-global zones to see how they are configured, monitor, and control them.

Next comes the sparse zone:

This figure shows that the sparse zone is actually a sub-instance of Solaris, on Solaris. The sparse zone shares the same physical devices but contains a logical NIC (NIC:0). The sparse zone also shares some packages with the global zone (/usr, /platform, /sbin), and contains local copies of other packages (/opt, /var/opt, /etc). In the sparse zone, users and groups are unique but have global IDs.

After the sparse zone comes the non-sparse zone (also called the whole root zone), as shown below:

Here, all the Solaris packages are copied to the zone and not shared.

The advantage to the sparse zone is that it has a better security model. Also, some applications, such as Communications Suite, have problems with writing to a shared /usr. For such applications, you should use a non-sparse zone.

Sidebar: The non-sparse zone model provides maximum flexibility. All file systems are private to the zone. The advantages of this model include the capability for global administrators to customize their zones file system layout. This would be done, for example, to add arbitrary unbundled or third-party packages.

Why Use Zones?

Reasons include:

  • Easier installations and recovery. Have a problem that requires an OS reload? Just 'blow away' the zone and continue (rather than having to do it the old fashioned way of reloading the entire OS).
  • Provides better security on production systems.
  • Well suited for Communications Express and MMP/MTA installs.
  • Better control over Resource Pools . BTW, define a Resource Pool, even if you're not going to use it. Why? Enables better management of CPU and memory resources.

Where Not to Use Zones

  • Only available on SPARC/x86, so sorry Linux users, you're out of luck.
  • If you're requiring HA, it's possible, but requires special handling, so for now, for Comms, we're saying don't.
  • Systems with small disk space aren't going to work.
  • Best practice so far: don't use in your data centers.

Installing Communications Suite with Zones

Okay, now we're into the good stuff. In a nut shell, here's what we are recommending for Comms Suite and Zones:

  • Use the non-sparse zone for Java ES 2005Q4. In Comms 5, officially, we support sparse zones, though there are bugs (and workarounds).
  • First step on your Solaris-installed host: Run the Comms installer to install the shared components on the global zone, because there is a set of packages in /usr key to the rest of the installation. THIS IS THE KEY STEP.
  • Create your non-global zone.
  • From the created zone, run the Comms installer and install Comms Suite.
  • Lastly, you patch the installation with MS/CS/etc. patches. You need to patch shared components in the global zone (pkgadd -G) and individual components in the non-global zone (pkgadd).

Helpful Hint: Create your runtime users with unique UIDs. This enables you to track users from the global zone.

Backing up the Zone

Here I will cheat and let the preso do the talking:

For More Information

Deploying Sun Java Enterprise System 2005Q4 on the Sun Fire T2000 Server Using Solaris Containers

Solaris 10 Zones, Communications Suite 5 Installation Guide

Solaris Container Trick #1 : Monitoring Users Processes

Tuesday Apr 10, 2007

New VP

Our new Comms VP has a blog. Check out what he's saying:

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:

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.

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.

Sunday Mar 25, 2007

New Communications Suite Technical Note: Comparing LDAP Schema Modes

Our Calendar Server writer just produced a rather interesting technical note titled "Technical Article: Comparison of Sun Java System LDAP Schema Modes for Communications Suite Products," which should go a long way towards filling the information gap that currently exists around this topic. You can get this technical note here:

Short description of this doc:

This article compares the Sun Java System LDAP schema modes used by the Sun Java Communications Suite products. It includes an overview and history of both modes, an example of domain and user LDAP entries for both schema modes, and a discussion on how to decide which mode is appropriate for you.

Shorter article, for those who don't have the time to digest it all:

  • You should use the same schema version for all Communications Suite products sharing the same LDAP directory.
  • If you require Sun Java System Access Manager to share the same LDAP user directory with Communications Suite products, use one of the Schema version 2 modes.
  • You should not use Schema version 1 mode unless you satisfy all of the following criteria.
    • You have an earlier version of one of the Communications Suite products already installed using Schema version 1.
    • And, you don't want to use Access Manager.
    • And, you don't want to migrate your LDAP database to either mode of Schema version 2.
  • If Sun Java Communications Suite Delegated Administrator does not have the features you require, but iPlanet Delegated Administrator does, use Schema version 1 mode.
  • If you are installing Communications Suite products for the first time, choose the Schema version 2 mode that integrates most easily with your current DIT structure. You can choose between Schema version 2 native mode or compatibility mode. The two modes are defined in Schema Version 2 Background Information.
UPDATE, May 2, 2007

As one astute commentator noted to me offline, once you are convinced that you ought to migrate your deployment from V.1 to V.2, what next? Apologies, we neglected to include a pointer in this article to the Schema Migration Guide, which "describes how to migrate Sun Java System LDAP Directory data from LDAP Schema 1 to LDAP Schema 2 for Sun Java Communications Suite, specifically Sun Java System Messaging Server and Sun Java System Calendar Server."

Friday Mar 23, 2007

Comms Suite 5: Get the New Software (Correct Link)

Okay, we messed up a bit. I didn't get that there was a NEW download site in the works for the Comms Suite 5 bits. Here it is:

Thanks to those letting me know in the comments section that I was still pointing to the 2005Q4 download site on the Comms Hub. That's being fixed right now too. Sorry for the inconvenience.


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


« June 2016