Nextcloud Talk MSI client installed via GPO/machine-wide lacks microphone and camera access

ℹ️ Support 💬 Talk (spreed)
,
1

Hello everyone,

I am facing an issue with deploying the Nextcloud Talk desktop client in an Active Directory domain environment.

The Problem: When installing the Nextcloud Talk client using the MSI installer (which installs machine-wide for all users) either via GPO or locally with administrative privileges, the application cannot get access to the microphone and video camera.

  • The OS is Windows 10/11.

  • The global Windows privacy toggle “Allow desktop apps to access your microphone/camera” is enabled.

  • However, Nextcloud Talk does not request or inherit these permissions when installed as a machine-wide application via MSI.

The Twist: If I install the client using the standard EXE installer into the local user profile (%LocalAppData% context), everything works flawlessly. The app prompts for permissions, and both the camera and microphone work as expected.

Questions:

  1. How can we grant microphone and camera access to the Nextcloud Talk client when it is installed machine-wide via the MSI package? Is there a specific registry key, capability deployment, or AppX/MSIX provision boundary we are missing?

  2. What is the recommended best practice for deploying the Nextcloud Talk desktop client in a domain infrastructure via GPO so that users don’t encounter media access issues?

Any help, registry workarounds, or deployment insights would be greatly appreciated.

Thank you!

2

When you install it machine wide under Program Files, Windows sometimes treats the app capability requests differently compared to runing it directly from the user’s %LocalAppData%

You might want to check the modern privacy registry keys. Windows maps app permissions under this path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CapabilityAccessManager\ConsentStore\webcam (and microphone)

Sometimes adding a string value with the path to the Nextcloud executable there and setting it to Allow forces Windows to grant access without waiting for a prompt that the MSI context is blocking.

If that doesn’t work, a temporary workaround we used for another app was using GPO to run a lightweight login script that copies the necessary files to the user profile or just running the EXE silently per user. Hopefully, someone from the official dev team can chime in on whether the MSI package is missing some specific capabilities in its manifest.