Run As Administrator

[mohammedha]

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

[zadjii-msft]

@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?

[mohammedha]

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.

[ghost]

I'm also currently experiencing this issue. I searched for terminal in the taskbar

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:

I just installed the terminal today.

Terminal Version:
Version: 0.2.1831.0

OS Version:
Windows 10 Pro
10.0.18362 Build 18362

[ghost]

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?

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)

[fcharlie]

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.)

[DHowett-MSFT]

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.

[FranklinYu]

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).

[cking22001]

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).

[DHowett-MSFT]

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]

Linking: this is also #1538

[musm]

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

[Arcitec]

@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. :-)

[hudo]

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

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.

[mohammedha]

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

[FranklinYu]

they will raise it with the team.

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

[hudo]

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.

[danstur]

@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.

[DHowett-MSFT]

@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.

[danstur]

@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.

[DHowett-MSFT]

@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. 😄

[SirStumfy]

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

[Mr-Sawyer]

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

[SirStumfy]

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.

[zadjii-msft]

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

[ghost]

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.

[kathodion]

Same here. problem seems not to be solved

[jt-github]

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.

[A9G-Data-Droid]

@jt-github That's like sudo.

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

[jt-github]

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

[BanterBoy]

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.

[smallzeh13]

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.

[clowg]

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 :(

[hsrizvi]

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.

[AndrewLane]

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. 👍

[williamt31]

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.

[eandersons]

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.

[brybalicious]

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

[ntaken]

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).

[zadjii-msft]

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

[ntaken]

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

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

[chrismedinapy]

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

[re4s0n4]

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). :-(

[ZilvinasJonaitis]

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.

[UberKluger]

@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.