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.