************************************************************************************
APPMETER V1.1 README	April 25, 1994
************************************************************************************

This document contains information that is not covered in the AppMeter manual:

*	Information on version 1.1 of AppMeter, including instructions on registering 
application suites with AppMeter

*	Information on Windows Module Editor, a set of utilities included on the AppMeter 
disk that let you centralize the configuration of Windows clients who will be using
applications registered through AppMeter. These utilities let you avoid traveling to 
individual workstations as you set up AppMeter.

*	Hints on configuring DOS and OS/2 clients who will be using applications registered 
through AppMeter

*	Version information for IPX and VIPX files contained in the NOVELL subdirectory

*	A description of the AMLOGDIR program, which lets you change the Log File directory 
after you've installed AppMeter.

*	A description of the %M command line switch. This switch is useful for metering
certain Windows programs, including 1-2-3 for Windows, WordPerfect for Windows, and 
Micrografx Designer.

*	A description of the %R command line switch. This switch is useful for metering 
programs whose initial executables reside in each user's personal directory, such as 
Windows itself (as opposed to applications that run under Windows).

*	Version information for OS/2 clients

*	Information on running applications registered through AppMeter
from Windows for Workgroups v3.11.


New Features in AppMeter 1.1

*	AppMeter can now meter application suites such as Microsoft Office and Lotus SmartSuite.
*	AppMeter  can meter DOS and Windows applications running under OS/2 version 2.x.  
*	You can now use AppMeter with the new VLM DOS Client.

Windows Module Editor for AppMeter

Windows Module Editor is a set of utilities that lets you configure Windows clients who will 
be using applications registered with AppMeter from a central machine. 

Windows Module Editor comprises:

*	Windows Initialization (.INI) Module Editor, to permit global editing of WIN.INI files
*	Windows Group (.GRP) Module Editor, to permit global editing of group files

Below is a description of how to install and use Windows Module Editor.

Installing Windows Module Editor

Perform the following steps once you've installed AppMeter.

1.	Connect to the root directory of the file server that's running the AppMeter NLM.

2.	Create a subdirectory under \PUBLIC\APPMETER to hold the Windows Module Editor 
utilities:

	MD SYS:\PUBLIC\APPMETER\WME 

3.	Copy the Windows Module Editor files from the AppMeter disk into the WME subdirectory. 
For example, if A:\ is your 3-1/2" disk drive, and you've installed AppMeter in 
J:\PUBLIC\APPMETER, you can use the following command to copy the files:

	Copy A:\WME\*.* J:\PUBLIC\APPMETER\WME

Using Windows Module Editor

Windows Initialization (.INI) Module Editor

AppMeter requires that the background task AMWIN.EXE be loaded during a Windows session in 
order to give the user access to metered Windows applications.  In order for this task to 
start up automatically, it must be included in the LOAD= line in each user's WIN.INI file.

The Windows Initialization (.INI) Module Editor lets you globally add AMWIN.EXE to each user's 
WIN.INI file.  For example, to insert AMWIN.EXE at the beginning of each user's LOAD= line, 
simply add the following command line to your System Login Script within Novell v2.x and 3.x:
 
#SYS:\PUBLIC\APPMETER\WME\WIM WIN.INI WINDOWS LOAD= AMWIN.EXE -I -Q

In this example, WINDOWS specifies the section of the WIN.INI file, and LOAD= specifies which 
line in WIN.INI to alter.  AMWIN.EXE is the text to be inserted and -I tells WIM to insert it 
at the beginning of the line.  Finally, -Q tells WIM not to output any text.  This way, the 
user will not see the processing take place when he or she logs in.

The example above assumes that you have a standard location for .INI files, and would therefore
need only one WIM line in your System Login Script pointing to the proper location of users' 
WIN.INI files.

Important Note:
On many networks, there is no standard location for WIN.INI files. If this is the case on your 
network, you simply need to add as many WIM lines to your System Login Script as there are 
possible locations for users' WIN.INI files. Adding extra lines to account for all 
possibilities will not cause any adverse effects on your network; if WIM doesn't find a 
WIN.INI file on a particular path, it simply moves on without doing anything.

For example, some users may have WIN.INI in their personal directory on the network, some may 
have it in a directory called Windows on their hard drive, still others may have it in a 
directory called WIN31 on their hard drive.  To account for all three situations, add the 
following lines to your System Login Script: 

