Wednesday May 16, 2007

Messaging Server Upgrade: The Missing Link

Heads up: For those of you patiently awaiting the Messaging Server 6.3 upgrade patch (that is, the patch that will take you from pre-6.3 releases to 6.3), there is news: it should be appearing on SunSolve in the next few weeks. Once it is made available, I'll be sure to alert the Comms community, as well as update the Comms Hub Updates tab.

One other heads up: The patch number will be a different revision than the one initially specified in the C5 Upgrade Guide.

Tuesday May 15, 2007

Comms Suite 5, "Single Host Install Doc," and Comms Express Timeout

Caught this on the Info-iMS@Arnold.com alias today: a customer reported successfully using my Comms Suite 5 Single Host Deployment Example but then had an issue with leaving and coming back, and his Communications Express session had timed out. Normal stuff, right? However, in this instance, he was not able to log back in. He was receiving this error:

    http://host/UWCMain?op=logout

can not be found

Well, it turns out that this is known issue, which should get fixed in the forthcoming update release to Comms 5. (And I'm not going to comment on when that will be.)

In the mean time, if you do come across this problem, there is a fix. Set the following configutil parameter:

/opt/SUNWmsgsr/sbin/configutil -o local.webmail.sso.uwccontexturi -v uwc

Be sure to do a restart to have this change take effect (stop-msg; start-msg).

Monday May 14, 2007

Comms Suite: Pull or Push, It's Up to You

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.

Thursday May 10, 2007

Comms Suite Hub Bub

In case you missed some of the new items on the Communications Suite 5 BigAdmin Hub, here's a recent round-up:

Monday May 07, 2007

Messaging Server: More on the War Against Spam

Here's a useful tip for configuring Sun Java System Messaging Server to combat spam: delay sending the SMTP banner for a brief time (half a second, say), then clear the input buffer, and finally send the banner. The reason this works is that many spam clients are not standards-compliant and start blasting SMTP commands as soon as the connection is open. Spam clients that do this when this capability is enabled will lose the first few commands in the SMTP dialogue, rendering the remainder of the dialogue invalid.

This feature has now been implemented in Messaging Server 6.3. You can enable the feature unconditionally by setting the BANNER_PURGE_DELAY SMTP channel option to the number of centiseconds to delay before purging and sending the banner. A value of 0 disables both the delay and purge.

The PORT_ACCESS mapping can also be used to control this capability. Specifying $D in the template causes an additional argument to be read from the template result, after the mandatory SMTP auth ruleset and realm and optional application info addition. This value must be an integer with the same semantics as the BANNER_PURGE_DELAY value. Note that any PORT_ACCESS mapping setting overrides the BANNER_PURGE_DELAY SMTP channel option.

Thursday May 03, 2007

Part II, Troubleshooting MTA Message Queues

As I mentioned previously, the topic of message build-up in the MTA message queues prompted this writeup. Here's the second part of this installment, providing some details on what you can do if you discover that your deployment is having an actual problem with message build-up.

Before You Begin

At a minimum, you need to enable logging for the channels that you want to troubleshoot. The amount of logging that you set (log level) depends on your situation. To enable logging on a channel and learn about other options, see Managing MTA Message and Connection Logs in Sun Java System Messaging Server 6.3 Administration Guide for more information.


Troubleshooting TCP Channels

This section describes a general approach to troubleshoot build up of messages in TCP message queues to determine if there is an actual problem.

  1. When you suspect that there is something happening that is more than the store-and-forward aspect of messages building up in a message queue, begin by using the imsimta qm summarize command.

    For more information, see imsimta qm in Sun Java System Messaging Server 6.3 Administration Reference.

  2. The imsimta qm summarize command can greatly impact your system if you have a large backlog of messages. Instead of running this command frequently, consider using the imsimta qm messages channel command instead.

    This command lists the destination hosts for which messages are queued in the specified channel. This command also lists how many messages are waiting for their next schedule retry (the delayed messages column) versus how many are ready to be retried now (active now). When you use the imsimta qm messages command, you must specify a channel name; a wildcard is not valid input. For example:

    # imsimta qm
    qm.maint> messsages tcp_local
    host                             active messages  delayed messages
                             example.com           0                 2000
                             sesta.com             0                 3000

    In this example, 2,000 messages are waiting for their next scheduled retry to be delivered to example.com, and 3,000 are waiting for their next scheduled retry for delivery to sesta.com.


    Note - The Messaging Server 6.3 release removed the imsimta qm messages command. However, Messaging Server 6.3 does contain a new, useful command—imsimta qm jobs—to help understand why messages are not being delivered.


    This information is also useful for the situation where messages have failed and are waiting to be retried. If you see there are many messages in a channel queue, but most of them are delayed, this probably indicates the problem is with the remote domain. See Destination Host Problems for information on how to workaround this problem.


    Note - A message can be in process of being tried by a job, or on a channel waiting to be tried, or on a channel waiting to be retried. The messages command active messages column includes messages which have not been tried yet and those which were previously delayed and are now ready to be tried again. That is why you might see a zero (0) in this column. In Messaging Server 6.3, you can see the messages being retried with the new jobs command.


    iPlanet Messaging Server 5. Use top -to channel or top -domain_to channel to analyze what is going on in that channel.

  3. Look for trends on your system. For example, when most of the mail is all destined for one remote domain, check the status of that remote domain.

    Additionally, look in the mail.log_current file to determine what has happened in recent history when you tried to send mail to that remote domain.

  4. Use the imsimta qm dir -to address command to select a group of messages. Then use this information to look at the delivery attempt history of some of the messages. (You use the sequence numbers from the dir listing). Often, you will find that these messages are all non-delivery notifications for spam, which was not deliverable. If this is the case, determine how those original spam messages got into the system in the first place. Verify that the messages are spam by using the imsimta qm subcommands dir, read, and history. If this is indeed the case, think about routing the non-delivery notifications through a different outbound channel, thereby preventing them from choking the normal tcp_local channel queue.

    For example, use the notificationchannel and dispositionchannel keywords to specify an alternate process channel to queue delivery status notifications and modify status notifications, respectively. Then you use source-specific rewrite rules to direct messages from these process channels to a particular tcp_\* channel set to only use a few processes/threads. For more information, see Source-Channel-Specific Rewrite Rules ($M, $N) in Sun Java System Messaging Server 6.3 Administration Guide.

  5. Verify that the master process for the channel is started. The tcp_\* channels all use the smtp_client process. To find out which process is associated with which channel, in respect to dequeuing, see the master_command parameter in the associated channel block in the job_controller.cnf file.


Destination Host Problems

When you have determined that messages are queued to an unavailable remote host, you have two options:

  1. Create a new channel for the host. If this host is consistently a problem, all future email will go to this new channel. For existing messages that are enqueued, you can either wait for the problem with the destination host to be resolved or delete the messages from the queue.

  2. Increase the number of delivery threads for the channel, or set a ceiling on the number of queued messages that will trigger a new thread or process to start. See the max_client_threads parameter in the channel option file and the threaddepth channel keyword, respectively.


Troubleshooting the ims-ms Channel

This section describes a general approach to troubleshoot build up of messages in the ims-ms channel. The four general cases where the ims-ms channel shows a build-up of messages in the queue are:

  • IMAP_MAILBOX_LOCKED. While you might see this error in a message file that is briefly in the queue area, typically such a message file doesn't remain for long. The error only repeats in a message file in the queue area if the mailbox is remaining locked for an extended period. The job controller retries delivery of these messages after short delays until either the message gets delivered or a different error is encountered.

  • IMAP_MAILBOX_BADFORMAT, IMAP_MAILBOX_NOTSUPPORTED. The mailbox is most likely corrupted. This case rarely occurs. You might want to use the reconstruct command for these cases.

  • IMAP_IOERROR. The message store is most likely corrupted or otherwise inaccessible. This case occurs even more rarely.

  • IMAP_QUOTA_EXCEEDED. The user or users are over quota. This is the most common case, which this technical note discusses below.


Note - If the channel gets a permanent delivery failure error, then the message is immediately bounced and does not remain in the ims-ms queue area.


To troubleshoot the ims-ms channel, use the following high-level approach:

  1. Perform a similar investigation as you would for tcp_\* channels by using the imsimta qm summarize command to view what is happening on the system.

  2. Use the imsimta qm history command to examine the message IDs to detect if there are different sorts of messages. For example, you might see:

    Message id: 800
    Filename: /opt/SUNWmsgsr/data/queue/tcp_local/001/ZZf0b0KaNZykG.00

    A message's file name starting with ZZ indicates that it has not been tried yet. The message file name is a counter starting at ZZ and decremented (ZY, ZX, and so on) each time the message is tried, fails, and is reenqueued for later retry. Thus, a ZZ\* file name has not been tried yet, and there is no history.

    In general, but not always, when you have non-ZZ\*, non-.HELD files in the queue area, you have the IMAP_QUOTA_EXCEEDED case. (The frequency with which you see IMAP_MAILBOX_LOCKED conditions probably depends upon user and email client characteristics. This condition is more common with users who like to receive and move around lots of large attachments but it should typically occur rarely.)

    For a site that enforces quota, probably most of the non-ZZ\*, non-.HELD messages in the ims-ms queue area are there because of the recipient user being over quota. Verify this is the case by running the imsimta qm command with the history subcommand. You should see “over quota" in the history of the over-quota messages.


    Note - In iPlanet Messaging Server 5.2, the imsimta qm top command was enhanced to have more sorting options.


  3. Are there any Q status messages in the mail.log_current file pertaining to the ims-ms channel? When you see “mailbox is busy” and Q status in the mail.log_current file, then the message is put back on the queue to be retried later as per the job controller's scheduling and the backoff keyword on the channel.

  4. If not, check that the ims_master process is running. Are there any errors in its log file (the imta file)? The ims_master process could be hung. Use the imsimta process command to verify running processes.

Use the following strategies for users who become over quota:

  1. Inform users of the need to perform mailbox maintenance to return to under quota status, or increase their quota.

  2. Reduce the time that mail is queued for over quota accounts before being bounced back as over quota. See the store.quotagraceperiod configutil parameter. If you don't want to queue email for over quota accounts (and bounce the message straight back), set this parameter to 0 (that is, no grace period). This parameter is available in iPlanet Messaging Server 5 as well.

  3. For Messaging Server 6, you can enable the local.store.overquotastatus configutil parameter. This enables quota enforcement before messages are enqueued in the MTA and prevents the MTA from filling up.


More About the ims-master Process

At times you might see the ims-master process shutting down and starting up in the log file:

# > imta /opt/SUNWmsgsr/logs
# grep "Sun Java" imta
[30/Aug/2006:17:05:05 -0400] learn ims_master[19736]: General Notice: Sun Java(t
m) System Messaging Server ims_master 6.2-7.02 (built Jun 13 2006) shutting down
[30/Aug/2006:17:05:20 -0400] learn ims_master[28310]: General Notice: Sun Java(t
m) System Messaging Server ims_master 6.2-7.02 (built Jun 13 2006) starting up
[30/Aug/2006:17:07:24 -0400] learn ims_master[28310]: General Notice: Sun Java(t
m) System Messaging Server ims_master 6.2-7.02 (built Jun 13 2006) shutting down
[30/Aug/2006:17:07:32 -0400] learn ims_master[28380]: General Notice: Sun Java(t
m) System Messaging Server ims_master 6.2-7.02 (built Jun 13 2006) starting up
[30/Aug/2006:17:19:31 -0400] learn ims_master[28380]: General Notice: Sun Java(t
m) System Messaging Server ims_master 6.2-7.02 (built Jun 13 2006) shutting down

This is normal operation and does note indicate a problem. This is a “notice” message (not an “error” or “critical” level message). As with all channel jobs, ims-ms channel jobs shut down from time to time based on either having nothing to do, or based on “timing out” (getting old). Then the job controller restarts new jobs as needed.


Configuration Issues

You might want to increase the number of processes the job controller can start for the tcp_local, tcp_intranet, or other tcp_\* channels, or increase the number of threads each of those processes will start. You might also want to give the tcp_local channel its own pool. If you observe queued messages (total across all queues) to be greater than 100,000, increase the value of MAX_MESSAGES for the job_controller.cnf setting. See Job Controller Configuration File in Sun Java System Messaging Server 6.3 Administration Reference for more information.


Additional Information

This section contains additional information to help you understand MTA operations.


What Are .HELD Messages?

If the MTA detects that messages are bouncing between servers or channels, delivery is halted and the messages are stored in a file with the suffix .HELD in the msg-srv-base/data/queue/channel directory. Typically, a message loop occurs because each server or channel thinks the other is responsible for delivery of the message. You need to manually fix these .HELD messages with the imsimta process held command.

There is an unfortunate collision of terminology and concepts between .held messages and the hold channel. And worse still, the command to process .held messages is called release, whereas the command to process messages on the hold channel is called process_held.

You use the hold channel to hold messages of a recipient temporarily prevented from receiving new messages. For example, you might be moving a user's mailbox and want to hold new incoming messages. The hold channel is located in the msg-svr-base/queue/hold directory. Messages are written to this queue as ZZxxx.held files. Because the job controller doesn't “see” these .held files, they are not dequeued for delivery. You release these files with the imsimta qm release command, and the reprocess daemon reprocesses them.

See To Temporarily Hold Messages Using the Hold Channel in Sun Java System Messaging Server 6.3 Administration Guide for more information.


How Does a Message Become a .HELD Message?

Messaging Server makes use of MAX_\*_RECEIVED_LINES options that you set in theoption.dat file to determine when a message is put into the .HELD state. The most relevant options and their default values are:

  • MAX_LOCAL_RECEIVED_LINES=10

  • MAX_RECEIVED_LINES=50

  • MAX_TOTAL_RECEIVED_LINES=100

Once a message has looped through the MTA enough to accumulate MAX_RECEIVED_LINES header lines indicating the local MTA, then the message becomes .HELD. You can cause the MTA to immediately recognize that it has connected to itself, rather than waiting to accumulate MAX_LOCAL_RECEIVED_LINES local Received: headers, by specifying the loopcheck keyword on the appropriate channel(s) in the imta.cnf file.


For More Information on Troubleshooting the MTA

Use the following to aid in troubleshooting the MTA:

Wednesday May 02, 2007

Comms 101: Troubleshooting MTA Message Queues

I've been working with two of our Messaging Server experts to come up with an article on Messaging Server's Message Transfer Agent (MTA) and how it handles the build-up of messages in its message queues. This has been a fairly frequent topic of inquiry from the Comms community that presents itself as, 'I'm noticing a build-up of messages in my queues, should I be worried about it.'

The short of it is, not necessarily, because of the way the MTA is designed to work as a store-and-foward message system. The long of it is, maybe, but there's more to consider than just number of messages in the queue.

So, here's part one (of two) on my take on this situation, based on the experiences of two of our support engineers. I'd be interested in hearing from others and their experiences, to see if this article should be expanded/corrected.

Troubleshooting Sun Java System Messaging Server MTA Message Queues

Part I

This article describes how to troubleshoot the Sun Java System Messaging Server Message Transfer Agent (MTA), specifically message build-up in channels, including the TCP channels (tcp_local and tcp_intranet) and ims-ms channel.

Products covered by this article are:

  • Sun Java System Messaging Server 6

  • iPlanet Messaging Server 5


Note - This technical note assumes you are running Sun Java System Messaging Server 6. Where appropriate, iPlanet Messaging Server 5 commands are also mentioned.


This article contains the following topics:

  • About the MTA and Channels

  • When Is a Message Queue Having a Problem?

  • Main Causes of Backed-up Message Queues

  • Before You Begin<

  • Troubleshooting TCP Channels

  • Destination Host Problems

  • Troubleshooting the ims-ms Channel

  • Configuration Issues

  • Additional Information


About the MTA and Channels

To begin understanding why messages build up in a channel queue, and whether an actual problem might be occurring on your system, you must first understand how mail messages flow through the MTA.

The MTA can be thought of as Messaging Server's central brain, responsible for message routing. The MTA takes in messages via SMTP sessions from other systems and decides what to do with those messages. The first stop for a message is the MTA SMTP server, which executes programs to handle the SMTP session. Based on numerous configuration possibilities, the SMTP server processes the message, which could include message blocking, address changing, or channel enqueueing.

Actually, the sequence of events is a bit more complex. The dispatcher spawns the SMTP server by listening on port 25 (or whichever port is defined for the SMTP server in the dispatcher.cnf file). When the dispatcher detects an attempt to connect to port 25, it starts an SMTP process to handle the incoming connection. The SMTP server typically decides whether to accept or reject the message based on numerous configuration possibilities. During the SMTP dialogue, the MTA machinery kicks in to decide what to do with the message. However, the PORT_ACCESS mapping table works with the dispatcher rather than the SMTP server to allow or block access to certain ports such as the SMTP port (port 25).

The focus of this technical note is the decision to route the message to a channel where the message is to be enqueued. A channel is a message connection with another system or destination. Once enqueued to a channel, the message's destination could be another server (either on the Internet or on your company's intranet), a remote message store, a specific domain name, a channel for extra processing, such as virus filtering, or a local message store.

