Required Software MSI override code returns a failure when run

Hi @TJ_Coppola I’ve had a lot of success preparing my worklet scripts using a 32-bit version of PowerShell running in the same context as the agent, which is NT SYSTEM.

This is how I’m loading that PowerShell ISE after downloading that SysInternals tool, psexec, from Microsoft.

psexec -s -i -d C:\windows\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe

psexec -s -i -d C:\windows\SysWOW64\WindowsPowerShell\v1.0\powershell_ise.exe

Thanks for this!

It made no difference if I ran from Powershell ISE using psexec as you described. It runs perfectly if I do that, but wont run if I run it as a policy from Automox. 

Maybe you could try to add this to the top/bottom of your worklet to discover more of what is going on:

$transcript = "$env:windir\temp\worklet.txt"
Start-Transcript $transcript

# Your Worklet Code

Stop-Transcript
Get-Content $transcript

$transcript = "$env:windir\temp\worklet.txt"
Start-Transcript $transcript

# Your Worklet Code

Stop-Transcript
Get-Content $transcript

This is the output of that transcript. 

**********************
Windows PowerShell transcript start
Start time: 20240502111430
Username: CPBI\SYSTEM
RunAs User: CPBI\SYSTEM
Configuration Name: 
Machine: HFD-MIS-TJ (Microsoft Windows NT 10.0.22000.0)
Host Application: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -NonInteractive -NoLogo -ExecutionPolicy unrestricted -File C:\Program Files (x86)\Automox\execDir677899075\execcmd077280710.ps1 
Process ID: 511056
PSVersion: 5.1.22000.2538
PSEdition: Desktop
PSCompatibleVersions: 1.0, 2.0, 3.0, 4.0, 5.0, 5.1.22000.2538
BuildVersion: 10.0.22000.2538
CLRVersion: 4.0.30319.42000
WSManStackVersion: 3.0
PSRemotingProtocolVersion: 2.3
SerializationVersion: 1.1.0.1
**********************
Transcript started, output file is C:\WINDOWS\temp\worklet.txt
**********************
Windows PowerShell transcript end
End time: 20240502111444
**********************

@TJ_Coppola could you post the output of the MSI log? Maybe there is something in there.

$transcript = "$env:windir\temp\worklet.txt"
Start-Transcript $transcript

exit (Start-Process -FilePath 'msiexec.exe' -ArgumentList ('/qn', '/i', '"Newsboss.msi"', '/L', '"$env:windir\temp\nblog.log"') -Wait -Passthru).ExitCode

Stop-Transcript
Get-Content $transcript

This is the override code with the transcript modification you suggested. I added the logging arguments, but for some reason the logs aren’t being generated. 

Is there an issue with the msiexec being called on the exit command? Would that prevent getting the transcript from generating correctly?

Is there an issue with the msiexec being called on the exit command? Would that prevent getting the transcript from generating correctly?

Nevermind, I removed the exit command and it didn’t make a difference. 

That looks right to me. This one will change it up some. Right now whatever happens, the exit code from msiexec. Which could be a desired behavior, but not super helpful when troubleshooting like this.

• Move exit code to regular output you can see in activity log
• Scan the event log for events related to the install (may need to adjust ‘Newboss’ to what it should show up as)
• Dump the msiexec log into the activity log

$install = (Start-Process -FilePath msiexec.exe -ArgumentList "/qn /i Newsboss.msi /l*v $env:windir\temp\nblog.log" -Wait -Passthru).ExitCode
Write-Output "Newboss.msi Install ExitCode: $install"

# Collect Application logs
$today = Get-Date
$start = $today.AddDays(-1)
$events = Get-WinEvent -FilterHashtable @{
   LogName='Application'
   ProviderName='MSIInstaller'
   StartTime=$start
   EndTime=$today
} | Where-Object Message -match "Newsboss" # <-- look at the log, the name might be different...
ForEach($event in $events)
{
    Write-Output "$($event.TimeCreated) | $($event.Message)"
}
Write-Output ''
Write-Output 'Collect MSI Log Output'

Get-Content $env:windir\temp\nblog.log

I used the code you provided and I still have no log file. The Activity Report still only shows “Failed to install software:”

Just out of curiosity I tried something else. I changed the code to make it incredibly simple:

