Chapter 19 - Chat and Instant Messaging Services

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Michael Aday, Senior Consultant, Microsoft 

Microsoft Exchange 2000 Server introduces real-time collaboration services that allow distant users to collaborate, to be better connected, and be more accessible for business communication. New services include data conferencing and video conferencing (which are shipped as a separate product), and Instant Messaging. These services, along with Chat Service (introduced with Microsoft Exchange Server version 5.5), can be deployed in various ways. This chapter presents information about best practices and initial approaches to deploying Chat Service and Instant Messaging in Exchange native-mode and mixed-mode environments.

The recommendations provided here are guidelines for including the Exchange 2000 real-time collaboration services in a messaging infrastructure. These recommendations might not be applicable in all customer scenarios. Examine your own implementation plans before following these recommendations.

Chat Service Overview

Internet Relay Chat (IRC) has existed for many years as a collaborative capability hosted by larger Internet Service Providers (ISPs). With the release of Microsoft Exchange 5.5, you could add this collaborative service to an existing Exchange messaging infrastructure to provide a virtual meeting place for scheduled or spontaneous text-based discussions. Using Chat Service allows a group of people to share ideas in a textual format, in either moderated or unmoderated real-time conversations.

In Exchange 2000, Chat Service takes advantage of Active Directory and its inherent management benefits, while still adhering to IRC standards. Chat Service uses Active Directory to store configuration information and objects such as chat communities, channels, classes, bans, and chat servers. The Exchange 2000 System Manager snap-in can consolidate these items into one interface. In addition to storing configuration and object information in Active Directory, Chat Service uses authentication and access controls from Microsoft Windows 2000 to determine a client's ability to connect to a chat community or join a chat channel, and to define administrative roles such as system operators and chat administrators.

The Exchange 2000 Chat Service implements the IRC (RFC 1459) and Extended IRC (IRCX, currently in RFC draft) protocol standards, allowing for the use of IRC clients such as Microsoft Chat Service. Chat Service allows you to create channels for one-to-many and many-to-many text conversation. Chat administrators can moderate the use of and access to chat communities with bans and classes, and allow users to host or moderate a chat channel's content.

Chat services in Exchange 2000 have been designed to support greater scalability than earlier releases. While Exchange 5.5 Chat Service relies on portals between chat servers to add additional concurrent connections to the chat infrastructure, Exchange 2000 can host an equivalent number of users on a single server. It is possible to consolidate larger chat channels hosted on several Exchange 5.5 servers onto one Exchange 2000 server.

Deploying Chat Service

It is easier to manage Chat Service when the information is stored in Active Directory. To do so, Active Directory must first be deployed in the organization. In addition, a Windows 2000–based server cluster must be available to host the service to utilize Chat Service's clustering capabilities. While clustering will not preserve specific chat server channel content, it will provide for failover of persistent channels that have been defined in the chat cluster.

Deployment of Chat Service in Exchange 2000 is fairly straightforward; however, before you deploy Chat Service, you should make some decisions about chat channels. For example, do you need registered (permanent) channels in your environment? What types, and how many channels should you host? Do you want to host channels that are accessible from outside your firewall?

Chat channels can support a variety of channel modes that determine the types of connections and content that can be hosted by the channel. Auditorium mode, for example, is used to host a very large number of concurrent users who are listening predominantly to a few presenters. This channel mode prevents each user in the channel from seeing the other users; each user sees only the presenters, while the presenters can see all the members of the channel. For more information about the various channel modes, see the Exchange 2000 Server online documentation.

Multiple channel modes can be set when you create the channel. Administrators and system operators can also change channel modes by using a chat client.

Communities and channels in Chat Service can be protected with a variety of authentication mechanisms. Chat clients can authenticate with Exchange 2000 Chat Service by using the Microsoft Windows 2000 security service provider interface authentication mechanism.

Chat Service Deployment Process

An overview of the Chat Service deployment process follows:

