I’ve noticed if using a mapped drive letter as a different user (say an admin account) the UAC prompt will pop up when trying to run deploy-application.exe, but then fail to re-load with the admin token. If using a UNC path this is not an issue. Seems to only be when mapping a drive.
Has this been reported/addressed?
This is actually a UAC feature.
With an Admin account you get 2 security tokens.
When you map the drive letter UN-elevated, you use your “user” token
When you elevate, you use your “Admin” security token.
While elevated you do not have access to your user token and all the things it has access to; Like your mapped drive. and vice versa. It’s like having 2 accounts.
Ok…maybe I haven’t described the issue well enough.
The mapped drive would be mapped using the admin credentials, as the admin account is the one that has access to the location mapped. So, it would be the same credentials, but after prompting to elevate Deploy-Application.exe as administrator (again, same creds as the mapped drive, so same user) the Deploy-Application.exe does not continue to run.
To re-create the issue:
Using UNC path as the admin account - double click Deploy-Application.exe - enter creds at UAC prompt - Deploy-Application.exe runs properly.
Mapped drive as the same admin account - double click Deploy-Application.exe - enter creds at UAC prompt - Deploy-Application.exe does not appear to run after providing credentials.
When you do your “Mapped Drive” example, you authenticate when you mapped the drive letter.
That’s why you do not get prompted when you launch Deploy-Application.exe
My initial thought is that the problem lies in the difference between
Deploy-Application.EXE calling your
Deploy-Application.PS1 script from a UNC path versus calling it from a mapped drive letter. Perhaps the script can’t be found and the behavior for “Script file not found” is different depending on your path (UNC vs. drive letter).
By default, the EXE is designed to look for the PS1 in the same dir; does that file exist in the same dir as the EXE? Did you rename it?
You say “…doesn’t seem to run…”. I would suggest confirming whether the PS script is being run at all by replacing the normal commands in your script with nothing more than some simple troubleshooting cmds. Just write out some lines to a log file. You could even replace the entire script with one containing only this:
$a = new-object -comobject wscript.shell
$a.popup("Deploy-Application.ps1 was found.",0,"Found or Not Found",1)
If still stuck, use Sysinternals’ ProcMon64.exe to capture and compare just what
Deploy-Application.exe is doing (UNC) versus what it’s not doing (drive letter).
That makes sense…good idea for the test thanks!
File is definitely in the same directory
That’s normal. You can use this workaround. I used the one with registry key
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.