XCON: Troubleshooting Dynamic RAS Connector (TCP/IP)

This document provides troubleshooting suggestions for the Exchange Server Dynamic RAS Connector that is configured to use TCP/IP. It can help you isolate any misconfiguration issues or breakdowns in the functionality of the underlying components needed by the connector.

Most reported problems with the Dynamic RAS Connector end up being either a basic configuration issue, a failure in RAS connectivity, or an underlying problem with network functionality over RAS (especially name resolution or remote procedure call [RPC] problems).

Troubleshooting steps are presented below in four phases from the most basic to the more complex.

Most reported failed connections fall into the following type of symptoms. The local modem dials and connects to the remote modem. Some data is exchanged but then the modem hangs up. This pattern is repeated over and over. No e-mail is sent. Troubleshooting these types of issues is covered in Phases 2 and 3.

Preliminary Notes

• Exchange Server computers connecting through the Dynamic RAS Connector should not have LAN connectivity to each other, as this confuses name resolution. If a prior LAN connection was established, the servers need to be rebooted to flush any cached connectivity information.
• Windows NT and Exchange Server should also be at the latest service pack levels.
• To successfully connect two Exchange Server computers together dynamically through RAS, both servers must have the TCP/IP protocol installed and must be properly configured.

Phase 1 - Initial Troubleshooting

1. Walk through the step by step "Dynamic RAS Connector" white paper found at the following location, and double-check everything in the order it is listed. Look for missed steps, typographical errors, and so on.
   http://support.microsoft.com/kb/148286
2. Remotely access the other server directly using either the Dial-up Networking or RAS clients. In other words, if Exchange Server is not even in the picture, is there basic RAS functionality?
   
   If not, you need to review your RAS and Windows NT configuration. If the modem is dialing but having trouble connecting to the other modem, you may want to turn up Point-to-Point Protocol (PPP) logging. You can enable the Ppp.log file by setting the following registry entry to a value of 1: WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
   
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan \PPP\Logging
3. Check the RemoteListen parameter setting under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\NetbiosGateway.
   
   It should be set to 2. A value of 0 or 1 indicates that something unusual such as removing and reinstalling the RAS server has taken place after the Exchange Server RAS Message Transport Agent (MTA) Transport stack was added. You can try just resetting the value to 2, but given the unknowns in this situation, you may need to remove and reinstall the Exchange Server RAS Connector and the RAS MTA Transport stack as well.
4. If you attempt to send a message but quickly get a non-delivery report (NDR) without the server even attempting to dial, you likely have an addressing problem on the local server. Double-check the exact spelling of all fields in your custom recipient and on the connector's Connected Sites tab (also verify any addresses on the Address Space tab if they exist).
5. If your server does connect to the other server but you get an NDR, you need to carefully read the NDR to determine if it originated from your server or the other server.
   
   If it came from the other server, the specific recipient you are sending to may not exist on the other server or there may be a spelling or typographical error on your custom recipient entry.
   
   If it came from your own server, it may be a result of too many failed connection attempts or deleting the message from the queue through the Exchange Server Administrator program. If so, just queue up a new test message.

Phase 2 - Troubleshooting Network Functionality over RAS

1. Connect from Server1 to Server2 using the same phone book entry the RAS Connector uses.
   
   Be sure to use the same account and password used on the RAS Override page to connect.
   
   NOTE: If you first log on to both servers as the RASCON account, you do not have to specify the security context in step 4. You can also use the Run with Security option while testing RPC in step 8.
   
   To log on as RASCON, you may first have to give the account permissions to log on locally in User Manager for Domains. To do so, on the Policies menu, click User Rights, and make the appropriate changes.
2. Note the IP addresses Server2 supplied to Server1 for use during the connection.
   
   If Server2 (the one receiving the call and assigning the IP addresses from its static pool), only has one modem and has only two addresses in its pool, the IP address assigned to Server1 for this connection is the second address in Server2's pool. If Server2 has more than one modem or more than two addresses in its pool, you need to verify the address assigned.
   
   Windows NT 4.0
   From Server1 (the server which dialed the phone), double-click the Dial-Up Network Monitor icon on the right side (or bottom) of the taskbar. After the Dial-Up Networking Monitor is displayed, click the Details button from either the Status or Summary tabs. The IP address displayed is the one Server2 (the dialed server) assigned to Server1 (the dialing server) from its static IP address pool for this connection.
   
   Windows NT 3.51
   From Server1 (the server which dialed the phone), bring up the Remote Access client and click the Status button on the top right. The IP address displayed near the bottom of the Port Status window is the one Server2 (the dialed server) assigned to Server1 (the dialing server) from its static IP address pool for this connection.
