by: Helge, published: Jul 25, 2022, in

Windows Terminal as Standard User With Dedicated Admin Account

Feature-wise, Windows Terminal is a fantastic replacement for the dated console host. It presents entirely new problems, however, in a secure setup with a standard user for day-to-day operations and a separate admin account for tasks that require elevation.

This app can’t open

If you expect Windows Terminal to behave like any other application, you might get the following error:

The application cannot be started for the target user. Please login as the user and explicitly install this package.


Terminal Cannot Be Installed per Machine (for All Users)

As an MSIX application, Windows Terminal can only be installed per user. There is no per-machine (AKA, all users) installation option, which really is a shame and poses multiple problems. In our scenario, we’re primarily concerned with the following:

The default installation type is via Windows Store, which is also the only way to keep Terminal updated automatically. Windows Store apps are always installed per user. If you install a Store app from your standard user, it won’t be available in your admin account.

More Information

There are two feature requests for a per-machine installation of Windows Terminal that I’m aware of:

If you’re provisioning a Windows image, you can preinstall Windows Terminal with the PowerShell cmdlet Add-AppXProvisionedPackage. This provisions the package so that any user logging into the machine will have the installation registered for them.

Hard-Coded Settings File Location

Where is the Settings File Located?

The location of the Windows Terminal settings file is hard-coded (not a great design choice). The exact location depends on the app variant you installed, but it’s always in the user profile:

  • Stable release: %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json
  • Preview release: %LOCALAPPDATA%\Packages\Microsoft.WindowsTerminalPreview_8wekyb3d8bbwe\LocalState\settings.json
  • GitHub release: %LOCALAPPDATA%\Microsoft\Windows Terminal\settings.json

Settings Per Machine Required

Why is it a problem that there is an individual per-user settings file whose location cannot (easily) be changed? Consider our scenario: we want to use Windows Terminal from two different user accounts, a standard user and an admin user, both of which have individual user profiles.

Terminal is one of those apps where many people lovingly fine-tune the app’s appearance and behavior, all of which goes into the settings file. Once you’ve done that for your standard user, you probably don’t want to repeat the process for your admin account. And you definitely don’t want to manually sync any future change to and fro.

What we really need is a single settings file in a location we can configure, e.g., per machine. Once we’re at it, we might put the file in a location synced to the cloud so we have it available on all our machines.


Installation Per User

We cannot do anything about the fact that Windows Terminal, as an MSIX app, is installed per user. Once you have installed it for your standard user, you need to log on with your admin account and install it – again.

Changing the Location of the Windows Terminal Settings File

Windows Terminal expects its settings file in a specific location, there’s nothing we can do about that. To change the location of the Terminal settings file, we’ll make use of a little trick: we move the file to any location we want and create a symbolic (or, alternatively, hard) link from the original to the new location.


  1. Close Windows Terminal.
  2. Move the existing settings file from the user account where you customized it to your preferred location (which we’ll call TARGETPATH\settings.json).
  3. Delete the settings file in the user profile of the account where you didn’t customize it.
  4. Run the following command for 1) the standard user and 2) the admin account to create a symbolic link from the default to the new location:
    mklink "%LOCALAPPDATA%\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json" "TARGETPATH\settings.json"


  • mklink requires admin rights.
  • Adjust the source path in the mklink command according to the app variant you installed (see above).
  • PowerShell enthusiasts might prefer New-Item -ItemType SymbolicLink over mklink.
  • You can use a hard link instead of a symbolic link, but keep in mind that hard links don’t work across drives (e.g., not from C: to D:).

Previous Article Windows 11: How To Configure Secure DNS (DoH) for All WiFi Networks
Next Article Identifying MS Teams Application Instances & Counting App Starts