Key add-ons to improve Microsoft's enterprise IM product
Microsoft introduced server-based Instant Messaging (IM) functionality when the company released the Microsoft Exchange 2000 Server IM service. Unfortunately, the Exchange 2000 IM platform didn't live up to anyone's expectations, least of all Microsoft's. The implementation used proprietary protocols, suffered from security problems that included transmitting data in clear text, and couldn't communicate with other vendors' client and server IM solutions. Given this history, Microsoft decided to start again by fixing some of these problems.
After briefly considering embedding IM functionality into Windows Server 2003, Microsoft decided to create a new, separate product called Microsoft Office Live Communications Server 2003, formerly known as Real-Time Communications (RTC) Server and before that code-named Greenwich. Live Communications Server made its debut in mid-2003. Although it's better than its predecessor and one of the best IM solutions available today, Microsoft will need to improve Live Communications Server before the product becomes the enterprise IM solution. But several third-party vendors now offer products to make up for Live Communication Server's shortcomings and help you get the most from the product. See Table 1, for a list of add-ons for Live Communications Server. Let's review Live Communications Server's current feature set, how you can complement those features with third-party products, and the changes that are likely to happen to Live Communications Server in the future.
Architecture and Technology
Internet Engineering Task Force (IETF) Request for Comments (RFC) 3261 defines the Session Initiation Protocol (SIP), which serves as Live Communications Server's core communications component. In essence, SIP defines a mechanism to set up and disconnect calls between communicating devices. Microsoft and other vendors have adapted SIP for use with IM, and IETF is developing the SIP for IM and Presence Leveraging Extensions (SIMPLE) standard. Although IETF hasn't yet fully ratified this standard, SIMPLE has widespread acceptance in the industry and Microsoft has built Live Communications Server on this standard.
Microsoft IM clients from Windows Messenger 5.0 and later support SIP and use the protocol to communicate with Live Communications Server-based servers. You must run Windows Messenger 5.0 on Windows XP Service Pack 1 (SP1) or Windows 2000 SP3 and later workstations. Live Communications Server-based servers, of which there are several types that I describe later, must run some version of Windows 2003.
Microsoft uses the concept of a home server to define a server that runs the Live Communications Server service and hosts Live Communications Server user conversations. Each home server can support approximately 10,000 users. (Microsoft recommends using a dual-processor 1.4GHz Pentium 4 machine with 2GB of RAM for each home server.) These servers require minimal disk storage and I/O throughput. Microsoft recommends using 36GB of storage to host both the system volume and the home server's Registration database. (Ideally, you'd use this configuration with some form of data redundancy, such as mirroring.)
Clients can connect directly to home servers, or they can first connect to a Live Communications Server front-end server. Although front-end servers aren't required, they are necessary when you want to scale Live Communications Server to tens of thousands of users or when you have more than one home server. When you implement a front-end server, the client connects to the front-end server, which in turn authenticates the client, then either proxies or redirects the client connection to the appropriate home server. Front-end server hardware configurations should match those for the home servers.
Live Communications Server closely integrates with Active Directory (AD), which the enterprise IM software uses to store the server configuration information and topology. Similarly, when either a front-end server or a home server authenticates a user, the authentication occurs using an AD Global Catalog (GC) server. You'll want to ensure that the GC server is nearby or, ideally, on the same LAN segment as the server requesting the authentication.
AD can be on Windows 2003 or Win2K, but regardless of which OS you use, Live Communications Server must install several AD schema extensions. Microsoft recommends using Windows 2003 because of its AD replication improvements. Figure 1 shows how the Live Communications Server clients and servers interact.
Protecting Your Company's Information
Most public IM services transmit sessions in clear text. So, for example, if remote employee Joan contacts employee John over IM in your office, the IM software typically transmits their conversation in clear text across the Internet, which makes the conversation available to anyone who intercepts the network traffic. Sending sensitive information in a form that's easily accessible to eavesdroppers is unacceptable in any corporate environment. Live Communications Server protects the integrity of your data in two ways. First, when you implement Live Communications Server within your organization, internal conversations don't travel outside your network. Second, you can (and should) use Secure Sockets Layer (SSL) to encrypt the communications stream between the Windows Messenger client and the Live Communications Server-based server. Although SSL usage between the client and the server is optional, all communications between home servers must use a Mutual Transport Layer Security (MTLS) secure connection. Figure 2 illustrates a secure communications session between Live Communications Server clients and servers.
To implement such an SSL and MTLS infrastructure, you must install certificates on all the servers in the enterprise that interact with one another when users hold IM conversations. From a deployment perspective, you need to carefully plan your environment and consider the Certificate Authority (CA) topology that you'll put in place.
Addressing Security Concerns
Any system that allows communications between two or more correspondents is a potential target for viruses and the delivery of unsolicited content. Because Live Communications Server is an internally focused enterprise IM solution, its exposure to these threats is limited; however, systems administrators should still be cautious. Live Communications Server doesn't scan for viruses during IM file transfers or detect malicious content in an IM conversation stream, so you have to depend on third-party vendors to protect against these threats. Sybari is the first of the traditional security vendors to have such a product. Sybari's Antigen 7.5 for IM performs several functions, including antivirus scanning and file filtering, and offers content-blocking capabilities for conversation streams and file transfers.
As Live Communications Server evolves and the capability to connect together disparate IM systems becomes commonplace, the widespread acceptance of IM will make it ripe for abuse. Spammers have traditionally relied on email but are increasingly using IM to ply their trade. To make matters worse, emerging legislation could leave your company liable if you fail to provide a safe working environment for your employees.
Archiving IM Conversations
One notable shortcoming of IM is the short-lived nature of conversations. Most traces of an IM conversation vanish when the user finishes his or her conversation and closes the PC client window. Although most people don't keep an archive of their oral conversations, modern business practice has come to expect a permanent record of all conversations. This expectation is particularly true of those companies that work in the financial services, pharmaceutical, and legal sectors in which correspondence archiving and compliance is becoming mandatory.
Windows Messenger 5.0 provides some client-side logging by creating an XML file in the \my documents\my received files\logon name\history folder. Although users can copy a conversation from an IM window or from the client-side log file, such efforts don't provide any evidence that the conversation occurred. Legislation demands that the record be verifiable and that the correspondents can be identified.
Live Communications Server provides a rudimentary form of server-side conversation archiving. You can designate any home server or front-end server running Live Communications Server as an archiving server by installing the Archiving Agent on it. The archiving server must be running Microsoft SQL Server 2000 SP3 or later and Microsoft Message Queue Services (MSMQ). If you consider a message sent from one correspondent to another as a transaction, then the Archiving Agent will log to the archiving server every transaction that passes through a Live Communications Server-based server that has the Archiving Agent installed.
For every transaction, the Archiving Agent logs the following information on the archiving server: From field, To field, Time field, and the message content. Unfortunately, the archiving and reporting mechanisms aren't very sophisticated. Live Communications Server doesn't easily let you view conversation threads or easily retrieve the contents of a specific conversation, other than by executing some SQL queries. So if you want to generate reports or retrieve archived content, you must roll out your own scripts.
Conversation archiving is an obvious shortcoming in the Live Communications Server feature lineup, and several third-party vendors have introduced solutions to shore up this area. Chief vendors in this area include IMlogic with its IMlogic IM Manager product and FaceTime Communications with its IM Auditor product. These applications greatly enhance Live Communications Server's logging and archiving functionality. Keeping a history of corporate IM communication is becoming increasingly important given the strictures of the US Securities and Exchange Commission (SEC) regulations, US Food and Drug Administration (FDA) guidelines, and the new Sarbanes-Oxley compliance legislation on accounting practices.
Manageability and Reporting
Out of the box, Live Communications Server boasts little in the way of management, monitoring, or reporting functionality. It can restrict who can be seen in the Windows Messenger Address Book (i.e., user entries in AD), and you can deny user access to the Live Communications Server service by disabling Live Communications Server accounts.
To improve the manageability and the reporting of your enterprise IM, you'll have to again look beyond Live Communications Server to third-party offerings. Both IMlogic's IM Manager and FaceTime's IM Director let you apply administrative policies to your Live Communications Server infrastructure. These policies let you control who can access services and restrict sensitive information so that this information can't leave your company's network. From a reporting perspective, you should consider the Microsoft Operations Manager (MOM) Management Pack for Live Communications Server, which lets you monitor Live Communications Server-based servers and receive reports on IM activity, such as the number of sessions during a given period of time.
Extending Live Communications Server's Functionality
As with any mainstream product, inventive third-party companies always come up with ideas and ways to make the basic product better. Here are a few solutions that I find particularly interesting.
eDial's IM Web Access Server lets users access their Live Communications Server accounts by using only a Web browser—you don't need to have the Windows Messenger client on the desktop. The Web application has the look and feel of the traditional Windows Messenger client. By using IM Web Access Server, anyone can use a thin client from anywhere on the network to access their Live Communications Server account. Furthermore, the program opens up the possibility of letting partners or road warriors easily communicate from outside the corporate network.
Another interesting third-party product is The Mesa Group's Automated Real-Time Translation module for Live Communications Server. You type your data into Windows Messenger in English and your correspondent receives the information in his or her native language, and vice versa. This module facilitates translation between various languages and English and supports several alphabets, including Chinese, Arabic, Cyrillic, and Latin. Language translation is often an inexact science, but the custom dictionaries support lexicons, jargon, slang, abbreviations, acronyms, and dialects. The value of such a tool is questionable for everyday use, but you can imagine scenarios in which it might prove useful: information services in foreign countries or maybe even international dating services.
Siemens's OpenScape is a real-time collaboration environment built on top of Live Communications Server. OpenScape uses Live Communications Server's presence features to determine whether an employee is available. For example, imagine you want to virtually convene your team members who are available by phone with audio-only capability, logged on to the network with audio and video capability, or on mobile devices. OpenScape uses Live Communications Server presence information about the various users to determine the best mode of communications with which to contact each user and engage him or her in the meeting.
Fenestrae Communication Server and RADVISION's IMfirst also offer interesting additions to Live Communications Server's core functionality. Fenestrae has long been involved in the enterprise fax and Short Message Service (SMS) messaging arena, so to see the company integrate this kind of extensibility into Live Communications Server isn't surprising. Similarly, SIP's growing importance as a session protocol for audio and videoconferencing has spurred RADVISION into action, resulting in integration between Live Communications Server's peer-to-peer (P2P) messaging capability with the more sophisticated functionality you expect to see in a bona fide multiparty audio and videoconferencing solution.
Preparing for Tomorrow's Enterprise IM
Strong similarities exist between the development of IM-based communication systems today and the development of the email systems of yesterday. Standards are emerging—the ongoing battle between SIMPLE and Jabber's Extensible Messaging and Presence Protocol (XMPP) is reminiscent of the X.400 versus SMTP face-off. Similarly, although widespread adoption of IM systems is increasing, widespread interoperability isn't. Even discrete deployments of Live Communications Server in one company are unable to easily communicate with Live Communications Server deployments in another company. Simplifying interorganizational Live Communications Server communication and enabling federated Live Communications Server topologies is high on Microsoft's radar for the next version of its product, code-named Vienna. You can expect to see Live Communications Server mature into a more mainstream product for Microsoft. As it does, you'll see Microsoft make improvements in the areas of manageability, reporting, and archiving.