3. Ping IP addresses in both directions over the RAS connection.
   1. From Server1 (the server which dialed the phone), ping the first IP address in Server2's Pool.
   2. From Server1, ping Server2's Network Card IP address.
   3. From Server1, ping Server2 by its server name.
   4. From Server2, ping the IP address assigned to Server1 for this connection (from Server2's pool).
   Pinging Server1's Network Card IP or host name does not work from the RAS server to client.
   
   From our three-server example (see the step-by-step Dynamic RAS Connector checklist), if Seattle called Portland, you would perform the following pings: From Seattle
   
   
   • ping 172.16.0.0
   • ping 192.168.0.0
   • ping PORTLAND
   
   From Portland
   
   
   • ping 172.16.0.2
4. Perform a net use command from Server1 to connect to IPC on Server2. This establishes the proper security context to the other server's domain:
   net use \\server2\ipc$ /user:domain2\rascon password
   In our three-server example, if Seattle (Server1) is connecting to Portland (Server2), the command issued on the Seattle server is as follows:
   net use \\portland\ipc$ /user:oregon\rascon ras
   Be sure to allow the command to finish successfully or to give a specific error message.
   
   If there is any failure at this point, carefully check your command-line syntax, server name, domain name, RAS connector account name, and password (including case). Then check the security information for the RAS connector account on the other domain.
5. Perform a net use command in the other direction (from Server2 to Server1) using the IP address that was assigned from the Server2's pool (see step 2 for details).
   
   NOTE: This only works if Server2 is using Windows NT 4.0. The Windows NT 3.51 object manager doesn't support device lookup by IP address. If Server2 is using Windows NT 3.51, skip this step.
   
   In our three-server example, if Seattle (Server1) is connecting to Portland (Server2), the command issued on the Portland server is as follows:
   net use \\172.16.0.2\ipc$ /user:washington\rascon ras
   Be sure to allow the command to compete successfully or to give a specific error message.
   
   If there is any failure at this point, carefully check your command-line syntax, IP address, domain name, RAS connector account name, and password (including case). Then check the security information for the RAS connector account on the other domain.
6. Perform a net view command from Server1 to view the shares on Server2:
   
   
   net view server2
   When Server1 initiates the RAS call, the IP addresses are supplied by Server2. Server1 should have an entry in its LMHOSTS file that allows it to resolve Server2's name to an IP address so the standard net view servername command works.
   
   In our three-server example, if Seattle (Server1) is connecting to Portland (Server2), the command issued on the Seattle server is as follows:
   net view portland
   If name resolution is working, you should see a list of the shares on the other server.
7. Perform a net view command in the other direction (from Server2 to Server1) using the IP address that was assigned from the Server2's pool (see step 2 for details).
   
   NOTE: This only works if Server2 is using Windows NT 4.0. The Windows NT 3.51 object manager doesn't support device lookup by IP address. If Server2 is using Windows NT 3.51, skip this step.
   
   Server1 is acting in the role of a RAS client and not a RAS server in this case so the LMHOSTS entry Server2 has for Server1 will not work in this situation. That entry is based on an IP address from the RAS pool on Server1, which is not used when Server1 is in the role of a client. As a result, a net view servername command will not work. However, in Windows NT 4.0, you can still test functionality by net viewing the IP address directly.
   
   In our three-server example, if Seattle (Server1) is connecting to Portland (Server2), the command issued on the Portland server is as follows:
   net view 172.16.0.2
   If name resolution is working, you should see a list of the shares on the other server.
   
   NOTE: The second net view and net use above more closely mimic what happens when the MTA over RAS attempts a Bindback (the most common potential problem area).
8. Perform RPCPing tests in both directions over the established connection. Be sure to configure the client half to use the TCP/IP Protocol Sequence. If you have logged on to both servers as the RASCON account (as suggested in step 1), you should also click to select the Run with Security check box. If your test fails with Security checked, then try again without it.
   
   
   1. Run Rpingc32.exe on Server1 and Rpings.exe on Server2, and ping Server2 by name.
   2. Run Rpings.exe on Server1 and Rpingc32.exe on Server2, and ping Server1 by IP.
   The RPC Ping client should report successful pings, or there may be a problem with RPC.
   
   In our example with Seattle connecting to Portland:
   
   
   • Seattle RPC pings Exchange Server: PORTLAND
     
     
   • Portland RPC pings Exchange Server: 172.16.0.2
   
   NOTE: RPC pinging by IP is only supported on Windows NT 4.0.
   
   RPC Ping utility documentation can be found with the utility on the Exchange Server CD.
9. Hang up the connection and then have Server2 connect to Server1 using the same phone book entry the RAS Connector is set to use.
10. Repeat steps 2 through 8 over the new connection.
    
    Problems with this phase over connections in either direction indicate underlying Windows NT problems that need to be corrected before you continue with the Exchange Server Dynamic RAS Connector configuration.

Phase 3 - Intermediate Troubleshooting

1. If no problems were uncovered in Phase 2, increase the logging on the Exchange Server MTAs on both servers for the X.400 Services and Field Engineering categories to Maximum. Then log another failed connection.
2. Check the system logs on both servers for any reported RAS errors and the application logs on both servers for any Exchange Server errors. Be sure to check the details of any Exchange Server errors for embedded Windows NT or RAS errors. The MSExchangeMTA 9311 Field Engineering event in particular often contains useful embedded RAS errors.
   
   For example, here is a 9311 from the application log:
   
   
   MSExchangeMTA Field Engineering Warning 9311
   
   A RAS communications error has occurred for gateway
   /o=MS/ou=PSS/cn=Configuration/cn=Connections/cn=DR. RAS error
   code returned: 718, RAS Table index: 0. The MTA will attempt to
   recover the RAS connection. [BASE IL PIPE RAS 35 230] (12)
   
   Notice the RAS error code embedded above. It is documented in the Rasphone.hlp Help file. To find the RAS error messages open the file, and on the Find tab, search for "Error Messages."
   
   In this case, the Help file points out that the RAS 718 error is a PPP Time-out. It further describes a 718 error as follows:
   A PPP conversation was started, but was terminated because the remote computer did not respond within an appropriate time. This can be caused by poor line quality or by a problem at the server.
   Embedded RAS codes along with the error messages in the RAS Help can be one of the more useful tools in identifying initial problems.
   
   If an Event ID 9316 is encountered, double-check the Remote Server Name field on the RAS Connector's General page (including case), and re-verify the information on the RAS Override page.
   MSExchangeMTA Interface Warning 9316
   
   An RPC communications error occurred. No data was sent over the
   RPC connection. Locality table (LTAB) index: <x>. Windows NT
   error: 9301.The MTA will attempt to recover the RPC connection.
   [BASE IL PIPE RAS xxxxx] (12)
3. Check to see that both modems are on the Hardware Compatibility List and have modem scripts that are included with Windows NT or are the most recent scripts from the modem manufacturer.
4. If the modem is a higher speed modem, try using the generic Hayes compatible 9600 script instead.

Phase 4 - Preparing to Escalate to Microsoft Product Support Services (PSS)

1. Clear the application and system logs.
2. Start a Network Monitor trace. (Note 1)
3. Send a test message (while X.400 Service and Field Engineering are still logging at Maximum).
4. Collect the following seven files (preferably zipped into one file), and contact PSS:
   • Server 1 application log
   • Server 1 system log
   • Server 2 application log
   • Server 2 system log
   • Network Monitor *.cap Trace of the RAS attempt (Note 1)
   • Admindmp.txt file for the RAS Connector object on Server 1 (Note 2)
   • Admindmp.txt file for the RAS Connector object on Server 2 (Note 2)

Note 1: If you have not used Network Monitor to capture a trace over RAS before:

1. Locate Network Monitor (this can be from Systems Management Server CDs or a dated copy direct from PSS).
2. Run the Setup program to install Network Monitor on one of the Exchange Server computers.
3. Start Network Monitor, and on the Capture menu, click Networks.
4. Select the network with the Current Address beginning with 5241 or 000000, and click OK.
5. On the Capture menu, click Start.
6. Perform a RAS connector test (you should see activity in Network Monitor at this point).
7. On the Capture menu, click Stop.
8. Save a *.cap file by clicking Save As on the File menu.

Note 2: If you have not performed an Administrator Dump on an object before: WARNING: If you use the raw mode of the Exchange Server Administrator program (admin /r) incorrectly, serious problems may occur that may require you to reinstall Microsoft Windows NT Server, Microsoft Exchange Server, or both. Microsoft cannot guarantee that problems that result from using raw mode incorrectly can be solved. Use raw mode at your own risk.

1. Start the Microsoft Exchange Server Administrator program in raw mode by typing the following at a command prompt:
   c:\exchsrvr\bin\admin /r
2. If an Admindmp.txt file already exists in the C:\Exchsrvr\Bin\ folder, delete or rename it.
3. Select the object you want to dump the raw properties from (in this case the RAS Connector object).
4. Press and hold down the CTRL key.
5. On the File menu, click Raw Properties.
6. Release the CTRL key after the raw properties are displayed.
7. Cancel out of the raw properties.
8. Rename the newly created Admindmp.txt file to match the object it was dumped from (each new dump recreates or appends to any existing Admindmp.txt file).
9. Quit raw mode.