Instant Messaging

Although many administrators think of Instant Messaging (IM) as a toy application, it's catching on in the business world because it lets users quickly exchange messages without the overhead required to support and maintain a "real" mail client. IM clients let you know whether the people on your contact list are online; IM users can set their status to a variety of states, including busy, on the phone, out to lunch, and away. Maybe even more important, such "presence" information is a gold mine when you need to know whether someone is available for another kind of communication, such as a phone call or office visit.

Exchange 2000 Server includes an IM server that integrates with Exchange and Active Directory (AD). The IM server is easy to install and manage, so you can quickly set up IM on your network. Windows XP, Windows 2000, Windows NT, and Windows 98 users can use the Exchange IM client to communicate with Exchange IM users; XP users can use the Windows Messenger client to simultaneously communicate with MSN Messenger and Exchange IM users. (I explain how that simultaneous communication works later.)

IM Works Through Home Servers
Each IM user must have an IM-enabled account in AD. You use the Exchange Task Wizard in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to enable IM accounts. Enabling a user populates the AD attributes that specify with which IM home server the user's account is associated. The IM home server must run Exchange 2000, but it doesn't have to be a mailbox server. The home server accepts messages sent by, and coming to, users homed on it and delivers these messages. As long as users talk only to other users who share the same home server, only one home server is required. Microsoft recommends a maximum of 7500 concurrent users per home server.

If your organization has more than one home server, how do users on different home servers communicate? Also, how do Internet users, who can't see the contents of your AD, send messages to clients on your home servers? First, let's consider the IM address resolution mechanism.

Names, Addresses, and URLs
When you send an email message, your SMTP server relies on the existence of a DNS MX record for the target domain to locate the correct SMTP server and deliver the message. When you send an IM message to someone who uses the Exchange IM or MSN IM system, you specify the recipient's email address, such as paul@robichaux.net. The convenience of using the email address masks the fact that Exchange IM servers use the rendezvous protocol (RVP) over TCP port 80—the same port that HTTP uses—to pass traffic. In fact, to send me an IM message, your client would actually send packets to http://exchange.robichaux.net/instmsgs/aliases/paul. Because that URL is a lot to type (let alone remember), IM requires a scheme to turn email addresses into IM URLs.

The solution lies in the DNS SRV record. AD uses SRV records to register the availability of Kerberos logon servers, Lightweight Directory Access Protocol (LDAP) servers, and servers of other useful services. Recall that an SRV record specifies that a service is available for the specified domain; the record includes the TCP or UDP port number on which the service is offered and the IP address of the responsible server. Therefore, an SRV record for the microsoft.com DNS domain can specify precisely which protocol or service (RVP, in this case) the server offers, the port number (TCP 80), and the IP address or DNS name (im.microsoft.com). Given the DNS domain of the recipient, IM software can use the SRV record to identify the IP address of the IM server.

What if no SRV record is available? In that case, the Exchange IM client must use the DNS domain name in the URL, so joe@somedomain.com turns into http://somedomain.com/instmsg/aliases/joe. If Joe's administrator has properly configured his Web server to forward RVP requests, this approach works too.

   Previous  [1]  2  Next