Blog Post
The Next Chapter of Microsoft Teams in Virtualized Environments
Split MSIX is irrelevant. The real problem is per-user runtime staging, which is a major design fiasco.
Locked-down enterprise endpoints (Finance, Healthcare) block this via AppLocker or disabled App Readiness Service by default. Service providers have zero control over these policies. If Microsoft doesn't provide a native, bundled SlimCore path within the admin installers by October 2026, these critical sectors simply lose Teams optimization entirely. The current architecture is not fit for secure enterprise VDI.
- Fernando_KlurfanMay 04, 2026
Microsoft
We have hundreds of customers in FSI/Healthcare running this with no issues. Not sure where you are getting stuck.
There are changes required in the configurations for AppLocker/WDAC/GPOs, but this is doable. You can use AppUserModelId, or BlockNonAdminUserInstall to block all MSIX apps except SlimCore.
As a measure of last resort, customers on restricted network environments in the branch office can opt for an alternative SlimCore distribution process, without requiring the endpoint be able to fetch SlimCore packages using https from Microsoft's public Content Delivery Network.
New VDI solution for Teams - Microsoft Teams | Microsoft Learn- Artur_888May 05, 2026Copper Contributor
Fernando,
We have a fundamental misunderstanding here. Your success with "hundreds of customers" suggests you are operating in internal IT scenarios where you manage both the Citrix environment and the user endpoints. If you own the device and the GPOs, yes, it is "doable."
Many Citrix administrators, myself included, operate as service providers or multi-tenant hosts. We deliver virtual desktops and apps to thousands of external users connecting from hundreds of different client organizations. We have absolutely zero control over those client endpoints. They are managed by our clients' respective IT departments, not by us.
Telling me that modifying AppLocker, WDAC, or GPOs is "doable" shows a complete lack of understanding of this specific, crucial Citrix use case. It is a complete non-starter for me to write to 500 separate corporate IT departments and demand they change their local security posture just to allow Microsoft’s new plugin architecture to function. They will say "no" due to security risks.
Furthermore, your suggestion regarding the "alternative distribution process" misses the technical point. Even if we distribute the SlimCore package offline to avoid CDN fetching, it still requires runtime MSIX staging per-user via the local App Readiness Service. That staging process itself is often blocked by default in locked-down environments, bringing us right back to square one.
If optimization worked before without needing local admin support from third-party IT, then this new dependency is an architectural failure for professional service provision.
Ultimately, the simplest and most logical solution is for Microsoft to bundle the SlimCore packages directly into every standard Microsoft Teams for Windows installation. If the dependency on SlimCore is that tight, it should be treated as a required local component of the Teams app itself, not a secondary, error-prone runtime add-on that requires a third-party IT admin to enable. We need a deterministic, native deployment path where the required binaries are present on disk upon installation, period.
- riahc3Jun 09, 2026Tin Contributor
Artur_888
If you are implementing a Citrix environment, you SHOULD be able to dictate the policies required for implementation.
As an IT consultant in an MSP, you are required to write up 1000 documents explaining the functionality of a Citrix infrastructure and requirements. Modifying AppLocker to allow SlimCore is not that big of an issue.
I’ve deployed 100s of Citrix infrastructure, stating different guidelines of all policies that need to be put in place, different for each client’s needs, both in the backend and the endpoints. Some companies ask for compliancy where we need to provide the proper documentation on what is met and isn’t met, and what changes are required from both sides to do so.
“If optimization worked before without needing local admin support from third-party IT, then this new dependency is an architectural failure for professional service provision.” – This is one of the most ignorant sentences I have read in a long time. Are you suggesting that large architectural changes should not require an admin to intervene? Are you comparing something like this to an enduser installing Solitaire on their local PC? Every thing configuration needs and requires admin access…