Required Software MSI override code returns a failure when run

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. 

$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
**********************

$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?

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

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

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.

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.