Management of floating license can be tedious if we must control what user is allowed to run what application. We use instead a "usage-based" license management model, where we generate montly reports of user-installed applications, based on which we can ensure that we have enough licenses. This document describes the appsreport_update and appsreport_send scripts that implement the generation of such reports.

License restrictions are best ensured by policy: we say to an institute that they have 10 licenses for AutoCAD and they must themselves ensure that no more than that are used. For this to work, information on who is using what application is needed. This is implemented by the appsreport_update and appsreport_send scripts.

appsreport_update scans the user's registry for applications that were installed and stores information about what user has installed what application in file (C:\ISG\appsreport\appsreport.db) using the Storable module. Each (user, application) pair has a counter that is incremented each time the appsreport_update scripts finds that the user uses that application. This counter can then be used to find out that for example a user had a certain application installed for more that half of the month.

This script is run on our principal server (where the user profiles reside) on a daily basis at 3:00 AM with the Scheduler service:

Start ->
  Settings ->
    Control Panel ->
      Scheduled Tasks ->
        Add Scheduled Task

Since the scheduler must run local scripts, small wrapper batch scripts are used to start the scripts. For appsreport_update we noted that if we started perl in the batch script, the script would fail because of permission problems. This was solved by executing a bash script (!), which itself executed perl. This is very ugly... If someone knows how to solve it in a better way, please tell.

C:\ISG\appsreport\appsreport.bat:

bash //isgtc/isgtc/tools/win32/appsreport/appsreport_update.sh

//isgtc/isgtc/tools/win32/appsreport/appsreport_update.sh:

//C/Perl/bin/perl //isgtc/isgtc/tools/win32/appsreport/appsreport_update.pl

The user registry is read by first loading the ntuser.dat file in the HKEY_LOCAL_MACHINE registry hive as TMP_username. The information on what application is installed resides under Software/Microsoft/Installed/Products of the user's registry tree.

Since the Windows-homes and the romaing profiles of the Windows users are stored on a Unix SAMBA share and are physically located in a subdirectory of the user's Unix home directory (~/.win_prof), we developed registry-collector. This tool deposits the registry hives in a directory structure in the target directory as it is expected by the Windows version appsreport_update.pl /{username}/profile/ntuser.dat So we can run appsreport_update.pl as usual after building the directory structure with registry-collector.

appsreport_update_unix does the same as appsreport_update.pl does but it is runnable on a Linux platform. It uses the same config. Don't use appsreport_update_unix on big-endian architectures like e.g. SPARC because chntpw tool required by the does not produce meaningful results.

appsreport_send does read the database produced by appsreport_update, move the file to C:\ISG\appsreport\old (with "dash-date" appended) and does send e-mails using Mail::Sendmail. One big report with all users is sent to w2k-admin@ee.ethz.ch (configurable in the script) and one mail per OU is sent to the "contact address" listed in the OU configuration file. A report looks as follows:

From: w2k-admin@ee.ethz.ch To: w2k-admin@ee.ethz.ch Subject: [appsreport] March 2001 (isg.ee)

Windows 2000 Application Report for isg.ee (2001-03-01 - 2001-03-31)
--------------------------------------------------------------------

  1 acrobat-4.05c-to
    (oetiker)
  1 colormailer-3.0.110-to
    (thaler)
  1 emacs-20.7-mo
    (luki)
  3 netscape-4.75-to
    (luki, testacc, dws)
  1 photoshop-6.0-mo
    (luki)
  1 quicktime-5.0-mo
    (luki)
  1 realplayer-8.0-to
    (luki)
  1 vim-5.7-ds
    (dws)
  2 vnc-3.3.3r7-mo
    (luki, testacc)

agpsreport_send is also run by a batch script using the Scheduler service. It is run on the first of each month at 2:30 AM (before appsreport_update).