Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

TCP/IP borked

Status
Not open for further replies.
Jan 23, 2004
292
0
0
US
Users unable to connect in the morning.

I could ping out from the server, but the server didn't respond to pings from any other source onm the same subnet.

Tried the WinsockFix utility which (after a reboot) restored TCP/IP functionality - for about 10 minutes.

Rebooted, and the original problem is still here. Unable to uninstall & reinstall TCP/IP as Microsoft suggests.

Any ideas?
 
Thanks Code666, for the advice. I had completely forgotten about NetDiag - that's what pressure can do.

NetDiag reports everything as having "passed" with the following exceptions:

Trust relationship test. . . . . . : Skipped
WAN configuration test . . . . . . : Skipped
No active remote access connections.
IP Security test . . . . . . . . . : Skipped
The IPSec Policy Agent service is not started.

NetDiag /fix didn't help

 
hmmm, the NIC seems to be working as you can ping from the server. when you try to ping to it from other boxes are you using the DNS name or IP address? is this a dc?
 
is this your only DC or do you have others? i guess since users were unable to connect you have ony one DC. how are you trying to unistall tcp/ip? were you logged in as the machine admin when trying to do it?
 
This is the only Windows server on the network.

Trying to uninstall TCP/IP in the "Local Area Network Properties" window. Uninstall button greyed out - even after uninstalling everything else.

Lopgged in as local Administrator (also domain administrator)
 
could you try uninstalling the NIC itself from the device manager? if memory serves when you do this and let the system reinstall tcp/ip is also reinstalled. also, have you considered setting up a second box as a DC to facilitate fault tolerance? it won't help now but in the future it could be a life saver...
 
Thanks Code666,

It was a good idea, but the problem is still here.

Next step, restore from tape.

Failing that, rebuild server - there aren't many users on this box. Besides, I've already spent nearly a day without a Windows server - I don't want to try for tweo.

Thanks again!!!
 
okay, one more thing to try. do you have an extra NIC lying around that you know is good? if so, install that one into the server and let's see what happens.
 
Already started restore from backup.

But, tried another NIC first - no difference.

Thanks for sticking with me on this.

Just in case the restore doesn't help (the way my day has been going, I won't count on anything) do you remember where (in the registry) I can find the Product Key - just in case we can't turn up the certificate of authenticity.

Thanks again Code666, I really appreciate the help!!!!!
 
try this tool:

i searched through registry and never came across the key. my guess is this is by design from MS. guess they don't want this to be visible. good luck, let me know how it turns out. this has been a strange one. now that i think about it had anything changed before this happened? like new software, updates, etc?
 
Restores take foooorevvvver!

Nothing (that I know of) has changed recently.

Working for well over two years (routine updates, added memory, user changes, new shares, etc.) This server is routinely rebooted weekly.

First clue of problem was when one user couldn't conect (via VPN) to check his schedule w/Outlook. Others tried to logon this morning - to nothing.

Whatever happened, it was between 3:00 yesterday afternoon and 7:00 this morning. Event viewer didn't give a clue.

Although it doesn't matter any more, I forgot to mention - shortly after running NetDiag /fix couldn't ping out anymore.
 
this is truly strange but then these things do happen from time to time. i guess the next place i was going to have you check was the event vwr to see if any messages were posted that might give us a clue. if the restore fixes the issue then ot least we know it was something in the software and not a hardware issue, good luck!
 
Hopefully, I won't need it, but Aida32 is (supposedly) able to pull the product id and key from the registry - along with tons of other good stuff.

At least it works on my XP Pro desktop. I don't want to install it on the server unless I have too.
 
I come to this somewhat late, so I'm not sure this will be useful, but it sounds like hardware failure if you can be sure that nothing has changed on the machine.

If you are running windows update, you could check to see if it has installed anything in the last few days that might have caused the problem. And roll back the patch if there has been one installed.

It would also be worth checking if your workstations have picked up IP addresses from a DHCP server if they are not statically configured.





 

there are some other things I would try once the machines are showing that they have IP addresses, and you are sure the the networking config is correct, is to see whether and 2 machines are correctly arping each other.

do;
ping address

and then quickly do;
arp -a

and check that an entry exists for the other machine in the arp cache.

Really you want to get ethereal or some packet logging software to see what packets are getting out, and what is coming back.






 
Thanks for the input tommyh1.

I started the restore before seeing your post, so it wasn't possible to follow your suggestions exactly.

Additional detail (for what its worth):
all desktop machines (and the servers)have static IP addresses.
this is Windows 2000 Small business server, so it can be the only Windows server in the domain.
had checked the windows updates - nothing new past few days.

AND, the good news is:
after the restore, eveerything appears to be OK!
have to admit, never used arp -a before - looks good though!

Thanks to both of you, I really appreciate it!!!!
 
well, that's good news. looks like it was something software related. the arp -a command will show you a listing of the hardware address associated to an ip address. this will reside locally in your cache for about 10 minutes or so and then is flushed. in a nutshell, when pc a needs to talk to pc b it will send out an arp request asking for the MAC(hardware) address of pc b. if pc b is on the same segment it sends a response back and then pc a can send packets directly. if pc b is on another segment, then the router responds with its address. when the router gets the packet it then arps for pc b and forwards it on to the machine. your welcome, i like trying to solve issues and was glad i could help in any way.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top