Aurena Agent best practices for installation

We let the users decide if they want it or not but as many users need to use local printers they install it for this. We decided to automate it completely. Things to note:

1. Software should always be installed under the “user context”. I.e. install it using the username for each user who wants to use the program. It doesn't require Admin to install.
2. The HTTPS Certs will rotate (usually yearly). This will be hashed and stored in %LOCALAPPDATA%\IFS\IFSAurenaAgent\allowed_hosts.txt with the connection info

We use “Intune” to manage our devices. We have created a install/uninstall script that does the install for all our environments on any given device. The user can request the software via our company app store “Company Portal”

We have then put in a check that will automatically update the values in allowed_hosts.txt when the certificates rotate (we have a detection and remediation script).

Message me if you need more info.

Do you happen to have more details of how you manage the deployment of the allowed_hosts.txt with it refreshing?

Do you also deploy it for your DEV and Test environments too?

Hi Chris,

Essentially we have 4 scripts:

• Install Script
  • Runs the MSI installer with arguments for each environment (runs the MSI 3 times just to auto-populate the allowed_hosts.txt)
  • Modifies some registry keys to ensure it is detected (old problem that stopped the agent being detected by IFS, might no longer be relevant)
• Uninstall Script
  • Uninstalls the software
• Detection Script
  • Reads the allowed_hosts.txt text and checks is the Hash value is old. If it is flags for remediation
• Remediation Script
  • If above is true replaces the old Hash with new hash in text file

Essentially every year we find get new cert hash and update our remediation / detection scripts to update all computers. We use the install and uninstall for new deployments / automating software updates.

At the same time we then update our IFS Print Agents as they also fall over with cert changes. All scripts are powershell.

Thank you! That makes sense. We managed to replicate enough of this in our environment and have succeeded in updating the hash with a new text file.

Seriously?
So I'm supposed to install a .msi with the same product code three times?

Hell no. 
Our software deployment solution first checks whether the product is installed before it even attempts to install it. As far as I know, this also applies to Intune. If the product code of the MSI is already present on the system (due to the previous installation), just nothing happens since it will be considered as “installed” allready. 

IFS should learn instad how to (properly) program an installer - resp. what a .msi actually is - since this is bs. Why can't I specify these strings separately, or why does this only allow one “HOST=” parameter?

I refuse to install it this way because that is not the purpose of a .msi and contradicts pretty much everything that is common practice in software packaging.

The ball is in your court IFS.

Hi ll4matDo,

I am only sharing how I approached this. There is no standard for how to deploy this software. But there are 3 requirements to manage:

• The browser must have the extension installed/enabled
• The MSI must be installed
• The allowed_hosts.txt must contain the hashes for each environment the extension is needed for
  • Note: These Hashes will change with the certificate changing of each respective environment, if IFS cloud hosted this is yearly.

For this installation we use the MSI package to detect it is installed or not and the version. If it is not installed it will trigger the install process. For us it was a simple case to have this install process be a simple script that runs the MSI command 3 times. However as long as you meet the above conditions everything will work.

If you wish this to change you could suggest the idea for development (there is a dedicated area in the IFS community for this). However I personally have no issues with how this currently works.

Otherwise if you need any help with your design just reach out.

Hi a.hutchings
 

First, I want to clarify that my earlier response wasn’t meant as a criticism of you personally. I apologize if it came across that way. As a fellow sysadmin, I fully understand the acrobatics we often have to perform because some software developers neglect to adhere to basic standards. Unfortunately, I've encountered this countless times over the years, and my patience for such practices has worn thin.

That said, I have serious reservations about the approach being suggested here. Running an MSI installer three times for the same product code just to populate a configuration file contradicts everything we know about proper software packaging and deployment. It's fundamentally misaligned with the purpose and design of the MSI format. Our deployment systems - and likely Intune as well - are designed to recognize an already-installed product by its product code. If the MSI is already present, nothing further happens, as it is correctly flagged as “installed.” This workflow seems to completely ignore that fundamental behavior.

Moreover, the entire SSL fingerprint pinning implementation feels questionable. Saving the hash in a plain-text file like “allowed_hosts.txt” - which resides in the user's profile under AppData - offers negligible security benefits. An attacker could easily overwrite this file, making the feature more of a checkbox exercise than a robust security measure.

Don’t get me wrong: SSL fingerprint pinning can be a valuable security measure when implemented properly. But in this case, it feels like a poorly thought-out attempt at pseudo-security, providing little real-world benefit while introducing unnecessary complications for administrators like us.

I strongly believe these issues stem from a flawed implementation, and I encourage IFS to consider addressing them urgently. For now, I cannot endorse or implement the suggested method due to its misalignment with established practices and my own standards for software deployment.

As an extension to the original question, I would like to understand how others approach version management for Aurena Agent. Where do you get the MSI file from, and how do you ensure your running the latest version?

It seems the link on the IFS Landing Page > Add Ons section doesn't always get you the latest version. In our case, it provides a version from 2023, while the latest version is dated 2025.

IFS does release new versions from time to time, but I have been unable to find any version history or change log. Does anyone know where i might find that?

As a recent example: In v0.1.2025.0107.1000 (which i think is the newest version currently available?) IFS seems to have address a bug which caused files duplication in the database (in previous versions, using Aurena Agent to check in a PDF file incorrectly resulted in 2 record in the EDM_FILE_STORAGE table, each containing the same binary blob of the file, meaning the file consumed twice as much space in the database than it really should have).

a.hutchings: Do your PowerShell scripts check the installed version vs the latest available, and force an uninstall/reinstall if they are out of date?

Our solution is very basic indeed: We use a script to uninstall any pre-existing version, and then install the latest version at every restart on every company PC/Laptop. Despite this script, our IT team still receive a large qty of tickets from users having issues with Aurena Agent. I'm sure there must be better/cleaner/more robust methods available?

(I wish IFS would provide a solution for this themselves, instead of leaving every user to have to develop their own scrips)

• Robin

Hi RobinHunter,

To be frank this is is really a more IT Operations topic on how to manage your end-user devices & software more than an IFS one which is probably why there isn't much information on it.

We use Intune all our device management. We create software packages and assign them to user groups / device groups. Each package has a method of detecting if the software is installed (registry key, MSI package ID, a specific file), an install command (or script) and and uninstall command (or script).

When we have a new version we create a new package and in Intune we mark it as superseding. This automatically detect the old version and if detected remove it before installing the new version. There is nothing wrong with just scripting it, you just get more options, controls and monitoring with a tool.

Regarding using the latest version or not I am not sure what the guidance is. But I have always assumed the version tied you your portal is the version that is tested with the Major/Minor release of the environment your using. Generally we stick to that version. We would only move to a later release if there was a bug, security concern or we are updating the environment to a new major/minor release.