If a net session command is run, I see a mixture of XP and 7 computers connected to various shared resources. All Windows 7 computers have an IP address for their computer name and have multiple connections using both their username and computer name followed by a dollar sign ($).
Example:
\\192.168.0.100 computername$
Where \\192.168.0.100 is the "Computer" and computername$ is the "User name". The "Client Type" is emtpy, and I can see how many open files there are. If I go into the GUI, I drill down to see what files are accessed, .EXE files are "Accessed by:" computername$ while others are "Accessed by:" username.
The problem with this is that the executables stored on these shares, even though shown to be accessed by computername$ and the open mode is "READ", the file is locked and cannot be updated. This is a problem because this is VB6 code and the way the current system is setup, we roll out updates by updating the EXE in the share...this means we can push code changes live and all users need to do is restart the EXE to see the changes.
I have found that this only occurs with Windows 7 32bit computers, Windows XP computers do not do this. The only indication that I have found of this behavior is what is found in the Shared Folders GUI or net session command where the computer and user are not displaying properly, much less indicating what the client type is. I have tried shares on Windows Server 2003 Standard 32bit and Windows Server 2008 Standard 64bit. Both have the same problem.
I have trolled the web in search for a solution to this but believe I'm having trouble searching for the right "terms". I have gone through various testing cycles with this in live production and in a lab environment. I cannot seem to replicate the problem to a different network. In a certain case, I am able to open the EXE as the user and the file is truly not locked using a Windows 7 computer.