Lesson 3: Implementing Instant Communication Services | MCSE Training Kit (Exam 70-225): Microsoft Exchange 2000 Server Design and Deployment (Pro-Certification)

ASPs will find it attractive to add support for instantaneous communication to their services portfolio because many potential customers will be interested in this technology. Popular Internet messaging sites already provide users with the ability to communicate instantly without the overhead of composing and sending e-mail messages—and even enterprises increasingly recognize IM as a valuable tool.

This lesson focuses on an implementation of Instant Messaging services in an Exchange 2000 organization. You can read about the various roles that IM servers can assume in an IM domain. You can also learn how to configure firewalls to support instant communication across the boundaries of the messaging environment. It is possible, for example, to exchange instant messages with users in other organizations over the Internet.

After this lesson, you will be able to

Explain how users can exchange instant messages in an Exchange 2000 organization and across the organization’s boundaries
Design an IM communication environment connected to the Internet but protected by firewalls or HTTP proxies

Estimated time to complete this lesson: 60 minutes

IM Technology Overview

IM is a client/server technology, meaning both clients and servers are actively involved in the communication process. Users work with an IM client, such as Microsoft MSN Messenger client. The client connects to an IM server, known as the user’s IM home server, and informs the server that the user is now online. The IM server communicates this presence information to other clients that have registered interest in this user. These users can then exchange instant messages with each other (see Figure 8.14). MSN Messenger comes with Exchange 2000 Server and can be installed on Microsoft Windows 95, Microsoft Windows 98, Windows NT 4.0, and Windows 2000.

IM has the following two main features:

Exchange of instant messages Allows you to send text messages and binary files to other users, but these messages are not stored on an Exchange 2000 server. Instant messages are dynamic in nature and they are lost when you close the MSN Messenger window. They are formatted as Multipurpose Internet Mail Extensions (MIME) body parts tagged in Extensible Markup Language (XML) and transferred between clients and servers over the Rendezvous Protocol (RVP), a proprietary protocol developed by Microsoft as an extension to the HTTP/1.1 protocol.
Propagation of presence information Allows you to see when other users are online, idle, or out of the office. In MSN Messenger, you can also control who can contact you. Seven different status settings are supported: Online, Invisible (your presence information is not propagated), Busy, Be Right Back, Away From Computer, On The Phone, and Out To Lunch. There are two other status indicators that the IM client sets for you automatically: Idle and Offline. Idle indicates that you haven’t been working with your keyboard for a defined time. When you close MSN Messenger, your status automatically changes to offline.

Figure 8.14 - The IM principle

More Info: Customizing the MSN Messenger Client

You can customize the MSN Messenger client software using the Internet Explorer Administration Kit (IEAK) 5.5. Among other things, you can brand the MSN Messenger client to use your organization’s name and logo.

MSN Messenger customization options include the following:

Modified graphics, promotional content, and sounds
Individualized organization name and logo
MSN Passport and Exchange 2000 integration settings

The IEAK 5.5 creates a separate setup package for your customized IM service client, which you can distribute separately from Microsoft Internet Explorer. To download IEAK 5.5, got to Microsoft’s Web site (www.microsoft.com ) and search for the phrase "IEAK."

If you do not have IEAK 5.5 at hand, you should change two registry settings to configure the MSN Messenger client to communicate with Exchange and to disable the promotional banners that are displayed at the bottom of MSN Messenger. To achieve this, set the REG_DWORD value called DisableCrossPromo to 0x1 and the REG_DWORD value called ExchangeConn to 0x2 under the following location in the Registry:

 HKEY_LOCAL_MACHINE \Software  \Microsoft  \MessengerService  \Policies

Maintaining Subscriber Lists

Before you can send another user instant messages, the MSN Messenger client needs to obtain that person’s status (that is, presence information). If the desired communication partner is offline, for example, you cannot communicate. To receive status information about other users to send them instant messages when they are online, you need to add them to your contact list.