1. Plan the infrastructure, determining server locations and properties of required objects, such as the number and types of channels. Determine channel authentication, define bans to be created, and determine which users will administer the services. 

2. Establish a meaningful naming convention for your chat servers. Be aware that a naming standard may already be in use. Where applicable, adhere to the existing standard as closely as possible to prevent confusion. 

3. Install servers to host the services. Exchange 2000 Chat Service can be installed as a service on an existing Exchange 2000 server, for example, a server already hosting Instant Messaging or Exchange 2000 Conferencing Services management components. If you want to deploy multiple services on one server, recognize that a heavily-utilized Chat Service requires significant server resources in terms of memory, CPU, and network throughput to meet customer response-time expectations. 

4. Configure objects within the chat topology. If you do not want any registered channels, bans, or classes, no objects need to be created. 

5. Create the required Domain Name System (DNS) resource records (typically, a host record) for each chat server. Decide which servers, if any, will be able to host externally-accessible chat channels. Remember that there may be internal and external DNS requirements; be sure to register the servers in the appropriate zones. 

6. Make chat client software available to users. 

For more information about the deployment process, see the Exchange 2000 Server online documentation.

Chat Server Scalability

Chat Service scalability has been significantly enhanced when compared with the implementations in Exchange 5.5. For example, Chat Service no longer uses portals. These changes permit up to 20,000 concurrent users per server.

During an IRC session, the server can resolve DNS names for the client upon connection and cache those names for the duration of the session. This procedure is useful for access control and attack protection.

Once connected to the server, users will generate traffic when they post messages or when messages are received. In most cases, these transfers will be small and come in periodically, depending on the activity level of the channel. Users continue to generate network traffic to the server for the duration of the connection.

Chat Server Location

Small companies that are highly centralized can have a single server providing chat services throughout the company.

The chat infrastructure topology in larger companies will likely mirror the distribution of data center hubs in the company's WAN topology. To facilitate localization of network traffic associated with logon and operation of chat clients, larger multinational or geographically-distributed companies may want to locate Exchange 2000 chat servers at the departmental or regional data center level in the company. For larger companies that use Chat Service as a supplemental collaboration component for other event, such as company-wide broadcasts, servers can be centralized in a single location.

For example, a company has approximately 15,000 employees geographically dispersed between three regional data centers (Seattle, Houston, and New York). The New York location has 500 to 1,000 users, the Houston location has 2,000 users; 1,500 users are remote and the balance of the users (10,500) is located in Seattle, the company's headquarters. It will be most beneficial to locate the chat servers in the Seattle location. If additional resources are available, it could be advantageous to place a server in Houston as well. However, if multiple servers are used to host content for a single channel, the company might want to develop a custom IRC client that can post to each instance of the channel on each of the servers. The company could also simply host all 15,000 users on one server in the Seattle location.

Figure 19.1 Large company deployment with Active Directory Connector (ADC) 

If you have previously deployed Exchange 5.5 and want to pilot Exchange 2000 real-time collaboration components such as Instant Messaging and Chat Service, you can do so with minimal impact to the existing deployment by deploying sufficient Active Directory and Exchange 2000 Server resources to host the services. If you support less than 5,000 real-time collaboration users, a single server is sufficient for Exchange 2000 Instant Messaging and Chat Services along with another server that hosts Active Directory and any ADC connection agreements that may be necessary to synchronize user display name and account information between the production and pilot infrastructures. The Active Directory Connector is not required in all configurations, but is necessary in mixed-mode Exchange 5.5 and Exchange 2000 topologies.

As concurrent user connections increase, or when you choose to deploy a more stable pilot, you should host these services on separate computers, beginning with the ADC and then if resources allow, Instant Messaging and Chat Service.

Depending on the concurrent usage of the Chat Service, you might decide to deploy servers that are shared by multiple services. However, you will likely exceed the capacity of a single server sooner or later.

