Microsoft Teams SlimCore optimization is not installing or activating successfully on endpoint laptops as we have the Microsoft Store block policy

Question

Microsoft Teams SlimCore optimization is not installing or activating successfully on endpoint laptops as we have the Microsoft Store block policy

Nair, Aneesh 20

Microsoft Teams SlimCore optimization is not installing or activating successfully on endpoint laptops as we have the Microsoft Store block policy.

Context

Microsoft Teams SlimCore optimization is not installing or activating successfully on endpoint laptops. The request is to validate and enable SlimCore on laptops used for Teams VDI. The goal is to improve call quality and reduce resource consumption inside the VDI.

Current Policy Settings:
User's image

Tried to tweek the MS Store configuration policy and found that The Slimcore Optimization is only working if we allow the Non Admin Install option in the above policy.

After extensive testing and evaluation of potential solutions, the most effective recommended approach is outlined below.

This is more restrictive, but there is an important production-support limitation. Microsoft documents a policy named: Allowed package family names for non-admin user install It can bypass Prevent non-admin users from installing packaged Windows apps for matching package family names. Microsoft’s Teams guidance recommends these values for the current split package architecture: Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe

Microsoft.Teams.SlimCoreVdiFwk.*_8wekyb3d8bbwe As of 30 July 2026, the Microsoft ApplicationManagement CSP reference still marks as applicable to Windows Insider Preview for MDM/CSP deployment.

Any Suggestions to achieve our result by keeping the Microsoft Store Restricted for users, but need the Slimcore activaion done.

0 comments

2 answers

Your answer

Answer 1

Ana Le 2,615 Independent Advisor

Hi,

It looks like the Microsoft Store restriction and the non-admin app installation restriction can be handled separately for this scenario. Microsoft documents a way for managed endpoints to keep BlockNonAdminUserInstall enabled while allowing the SlimCore MSIX packages to install.

For the current split MSIX architecture, I would check these areas:

1/ Check the Windows build and required updates.

Microsoft documents support for SlimCore installation with BlockNonAdminUserInstall enabled after applying the applicable cumulative update:

Windows 11 23H2 / 22H2: KB5052094
Windows 11 24H2: KB5052093
Windows 10 22H2: KB5055612
or a later cumulative update

These updates introduce the Allowed package family names for non-admin user install policy, which can be used to allow the SlimCore packages without broadly allowing non-admin users to install packaged apps.

For the new split MSIX architecture, Microsoft lists these SlimCore package families:

Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe
Microsoft.Teams.SlimCoreVdiFwk.<version>_8wekyb3d8bbwe

Microsoft also documents a regex-based allow-list option: New VDI solution for Teams - Microsoft Teams | Microsoft Learn

2/ If the endpoints are Intune-managed, check whether the following policy can be configured in your environment:

./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/AllowedNonAdminPackageFamilyNameRules

Microsoft documents this as an option for allowing matching package family names even when BlockNonAdminUserInstall is enabled: ApplicationManagement Policy CSP | Microsoft Learn

3/ Verify the other MSIX-related policies.

Microsoft identifies these settings as possible blockers for SlimCore installation:

BlockNonAdminUserInstall
AllowAllTrustedApps
AllowDevelopmentWithoutDevLicense

Your screenshot currently shows Allow All Trusted Apps as Explicit allow unlock, so I would verify the effective policy on an affected endpoint rather than changing this setting immediately.

4/ Also check AppLocker or WDAC.

Microsoft notes that AppLocker or Windows Defender Application Control can block SlimCore MSIX installation. If either is being used, check whether there is a rule preventing the SlimCore Host or Framework packages from being installed or registered.

5/ If the policy configuration looks correct, check the endpoint logs for the actual deployment failure.

On the affected endpoint, review: Applications and Services Logs > Microsoft > Windows > AppxPackagingOM > Microsoft-Windows-AppxPackaging/Operational

and Applications and Services Logs > Microsoft > Windows > AppXDeployment-Server > Microsoft-Windows-AppXDeploymentServer/Operational

These logs should help distinguish a policy restriction from another MSIX deployment or registration issue.

Could you also provide the following details from one affected endpoint?

Windows version/build
Whether the device is managed by Intune, Group Policy, or both
The exact Teams/SlimCore error code, if one is shown
Whether the screenshot represents the current effective policy or the configuration after your testing

For reference, Microsoft specifically documents error 16389 as commonly associated with BlockNonAdminUserInstall, while error 15615 is associated with MSIX installation policy issues such as AllowAllTrustedApps. (Troubleshooting the VDI 2.0 solution for Teams - Microsoft Teams | Microsoft Learn)