The IM client attempts to determine the status of a new contact as soon as you add that user by sending a status and a subscription request to that user’s IM home server. The IM client also updates its list of subscribed contacts in the local Registry. Whenever you start your client, it reads this information and again sends the status and a subscription request. Contact subscriptions are temporary on the server, so your client must periodically renew them to obtain continuous presence information about other users.

MSN Messenger keeps track of subscribed contacts under the following Registry key:

 HKEY_CURRENT_USER \Software  \Microsoft  \Exchange  \Messenger  \Profiles  \http://<IM domain name>/instmsg/aliases/<User Alias>\contacts

Each IM home server maintains a temporary subscriber list for its local users to send notifications to each registered subscriber if the status of a local user changes. Having the server actively send status change notifications ensures that contact lists are always up to date. Using MSN Messenger, you can display a list of users who have added you as a contact. On the Tools menu, under Which MSN Messenger Service Users Have Added Me To Their Contact Lists, click View.

Understanding the Instant Messaging Architecture

The IM architecture relies on three important elements: the clients, the IM home servers, and the IM routers. Clients directly communicate via RVP/HTTP with home servers that are in the local IM domain. Between IM domains, however, an IM router is required (see Figure 8.15). You can read more about IM domains later in this lesson.

Figure 8.15 - The hierarchy of IM clients, home servers, and routers

IM home servers and routers have the following purposes:

IM home server Hosts the IM accounts of users and maintains their status information. Up to 10,000 online users can be placed on a single IM home server. The home server communicates directly with IM clients via RVP. An IM domain must contain at least one home server.
Router servers Route instant messages between domains to the home servers of IM recipients and redirect internal IM users to their home servers. IM routers do not maintain any user accounts and assume a role in the IM domain similar to FE servers in an FE/BE configuration. IM routers are especially important when exchanging instant messages with Internet users through firewalls. Depending on the frequency of external communication, a single IM router may be able to support between 20,000 and 50,000 users.

Note

Microsoft recommends creating IM home servers and IM routers on different physical machines.

Instant Messaging, Exchange 2000 Server, and Internet Information Services

IM is integrated with Windows 2000 Server and IIS, but does not require any Exchange 2000 Server services on the local computer. You only need to install Exchange 2000 on at least one server in your organization to prepare the Active Directory forest. IM is based on an Internet Server Application Programming Interface (ISAPI)-based dynamic-link library (DLL) called MSIMSRV.DLL. This DLL is registered for the WWW Publishing Service in the IIS metabase, and runs as part of the IIS process (INETINFO.EXE), as shown in Figure 8.16.

Figure 8.16 - IM and IIS 5.0

MSIMSRV.DLL implements the server application layer that communicates with other server-side IM components, as well as the Active Directory service and IM clients. Communication with Active Directory takes place when the IM server examines user account information to determine the user’s home server. MSIMSRV.DLL also maintains the IM node database, in which home servers hold user status information, contact subscriptions, and client IP addresses of active IM connections. The remaining server components are the firewall topology module (FTM) and the locator service. FTM provides IP-related data about IM servers that are located in the area protected by a firewall. The locator is used to dispatch notifications via IM routers.

Configuring Instant Messaging in a Single Domain

IM is easy to comprehend in a single-domain scenario (see Figure 8.17). The IM router is on the top of the IM domain and implements the domain’s name- space, such as im.adventure-works.com. All users with an account on a home server in this environment are assigned this domain name, such as Toby.Nixon@im.adventure-works.com. First, you should create the IM router and then the IM home servers.

Figure 8.17 - IM in a single domain

To configure IM in a single organization, you need to do the following:

Install Instant Messaging on all servers that you want to use for IM.
Create one or more IM routers and assign them a common fully qualified domain name (FQDN), which establishes the IM domain’s namespace.
Create one or more IM home servers. Assign each home server a unique domain name.
Configure your DNS zone and add an A resource record for the FQDN assigned to your IM routers, which is the name of your IM domain. If you have installed multiple IM routers in a load-balancing cluster, specify the cluster’s IP address in the A record.
Verify that all workstations can resolve the domain name of each IM home server into its corresponding IP address.
Optionally, configure a service (SRV) resource record to provide your users with a unified SMTP/IM domain name.
Enable your users with Instant Messaging using the Exchange Tasks Wizard in the Active Directory Users and Computers console.

