IM catches on in the business world
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 firstname.lastname@example.org. 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 email@example.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.
Enter IM Routers
Each IM-enabled user account actually has two separate URLs. As I discussed earlier, one URL contains the name of the server registered in the SRV record. The other URL contains the name of the user's home server. Because an organization can have multiple home servers and because putting them outside the firewall exposes your systems to an unnecessary security risk, IM needs a way to tunnel messages from the one well-known server listed in the SRV record to the correct home server. Enter IM routers, whose job is to route IM messages to the correct home server for a particular user. IM routers, one of which is required for every two home servers, use the two URLs registered for each IM-enabled user to determine where to send messages for that user. Redirecting messages to the appropriate server occurs one of two ways.
First, the router can issue HTTP 302 redirection messages, which it typically sends to redirect an IM client to another server within a corporate network. Consider the case of Alice, whose home server is TORNADO. She wants to send a message to Bob, whose home server is HURRICANE. When Alice sends a message to Bob, her client must look up an SRV record to find the correct server for Bob's domain, which just happens to be the same as hers. Her client sends the message to the IM router, which issues an HTTP 302 redirection message to tell Alice's client the correct URL for Bob (i.e., http://hurricane/instmsg/aliases/bob). Alice's client then resends the message to Bob's home server, which passes it on to Bob's client. The second method is a little more complex: If Alice and Bob are in separate organizations, the router sends the message directly to Bob's home server. (There's no point in sending an HTTP 302 redirection message back to Alice because she almost certainly won't have direct access through the firewall to Bob's home server.)
Installing the Exchange IM Server
The IM server components are easy to install. The primary server piece, msimsrv.dll, is actually an Internet Server API (ISAPI) extension that Microsoft IIS loads and runs on the IM server or router. First, you must change your Exchange server configuration. Use the Exchange setup program to select and add the Exchange Instant Messaging component. After the installation finishes, you see Instant Messaging (RVP) in the Protocols container. Now, you can follow these steps to create a new IM virtual server:
- Right-click the Instant Messaging (RVP) node. Select New, Virtual Server from the context menu.
- When the New Instant Messaging Virtual Server Wizard starts, enter a display name for the server. This name is what you'll see in the Active Directory Users and Computers snap-in when you enable IM for a user.
- Select the IIS Web site on which you want to host the IM DLL. Most of the time, you'll probably use the default Web site, but you can create a separate site if you prefer to have users use a different URL for their IM traffic. Of course, because users won't see the name, this step isn't really necessary.
- Provide the DNS name of this particular IM server. Clients use this name to find the server, so it should be a Fully Qualified Domain Name (FQDN). By convention, most IM sites use im.domain.com as the IM server name.
- The last screen of the New Instant Messaging Virtual Server Wizard lets you specify whether you want the new server to act as an IM home server or as a router. If you want this server to be an IM home server, select the Allow this server to host user accounts check box (by default, it's not selected).
These steps create the IM virtual server, but you must create an SRV record for it on your DNS server so that clients can use DNS to find the virtual IM server. Doing so is fairly straightforward; you use the MMC DNS snap-in.
- Launch the DNS snap-in (dnsmgmt.msc) and expand the forward lookup zone for your DNS domain.
- Right-click the domain and choose New Other Records. When the Resource Record Type dialog box appears, scroll down to Service Location, select it, and click Create Record.
- When you see the New Resource Record dialog box, which Figure 1 shows, type
- Launch Windows Messenger.
- Select Tools, Options to open the Options dialog box.
- Go to the Accounts tab, which Figure 3 shows.
- Select the My contacts include users of a communications service check box. In the Sign-in name field, enter the sign-in name for your IM server.
- Choose how you want your particular client to sign in. You can choose to sign in either with Exchange first (click the Communications Service radio button) or with your Microsoft .NET Passport account.
- Click OK. Windows Messenger will tell you that your changes won't take effect until after the next time you sign out, then sign back in.
- After you sign out and back in, your contact list will show contacts from your MSN Messenger and Exchange accounts.
in the Service field, set the port number to 80, and enter the externally visible DNS name of your IM server in the Host offering this service field.
After you create the SRV record, your only remaining task is to enable your users' accounts for IM. You can use the Exchange Features tab of the User Properties dialog box in the Active Directory Users and Computers snap-in to enable users one by one. Select the user account, open its Properties dialog box, go to the Exchange Features tab, select Instant Messaging, and click Enable, as Figure 2 shows. You'll be prompted to select the home server you want to host the user account. Alternatively, you can enable IM for multiple users at one time by selecting them in the Active Directory Users and Computers snap-in, right-clicking one of the selected users, and launching the Exchange Tasks Wizard.
Setting Up IM Clients
The Exchange IM client is included on the Exchange product CD-ROM. Don't confuse the Exchange IM client with the MSN Messenger or Windows Messenger clients. Although the Exchange IM client shares features with the other two, some key differences exist. All three available clients use a plug-in architecture that lets each client support multiple protocols. However, if you want to use Exchange and MSN IM at the same time, you must install the MSN client first, then install the Exchange IM client on top of it.
Windows Messenger in XP supports using both MSN Messenger and Exchange IM at the same time. Follow these steps to configure Windows Messenger to use MSN and your own Exchange service:
IM isn't a complete replacement for phone or email. For example, IM doesn't let you archive traffic for legal or regulatory compliance (although third-party products provide this function). For more information about third-party products for IM, go to the IT Buyer's Network at http://www.itbuynet.com. IM also doesn't let you encrypt traffic between two clients, although you can use IP Security (IPSec) to encrypt it. However, the Exchange IM server included with Exchange lets you tap IM's power on your network for your users without having to depend on the availability of external services.