Purging Remote Names Table 'Remotely'...

From: Rob Jones (robjones_at_lightspeedsystems.com)
Date: 03/30/04 

Date: Tue, 30 Mar 2004 10:59:54 -0800

I have an ASPNET server application that allows a remote intranet
client (using IE) to change Tcp/Ip settings on the server machine.
The app brings up a server-side form that is designed to closely
resemble the standard Tcp/Ip properties dialogs. When the remote user
completes the changes, a Finish button is clicked, which causes the
server to execute code that impliments the changes (new IP, new DNS,
etc). In the server code that performs all this magic, I have code
that forces the client's browser to display a 'Waiting' web page for
30 seconds, after which it will try to re-connect to the server. This
all works fine if the server's new IP address is known to the server
application before the change is made, as in when the user provides
the desired new IP address. However, if the user wants to change the
settings to use DHCP, I have no way of knowing what the new Ip address
will be, and consequently I can't provide a way for the client to
re-connect after the 30-second time period has elapsed. So, what I
thought I would do in this situation is have the client redirect using
the machine name instead of an Ip address, like:

     http://machine_name/setup/default.aspx

The problem with this approach is that it appears that the client
machine usually has the remote computer's original Ip address stored
in the netbios remote names table, and it is associated with the old
Ip address. After the server has been reconfigured to use DHCP, I
cannot have the client redirect using the machine's name as it is
associated with the original (wrong) Ip address.

My question is this: For this scenario, is there anything I can do on
the server machine to force the client to reload his remote names
table. I've discovered that if the client simply runs NBTSTAT -R from
a cmd prompt, his table gets reloaded with the new DHCP-based IP
address of the server, and the re-connect works. This has been my
short-term solution - to tell the client (via text on the waiting
page) that he should issue the NBTSTAT -R command before the timeout
expires if he wishes to successfully re-connect. However, I can't
help but think that there must be some code I can write on the server
that tells the client to reload this name table. I've tried rebooting
the server after DHCP has completed his work, but even that doesn't
tell the client about the new Ip address for the server!

Any thoughts / ideas would be greatly appreciated.

Rob Jones