Creating Instant Messaging Routers and Home Servers

To create an IM router, launch the Exchange System Manager snap-in and expand the administrative group where the server on which Instant Messaging is installed resides. Expand the server object and its Protocols container, and then select the Instant Messaging (RVP) object. Right-click this object, point to New, and then select Instant Messaging Virtual Server to invoke the New Instant Messaging Virtual Server Wizard. Provide a display name and select the desired HTTP virtual server (every IM server requires a separate virtual server). Then, on the Domain Name wizard screen, overwrite the default domain name obtained from the server’s IP configuration. If you plan to implement a load-balanced cluster of multiple IM routers, assign all router servers the same namespace. On the Instant Messaging Home Server wizard screen, make sure you do not select the Allow This Server To Host User Accounts check box, and then complete the New Instant Messaging Virtual Server Wizard.

As IM routers are not supposed to maintain IM user accounts, you need to install at least one IM home server to host the IM user accounts, which should not reside on the same computer, if possible. The configuration is similar to the IM router, with two important differences: You need to specify a unique domain name for each home server and select the Allow This Server To Host User Accounts check box. A unique domain name is necessary to distinguish the home servers from each other, because in a particular IM domain, a user can have an account on only one home server. The New Instant Messaging Virtual Server Wizard suggests a server name, which is a perfect choice.

Note

Whatever domain names you specify, make sure that all systems in your network can resolve these names into their corresponding IP addresses. Depending on the situation, this may require you to add A records to your DNS zone.

Logging On to Instant Messaging

It is important to note that in an Instant Messaging environment with multiple servers, the IM home server is not the clients’ primary point of contact. It is actually the IM router, referenced by means of its IP address in the DNS A record for the IM domain name, that is contacted first (see Figure 8.18). The router determines the user’s home server via Active Directory and returns this information to the client. The client directly connects to the home server.

Figure 8.18 - Logging on to Instant Messaging and sending messages

Users log on to Instant Messaging as follows:

The user logs on as username@<IM domain name>, such as Toby.Nixon@im.adventure-works.com. Because the domain name points to the IP address of the IM router, the client connects to the router server.
The IM router determines the user’s IM home server and returns a corresponding referral to the client.
The client connects directly to the user’s IM home server.
The IM server validates the user and updates the status information in its IM node database.

Sending Instant Messages Within the IM Domain

The process of sending an instant message to another user within the domain is similar to the process of logging on to the home server. Figure 8.18 shows an example of this procedure. Julia.Moseley@im.adventure-works.com sends a message to Stuart.Munson@im.adventure-works.com. Her client contacts the IM router first (5), which returns Stuart’s home server (6). Correspondingly, Julia’s client disconnects from the IM router and connects to VAC-02-IMH (7), which is the IM home server of Stuart. At this point, the client sends the message and VAC-02-IMH forwards it to Stuart’s client (8). The client displays the message on Stuart’s screen and Stuart can reply right away, which is a typical reaction in an instantaneous conversation: "How about lunch in 5 minutes, Stuart?" "OK, J. - CU in a sec, S."

It is important to note that Stuart’s client does not need to contact the IM router to reply to Julia’s message. Sessions exist between his client and his IM home server and this server knows how to reach Julia’s client. In technical language, Stuart’s home server knows Julia’s IM URL address. Therefore, the home server can forward the reply message to Julia directly. Likewise, Julia’s client caches URL information. If Julia sends Stuart another message after lunch, for example, her client does not need to go through the IM router anymore, but connects to his IM home server right away.

Note

If you move a user to another IM home server using the Active Directory Users and Computers console, others may be unable to communicate with this person due to incorrect URL information in their client cache. To clear the cache, users need to exit their MSN Messenger client.

