So it seems Remove-MSIApplications -Name ‘Forticlient’ -ExcludeFromUninstall @(‘DisplayVersion’,‘7.2*’,‘Wilcard’) -ContinueOnError $true
has stopped continuing on error. The MSI installer file is not being found on purpose, which gives a error/exitcode 1612, so the next line can execute, but the next line of code is not being executed that uninstalls using the MSI file in the \FIles\ folder.
Execute-MSI -Action Uninstall -Path ‘Forticlient6.msi’ -addParameters 'reinstallmode=vomus’
I’m not sure what I have done to break the action. Some of our laptops dont have the MSI still cached under C:\windows\Installer, hence the need for the code above. Any advice?
This is why I force ALL my MSIs to create a log file.
Maybe some of your PC don’t have Forticlient installed at all.
Does your Script handle that?
or at least send a write-log to say that no Forticlient was found on the computer?
This is a real problem - been brought up several times before - and never addressed. Most of the responses are along the lines of “Don’t you want to if the line fails?!” or “write a log to determine why the 1603”. These suggestions are using the sledgehammer approach and are missing the very valid use cases to continue on error.
Real world example:
I’m doing an uninstall of an application via “Remove-MSIApplications”.
Uninstall succeeds on 97% of devices.
The remaining 3% need some additional special handling/manual cleanup, which is further down in the script. Script never gets to that point due to the force-exit by the 1603.
Not looking to investigate why the 3% are failing when I already have steps further down in the script which will address them perfectly - but the way PSADT works, the script never makes it there.
As OP stated, $ContinueOnError $true does NOT WORK with “Remove-MSIApplications”. This should be treated as a bug.
If Remove-MSIApplications’s -ContinueOnError $true does not work, Please report it here:
Issues · PSAppDeployToolkit/PSAppDeployToolkit (github.com)
That said, some people use .tag file to determine a if we have a successful install/uninstall.
I use them to make sure any extra code placed after the MSI or Setup.exe is processed or not.
It’s the last thing my PSADT script does.
Then I use the existence of the tag file as the target for the Intune/SCCM detection script.
I can submit it, but truly not sure if it’s an “error” in the traditional sense. Meaning, 1603 could very well be treated as a non-0 exit code, but not necessarily an “error”.
In that case, this would be more of a feature request than a bug fix: Continue on a non-0 exit code (as opposed to Continue On Error)
For me, an MSI 1603 error during a removal on a fairly clean computer means:
- Computer OS/Software is broken. Might need to re-install the app on top of broken installation to uninstall.
- MSI package has a poorly authored Uninstall. Author focused on the installation with tweaks or scripts but ignored the uninstall.
- Other bad things (e.g. a CA with embedded VBS script…)
IOW: is an MSI issue, not a PSADT issue.
2 Likes