Troubleshooting and logging RAS Connections

In old saying in corporate-management circles states, "If you can't measure it, you can't manage it." In the world of Windows NT RAS management, a more appropriate version of this saying is, "If you can't log it, you can't manage it." If RAS's default monitoring and troubleshooting tools don't offer helpful information, you can employ several tricks to improve the level of information that RAS provides and facilitate its overall manageability.

One of the lessons that NT administrators learn after working with RAS for a while is that the default tools for monitoring and troubleshooting RAS connections provide a fairly anemic level of diagnostic information. As in any network-troubleshooting situation, the first step in identifying and resolving RAS connection problems is to examine the information at hand. Check the event logs on the RAS client and server. If you discover an error message in the event logs or the system prompts you with an error-message dialog box, look up the error message to determine its possible causes. The Microsoft article "Remote Access Service (RAS) Error Code List" (http://support.microsoft.com/support/kb/articles/q163/1/11.asp) provides a comprehensive list of RAS-related error messages, their meanings, and their possible causes. Even if the text of an error message seems obvious, I recommend that you check this article and perform a comprehensive search for all Microsoft articles that relate to situations involving your error message. Performing a search is helpful because some RAS error messages are misleading and might throw you off the trail to discovering a problem's true source.

The NT event logs and RAS client-side error messages sometimes provide decent clues, but in many cases these resources don't provide enough information to help you identify a problem's source. If these resources don't provide you with enough information to resolve a problem, the next step is to enable RAS logging.

Log files are often very helpful when you're troubleshooting. However, NT's default logging level for RAS doesn't provide much useful information. To glean more information from RAS about what's going wrong on a connection, you need to modify the Registry to force RAS to log connections. Most RAS connections, including connections to ISPs and Windows 2000 (Win2K) or NT 4.0 RAS servers, use Point-to-Point Protocol (PPP). A RAS subcomponent called the RAS PPP Engine (i.e., raspppen.dll) establishes PPP connections. This subcomponent also logs the conversations that take place between a PPP client and server on a connection. To enable logging on an NT RAS server or client, run a Registry editor and locate the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesRasManPPP key. You can set the following options for the Logging REG_DWORD value: 0 for No Logging (Disabled), 1 for Regular Logging, and 2 for Verbose/Detailed Logging. You must reboot the system for changes to take effect. When you enable the Regular Logging or Verbose/Detailed Logging options, RAS will create a log file named ppp.log, which you can find in the %systemroot%system32ras folder. If you attempt to make the problematic RAS connection with PPP logging enabled, you can examine the contents of ppp.log to see where the problem is in the PPP negotiation process. This information is especially useful when you're troubleshooting problems with ISP connections because most ISPs have technical support staff who understand PPP and its various stages of negotiation.

An even better troubleshooting strategy is to gain a good understanding of PPP. The collection of Request for Comments (RFCs) that define PPP (i.e., 1661, 1549, 1334, and 1332) is a great resource (http://www.rfc-editor.org). You can also find several good FAQs online that describe PPP.

This column's discussion relates only to RAS connections and not to RRAS. Next time, I'll continue my troubleshooting discussion and explain how to enable logging with RRAS and individual dial-up adapters.