Instant Messaging URL Addresses

Every IM user is assigned a unique public URL, which points to the IM domain’s router server in your IM domain. This URL has the format http://<IM domain name>/instmsg/aliases/<user alias>/ (such as http://im.adventure-works.com/instmsg/aliases/stuart.munson/ ). As previously mentioned, every IM user also owns an IM home server URL address that points to the user’s home server. This URL has the format http://<IM home server>/instmsg/local/<IM domain name>/instmsg/ aliases/<user alias>/ (such as http://VAC-01-IMR/instmsg/local/im.adventure-works.com/instmsg/aliases/stuart.munson/ ). In environments with a single IM server, home server and public URLs are the same because the IM router is also the home server.

To send you messages, IM clients and IM routers in other domains use your public URL to contact your router server. When the IM router refers an IM client to a user’s home server (points 2 and 6 in Figure 8.18), it actually returns this URL to the client, and the client can establish a direct connection.

Instant Messaging User Addresses

Although it is a real-time technology, users see Instant Messaging primarily as an e-mail service. To support a consistent address scheme, user addresses have been standardized according to the SMTP address convention: <User Name>@<IM Domain Name> (such as Stuart.Munson@im.adventure-works.com). In the background, the client uses this information to construct the public URL.

To illustrate this process, let’s take Stuart.Munson@im.adventure-works.com and construct his public URL. Take the domain name part and place it in the domain name part of the URL: http://im.adventure-works.com. Now, add /Instmsg/Aliases/, which is part of every Instant Messaging URL, and then add the user name. The result is http://im.adventure-works.com/Instmsg/Aliases/Stuart.Munson/ and this is his public URL address.

Note

When you move a user to another IM home server, the IM home server URL address changes, but the public URL remains constant and users can continue to exchange instant messages after restarting the MSN Messenger client.

Service Location Resource Records for Instant Messaging

Besides configuring an A record in DNS to reference the IM router server with the IM domain name, you can simplify the IM addressing scheme by means of an SRV resource record. SRV records allow you to map the IM domain name to the server and the TCP port on which the service is provided. Using an SRV record, you can register IM services for a domain, allowing IM user addresses to be consistent with SMTP e-mail addresses (see Figure 8.19). Your users can then specify IM user addresses in the form of <user alias>@adventure-works.com instead of <user alias>@im.adventure-works.com.

Figure 8.19 - An example of an SRV record for the IM domain adventure-works.com

As shown in Figure 8.19, the symbolic name for IM is _rvp, the transport protocol is _tcp, and im.adventure-works.com is the server providing IM services for the adventure-works.com domain. The two zeroes following SRV represent priority and weight, which can be used for load balancing between multiple servers. The TCP port number follows. It is set to 80 for Instant Messaging over HTTP.

Note

To support SRV record lookups on computers running Windows 98 or earlier versions or Windows NT 4.0, install the Microsoft Active Directory client. The Active Directory client for Windows 95 and Windows 98 is on the Windows 2000 product CD. The Active Directory client for Windows NT 4.0 is included in Windows NT 4.0 Service Pack 7. You also need to install Windows Sockets (WinSock) 2.0 and Internet Explorer 5.0 to use Instant Messaging.

IM Communication Across Forest Boundaries

Direct communication with another user’s home server works as long as direct network connectivity is available via HTTP/RVP. Based on the user’s IM address, your client can construct the destination’s public URL, contact the referenced IM router, and send instant messages. This works even if both users reside in different IM domains. However, this mechanism does not work if firewalls and HTTP proxies prevent direct communication. Firewall topologies are discussed in detail in Chapter 9, "Implementing Security for Hosted Services."

Firewalls and HTTP Proxies

