C
Chris957
Guest
I have kind of a strange one. I've seen several of forums similar but not exact to the issue i'm having. let me give you a little background on the issue.
Original Setup: 3 Windows XP Pro computers and 1 Win 7 Pro 64 bit in a small office. one of the XP pro computers was setup as a file share host where the others all mapped to it. there was an application that was installed on that computer that was run from the file share. all other hosts had mapped a drive to the file share computer and ran the application through the file share. all computers could access the program on the file share fine and there was no problems.
Network layout: 1 network using DHCP, nothing fancy. DHCP handed out by ISP router. all hosts had a NAT address. No connectivity problems.
New setup: the business wanted to move to a system that had some drive redundancy (raid1). they weren't ready to go to a server based on cost so they ended up with a high performance client computer (dell optiplex 990) with a Raid 1 drive setup. This computer became the new file share. it was Windows 7 64 bit system . All the patches were applied to it. The old file share computer was taken off the network and the new computers was given the same name as the old file share server which was just "server". hosts are mapped to the share by the computer name hosting the share. ie z= \\server\data\
Problem: the problem was noticed several hours later in the first day when the XP computers started loosing the map drive. So at this point there are 2 windows xp pro and 2 win 7 64 bit systems. while the xp computers lost the map drive, the window 7 host did not. it in fact the win7 computer never lost the map drive even till this day. I have determined its not a network issue because the xp computers can ping the "server" (with no dropped packets) even when the drive map is lost. Let me describe the "lost drive map" a bit.
Lost Drive map scenario: the xp system which looses the drive map from the win 7 file share computer, can be rebooted and when it comes back, there is no difference. it still cannot connect. It can see the server and the other computers on the network but it is denied access to the file shares on the win 7 host. If you reboot the win 7 file share server, then the win xp hosts start to work. so this tells me that the issue is possibly on the windows 7 file share computer.
I have taken these steps so far.
1) static ip on the win 7 file share server. all other hosts are still dhcp
2) added a entry to each xp computer with server details
3) turned off IP v6 on all computers. only protocol is IP v4 in the while office
4) disabled firewall on win7 file share and xp hosts
5) removed antivirus on on win7 file share and xp hosts. didn't see any difference so i put it back on.
6) changed the file shares to allow everyone and even added the ID for the local users of the XP pro system to the file share. none of the users of the file share are being prompted for login anymore since the file share (win 7 computer) has the ID local.
7) rebooted the network. i never saw any network issues or dropped packets between any hosts
8) all windows 7 and xp computers have all the windows patches to date.
I see in the error log these couple errors repeated many time.
Error 1:
event ID: 2017
event source: srv
locale ID: 1033
The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.
As a result of this event ID: I found a website listing a similar problem and solution. I have implemented this fix on the Windows 7 file server and am waiting to see if the issue occurs again.
http://www.computer-how-to-guide.com/windows-software/event-id-2017-2021/
Error 2:
Event ID: 7001
Event source: Service control manager
locale ID: 1033
The NTRU TSS v1.2.1.36 TCS service depends on the TPM Base Services service which failed to start because of the following error:
The operation completed successfully.
Error 3:
Event ID: 10010
Event source: Microsoft-Windows-distributedCOM
Local ID: 1033
The server {E10F6C3A-F1AE-4ADC-AA9D-2FE65525666E} did not register with DCOM within the required timeout.
So to summarize:
Win 7 64 client talking to win 7 64 file share server - works great, never looses connectivity to file shares
Window XP pro talking to win7 64 file share server - looses connectivity randomly to win 7 file shares. to restore connectivity, a reboot of win
7 computer hosting file shares.
I've seen the forum topics regarding disabling autodisconnect. this is my next step to try. i just wanted to run this issue by the forum group
here to see if anyone has any thoughts.
Continue reading...
Original Setup: 3 Windows XP Pro computers and 1 Win 7 Pro 64 bit in a small office. one of the XP pro computers was setup as a file share host where the others all mapped to it. there was an application that was installed on that computer that was run from the file share. all other hosts had mapped a drive to the file share computer and ran the application through the file share. all computers could access the program on the file share fine and there was no problems.
Network layout: 1 network using DHCP, nothing fancy. DHCP handed out by ISP router. all hosts had a NAT address. No connectivity problems.
New setup: the business wanted to move to a system that had some drive redundancy (raid1). they weren't ready to go to a server based on cost so they ended up with a high performance client computer (dell optiplex 990) with a Raid 1 drive setup. This computer became the new file share. it was Windows 7 64 bit system . All the patches were applied to it. The old file share computer was taken off the network and the new computers was given the same name as the old file share server which was just "server". hosts are mapped to the share by the computer name hosting the share. ie z= \\server\data\
Problem: the problem was noticed several hours later in the first day when the XP computers started loosing the map drive. So at this point there are 2 windows xp pro and 2 win 7 64 bit systems. while the xp computers lost the map drive, the window 7 host did not. it in fact the win7 computer never lost the map drive even till this day. I have determined its not a network issue because the xp computers can ping the "server" (with no dropped packets) even when the drive map is lost. Let me describe the "lost drive map" a bit.
Lost Drive map scenario: the xp system which looses the drive map from the win 7 file share computer, can be rebooted and when it comes back, there is no difference. it still cannot connect. It can see the server and the other computers on the network but it is denied access to the file shares on the win 7 host. If you reboot the win 7 file share server, then the win xp hosts start to work. so this tells me that the issue is possibly on the windows 7 file share computer.
I have taken these steps so far.
1) static ip on the win 7 file share server. all other hosts are still dhcp
2) added a entry to each xp computer with server details
3) turned off IP v6 on all computers. only protocol is IP v4 in the while office
4) disabled firewall on win7 file share and xp hosts
5) removed antivirus on on win7 file share and xp hosts. didn't see any difference so i put it back on.
6) changed the file shares to allow everyone and even added the ID for the local users of the XP pro system to the file share. none of the users of the file share are being prompted for login anymore since the file share (win 7 computer) has the ID local.
7) rebooted the network. i never saw any network issues or dropped packets between any hosts
8) all windows 7 and xp computers have all the windows patches to date.
I see in the error log these couple errors repeated many time.
Error 1:
event ID: 2017
event source: srv
locale ID: 1033
The server was unable to allocate from the system nonpaged pool because the server reached the configured limit for nonpaged pool allocations.
As a result of this event ID: I found a website listing a similar problem and solution. I have implemented this fix on the Windows 7 file server and am waiting to see if the issue occurs again.
http://www.computer-how-to-guide.com/windows-software/event-id-2017-2021/
Error 2:
Event ID: 7001
Event source: Service control manager
locale ID: 1033
The NTRU TSS v1.2.1.36 TCS service depends on the TPM Base Services service which failed to start because of the following error:
The operation completed successfully.
Error 3:
Event ID: 10010
Event source: Microsoft-Windows-distributedCOM
Local ID: 1033
The server {E10F6C3A-F1AE-4ADC-AA9D-2FE65525666E} did not register with DCOM within the required timeout.
So to summarize:
Win 7 64 client talking to win 7 64 file share server - works great, never looses connectivity to file shares
Window XP pro talking to win7 64 file share server - looses connectivity randomly to win 7 file shares. to restore connectivity, a reboot of win
7 computer hosting file shares.
I've seen the forum topics regarding disabling autodisconnect. this is my next step to try. i just wanted to run this issue by the forum group
here to see if anyone has any thoughts.
Continue reading...