#SYS:\PUBLIC\APPMETER\WME\WIM F:\USERS\%LOGIN_NAME\WIN.INI WINDOWS LOAD= AMWIN.EXE -I -Q
#SYS:\PUBLIC\APPMETER\WME\WIM C:\WINDOWS\WIN.INI WINDOWS LOAD= AMWIN.EXE -I -Q
#SYS:\PUBLIC\APPMETER\WME\WIM C:\WIN31\WIN.INI WINDOWS LOAD= AMWIN.EXE -I -Q

This example assumes that F: is the network drive which contains the home directory of the user.
It also assumes that the names of the users' home directories are the same as the users' names.

Windows Group (.GRP) Module Editor

When you set up AppMeter, you must change each user's Command Line (in Program Item Properties 
window) to include the path name of the stub file. (In unmetered applications, this field 
typically contains the entire path of the executable.) You must make this change for every 
application the user is running.
 
The Windows Group (.GRP) Module Editor lets you make this change globally.  For example, 
suppose you meter Microsoft Excel on your network.  If you used Excel's Setup program to 
install your new users, their Command Lines will include the complete path to EXCEL.EXE.  
To change this so every user's Command Line points to the stub file, add the following command 
line to the System Login Script within Novell v2.x and 3.x.

#SYS:\PUBLIC\APPMETER\WME\WGM C:\WINDOWS\EXCEL.GRP -P EXCEL EXCEL.EXE -Q

The -P option tells WGM to replace the contents of the Command Line field in the Excel icon 
with only EXCEL.EXE. This lets Windows search the path and find the stub file.  Again, -Q 
specifies quiet mode so that users logging in will not see messages from WGM.

The example above assumes that every user on the network keeps his or her applications in 
Windows directories that are similarly named. As in the WIM examples in the previous section, if 
Windows directory names vary on your network, you can use multiple WGM lines in your 
System Login Script to account for different names. Since users can easily move an icon from 
one group to another, you can also use wildcards to search through all the groups in a given 
directory to find the appropriate Command Line to change.  For example:

#SYS:\PUBLIC\APPMETER\WME\WGM C:\WINDOWS\*.GRP -P EXCEL EXCEL.EXE -Q

Configuring DOS Clients

If you have set up batch or menu files to make it easy for users to launch applications, you 
need to make sure that the line within the batch or menu file that executes the application 
points to the stub file. 

For example, if, prior to installing AppMeter, you've used the following .BAT file to launch 
WordPerfect:

J:
CD\APPS\WP51
WP.EXE
C:\

Once AppMeter is in use, you should edit the line that launches the application as follows:
J:

CD\APPS\WP51
Z:\PUBLIC\APPMETER\WP.EXE
C:\

Similarly, if the menu or .BAT file resides in a user's personal directory and launches an 
application by specifying the full path to it, specify the full path of the stub file instead.

Configuring OS/2 Clients

AppMeter requires that AMWIN.EXE be loaded in order to give an OS/2 client access to metered 
Windows applications. The examples included in the first section of this document that detail 
how to globally modify WIN.INI files pertain to WINOS2.INI as well. 

About Suite Metering

It is a common practice for software publishers to sell several applications as a bundled 
package. If the bundle includes a separate license for each application, you can simply 
register each individual application with AppMeter, just as if you had purchased the 
applications separately.However, if the applications in the bundle share a single "suite" 
license, you should use AppMeter's suite metering capability to manage access to the 
applications in the suite.

Suite Licenses

A typical concurrent-use suite license provides that, at any given time, the number of users 
using any item in the suite may not exceed the number of suite licenses purchased. This implies:

*	A user takes up exactly one suite license while using one or more applications in the 
suite. Regardless of whether the user is using one, several, or all applications in the suite, 
that user is taking up one suite license.

*	If two users are using applications in the suite, they take up two licenses, even if 
the applications are different.

Overview of Suite Metering with AppMeter

To meter a suite with AppMeter:

1.	Separately register the individual applications that make up the suite, using the 
Register Application command.

	You should set Maximum Concurrent Users for each application to the number of individual
licenses you own for that application. If you do not own any individual licenses for the 
application, set this value to 0. (You will be able to enter the number of suite licenses 
later in the suite registration dialog.)

	You should set Enforce Maximum? to Yes. If you want to permit overflow usage, it is 
