Run As Administrator #2639

Closed
opened 2026-01-30 23:00:49 +00:00 by claunia · 52 comments
Owner

Originally created by @mohammedha on GitHub (Jul 8, 2019).

Originally assigned to: @DHowett-MSFT on GitHub.

2019-07-08_14h29_22
2019-07-08_14h29_54

Seems there is an issue running the terminal "As Administrator"

Error: Windows cannot find "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe" Make sure you've typed the name correctly, then try again

Originally created by @mohammedha on GitHub (Jul 8, 2019). Originally assigned to: @DHowett-MSFT on GitHub. ![2019-07-08_14h29_22](https://user-images.githubusercontent.com/4114872/60814245-2aadba80-a18d-11e9-8188-cda6edf362f4.png) ![2019-07-08_14h29_54](https://user-images.githubusercontent.com/4114872/60814275-3a2d0380-a18d-11e9-9bb1-b8f822c82e96.png) Seems there is an issue running the terminal "As Administrator" Error: Windows cannot find "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe" Make sure you've typed the name correctly, then try again
claunia added the Issue-BugResolution-ExternalNeeds-Tag-FixProduct-Terminal labels 2026-01-30 23:00:49 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Jul 8, 2019):

@DHowett-MSFT I could've swore we had a duplicate issue sitting around somewhere for this, but I can't find it now. Do you remember what causes this?

@zadjii-msft commented on GitHub (Jul 8, 2019): @DHowett-MSFT I could've swore we had a duplicate issue sitting around somewhere for this, but I can't find it now. Do you remember what causes this?
Author
Owner

@mohammedha commented on GitHub (Jul 9, 2019):

Ahh man, sorry if it is a duplicate.

there is no reason, start the app fine but r-click and start as admin fails, windows UAC prompt for admin password twice then you get the error.

@mohammedha commented on GitHub (Jul 9, 2019): Ahh man, sorry if it is a duplicate. there is no reason, start the app fine but r-click and start as admin fails, windows UAC prompt for admin password twice then you get the error.
Author
Owner

@ghost commented on GitHub (Jul 11, 2019):

I'm also currently experiencing this issue. I searched for terminal in the taskbar
win-terminal-run-as-admin-issue-1

Then I was prompted to enter my admin credentials twice! One admin prompt after another. Then when I finished entering my credentials the second time this error message popped up:

win-terminal-run-as-admin-issue

I just installed the terminal today.

Terminal Version:
Version: 0.2.1831.0

OS Version:
Windows 10 Pro
10.0.18362 Build 18362

@ghost commented on GitHub (Jul 11, 2019): I'm also currently experiencing this issue. I searched for terminal in the taskbar ![win-terminal-run-as-admin-issue-1](https://user-images.githubusercontent.com/52471106/61085644-c134e280-a3fe-11e9-81e9-d67f0cb518e0.png) Then I was prompted to enter my admin credentials twice! One admin prompt after another. Then when I finished entering my credentials the second time this error message popped up: ![win-terminal-run-as-admin-issue](https://user-images.githubusercontent.com/52471106/61085740-fe997000-a3fe-11e9-87ae-003b50c28611.png) I just installed the terminal today. Terminal Version: Version: 0.2.1831.0 OS Version: Windows 10 Pro 10.0.18362 Build 18362
Author
Owner

@ghost commented on GitHub (Jul 11, 2019):

Also as a suggestion instead of running the WHOLE terminal as admin from the taskbar, perhaps have alternatives?

For example:

When opening a new tab prompt the user or have some UI asking if they want to open the new instance as an administrator?
suggesstion

