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: PowerShell/PowerShell#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 😉

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

[mammo0]

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

[WSLUser]

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.

[DHowett]

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.

[mammo0]

I also think that is not a problem of this specific app.

Because it's also affects other Microsoft apps, that were installed additionally to the default ones. So it seems, that if such an app is launched, Windows 10 always checks the activation status. Regardless if it's a paid app or a free one.

@DHowett: Since you're a member of Microsoft, maybe you can name a contact that is responsible for the Microsoft Store activation?

[tebeco]

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

this look like something that could be documented if the team already knew about that no ?
Same as the script to extract msixbundle and msix

I mean it's just like knowing the workaround already but not sharing them with the community only the real issue is fixed
That less the consumer/client/user being able to share and use the product you're building for the community
It's a very good one, but until Store issue are fixed having a middleman helping is definitely worth it

Generally corporation whiling to deploy GPO rule for firewall ask for the docs and statement regarding FQDN/Port/Protocol to open so that would definitely help (even if it's linked to the Store)

[Kein]

Tested 1.11 on LTSC 2021 offline, used directly unpacked and unregistered version - works fine. Seems like they finally added offline license.

[rchristman89]

I have a similar issue the only difference is I am creating an app attach MSIX package with Terminal 1.14.1861.0. In a disconnected environment I am seeing the error for this in the event logs. Is there an update on this status?

[FaffeF]

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

[sisrfeng]

win11 ships with windows terminal, and it work even if offline

[DHowett]

Now that we have released "portable" and "unpackaged" distributions as well as documented the online and offline characteristics of the "msix bundle" and "preinstallation kit" distributions, I am comfortable closing this issue out.

The Preinstallation kit is the recommended way to deploy Windows Terminal on an air-gapped machine, as it comes with an offline license document and integrated dependencies--both of which preclude the AppX Service from needing to reach out over the internet.