• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 116
  • Last Modified:

Finding out how many users have opened a file from read-only remote share

This question is not some project where I need help; rather it's a mystery I'm curious about.

At some point I discovered that if Microsoft Access project file (ADP) is installed on a server read-only share, and the users open it from there, it allows only 20 users to open the file. The 21st receives an error.

This seems to be impossible - if the users have read-only access, there's no way they would store on the share some information that would allow the next user to count how many have already opened it. Still, it's implemented, and Microsoft has confirmed it, however did not say how (" Our method for determining the number of users in the file is not exposed for customer/developer use, and there is no plan to make it publicly available."). I already posted about it here on e-e, see my comment at https://www.experts-exchange.com/questions/22091003/Access-Project-file-adp-with-SQL-20-user-limit.html for more details

Does anybody have a clue how this might be implemented?
0
Vadim Rapp
Asked:
Vadim Rapp
  • 7
  • 4
  • 3
  • +1
1 Solution
 
Bill BachPresidentCommented:
The operating system is clearly tracking the number of users that have files open. You can see the number of users with the file open using Server Manager. I would expect that Access is using the same calls.

One way to find out is to set up a controlled test. Use a tool like Wireshark to capture network traffic to the server from a user donn a normal open of the file. Then, capture a user failing because of the 20u limit. Pay attention to the SMB traffic in yellow for sure.

Another way would be to use Process Monitor to trap the OS calls, either on the server or on the client. (If you do this on the server, be sure to enable Advanced Output mode in ProcMon.)
0
 
QlemoC++ DeveloperCommented:
I agree counting has to occur on OS level, not file level. If Access would run with a server backend, it'll be different, but on file level there is no way to override the share/NTFS priveleges (for non-admin users).
0
 
Davis McCarnOwnerCommented:
On the host, under computer management (COMPMGMT.MSC), expand the Shared Folders entry, and highlight Sessions.  It should list all of the users currently connected.
It should; however, be cleared if you reboot the PC.
What version of Windows is the host?
0
Configuration Guide and Best Practices

Read the guide to learn how to orchestrate Data ONTAP, create application-consistent backups and enable fast recovery from NetApp storage snapshots. Version 9.5 also contains performance and scalability enhancements to meet the needs of the largest enterprise environments.

 
Vadim RappAuthor Commented:
Bill and Qlemo - yes, I think that's one way. Probably there's no point to monitor, since even if I catch something, there will be no definite answer anyways. I thought, maybe someone actually already heard about these undocumented features (probably there's much more), would be interesting.

I also thought about another possibility - maybe it could be that the file itself has some undocumented bits that instruct the server to limit the number of users opening it.

I think the first way, by undocumented API, would be a security breach possibility - a backdoor for a non-admin user to obtain admin information.

Davis, sorry , but it does not look like you understood the question.
0
 
Davis McCarnOwnerCommented:
If it is server 2008 (which I didn't notice before), the limit is the number of local CAL's installed on the server (and not RDP licenses).  This is true in AD or in a workgroup.
If it is a non-server O/S hosting the file, 20 is the limit without hacking; but, it is possible to overcome.
I understood the question perfectly.
What O/S is sharing the file and how many sessions are active?
0
 
Vadim RappAuthor Commented:
It's not necessarily server 2008, it's any server - 2000, 2003, 2008, any. In the same share there may be an executable, and opening that executable remotely 100 times is no problem. I just tried it on windows 10, not even a server - successfully opened an executable 30 times, then opened the access file 21 times - and 21st has failed.

There's no need to look for alternative explanations, since as you saw, Microsoft has confirmed (in a tech support incident I opened for that) that they are indeed using unpublished way to find out how many users have opened the file - in fact, not even the "users" but "how many times" - I was opening the file by myself, with the same result.
0
 
Bill BachPresidentCommented:
Back to your original question: How?

Can you get a trace via ProcMon or Wireshark of both a successful and a failing open attempt? If so, and if you can post the trace data, we may be able to answer this question.
0
 
Vadim RappAuthor Commented:
OK, here's procmon trace - of the opening #20 (success) and of #21 (failure). Since I was opening it from my own computer, you can see both client's part and server part. The process was msaccess.exe, and it was opening file \\vadim\theshare\adp1.ade, which is local directory c:\users\dima\desktop\theshare

Rename .txt to .rar.
theshare.txt
0
 
Vadim RappAuthor Commented:
...I should mention that during openings 1-20 , Access is trying to open the file in r/w mode, which fails (because the share is read-only), then it shows a warning and opens it as read-only, which is OK (in fact, being read-only is even better for this particular application, due to certain issues in Access). With #21, it shows message "The file is not in correct format" and does not open it.
0
 
QlemoC++ DeveloperCommented:
If you have that file local, try if you can open it with a local path as #21.
0
 
Vadim RappAuthor Commented:
When local, it opens without problem any number of times.

By the way: "If it is server 2008 (which I didn't notice before), the limit is the number of local CAL's installed on the server (and not RDP licenses). " - if I'm not mistaken, the CAL's are never installed anywhere at all, and windows server has no idea how many you have have.
0
 
QlemoC++ DeveloperCommented:
Well, that is works locally no matter how many others have opened it, it cannot be an Access "feature".
0
 
Bill BachPresidentCommented:
In the Success trace, you can clearly see the user count being implemented.  If you add a filter on ProcMon to monitor ONLY the ADP1.ADE file, you'll see a series of LockFile attempts, first at offset 2,147,483,539, then 540, 541, 542, etc.  You said that this was the 19th user, and you can clearly see the 18 failures and success on #19.

The Magic development environment uses the exact same locking mechanism thing to determine the current user account.  It simply starts trying to lock at varying offsets until it finds an open slot.  When the open slot is found, the resulting lock becomes the user access ID number for that session.  If the user access ID is greater than the purchased user account, the process fails with a licensing error.

This solution works nicely because the OS lock is automatically cleared by the OS on a restart or failure, and you don't need to actually modify the file or even have rights to it.  

I was intrigued by the attempt to lock (and unlock) a 20-byte range at 579 immediately before this process -- making me wonder if it cannot be altered by modifying the EXE?  However, the subsequent locks (558, 578, 598, 618, 538) come on even 20-byte boundaries, almost like there are OTHER flags used as well.  Because of this, I am betting that this is a hard limit for some reason.
0
 
Vadim RappAuthor Commented:
Great Bill - so as I understand, it takes the size of the file, divides it by the number of users it wants to allow, then sends the locks for sequential positions until the next one fails, which means that the number is exceeded. Right?

I wonder what would happen if one of the workstations that already reserved the lock, is hard-reset. The lock would probably stay?
0
 
Bill BachPresidentCommented:
The lock would stay, but only for a short time. That's the beauty of OS locks.  If the file is closed, the locks are dropped immediately.  If the server OS hard-faults and restarts, all locks are cleared and things start over anew.  If a client OS hard-faults, then the connection watchdog will eventually clean it up.  

By default, the watchdog for TCP connections is 2 hours, but I did a quick lookup, and it appears that there is a default SMB watchdog process that cleans up after 15 minutes of inactivity.  So, a user PC failing might show as "in use" for 15 minutes, but it should clear automatically after that time period.
0
 
Vadim RappAuthor Commented:
Brilliant!
0

Featured Post

Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

  • 7
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now