DISCUSSION: Terminal won&#39;t run in offline environment #8295

@EmbeddedBacon commented on GitHub (May 20, 2020):

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?

@EmbeddedBacon commented on GitHub (May 20, 2020): 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?

claunia commented

@JasonFossen commented on GitHub (May 20, 2020):

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

@JasonFossen commented on GitHub (May 20, 2020): 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...

claunia commented

@EmbeddedBacon commented on GitHub (May 20, 2020):

@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?

@EmbeddedBacon commented on GitHub (May 20, 2020): @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?

claunia commented

@ttutko commented on GitHub (May 20, 2020):

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.

@ttutko commented on GitHub (May 20, 2020): 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.

claunia commented

@JasonFossen commented on GitHub (May 20, 2020):

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

@JasonFossen commented on GitHub (May 20, 2020): 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

claunia commented

@tebeco commented on GitHub (May 21, 2020):

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" ^^

@tebeco commented on GitHub (May 21, 2020): 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" ^^

claunia commented

@EmbeddedBacon commented on GitHub (May 21, 2020):

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 commented on GitHub (May 21, 2020): I tried running WindowsTerminal from the start menu and when I tried to launch it I saw the following dialog ![image](https://user-images.githubusercontent.com/42427056/82610653-9dd8d900-9b73-11ea-9317-6fad9276d7d1.png) Try to navigate to the file location using a cmd console I can't access it using an admin account ![image](https://user-images.githubusercontent.com/42427056/82610752-ce207780-9b73-11ea-99a1-f3b01802fec4.png) Is this the expected behavior?

claunia commented

@EmbeddedBacon commented on GitHub (May 21, 2020):

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.

@EmbeddedBacon commented on GitHub (May 21, 2020): 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.

claunia commented

@tebeco commented on GitHub (May 21, 2020):

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

@tebeco commented on GitHub (May 21, 2020): 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

claunia commented

@Kein commented on GitHub (May 25, 2020):

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

@Kein commented on GitHub (May 25, 2020): 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..._).

claunia commented

@armando-herastang commented on GitHub (May 28, 2020):

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

@armando-herastang commented on GitHub (May 28, 2020): > > > 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

claunia commented

@Kein commented on GitHub (May 28, 2020):

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.

@Kein commented on GitHub (May 28, 2020): 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.

claunia commented

@DHowett commented on GitHub (May 28, 2020):

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

@DHowett commented on GitHub (May 28, 2020): @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.

claunia commented

@Kein commented on GitHub (May 28, 2020):

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.

@Kein commented on GitHub (May 28, 2020): > 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.

claunia commented

@DHowett commented on GitHub (May 28, 2020):

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

@DHowett commented on GitHub (May 28, 2020): And which executable file are you launching? Mind sharing its path (redacted to the extent you need)?

claunia commented

@Kein commented on GitHub (May 28, 2020):

🤔
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?

@Kein commented on GitHub (May 28, 2020): 🤔 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?

claunia commented

@DHowett commented on GitHub (May 28, 2020):

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.

@DHowett commented on GitHub (May 28, 2020): 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.

claunia commented

@armando-herastang commented on GitHub (May 28, 2020):

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.

@armando-herastang commented on GitHub (May 28, 2020): > > > 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.

claunia commented

@Kein commented on GitHub (May 28, 2020):

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

