Alright listen here - I don’t like the implication that the Terminal is some sort of data harvesting shitware that we’re pushing on developers to track their every keystroke. It’s not. Go look at the code. It’s all right there out in the open. The “telemetry” we gather is shit like “how long it takes to load the settings”, or “is anyone actually using the command palette?”. We as a team have been pushing really hard to do this project out in the open for years, and I think it’s been a huge success. We’ve had great contributions from the community. I’ve really loved working directly with our users - I feel like with the OSS Terminal we can react to user feedback in real-time, and that’s been amazing.

But if you want to disparage this project that we’ve spent the last two years working our asses off on, I’m gonna call you the fuck out on it.

When you install the signed msix bundle from us, it’s signed to say “yep, this app from Microsoft is actually signed by Microsoft”. Then, when you try installing it, the OS goes “hol up, this thing from ‘Microsoft’? Let’s just check real quick to make sure that it actually is from Microsoft”. Cause turns out, people are totally willing to checkout the code, build it, and ship their own msix of our code. And maybe one of those people actually is malicious, adds some actual code to fuck-your-shit.exe and signs the code with a fake “Microsoft” cert. It’s actually a good idea to have your PC check to make sure that Microsoft signed code is actually from Microsoft.

It is not our job to circumvent your IT department’s shitty GPO policies. I would love for more people in more places to be able to run the Terminal. We chose MSIX and the Store because we believed that it was the right way forward. It’s the “modern” deployment stack, so it should be better… Clearly it has its own shortcomings. Fortunately, the Terminal provides an excellent study for the MSIX and Store teams to help get their ducks in a row. More apps are moving to MSIX every year, and the Terminal is helping highlight where the deployment pipelines need some help. We’ve got internal threads moving on the subject, but that’s about all I can say in the matter. I’m not a deployment expert. I’m just here to build the best goddamn terminal emulator on the planet.

Now, this thread has my blood pressure way to high for 5am before coffee. I’m gonna lock it to let it cool down, and we can resume this discussion next week.

Workaround until this is fixed:

• rename foo.msixbundle to zip
• extract until it to a known location
• local the executable
• pin it to the TaskBar
• Add to PATH if you’d like …
• run it from this folder not anywhere else

the one in C:\Pro...\WindowsApp is restricted … from a good reason it seems, I manually overriden this folder to access it … it;s a terrible and bad idea for security and integrity reason of your computer and possible sensitive application in there. Also every time you update that subfolder will change at it will break the pin in the TaskBar

To add a datapoint: the unzipping of the package workaround works for me. OS: Microsoft Windows 10 Pro N version 10.0.19041

1. downloaded wsixbundle from https://github.com/microsoft/terminal/releases
2. extracted Microsoft.WindowsTerminal_1.1.1671.0_8wekyb3d8bbwe.msixbundle to a folder with 7-zip
3. opened that folder in explorer
4. extracted CascadiaPackage_1.1.1671.0_x64.msix to another folder with 7-zip
5. opened that folder in explorer
6. ran WindowsTerminal.exe without issue

“Microsoft Account Sign-in Assistant” service is set to “Manual” on my system and was not running before execution of WindowsTerminal.exe and it was still not running afterwards.

Awesome analysis. Unfortunately not everyone can whitelist, especially if the network is completely disconnected. So the fix here is to remove online activation. The app license shouldn’t be needed when this is a FOSS app. We’re not activating a paid product so there should be no activation needed.

Hello,

I hit the same error today when installing this app behind a very restrictive firewall. I also noticed that this error (“The network location cannot be reached…”) happens on other Microsoft Store apps, that are not installed by default on Windows 10.

On a fresh virtual machine, that is also behind the firewall, the problem is the same. But if I let the VM have a direct internet connection without any firewall, then everything works as expected and the app launches. Then I switched the firewall back on and got another error. This one is described in #2555.

I analysed the network traffic of the VM and noticed that on every start of a Microsoft Store app there’s a request to the domain licensing.mp.microsoft.com. According to https://docs.microsoft.com/en-us/windows/privacy/windows-endpoints-20h2-non-enterprise-editions#windows-10-pro this domain is used for online activation and app licensing.

After adding the mentioned domain to the firewall whitelist, the manual installed Microsoft Store apps launch also on my workstation.

Maybe this helps someone 😃