better for reporting purposes to turn enforcement off for the suite but leave it on for the 
component applications; otherwise, usage will always be granted for the application, and no 
suite usage will ever be logged.

2.	Now register the suite, using the Register Application Suite command.

	Select the Component Applications that belong to the suite. You will be able to select 
from a list of all registered applications that are not already members of another suite.
 
	Set Maximum Concurrent Users for the suite to the number of suite licenses you own.

	The Register Application Suite command is explained in detail in the next section of
this document.

Dealing with a Mix of Application and Suite Licenses

Often you will have individual application licenses for the same applications that you also 
have covered by suite licenses. For example, you may have:

*	10 licenses for Microsoft Office suite (includes Excel, Word, PowerPoint, Access and 
Mail)

*	20 additional licenses for Excel

*	40 additional licenses for Word.

Since Excel and Word are included in the Microsoft Office suite, you can have, potentially, 
30 uses of Excel and 50 uses of Word.

You should set this up as follows:

1.	Register each of the component applications, setting Maximum Concurrent Users to the 
number of separate application licenses you own for that application. Thus:

	Application	Maximum Concurrent Users
	Excel			20
	Word			40
	PowerPoint		0
	Access			0
	Mail			0

2.	Now register the suite MSOffice. Select the above five applications as components of 
the suite, and set the suite's Maximum Concurrent Users to 10.

AppMeter will always try to acquire an application license for a user before acquiring a 
suite license. This is because suite licenses are "expensive" compared to licenses for 
individual applications. Use of an application license limits other people's ability to use 
just that application, but use of a suite license limits other people's ability to use any 
of the applications in the suite.

Registering Suites

The Register Application Suite command on the main menu displays a list of all suites that 
you've registered for metering.  You can add new suites to this list, modify the settings 
for suites you've already registered, or remove (de-register) application suites if you 
no longer want to meter them.

To register a new application suite for metering:

1.	Select Register Application Suite from the main menu.  A list of all registered 
applications will be displayed (initially this list will be empty).

2.	Press [Ins].  This will bring up the Register Application Suite dialog.

3.	Fill out all the fields in the dialog, then press [Esc] to save the registration 
settings for the new metered application.

To modify the settings for an application suite you've already registered:

1.	Select Register Application Suite from the main menu to bring up the list of 
registered suites.

2.	Highlight the suite you'd like to modify and press [Enter].  This will bring up the 
Register Application Suite dialog.

3.	Make whatever changes you'd like to the dialog settings, then press [Esc] to save 
the new registration settings for the suite.  If you change your mind, press [F7] to restore 
the former settings.

To de-register one or more metered suites:

1.	Select Register Application Suite from the main menu to bring up the list of 
registered application suites.

2.	Highlight the suite you'd like to de-register and press [Del].  To de-register 
more than one suite at a time, tag them with [F5], then press [Del].

The Register Application Suite Dialog

The Register Application Suite dialog allows you to view and edit all the registration 
settings for an application suite.

Suite Name

The Suite Name is used to represent suites in the list of Registered Application Suites and 
in reports.  Unlike application names, suite names are not used to create stub files.

To enter a Suite Name, highlight the field, type in a name, and press [Enter]. Note that 
you may not assign a Suite Name that is identical to the name of a registered application 
or another suite.

Description

The Description is some piece of text that identifies the suite.  You can enter whatever 
you wish for a description, or you can leave the field blank.  The Description is a 
convenience but otherwise has no function in AppMeter's operation.

To enter or edit the Description, either:

*	type in a new description, or

*	press [Enter] to edit the current description.

Component Applications

When you register an application suite, you must add the appropriate metered applications to 
that suite.  To add applications to the suite, highlight the Component Applications field 
and press [Ins].  AppMeter will display a list of all applications registered on the current 
server.  Tag all applications to be added with [F5] and then press [Enter].  To cancel 
your changes, press [F7].

Note that an application must already be registered before it can be added to a suite.  An 
application can only belong to one suite.

Other Settings

The remaining settings on the Register Application Suite dialog operate in the same manner as 
the settings on the Register Application dialog.  Refer to pp. 40-41 of the AppMeter 
manual for more information on defining these settings.

