Link to home
Start Free TrialLog in
Avatar of Tomster2
Tomster2Flag for United States of America

asked on

Peer to peer network requires "forced wakeup"

Working with a small (3 computer peer to peer network).  Whenever either of the two workstations (not the designated server) reboots, it fails to find the server mapped drives.

We can ping each way - by iP and name, renew IP addresses and other reset procedures but the we still get "connection cannot be found".

The only choices we have are:

1) wait about 1-2 hours and the mapped drives suddenly connect. or

2) Go to the server and do

START | RUN
Type in: "\\workstation1" without the quotation marks
Hit <enter>
and wait for the folders to show up.

.... then go back to the workstation machine and do
START | RUN
type in "\\server"
Hit <enter> and wait for the folders to show up.

At that point connections are OK until the next reboot/restart.

I have worked with several peer to peer networks but have not seen any that have this long delay or difficulty in finding each other.  

Any suggestions would be most welcome.
ASKER CERTIFIED SOLUTION
Avatar of DanielGoad
DanielGoad

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of Tomster2

ASKER

I setup the static IPs, and editing the hostfiles per above for each machine.  

The problem still persists, particularly with one machine that in Windows Explorer, I can go to to My Network places | Entire Network etc and I immediately see all three PCs.   I can see all three machines... but I only access the shared folders on the machine I am on and one other.   When I try expand the third machine to see the shared folders, it tells me the network cannot be found... even thought I can ping in both directions between these machines.  If I wait about an hour, the connection goes live... unless I force it per my original post.

Microsoft Firewall is off on both machines, and I disabled ZoneAlarm on both machines... and the result is the same.   This is a bugger.  Make that BUGGER!
Additional note.  This is the morning after.  Setting up the static IP and Hosts files worked like a charm on one of the machines (XP connecting to XP [peer to peer server]).  So thank you for that.

The other PC is a Windows 2K machine - and that is the one that is behaving as described in the post of 11/15.
It can see shared folders on itself and the other "workstation", but not the machine that is the peer to peer server.

Oddly, it was able to connect fine for the last two years... so something changed... but no idea what.

I would have reinstalled this machine, but the original OS cds are lost.

I am giving Daniel goad the points on this one, as he was the only reply and the solution worked for one of the machines.  Daniel... if you have any other ideas on the W2K machine, let me know.

Avatar of DanielGoad
DanielGoad

Thanks for the points - and let's try one other thing.  The hosts file in c:\windows\system32\drivers\etc is read before (and in place of) a standard DNS request to resolve the address of the other machine.  By default, Windows XP uses IP as the only network protocol.  Of course, it can use others for compatibility and will simulate older protocols over TCP/IP to achieve the same results.  The Hosts file should work if you are using IP only, but just to cover all bases, lets set up a LMHOSTS file to work with NetBios.   LMHOSTS is created much like the HOSTS file, with a few small differences: LMHOSTS is designed to translate computer NetBios names to an address - the file can effectively take the place of a WINS server on a small network with static addresses.

* Go to the c:\windows\system32\drivers\etc folder (assuming that your Windows directory is named "Windows" and located on the C: drive, if not adjust accordingly).
* If you created the HOSTS file as outlined above, then simply copy the HOSTS file to a new file named LMHOSTS.  (There may be an existing file names LMHOSTS.SAM - this is a sample of the LMHOSTS file.  Feel free to read it at your leisure, but any changes you make to it will not 'go live' unless saved in a file named LMHOSTS with no extension.
* If you don't wish to copy the HOSTS file or want to start from scratch, then open Notepad and save the blank document as C:\windows\system32\drivers\etc\lmhosts. as type "All files".  Notepad generally tries to add ".txt" to the end of a file name, so after you save the file, close notepad and look in the directory to see if it named the file LMHOSTS.txt.  If so, rename it to LMHOSTS.
* Open the LMHOSTS file in notepad.  Add or update it as follows (I am using the data from my sample above, use your specific address and computer names):
192.168.1.1    Computer1      #PRE
192.168.1.2    Computer2      #PRE
192.168.1.0    ServerName    #PRE
* The #PRE entry at the end of each line instructs Windows to pre-load this entry and to hold it the routing table's memory.
* Save the file.  Double check that the HOSTS. and LMHOSTS. file both exists and that both have the same computer names and addresses.  Copy these two files to all three machines and save in the Windows\system32\drivers\etc folder.
* Reboot the computers.
* Open a command prompt on each system and type NBTSTAT -c  <enter>.  This will list all of the computer names and addresses in the cache.  This should show all three computers (there may be multiple entries for each because of various network services on each computer) and their correct address.

One last suggestion, and possibly the reason this issue 'just started'.  Make sure that the 'Computer Browser' service is running and set to automatic start - especially on the Windows 2000 machine.  If this service was disabled or is not running, then a 'wrestling match' is constantly going on between the peer computers in the background -- each thinking they are the browse master of the network and that their list is the master list.  Ok, so I am being a little dramatic, but not by much.  This extra network traffic and negotiation can cause noticeable delays and cause a computer or the entire workgroup to 'disappear' because it is not on the current "browse master's" list.

I assume that each machine has a persistent share mapped to each of the other computers.  If not, do that - even if you don't need it.  Create a share (it can be to an empty folder if you want) on each computer - then map a drive in Windows Explorer to that share and click "Reconnect at logon".  This will create an open connection to the other systems.  Even if the share is not used, the process of opening the connection keeps the remote system and a path to it mapped in the routing table.  This should eliminate any dropped connections.

Good luck and Happy Holidays!