Mark Minasi's Tech Forum
Register Calendar Latest Topics Chat
 
 
 


Reply
  Author   Comment  
krakrs

Still Checking the Forum Out
Registered:
Posts: 1
Reply with quote  #1 
Hi everyone!  Sorry for the forth-coming length, I just want to be clear in describing my issue.

I've got two 2008 R2 file servers replicating via DFS (if that ends up mattering - DFS namespace with replication enabled).  I've got remote users connecting to our network using the built-in Windows VPN client (Win10).  When the remote users attempt to edit and save a served file - or even when creating a NEW file - they occasionally get a "file in use" error and are unable to save.  But the file isn't in use otherwise.  When I look at the file server's event log and view file WRITE events, for LOCAL users who do NOT have this issue I see what I would expect - a single Write event with their username in the details.  When I look at Write events for remote VPN users that DO have this issue, I see TWO events - one Write with their username attached as expected along with another within a few seconds with the file server itself listed as the "Account Name" (FileServerName$).  I've got local and remote people accessing the same files all the time so it's hard to be 100% sure, but I've seen enough evidence in the logs to convince me that the FileServerName$ write event does not occur when a local user accesses a file, only when it's being accessed by a remote VPN user.

So the file server appears to be performing some Write action around the same time the VPN user performs a save, and my guess is that the locking/unlocking of the file during that save is not being communicated effectively over the VPN which results in the remote user getting the "file in use" error when they try to save.  Persistence usually pays off, if they try enough times remote users can eventually save.

Is this behavior familiar to anyone?  As far as I've seen this happens with every VPN user and not at all with local users, so I'm pretty resolved to this just being "how it is" over VPNs and the culprit to blame for the saving trouble is the latency between the remote user's home and the internal file server.  I'm not sure what to do about it (if there's anything TO do).  Any thoughts or comments?  Or a link to documentation that talks about this file server Write event that takes place when a file is accessed over a VPN?  I've searched a bit but haven't found anything to explain what I'm seeing in the logs.

Thanks ~ k
0
wobble_wobble

Avatar / Picture

Associate Troublemaker Apprentice
Registered:
Posts: 808
Reply with quote  #2 
Kris

Welcome to the forum.
Not sure if I can help, but at least ask a few more questions.

1. What sort of VPN, to what Endpoint/ firewall/ server? PPTP/ L2TP, Direct Access?
2. What happens the user is they try to save/ edit a file to a standard share/ test share? Same issue?
3. Is there similar access to the DFS Shares from the VPN internal IP Range? ie. are the 2 servers on the same LAN/ location?
4. What sort of files are we talking about ?Word/ Excel/ CadCam...

Generally I would not expect to see the sort of event you are seeing, in that a VPN user cannot save a file, they should be able to.

Usual suspects are AV or in some cases, if the edits/saves on the file are "too fast or too frequent for the DFS Sync", I've seen DFS kick up. 



__________________
Have you tried turning it off and walking away? The next person can fix it!

New to the forum? Read this
0
donoli

Senior Member
Registered:
Posts: 505
Reply with quote  #3 
Have you compared the time stamps of the local users vs the remote users?  AFAIK, even if the local user opens the file one second earlier than the remote user, the remote user won't be able to write to the file until the local user closes it.  That's why the "persistence pays off".  The same should go for two local users or any combination of users.  However, there could be something that gives local users precedence. 
0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:

Easily create a Forum Website with Website Toolbox.