Nair, Aneesh 20 Reputation points

2026-09-28T11:07:29.78+00:00
Windows 25H2

Managed by Intune

Error 404 Appx Deployment operation failed for package Microsoft.Teams.SlimcoreVdi............

Screenshot represents the current policy.

I tried to tweak the policy no luck. also, the custom uri method is not working.
Ana Le 2,615 Reputation points Independent Advisor

2026-09-29T08:56:24.8+00:00

Hi,

Thanks for the additional details. The fact that the affected endpoints are on Windows 11 25H2 and the SlimCore deployment is returning error 404 changes the direction of the troubleshooting.

Microsoft's current Teams VDI troubleshooting documentation maps SlimCore deployment error 404 (deployErrc 3235) to HTTP_STATUS_NOT_FOUND. This indicates that the SlimCore MSIX package could not be found on Microsoft's Content Delivery Network, with proxy/network interference listed as a possible cause.

This is different from the BlockNonAdminUserInstall issue, which is more commonly associated with ERROR_ACCESS_DENIED / error 16389. Since your current policy already shows Block Non Admin User Install as Allow, I would not focus on that policy as the cause of the 404 at this point.

I would check the following on one affected endpoint:

1/ Check the Teams VDI log for the exact deployment code.

Press Ctrl+Alt+Shift+1 in Teams to collect the logs, then check the vdi_debug.txt file for the SlimCore onConnected entry. In particular, please look for the values of: loadErrc deployErrc

If deployErrc is 3235, that would match Microsoft's documented 404 condition.

2/ Check whether a proxy, SSL inspection, or other network security device is affecting the SlimCore download.

SlimCore is normally downloaded by the Teams VDI plugin from Microsoft's public CDN. A 404 at this stage can indicate that the requested SlimCore package cannot be retrieved correctly.

Please compare the behavior from an affected endpoint with an endpoint on a network path that does not use the same proxy or security filtering, if such a test is possible.

3/ Verify that the Teams VDI plugin is current.

Microsoft's current VDI documentation lists plugin updates separately from the Teams client. The Windows plugin version 2026.29.1.4 and later includes fixes for SlimCore MSIX provisioning/registration issues on some thin-client and kiosk scenarios.

4/ If the endpoint cannot reliably obtain SlimCore from Microsoft's CDN because of the network configuration, Microsoft also documents an alternative local/network distribution method using the MsixUrlBase registry value. This requires the SlimCore MSIX version to match the Teams client version and has additional deployment requirements.

The AllowedNonAdminPackageFamilyNameRules policy is intended to address the separate non-admin installation restriction. Given the 404 you are seeing, I would not treat that policy as the primary cause unless the VDI logs show an installation-policy error as well.
Nair, Aneesh 20 Reputation points

2026-09-29T09:04:27.83+00:00

Please note that we isolated this issue to the “Allow Non-Admin Install of Store Apps” policy. We duplicated the current policy and set “Block the Non-Admin Install” to Allow. The test user was then able to activate Slimcore.
That’s why we tested excluding the Teams Slimcore framework and plugin through the new OMA-URI testing.
Ana Le 2,615 Reputation points Independent Advisor

2026-09-30T12:55:22.3+00:00

That clarification is helpful. Since your controlled test shows that changing the non-admin installation setting allows SlimCore to activate, that gives us a much stronger indication that the policy is directly affecting the SlimCore installation in your environment.

In that case, the main point to investigate is why the AllowedNonAdminPackageFamilyNameRules OMA-URI is not taking effect on your Windows 11 25H2 devices.

Could you check the Intune device status for that specific custom OMA-URI and see whether it reports Succeeded, Pending, or Error on the test device?

Also, Microsoft maps this policy to the following registry value, so checking whether the policy value is actually present on the endpoint may help distinguish between an Intune policy delivery issue and a package matching issue: HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\AllowedNonAdminPackageFamilyNameRules

Since the Teams documentation provides the OMA-URI specifically for this SlimCore scenario, but the Windows CSP documentation currently lists the policy under Windows Insider Preview, the result on Windows 11 25H2 is worth verifying rather than assuming the OMA-URI should apply successfully.

That would be the next detail I'd check before changing the Store restrictions again.
Nair, Aneesh 20 Reputation points

2026-09-30T13:16:44.8533333+00:00

"Since the Teams documentation provides the OMA-URI specifically for this SlimCore scenario, but the Windows CSP documentation currently lists the policy under Windows Insider Preview, the result on Windows 11 25H2 is worth verifying rather than assuming the OMA-URI should apply successfully."

