Hello! Our (un)installer runs a few Powershell scripts. They all are running from the temp folder (as specified in the Powershell execution options).

Unfortunately, on some systems, the invocation of the scrip generates the following error:

> MSI (c) (44:90) [18:40:33:647]: Invoking remote custom action. DLL: C:\Users\S12DE~1.RAM\AppData\Local\Temp\MSI462.tmp, Entrypoint: RunPowerShellScript
[INFO] PowerShell script preferred invocation folder:
Dumping PowerShell invoke log ...
--> Found PowerShell path: C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe
--> PowerShell Script Execution Result Code: 574
--> PowerShell Script Execution log:
ERROR: An object at the specified path C:\Users\S12DE~1.RAM does not exist.

MSI (c) (44!08) [18:41:01:987]: PROPERTY CHANGE: Adding POWERSHELL_EXECUTION_LOG property. Its value is 'ERROR: An object at the specified path C:\Users\S12DE~1.RAM does not exist.'.
CustomAction XXXX returned actual error code 1603 (note this may not be 100% accurate if translation happened inside sandbox)

Searching online results in a few hits:
https://stackoverflow.com/questions/107 ... powershell
https://stackoverflow.com/questions/415 ... -not-exist

I wonder if there is a possibility of the Advanced Installer changing/fixing how the temp file location is determined? So the PS scripts can run without the errors?

Thanks!

Hello Sasha,

From what I currently understand, this issue is machine related.

I wonder if there is a possibility of the Advanced Installer changing/fixing how the temp file location is determined? So the PS scripts can run without the errors?

I'm afraid that I do not quite understand this question.

In order for me to have a better view on this issue, I would need to reproduce this on my end so I can further investigate it.

For instance, are you able to reproduce this issue on your end? If so, have you managed to find what option is the "culprit"?

If that's the case, please forward me a sample AIP file (it can be empty, only containing the script) that reproduces this by email at support at advancedinstaller dot com together with a test-case so I can further investigate this.

Best regards,
Catalin

Thanks for the reply, Catalin.
The issue does seem to be machine-specific. I cannot reproduce this at-will. The same MSI will work fine elsewhere, but fail on a 'bad' system.
The 'run from' is selected to be the temporary folder in the AI Powershell script options.

The links I included possible explanation on what happens with the temp folder location and Powershell. Basically, using the $env:temp is unreliable. I don't know if internally AI is using that or not.

The 'bad' systems seem to be such where the %userprofile% ends up being in the 'short path' form. That includes accounts in this form: first.last or "first last".

So, in short, providing an .aip is probably not useful. I suspect any .aip that includes running an inline Powershell script that run on a 'bad' system will fail. How to get a system into the 'bad' state (if having a 'funky' account name is not enough), I don't know. Again, if AI is relying on $env:temp, that's the problem. If AI doesn't rely on that, then I don't know what a solution could be.

Thanks!

Hello,

Thank you for your followup on this!

If you manage to find the culprit here, please let me know and I will gladly test this on our end.

Regarding the $env:temp, please note that we do not use it, so I do not think that's what's causing this.

Best regards,
Catalin