In environments that have firewalls or HTTP proxies, such as Microsoft Internet Security and Acceleration Server, clients and destination home servers cannot exchange instant messages directly. To allow them to communicate, you need to actively involve the IM router to relay the communication. You can accomplish this via RVP firewall topology settings. After the installation of Instant Messaging in your organization, in the console tree of the Exchange System Manager snap-in, under Global Settings, there is an Instant Messaging Settings object. Right-click this object, select Properties, and then click the Firewall Topology tab. Select This Network Is Protected By A Firewall and then click Add to define the IP address ranges that are within the local network of the IM router. You can also specify a proxy server for outbound requests. Remember to register the IM domain name of your organization in your external DNS zone.

If the firewall topology indicates that an IM user is outside the protected firewall (that is, the user communicates with the IM router through a firewall), the IM router does not redirect the client to the destination home server. Instead, the client must send its instant messages directly to the router and the router relays the messages on behalf of the client to the correct IM home server (see Figure 8.20).

Responses follow a slightly different path. The IM home server is in the protected network of the IM router, knows the public URL of the originating user from the previous conversation, and correspondingly connects to the originating user’s IM router directly or via an HTTP proxy. This is similar to accessing a Web site on the Internet, and it also applies if a user within the protected network wants to send persons in another organization instant messages, because again, the public URL of the recipient is used.

Note

Do not place an HTTP proxy between an IM client and its IM home server. If you are using a Web proxy in your network, exclude the IM URLs in the proxy setting of Internet Explorer (Do Not Use Proxy Server For Addresses Beginning With).

Figure 8.20 - IM through firewalls and proxies

Instant Messaging Authentication

To participate in Instant Messaging, log on to your home server using your Windows 2000 user account and password. Within the internal network, the IM client logs you on implicitly and does not prompt you for user information unless there is a problem (for example, your user account is not enabled with IM). This very secure method of authenticating users is enabled by default.

Users who need to work with IM clients over firewalls or HTTP proxies might not be able to log on using integrated Windows authentication. The good news is that you can support them via digest authentication over HTTP. Digest authentication is an Internet standard that transmits password information in the form of encrypted hash values to the server. For your IM servers’ InstMsg virtual directories, digest authentication is enabled by default, but you also need to allow reversible password encryption in Windows 2000 Server to support this form of authentication. This can be accomplished via the Store Password Using Reversible Encryption For All Users In The Domain setting in a Group Policy that applies to your users. You can find this option under Computer Configuration/Windows Settings/Security Settings/Account Policies/Password Policy. For more information about Group Policies, see the Windows 2000 product documentation.

Designing an IM Environment

To accurately design an IM environment, your project team must have a thorough understanding of the existing Active Directory infrastructure. Among other things, IM domains cannot span multiple Active Directory forests, which forces you to outline separate IM domains if your organization did not consolidate all resources in a single forest. Recall that each forest must have at least one Exchange 2000 server. If this is not feasible, consider a central deployment of Instant Messaging similar to the strategies for Exchange 2000 organizations discussed in Chapter 3, "Assessing the Current Network Environment."

Table 8.7 lists important questions you need to address when designing IM domains.

Table 8.7 Important Design Questions for IM Domains