To minimize the administrative overhead associated with the server, you should bundle services that do not save data in Web Storage System, if possible. If you do, the server could host Instant Messaging, Chat Services, video conferencing, and Exchange Collaboration Services management components for as many as 300 users, depending on the amount of activity. This assumes fairly constant data and video conferencing between 2 to 10 concurrent users, and active Instant Messaging users sending three or more messages per hour with 20 or more people on each user's Instant Messaging contact list.

Note that, as with all server-sizing estimates, the above example is a rough estimate based on a hypothetical user load. If you choose to deploy these services on a single server and it fails, all of these services are unavailable. As services grow more crucial, it is important to partition services onto separate servers.

In branch office deployments, the need for Chat Service within a company should be considered independently of WAN topology. If you expect specific client populations within the company to use Chat Service heavily, it might be beneficial to put a local chat server source close to the clients.

Network Address Translation and Internal Firewalls

IRC services are not affected by network address translation or by firewalls, provided the clients can connect to the ports, as described in the following section.

Security and TCP Ports

Chat Service in Exchange 2000 Server is self-contained. It requires only Active Directory to save the configuration and management information about the chat infrastructure and host servers and to verify access permissions for secured channels. Chat Service transmits information over known ports for IRC (port 6667, by default) and DNS resolution (port 53), simplifying firewall-specific issues.

Clients connecting from remote locations through ISPs can connect to channels on servers offering Chat Service if they are able to resolve external DNS entries. This poses a risk because there is no inherent protection, such as a session layer encryption, of the content of an IRC session even if clients have been authenticated with a strong authentication package such as MD5 Digest or NTLM protocol. During an IRC session, messages are sent back and forth between the client and the server as clear text over port 6667.

Because users can send sensitive information and the information travels as clear text, chat security can be a concern. IRC sessions currently lack encryption support, such as Secure Sockets Layer (SSL) encryption or Transport Layer Security (TLS) encryption. Virtual private network (VPN) protected sessions, such as Point-to-Point Tunneling Protocol (PPTP), Layer 2 Tunneling Protocol (L2TP), or IPSec tunnel (and IPSec are available in Windows 2000) can be used to encapsulate an entire communications stream; however, if you use network address translation for servers and clients, you could have connectivity problems.

Basic Chat Service Recommendations

The following are guidelines for deploying Chat Service.

• Keep the naming standards for channels and servers as simple as possible. Be aware of the use of internal names, as described earlier in this chapter. Verify that the proper service records have been entered in all internal DNS servers, and if you offer chat services across a public network, in external DNS servers. 

• Deploy chat servers to high population client locations based on network topology. 

Instant Messaging Overview

Instant Messaging in Exchange 2000 permits small groups of two or more users to exchange basic HTTP messages using a small client-side component and an Internet Server Application Programming Interface (ISAPI) server extension running on a Microsoft Internet Information Services (IIS) server. The main difference between e-mail and instant messages is that instant messages are not saved in Exchange 2000; once a message has disappeared from the screen, it is gone forever. Another difference is that Instant Messaging informs users when their contacts are logged on to the system. This presence information is the most valuable feature of Instant Messaging.

Instant Messaging uses HTTP 1.1 over TCP port 80 and uses a simplified address (based on RFC 822) to identify users. Instant Messaging can be installed separately from other Exchange services; however, it requires the existence of an Exchange 2000 organization.

An Instant Messaging implementation is comprised of the following components:

• Instant Messaging home servers These servers are responsible for hosting user accounts and tracking each user's contact lists for posting presence information. Each Instant Messaging home server can support approximately 10,000 online users. 

• Instant Messaging routers These servers route incoming requests from Instant Messaging clients to their home servers. By placing Instant Messaging Router servers at strategic locations in the deployment architecture, systems can scale more smoothly and provide additional security and management capabilities. Each Instant Messaging router can support approximately 50,000 online users. Routers also allow companies to establish and maintain single Instant Messaging namespaces for all Instant Messaging users, regardless of their home servers. 

