Windows Credentials Pop Up Issue


A few months back we had an issue where the PSAppDeployToolkit was popping up with a username/password admin elevation when deployed to a device. Before this issue the application was able to run properly without issue. We didnt make any changed to the PSAppDeployToolkit deployment.

We were able to resolve this issue by creating a profile and disabling the LSA Protection via a registry key. Apparently some enrollments were getting this turned on by default due to a Microsoft change.

A few more devices have started this behaviour again and were trying to figure out the cause this time. Has anyone else experienced issues with the PSAppDeployToolkit asking the users to enter in a admin credentials when it runs? This is an example screenshot of the issue. If you enter in a admin credential it will work properly. If you cancel it will fail. When its working correctly this never appears and the user is presented with the PSAppDeployToolkit normal process.

What are you using to trigger the PSADT package?

We are using VMware Workspace ONE as our MDM solution. It pushes down the application and then runs the install command Deploy-Application.exe that kicks off the PSADT package.

Sorry, I am not familiar with VMware Workspace ONE (I use Microsoft Intune), but I’m guessing that Workspace ONE incorrectly assumes your Users (Install Context = USER) to have Admin rights (Admin Priviledges = Yes), this may be by behaviour of VMware Workspace ONE but not best practice fromn a security perspective (Least priviledge access), I’m thinking if you tried to change the Install context to Device (with Admin Priviledges still set to Yes) it ‘might’ work
The (i) next to each setting might give you some context of the behaviour.

But you should be aware, that if what you are deploying needs the user to have some interaction - you may need to include the ServiceUI.exe (from MDT) to bring the dialogs through to the users context, e.g.

ServiceUI.exe -Process:explorer.exe Deploy-Application.exe -DeploymentType "Install"

N.B. Intune defines the Install context as SYSTEM (e.g. full rights) or User (rights (limited) assigned to user), as our users have very limited rights we deploy software using system - this also means we control what can be installed on a users device.

1 Like

Thanks for the input.

We have that set to User context because it allows the user to provide input during the install. When we do silent installs we normally select Device as users dont need to provide input. But during this app install were checking for running programs that need to close so we ask the users to save their work before its closed.


In the past the Deploy-Application.exe has kicked off the install process and allows the user to postpone or install the updated application. I may look into utilizing the ServiceUI.exe as an alternative. I may also look into the PSADT.ToastNotification Extension as I see that doesnt require admin privilidges to run. Perhaps that can be a workaround.

So far we only have a few devices having the issue and they are just IT users. I cant reproduce the issue on my device, its working as expected.

I couldn’t post more than one image in a post as I am a new user. But here is the description for the admin privileges.

Our users are not local admins. We use this option here to have the install work for non admin users

In VMware Workspace ONE, try using the DEVICE install context.
The installation will use the Local SYSTEM account for the installation and the ServiceUI.EXE should make it possible to send GUI popups to the user’s context.


I entirely agree with @That-Annoying-Guy - ServiceUI.exe is the tool you need to bring the System deployed application dialogs to the Users context
I have mentioned this previously on another thread, but there is a reasonably good blog (apart from the adverts) about the usage of ServiceUI.exe with Intune here: Use ServiceUI With Intune To Bring SYSTEM Process To Interactive Mode HTMD Blog This is well worth a read to solve the issue (It doesn’t matter that you are using VMware Workspace ONE, the process is much the same)


Hi There,

Where you able to resolve this isseu, and if so how did you manage to do that. We are also using the same Method with UEM and with the USER with ADMIN settings. With LSA now enabled we are having the same issue that this is no longer working as should be. Hope you can give us some information on this matter. We can and MAY NOT disable LSA… Also Does the ServiceUI.exe ‘for instance’ work from the system towards the user with LSA enabled on a Windows 11 device??

Thank you in advanced.

Hey, we resolved the issue by disabling LSA. Couldn’t find anything else that would work when I was trying to fix the issue. So far its still working.

1 Like

Hi Thanks for the fast responce.!! Too bad you havent found a solution…
Disabling LSA is not an option for our company. To big of a risk there. Also in future releases LSA is default by Windows, and also adviced in security baselines.
Have you created a case with VMWare for future references?
Also does that mean that the AppDeployToolkit will not work at all in the future cause of LSA? / Security settings? Thanks again and greetings.

Our infosec team vetted our change request and they were okay with us disabling LSA. We use CrowdStrike and the infosec team said that would handle what LSA was supposed to be handling. We did create a ticket with VMware to look at the issue at the time, but since this is a 3rd party app, they weren’t very helpful.

1 Like

The authors are planning to compile the AppDeployToolkitMain.cs file to a digitally signed DLL.
This should help with WDAC issues.
It might help your situation, too.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.