I have been having some problems using PSADT v4.0.6.
The most severe problem is that it seems to, for reasons I don’t understand, completely disregard the exit codes from any msi or executable that i run inside install or uninstall sections of the script.
For instance, if I write something obviously wrong, like:
Start-ADTProcess -FilePath “random.exe” -ArgumentList “/S”
the above command not correctly specifying the path to the executable, I will see the
toolkit start, display the fluent widget, then refresh and say that nothing went bad, just an OK.
In the logfile I’ll find a “path not found error” related to the “random.exe” file not being found, but later down in the final part of the log, there will be a “finished with exit code [0]”, which in my view is completely wrong, and not at all how v3 handled exit codes.
I have downloaded the “PSAppDeployToolkit_Template_v4.zip)” from the GitHub, which as I understand it, should contain all I need.
I understand that the correct way to find the file that is places inside “Files” is to use:
$($adtSession.DirFiles)
I am just wondering why the exit codes are not being handled as before, and also of course what I am doing wrong?
Just like v3, you need to specify -AllowRebootPassThru when running the script. It’s one of my most hated aspects of the toolkit though and I wish I put my foot down about it for v4 and just removed it. There was internal miscommunication about it which is why it survived.
The reason most exitcodes were changed to 0 is for MECM (pka SCCM and SMS). Each MECM app would have to be changed to accept exitcodes other than 0 as a success. And older versions of SCCM wouldn’t even allow non-zero exitcodes to be treated as success.
SCCM is probably not the only flaky beast out there for ExitCodes so it’s probably best to keep the feature. We could add a mention of -AllowRebootPassThru in the log when PSADT is converting the non-zero success exitcode to zero to avoid posts like this.
This is not the scenario I am trying to describe.
I am not using SCCM or any deployment-suite atm, I am ONLY using the toolkit as is, to test it.
I am running the Invoke-AppDeployToolkit.exe file or ps1 to see that my script is working, but even then the exit code is always 0.
This was not the case with v3. Please explain why this happens. Why is the toolkit “on its own” not able handle the exit codes anymore?
I assume I am too new to v4, but still I think I have to have missed something.
so my scenario is:
downloaded the toolkit
edited the script to add let’s say Copy-ADTFile to copy a file, that I, on purpose, specify the wrong path to.
run the ps1 or exe from the toolkit
toolkit says OK
nothing is copied, and the log is stating “file not found”.
no sccm or other third-party deploy method used at this stage.
this means I am not using any passthru, since I am only using the toolkit itself atm. (for testing)
Blockquote
The reason most exitcodes were changed to 0 is for MECM (pka SCCM and SMS). Each MECM app would have to be changed to accept exitcodes other than 0 as a success. And older versions of SCCM wouldn’t even allow non-zero exitcodes to be treated as success.
it is potential problem.
this is my logs:
<![LOG[[Post-Install] :: installatoin was not successful, terminate with 3010]LOG]!><time=“03:37:20.585-480” date=“5-27-2025” component=“Post-Installation” context=“------------” type=“1” thread=“10776” file=“--------------\Invoke-AppDeployToolkit.ps1”>
<![LOG[[Finalization] :: [----------------] installation completed with exit code [0].]LOG]
so, i am forcing 3010 exit code, but getting 0 in the end.
The problem is I reckon this has been asked at least 15-20 times that I’ve seen since the v4 release, it’s just not intuitive.
What we’ll likely do is change it to -SuppressReboot so that by default it emits the reboot codes properly unless you tell it to otherwise. That way you get the behaviour you may want, but the default experience is arguably better.
Why are you talking about “SupressReboot” ??? I am talking about the very CORE function of any script language, program or app, namely proper handling of EXIT CODES.
If MECM or anything else doesn’t handle or “accept” anything other than 0 as a success, then that is a failure or lack of feature on MECM’s part. It is NOT something you should try and solve, especially in the way of ALWAYS returning exit code 0. This literally means the toolkit is useless, since I can’t even know if the installation failed.
I will say it again, v4 is no-go for anyone that needs to properly know an exit code. Did something go wrong, does the device actually need a reboot, did the installation generate a custom exit code. None of this can be gleaned from the current implementation of v4. It baffles me how one can do this at all if I am being honest.
I’m trying to work out whether you’re agreeing with me or having a go at me . Let’s try and break it down.
Regrettably, our toolkit even in the v3 days has had an option called -AllowRebootPassThru, whereby in its default state, a nominated reboot code does not get returned; instead returning 0. We don’t believe this is the right approach anymore and seek to change it, however people may be relying on that behaviour, rightly or wrongly, hence the suggestion of an opposing switch to replace it which does the opposite.
I believe we’re in complete agreement here, hence why we’re trying to right the wrongs of the past for the benefit of not just yourself, but the wider community.
Far from it. By virtue of the name, the -AllowRebootPassThru switch only supresses the return of an exit code that’d tell MECM, Intune, or other software that an app deployment requires a reboot. A failing exit code will always be returned when an error occurs, either the app installer’s own exit code or one of our generic ones in the event of a script typo, etc.
I believe you’ve got a huge misunderstanding about what’s being talked about here and as such, I’d refer to you to the previous quote reply in this post I’m writing to you now. I will say it again, v4, like v3, will return an error code at all times when a deployment fails unless you as the packager go out of your way to suppress. The only thing v4 suppresses is the same thing that v3 suppresses by default, reboot exit codes.
There shouldn’t be anything in-particular to glean as the behaviour in this regard is 1:1 with v3 and it was very deliberate to make v4 maintain the core of what makes PSAppDeployToolkit the solution everyone’s come to know and love. We absolutely welcome documentation suggestions or improvements from the comunity and want to make sure you’ve got the information necessary to feel empowered with your deployments. On the initial release of v4, some of our documentation did not meet our own standards which we apologise for. I can only offer excuses, however the refactoring that’s gone into making v4 was no small undertaking and in trying to deliver a first class product among sacrificing personal time with our family, friends, and loved ones to deliver the product for free, the quality of documentation did slip in that process.
I’m unsure whether you’ve used v4 yet, however you yourself can download our latest template, add a line akin to Start-ADTProcess -FilePath cmd.exe -ArgumentList '/c "exit 1234"' and observe your deployment will fail and exit out with an exit code of 1234. That truly is package management 101 and nothing’s slipped there.
. Let’s try and break it down.