Install app from Microsoft Store to Entra Domain joined AVD

For a Windows 11 Enterprise multi-session host pool managed by Nerdio, the correct approach is to install ClickUp once on the base/golden image (machine-wide / provisioned for all users) not per-user from the Microsoft Store. In multi-session, per-user Store installs don't persist or appear for other users on the same session host

Install on the base image via WinGet (machine scope)

ClickUp is published in the WinGet repo, so you don't need to get MSIX from the Store. - https://winstall.app/apps/ClickUp.ClickUp

On the golden image VM (elevated PowerShell):

winget install -e --id ClickUp.ClickUp --scope machine --accept-source-agreements --accept-package-agreements

Show more lines

The --scope machine flag makes it available to all users on the host.

Note - If winget isn't available under SYSTEM/elevated context on multi-session, bootstrap it first (App Installer + WindowsApps PATH)

• Nerdio's Scripted Actions library already has a ready-made "Install WinGet" + "Install app via WinGet" action you can run against the image VM.

Hi Himanshu, thanks for your response. I've tried to run the command in admin PowerShell, it did install ClickUp, but it only exist under the admin account (when you elevate PS, you need to provide admin account credentials). It doesn't exist as machine wide, even there is --scope machine in the command. Looks like ClickUp doesn't support it's installed as machine wide for all users. Any other possible workarounds? Thanks.

(after intalled, the path where is ClickUp is C:\Users<entra domain admin account>\AppData\Local\Programs\desktop\ClickUp.exe

Thanks for testing and for the detailed feedback — that behavior is expected, and it confirms the root cause.

Why --scope machine didn't work here

ClickUp's installer is a per‑user (Squirrel/NSIS) installer. It always installs into the launching user's profile (%LocalAppData%\Programs\desktop\ClickUp.exe) and effectively ignores the --scope machine flag — winget can only honor machine scope if the underlying installer actually supports a machine‑wide/Program Files install. ClickUp's standard .exe does not, which is why it only appeared under the admin account you elevated with. [github.com]

So this isn't an AVD or Nerdio limitation — it's the packaging of the ClickUp .exe itself.

Recommended approach please use ClickUp's MSI for a machine‑wide install

ClickUp provides a machine‑wide MSI on request (via their support team). Deploying that MSI in device/SYSTEM context installs to C:\Program Files\…, which makes it available to all users on the multi‑session host — exactly what you need for a pooled host pool. [learn.microsoft.com]

1. Request the MSI from ClickUp support (their website .exe is a per‑user stub and won't work for all‑user deployment).
2. Deploy it machine‑wide on the base/golden image (or via Nerdio), e.g. in an elevated/SYSTEM context:

      PowerShell
      1 msiexec /i "ClickUp.msi" /qn ALLUSERS=1
      
   

3. Reseal/recapture the image in Nerdio and reprovision the host pool so every session host carries the all‑user install.

A note on updates (worth flagging to your users): with the MSI installed to Program Files, the built‑in updater needs admin write access, so auto‑updates won't apply silently for standard users. Plan to manage version updates through Nerdio/your image refresh cycle (or Intune) rather than relying on Click Up's self‑update. [learn.microsoft.com]

Alternative (if you prefer to avoid base‑image installs): package ClickUp as MSIX App Attach and deliver it to the host pool. This keeps the app layered and out of the golden image, which can simplify lifecycle management on multi‑session pools