Table of contents
For a while now I’ve been working on an application called AppUserList, which I’ve written several posts about here, but I realized I never updated the guide on how to install it correctly.
So I decided it was time to spend a bit of time describing the installation process, to make it easier to deploy, and also to better define the permissions the service user needs in order to work correctly.
The purpose of AppUserList is to give administrators a clear picture of which applications users are using inside VDI or DaaS environments; having this information clear can help you understand where the machines can be optimized and which software is no longer being used (so you can uninstall it from the virtual desktops, or stop installing it later on new workstations as part of migration/upgrade projects).
As described before, the application is made up of the following components:
- AULMonitor: SQL database dedicated to storing the historical information;
- AULService: service running on the Windows VMs, dedicated to collecting the applications run by users;
- AULReport: console dedicated to analyzing the collected data and generating reports;
Below is a diagram of how the application’s flows work:
AULService is an agent running on the virtual machines that deliver Desktops and/or Applications (for example in Citrix, Parallels RAS, Azure Virtual Desktop environments, etc…), whose purpose is to monitor how users use applications and send the collected information to the AULMonitor DB.
AULMonitor is a SQL database, running on a SQL Server instance, whose job is to store the history of the data collected by the various AULAgents.
AULReport is the application that lets you view and quickly analyze the collected data, as well as export it in the various report formats provided.
Here are the prerequisites for installing the product:
- create a user that must have the following permissions:
- The service user must be a domain user, but being a Domain User is enough (no higher permissions are needed);
- It must be assigned as db_owner of the AULMonitor database;
- It must be a local administrator on the machines where the AULService component runs;
- A SQL Server instance to host the AULMonitor DB. No special features are needed, so a SQL Express instance is enough;
- Create an empty DB named AULMonitor;
To proceed with the installation, you can download the latest releases of the packages I developed, available on my GitHub:
The versions of the 3 components may not follow the same release progression, since I might, for example, publish an update to AULReport that has no impact on AULService or AULMonitor; so I recommend running the latest published version of each component, so you have the most up-to-date release running, with any bugs fixed over time.
AULMonitor
After manually creating the AULMonitor SQL database, we can run the AULMonitor.sql script, which will create the required tables and views:
After running the AULMonitor.sql script, you’ll end up with an AULMonitor database structure similar to this one:
At this point we can add the domain user we created (in my case I named it “aulservice”) as a user with permissions on the SQL Server instance, and assign it “dbo” as Default Schema and the “db_owner” role on the AULMonitor database.
This way we’re authorizing the aulservice user to read and write on the AULMonitor DB, without granting it any permissions on any other DBs on the SQL Server instance.
AULService
Now let’s install AULService.msi on the machines to be monitored. This can be done individually on each user VM, or in the master images (as in Citrix PVS or MCS environments). By installing it in the master images, we can automatically monitor all the “child” instances.
Installing the AULService.msi package deploys the files needed to configure and run the AULService service, in the C:\Program Files\Silvio Balduzzi\AULService\ location:
The role of each file is the following:
- AULService.exe – the executable that runs on the user VMs, monitors the applications launched by users and communicates with AULMonitor;
- AULService-Test.ps1 – a PowerShell file that can be used to run AULService.exe in debug mode (I’ll show you how to use it later);
- TaskScheduler.exe – an executable that guides you through creating the Task Scheduler task needed to start AULService when the machine boots;
After the installation, you need to manually run TaskScheduler.exe, fill in the required data and press OK:
For example, the data could be the following:
- SQL Server with instance: SERVERDB01\SQLExpress (in some cases the server name alone is enough, without the instance name, depending on how it was configured during installation)
- Database: AULMonitor
- TrustCertDB: True or False, depending on whether the certificates used for the SQL connection to the DB are valid
- CheckDBConnection: True (False only for specific debugging purposes)
- Work Folder: C:\AULService\Logs\ (deprecated feature, but not yet removed from TaskScheduler.exe)
- Username: domain\aulservice
- Password: ********
Once you’ve filled in the data and clicked “OK”, a Task will automatically be created in Windows Task Scheduler:
The Task will automatically be configured to run at system startup, with the permissions of the “aulservice” user (which, as a reminder, must be a local administrator on the Windows machines where we want to run AULService). The local administrator role is required to allow the AULService service to access sections of the machine’s registry that contain keys in the user context.
Before rolling out AULService across all VMs, we can debug it from one VM, running the executable through the AULService-Test.ps1 file
By opening the AULService-Test.ps1 file in an editor and filling it in with the same data entered in TaskScheduler.exe, we can run AULService in graphical mode and see how it works; normally, it runs in the background, without a GUI. It’s best to run it as the aulservice user defined above, so that it replicates how the Task Scheduler runs it:
If everything communicates correctly, after a few seconds you’ll see the process writing to the AULMonitor DB during the “Cache to DB Sync…” phase (the section highlighted in purple):
The process is written to analyze, every few seconds, the applications of the users connected to the VM, writing the information to memory and flushing it to the AULMonitor DB only after a few execution cycles. To optimize the application, at startup AULService caches locally the contents of some specific AULMonitor tables, to avoid continuous queries against the SQL DB.
If everything works correctly, we should start seeing the tables in AULMonitor being populated.
Now we can close the application in Debug mode and start it through the scheduled Task. From then on it will start automatically when the VM boots.
At first AULMonitor may have to “take” a lot of writes, since it won’t “know” any applications yet. Later on, the AULService cache will avoid sending unnecessary information to AULMonitor, reducing the writes to the DB. In the first versions of the application I was continuously reading from and writing to AULMonitor, but this made the AULService application consume more resources.
AULReport
As mentioned, AULReport is the package that runs the queries against AULMonitor and shows the collected data. So it only needs to be installed on the VMs of the administrators who need to analyze the data.
The installation package is AULReport.msi, and the installation creates these files:
When you start AULReport.exe (a shortcut is also created automatically in the Start Menu), you’ll be guided through configuring the connection to AULMonitor and activating the tool (it’s free, but I like having a little evidence of who’s using my product).
The application must be configured with the same information defined earlier for AULService, plus a few other details we’ll see shortly. All the settings can also be changed later, if needed.
After clicking “Save and Close”, the license key activation window will appear:
Activation can be done in two ways:
- Hostname dependent;
- Hostname independent;
The first mode lets you activate AULReport on a single VM; activation is done by validating the license against the hostname of the VM it’s running on.
The second mode lets you generate a license file that can be used on several VMs where we’re going to run AULReport.
In both cases you need to enter an email address in the top section of the window and follow the steps for the chosen activation type. If needed, in this earlier post I described how to do the activation step by step: https://www.silviobalduzzi.com/en/2023/09/appuserlist-v2-2-application-user-list-en/
Once AULReport is configured and activated, you can start using it to analyze the data collected by the AULService agents running on the user VMs.
You’ll then be able to run reports and export them in Excel format:
For any suggestions or issues, feel free to write to me.