You are right. This is why I posted in Q & A. The error code is : ERROR CODE 0x87d1fde8 And There is no entry related to this key in reg. HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\AllowedNonAdminPackageFamilyNameRules
Ana Le 2,615 Reputation points Independent Advisor

2026-10-02T03:19:44.1266667+00:00

Thank you for checking both. I understand the frustration when the documented exception does not apply as expected.

The error code alone does not establish the cause. Together with the missing registry entry you reported, it warrants checking whether the allow-list policy was delivered and applied successfully. It does not, by itself, prove that Windows 11 25H2 does not support the policy.

I also need to correct my earlier interpretation of “404”: an AppXDeployment-Server Event ID 404 is not equivalent to an HTTP 404 download error. Microsoft’s AppX troubleshooting guidance shows Event ID 404 for deployment failures caused by policy restrictions. My earlier CDN interpretation was therefore premature. Your policy comparison remains the stronger evidence here.

The documentation discrepancy also remains unresolved: the Teams VDI guidance provides this OMA-URI, while the CSP reference still lists Windows Insider Preview. I cannot confirm production support for your specific build from those pages alone.

At this point, I recommend opening an Intune support request through Troubleshooting + support > Help and support, asking Microsoft to investigate the failed policy application and clarify its applicability to your Windows edition/build. See Get support in the Microsoft Intune admin center.

For that request, include your policy comparison, full Windows edition/build, the custom profile’s OMA-URI/data type/value, and the reported error. On one affected endpoint, also collect the event associated with this policy under: Event Viewer > Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin

Microsoft’s custom OMA-URI troubleshooting guidance identifies this log as the place to check for additional details about failed policy application. Share the diagnostic files privately through the support case.

This gives support a focused case: the non-admin restriction affects SlimCore activation, and the documented exception is failing to apply in your environment.

Answer 2

Yes. SlimCore can be enabled while keeping Microsoft Store access restricted, but the endpoint policies must allow the SlimCore MSIX packages to install.

The key points are:

BlockNonAdminUserInstall is the most likely cause of SlimCore failing to install or activate. This commonly surfaces as Error 16389 / E_FAIL, with the underlying AppX failure often being 0x80070005 Access Denied.
Keeping Store restricted is possible. The documented approach is to keep the restrictive policy and allow-list the SlimCore package family names using the new policy Allowed package family names for non-admin user install.
For the new split MSIX package architecture, both package families must be allow-listed:
- Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe
- Microsoft.Teams.SlimCoreVdiFwk.*_8wekyb3d8bbwe
Regex form:
- Microsoft.Teams.SlimCoreVdi*.*_8wekyb3d8bbwe
On Intune-managed endpoints, this can be set with the OMA-URI:
- ./Device/Vendor/MSFT/Policy/Config/ApplicationManagement/AllowedNonAdminPackageFamilyNameRules
Value:
```
   <enabled/>
   <data id="AllowedNonAdminPackageFamilyNameRules" value="Microsoft.Teams.SlimCoreVdi*.*_8wekyb3d8bbwe"/>
```
Required Windows updates matter. Managed endpoints/thin clients with BlockNonAdminUserInstall enabled can still allow SlimCore packages to install after applying these updates or later:
- KB5052094 for Windows 11 23H2 and 22H2
- KB5052093 for Windows 11 24H2
- KB5055612 for Windows 10 22H2
AllowAllTrustedApps must not be disabled. If AllowAllTrustedApps is disabled, the new media engine MSIX installation fails.
Also verify that AppLocker or WDAC is not blocking the SlimCore MSIX packages. If AppLocker is used, add an exception for SlimCore packages. AppLocker cannot process trailing wildcards, so exclusions can rely on the PublisherID 8wekyb3d8bbwe. The new Host package family name is Microsoft.Teams.SlimCoreVdiHost.win-x64_8wekyb3d8bbwe.
After policy changes, verify optimization on the endpoint:
- Check whether MsTeamsVdi.exe is running on the endpoint.
- For Azure Virtual Desktop/Windows 365, it appears as a child of msrdc.exe.
- In Teams, hover over the Optimized banner to confirm whether SlimCore optimization is active.
- If not optimized, use Optimize virtual desktop and restart from the Teams menu to trigger a repair attempt.

Recommended path for the current scenario:

Keep Microsoft Store restricted for users.
Apply the required Windows cumulative update for the endpoint OS.
Configure Allowed package family names for non-admin user install for the SlimCore package families.
Ensure AllowAllTrustedApps is enabled.
Check AppLocker/WDAC for blocking rules and add SlimCore exceptions if needed.
Restart Teams and validate optimization status on the endpoint.

If the environment is currently showing windows_error_16389, this strongly matches the documented BlockNonAdminUserInstall policy issue.