**I’m using the 3.9.2 version of the toolkit with the updated AppdeployToolkitConfig.xml and the Appdeploytoolkitmain.ps1 files (basically v3.9.3), and I keep running into this access denied error no matter if I run as system or elevated administrator account. As you can see from the error from the log below, I’m updating the version of VLC in our environment.
It will show the normal toast notifications from the regular PSADT, but throws the error when attempting to show the actual PSADT.Toastnotification toast notifications. I read on here where this was an issue showing balloon notifications with this version and some previous versions, but I have tried several different versions to the same effect. The regular balloon notifications work fine, but I think the regular user base we have would like the look and feel of the ToastNotification extension Toast notifications better if I can get those working. **
I’m hoping this is an easy fix.
The snippet of the error from CMTrace is below:
[Post-Installation] :: Unable to show Toast Notification. Falling back to original function…
Error Record:
Message : Exception calling “Show” with “1” argument(s): “Access is denied. (Exception from HRESULT: 0x80070005
(E_ACCESSDENIED))”
InnerException : System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005
(E_ACCESSDENIED))
at Windows.UI.Notifications.ToastNotifier.Show(ToastNotification notification)
at CallSite.Target(Closure , CallSite , Object , Object )
FullyQualifiedErrorId : UnauthorizedAccessException
ScriptStackTrace : at ,
C:\Temp\vlc\AppDeployToolkit\PSADT.ToastNotification\ToastNotificationExtension.ps1: line 2240
at Show-BalloonTip,
C:\Temp\vlc\AppDeployToolkit\PSADT.ToastNotification\ToastNotificationExtension.ps1: line 2286
at , : line 117
at Exit-Script,
C:\Temp\vlc\AppDeployToolkit\PSADT.ToastNotification\ToastNotificationExtension.ps1: line 673
at , C:\Temp\vlc\Deploy-Application.ps1: line 322
at , : line 1
at , : line 1
PositionMessage : At C:\Temp\vlc\AppDeployToolkit\PSADT.ToastNotification\ToastNotificationExtension.ps1:2240 char:6
+ … $null = [Windows.UI.Notifications.ToastNotificationManage …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Error Inner Exception(s):
Message : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
InnerException :
Show-BalloonTip 3/20/2023 8:43:59 PM 12652 (0x316C)
Just asking: are regular users allowed to run scripts at:
C:\Temp\vlc\AppDeployToolkit\PSADT.ToastNotification\ToastNotificationExtension.ps1
No, they don’t have rights. PowerShell is locked down to elevated accounts only. But I ran it from my elevated account and it gives the same error.
I know they changed how notifications are sent to the user.
I think they still create a custom script and launch it in the user context.
My guess is that PSADT is launching the ToastNotificationExtension.ps1 unelevated and since in your Environment that is not allowed: Access denied.
If the ToastNotificationExtension.ps1 script is created in a location where users cannot create or edit files, consider allowing regular user to run PS1 files from that location.
I think if you are using AppLocker, this can be done by designating a folder to be safe.
Well, I retract what I said in my previous comment. I was invoking with elevated account but was logged in as regular account. I just tested by actually signing in as elevated so the runasuser actually ran as an elevated account, and it works great. They have powershell.exe blacklisted here by group policy and have certain users in an exception group, and I don’t think they are going to change their posture on blacklisting powershell anytime soon.
I wonder if there is a way to change it so that it displays as the account it is invoked with rather than the account of the currently logged in user? Ultimately it is going to be invoked under system from SCCM.
RE:
Unfortunately that is not how security on Windows works. One user cannot see the GUI launched by another. This is why in previous versions of PSADT, the popup script was launched by a scheduled task running AS the logged on user.
Popups and Toast notifications are dynamic and are created on the fly.
PSADT must create a script somewhere. VBS is more insecure than PS1 so VBS is being phased out.
Blocking PS1 for all regular users regardless of WHERE the script came from might cause other software to fail, too.
Update: This issue seems to be fixed in the 3.9.3 Beta
Figured I would throw this out there so others don’t waste time like me.
I ran into the same issue running 3.9.3. After reading through the RunAsActiveUserExtension.ps1 code I found this line.
When the context is user (not SYSTEM) the function executes the logic in that context, no invokation as user required.
So if you aren’t testing with system and your elevating PS with an admin account but logged in with a standard user you are going to have a bad time.
After running PS with psexec.exe everything worked as intended.