Where has "ExitOnProcessFailure" gone? "Start-ADTProcess" function in v4

The Toolkit General Discussion
1

Hey all,

I may not have done a good “RTFM” but for one specific deployment, I need to handle correctly the case where the process crashes.

With PSADT v3.10.2, I used that in order to exit in a good way PSADT:

        $result = Execute-Process -Path "$CMUTool" -Parameters "-i -f `"$dirFiles\$LicenseFile`"" -ContinueOnError $true -ExitOnProcessFailure $false -PassThru
        If ($result.ExitCode -ne 0){
                Write-Log "Cloud license file for GGU wasn't imported - Check if Codemeter is installed on the device." -LogType 'CMTrace' -Severity '3'
                Exit-Script -ExitCode 1
            }

Now with PSADT v4.0.6, I made this and tried a couple of other things without success:

    $result = Start-ADTProcess -FilePath "$CMUTool" -ArgumentList "-i -f `"$($adtSession.dirFiles)\$($adtSession.LicenseFile)`"" -ErrorAction SilentlyContinue -PassThru
    If ($result.ExitCode -ne 0){
            Write-ADTLogEntry -Message "Cloud license file for GGU wasn't imported - Check if Codemeter is installed on the device." -LogType 'CMTrace' -Severity 3
            Close-ADTSession -ExitCode 1
        }

I’m always getting this popup:

image
image335×176 14 KB

I understand:

  • “-ContinueOnError $true” been replaced by “-ErrorAction SilentlyContinue”
  • “-PassThru” remains same
  • But what about “-ExitOnProcessFailure $false”? I can’t find any reference to switch part of PSADT v3.

I used “Test-ADTCompatibility” and “Convert-ADTDeployment” to identify a tips but the PSADT v4 doesn’t refer anything for “-ExitOnProcessFailure $false”.

Measure-ADTCompatibility            Warning      Deploy-App 243   The function [Execute-Process] is deprecated, use
                                                 lication.p       [Start-ADTProcess] instead.
                                                 s1               -Path "$CMUTool"  →  -FilePath "$CMUTool"
                                                                  -Parameters "--delete-cmcloud-credentials --serial
                                                                  140-3815331051"  →  -ArgumentList
                                                                  "--delete-cmcloud-credentials --serial 140-3815331051"
                                                                  -ContinueOnError $true  →  -ErrorAction SilentlyContinue
                                                                  -IgnoreExitCodes "1"  →  -IgnoreExitCodes 1

Is this switch will soon arrive in v4? Any ideas?
Am I completely off the mark?

Thanks all by advance,
Axel.

2

What you did should have worked but you are also troubleshooting blind.
Was an Exitcode even returned?
Was there an error message?

Try adding these lines to your sample to capture that info to the log file:

    Write-ADTLogEntry -Message "ExitCode = [$($result.ExitCode)] " -Severity 1
    Write-ADTLogEntry -Message "StdOut = [$($result.StdOut.Trim())] " -Severity 1
    Write-ADTLogEntry -Message "StdErr= [$($result.StdErr.Trim())] " -Severity 1

Something like this:

    $result = Start-ADTProcess -FilePath "$CMUTool" -ArgumentList "-i -f `"$($adtSession.dirFiles)\$($adtSession.LicenseFile)`"" -ErrorAction SilentlyContinue -PassThru
    Write-ADTLogEntry -Message "ExitCode = [$($result.ExitCode)] " -Severity 1
    Write-ADTLogEntry -Message "StdOut = [$($result.StdOut.Trim())] " -Severity 1
    Write-ADTLogEntry -Message "StdErr= [$($result.StdErr.Trim())] " -Severity 1
    If ($result.ExitCode -ne 0){
            Write-ADTLogEntry -Message "Cloud license file for GGU wasn't imported - Check if Codemeter is installed on the device." -LogType 'CMTrace' -Severity 3
            Close-ADTSession -ExitCode 1
        }

BTW: the -ExitOnProcessFailure parameter in v3 was a late addition to PSADT and I did a WTF when they added it. I saw it as a crippled `-PassThru’ hack and never used it.

3

The -ExitOnProcessFailure is dead and gone, it wasn’t well thought through and it flies in the face of proper PowerShell code.

What happens now is that by default, if the executing function fails with an unspecified exit code, a terminating error is thrown and the main catch block in Invoke-AppDeployToolkit.ps1 closes the session for you. Perfectly logical, reasonable, and sane.

Regarding the OP’s specific things:

This is completely correct and shouldn’t cause any issues.

This popup is from Invoke-AppDeployToolkit.exe. With 4.0, if running interactively, it will display such a dialog for certain exit codes and all unknown ones. An exit code of 1 is one of those certain codes because that’s what PowerShell throws when you’ve got an unhandled exception, such as a typo or missing curly brace in your script.

This change isn’t without issue though and is being discussed here: [Bug] Get an error message when using ServiceUI with an user-specific exit code · Issue #1339 · PSAppDeployToolkit/PSAppDeployToolkit · GitHub. The basis behind it is that too many people use the exe, have a problem and don’t know where to start troubleshooting because they don’t even think to test via powershell.exe -File Invoke-AppDeployToolkit.ps1, etc. Sort of a “damned if you do, damned if you don’t” type thing.

We’re discussing this internally around what we can do to resolve this while making the executable more resilient. What I really want is to not have the exe call powershell.exe to run the script, I’d rather instantiate a C#-based PowerShell runspace object so that we can actually properly read errors out of PowerShell. For this, we’d need to get rid of the whole RequireAdmin config option.

We’ll update the aforementioned GitHub issue with what we’re considering regarding the exe and error notifications during interactive usage.

4

Thanks guys for the time to answer me.
You highlighted a lot of things to me.

Since at least 4 years with PSADT v3, our standard is to use exactly this cmd line to invoke our deployments from Intune: ServiceUI.exe -process:explorer.exe "Deploy-Application.exe" Install and with Uninstall for uninstall command. We used that way to ensure the interactive session to close apps and show PSADT messages coming from Intune system context.

Thanks the linked topic, I understand a new recommandation to play with ServiceUI. And that’s so fun because it will prevent issues we have currently when “explorer.exe” isn’t running because the device just turn on without logged user. Thanks this new way to call ServiceUI, we will be able to be in interactive session only if we have a logged user, that’s super exiting.

About the main issue I asked to discussed, I also understand what I missed and forgot to check. The end of the script inside the catch block is my answer. I can probably play with Show-ADTDialogBox -Text $mainErrorMessage -Icon Stop | Out-Null to mask this box to the user.

Sorry for the bad “RTFM” “Read The F****** Manual”, I now have to review this new feature and play a bit with it. This will probably also highlight me why I don’t have like in PSADT v3, the install status bollon shown on the bottom right of the screen at the end of the install.