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.
Problems
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.
Solutions
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.
Instructions:
- Close Windows Terminal.
- Move the existing settings file from the user account where you customized it to your preferred location (which we’ll call
TARGETPATH\settings.json
). - Delete the settings file in the user profile of the account where you didn’t customize it.
- 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"
Notes:
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
overmklink
. - 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:).
1 Comment
I could create the symlink using my admin account but when I try doing it with my user account, I get the following message: Cannot create a file when that file already exists.
I tried both ways with admin command prompt and non-admin.