bedalus
commented
2 weeks ago No response from the devs, but if anyone is looking for a solution, this may help:
# Standard path to the ProM .ini file
$configPath = "C:\Program Files\ProM\ProM.ini"
# Read the content of the file
$content = Get-Content $configPath
# First test if the ini has already been edited on this machine
$check = $content | Select-String "^PROM_USER_FOLDER = \.\." | Select-Object -ExpandProperty Line
if ($check) {
# Already edited, someone else has dibs on this machine
Exit 0
}
# Find the line that starts with the default "PROM_USER_FOLDER = ."
$line = $content | Select-String "^PROM_USER_FOLDER = \." | Select-Object -ExpandProperty Line
# Replace the line for the current user
$relativePath = "../.." + ($env:USERPROFILE -split(':'))[1].Replace('\','/')
$newContent = $content | ForEach-Object { $_ -replace [regex]::Escape($line), "PROM_USER_FOLDER = $relativePath/ProM" }
# Save the updated content back to the file
$newContent | Set-Content $configPathThis works when the software has been installed to C:\Program Files\ProM
However, we couldn't get the GPO scheduled task to run this in our environment so have reached a dead end in terms of an unattended solution for end users.
UPDATE: We found that we could edit this in our install location 'C:\Program Files\ProM\Prom.ini' - but we would need a script to sed/regex/replace with the $LOCALAPPDATA$ location on a per user basis each logon. In Windows this can be achieved by a scheduled task, but it's not a clean solution as it's an overhead for the hundreds of other users who don't use this package. However the impact is minor. Accepting my suggestion below, or providing any other ideas would be very welcome.
Hello, I'm an admin for NHS Azure Virtual Desktop, and we have a request to provide ProM. We're installing the software like this:
...but we are having a problem. The user has the following error:
...as text:
Firstly, the extra dot in the path seems to be an error. Second issue is that the machine is not persistant (deleted/recreated each day), so for packages to be persisted they would need to reside in a dedicated ProM folder within the user's AppData (i.e. $env:APPDATA)
I imagine the software would also need to search in AppData as an initial step in order to read from a config file there that stores whether the install location is being used for packages, or whether it's been customised to use AppData instead. That file would of course need to be written after the user selects that they require a custom location.
Does this sound like something you could support?