Event banner
Event details
116 Comments
- It's not overly transparent how apps, especially Win32 ones will update once installed. If the app lacks its own inbuilt update mechanism then what will actually trigger the future upgrades of these apps from the store once installed?
- If it's a Store app without built in update, it will update at whatever frequency the Store checks for updates. Unfortunately, the Store isn't consistent in it's auto-updating and frequently requires manual checks. If it's a win32 app installed via winget, I am not aware of any current default settings for winget to auto-update. I there'd need to be a scheduled task setup for it.
- What solution can I provide users if we dont have intune for offering the new Windows Store application yet?
Thanks for participating in today's session of AMA: Microsoft Store and Windows app management! For reference, the panel covered this topic at around 26:00.
Noticed this in the Under Development page, how will this work vs the new Store for Business, will it be a replacement, enhancement or something completely different? Are there plans to support enterprise catalog installs during Autopilot provisioning?
Thanks for participating in today's session of AMA: Microsoft Store and Windows app management! For reference, the panel covered this topic at around 19:00.
- Bryan Keller
Microsoft
Very similar technology but they will work side-by-side. The focus will be Win32 apps leveraging Intune's IME agent and will include advanced capabilities like dependencies and supersedence. The Store integration, although supporting some Win32 apps, is highly focused on Store/UWP content.
Some apps within Intune using the new store for Business that are Win32 cannot be deployed "in preview" (example: Microsoft PowerToys) but other apps that are Win32 based like Adobe Reader can be. Why the discrepancy? When is the preview period scheduled to be over, and will those apps that can't be deployed today be available with the Intune new store integration?
Can someone please explain the Blocking Apps feature in ESP where "Only fail selected blocking apps in technician phase" in the most simple way possible? I purposefully created a Win32 app that fails on either detection or exit code, I have used that setting on an app assigned to a group and listed under blocked apps in ESP. Regardless of the setting for "only fail in technician phase" the app that fails always breaks Autopilot during pre-provisioning. What is the specific purpose of the setting? What is the specific test case we can create to test it? https://techcommunity.microsoft.com/t5/intune-customer-success/update-to-windows-autopilot-pre-provisioning-process-for-app/bc-p/3809809
Thanks for participating in today's session of AMA: Microsoft Store and Windows app management! For reference, the panel covered this topic at around 43:00.
- App "PC-Integrity-Check" shows that CPUs Intel Core i5-4570 and i5-5200U atre not supported "at this time" by Windows 11. That inhibits from migrating windows 10 to 11. When shall these CPUs be supüported by Windows 11? Never?
- We have an open incident using New Store to uninstall Windows built-in apps using system context. Some devices work as expected but other will continuously fail with various fail messages. The devices that are already in use seem to be the ones that see the errors but not all of them and not every built-in app uninstall. Net new devices that are being provisioned don't seem to be having the issue.
I suspect that could be an issue related to the Store re-design last year. There was some under-the-hood changes to go along with the UI re-design. I ended up having to manually download standalone installers for the current Store and AppInstaller packages, and then manually deploy those to computers* that were having Store and Store app update issues.
*almost all the computers I have seen with the Store issues you described have had at least one Windows 10 major version upgrade - i.e., they started life before the new store design. I've not been able to determine why some of them just won't update. I've had a few 18363-19041 computers that still have the old store and when you click on either "Library" or "Get Updates", it just kicks you back to the Store main page and could only be fixed by manually installing current Store and AppInstaller from standalone packages.
- I will try this on my device and see if the failures stop.
Ask Microsoft Anything: Microsoft Store and Windows app management starts tomorrow, May 31st at 7:30 AM PT! Continue to help us get started with questions and post them here in the Comments.
- A recent Intune update added support for System wide context for UWP apps when installed via the new store mechanism - https://learn.microsoft.com/en-us/mem/intune/fundamentals/whats-new#system-context-support-for-uwp-apps. This is fine when installing via Intune, but if you try and install the same UWP app from the msstore repo via the winget command line, scoping the installation to the machine via the --scope machine option then winget responds "Device wide install for msstore type is not supported under admin context". Why is such an installation possible via Intune but the same app cannot be installed in the same context from the command line?
"Why is such an installation possible via Intune but the same app cannot be installed in the same context from the command line?" - THIS exactly!
- Winget ships with two configured repos: msstore and winget - what are the key differences between these repos as there appears to be some overlap, i.e. we see some "unofficial" apps, i.e. not maintained by the actual vendor in the msstore repo, but also official looking apps in the winget repo. I'm aware that the Intune integration pulls in a subset of apps from the msstore repo only, but from the command line it appears possible to install from either and there's a confusing overlap between them.
Thanks for participating in today's session of AMA: Microsoft Store and Windows app management! For reference, the panel covered this topic at around 02:00.
- Some vendors have both UWP (store) apps and their traditional x86/64 apps. There are a lot of things in the Store that aren't in winget catalog, and vice-versa. I like the option to choose from and I do totally understand the user-space only nature of Store apps: however, it seems like winget _should_ be able to scan the entire system, incl each userspace, and update/install apps as needed. It should DEFINITELY have the ability to perform system-wide actions from the catalog context, even if not from the Store app context.