When a channel contains messages but is not delivering them, the messages build up in the channel's message queue. The message queues are directories, located by default in the msg-svr-base/data/queue/channel/ directory. In this way the MTA holds the messages for future delivery when whatever situation preventing their delivery is resolved.

The specific channels discussed in this technical note are the TCP channels (tcp_local and tcp_intranet) and the ims-ms channel. The tcp_local channel is responsible for routing messages to the Internet, while the tcp_intranet channel is responsible for delivering messages to remote message stores on your company's intranet. The tcp_intranet channel also routes messages to any intermediary internal systems on their way to another system. The ims-ms channel is responsible for delivering messages to the local message store.

For a complete description of the MTA architecture and message flow, see MTA Architecture and Message Flow Overview in Sun Java System Messaging Server 6.3 Administration Guide.


When Is a Message Queue Having a Problem?

Though this might be counter-intuitive, in general, it is not a problem for messages to build up in a message queue. Indeed, the MTA is designed to handle this situation. Internet mail (SMTP) is a store-and-forward mail system. Internet mailers are designed to store the messages that cannot yet be delivered. Keep in mind that it is perfectly normal to not be able to deliver outgoing SMTP messages immediately. Network problems, problems on remote hosts, problems with remote users' mailboxes, and so forth, are common cases that cause the MTA to hold and not deliver messages. MTAs, including Messaging Servers', therefore can store and retry outgoing messages. An often encountered case has to do with message store users being over quota and hence their messages are waiting for retry. From the MTA design point of view, this exactly the same case as being unable to deliver a message because of a network problem. The MTA handles the over quota situation with exactly the same underlying mechanisms: the messages are stored in queues where they will be retried for delivery. Thus, just because you are seeing a build-up of messages in queues is not necessarily cause for alarm.

