The concept of establishing realtime contact across a network existed well before AOL and MSN Messenger Service made Instant Messaging (IM) a part of online culture. Since the late 1970s, many OSs have supported some facility to let users exchange messages in realtime. My introduction to such a tool came when I first started working with VMS and discovered VAXPhone, which let users dial one another across a DECnet network. If the user you contacted was logged on, that user could accept the call, and a two-way conversation ensued. Other users could join the call in a primitive form of online conferencing.
IM is now popular, perhaps because of the number of people likely to be online and available to converse at any given time. According to its supporters, IM lets people exchange dialogue dynamically. IM is more spontaneous than email and less expensive than videoconferencing. And IM provides presence information, which lets users know when a correspondent is available and can help users avoid talking to voicemail.
Currently, interoperability among IM applications is poor, although ongoing discussions are focusing on using either the Instant Messaging and Presence Protocol (IMPP) or the open-source Jabber protocol as the basis for future cooperation. Microsoft was a late entrant in the IM race, but Exchange 2000 Server and Exchange 2000 Enterprise Server include the Exchange IM service—part of the new functionality that somewhat justifies the increase in Exchange 2000 pricing.
All in the Delivery
Exchange IM is easy to deploy, makes only lightweight changes to user desktops, and generates no user data that you must back up or restore. The service doesn't compete with AOL or Yahoo!; MSN Messenger Service targets those products' large, widespread IM communities. Instead, Exchange IM seeks to provide a secure mode of instant communication that is well integrated with a company's internal IP network. As such, the service competes with products such as Lotus Sametime and Tribal Voice's PowWow. Microsoft based the Exchange IM client on the standard MSN Messenger Service client and added code to integrate the client with Exchange 2000. Exchange IM offers the following features, which combine email's functionality and the telephone's speed and accessibility.
Realtime messaging. Email transmits and delivers data at an unpredictable future time. With IM, users send and see data immediately.
Contacts. Users can maintain a list of people with whom they want to communicate on a regular basis. IM contacts aren't the same as Microsoft Outlook contacts or Windows 2000 Active Directory (AD) contacts, although you can expect IM contacts and Outlook contacts to merge in the future. IM holds contact information, on a by-user basis, in the Registry on client PCs.
Status tracking and notification. IM tracks users' online status (aka presence information) and reports that information to the users' contacts. The Exchange IM client, which Figure 1, page 150, shows, displays contact and status information. Users can change their status to show whether they're available for a realtime conversation or are otherwise engaged (e.g., on the telephone) and shouldn't be disturbed. Bespoke applications can use the Exchange IM software development kit (SDK) to exploit presence information. (For information about the Exchange IM SDK, see the sidebar "Building Custom Clients and More," page 152.)
As Figure 1 shows, the Exchange IM client also includes a pane that displays advertisements from MSN. Having advertisements pumped down your throat can be annoying; to solve the problem, you can use the Exchange IM SDK to create your own client. However, custom-built clients can communicate only with Exchange 2000's IM service. To create an ad-free environment, you can modify two policy settings in the Registry. You must change these settings on every client machine, so I suggest that you use a tool such as Microsoft Systems Management Server (SMS). To eliminate the advertisements, go to the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ MessengerService\Policies Registry key. Set the Disable CrossPromo and ExchangeConn values to 1. (These changes disable the advertisements, but you can't remove the MSN logo that displays when the client starts.)
To prevent clients from using the standard MSN Messenger Service (and thereby restrict their IM communications to Exchange 2000 users only), you can set the ExchangeConn value to 2. To display a warning message when the client starts, you can modify IMWarning. For example, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MessengerService\Policies\IMWarning "Don't be silly—keep credit card information to yourself!" will remind users not to send credit card numbers to IM correspondents.
Privacy. Users can decide who can view their online status or communicate with them. Users can also see who asks for or receives their status information.
You've Got (Less) Email
Apart from the ability to support realtime conversations, Exchange IM's most attractive aspect is the chance to eliminate some of the mailbox-cluttering staccato-type email exchanges that happen today. The following exchange is a typical example:
User 1: Hello? Are you in today?
User 2: Yes, do you want to talk to me?
User 1: That'd be great. When are you available?
User 2: I should be free at 11:00 a.m. or at 2:00 p.m. What's good for you?
User 1: I can't make either time. Could you come to my office for 10 minutes now?
User 2: Sure. Let me clear up a couple of things and I'll be there in 5.
User 1: Great. See you then.
Seven messages make up this message thread. From a systems perspective, seven messages now clutter up mailboxes—perhaps on two servers—and each message probably contains all the text from the preceding items.
Exchange IM uses fewer system resources for these types of communications and, best of all, leaves no trace of the finished conversation, eliminating long-term data retention. This elimination brings us to another facet of Exchange IM. You might think that IM is most interesting to the technical community, but senior managers can also get a lot of value from this technology. Users can discuss potentially sensitive topics (such as those featured in some recent high-profile court cases) without the fear that their words will come back to haunt them. (Indeed, Bill Gates probably wishes he'd used IM for some of his past communications with senior managers.) The potential benefits are obvious, although Microsoft might need to add an optional method to record IM conversations in industries that require monitoring (e.g., financial trading).
Additionally, most senior managers don't have a lot of free time, and personal assistants monitor these managers' mailboxes and closely schedule their time in the office—complicating your efforts to get a slot on the manager's agenda or a quick answer to an email message. If managers log on to IM, their contacts (e.g., their staff, employees who report to them directly) might be able to use IM to speed up decision-making processes.
The primary problem with Exchange IM is its total lack of integration with Outlook. Exchange 2000 holds IM contacts in the Registry and offers no support for linking IM contacts and Outlook contacts. The gap in development deadlines between Exchange 2000 and the next major release of Microsoft Office is largely to blame for this problem, so you can expect the next iterations of IM and Outlook to be much more integrated. Microsoft might also release a COM add-in for Outlook to bridge the gap between IM contacts and Outlook contacts, but at the time of this writing, that code hasn't yet materialized.
IM Components
The Exchange IM system comprises clients, IM home servers, AD, IM routers, and firewalls. Figure 2 shows how these components interact.
Clients. You can use the standard Exchange IM client. Alternatively, you can use the Exchange IM SDK to develop a custom-built client.
IM home servers. IM associates every user with a specific server. These home servers can typically support as many as 10,000 users who have modest hardware requirements (e.g., dual-CPU 400MHz systems with 256MB of memory) and who send as many as six IM messages a day to different correspondents. If home-server hardware can provide more CPU and memory, the servers can support larger populations. Conversely, if your users are more active and generate additional IM message traffic, you'll find that the servers can support smaller populations. I suggest you take a cautious approach during initial IM deployments and don't overstress your servers.
AD. AD holds IM data about users and servers. (AD also holds other information about the users' and servers' Exchange 2000 attributes, such as the users' and servers' mailbox server and database.)
IM routers. In distributed environments, IM routers consult AD, then route connections to the correct IM home server. The IM router simply routes messages from internal users; the router acts as a gateway for external connections that come through a firewall. IM routers don't broadcast source IP addresses to correspondents, thus ensuring that IM users' IP addresses are never revealed. IM routers also let you create separate namespaces for IM users. IM addresses resemble SMTP addresses. During IM implementation, you can designate one or more IM namespaces in one organization, or you can match the IM and SMTP namespaces. For example, if I decide to match the IM namespace and SMTP namespace, I can use [email protected] as my SMTP email address and my IM address. If I use separate namespaces for IM users, my SMTP email address could be [email protected] and my IM address could be tony.redmond@im .compaq.com. IM routers manage IM addresses, so the IM router for the compaq.com domain will take charge of resolving the IM address on incoming messages and routing those messages to the correct IM home server.
Firewalls. Firewalls secure IM conversations across the Internet. You can also use firewalls for secure internal connections.
Go with the Flow
As Figure 2 shows, IM messages flow from clients, through IM home servers, to internal destination clients or through an HTTP proxy server for delivery to external clients. No client-to-client communication ever takes place; all messages must go through correspondents' IM home servers before the messages can reach their destinations.
Before your organization can use Exchange IM, you must enable users' Exchange 2000 mailboxes for IM. As part of this process, you need to associate the mailbox with an IM home server by setting the IM home server property in AD. To allocate IM-enabled users to home servers, use the Active Directory Users and Computers' Exchange Tasks option, which Figure 3 shows. Small deployments probably need only one IM home server and don't require a router to deal with incoming connection requests. Larger and more distributed deployments need multiple IM routers to handle incoming requests, locate the correct IM home server, and pass the connection through to that server. Home servers maintain status information about users, as well as a list of contacts who are interested in status information for users homed on that server. This contact list is known as a subscription or a reverse list; IM stores this data in a Jet database in the \exchsrvr\imdata directory. For example, if I register John Smith's account as an IM contact, IM makes an entry for my account on John Smith's IM home server. When John logs on to IM, Exchange IM updates his status information on that home server, which knows that he's one of my contacts and therefore sends a status update to my account. If John then updates his status to notify people that he's busy and unavailable to communicate, the server sends another status message to notify his reverse list. Even when IM routers are in place, the home server is always responsible for sending out messages and status changes. IM performance counters come with Exchange 2000 and are available to log the number of current connections and message traffic, including status broadcasts.
IM servers (i.e., home servers and routers) run as an Internet Server API (ISAPI) extension—InstMsg, which Figure 4 shows—within the IIS process, which manages client authentication and logon. Exchange IM supports NT LAN Manager (NTLM) and Digest authentication but doesn't support Kerberos. (Digest authentication is a basic challenge-and-response mechanism that is more secure than sending password and account information in clear text. For information about Digest authentication, see Ken Spencer, "IIS 5.0's New Security Features," November 1999.) You can create and manage IM servers through the Microsoft Management Console (MMC) Exchange System Manager snap-in. When you create a server, you specify whether it's a home server or a router. This specification affects the DNS information that Exchange 2000 registers for the server: Home servers have private DNS names that aren't visible, whereas routers have public names. This difference is important when clients use IM to communicate through firewalls.
Exchange IM is divided into domains, or realms; each domain needs at least one IM router that is named after the domain. Inside a domain, you typically need to place IM home servers in each WAN area, scaling up with additional servers as the user community grows. As a rule of thumb, allocate as many as 5000 IM users to an IM home server, and allocate two or three home servers to an IM router. (Microsoft believes that you can support as many as 10,000 users per home server and recommends one router per two home servers.) The hardware and the number of servers you use depend on how much use IM receives in your organization. IM usage, and thus your hardware and server requirements, might grow over time, but you can easily reallocate users to new home servers, so don't be afraid to start small.
According to Protocol
To communicate, Exchange IM uses the rendezvous protocol (RVP)—a WWW Distributed Authoring and Versioning (WebDAV) extension to HTTP 1.1. RVP adds the Subscribe and Unsubscribe methods (to subscribe and unsubscribe contacts) and the Notify method (to notify contacts of status changes). To complete its functionality, Exchange IM uses standard WebDAV methods, including the Proppatch method to set an IM node's property (e.g., a contact's online status).
The Internet Engineering Task Force (IETF) IMPP working group, which includes Microsoft, is working on a Request for Comments (RFC) for an agreed-upon IM standard. The group expects to formalize its agreement sometime in 2001 or 2002, at which point a standard might integrate RVP extensions into WebDAV. (For information about the IMPP group, visit http://www.ietf.org/html.charters/impp-charter.html.) However, this work doesn't guarantee a bridge across the gap between corporate IM systems and personal systems such as AOL: Although IM uses RVP as an application protocol, it uses XML as a wire protocol.
To identify users, Exchange IM uses a unique URL (aka an IM Resource), which takes the form http://im_domain/instmsg/aliases/user_alias. Exchange IM sends messages and status updates through HTTP requests to these IM Resources. For example, an attempt to resolve the IM Resource http://im.compaq.com/instmsg/aliases/redmond will use DNS to locate the IM server for the im.compaq.com domain, then check AD to see whether IM has been enabled for a user with the alias Redmond.
Users aren't accustomed to using URLs to address one another, so IM provides the more convenient option of stating an IM address in the same format as a standard SMTP email address or, even better, letting users have identical IM and email addresses. (Although users can have only one IM address, they can have multiple SMTP addresses.) Internally, Exchange IM clients and servers always use the URL format to reference users. To find users, the Exchange IM service takes the domain part of the email-style address and performs a DNS lookup for an RVP service resource record (SRV RR). This process returns the name of the IM domain to contact. For example, the IM address redmond @compaq.com resolves as the URL http://im.compaq.com/instmsg/aliases/redmond if the IM service receives an RVP SRV RR through a DNS lookup against compaq.com. The format used for the SRV RR is _rvp._tcp.compaq.com SRV 0 0 80 imserver.compaq.com. In this instance, the SRV RR indicates that the RVP service for the domain compaq.com is available through port 80 on the server imserver .compaq.com. The two zeros designate priority and weight (you can use this information for load balancing). If the IM service can't find an RVP SRV RR, the service omits the im component, and the address resolves as http://compaq .com/instmsg/aliases/redmond.
Make a Connection
To better understand how IM operates, you can trace the steps that a client executes while connecting to a server. This sequence gives a good overview of how the Exchange IM client, IM home servers, HTTP, and AD work together to connect users.
- The IM client starts and requests a logon address.
- The IM client performs a DNS lookup to locate the Exchange IM service for the domain.
- The IM client performs a second DNS lookup to retrieve the IP address for the IM router, then uses HTTP to send a Subscribe request over port 80 to that IP address. The client sends a host header with the request for a callback IP address and port number for the client PC that the IM router will use to talk to the Exchange IM client. For example, the callback address http://10.10.1.1:1051 means that the IM router will send all subsequent requests (i.e., new messages and status updates) to port 1051 on the PC with IP address 10.10.1.1.
- IIS calls the InstMsg extension to locate the AD account for the specified logon address. An authentication sequence begins: The client attempts to authenticate using the standard NTLM method; if this method fails, the client uses the Digest authentication method.
- After successful authentication, the IM router queries AD for the correct IM home server and generates the correct URL to let the client connect to that server.
- The IM router sets the URL's callback property to the IP address and port number determined in Step 3.
- The IM client issues a Proppatch request to notify the server that the client is now online. The server maintains this value for 20 minutes. If the client doesn't issue another Proppatch request during that time, the server automatically adjusts the client's value to offline.
- The IM client retrieves its Allow/Block lists. IM uses these lists to let users accept connections from only a specific list of other users or to block connections from another list. The IM home server maintains the lists.
- The client issues a Subscribe request to discover which other users are interested in the client's status.
- The IM server sends a Notify request to each user on the list to tell them that the client is now online.
- The client checks the Registry to retrieve the list of IM users whose status the client wants to know. Exchange IM stores this information as a set of IM addresses, which the client converts into URLs; the client then sends Subscribe requests to each URL. The client displays the responses to these probes as status updates.
The Deployment Decision
Exchange IM isn't perfect, but it can deliver a lot of value if your users like the idea of realtime conversations. However, users won't accept IM simply because you deploy it—they need to discover how IM's features add value to their working lives. The current lack of integration with Outlook is annoying, but it's a minor hiccup. Exchange IM deserves a close look and perhaps a trial deployment, but only after you have a solid Win2K and Exchange 2000 infrastructure in place to provide the necessary underpinnings.
