Terminal: DISCUSSION: Terminal won't run in offline environment

[ttutko]

Environment

Windows build number: 10.0.19041.0
Windows Terminal version (if applicable): 1.0.1401.0

Any other software?

Steps to reproduce

Download msixbundle file on internet connected machine.
Move file to machine without internet connection (via USB thumb drive, for example)
Double-click to install Windows Terminal
Click "Launch" to run Windows Terminal

Expected behavior

Windows Terminal opens

Actual behavior

After some period of time (typically less than a minute, I believe), an error window pops up:
"C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.0.1401.0_x64_8w...\WindowsTerminal.exe

The network location cannot be reached. For information about network troubleshooting see Windows Help."

The only thing POSSIBLY related that I saw was when I run it, there are several attempts to reach out to slscr.update.microsoft.com (viewed using fiddler) every time I try to launch it. Since the machine does not have internet, obviously those requests fail.

This may be somewhat related to #1386 but when I tried an older version of Windows Terminal it wouldn't even install. Now that you bundled the dependencies it seems to indicate a successful install but will not launch.

[EmbeddedBacon]

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?

[JasonFossen]

I spent two hours on the same problem, it's not just your machine. When I run PowerShell.exe running as System, I'm able to launch WindowsTerminal.exe from the install folder, but not as a regular user or even as an elevated user in the Administrators group. As a guess, AppLocker or Windows Defender might be to blame...

[EmbeddedBacon]

@JasonFossen, interesting data points. For my case my companies manages the firewall and doesn't use Windows Defender from what I have been told. Perhaps AppLocker is blocking it on my end?

[ttutko]

Windows Defender is disabled on my machine and although I'm not that familiar with AppLocker, I am fairly sure we aren't using it on this network. I have domain admin rights and am looking through group policy now but I don't see nor have I heard of any other admins setting up any app restriction policies on here.

[JasonFossen]

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

[tebeco]