Issue	Comments
Do you need to take multiple Active Directory forests into consideration?	Organizations with more than one Active Directory forest must configure separate IM domains, each representing an independent Instant Messaging installation, or create a single IM domain in a central forest, which requires the creation of an additional user account for each IM user.
Does your Exchange 2000 organization span multiple SMTP domains?	In general, you should strive to keep the IM environment of your users as simple as possible, which includes simplifying and matching the IM user address to the user’s primary SMTP address by means of SRV DNS records. If this is not desired or possible, consider providing an intui- tive IM domain name, such as im.adventure-works.com.
Do you wish to unify the SMTP and IM domain namespaces in an organization that uses legacy clients, such as Windows 98 or Windows NT Workstation 4.0?	Computers running Windows 2000 support SRV records by default, but Windows 95, Windows 98, and Windows NT 4.0 require the Active Directory client. Other- wise, those users cannot use the unified domain name to exchange instant messages and must use the full IM user address, such as im.adventure-works.com.
Do you need to support users who work with multiple workstations?	The MSN Messenger client stores contact subscriptions in the HKEY_CURRENT_USER key, which is part of the user profile. By configuring server-based profiles, you can easily support roaming users in your organization.
Do you want to customize MSN Messenger?	If your company would like to create a company-specific MSN Messenger client, use IEAK 5.5 to customize the client installation files. You can deploy MSN Messenger separately from Internet Explorer.
How many users do you need to enable with Instant Messaging, and where in the network are these users?	The number of users and their location in the network determines the number of IM home servers and IM routers you need to install. Microsoft recommends an IM home server for every 10,000 IM users and an IM router for every 20,000 to 50,000 IM users. This gives you plenty of room to support very large organizations using a small number of IM servers. However, to achieve acceptable system response times, consider deploying IM routers and home servers in each Windows 2000 site of your network.
How important is Instant Messaging for the business of your company?	Instant Messaging, as available in Exchange 2000 Server, might not be considered a critical communication service. However, organizations can use it to extend the capabilities of workgroup applications, in which case it might evolve into a business-critical technology. You can implement multiple IM routers in a load-balancing cluster to increase fault tolerance.
Do you need to communicate with external organizations over firewalls or proxies?	To support communication with external IM domains over public networks, specify internal IP address ranges to cause the IM router to proxy incoming connections to IM home servers instead of redirecting the clients directly. Do not forget to include the name of your IM domain in your external DNS zones.
Do your users connect to their IM home servers over a public network, such as the Internet?	Users who want to participate in IM might not be able to log on using integrated Windows authentication, in which case you may want to enable support for digest authentication, as explained earlier in this lesson.
Do you need to encrypt the IM communication?	Currently, you cannot encrypt the IM communication between IM servers or IM clients using SSL or TLS. This might be a security problem if you expect your users to exchange sensitive or confidential information in instanta- neous conversations over public network connections. To provide the required security, consider encapsulating the data using a virtual private network based on Internet Protocol Security (IPSec) or Point-to-Point Tunneling Protocol (PPTP). VPNs, IPSec, and PPTP are discussed in Chapter 9, "Implementing Security for Hosted Services."

Designing an Instant Messaging Environment for Adventure Works

Adventure Works, a fictitious travel agency, was introduced in Chapter 3. The company is headquartered in Vancouver, Canada, with subsidiaries in the United States, South Africa, and Australia. Adventure Works has fully upgraded its messaging environment to Exchange 2000 Server. To provide a modern work environment, the company is considering an implementation of Instant Messaging worldwide. "We intend to deploy Instant Messaging to give our office workers a fast and convenient communication channel in addition to e-mail messaging. We are very excited about this technology. It would allow our travel agencies to use instant messages to quickly verify late-breaking news from any of our geographical locations," says John Y. Chen, Senior IT Administrator at Adventure Works. The current messaging environment of Adventure Works is displayed in Figure 8.21.

Figure 8.21 - The Exchange 2000 organization of Adventure Works

Chen designed the following Instant Messaging infrastructure for Adventure Works:

