\[Editor's Note: Do you have something to share with other Windows NT Magazine readers? We want to know about it. Write for Reader to Reader online, and you can tell others about your NT discoveries, comments, problems, solutions, and experiences. Email your contributions (700 words or less) to email@example.com along with your name and phone number. We edit submissions for style, grammar, and length. If we print your submission, you'll get $100.\]
My company consists of several locations, and I help support the entire company from the corporate location. One location (Site B) is set up with 10 nodes (all running Windows 95), one server (a PDC) running Windows NT Server 4.0 with Service Pack 4 (SP4), and Microsoft Exchange Server 5.5 SP1 and DHCP running on the same server. All the nodes get their IP lease from the DHCP server. We recently decided to remove Exchange from the second server and use an ISP to provide dial-up access to all the nodes so users can receive their email from our centralized Exchange server over the Internet. After running this new configuration for a few months, my company started testing NetMeeting for our enterprise. I installed an Internet Locator Service (ILS) specifically for my company and asked everyone to log on using NetMeeting.
Shortly thereafter, I encountered a problem with Site B. I could see all the names of the nodes in the ILS directory, but when I tried to call any of them, I received an error message: "The person you are trying to reach is unable to accept the NetMeeting calls, would you like to send him a mail?" Because everyone at Site B was using the dial-up connection, I tried to simulate their configuration using a dial-up connection at my site. I called my machine over a dial-up connection from another local machine, and the process worked fine. I then asked a user at Site B to call my machine with NetMeeting using the dial-up connection, and the call worked. However, when I tried to call a user at Site B, I ran into the initial problem.
I called my ISP to help me diagnose the problem, and the ISP was able to perform a successful tracert to my ILS. Unfortunately, we were not able to rectify the problem. I turned to Microsoft for help, but none of the Microsoft Support Online articles describe the problem. I called the Microsoft Support Center, but after many attempts they could not help.
Finally, I took a fresh approach to the problem. Here are the steps I used to resolve the problem:
- I called the user at Site B on the phone and asked him to log on to the ISP's network.
- I asked him to run the command winipcfg on his PC to identify the IP address of his machine.
- When I saw his IP address, the problem was immediately clear. His machine was still using the IP address that the DHCP server assigned, not the one that the ISP provided.
- I changed Site B's complete setup, removed the NT server, created a workgroup under NetBEUI for internal network file-sharing purposes, and configured DUN on TCP/IP for ISP access.
Now everything works fine, and we can call the Site B users using NetMeeting.