We have the exact same issue at work (see #6027 / closed for dup)
Do you want me to run PS script / check things .... to get more info ?

By reading the issue here I'm not sure what to do to provider more info

@DHowett
If you want to create an app with the same packaging as the Windows terminal but tons of logs so that I can send you back diagnostic, don't hesitate to ping me here
If there's a way to run a kinda of profiler or windbg or just dump log files

I'm very whiling to help send data that coul help you resolves this issue.
As the msixbundle issue is solved, this seems like the next blocking step

I only found one workaround so far => directly accessing / running the file but as described in a previous issue I had to "change" user right on a thing i was not supposed to do
So we're back to "unzip the msixbundle manually" ^^

[EmbeddedBacon]

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?

[EmbeddedBacon]

Does Windows Terminal create events that can be viewed in the Event Viewer? I looked through the trees under the Windows Logs, but I didn't see anything that stood out to me.

[tebeco]

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

[Kein]

I have the same issue.
This is because when you launch Terminal, Store integration launches MS Account Sign-In service, which tries to connect to the store and fetch some meta[data], then it fails and propagates the error - what you see isnt Terminal error per se, it is UWP/Store platform error. It is similar to the X-box apps that wont launch offline (_albeit there is a way but it is a massive pita that requires you to launch every single game you want to play offline - imagine launching manually 100+ apps..._).

[armando-herastang]

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

Had the same issue and this solution worked for me. It would be nice to fix this problem so users can run it out of the box. Greetings

[Kein]

This wont work for 1.0 in pure offline mode because it will require store to run MS Sign-up service and connect the ms services which will fail. That's why this issue exist. You either are doing it on the always online system OR the said service very, very recently already did the connection for any other reason and its session still valid for XX hours.
Both are not applicable to pure offline systems.

[DHowett]

@Kein downloading the msixbundle file from our repository _and extracting it like a zip file_ does not require an active store session, an internet connection (beyond the initial download), or any other service attachment. It is fully standalone.

[Kein]

downloading the msixbundle file from our repository _and extracting it like a zip file_ does not require an active store session

No, downloading isnt, launching Terminal executable is. It will fail with the error in the OP because store has no valid tokens acquired by Sign-In service (does not matter if you have account or not - it still need just one). I have VM with offline setup open right now and I can reproduce it anytime. I can also acquire tokens by letting the SingUp service go online once and then Terminal launches just fine for a while.

[DHowett]

And which executable file are you launching? Mind sharing its path (redacted to the extent you need)?

[Kein]

🤔
WindowsTerminal.exe, there is only one related to terminal itself and that is the one applet launches from store as well. Did you read opening issue?

[DHowett]

Yes, the opening issue indicates that WindowsTerminal.exe is in the WindowsApps folder. My assertion is that if you treat the msix bundle like a zip file and unzip it instead of installing it (which would place files in the WindowsApps folder), you can use it in a fully offline environment.

If you double-click OpenConsole.exe in the same folder you extracted the msix file into, does _that_ launch? It’ll be the old console instead of the new terminal, but it is very useful as a benchmark.

[armando-herastang]

This wont work for 1.0 in pure offline mode because it will require store to run MS Sign-up service and connect the ms services which will fail. That's why this issue exist. You either are doing it on the always online system OR the said service very, very recently already did the connection for any other reason and its session still valid for XX hours.
Both are not applicable to pure offline systems.

I was running online, so I totally unplugged my network connections and restarted the terminal and it worked just fine. Before I wasn't able to start it online nor offline.

I had @EmbeddedBacon problem, and did @tebeco workaround.

[Kein]

Yes, the opening issue indicates that WindowsTerminal.exe is in the WindowsApps folder. My assertion is that if you treat the msix bundle like a zip file and unzip it instead of installing it (which would place files in the WindowsApps folder), you can use it in a fully offline environment.

No, in my case I extracted it into my custom programs folder and I've got the same issue. I've enabled the packet tracing and noticed that each time I launch Terminal and get the error, "Microsoft Sign-In Service" tries to access MS servers. Enabling the internet access to it and letting it do whatever it wanted to do enabled the ability to launch Terminal. Further testing confirms the network access can be disabled later and Terminal still works. I'm not yet sure for how long the session token that service obtained is good for, so far it launches.
Taking into the account this wasnt the case with versions below 1.0 I'm assuming this is an issue on the side with store app integration rather than Terminal itself. At least I'm not seeing any reason why would it need online access to launch and provide its functionality (_unless there are some forced telemetry endpoints which wouldnt surprise me as it is Microsoft product_)

If you double-click OpenConsole.exe in the same folder you extracted the msix file into, does _that_ launch?

Yes, I see no reason why wouldnt that launch, it just a wrapper for native windows console like cmder

[DHowett]

Yes, I see no reason why wouldnt that launch, it just a wrapper for native windows console like cmder

That's an unusually evasive response. Speaking as the engineering lead: OpenConsole is literally the same code as C:\windows\system32\conhost.exe but built from our open-source project. It's an excellent sentinel to help diagnose these issues because it's built out of the same project, same source, and same repository as WindowsTerminal.exe, and it's packaged in the same way in the same place :wink:

(edit: so, openconsole isn't a wrapper for the native console, it is the native console. It is the API server for all of the win32 console APIs)

Unzipping the MSIX and turning it into a set of files on disk breaks all connection with the store, and we've not written an ounce of code to make Terminal fail to launch when there's no connection to the store. That would be madness!

(edit: I re-read this, and it sounded like i was defending against an insinuation. I didn't intend that. What you're seeing is not intended behavior)

Just for completeness' sake, when you do have Terminal running can you share a screenshot of the About dialog?

[Kein]

That's an unusually evasive response. Speaking as the engineering lead: OpenConsole is literally the same code as C:\windows\system32\conhost.exe but built from our open-source project. It's an excellent sentinel to help diagnose these issues because it's built out of the same project, same source, and same repository as WindowsTerminal.exe, and it's packaged in the same way in the same place

Okay, I'm not sure what is evasive here. In fact, if what you say is correct -- and I dont see any reason to question it -- then it would explain why OpenConsole would launch without any issues.

Just for completeness' sake, when you do have Terminal running can you share a screenshot of the About dialog?

Sure thing:

Windows Terminal (Unpackaged)
Version: 1.0.200517002-release1.0

Unzipping the MSIX and turning it into a set of files on disk breaks all connection with the store, and we've not written an ounce of code to make Terminal fail to launch when there's no connection to the store. That would be madness!

I'm relying what I have observed. Mind you, this is a system that was installed offline and NEVER had any online connection. When I get the error, same error as in the OP:
_The network location cannot be reached. For information about network troubleshooting see Windows Help."_
My first thought was to diagnose network, which I did by monitoring any network activity. Repeated launch of WindowsTerminal.exe triggered remote network requests from service wrapper process svchost.exe with the PID corresponding to widsvc (Microsoft Account Sign-in Assistant). By allowing this and only this service access to internet and remote endpoints it wanted I've got a successful launch of WindowsTerminal without any network errors.

[DHowett]

Wow, this is truly wild. I have no idea why even unpackaged launch would do that.

Sorry to put you through the wringer: we are getting a lot of activation issues in a lot of different verticals, so I'm trying to make sure we've got them very crisply categorized!

[ttutko]

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.

[miketheitguy]

Thanks @DHowett for posting how to work around this issue. This was causing me to pull my hair out. Between the below issue and this one, I believe I've now gotten it to work in an offline environment :)

The only thing that sucks is in order to pass this around to folks at work, I'll end up having to completely re-package the files for distribution in a custom installer that doesn't force the connection into the Windows Store. Which just sucks. I'd prefer to have a consistent experience from what people are doing on their personal machines and our work environment.

There's another issue that can occur when attempting to install the msixbundle if you're firewalled-off; and that's an error with Windows Defender SmartScreen when Group Policy is configured to "Block".

When the following registry value is configured, even on newer versions of Windows 10 (this was the original setting for TH2, but modern versions include newer registry settings) AND when you're firewalled from connecting to SmartScreen for Apps and Files ; you'll see an error installing the MSIX that is cryptic and doesn't tell you that it's a SmartScreen problem.

Interestingly, the registry configuration for Defender Smart Screen seems to have changed in 1703 or newer ; but 2004 will still honor the below registry setting. (Documented here: https://www.stigviewer.com/stig/windows_10/2018-04-06/finding/V-63685)

Registry Hive: HKEY_LOCAL_MACHINE
Registry Path: \SOFTWARE\Policies\Microsoft\Windows\System\

Value Name: EnableSmartScreen

Value Type: REG_DWORD
Value: 0x00000002 (2)

[miketheitguy]

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

[Kein]

(WE DON'T USE THE WINDOWS STORE WE NEED TO BLOCK IT AT ALL COSTS.)

Yeah, you have a problem with that you can argument and back up that are not witty sarcastic remarks? There is 0 reason a complete offline package should require global network connection to be used or installed.

[JorisVanEijden]

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.

[htcfreek]

Hello.

I had a error message with the same meaning today under W10 1903. For me it gets fixed after installing the Windows Updates (Windows, .Net) from June 2020.

[tebeco]

I'm confused, this issue is about "staying offline" (because GPO make it impossible to get any connectivity even for 4-5 mins) / Store is locked / Update are controlled by internal server
And yet:

For me it gets fixed after installing the Windows Updates

So, Online ?
I mean this issue is open for corporation that blocks "Live" windows update + Store + User Account ARE NOT "Microsoft Account" (which might be part of the issue here)
Companies uses "Windows Server Update" which means they only ship update of what is critical so this is not going to happend before a very long time
Are you sure a KB fixed it ? It look like it's more because you managed to have a fully functionnal "online" connectivity, which is the issue here

[htcfreek]

My last answer was incorrect.

The solution ist to have internet access for a short time, when starting wt the first time.

After that it works also offline.

[jeff-bb]

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.

[DHowett]

That might help, but it also seems very difficult for an end user to install and our documentation about this is quite poor.

[DHowett]

(We do have offline license files, but the relative dearth of documentation and inability for an end user to figure out what to do with them has quite given me pause on distributing them.)

[jeff-bb]

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

[miketheitguy]

(We do have offline license files, but the relative dearth of documentation and inability for an end user to figure out what to do with them has quite given me pause on distributing them.)

Would love to have this for IT distribution reasons. Right now my plan for distributing the Terminal is to re-package the msixbundle x64 package into our own distribution mechanism to deploy it--and maintain our own distribution of the software. I'd rather try to integrate it all to the Store if possible, but I have a network that has ABSOLUTELY no connectivity to the internet. And that's not going to change, but I'd prefer to follow the same, easy-to-integrate distribution mechanism for both.

Also, when manually distributed, "wt.exe" doesn't work ; and the Terminal doesn't report the same version in "About", so it makes it difficult to track which release someone is on versus the release notes your team publishes online.

I'm also not sure if the store installation process installs the Cascadia fonts or if Terminal uses the font explicitly as part of its application. Based on Font settings, it looks like the font is installed and then linked back to the Terminal. The Cascadia Code github page references that you should uninstall the old fonts first if you're upgrading, but the Terminal dependency causes some confusion there. I'm not even sure how it tracks the dependency on that :)

Nitpicks, of course ; but little annoying ones that add up :)

[nickdalt]

In my experience this is not an issue specific to the Windows Terminal Appx, but to all MSIX packages not installed from the store. I have seen the same issues with WinDbg Preview and WSL Distros.
The type of Windows installation is also not a factor, both AD joined and standalone installs exhibit the problem.
In all instances the installation was completely offline.

[DHowett]

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.

[DHowett]

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

[WSLUser]

Back to the original OP of experience a network path error, I've seen notice of App Paths that the system manages for apps in a few issues. I would assume that is what's causing the network path error. Does offline licensing actually address the issue of App Paths? Is there something we can do to get App Paths to work correctly in the offline environment?

[DHowett]

App Paths is neither an issue _nor addressed by anything related to licensing._