• Clients Computers with Instant Messaging client components installed on them. 

• Windows 2000 domain controllers Instant Messaging uses NTLM protocol and digest authentication to permit a user access to the service. Windows 2000 domain controllers authenticate users and return configuration information to Instant Messaging Microsoft Management Console (MMC) consoles. Domain controllers also facilitate Instant Messaging servers in determining whether a resource is local or needs to be relayed to some other network location. 

• Firewalls The presence of firewalls is likely in enterprise-wide Instant Messaging deployments. Internal firewalls in a departmental deployment are also possible. 

• DNS records Instant Messaging relies on DNS to return name resolution information for specific services, such as Simple Mail Transfer Protocol (SMTP) and mail exchanger (MX) host records. It is essential to have the correct A (host) and SRV (service) records published to the proper DNS server in an Instant Messaging deployment to ensure that clients are able to resolve host name information properly. 

More than one Instant Messaging domain can exist in a deployment. In larger, geographically dispersed companies or in installations that are supported by more than one Windows 2000 forest, multiple Instant Messaging domains should be created. These scenarios are explored in greater depth later in this chapter.

Deploying Instant Messaging

To deploy Instant Messaging, you will need Windows 2000 Active Directory and because Instant Messaging is installed within the context of an Exchange 2000 organization, you will also need information about any existing Exchange 2000 topology.

If you are upgrading an Exchange system to Exchange 2000, the installation is relatively straightforward. However, you can pilot Exchange 2000 features such as Instant Messaging before concluding the upgrade of an existing Microsoft Windows NT 4.0 and Exchange 5.5 environment. All that is required to install Instant Messaging is Windows 2000 Active Directory. It is possible to connect the existing Exchange 5.5 environment and the new Exchange 2000 Instant Messaging installation by using ADC.

The following sections discuss the deployment of Instant Messaging in mixed-mode and native-mode Exchange environments and provide direction on possible implementation considerations based on company requirements and typical installation practices.

Instant Messaging Deployment Process

An overview of the Instant Messaging deployment process follows:

1. Plan the Instant Messaging network, including its topology and server resources. Determine how many home servers and Instant Messaging routers are required to support the users. Instant Messaging home servers host user accounts; Instant Messaging routers route messages to home servers. 

2. Establish a naming convention for your Instant Messaging servers and user addresses. 

3. Install Instant Messaging on servers running Exchange 2000 Server where you plan to create Instant Messaging home servers and Instant Messaging routers. 

4. Configure your firewall topology by defining the local IP networks and proxy server that your Instant Messaging client uses. 

5. Use IIS to create a virtual directory for each Instant Messaging home server and Instant Messaging router. 

6. Create the required DNS resource records for each home server and Instant Messaging router. 

7. Set administrative permissions. 

8. Set the password policy on the domain controller. This is necessary only if you use digest authentication. If you use NTLM authentication, a policy change is unnecessary. 

9. Enable users to access Instant Messaging. Create new Instant Messaging accounts, or enable existing user accounts for Instant Messaging. If users are not on the system, first create Windows 2000 user accounts. 

10. Make the Instant Messaging client software available to users in your company. 

For more information about the Instant Messaging deployment process, see the Exchange 2000 Server online documentation.

Exchange 2000-Only Deployment

Instant Messaging is installed as a separate component in Exchange 2000 Setup. If you are installing the service in an existing Exchange 2000 environment, the process is simple. However, the following issues and considerations must be resolved before you deploy Instant Messaging:

• Determine the number and location of Instant Messaging servers. This should be based on the location and number of users in your company. 

• Investigate physical LAN and WAN topologies and issues. If your company is multinational or has users that are participating in the services over very slow links, you may want to place servers closer to those groups of users. If your company hosts multiple SMTP domains based on country or region, you might want to set up more servers and Instant Messaging domains to facilitate management or to set up a configuration that closely matches your SMTP architecture. 