Or just right click on the terminal to open up a admin tab from the exact same directory. (That would be very useful for powershell-core since it doesn't have nice functionality like sudo)

@ghost commented on GitHub (Jul 11, 2019): Also as a suggestion instead of running the WHOLE terminal as admin from the taskbar, perhaps have alternatives? For example: When opening a new tab prompt the user or have some UI asking if they want to open the new instance as an administrator? ![suggesstion](https://user-images.githubusercontent.com/52471106/61086091-fa218700-a3ff-11e9-836c-60be3129ff02.png) Or just right click on the terminal to open up a admin tab from the exact same directory. (That would be very useful for powershell-core since it doesn't have nice functionality like sudo)
Author
Owner

@fcharlie commented on GitHub (Jul 14, 2019):

Windows Terminal support running in admin mode may not be a good behavior, which means that all shells in other tabs opened from Ctrl+T may be administrator privilege. As far as I know, Windows Terminal does not implement any code from the Administrator to the restricted user. In fact, what Windows lacks is the kind of privilege implementation that does not require UI interaction, like sudo.

But implementing sudo can also be cumbersome. The flow of runas verb is roughly as follows (if anything is wrong, please remind me):

  1. AppInfo goes and talks to the Local Security Authority to get the elevated token of the logged in user of Session 1.
  2. AppInfo loads up a STARTUPINFOEX structure (new to Vista), and calls the brand new Vista API InitializeProcThreadAttributeList() with room for one attribute.
  3. OpenProcess() is called to get a handle to the process that initiated the RPC call.
  4. UpdateProcThreadAttribute() is called with PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, and uses the handle retrieved in step 3.
  5. CreateProcessAsUser() is called with EXTENDED_STARTUPINFO_PRESENT and the results of steps 1 and 4.
  6. DeleteProcThreadAttributeList() is called.
  7. Results are gathered, and handles are cleaned up.

We can draw a simple conclusion. In fact, runas is actually a normal process that initiates an RPC request to a high-privileged process. The high-privilege process (AppInfo service) creates an Administrator process and sets its parent process as a normal process.

AppInfo does not currently support setting up a working directory, input and output (although calling CreateProcessAsUser) when launching the administrator process. This is a problem that needs to be solved to enable sudo support to run in Windows Terminal. (ShellExecuteEx SEE_MASK_NO_CONSOLE not work)

SHELLEXECUTEINFOW:

typedef struct _SHELLEXECUTEINFOW {
  DWORD     cbSize;
  ULONG     fMask;
  HWND      hwnd;
  LPCWSTR   lpVerb;
  LPCWSTR   lpFile;
  LPCWSTR   lpParameters;
  LPCWSTR   lpDirectory;
  int       nShow;
  HINSTANCE hInstApp;
  void      *lpIDList;
  LPCWSTR   lpClass;
  HKEY      hkeyClass;
  DWORD     dwHotKey;
  union {
    HANDLE hIcon;
    HANDLE hMonitor;
  } DUMMYUNIONNAME;
  HANDLE    hProcess;
} SHELLEXECUTEINFOW, *LPSHELLEXECUTEINFOW;

See: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute

Value Meaning
PROC_THREAD_ATTRIBUTE_PARENT_PROCESS The lpValue parameter is a pointer to a handle to a process to use instead of the calling process as the parent for the process being created. The process to use must have the PROCESS_CREATE_PROCESS access right.

Attributes inherited from the specified process include handles, the device map, processor affinity, priority, quotas, the process token, and job object. (Note that some attributes such as the debug port will come from the creating process, not the process specified by this handle.)
@fcharlie commented on GitHub (Jul 14, 2019): Windows Terminal support running in admin mode may not be a good behavior, which means that all shells in other tabs opened from Ctrl+T may be administrator privilege. As far as I know, Windows Terminal does not implement any code from the Administrator to the restricted user. In fact, what Windows lacks is the kind of privilege implementation that does not require UI interaction, like sudo. But implementing sudo can also be cumbersome. The flow of **runas** verb is roughly as follows (if anything is wrong, please remind me): 1. AppInfo goes and talks to the Local Security Authority to get the elevated token of the logged in user of Session 1. 2. AppInfo loads up a STARTUPINFOEX structure (new to Vista), and calls the brand new Vista API InitializeProcThreadAttributeList() with room for one attribute. 3. OpenProcess() is called to get a handle to the process that initiated the RPC call. 4. UpdateProcThreadAttribute() is called with `PROC_THREAD_ATTRIBUTE_PARENT_PROCESS`, and uses the handle retrieved in step 3. 5. CreateProcessAsUser() is called with `EXTENDED_STARTUPINFO_PRESENT` and the results of steps 1 and 4. 6. DeleteProcThreadAttributeList() is called. 7. Results are gathered, and handles are cleaned up. We can draw a simple conclusion. In fact, `runas` is actually a normal process that initiates an RPC request to a high-privileged process. The high-privilege process (AppInfo service) creates an Administrator process and sets its parent process as a normal process. AppInfo does not currently support setting up a working directory, input and output (although calling CreateProcessAsUser) when launching the administrator process. This is a problem that needs to be solved to enable sudo support to run in Windows Terminal. (ShellExecuteEx SEE_MASK_NO_CONSOLE not work) [SHELLEXECUTEINFOW](https://docs.microsoft.com/en-us/windows/win32/api/shellapi/ns-shellapi-shellexecuteinfow): ```c++ typedef struct _SHELLEXECUTEINFOW { DWORD cbSize; ULONG fMask; HWND hwnd; LPCWSTR lpVerb; LPCWSTR lpFile; LPCWSTR lpParameters; LPCWSTR lpDirectory; int nShow; HINSTANCE hInstApp; void *lpIDList; LPCWSTR lpClass; HKEY hkeyClass; DWORD dwHotKey; union { HANDLE hIcon; HANDLE hMonitor; } DUMMYUNIONNAME; HANDLE hProcess; } SHELLEXECUTEINFOW, *LPSHELLEXECUTEINFOW; ``` See: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute |Value | Meaning| |---|---| |**PROC_THREAD_ATTRIBUTE_PARENT_PROCESS**|The lpValue parameter is a pointer to a handle to a process to use instead of the calling process as the parent for the process being created. The process to use must have the PROCESS_CREATE_PROCESS access right.<br><br>Attributes inherited from the specified process include handles, the device map, processor affinity, priority, quotas, the process token, and job object. (Note that some attributes such as the debug port will come from the creating process, not the process specified by this handle.)|
Author
Owner

@DHowett-MSFT commented on GitHub (Jul 15, 2019):

This is definitely a windows platform issue. I'm assigning it to myself to follow up with the team that owns it and close this out. Thanks.

@DHowett-MSFT commented on GitHub (Jul 15, 2019): This is definitely a windows platform issue. I'm assigning it to myself to follow up with the team that owns it and close this out. Thanks.
Author
Owner

@FranklinYu commented on GitHub (Jul 17, 2019):

I like @YMba9g8j9CJp0wLoQf5y’s proposal of authorizing a tab with escalated privilege. I’m from ConEmu where we can create a tab with or without admin privilege. When creating an admin tab I will be prompted with UAC (for good).

@FranklinYu commented on GitHub (Jul 17, 2019): I like @YMba9g8j9CJp0wLoQf5y’s proposal of authorizing a tab with escalated privilege. I’m from ConEmu where we can create a tab with or without admin privilege. When creating an admin tab I will be prompted with UAC (for good).
Author
Owner

@cking22001 commented on GitHub (Jul 17, 2019):

Is this not just normal behavior of Windows store applications? This looks like the Preview app recently released.
But I do need a way to run elevated shells. It does not seem possible to do that today (open tabs as admin).

@cking22001 commented on GitHub (Jul 17, 2019): Is this not just normal behavior of Windows store applications? This looks like the Preview app recently released. But I do need a way to run elevated shells. It does not seem possible to do that today (open tabs as admin).
Author
Owner

@DHowett-MSFT commented on GitHub (Jul 29, 2019):

Hey, we're not sure there's anything we can do about this. Would you mind filing feedback in the "Developer Platform > App Deployment" category? That'll help get it routed to the right team, and collects some very useful diagnostic information.

@DHowett-MSFT commented on GitHub (Jul 29, 2019): Hey, we're not sure there's anything we can do about this. Would you mind filing feedback in the "Developer Platform > App Deployment" category? That'll help get it routed to the right team, and collects some very useful diagnostic information.
Author
Owner

@DHowett-MSFT commented on GitHub (Jul 29, 2019):

Linking: this is also #1538

@DHowett-MSFT commented on GitHub (Jul 29, 2019): Linking: this is also #1538
Author
Owner

@musm commented on GitHub (Oct 28, 2019):

Even though I agree with the decision. It does make it quite painful to use chocolatey without having the explicitly run in admin mode. (

@musm commented on GitHub (Oct 28, 2019): Even though I agree with the decision. It does make it quite painful to use `chocolatey` without having the explicitly run in admin mode. (
Author
Owner

@Arcitec commented on GitHub (Dec 6, 2019):

@musm I just have this in my PowerShell 6 config:

function GoAdmin { start-process pwsh –verb runAs }

(replace pwsh with powershell if you are using the old powershell)

So whenever I need to install/update packages via chocolatey I type GoAdmin (in Windows Terminal's hosted PowerShell), which takes me to a separate Admin powershell window. There I can run all chocolatey admin commands. Then I simply close the admin window, and type refreshenv in my Windows Terminal session to update all PATH variables. It's pretty easy.

I would definitely like a way to launch wt (Windows Terminal) instead of directly going to a "bare" pwsh, but that doesn't seem possible. But it's a minor gripe. Meh. :-)

@Arcitec commented on GitHub (Dec 6, 2019): @musm I just have this in my PowerShell 6 config: `function GoAdmin { start-process pwsh –verb runAs }` (replace `pwsh` with `powershell` if you are using the old powershell) So whenever I need to install/update packages via chocolatey I type `GoAdmin` (in Windows Terminal's hosted PowerShell), which takes me to a separate Admin powershell window. There I can run all chocolatey admin commands. Then I simply close the admin window, and type `refreshenv` in my Windows Terminal session to update all PATH variables. It's pretty easy. I would definitely like a way to launch `wt` (Windows Terminal) instead of directly going to a "bare" pwsh, but that doesn't seem possible. But it's a minor gripe. Meh. :-)
Author
Owner

@hudo commented on GitHub (Feb 20, 2020):

Im still getting an error when I want to start WT (0.9.433.0) as admin:

image

Happens on several machines, with latest WT and Windows (v10.0.18363.657).
Don't quite understand why is this issue closed and what's the workaround.

@hudo commented on GitHub (Feb 20, 2020): Im still getting an error when I want to start WT (0.9.433.0) as admin: ![image](https://user-images.githubusercontent.com/121091/74933268-87d44480-53db-11ea-87d0-cfae31fea9f0.png) Happens on several machines, with latest WT and Windows (v10.0.18363.657). Don't quite understand why is this issue closed and what's the workaround.
Author
Owner

@mohammedha commented on GitHub (Feb 20, 2020):

Actually it never worked, the last comment I got was, it is a Windows issue and they will raise it with the team.

@mohammedha commented on GitHub (Feb 20, 2020): Actually it never worked, the last comment I got was, it is a Windows issue and they will raise it with the team.
Author
Owner

@FranklinYu commented on GitHub (Feb 21, 2020):

they will raise it with the team.

I don’t think so. It’s more like “you should raise it with the team”.

@FranklinYu commented on GitHub (Feb 21, 2020): > they will raise it with the team. I don’t think so. It’s more like “*you* should raise it with the team”.
Author
Owner

@hudo commented on GitHub (Feb 21, 2020):

Im sure they're not thinking of releasing Win Terminal v1 with one of the most important functionality broken.
Too bad since it makes current pre-release versions of WT unusable.

@hudo commented on GitHub (Feb 21, 2020): Im sure they're not thinking of releasing Win Terminal v1 with one of the most important functionality broken. Too bad since it makes current pre-release versions of WT unusable.
Author
Owner

@CraigHead commented on GitHub (Feb 27, 2020):

This will pop a new powershell window with administrator. Not exactly what we want but it's a work around. Create a new profile with the following command line.

"commandline": "powershell.exe -Command \"Start-Process powershell.exe -Verb RunAs\"",

@CraigHead commented on GitHub (Feb 27, 2020): This will pop a new powershell window with administrator. Not exactly what we want but it's a work around. Create a new profile with the following command line. `"commandline": "powershell.exe -Command \"Start-Process powershell.exe -Verb RunAs\"",`
Author
Owner

@A9G-Data-Droid commented on GitHub (Mar 13, 2020):

Why is this closed? There still need to be an elevate tab feature.

@A9G-Data-Droid commented on GitHub (Mar 13, 2020): Why is this closed? There still need to be an elevate tab feature.
Author
Owner

@DHowett-MSFT commented on GitHub (Mar 13, 2020):

This is being tracked in a bunch of other issues on this repository, that's why.

@DHowett-MSFT commented on GitHub (Mar 13, 2020): This is being tracked in a bunch of other issues on this repository, that's why.
Author
Owner

@FranklinYu commented on GitHub (Mar 15, 2020):

@DHowett-MSFT Thanks. Which issue should we follow? I don’t think it’s mentioned above.

@FranklinYu commented on GitHub (Mar 15, 2020): @DHowett-MSFT Thanks. Which issue should we follow? I don’t think it’s mentioned above.
Author
Owner

@mian-muhammad commented on GitHub (Mar 25, 2020):

@musm I just have this in my PowerShell 6 config:

function GoAdmin { start-process pwsh –verb runAs }

(replace pwsh with powershell if you are using the old powershell)

So whenever I need to install/update packages via chocolatey I type GoAdmin (in Windows Terminal's hosted PowerShell), which takes me to a separate Admin powershell window. There I can run all chocolatey admin commands. Then I simply close the admin window, and type refreshenv in my Windows Terminal session to update all PATH variables. It's pretty easy.

I would definitely like a way to launch wt (Windows Terminal) instead of directly going to a "bare" pwsh, but that doesn't seem possible. But it's a minor gripe. Meh. :-)

In windows where is this config file located?

@mian-muhammad commented on GitHub (Mar 25, 2020): > @musm I just have this in my PowerShell 6 config: > > `function GoAdmin { start-process pwsh –verb runAs }` > > (replace `pwsh` with `powershell` if you are using the old powershell) > > So whenever I need to install/update packages via chocolatey I type `GoAdmin` (in Windows Terminal's hosted PowerShell), which takes me to a separate Admin powershell window. There I can run all chocolatey admin commands. Then I simply close the admin window, and type `refreshenv` in my Windows Terminal session to update all PATH variables. It's pretty easy. > > I would definitely like a way to launch `wt` (Windows Terminal) instead of directly going to a "bare" pwsh, but that doesn't seem possible. But it's a minor gripe. Meh. :-) In windows where is this config file located?
Author
Owner

@FranklinYu commented on GitHub (Apr 2, 2020):

@mian-muhammad I think he meant PowerShell profile. https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles

@FranklinYu commented on GitHub (Apr 2, 2020): @mian-muhammad I think he meant PowerShell profile. https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles
Author
Owner

@Steffen-Jens commented on GitHub (Apr 17, 2020):

I found a workaround. You can use chocolatey to install a package called sudo (choco install -y sudo). Then you can use sudo as expected.

@Steffen-Jens commented on GitHub (Apr 17, 2020): I found a workaround. You can use chocolatey to install a package called sudo (choco install -y sudo). Then you can use sudo as expected.
Author
Owner

@FranklinYu commented on GitHub (Apr 19, 2020):

It seems like I can currently open the terminal as administrator; at least it works on my machine. It would be even better if we can create a tab as administrator like ConEmu (which is discussed in #632), but there is currently no point to re-open this issue.

Other related pending feature requests:

  • #146 sudo which @Pens99 might be interested in
  • #576 task bar jumplist; I regard this as substitution of #632 due to security implication (which I fully understand coming from security industry), especially when combined with #3246.

Hope this help everyone following this thread.

@FranklinYu commented on GitHub (Apr 19, 2020): It seems like I can currently open the terminal as administrator; at least it works on my machine. It would be even better if we can create a tab as administrator like ConEmu (which is discussed in #632), but there is currently no point to re-open this issue. Other related pending feature requests: - #146 `sudo` which @Pens99 might be interested in - #576 task bar jumplist; I regard this as substitution of #632 due to security implication (which I fully understand coming from security industry), especially when combined with #3246. Hope this help everyone following this thread.
Author
Owner

@danstur commented on GitHub (Apr 28, 2020):

@DHowett-MSFT Which issue should we follow and star to get this resolved? The only other referenced issue I can see is #1538 which is also closed.

I'm sure Microsoft's stance can't be that everybody should have administrative rights on their standard user instead of using a separate admin account if they want to use modern Windows apps. This is after all contrary to standard security practices.

@danstur commented on GitHub (Apr 28, 2020): @DHowett-MSFT Which issue should we follow and star to get this resolved? The only other referenced issue I can see is #1538 which is also closed. I'm sure Microsoft's stance can't be that everybody should have administrative rights on their standard user instead of using a separate admin account if they want to use modern Windows apps. This is after all contrary to standard security practices.
Author
Owner

@DHowett-MSFT commented on GitHub (May 2, 2020):

@danstur Best I can offer for that concern is #4217. We're pursuing a fix with the team who owns app deployment. The issue is that apps are installed globally, but only registered per-user. This was some infrastructure that was built for Windows 8 that has only very slowly evolved to support even running standard win32 applications like Terminal. #1386 tracks us getting out of the package and distributing as something more traditional for enterprise customers and folks who are having trouble with the package deployment engine.

@DHowett-MSFT commented on GitHub (May 2, 2020): @danstur Best I can offer for that concern is #4217. We're pursuing a fix with the team who owns app deployment. The issue is that apps are _installed_ globally, but only registered per-user. This was some infrastructure that was built for Windows 8 that has only very slowly evolved to support even running standard win32 applications like Terminal. #1386 tracks us getting out of the package and distributing as something more traditional for enterprise customers and folks who are having trouble with the package deployment engine.
Author
Owner

@danstur commented on GitHub (May 4, 2020):

@DHowett-MSFT Thanks for the issues, glad to hear that it's being tracked.

To clarify: If I install the application via the options mentioned in #1386 will I then be able to run it as a different user or would that still not work? I wouldn't mind having to register the app (does that mean running Add-AppxPackage?) with the other users.

@danstur commented on GitHub (May 4, 2020): @DHowett-MSFT Thanks for the issues, glad to hear that it's being tracked. To clarify: If I install the application via the options mentioned in #1386 will I then be able to run it as a different user or would that still not work? I wouldn't mind having to register the app (does that mean running `Add-AppxPackage`?) with the other users.
Author
Owner

@DHowett-MSFT commented on GitHub (May 5, 2020):

@DHowett-MSFT Dustin Howett FTE Thanks for the issues, glad to hear that it's being tracked.

To clarify: If I install the application via the options mentioned in #1386 will I then be able to run it as a different user or would that still not work? I wouldn't mind having to register the app (does that mean running Add-AppxPackage?) with the other users.

That should work fine. You'll need to Add-AppxPackage as those users, yes. 😄

@DHowett-MSFT commented on GitHub (May 5, 2020): > @DHowett-MSFT Dustin Howett FTE Thanks for the issues, glad to hear that it's being tracked. > > To clarify: If I install the application via the options mentioned in #1386 will I then be able to run it as a different user or would that still not work? I wouldn't mind having to register the app (does that mean running `Add-AppxPackage`?) with the other users. That should work fine. You'll need to Add-AppxPackage as those users, yes. :smile:
Author
Owner

@SirStumfy commented on GitHub (May 21, 2020):

Glad to see its being tacked.

This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store

@SirStumfy commented on GitHub (May 21, 2020): Glad to see its being tacked. This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store
Author
Owner

@Mr-Sawyer commented on GitHub (May 22, 2020):

Glad to see its being tacked.

This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store

A workaround that worked for me was logging in as the admin user in the local machine and "install" again the terminal from the Store. Then, when logged as a standard user, I could run the terminal as an administrator

@Mr-Sawyer commented on GitHub (May 22, 2020): > > > Glad to see its being tacked. > > This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store A workaround that worked for me was logging in as the admin user in the local machine and "install" again the terminal from the Store. Then, when logged as a standard user, I could run the terminal as an administrator
Author
Owner

@SirStumfy commented on GitHub (May 23, 2020):

Yes the problem seems to be Store registers the app for current user only. That is fine for most apps (actually thats how most apps should be installed anyway) but is not good for administrative apps like terminals.

@SirStumfy commented on GitHub (May 23, 2020): Yes the problem seems to be Store registers the app for current user only. That is fine for most apps (actually thats how most apps should be installed anyway) but is not good for administrative apps like terminals.
Author
Owner

@zadjii-msft commented on GitHub (May 26, 2020):

Hey future me: the store registration issue is being tracked internally with MSFT:20356613 and discussed at length in #4217

@zadjii-msft commented on GitHub (May 26, 2020): Hey future me: the store registration issue is being tracked internally with MSFT:20356613 and discussed at length in #4217
Author
Owner

@ghost commented on GitHub (Jul 1, 2020):

Hello,
I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account.

@ghost commented on GitHub (Jul 1, 2020): Hello, I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account.
Author
Owner

@kathodion commented on GitHub (Jul 2, 2020):

Same here. problem seems not to be solved

@kathodion commented on GitHub (Jul 2, 2020): Same here. problem seems not to be solved
Author
Owner

@jt-github commented on GitHub (Jul 8, 2020):

I have yet another less-than-perfect workaround which doesn't allow opening a tab running as administrator, but it does allow opening a PowerShell window as Administrator from an existing (non-admin) tab:

https://github.com/jt-github/elevate

This works the same way as adding the profile as suggested by @CraigHead above:
"commandline": "powershell.exe -Command \"Start-Process powershell.exe -Verb RunAs\"",

Except that my my version is executed by running the elevate command.

@jt-github commented on GitHub (Jul 8, 2020): I have yet another less-than-perfect workaround which doesn't allow opening a _tab_ running as administrator, but it does allow opening a PowerShell window as Administrator from an existing (non-admin) tab: https://github.com/jt-github/elevate This works the same way as adding the profile as suggested by @CraigHead above: `"commandline": "powershell.exe -Command \"Start-Process powershell.exe -Verb RunAs\"",` Except that my my version is executed by running the `elevate` command.
Author
Owner

@A9G-Data-Droid commented on GitHub (Jul 8, 2020):

@jt-github That's like sudo.

See here: https://github.com/pldmgg/Sudo

@A9G-Data-Droid commented on GitHub (Jul 8, 2020): @jt-github That's like sudo. See here: https://github.com/pldmgg/Sudo
Author
Owner

@jt-github commented on GitHub (Jul 8, 2020):

Exactly, only sudo is way cooler than mine but mine is so dead simple that it's easy to understand and use.

@jt-github commented on GitHub (Jul 8, 2020): Exactly, only `sudo` is way cooler than mine but mine is so dead simple that it's easy to understand and use.
Author
Owner

@BanterBoy commented on GitHub (Aug 14, 2020):

Like many of you, I have also run into this issue, so I created the following functions in order to open an Admin shell from either powershell.exe, pwsh.exe or Microsoft terminal


# Function        Test-IsAdmin
function Test-IsAdmin {
	<#
	.Synopsis
	Tests if the user is an administrator
	.Description
	Returns true if a user is an administrator, false if the user is not an administrator
	.Example
	Test-IsAdmin
	#>
	$identity = [Security.Principal.WindowsIdentity]::GetCurrent()
	$principal = New-Object Security.Principal.WindowsPrincipal $identity
	$principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
}


# Function        New-AdminShell
function New-AdminShell {
	<#
	.Synopsis
	Starts an Elevated PowerShell Console.

	.Description
	Opens a new PowerShell Console Elevated as Administrator. If the user is already running an elevated
	administrator shell, a message is displayed in the console session.

	.Example
	New-AdminShell

	#>

	$Process = Get-Process | Where-Object { $_.Id -eq "$($PID)" }
	if (Test-IsAdmin = $True) {
		Write-Warning -Message "Admin Shell already running!"
	}
	else {
		if ($Process.Name -eq "powershell") {
			Start-Process -FilePath "powershell.exe" -Verb runas -PassThru
		}
		if ($Process.Name -eq "pwsh") {
			Start-Process -FilePath "pwsh.exe" -Verb runas -PassThru
		}
	}
}

# Function        New-AdminTerminal
function New-AdminTerminal {
	<#
	.Synopsis
	Starts an Elevated Microsoft Terminal.

	.Description
	Opens a new Microsoft Terminal Elevated as Administrator. If the user is already running an elevated
	Microsoft Terminal, a message is displayed in the console session.

	.Example
	New-AdminShell

	#>

	if (Test-IsAdmin = $True) {
		Write-Warning -Message "Admin Shell already running!"
	}
	else {
		Start-Process "wt.exe" -ArgumentList "-p pwsh" -Verb runas -PassThru
	}
}

I hope someone finds them useful. I have added them to my PowerShell Profiles, so they are always available.

@BanterBoy commented on GitHub (Aug 14, 2020): Like many of you, I have also run into this issue, so I created the following functions in order to open an Admin shell from either powershell.exe, pwsh.exe or Microsoft terminal ```powershell # Function Test-IsAdmin function Test-IsAdmin { <# .Synopsis Tests if the user is an administrator .Description Returns true if a user is an administrator, false if the user is not an administrator .Example Test-IsAdmin #> $identity = [Security.Principal.WindowsIdentity]::GetCurrent() $principal = New-Object Security.Principal.WindowsPrincipal $identity $principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator) } # Function New-AdminShell function New-AdminShell { <# .Synopsis Starts an Elevated PowerShell Console. .Description Opens a new PowerShell Console Elevated as Administrator. If the user is already running an elevated administrator shell, a message is displayed in the console session. .Example New-AdminShell #> $Process = Get-Process | Where-Object { $_.Id -eq "$($PID)" } if (Test-IsAdmin = $True) { Write-Warning -Message "Admin Shell already running!" } else { if ($Process.Name -eq "powershell") { Start-Process -FilePath "powershell.exe" -Verb runas -PassThru } if ($Process.Name -eq "pwsh") { Start-Process -FilePath "pwsh.exe" -Verb runas -PassThru } } } # Function New-AdminTerminal function New-AdminTerminal { <# .Synopsis Starts an Elevated Microsoft Terminal. .Description Opens a new Microsoft Terminal Elevated as Administrator. If the user is already running an elevated Microsoft Terminal, a message is displayed in the console session. .Example New-AdminShell #> if (Test-IsAdmin = $True) { Write-Warning -Message "Admin Shell already running!" } else { Start-Process "wt.exe" -ArgumentList "-p pwsh" -Verb runas -PassThru } } ``` I hope someone finds them useful. I have added them to my PowerShell Profiles, so they are always available.
Author
Owner

@smallzeh13 commented on GitHub (Aug 27, 2020):

Hello,
I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account.

This worked for me as well, its super annoying but on a corp network thats pretty much the only way that has worked for me. If you don't have local admin this app is pretty much a bust for elevated privs on a corp network.

@smallzeh13 commented on GitHub (Aug 27, 2020): > > > Hello, > I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account. This worked for me as well, its super annoying but on a corp network thats pretty much the only way that has worked for me. If you don't have local admin this app is pretty much a bust for elevated privs on a corp network.
Author
Owner

@clowg commented on GitHub (Sep 7, 2020):

Glad to see its being tacked.
This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store

A workaround that worked for me was logging in as the admin user in the local machine and "install" again the terminal from the Store. Then, when logged as a standard user, I could run the terminal as an administrator

Nah, that didn't work for me :(

@clowg commented on GitHub (Sep 7, 2020): > > > > Glad to see its being tacked. > > This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store > > A workaround that worked for me was logging in as the admin user in the local machine and "install" again the terminal from the Store. Then, when logged as a standard user, I could run the terminal as an administrator Nah, that didn't work for me :(
Author
Owner

@hsrizvi commented on GitHub (Sep 8, 2020):

So i figured it out.

You have to have it installed in BOTH the administrator account and also in the main account, but also the administrative account must be signed in for it to work. By this, i mean that the computer has to be logged into administrator, then switch the user (not sign out) and log into the other account. This will allow the app to run in administrator mode.

I'm guessing store apps installed on both accounts cannot be run as administrator unless an administrator account is logged into.

@hsrizvi commented on GitHub (Sep 8, 2020): So i figured it out. You have to have it installed in BOTH the administrator account and also in the main account, but also the administrative account must be signed in for it to work. By this, i mean that the computer has to be logged into administrator, then switch the user (not sign out) and log into the other account. This will allow the app to run in administrator mode. I'm guessing store apps installed on both accounts cannot be run as administrator unless an administrator account is logged into.
Author
Owner

@AndrewLane commented on GitHub (Sep 23, 2020):

So i figured it out.

You have to have it installed in BOTH the administrator account and also in the main account, but also the administrative account must be signed in for it to work. By this, i mean that the computer has to be logged into administrator, then switch the user (not sign out) and log into the other account. This will allow the app to run in administrator mode.

I'm guessing store apps installed on both accounts cannot be run as administrator unless an administrator account is logged into.

This works for me. 👍

@AndrewLane commented on GitHub (Sep 23, 2020): > So i figured it out. > > You have to have it installed in BOTH the administrator account and also in the main account, but also the administrative account must be signed in for it to work. By this, i mean that the computer has to be logged into administrator, then switch the user (not sign out) and log into the other account. This will allow the app to run in administrator mode. > > I'm guessing store apps installed on both accounts cannot be run as administrator unless an administrator account is logged into. This works for me. 👍
Author
Owner

@williamt31 commented on GitHub (Jan 30, 2021):

Still having the issue documented above. Tried current 1.5x and preview 1.6 as of today and either I get one UAC cred prompt and nothing happens or two cred prompts and an error like screenshot-ted above saying couldn't find file.
Note, I'm not even going to try the fix listed just above. The whole reason I have UAC setup is so that I DON'T login with administrator unless I have to fix my regular account. I'm most certainly not going to leave a profile running just so I can try a new terminal. If it gets fixed, I'll come back and try again.

@williamt31 commented on GitHub (Jan 30, 2021): Still having the issue documented above. Tried current 1.5x and preview 1.6 as of today and either I get one UAC cred prompt and nothing happens or two cred prompts and an error like screenshot-ted above saying couldn't find file. Note, I'm not even going to try the fix listed just above. The whole reason I have UAC setup is so that I DON'T login with administrator unless I have to fix my regular account. I'm most certainly not going to leave a profile running just so I can try a new terminal. If it gets fixed, I'll come back and try again.
Author
Owner

@eandersons commented on GitHub (Jan 30, 2021):

I am currently not on Windows so I cannot double check this, but if I recall correctly I could run Terminal as an administrator without logging into administrative profile. Only thing I had to do once to be able to run Terminal as a privileged user was installing it in administrator account.

@eandersons commented on GitHub (Jan 30, 2021): I am currently not on Windows so I cannot double check this, but if I recall correctly I could run Terminal as an administrator without logging into administrative profile. Only thing I had to do once to be able to run Terminal as a privileged user was installing it in administrator account.
Author
Owner

@brybalicious commented on GitHub (Feb 18, 2021):

This is awesome - adds registry keys to run any of the Windows Terminal shells as administrator, from the right-click context menu in Windows File Explorer

@brybalicious commented on GitHub (Feb 18, 2021): [This](https://github.com/kerol2r20/Windows-terminal-context-menu) is awesome - adds registry keys to run any of the Windows Terminal shells as administrator, from the right-click context menu in Windows File Explorer
Author
Owner

@ntaken commented on GitHub (Mar 29, 2021):

Do not think that this issue should be considered closed. It really limits the usefulness of windows terminal in a corporate environment (where you have a user account and one administrator account).

@ntaken commented on GitHub (Mar 29, 2021): Do not think that this issue should be considered closed. It really limits the usefulness of windows terminal in a corporate environment (where you have a user account and one administrator account).
Author
Owner

@zadjii-msft commented on GitHub (Mar 29, 2021):

@ntaken The thread that's following that subject most closely these days is #4217.

@zadjii-msft commented on GitHub (Mar 29, 2021): @ntaken The thread that's following that subject most closely these days is #4217.
Author
Owner

@ntaken commented on GitHub (Mar 29, 2021):

@ntaken The thread that's following that subject most closely these days is #4217.

Thanks. I get lost in the GitHub forest sometimes...

@ntaken commented on GitHub (Mar 29, 2021): > @ntaken The thread that's following that subject most closely these days is #4217. Thanks. I get lost in the GitHub forest sometimes...
Author
Owner

@chrismedinapy commented on GitHub (Apr 15, 2021):

Hello,
I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account.

This actually help me!.. very nice work around

@chrismedinapy commented on GitHub (Apr 15, 2021): > > > Hello, > I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account. This actually help me!.. very nice work around
Author
Owner

@re4s0n4 commented on GitHub (Apr 25, 2021):

I think everyone is missing the point. At the top someone mentioned installing with Chocolatey. I have this same problem. I believe it's because my workstation is quite long in the tooth. It's been through a few feature updates, and a while back I tried to compile a early iteration from source. Then I uninstalled it for whatever reason and tried to install it with Chocolatey. One thing let to another and probably encountered the elevation issue you all are talking about. I think there are some artifacts from previous installs causing the problem, but I don't know of a registry key, or appdata folder I can wipe out. I thought it was simply a biproduct of being a Store App (Appx), like you were all saying. Store installs in user context. After talking to people on Twitter (Jeff Hicks I think), I spun up a brand new vm and installed WT from the store. Elevation works just fine. Unless anyone here has any bright ideas, I have reserved myself to biting the bullet and rebuilding my workstation, but never a great time for that. So at the moment I cannot use the new hotness (Windows Terminal). :-(

@re4s0n4 commented on GitHub (Apr 25, 2021): I think everyone is missing the point. At the top someone mentioned installing with Chocolatey. I have this same problem. I believe it's because my workstation is quite long in the tooth. It's been through a few feature updates, and a while back I tried to compile a early iteration from source. Then I uninstalled it for whatever reason and tried to install it with Chocolatey. One thing let to another and probably encountered the elevation issue you all are talking about. I think there are some artifacts from previous installs causing the problem, but I don't know of a registry key, or appdata folder I can wipe out. I thought it was simply a biproduct of being a Store App (Appx), like you were all saying. Store installs in user context. After talking to people on Twitter (Jeff Hicks I think), I spun up a brand new vm and installed WT from the store. Elevation works just fine. Unless anyone here has any bright ideas, I have reserved myself to biting the bullet and rebuilding my workstation, but never a great time for that. So at the moment I cannot use the new hotness (Windows Terminal). :-(
Author
Owner

@ZilvinasJonaitis commented on GitHub (May 22, 2021):

Hello,
I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account.

This actually help me!.. very nice work around

Did not work for me. However, I have found another work around.

Run Windows built-in PowerShell as Administrator (Win+X, A) and leave it open, then run Windows Terminal as Administrator. If no need, one can exit original PowerShell session.

@ZilvinasJonaitis commented on GitHub (May 22, 2021): > > > > Hello, > > I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account. > > This actually help me!.. very nice work around Did not work for me. However, I have found another work around. Run Windows built-in PowerShell as Administrator (Win+X, A) and leave it open, then run Windows Terminal as Administrator. If no need, one can exit original PowerShell session.
Author
Owner

@UberKluger commented on GitHub (Jun 9, 2021):

@BanterBoy
The line

if (Test-IsAdmin = $True)

had me wondering if powershell syntax had changed or maybe it was just a typo (yes, I am your 1 confused 😕). It took me a while to realise that it was neither. Though the definition of Test-IsAdmin has no parameters, there is nothing stopping parameters being supplied and then ignored. So the line is effectively

if (Test-IsAdmin)

with a clever little reminder about what type is being returned. This comment is basically an explanation for anybody else who might be wondering about it (or maybe it's just me).

Though I appreciate the benefits of self-documenting code, the use of a personal mnemonic (I can't remember seeing it before) that, to a casual observer, seems like a syntax error might be better avoided on public forums, particularly where code snippets tend to be short. In this case, Test-IsAdmin was defined (and its return value well described) less than 1/2 a page before, so a localised reminder about what it returns didn't provide much improved clarity but the form of the reminder was actually a bit of a distraction (at least it was for me). So the 😕 isn't a mark of disapproval, more of a 'Hmm, I wonder what's happening here. What am I missing?' (the sort of thing that could itself end up as a question on stack overflow). Maybe a 🤔 (thinking) would have been better. After all, I did learn something.

@UberKluger commented on GitHub (Jun 9, 2021): @BanterBoy The line > if (Test-IsAdmin = $True) had me wondering if powershell syntax had changed or maybe it was just a typo (yes, I am your 1 confused :confused:). It took me a while to realise that it was neither. Though the definition of `Test-IsAdmin` has no parameters, there is nothing stopping parameters being supplied and then ignored. So the line is effectively > if (Test-IsAdmin) with a clever little reminder about what type is being returned. This comment is basically an explanation for anybody else who might be wondering about it (or maybe it's just me). Though I appreciate the benefits of self-documenting code, the use of a personal mnemonic (I can't remember seeing it before) that, to a casual observer, *seems like* a syntax error might be better avoided on public forums, particularly where code snippets tend to be short. In this case, `Test-IsAdmin` was defined (and its return value well described) less than 1/2 a page before, so a localised reminder about what it returns didn't provide much improved clarity but the form of the reminder was actually a bit of a distraction (at least it was for me). So the :confused: isn't a mark of disapproval, more of a 'Hmm, I wonder what's happening here. What am I missing?' (the sort of thing that could itself end up as a question on stack overflow). Maybe a :thinking: (*thinking*) would have been better. After all, I did learn something.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#2639