Since we changed PSADT to version 3.9.x a weird problem appeared.
First of all:
There are public faced machines in our environment were the execution of powershell scripts for the USER is of course blocked.
Since the deployments are getting deployed to the SYSTEM via SCCM this was never a problem with 3.8.4
With version 3.9.x we are getting an error popup window with “PSAppDeployToolkit-ExecuteAsUser.vbs” got blocked by group policy.
Same deployment, all the same, only the PSADT version is different.
So why is version 3.9.x trying to do something under the user account even if the deployment is for SYSTEM and DEVICES and how can I block it from happening?
If you allow users to VBS scripts located in
\ProgramFiles, I suggest to move the PSADT temp file location in the XML to \ProgramFiles\
I explain why here: Microsoft Defender "Suspicious Scheduled Task Launched" - #3 by Axelo2
You might want to consider allowing users to PowerShell scripts located in
FYI: PSADT authors want to remove VBS from PSADT. VBS has been deprecated in Windows 11.
So, are we only talking about a location or permissions for the user?
As I mentioned above, these are public faced machines, so the user will never be allowed to run powershell or vbs scripts, no matter from were. But since we are talking about a SCCM deployment to a device, the SYSTEM account is what should take action, and not the user account. If there is something running under the user account, then this is wrong by design.
Again, switching back to version 3.8.4 the problem is gone, so there must be something in 3.9.x causing it. Question is: Can I change this wrong behaviour from PSADT in 3.9 or not?
I vaguely remember that they changed how popups worked in 3.9.x.
It caused many problems.
I recommended to edit the Toolkit_TempPath in the XML to this:
if you don’t want to do this, look in the PSADT log file when you get the error message and see what it’s trying to do. Then modify your script to not cause the issue. I’m guessing here because I have no lines code or log files to go by.
You are most likely seeing this issue because you are allowing the SCCM application to be run interactively and you are using the Show-InstallationWelcome function in your Deploy-Application.ps1 script (which is the default configuration).
It’s probably enough to run the installation with the parameter -DeployMode Silent, or you could remove/remark all Show-InstallationWelcome functions in your script.
Note that the script Deploy-Application.ps1 is configured to be run interactively by default so you might need to modify it depending on your need/scenario.
Hi JFP and thanks for reacting.
You are right, we are running the applications with allowing the user to interact. If you’re planning on using specific functions like deadline behaviour where the user can start the installation when it is convenient for him, you pretty much have to. But all the welcome lines in the deploy-application.ps1 are already removed, so that cannot be the issue.
-DeployMode silent would be an option, but I believe that would also suppress some PSADT functions like closing and blocking tasks and informing the user about it, wouldn’t it ?
Thanks for your support That-Annoying-Guy.
I will give the XML Path change a try and let you know if it helped.
Changing the path to $envProgramFiles did not help. But I guess that’s because the error message in the screenshot above is not revering to the $envTemp folder.
But I finally figured out where the problem is.
There is a new XML configuration in 3.9.x which did not exist in 3.8.x:
<!--Toast Notification Options-->
If I set this option to “true” in order to supress the toast the error popup is gone. Which means the toast from PSADT is getting prepared for displaying in the user-profile-folder as vbs which causes applocker getting a tantrum.
I hope this will help others with the same issue.
FYI: The xml file gets updated almost every release.
E.g. language support, New settings, etc.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.