• Choose the administrative group for each Instant Messaging server. After you place an Exchange 2000 server in an administrative group, you cannot move it to another administrative group. 

• Determine if access to the Instant Messaging system from other public networks, such as the Internet, is necessary. Secure access from external networks requires additional servers acting as Instant Messaging routers, HTTP proxy servers, and reverse proxy servers. 

Depending on the existing network topology and the intended audience for the services, a wide variety of implementations are possible.

Exchange 5.5 Deployment

Instant Messaging can be deployed as an addition to an existing Exchange 5.5 environment, because the client is a separate software installation. It is not necessary to upgrade in totality to Exchange 2000 for Exchange 5.5 to use Instant Messaging. However, certain requirements must be met to provide this functionality.

Exchange 2000 Instant Messaging in an Exchange 5.5 environment requires that Active Directory and the Windows 2000 infrastructure is deployed. Instant Messaging relies on Active Directory for the mapping of physical URLs to logical URLs and for the initial digest authentication that determines a user's access to the system. A Windows 2000 infrastructure can be deployed and connected to the Exchange 5.5 environment by using Active Directory Connector (ADC). You do not need to change the existing Exchange 5.5 environment, provided the target server for the ADC connection agreement is running Exchange 5.5 Service Pack (SP1).

Instant Messaging can be deployed only on a computer running Windows 2000 Server. However, for smaller companies, ADC and Instant Messaging services can be installed on the same server. This ADC installation must synchronize existing display names and user's SMTP addresses from the production infrastructure to the host Windows 2000 environment. Once these accounts have been replicated into Active Directory, they can be Instant Messaging-enabled though the Active Directory Users and Computers snap-in, or you can bulk-enable users through an Active Directory Service Interfaces (ADSI) script.

Once properly installed, Windows 2000–based clients that are using Instant Messaging will display the friendly name rather than the e-mail alias. If Instant Messaging is deployed on earlier Windows clients, you must install extensions that allow the operating system to communicate with Active Directory. For more information about Active Directory Client Extensions, search the Microsoft Web site at https://www.microsoft.com or see the Clients directory on your Windows 2000 Server compact disc.

Instant Messaging Routers and Home Servers

Several functions can be assigned to multiple servers in an Instant Messaging architecture. Specifically, Instant Messaging servers can serve two distinct functions: Instant Messaging router and Instant Messaging home server. These functions can be deployed on the same computer. This is a viable configuration for smaller companies that host a relatively small number of users, have one geographic location, and connect to the Internet using an ISP. Figure 19.2 illustrates a typical Instant Messaging deployment in a small company.

 

Figure 19.2 Small company deployment 

In this type of deployment, one computer performs all of the Instant Messaging functions associated with an Instant Messaging router and home server.

If you deploy more than one Instant Messaging user home server, a separate server must perform the role of the Instant Messaging Router to prevent partitioning of the Instant Messaging namespace and consequent poor performance. Deployment of a separate Instant Messaging router allows incoming connections from Instant Messaging clients to be redirected to their appropriate home server more readily and prevents all Instant Messaging servers from being registered in an externally visible DNS. Figure 19.3 illustrates how a mid-sized company might deploy Instant Messaging.

Figure 19.3 Mid-sized company deployment 

If your company is likely to exceed the capacity of one server, you will want to have one or more Instant Messaging router servers. The deployment of one or more Instant Messaging router server is necessary in the following instances:

• Your company wants fault tolerance or load balanced Instant Messaging router servers for performance reasons. Instant Messaging routers can load balance by using round-robin DNS or, more preferably, by using network load balancing. 

• A company with multiple e-mail domains, such as a multinational company that has partitioned its SMTP namespace geographically. For example, a company has an SMTP namespace, us.contoso.tld, for e-mail within the United States and other SMTP namespaces for other geographic areas such as, gb.contoso.tld. This company would have multiple Instant Messaging domains with one or more Instant Messaging routers associated with each of them. 

  Note Throughout this chapter, the root domain name .tld is used to distinguish fictitious or sample domain names from actual domain names. Typically, the root domain name is .com, .edu, .org, .net, and so on, rather than .tld. 