How AppMeter Negotiates Requests for Licenses

When a user launches a metered application, AppMeter uses the following set of rules to 
determine if the user receives an application license or a suite license.  AppMeter proceeds 
through these rules until it can grant a license.  If it can't grant a license, AppMeter will 
return the appropriate error message.

1.	AppMeter checks to see if the user is already using the application.  If so, it 
increments the instance count of the application without incrementing the license count.

2.	AppMeter checks to see if the user is already using a suite which contains the 
application.  If so, it increments the instance count of the suite without incrementing 
the license count.

3.	AppMeter tries to grant a license to the individual application.  If successful, it 
increments the license count of the application.

4.	AppMeter tries to grant a license to the suite which contains the application.  If 
successful, it increments the suite license count.

The NOVELL subdirectory

The NOVELL subdirectory of the AppMeter diskette contains recent versions of VIPX.386 and IPX. 
If your versions are earlier you should install these new ones:

	VIPX.386	version 1.11
	IPX.OBJ		version 3.10
	IPXODI.COM	version 2.10
	LSL.COM		version 2.01

Changing the Log File directory

The Log File directory is the directory to which the Enforcer writes daily log files. The Log 
File directory is selected during installation, and defaults to SYS:SYSTEM\APPMETER.
If you'd like to switch to a different Log File directory, you can use the AMLOGDIR.EXE 
utility to do so. 

Follow these steps:

1.	The Enforcer should not be active when you run AMLOGDIR. Pick a time when metered 
applications are not in use. If the Enforcer is active, you must unload it.

	To unload the Enforcer, type the following at the server console:

		UNLOAD  APPMETER.NLM   		(NetWare/386)
			or
		AMUNLOAD   			(NetWare/286)

2.	Log in as SUPERVISOR or equivalent on any workstation, and type the following from the 
DOS command prompt:

		AMLOGDIR   

	From AMLOGDIR, you will be able to select a new directory for log files.

3.	Once back in DOS, copy the log files from the original Log File directory to the new 
Log File directory, using a command such as:

		COPY  olddir\AM*.LOG  newdir   

	where "olddir" and "newdir" are the original and new drive and directories for log 
files. You may then delete the log files from the original directory.

4.	You may now re-load the Enforcer.

The %M (Monitor) Command Line switch (Windows)

Certain Windows programs pose the following problem for AppMeter: The main executable is just 
a "loader"; it loads the real application, then exits. AppMeter thinks that usage of the 
application has ended once the loader is done; such applications will seem to be in use for 
just a few seconds at a time.

1-2-3 for Windows is an example. The executable that you run is called 123W.EXE. It, however, 
runs MAIN123W.EXE and exits. MAIN123W.EXE contains the actual program code and continues to 
run while the user runs 1-2-3.

You can inform AppMeter of this situation by including a %M (or %m) switch in the Command Line 
field when you register the application. The %M switch tells AppMeter to monitor an additional 
module to determine whether an application is still in use. For example, your Command Line for 
1-2-3 for Windows might be as follows:

	123W.EXE  %mMAIN123W.EXE

This tells AppMeter to run 123W.EXE but consider the application in use as long as either 
123W.EXE or MAIN123W.EXE are active.

You can have no more than one %M switch on a Command Line.

Windows applications for which %M is necessary include:

	Application			Command Line
	WordPerfect for Windows		WPWIN.EXE  %mWPWINFIL.EXE
	WordPerfect 6.0 Windows		WPWIN.EXE  %mWPWIN60.EXE
	WordPerfect Office for Windows	WPOFF.EXE  %mWPOFFIL.EXE
	1-2-3 for Windows		123W.EXE  %mMAIN123W.EXE
	Freelance for Windows		FLW.EXE  %mFLWMAIN.EXE
	Micrografx Charisma		CHARISMA  %mCHARISMA.BIN
	Micrografx Designer		DESIGNER.EXE  %mDESIGNER.BIN
	Micrografx Draw			DRAW.EXE  %mDRAW.BIN
	ccMail for Windows		CCMAIL.EXE  %mWMAIL.EXE
	Lotus Notes			NOTES.EXE  %m_LNOTES.EXE
	PageMaker 5.0			PM5.EXE  %mPM5APP.EXE
	PageMaker 5.0 Table Editor	TE.EXE  %mTEAPP.EXE
	PowerPoint 4.0			POWERPNT.EXE  %mPOWERPNT.DLL

