Troubleshooting Instant Messaging | Microsoft Exchange 2000 Server Adminstrator's Companion

[Previous] [Next]

Although we can't cover every possible problem that may occur with Instant Messaging in this chapter, several common scenarios are worth discussing here. We also cover how to use the logs and Network Monitor to troubleshoot a problem.

Users Can't Log On

Client logon is one of the main areas that might require troubleshooting. It will also be one of your most frustrating problems. Here are some things to check as you troubleshoot client logon problems.

First, since the user's IM profile is derived from the user's Internet Explorer profile, be sure that the FQDN of the routing and home servers as well as the Instant Messaging domain name are excluded in Internet Explorer. To accomplish this, navigate to the Connections tab of the property sheet for Internet Explorer, click the LAN Settings button, and then click the Advanced button (Figure 19-23). Enter the FQDN of the routing and home servers and the Instant Messaging domain name. If these addresses are not excluded and IE is configured to use a proxy server, the instant messaging client will be sending its logon request to the proxy server.

MORE INFO
Exclusions can be set for all users by configuring a group policy. For more information on how to create and configure group policies, see the Microsoft Windows 2000 Server Administrator's Companion, by Charlie Russel and Sharon Crawford (Microsoft Press, 2000).

Figure 19-23. Proxy settings for Internet Explorer, showing excluded addresses.

Second, be sure that, if you have a routing server, (1) there is a SRV resource record in DNS for this server, (2) the client's logon is to the DNS domain that the routing server resides in, and (3) if you are using MSN Messenger, the version is 2.1 or later. Earlier versions of MSN Messenger will not work with Exchange 2000 Instant Messaging.

Third, be sure that the client has IP connectivity and name resolution. You should be able to Ping the routing server, the home server, and the DNS server. In addition, you should be able to Ping the host name of each of these servers (Figure 1924) and receive back its FQDN along with its IP address. If you receive back only the host name and IP address, something is wrong with DNS resolution. Troubleshoot as necessary.

click to view at full size.

Figure 19-24. Pinging to check for FQDNs.

At this point, you might be wanting to reach through the pages of this book and let us know that your IM users still can't log on. If that's the case, consider the following points.

First, if you have recently deleted and then re-created your routing virtual server, you need to make sure that you allow Active Directory to replicate these changes. If you can't wait for that to happen, you can manually force replication by using Active Directory Sites and Services. Navigate to the connection object under the server object that needs to be updated, right-click the object, and choose Replicate Now. Most likely, you will need to repeat this step for each server in your domain. Also—and this must be done before you create the new routing server—you must delete the Instmsg virtual directory in the associated Web site that was created when you created the last routing server. When you create the new routing server, it will create a new Instmsg virtual directory that will cooperate with your new virtual server. And remember, since the IM does most of its lookups to the Global Catalog (GC) Server, you will need to be patient and wait for the GC to update before attempting to silent log on with the messenger client.

Second, do not use alias names in DNS for your routing server. If your routing server's host name is something other than IM, either use the host name for that server (we used Tucson in our examples) or else add a second A record that resolves the IM host name to the IP address of the server that will host the routing virtual server. But do not attempt to alias the host name of IM to your server's host name and then have the routing virtual server point to the IM host name.

Third, when you delete and then re-create a routing virtual server, the new information is not automatically updated in the user's properties. You will need to disable and then reenable IM in your users' accounts in order for them to receive the new routing server information. Again, since the messenging client does most of its lookups in the GC, you'll need to be patient to allow the GC to update as well.

Fourth, be sure your IM clients are using a password for their logons. The IM service will not accept a client logon request that contains a blanket password.

Best practice is to do the following:

Create the virtual server or servers that you think you need.

Install the instant messaging client on one machine.

Test with that user to make sure she or he can log on.

Deploy IM to a larger group of 10 or 15 and make sure it is working before you roll it out to your entire company.

The overall point here is this: any change you make in one of your virtual servers affects the virtual directory entries in IIS, the users' properties, the GC servers, Active Directory, and DNS. Make sure you have accounted for all of the "domino effects" that a change to a virtual server will cause.

Instant Messaging Client Suddenly Disappears

If the instant messaging client disappears suddenly from users' screens, it means either that the IM home server's Web site has stoppedor that the World Wide Web Publishing Service has stopped. Once the service or the Web site is restarted, users may need to log on again to establish a new connection to IM on the IM server.

Users Can Send Messages to the Internet but Cannot Receive Messages From the Internet

You might find that your users are able to send instant messages to one another and to users on the Internet but that they cannot receive messages from the Internet. In addition, if they log off and immediately try to log back on, they receive the error message shown in Figure 19-25. This problem can mean that the Web site associated with the routing server has been stopped or that the World Wide Web Publishing Service on the routings server has been stopped. Restarting the service should restore full communications.

click to view at full size.

Figure 19-25. Logon failure message.

Using the IIS Logs and Network Monitor For Troubleshooting

One of the best ways to troubleshoot an IM issue is to look at the logs that IIS generates. You can use Network Monitor along with the IIS logs to troubleshoot a logon problem. To see the location of the log files, go to the Web Site tab of the property sheet for the IM Web site (Figure 19-26), and click the Properties button within the Enable Logging area to display the logging properties (Figure 19-27).

click to view at full size.

Figure 19-26. Web Site tab for the IM Web site.

These log files are very helpful in determining the nature of an error and how to troubleshoot the problem. (Bear in mind that the timestamp in these files is always Greenwich mean time.) For instance, Figure 19-28 shows part of a log file from a test network. It indicates that users are getting some (404) responses to their SUBSCRIBE requests, meaning that the server is not being found. A corresponding packet trace in Network Monitor shows the same error message (Figure 19-29).

Figure 19-27. Logging properties, showing log file location.

click to view at full size.

Figure 19-28. IIS log containing 404 errors.

click to view at full size.

Figure 19-29. Trace log showing 404 error message.

This error is due to an incorrect SRV record in DNS, the incorrect placement of a host header name in the default Web site for the routing server, Tucson. Or it is due to incorrect information being returned from one or more Global Catalog servers that have not been fully updated with new IM virtual server information. At the client end, the logon screen was returned almost instantaneously, indicating that the client's first step—to contact DNS and get a resolution on the SRV record—did not work.

In many cases, you can use the IIS logs in conjunction with packet traces in Network Monitor to quickly diagnose a problem. Once you know what the HTTP error is, you can reference the error code and then begin the process of isolating the incorrect configuration and making the necessary changes.

MORE INFO
For a good list of the HTTP error codes, along with descriptions, please consult Dilip Naik's book Internet Standards and Protocols (Microsoft Press, 1998).