We’re actively discussing this with the licensing team, and in the interim we’ve released a preinstallation kit that an administrator (sorry: admins only right now ☹️) can use to install Terminal with a hardcoded license. This should remove the need for an online exchange.

Awesome analysis. Unfortunately not everyone can whitelist, especially if the network is completely disconnected. So the fix here is to remove online activation. The app license shouldn’t be needed when this is a FOSS app. We’re not activating a paid product so there should be no activation needed.

Yeah- if we could do that, we would have already.

@miketheitguy Fortunately, we just fixed the wt.exe issue (in #6860) such that the WT directory can be added to your path and you’ll get roughly the same behavior. As for the font … yeah, distributing it inside the package is a terribly unfortunate choice we’ve made and need to slowly un-spool. 😄

If you have them, please make them available in the Store at least, so that business can at least distribute it offline. As it stands now, I can not deploy this to users who want it (for example, on network segmented administrative workstations with no internet / store access).

As the original poster of this issue I just want to report that in my case, extracting the contents of the msixbundle by making it a zip worked for me and I can launch WindowsTerminal.exe now. Just for clarity as I don’t think the “workaround” instructions mentioned it but after you rename the msixbundle to .zip and open it, inside were several “.msix” and other files. You then have to pick the correct msix file for your system, and open it as a zip file and THEN you will get all of the files needed to extract and run WindowsTerminal.exe.

Obviously it’s a shame that any of that is required but I’m glad it works. Thanks for digging into this @DHowett . It really does seem like it’s hard to tell if the problem lies with something you guys are doing or the way Windows in general works so I don’t envy the position you are in trying to track this down. I hope that you share details as to what was causing it when you find them and not just release a fix because I have a feeling that it could help me and others resolve strangeness we may have with other Microsoft software running offline such as the PowerShellCore startup delay that @JasonFossen pointed out.

I tried running WindowsTerminal from the start menu and when I tried to launch it I saw the following dialog

Try to navigate to the file location using a cmd console I can’t access it using an admin account

Is this the expected behavior?

My company blocks the Microsoft Store so I had to download the 1.0 release from the guthub location (https://github.com/microsoft/terminal/releases). Once installed I launched application. I see the same error as @ttutko is seeing. Not sure if my company’s firewall is causing issues or not. Also, my company uses a proxy, so the question is does the Windows Terminal need to know the proxy information?

Doesn’t run on an off-grid Win 10 installation. Terminal version 1.16.10261.0

Wouldn’t this be resolved with an Offline license? Then we don’t have to worry about wlidsvc / Microsoft Account Sign-in Assistant running or being able to talk out to login.live.com for acquiring a license on the first run.

I just want to add on to this. I think the core of this issue is the expectation modern Windows has of Internet connectivity, a combination of not-very-well-documented-or-understood configurations related to Windows’ security technologies (i.e. SmartScreen) ; poorly understood and often misguided network and firewall configurations in enterprise environments (WE DON’T USE THE WINDOWS STORE WE NEED TO BLOCK IT AT ALL COSTS.) ; and the very real problem of actual offline environments that have legal mandates to stay disconnected.

Some combination of the mix between these is often causing issues. And I can tell you that with certainty, there are folks that firmly believe that all systems should stay 100% disconnected, even to Microsoft services (even if they’re trusting Microsoft with O365/etc in other areas).

Btw, I reverted a different Win10 VM to a snapshot from a month ago, reapplied all patches (now at v1903, build 18363.836), disconnected all networking, installed the Desktop Bridge VC++ v14 Redistributable Package, installed the Terminal 1.0 msixbundle with File Explorer, and now I get a different error message, “File system error (12007)”, which is similar to Issue #2129

I don’t know if this is relevant, but when I run “Get-AppxPackage -Name Microsoft.WindowsTerminal”, the output object has a property named “IsBundle” set to False, even though the package is a msixbundle. Two of the bundled files are *.ttf font files, so there may be an AppLocker check or Windows Defender exploit mitigation for font files that is blocking because the machine has no internet access (???). These font files remain behind even when the Terminal is uninstalled.

@ttutko My guess about AppLocker is not because of any evidence (other than being able to launch from a System command shell), but because of a problem that occurs with PowerShell 7.0 on air-gapped machines that turned out to be AppLocker under the hood even when there are no AppLocker rules: https://github.com/PowerShell/PowerShell/issues/10983