Following on from this discussion - V4.0.5 - PowerShell Constrained Language mode and the Dot-Source Operator
I’m getting this in 4.0.6 when using WDAC to with script enforcement enabled. The locations where the PSADT is running from are all allowed paths in the WDAC configuration and I’ve verified scripts running in the same locations as the PSADT all report FullLanguage mode when running. I’ve added the signing certificate to the WDAC policy as well, but this was before I found the info below and don’t think it was needed.
If I start a powershell session and run .\Invoke-AppDeployToolkit.ps1 from the prompt, it works fine. It doesn’t work using the exe or the -file parameter from powershell.exe
In our environment I’m seeing errors from PSADT and Windows Defender Advanced Threat Protection (which is creating on the fly scripts in a secure location and using dot-sourcing to import them)
It took quite a while to find this, as the errors given don’t really tell you what’s going on, but when powershell is running in constrained language mode and you launch a script with the -file parameter and the script has a [CmdletBinding()] section for parameters, powershell treats that as dot-sourcing the file into the shell which is in ConstrainedLanauge mode… bug report here for powershell 7 (applies to 5 too), that MS have said is intended behaviour Whitelisted scripts with cmdletbinding cannot be executed by `pwsh -File <Path>` when applocker is enabled · Issue #20508 · PowerShell/PowerShell · GitHub
The fix is not nice, change the -file “Invoke-AppDeployToolkit.ps1” to -command “.\Invoke-AppDeployToolkit.ps1” then it runs the script fine, getting parameters into this might be more difficult though, I’m going to test soon.
Posting this so anyone else who runs into this issue might not have to spend quite as long figuring it out!
It would be nice if PSADT could look at implementing a built in workaround for this in the Invoke-AppDeployToolkit.exe, either detecting the issue or having an argument to switch to -command mode from -file mode and passing params in a safe way to script, to cope with WDAC Script Enforcement, if that’s at all possible!
Thank you for all the work on the toolkit!
Thanks for sharing this, We appreciate the useful info, I’m sure this will assist others in the community.
Can I suggest you raise this as a feature improvement on the GitHub page:
This gives the developers a task they can review and respond to as appropriate
@sfcmgr this is already taken care of for 4.1.0.
3 Likes
Do we have timeline when 4.1.0 release will be? Thanks!
There’s a lot of people deeply excited for the upcoming v4.1.0 release, and we’re excited to bring it to you. We do not have an official release date in mind except for the classic id software line of “when it’s done”. We don’t want to agree to a date and deliver something sub-par.
In saying all of this, we’re still hopeful at the very least to get a release candidate out before the end of this quarter. Being a release candidate, it means that unless something’s wrong, its code that’s in a releasable state. We feel with the raft of changes to deliver v4.1.0, especially with the ServiceUI-less stuff, it’s going to need some vetting among packagers to test in unique enterprise scenarios we may not necessarily have access to (think strange AppLocker/WDAC/Airlock/CyberArk environments).
Our PSADT v4.1.0 release candidate will be released on GitHub and the PSGallery when we’re ready to release it. There’s not long to go though, and I’m proud that for this release we’ve been able to get our GitHub issues count down to <25 (a single page). The issues tracker hasn’t been a single page for well over half a decade. This will be the release people have been waiting for.
3 Likes
Thanks for that reply. Concise and I understood very well the challenges your team has. Keep up the good work! Count me in now among those deeply excited for v4.1.0. Cheers! 
1 Like
That’s all excellent news, thanks for that! I’ll look forward to doing some tests with v4.1.0 when it’s available
1 Like
I just saw that the 4.1.0 release candidate is out!
The notes though doesn’t say anything about WDAC or app control updates. But I’m doing a test run now in our environment. Hopefully it goes through WDAC. 
1 Like
It’s an oversight given the huge amount of features and improvements, however the WDAC goodness you’re after should be there. If there’s any issues, please create a GitHub issue as it’s something we’d love to ensure is ironed out for 4.1.0 final! 
1 Like
Lovely! Thanks again! So excited to try this now…
2 Likes