The %R (Run) Command Line switch (DOS and Windows)

The %R (or %r) switch in the Command Line field of the registration dialog allows you to 
specify a different executable to run than the first file listed in the Command Line.

Normally, the filename that appears at the beginning of the Command Line is the one that 
AppMeter runs when the user invokes the application. This very same file is the file that 
AppMeter protects by revoking user rights to it, granting those rights only when the user 
invokes the application.

The %R switch allows you to specify a different executable to run than to protect. For example:

	FILE1  %rFILE2.EXE

tells AppMeter that it must revoke rights to FILE1; when the user invokes the application it 
must: (1) grant rights to FILE1, and (2) run FILE2.EXE.

One of the uses of this feature is to allow you to meter applications that primarily reside in 
a shared server directory, but are run from executables that reside in each user's personal 
directory. 

For example, suppose you are trying to meter Windows itself (as opposed to applications that 
run under Windows). While the Windows software resides in a shared directory on the server, 
the WIN.COM program which the user runs resides in the user's personal directory (either on 
the server or on the user's hard disk). 

This poses a problem for AppMeter: Since there are multiple copies (one per user) of the 
executable, AppMeter cannot meter the application in the usual way.

The %R switch provides a solution. Suppose you set up an application called WINGO, with a 
directory pointing to the shared Windows "System" directory, and with a command line such 
as the following:

	GDI.EXE  %rWIN.COM

GDI.EXE is a file necessary for Windows to run; AppMeter will make it invisible to users by 
revoking rights to it. When a user types WINGO, AppMeter will grant rights to GDI.EXE 
(to enable Windows to run), and then will execute the %R argument, WIN.COM. Provided it is 
in the current directory or on the path, WIN.COM will be invoked from the user's personal 
directory.

Note that this example uses an alias (WINGO) rather than the actual application name (WIN). 
The reason for this is to insure that the stub (WINGO.COM), not WIN.COM, will be invoked, 
even if the user's current directory is the one containing WIN.COM. If it can be insured that 
the user will never start Windows from his or her personal Windows directory, then you can 
avoid aliasing and simply call the application WIN.

Version Information for OS/2 Clients

In order to work with AppMeter, OS/2 clients need to be running version 2.01 of the OS/2
Requester, with the update kit that became available on 11/5/93. To download this kit from 
CompuServe:

GO NOVFILES
7. Client Kits
2. OS/2 Client Kit
2. Netware Client Kit-OS/2 Fixes

This kit only works with the newest NETWARE.DRV which can be found in Novell's WINUP9 in the 
NOVFILES library.

Information on Running Applications Registered through AppMeter from Windows for 
Workgroups v3.11.

If you are running the standard configuration of WFW 3.11, you will have problems 
running metered applications. This is due to software errors in a WFW driver 
(NWLINK.386) that interfaces to IPX. The problem can be cured by substituting a Novell 
driver (VIPX.386) for the standard WFW driver. To do this, perform the following:

1.	Run WFW's Network Setup utility.
2.	Select the DRIVERS button.
3.	Highlight the IPX/SPX driver that is currently installed on the workstation.
4.	Choose REMOVE and then YES.
5.	Choose ADD ADAPTER.
6.	In the list of adapters, select the IPX SUPPORT DRIVER (MONOLITHIC) WITH NETBIOS 
	TRANSPORT.
7.	Select CLOSE.
8.	Select OK.  At this point, you may need to insert diskettes.  It will also need 
	VIPX.386 from Windows 3.1.
9.	Once all files have been copied, select RESTART COMPUTER.

The result of this procedure will be to remove NWLINK.386, install VIPX.386, and modify 
other .INI variables appropriately. You will now be able to run metered applications from 
WFW 3.11.

Using Novell's ODINSUP.COM with WFW 3.11

A small number of users may have installed ODINSUP.COM from Novell to enable NDIS 2 
protocols to operate. Microsoft article Q107648 describes how to do this. If you have 
installed ODINSUP.COM, you should first perform the steps described above to install 
VIPX.386, then follow the instructions in article Q107648 (this article can be found on
CompuServe: GO MSWRKGRP, Library 1, download WFW.EXE). 


										AM-RMF.1


