In my Windows 2000 Magazine> article "Exchange 2000 Server's Instant Messaging" (November 2000), I described the architecture of the new Exchange 2000 Instant Messaging (IM) subsystem and its basic feature set. Time is a wonderful teacher, and my experience using IM since I wrote that article has revealed some interesting questions about the software that deserve further discussion.
Does IM Require a Win2K Account?
The schema extensions applied to Active Directory (AD) when you first install Exchange 2000 in a forest include attributes to specify who uses IM, the server they log on to, and so on. Therefore, you must have an AD account before you can have IM. The enabling process allocates your account to a home server, which the IM client contacts whenever someone wants to have an instant conversation with you. You also need a mailbox on an Exchange 2000 server. The IM service is an extension of Exchange 2000. Although you use a Win2K account to access a mailbox on an Exchange Server 5.5 server, you can't associate an Exchange Server 5.5 mailbox with an IM server; therefore, you can't use IM unless Exchange 2000 is in place.
Figure 1, page 2, shows the properties of my Win2K user account. The Exchange Features tab defines details of the optional subsystems that users can use. If Exchange 2000 Conferencing Server were available to me, you'd see an entry for it here. By default, Win2K disables access to optional subsystems; administrators must explicitly enable users before they can use a facility such as IM.
IM's dependency on Win2K and Exchange 2000 means that it will be some time before the Exchange community adopts IM widely. The silver lining in this cloud is that Microsoft can use this lag time to fix some of the shortcomings in the current implementation. These shortcomings include the lack of integration between Outlook and IM, which Microsoft will likely address in Office 10 (the tentative name for the next Outlook version), and the inability of IM conversations to flow into a corporate network through a firewall. Expect some of these improvements to appear in Exchange 2000 Service Pack 1 (SP1).
Who Can You Talk To?
After you've enabled users to use IM, how do they know who else has been enabled for IM? Eventually, all Exchange users will be enabled for IM, and this problem will be moot. However, during the initial stages of IM implementation, only administrators know which users are enabled. Administrators can use the Find option in the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to look for IM users. Select the Advanced tab, then build the search expression Instant Messaging Address is exactly *. You build the expression by selecting Instant Messaging Address from the Field drop-down list, then selecting is (exactly) as the condition to look for and * (i.e., all values) as the value. Click Add to add the expression to the search, then click Find Now to scan AD. Figure 2, page 2, shows the result of a typical search.
Users who aren't administrators can't use this method to look for other IM users unless you let everyone use the Active Directory Users and Computers snap-in. This approach isn't as mad as it seems because you can secure the directory so that users can only search and can't change permissions or other user account attributes. Unfortunately, however, if users can search the directory, they can also look at many details of accounts and other objects that you probably want to keep out of general sight. Therefore, you need another solution.
Win2K workstations and servers include the ability to look up AD from the Start, Search option. However, by design, this option doesn't offer the power and flexibility of Active Directory Users and Computers, so you can't search based on attributes such as the Instant Messaging Address. Therefore, this approach isn't very productive.
A third option—and the approach that most people will use—is to search when you add a new IM contact by using the Add option in the IM client. A contact is simply someone that you want to have IM conversations with. The process of adding a contact registers the contact's IM address on your PC so that you can communicate with him or her in the future.
The first step in searching for a contact is to decide whether you want to input an email address or use other criteria to look through AD. Both options result in a search of AD.
Using the contact's email address to look for a contact is the fastest option if your company is small and the namespace used for email addresses is logical. Problems occur when you have several people with the same name (such as John Smith) or if the namespace uses an unfriendly naming scheme (e.g., [email protected]) so that you can't easily guess someone's email address. Compaq's Global Address List (GAL) includes more than 75,000 mailboxes, so I usually select the option to search for a contact, as Figure 3 shows. When IM finds a suitable contact, you can add it to your contact list and begin a conversation immediately.
Where Are Contacts Stored?
Unlike most other Exchange 2000 data, IM contacts aren't held in AD. This arrangement is logical for two reasons. First, IM stores very little data on a server. Second, contacts are personal data, so it makes sense in some settings to store them on a workstation.
Two IM versions are in use, and where the IM contacts are stored depends on the application. For example, the MSN IM stores the contact list on a Hotmail server. This arrangement makes contacts available from whatever workstation you log on to. In Exchange IM, the registry stores your contacts list in the HKEY_CURRENT_USER\Software\Microsoft\Exchange\Messenger\Profiles registry subkey. The name of the IM domain that you use is then specified under the Profiles subkey. If you use several IM domains (e.g., one for production, one for testing), a separate subkey is maintained for each domain.
The form of the domain subkey is http://im_domain/instmsg/aliases/user, where im_domain represents the name of the IM domain. I discuss the IM domain in more detail later in this article. The rest of the subkey identifies the name of the IM application as known to Microsoft IIS (i.e., instmsg), then refers to aliases for the contacts. The last part of the subkey holds the name of the user as he or she is known to IM.
A Contacts subkey is held under each IM domain subkey. The contacts are stored as a set of values under the Contacts subkey. Figure 4 shows the values for a set of contacts I used for a test implementation. You can also see that separate values are maintained for separate sets of contacts for two different IM domains.
How Do I Move Contacts Between Workstations?
The problem that occurs when any data is maintained in the registry is how to move the data between workstations. For example, if you use a desktop system in the office and a notebook on the road, you have to either recreate your set of IM contacts or come up with a method of moving the data from one workstation to the other. You can move data reasonably easily, but you must perform the task manually and tell users to use the regedit utility to make registry changes, which most administrators prefer not to do. (You can avoid using regedit by importing contacts into the registry behind the scenes as part of a logon script; however, this task isn't always easy to carry out.)
To use regedit to move contacts from one workstation to another, you need to use the Export Registry File option to back up the registry subkey that contains the IM contacts to a registration entries (.reg) file. You can also use the regedt32 utility to accomplish a similar result, but the option is different. Figure 5 shows the dialog box you see when you use regedit to export the data.
After you create the export file, you can move the registration entries file to any other workstation and use regedit's Import Registry File option to import the contacts into that workstation's registry. Of course, you need to make sure that the IM client is installed on the workstation, because the contacts are available only if the software is present.
The problem with moving contacts might go away in a future Exchange release, when contacts might be held in AD as properties of a user account. However, if you want to implement IM now, you need to work out how you're going to deal with the challenge of moving contacts.
How Should I Configure Namespaces and IM Domains?
The name of the IM domain is defined within Exchange 2000 as a property of the IM application. IM can use a separate namespace (e.g., im.abc.com), or you can configure IM to use the same namespace for both IM and email. The latter approach is better in many respects because most users prefer not to remember two addresses for the applications. It makes sense to use [email protected] for both, if at all possible.
In either case, the IM client uses DNS to resolve IM addresses and locate the servers that will handle requests to connect users. A request to connect to addresses such as [email protected] or [email protected] will provoke a DNS lookup for a rendezvous protocol (RVP) record for the supplied address. The RVP—a WWW Distributed Authoring and Versioning (WebDAV) extension to HTTP 1.1—adds the Subscribe and Unsubscribe methods (to subscribe and unsubscribe contacts, respectively) and the Notify method (to notify contacts of status changes). The IM client then routes the request to the server found by the lookup. For details about how IM handles the connection, see my November 2000 Windows 2000 Magazine article.
IM associates every IM user with an IM home server. In small implementations (fewer than 10,000 users) that don't span large networks, you can use one server to host all users. Larger implementations or those that span low-bandwidth network links (less than 128Kbps between servers) might need additional IM servers, including special servers called IM routers, which IM uses to refer requests for new IM connections to the correct home server.
Remember that IIS handles all Internet protocol access for Exchange 2000, including RVP. Exchange 2000 accesses each protocol through one or more virtual servers, each of which is associated with a TCP/IP port number. You can think of a virtual server as a combination of a protocol and port number.
Win2K's User Principal Name (UPN) feature lets you define one name for logging on to Windows, addressing email, and identifying a person to other applications. Thus, I can use [email protected] to log on, have email sent to me, and access applications such as IM. To use one name, you must set up DNS correctly with RVP service records so that IM can resolve UPNs into the unique addresses that IM uses internally. However, supporting UPNs is optional, and many consultants believe that maintaining a separate address for IM (e.g., [email protected]) is a better approach. As this discussion shows, you must perform a reasonable degree of namespace planning before you introduce IM. You can start off with one namespace and change over to unique namespaces if needed (e.g., if you find that another design is better or that you must change you're design as the result of a corporate name change or merger). However, if you change the namespace, your users must recreate their personal contacts.
After you enable users and design the namespace and AD has replicated the necessary information throughout your organization, IM access is quite painless. However, one client-side aspect often trips people up. IM uses browser proxy information to determine how to connect to the home server. You must exclude the domain where the IM home server resides, or you'll fail to connect, or even worse, generate multiple failed attempts to log on that result in a locked account. For example, if you use im.abc.com as your IM domain, im.abc.com or *.abc.com must be excluded in the proxy settings that your browser uses.
What Clients Can You Use with IM?
Two MSN Messenger Service clients support Exchange IM. MSN Messenger Service 2.2 is bundled with Exchange 2000. MSN Messenger Service 3.0 is slightly better integrated with Exchange 2000 because it incorporates an option to switch to your Inbox in case, for example, you want to send a traditional email message to complete a thought you began in IM. However, this capability doesn't mean that IM messages end up in your Inbox. MSN 3.0 also includes new features such as support for emoticons (symbols that express emotions), integration with Microsoft NetMeeting, and the ability to include voice in your IM conversations. Both clients can connect to Exchange IM and MSN IM, as long as your corporate firewall lets MSN traffic pass out to the Internet (IM uses port 1080).
IM doesn't require you to deploy Win2K Professional workstations (you just need to log on to a Win2K domain). IM supports Windows NT 4.0, Windows Millennium Edition (Windows Me), and Windows 9X workstations, but check out http://www.microsoft.com/exchange/techinfo/deployim.htm for steps you need to take to get IM working smoothly on these platforms. Further details are available from http://www.microsoft.com/exchange/downloads/imclient.htm, which also includes a location from which you can download the MSN 2.2 client. Various language versions of the MSN client are available (e.g., Greek, Arabic, Korean). Check with Microsoft for the latest range of supported languages.
IM clients register themselves with home servers by using the combination of the client's IP address and the port number used for IM communications. As long as these values remain constant, instant messages can get through. Roaming through a wireless network that allocates new IP addresses or switching to another network connection (e.g., moving from a LAN connection at work to a dial-in connection at home) will cause IM some confusion. Clients will still appear to work, but any communication sent to them will fail because the IP address has changed. The solution is simple. Stop and restart the client, and the new address will be registered to enable communications to flow again.
Is IM Useful?
Is IM useful? After using this tool daily for several months, I say that it is. IM takes a little getting used to, mostly because you must decide when to use IM and when to send regular messages. However, after you make that decision, IM is tremendously useful. It speeds communication, eliminates many to-and-fro email threads that clog mailboxes, and preserves a certain degree of confidentiality because no trace of instant messages is retained on any server. You can capture conversations in a text file by using the File, Save option, but it's unlikely that such a file would be admissible in a court action in the same way that an email message is now acceptable evidence. After all, anyone can create a text file, but it's substantially harder to fabricate a message thread that potentially involves transmission through several different email servers.
This last point can't be overlooked. We live in an era when the demand of lawyers' discovery actions causes serious concern to senior management and email administrators alike. Sometimes people want to have a conversation without leaving a record. IM certainly serves this purpose, but this and the other IM advantages probably isn't enough to make companies deploy Win2K and Exchange 2000 any faster than they already have planned. IM will affect the Exchange community, but not yet. Until then, people who are lucky enough to have this facility available will luxuriate in instant connectivity and private conversations.