• A company has a geographically distributed infrastructure. Depending on the available WAN bandwidth, Instant Messaging router servers would either be deployed in areas with Instant Messaging home servers or in a central location, such as the company headquarters. To prevent excessive traffic to the central location, Instant Messaging home servers would be distributed geographically to each location with Instant Messaging users. 

• A company has more than one Windows 2000 forest. Each forest is an independent Instant Messaging installation with an associated Instant Messaging domain. This installation is redundant and should be avoided except when the forest namespace is no longer contiguous. 

• A company has exceeded 50,000 concurrent users for an Instant Messaging service in a particular location. As an example, a company has 80,000 employees in one geographic location and plans to deploy Instant Messaging services for all 80,000 users. 

As organizational topologies grow larger, additional servers might be required to handle external and incoming requests, to host larger numbers of concurrent users, and to route users to their appropriate home servers more effectively. These servers may be deployed in multiple geographic locations or in a central location, depending on a company's needs; however, some of the new server functions are more efficient when placed near a high speed Internet connection.

Companies that want to protect their internal environments more extensively should consider deploying additional servers. The following list contains the components that a company can use to enhance its security:

• HTTP reverse proxy servers (external) Used to send all outgoing information from internal Instant Messaging routers to external addresses. You can deploy these servers to protect the internal architecture from public network-connected clients. When deployed, all information appears to be coming from one or small number of servers, based on an HTTP reverse proxy server per Instant Messaging domain. These servers should be placed near high-speed Internet connections or near dial-up services. 

• HTTP proxy servers (regular outbound) These servers consolidate outgoing HTTP requests and might already be in place. Instant Messaging uses HTTP requests and requires no special configuration on these servers. However, there is no benefit in caching the returned information because the information is client-specific. These servers should be set up near high-speed Internet connections. 

• Instant Messaging routers for multiple Instant Messaging domains (matched to multiple SMTP domains) These servers should be distributed to serve larger user populations and consolidated where user population is sparse and in remote locations. 

• Instant Messaging home servers These servers can be deployed at remote locations to reduce the long distance bandwidth consumed by user log on and presence update information. This assumes that remote groups work more frequently with one another, therefore presence notification and messaging traffic is confined mostly to those locations. 

Figure 19.4 Large company secure deployment 

Relaying Requests Across the Network

In a global company, there are likely to be many disparate subnets and internal firewalls. Instant Messaging routers determine whether the source server can make the request to the destination directly, whether to forward the request and return the results to the source server, and whether to reject the request. Routing decisions are based on network topology and on source and destination IP addresses of requests, and functions similar to a network basic input/output system (NetBIOS) component on network routers.

By default, information is not published outside the firewall. You must configure the firewall to allow traffic to the Instant Messaging router. You can configure Instant Messaging settings in System Manager in the Global Settings dialog box.

Resolving Names for Instant Messaging Servers