The real issue about backed-up queues is when should you have cause to worry and so try to troubleshoot the source of the problem. The next sections explain the main causes of queue backups and how to go about troubleshooting such situations.


Main Causes of Backed-up Message Queues

In general, four situations can cause messages to back up in the MTA message queues:

  • Performance problems. Simply put, this occurs when your system is unable to keep up. Performance problems manifest themselves by high system loads and processes running flat out. In such situations, you need to perform an in-depth look at the system to be able to tune it and reduce the load.

  • Destination host problems. Regardless of what is causing problems on the destination host (networking problems, system problems, and so on), this situation can cause all delivery threads to become “stuck,” stopping valid email from getting through, or causing a lot of queued emails. The “stuck” problem presents itself as a lot of active messages waiting to be processed but with a low load. The “queued” problem shows as lots of queued email with long delivery attempt history.


    Tip - To contact the administrator of a domain that is causing you problems, use the whois command or http://www.netsol.com/cgi-bin/whois/whois.


  • Problems with Messaging Server itself. An example of a Messaging Server problem is when the stored process has an orphan lock for a user account, resulting in message build up for users in the ims-ms channel.

  • Configuration issues. Two common configuration issues include the job controller ignoring queued email or queued email due to overquota accounts, or queued email due to slow directory response, common for big mailing lists.