@Kein commented on GitHub (May 28, 2020): > 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`

claunia commented

@DHowett commented on GitHub (May 28, 2020):

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?

@DHowett commented on GitHub (May 28, 2020): > 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?

claunia commented

@Kein commented on GitHub (May 28, 2020):

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.

@Kein commented on GitHub (May 28, 2020): > 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.

claunia commented

@DHowett commented on GitHub (May 28, 2020):

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!

@DHowett commented on GitHub (May 28, 2020): 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!

claunia commented

@ttutko commented on GitHub (Jun 3, 2020):

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.

@ttutko commented on GitHub (Jun 3, 2020): 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.

claunia commented

@miketheitguy commented on GitHub (Jun 25, 2020):

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 commented on GitHub (Jun 25, 2020): 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)

claunia commented

@miketheitguy commented on GitHub (Jun 25, 2020):

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

@miketheitguy commented on GitHub (Jun 25, 2020): 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).

claunia commented

@Kein commented on GitHub (Jun 25, 2020):

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

@Kein commented on GitHub (Jun 25, 2020): > (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.

claunia commented

@JorisVanEijden commented on GitHub (Jun 25, 2020):

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

downloaded wsixbundle from https://github.com/microsoft/terminal/releases
extracted Microsoft.WindowsTerminal_1.1.1671.0_8wekyb3d8bbwe.msixbundle to a folder with 7-zip
opened that folder in explorer
extracted CascadiaPackage_1.1.1671.0_x64.msix to another folder with 7-zip
opened that folder in explorer
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.

@JorisVanEijden commented on GitHub (Jun 25, 2020): 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.

claunia commented

@htcfreek commented on GitHub (Jun 29, 2020):

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.

@htcfreek commented on GitHub (Jun 29, 2020): 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.

claunia commented

@tebeco commented on GitHub (Jul 1, 2020):

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

@tebeco commented on GitHub (Jul 1, 2020): 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

claunia commented

@htcfreek commented on GitHub (Jul 1, 2020):

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.

@htcfreek commented on GitHub (Jul 1, 2020): 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.

claunia commented

@jeff-bb commented on GitHub (Jul 1, 2020):

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.

@jeff-bb commented on GitHub (Jul 1, 2020): Wouldn't this be resolved with an [Offline](https://docs.microsoft.com/en-us/microsoft-store/distribute-offline-apps) 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.

claunia commented

@DHowett commented on GitHub (Jul 1, 2020):

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

@DHowett commented on GitHub (Jul 1, 2020): That might help, but it also seems very difficult for an end user to install and our documentation about this is quite poor.

claunia commented

@DHowett commented on GitHub (Jul 1, 2020):

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

@DHowett commented on GitHub (Jul 1, 2020): (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.)

claunia commented

@jeff-bb commented on GitHub (Jul 1, 2020):

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

@jeff-bb commented on GitHub (Jul 1, 2020): If you have them, please make them available in the Store at least, so that business can at least [distribute it offline](https://docs.microsoft.com/en-us/microsoft-store/acquire-apps-microsoft-store-for-business). 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).

claunia commented

@miketheitguy commented on GitHub (Jul 1, 2020):

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

@miketheitguy commented on GitHub (Jul 1, 2020): > (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 :)

claunia commented

@nickdalt commented on GitHub (Jul 30, 2020):

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.

@nickdalt commented on GitHub (Jul 30, 2020): 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.

claunia commented

@DHowett commented on GitHub (Jul 31, 2020):

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 commented on GitHub (Jul 31, 2020): 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.

claunia commented

@DHowett commented on GitHub (Jul 31, 2020):

@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. 😄

@DHowett commented on GitHub (Jul 31, 2020): @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:

claunia commented

@WSLUser commented on GitHub (Aug 11, 2020):

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?

@WSLUser commented on GitHub (Aug 11, 2020): 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?

claunia commented

@DHowett commented on GitHub (Aug 11, 2020):

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

@DHowett commented on GitHub (Aug 11, 2020): `App Paths` is neither an issue _nor addressed by anything related to licensing._

claunia commented

@mammo0 commented on GitHub (Mar 8, 2021):

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

@mammo0 commented on GitHub (Mar 8, 2021): 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 :)

claunia commented

@WSLUser commented on GitHub (Mar 9, 2021):

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.

@WSLUser commented on GitHub (Mar 9, 2021): 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.

claunia commented

@DHowett commented on GitHub (Mar 9, 2021):

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.

@DHowett commented on GitHub (Mar 9, 2021): > 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_.

claunia commented

@mammo0 commented on GitHub (Mar 9, 2021):

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?

@mammo0 commented on GitHub (Mar 9, 2021): 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?

claunia commented

@tebeco commented on GitHub (Mar 9, 2021):

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)

@tebeco commented on GitHub (Mar 9, 2021): > 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)

claunia commented

2026-01-31 01:25:49 +00:00

@Kein commented on GitHub (Mar 9, 2021):

Remember - if you dont pay for the product - you are product. MS just wants any possible data it can extort form the user and they lovingly lump it into "telemetry" and "insight".

And this will never be fixed, because there is absolutely no point for MS to offer free products for... free. If you think Terminal or VSCode is free you are being a simpleton.

This comes from the top of the chain and maintainers are "just the guy executing an order" as they love to say to distant themselves from the responsibility.

@Kein commented on GitHub (Mar 9, 2021): Remember - if you dont pay for the product - you are product. MS just wants any possible data it can extort form the user and they lovingly lump it into "telemetry" and "insight". **And this will never be fixed**, because there is absolutely no point for MS to offer free products for... free. If you think Terminal or VSCode is free you are being a simpleton. This comes from the top of the chain and maintainers are "just the guy executing an order" as they love to say to distant themselves from the responsibility.

claunia commented

@zadjii-msft commented on GitHub (Mar 9, 2021):

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.

@zadjii-msft commented on GitHub (Mar 9, 2021): 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](https://github.com/microsoft/terminal/blob/7b1a660e590012893407a64f4321f01ba74a6e9b/src/cascadia/TerminalApp/AppLogic.cpp#L824-L830)", or "[is anyone actually using the command palette?](https://github.com/microsoft/terminal/blob/7b1a660e590012893407a64f4321f01ba74a6e9b/src/cascadia/TerminalApp/CommandPalette.cpp#L75-L81)". 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.

claunia commented

2026-01-31 01:25:49 +00:00

@Kein commented on GitHub (Nov 20, 2021):

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

@Kein commented on GitHub (Nov 20, 2021): Tested 1.11 on LTSC 2021 offline, used directly unpacked and unregistered version - works fine. Seems like they finally added offline license.

claunia commented

@rchristman89 commented on GitHub (Sep 30, 2022):

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?

@rchristman89 commented on GitHub (Sep 30, 2022): 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?

claunia commented

@FaffeF commented on GitHub (May 10, 2023):

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

@FaffeF commented on GitHub (May 10, 2023): Doesn't run on an off-grid Win 10 installation. Terminal version 1.16.10261.0

claunia commented

@sisrfeng commented on GitHub (Jun 9, 2023):

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

@sisrfeng commented on GitHub (Jun 9, 2023): win11 ships with windows terminal, and it work even if offline

claunia commented