Restricting the Number of Users on a Shared Program

Kenn's
Tech
Notes

20001012: Restricting the Number of Users on a Shared Program

October/2000
Tech Note #12

This note has been updated! See also March/2001, Tech Note #2.

Neil B has been investigating ways to restrict user access to network-shared applications for the purpose of complying with licensing requirements. Although Windows NT has the facility for restricting access to network shares based on the number of connected users, simply sharing an application from such a share does not always work correctly, for one reason or another. Even when it does work, there are drawbacks to this approach.

However, Neil has developed a technique which works very reliably. Briefly stated, the idea is this: As above, connect to the application in an NT share which is restricted to the maximum number of users permitted by the software license. The difference is this - instead of accessing the application directly from the UNC or from a connection which is common to many systems via logon script or persistent connection, run the application from a local Kix script which first makes the connection, then runs the program, and finally deletes the network connection after you exit the program. The script can also test the connection and provide an error message when you try to access the connection when the maximum number of users has been exceeded. The beauty of this system is that users need not log off and on to access specific software shares. The Kix script ensures that the network connection is open only so long as the application is open, freeing it up for another user as soon as the current user exits the program.

The easiest way to understand this is to try Neil's example below, which uses LabPop:
a. Create a share called test$ on a server with the program file labpop.exe in it, and restrict share connections to 1 only. (Note that in order for LabPop to work properly, the NTFS permissions for the folder LabPop is stored in should be "Change" for the desired users' group(s), since LabPop wants to write a temporary file to the drive containing the LabPop files. For the purpose of testing, setting Everyone's file permissions in the shared directory to "Change" will work fine.)
b. In the file NETAPP.SCR (see below), change \\SERVER to your server name. Change Q: to whatever drive letter is not in current use on your workstations.
c. On two workstations which have Kix32 installed (any Windows 9x system that has had the WSD1 Anti-Virus Installer/Updater installed will have this), copy the TEST.BAT and NETAPP.SCR files to a directory.
d. Make a shortcut for TEST.BAT and set the icon for TEST.BAT to run minimized.
e. Run the shortcut for TEST.BAT first on one, then on the second workstation. On the second workstation, because the maximum number of users (ie. 1) has been exceeded, the error message should come up. Close LabPop on the first machine, and rerun TEST.BAT on the second. This time, LabPop should run.

Neil has tested this technique with a number of programs and has found it to be a very reliable method of sharing applications which have "number of user" licensing restrictions. The only down side to this technique is that it is not compatible with Windows 3.1x clients, since the Kixtart SHELL command cannot launch Windows applications. However, for Windows 9x and Windows NT clients, this works really slick!

Here is the TEST.BAT file:

@echo off
kix32 netapp.scr

Here is the NETAPP.SCR file:

$rcode=SETCONSOLE("HIDE") 
$style=64 
$timeout=5 
$report="" 
$cr=chr(13) 
USE Q: "\\SERVER\test$"
IF @error 
  $style=16 
  $timeout=10 
  $report="Program drive connection is unavailable.$cr" 
  if SUBSTR(@serror, 1, 11) = "An extended"
    $report=$report+"Maximum licenses reached or network problem." 
  else
    $report=$report+"@serror"
  endif
  $rcode=messagebox($report,"App Connection",$style,$timeout)  
ELSE
  SHELL "Q:\LABPOP"
  $rcode=SETCONSOLE("FOREGROUND") 
  USE Q: /DELETE
ENDIF

DISCLAIMER: This document is intended for the reference of computer support personnel within Winnipeg School Division No. 1. There is no warranty or liability if procedures recommended here have an adverse affect on any systems. Use them at your own risk. Any trademarks mentioned are the property of their owners, none of whom have certified any information provided here. Opinions expressed here are personal only and do not represent the policy of Winnipeg School Division No. 1 or any other organization anywhere.

Got a Tech Note to share? Submissions are most welcome! [Click here.]
To return to the Tech Notes home page, click here.
To download a copy of all the October/2000 Tech Notes in Rich Text Format, click here.

Click here to visit the Information "Super-Cul-De-Sac". This page was updated
2001 June 9

This page hosted by
Get your own Free Homepage
Check out my neighbours here in Silicon Valley Peaks by clicking here.