Instant Messaging clients use HTTP to communicate with the Instant Messaging home server and router server. Microsoft has developed a protocol called RVP that converts the potentially lengthy URL that is formed and used during these communications (http*://SRV lookup result*/instmsg/aliases/username) into shorter SMTP-formatted addresses. In many cases, this name is the pre-existing SMTP address of the user or the pre-existing address with an "im" prefix attached to the domain name, such as suzan@im.contoso.tld. Instant Messaging uses service location records in DNS for the RVP services to make this referral. This service registration is similar to MX record registration for SMTP mail hosts in DNS. Records are added so that a client requesting a specific service such as RVP service can identify a host that can provide that service.

Registering Instant Messaging Routers in DNS

Instant Messaging router servers must have the fully qualified domain name (FQDN) of the server (for example, im.contoso.tld) registered in DNS with a SRV (service) resource record.

To create a DNS record for the Instant Messaging routing server 

1. Open the DNS Manager console and double-click Forward Lookup Zone. 

2. Right-click the domain to which you want to add the record, and click Other New Records. 

3. On the Resource Record Type tab, select Service Location, and then click Create Record. 

4. On the New Resource Record tab, in Service, type _rvp. In Protocol, select _tcp. In Priority, type 0; in Weight, type 0; in Port number, type 80. 

5. In Host offering this service, type the FQDN. This will be the FQDN of the Instant Messaging router servers in the topology. Click OK. 

The finished registration will resemble the following example:

_rvp Service Location [0][0][80] im.contoso.tld

Client Name Resolution

You might decide to prevent internal clients from resolving external DNS entries for security reasons. If so, an Instant Messaging client will fail on the DNS query for a new contact. For example, a user who wants to add a contact for a particular external domain would be able to resolve a SRV record if the client is able to resolve external DNS entries. However, if the client is blocked from resolving the address, it does not mean that they are unable to conduct an Instant Messaging conversation with the contact from the other organization.

HTTP (port 80) can be made available through the firewalls, even though DNS queries are not allowed. If a client is unable to query a DNS entry for a particular Instant Messaging domain, the user can enter the fully qualified Instant Messaging address for the user (for example, suzan@im.contoso.tld instead of suzan@contoso.tld). In this way the client can be added and conversations can be started even though the client will fail on the initial SRV lookup. Note that when the client has resolved server names, the Instant Messaging Router server is not involved in communications until a new session is initiated. Server and client names are cached for the duration of the session.

Instant Messaging servers use DNS queries to resolve address information for destination connections. If you want to allow communications between internal and external Instant Messaging servers, your company's Instant Messaging servers must always be able to resolve DNS queries for external hosts.

Companies that want to communicate by means of Instant Messaging can do so by configuring routers to work with firewall security and exposing their Instant Messaging infrastructures by using Instant Messaging routers. Clients from one company can connect to servers in other companies by using HTTP, just as they would for internal Instant Messaging. Users can subscribe to presence information when they obtain resolved user names from directories or from aliases provided by correspondents. To configure the firewall settings to allow communication between companies, open System Manager, click Global Settings, and right-click Instant Messaging.

Scalability for Instant Messaging Servers

Independent of geography or multiple e-mail domain issues, the number of servers increases in direct proportion to the size of the user population. In typical corporate settings, most users will be online concurrently at peak times. In hosting scenarios, only a small fraction, of all users will be concurrently online at any given time.

Therefore, a company with 30,000 active users might need three home servers, because almost all 30,000 users could be logged on at the same time. An ISP with 1 million users and a 5 percent peak online rate would need five home servers, because the peak load would be 50,000 concurrent online users.

Server Location and Network Connectivity

Instant Messaging assumes that home servers and Instant Messaging routers are continuously connected to a WAN and that clients are continuously connected to the network (through low-bandwidth or high-bandwidth connections) while logged on. In the simplest case, all Instant Messaging servers could be placed in one location even if the organization contains subnets in multiple branch offices scattered throughout the region or continent. Clients periodically connect with home servers and Instant Messaging routers, but such connections are low-bandwidth, and of short-duration, and can be made easily over long distances, such as across continents.

Low Bandwidth Connections

If a company has multiple concentrations of users separated by low-bandwidth, or expensive links, you should consider distributing home servers to the highest density areas in the network topology.

For example, if a company has significant populations of users in Asia (3,000 users), South America (3,000 users), North America (11,000 users), and Europe (3,000 users), and if the continents are connected by low-bandwidth or expensive links, the company can deploy two or more home servers in North America and at least one user home server in Asia, South America, and Europe, even though the total number of users worldwide would typically require no more than two home servers.

If a geographically distributed company wants to use Instant Messaging to communicate externally and has only one connection to the Internet, all of the Instant Messaging routers (if more than one has been deployed) should be located near the Internet connection. Instant Messaging clients typically communicate far less frequently with Instant Messaging routers than they do with home servers. Instant Messaging clients cache home server information provided by routers. Instant Messaging routers can be placed at any location that has an Internet connection.

Branch Offices

Special considerations should be made when deploying Instant Messaging in companies with many small branch offices and few (10 to 100) users at each location. Most branch office architectures have a continuous connection to the corporate network backbone, although this connection may be low-bandwidth (56 KB or 128 KB). In such scenarios, branch offices have their own Instant Messaging servers or have multiple servers local to each location.

Clients communicate using the RVP protocol, which is asynchronous and requires low bandwidth, so network traffic is a minor consideration when you determine the number of Instant Messaging servers to deploy and how to position them on your network. The increased traffic caused by adding Instant Messaging to the infrastructure will be minimal in most cases.

You must consider administrative issues, such as the management of servers at remote locations, when you decide where to place your servers. For example, you might have branch offices administer their own Exchange servers. If so, the home server for each location could still be located in the enterprise hub. However, if local administrators want to control collaborative services, Instant Messaging servers can be placed at branch offices. When planning server placement, consider deploying Instant Messaging servers based on the concentration of groups of users that will communicate with one another. You can reduce the number of servers to which a client must subscribe and decrease the associated WAN bandwidth for presence information updates by placing servers within these groups and setting up members of highly communicative groups on single or multiple co-located servers.

Network Address Translation and Internal Firewalls

Instant Messaging clients use IP addresses during connected sessions to initiate requests to servers and to conduct communications with other Instant Messaging clients. Instant Messaging servers query DNS to resolve addresses for server-to-server communications. If a client is on a network that is protected by a firewall that is translating IP addresses, the client will be unable to resolve IP information for clients on another subnet. To resolve this issue, you can place a home server on the subnet protected by network address translation. This allows the home server to act as a relay host for client communications with other clients beyond the local subnet.

Security Considerations

In Instant Messaging conversations, messages are sent between all parties as Extensible Markup Language (XML)-tagged Multipurpose Internet Mail Extensions (MIME) message body parts over HTTP. Secure MIME (S/MIME) conversations are currently not supported. Neither is SSL or TLS-encrypted sessions with Instant Messaging servers or between Instant Messaging clients. Instant Messaging can be a security issue when users communicate sensitive information in clear text. You can encapsulate an entire communications stream by using a VPN-protected session (such as a PPTP, L2TP, or IPSec tunnel (L2TP and IPSec are available in Windows 2000), but the communications stream might be susceptible to connection issues if the organization is translating network addresses for servers and clients.

Instant Messaging Deployment Recommendations

Further recommendations for deploying Instant Messaging Service include:

• Keep naming standards for clients, servers, and Instant Messaging domains as simple as possible. Be aware of the use of internal names as described earlier in this chapter. In most cases, you can add the prefix "im" to the SMTP address of users (Sandra@im.contoso.tld) and you should verify that the proper SRV records have been entered in all internal and external DNS servers, if your company wants to use Instant Messaging across a public network. 

• Follow SMTP naming conventions in the construction of Instant Messaging names when your company's multiple geographic locations are served by multiple SMTP domains. For example, a U.S. location that has an SMTP domain of us.contoso.tld associated with it should have an Instant Messaging domain of im.us.contoso.tld. 

• Deploy one or more IIS servers per Windows 2000 site. These servers can host the required virtual server instances for Instant Messaging router or home servers. 

• Deploy one Instant Messaging home server per 10,000 concurrent users, and one Instant Messaging router per 50,000 concurrent users in all but widely geographically distributed companies. In general, the number of home servers increases relative to the number of concurrent users (for centralized deployments). At a minimum, a server hosting this many concurrent user connections requires a dual processor Pentium III or compatible 400-MHz computer with 256 megabytes (MB) of system RAM.