Adventure Works operates a single Active Directory forest with multiple domains, but our users have different SMTP addresses. For this reason, we will install multiple IM routers and assign them appropriate IM domain names. In Canada and the United States, the SMTP domain name is adventure-works.com; so we will assign the users in North America the IM domain name im.adventure-works.com. Our South African employees have the SMTP namespace adventure-works.co.za, so we will use im.adventure-works.co.za for IM. Applying the same convention to our users in Australia, their IM domain name will be im.adventure-works.com.au.
Adventure Works should install a dedicated IM router server in each geographical location: VAC-01-IMR, JHB-01-IMR, and MLB-01-IMR. To achieve fault tolerance, we will create three HTTP virtual servers that use different IP addresses on each of these machines and create an IM router instance for each IM domain on every one of these servers. VAC-01-IMR, JHB-01-IMR, and MLB-01-IMR will run three IM router instances each—one for each IM domain—and the IP addresses of all of these IM routers must be registered in A host records for their IM domain names. DNS should be configured so that the IP address of the router closest to the client is always returned in IM domain name lookups.
The number of users in our environment is sufficiently small and the wide area network (WAN) connections are fast and reliable. Therefore, we do not need more than a single IM home server per geographical location. We will install the IM home servers directly on the Exchange 2000 servers SEA-01-EX, VAC-01-EX, JHB-01-EX, and MLB-01-EX.
To simplify the user environment, we should configure SRV DNS records and register the SMTP domain name for Instant Messaging as well, so that users can log on to their home servers using their e-mail address information. Because several of our users are still on Windows 98 or Windows NT 4.0, we need to develop a strategy to deploy the Active Directory client on all of our legacy workstations.
We will prepare a shared network installation point for the MSN Messenger client and customize the installation files to implement our own logo and company name in the user interface.
The users of Adventure Works do not need to communicate with users in external organizations. There is no need to register the internal IM domains in our external DNS zones or specify ranges of protected IP addresses. Our users can communicate directly with each other without the need for Web proxies. Sites that use HTTP proxies for browsing the Internet will need to update the configuration of Internet Explorer to register the IM URLs as internal resources that don’t require proxy communication. Digest authentication or encryption of instant messages is not a requirement.

Activity: Designing an Instant Messaging Environment

In this activity, you will design an Instant Messaging environment for Proseware, Inc., a fictitious ASP introduced earlier in this chapter.

Tip

You can use Figure B.24 in Appendix B as a guideline to accomplish this activity.

Scenario: Proseware, Inc.

Proseware, Inc. has deployed an involved messaging organization based on Exchange 2000 Server to support more than 350,000 OWA users in a single hosted environment. The company has installed numerous FE servers, which relay HTTP-based communication to the BE servers in the internal network. The communication between OWA clients and FE servers is encrypted using SSL. FE servers and internal systems, such as internal DNS servers, DCs, GCs, and BE machines, communicate exclusively over IPSec tunnels, which allow secure communication with internal systems without TCP port restrictions (see Figure 8.22). You can read more about IPSec in Chapter 9, "Implementing Security for Hosted Services."

Proseware, Inc. wants to provide its users with the ability to exchange instant messages with each other and with other organizations.

Figure 8.22 - The hosted Exchange 2000 organization of Proseware, Inc.

It is your task to design an Instant Messaging environment for Proseware, Inc.:

How many IM domains should Proseware implement in its hosted environment?
How many IM router servers should Proseware install at a minimum, considering that the ASP’s customers will send instant messages frequently?
How many IM home servers should Proseware install and where should they reside?
To provide an adequate level of security for users, which feature should Proseware enable for all InstMsg virtual directories?
Which IP address ranges should Proseware identify as protected by their firewalls to support communication with other IM domains?

Lesson Summary

IM is a client/server technology that allows you to communicate in real-time with other users and exchange presence information. Both clients and servers are actively involved in the communication process. When a user logs on to the Instant Messaging service, the client contacts the IM domain’s router server, which redirects the client to the correct home server—if the client is in a network segment in which direct communication with home servers is supported. The client connects to the user’s home server. Correspondingly, the server updates the user’s status information in its IM node database and sends a notification to all other users who have registered an interest in this information (that is, those who have added the user as a contact in their IM clients). Those users are then able to send the user instant messages.

IM domains include two different types of IM servers: routers and home servers. The IM router establishes the namespace of the IM domain. The IM home server maintains accounts enabled with Instant Messaging. To simplify the environment for users, you may want to add an SRV record to your DNS zone to allow all users to log on using their e-mail address information.

It is important to note that the client directly connects to a recipient’s home server to send this user an instant message. This might not always be possible, especially if firewalls or proxy servers exist in the communication path. To account for firewall topologies, you need to identify all those IP address ranges protected by a firewall in the global Instant Messaging settings within the Exchange System Manager snap-in. Providing information about your firewall topology and proxy servers enables your internal users to communicate with users in other organizations over the Internet, for example.