Part Two of this article will discuss courses of action to the above situations, and provide more information on troubleshooting. Stay tuned.

Monday Apr 30, 2007

When the Walls, Come Tumblin', Tumblin'...

My heart goes out to commuters in the Bay Area, after this mess (luckily, amazingly, no one was hurt). (Also interesting to note that local news here in Colorado first sensationally reported the Bay Bridge itself collapsing.)

I used to commute the Macarther Maze back in the good ol' days when I lived in The City in the 90's, and even back then, it was a white-knuckle kind of drive. Nowadays, my commute is only slowed up by whatever the kids have left on the stairs to the basement, where I've been a telecommuter for years now.

Anyways, some Comms pieces in the works (that should be out before the Maze is fixed nonetheless) that I wanted to plug:

  • Tech article on troubleshooting MTA queues: this paper looks at four common causes for messages building up in the MTA queues, and how you can troubleshoot and potentially alleviate these problems.
  • Tech tip on tuning your Messaging Server MMPs.
  • Updated Evaluation Guide for the new Comms Suite 5 release. (Reminder: Here's the link to the 2005Q4 version.
  • More on the Comms NextGen client, giving you some additional info on our new Web-based client that Jim P. talked about here.
As usual, I'll try and get this info out as quickly as possible to the Comms community. Stay tuned for details.

Friday Apr 27, 2007

New and Improved: Communications Suite 5 Release Notes

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.

Tuesday Apr 24, 2007

More on Using Communications Suite for Emergency Notifications

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.

Communications Suite 5: All the Docs Fit to Print

One doc complaint often heard at a Comms Suite voice of the customer gripe/feedback session is that docs.sun.com doesn't provide the ability to download all docs from a particular collection or product set at one time in the form of a zip file. Thankfully, at least in the Comms area, we have other means of helping out customers with this item.

You can now get the entire Comms Suite 5 doc set (PDF versions)--including guides, reference manuals, and technical notes--at the following URL:

http://www.sun.com/bigadmin/hubs/comms/files/COMMS5_DOCS.zip

If you want to know the full list of titles, here's the README:

Sun Java Communications Suite 5 Documentation, Alphabetical Order
-----------------------------------------------------------------

819-4654.pdf Calendar Server 6.3 Administration Guide
819-4655.pdf Calendar Server 6.3 WCAP Developer's Guide
819-4440.pdf Communications Express 6.3 Administration Guide
819-4441.pdf Communications Express 6.3 Customization Guide
819-2656.pdf Communications Services 6 2005Q4 Migration Guide
819-4432.pdf Communications Suite 5 Release Notes
819-4434.pdf Communications Suite 5 Documentation Center
819-4435.pdf Communications Suite 5 Event Notification Service Guide
819-4437.pdf Communications Suite 5 Schema Reference
819-4439.pdf Communications Suite 5 Deployment Planning Guide
819-7560.pdf Communications Suite 5 Installation Guide
819-7561.pdf Communications Suite 5 Upgrade Guide
820-0430.pdf Communications Suite 5 What's New
820-0639.pdf Comparison of Sun Java System LDAP Schema Modes for Communications Suite Products
819-5195.pdf Configuring Brightmail with Sun Java System Messaging Server
819-4409.pdf Connector for Microsoft Outlook 7.2 Installation Guide
819-4410.pdf Connector for Microsoft Outlook 7.2 Administration Guide
819-4411.pdf Connector for Microsoft Outlook 7.2 User's Guide
819-4438.pdf Delegated Administrator 6.4 Administration Guide
819-6839.pdf Deleting Messaging Server, Calendar Server, and Communications Express Users
820-0086.pdf Deployment Example: Sun Java Communications Suite 5 on a Single Host
819-5104.pdf Escaping Vendor Lock-in: Life After Microsoft Exchange
819-4412.pdf Instant Messaging 7.2 Administration Guide
819-6991.pdf Message Archiving Using the Sun Compliance and Content Management Solution
819-2652.pdf Messaging Server 6 2005Q4 MTA Developer's Reference
819-4428.pdf Messaging Server 6.3 Administration Guide
819-4429.pdf Messaging Server 6.3 Administration Reference
819-2653.pdf Messenger Express 6 2005Q4 Customization Guide
819-5355.pdf Sun Gathering Debug Data for Sun Java System Messaging Server
820-0374.pdf Sun Gathering Debug Data for Sun Java System Calendar Server
819-7603.pdf Transferring Messaging Server Configuration Data to a New Directory
 Server Host Without Reinstalling Messaging Server
819-6504.pdf Using NetApp Filers with Sun Java System Messaging Server Message Store
820-1040.pdf Using Sun StorageTek 53xx NAS with Messaging Server Message Store

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.

Friday Apr 20, 2007

Sun Java System Messaging Server 6.3: New White Paper

Per a previous post, I alluded to a new white paper out on Messaging Server 6.3. Astute readers alerted me to the fact that I may have, uh, jumped the gun: link not found.

I'm here to report that as of today, this paper is available:

http://www.sun.com/software/products/messaging_srvr/wp_messagingsrvr63.pdf

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.

About

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

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today