Start-Process Newsboss.msi

That’s it. I still got “Failed to install software:”

Could there be something preventing the whole worklet from being run? 

You could use PsExec.exe (by Microsoft SysInternals). Start that software. Hit Spacebar to freeze collection. Run worklet, then go back to PsExec and hit F5 to refresh. That would show you (highlighted in green) amagent launching the powershell.exe process and that launching the MSIExec process. This is a priceless troubleshooting technique to see what’s happening. Then you would know where the breakdown is. 

Another simple way, would be to test to see if you can see the payload and remove the exit code logic. I’ve never relied on exit code logic myself. If I have issues with an MsiInstaller, I typically do the log and grab the output. For most all payloads I’ve always wrapped them in a, does it really exist IF statement. 

IF(Test-Path Newsboss.msi){
     Start-Process msiexec.exe -ArgumentList "/qn /i Newsboss.msi /l*v $env:windir\temp\nblog.log" -Wait
}else{
     Write-Output 'Unable to detect Newsboss.msi'
}


# Collect Application logs
$today = Get-Date
$start = $today.AddDays(-1)
$events = Get-WinEvent -FilterHashtable @{
   LogName='Application'
   ProviderName='MSIInstaller'
   StartTime=$start
   EndTime=$today
} | Where-Object Message -match "Newsboss"
ForEach($event in $events)
{
    Write-Output "$($event.TimeCreated) | $($event.Message)"
}
Write-Output ''
Write-Output 'Collect MSI Log Output'

Get-Content $env:windir\temp\nblog.log

I think I may be missing a step. How would I use PsExec to collect the output of the worklet? Running it only gives me the help information. 

 

My bad. I was just using that one and got my wires crossed. You want to use ProcExp Instead. However when testing, it did not work the way I thought it would I was expecting to see powershell launch msiexec, which I did not. You can only see amagent launch powershell.exe. 

Might just stick with the code re-write where it will test for the payload before executing.

Same result: activity report only gives “Failed to install software:” and there’s no nblog.log

It doesn’t seem to be running the worklet code at all. Something must be precluding it. 
 

I tried reuploading the msi in case it’s bad, but that didn’t change anything. I wonder if the msi isn’t 32 bit. It doesn’t seem to specify if its x64 or x86. Would that make a difference since Automox is using a 32 bit PS?

After reading the documentation, https://help.automox.com/hc/en-us/articles/5352032560788-Using-the-Required-Software-Policy,  I’m wondering if “Failed to install software” could be related to a miss-match of how Automox sees the exact software title on any devices inventory. I’ve had instances where a vendor will change the software title as it appears in “Programs and Features”.  Make sure the Package Name and Package Version match exactly what you see in Automox.

If that still fails, then move over to a “Worklet Policy” to test. That way you can get output and logs. I’d expect at least there you will get to see what’s going on more in depth..

How I figured this out:

The “Required Software Policy” activity log will not write-output similar to how a “Worklet Policy" will. In this example, I’ve used that “Required Software Policy” to deploy Nessus. When looking at the code execution history in the event log, it is clearly writing output, but the activity log in Automox is not showing it. Similar to your experience, the only output you get is installed or failed. Which is not super helpful for troubleshooting.  

Jack, Just wanted to update you on this since it’s been so long. Thank you for all the time and effort you put in on this.

I’ve been noticing that not only does this policy return an empty error, but most policies running are returning an empty error. I put in a support ticket to get to the bottom of it. I’ll return here with the findings once it’s been resolved. 

@TJ_Coppola same experience. Tried one out and no error was returned.

I’m learning that amagent.log might show you the error, which in my case for MsiExec is the famous 1603, a generic error.

I’ve been paying close attention to this experience using the Required Software Policy. At least for me, when deploying the latest MSIExec installer, no error code in activity log, error code in amagent.log (know policy ID to find it), and the EDR logs show msiexec executing, but many clients just hang onto the process for hours on end, never ending. This causes the command to never report back. I don’t think in anyway this is a larger issue, as I’m only using one MSIExec to do some initial testing. 

I’ve been adding the MSIExec log command, and watching EDR logs to better understand what is happening. 

, '"/lvx* C:\windows\temp\my-install.log"'