1
I originally posted this in serverfault.com but was deemed off-topic so I'm posting this on here...
I'm currently experiencing an issue relating to shared drives between Windows 7 and Windows XP machines in our business and I seem to be at a loss as to why it's occurring... Let me provide a brief explanation of the network configuration and the issue I am trying to deal with;
In one environment in the business we have a number of users, each with a Windows 7 machine (PC1) and a Windows XP machine (PC2). PC1 has a persistent network drive connection to PC2 and this drive is used to allow other customer-facing Windows 7 machines to circumnavigate the concurrent connection limit of Windows XP and transfer files to PC2 by pushing their files to PC1 through series of bespoke programs. Currently we are getting about 15-20 users a week complaining that the shared drive is becoming disconnected and it is impacting their work.
There are some scenarios that we have already identified that would cause PC1 to drop the network drive connection (i.e. if the user locks their AD account on PC1 (PC2 is on a Workgroup), if the user reboots either computer or if they log out of PC1) but we are still getting calls about this problem unrelated to any of the scenarios mentioned previously.
The drive is initially mapped through a batch file in an EXE wrapper which runs at Startup and follows the below logic;
- Clear all network drive shares
- Check for flag file in C:\Windows\System32 (sometimes there can be two Win XP machines to map to; the flag is used to differentiate)
- Use
net use [devicename] [sharename] /persistent:yes
to create the connection.
After investigating reasons for why the drive may become disconnected, I stumbled upon this Microsoft article which describes the "autodisconnect" registry key that can de-activate a shared drive after a period of time. Using net config server
to interrogate these values on the two computers yielded the following data;
PC1
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\WINDOWS\system32>net config server
Server Name \\PC1
Server Comment
Software version Windows 7 Professional
Server is active on
//details removed
Server hidden No
Maximum Logged On Users 20
Maximum open files per session 16384
Idle session time (min) 15
The command completed successfully.
PC2
C:\Documents and Settings\PC2_User>net config server
Server Name \\PC2
Server Comment
Software version Windows 2002
Server is active on
//details removed
Server hidden No
Maximum Logged On Users 10
Maximum open files per session 16384
Idle session time (min) 15
The command completed successfully.
Both computers have a default setting on the Idle session time, but the drive connection is persistent so this shouldn't affect it... right?
Additionally, when the user calls in to report this issue, I use RDP to connect to PC1 and what I have noticed is that when you click on the drive share in Windows Explorer, a Username/Password prompt appears advising that the user account details are wrong but I know that this is not the case. The user account details are supplied by the mapping program and the AD account used to do this is not locked - furthermore, if you re-run the mapping program then the share maps correctly.
Event logs on PC1 yield next to no information relating to this (at least as far as I can see) so I'm kind of stuck here - speaking to other people in the business, their advice has been to just write a program to check the drive connection periodically but I need to know what is causing this, if not for anything but my sanity!
My first question is this - Could the idle session timeout be the root cause? And more to the point, does the idle session time rule still apply if a shared drive connection is persistent? I cannot find an answer (or even a question of this kind) anywhere and my Google searches have turned up empty.
Secondly, are mapped drive details logged in the Event Logs at all? If I could see what was happening at the time of disconnection then this would greatly improve the chances of me fixing this issue.
Failing both of those, any suggestions, support or a reason why this is occurring would be greatly appreciated :P
Do the clocks (time and date) on all the computers match? – Ƭᴇcʜιᴇ007 – 2016-03-17T12:59:54.100
@Ƭᴇcʜιᴇ007, yes they do. PC1 has it's time synchronised by the DC, PC2 has it's time synchronising via NTP (as far as I am aware) and the other Win7 devices get their time by querying a Tomcat Server running on PC1. Would time mismatching cause such a problem? – Fredulom – 2016-03-17T13:13:48.690