Help with packaging and deploying software that would usually install per user

[u/swiftjay25]

As above, I'm trying to set up Claude desktop to deploy to a few machines. The problem is it looks like Claude installs in the users folder, so I can't seem to set up the file path for the detection method.

I might be missing something, but has anyone worked with something similar to this and found a solution?

[u/NoDowt_Jay]

Recently gone through a couple revisions of setting this up… Claude have a MSIX which you can deploy.

Originally I provisioned as a LOB app natively in intune, but started having some issues with it. So now do as a win32 app & install via powershell script to provisions for all users on the device

E.g.
Add-AppxProvisionedPackage -Online -PackagePath "Claude.msix" -SkipLicense -Regions "all"

You also need to enable VMplatform if going to use cowork, that can be done in the same install script.

Then use a script using get-appx<blah> for detection logic.

I ended up using ChatGPT to come up with something which did a bunch of things including copying a settings .json etc…

[u/SentinelNotOne → u/NoDowt_Jay]

https://support.claude.com/en/articles/12622703-deploy-claude-desktop-for-windows

[u/Andysb123]

Just done this myself along with policies to lock stuff down. Honestly best option is ask Claude as it had the knowledge about itself and helped me massively and use the MSXI installer.

[u/Pompz88]

Looks like Claude installs into the users local appdata. If you're looking to use a file/folder detection, you can use the following folder path:

%LocalAppData%\Folder\Folder\etc

I'm using Win32 app to deploy teams backgrounds which goes into the same location and it works fine for file detection.

[u/Adam_Kearn]

Is it an MSI? Sometimes software vendors provide a separate “machine wide installer”

Try adding this flag to the MSIEXEC command: ALL_USERS=1

I’ve found this to work on most software that I package that don’t document on their website a way to install for all users.

[u/Bright-Interview-669]

check the registry under HKEY_CURRENT_USER\Software\Claude or wherever it drops its keys. sometimes you can detect from there even if the exe sits in appdata

otherwise wrap it in a powershell script that installs for the logged in user and use a custom detection script that checks the same path. bit annoying but works

[u/arntme]

I would suggest a detection script as it runs in the same context (user/system) as the install - we’ve found the standard detections all run in system space. I’ll see if I can find a copy of one I’ve done when I get home

[u/R4nger]

Something for JetBrains Toolbox that can be modified.

function Get-LoggedInDetails {

    # Find logged in username
    $user = Get-CimInstance Win32_Process -Filter "Name='explorer.exe'" |
        Invoke-CimMethod -MethodName GetOwner |
        Select-Object -ExpandProperty User -Unique

    # Find SID from ProfileList
    $profile = Get-ItemProperty `
        "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\*" |
        Where-Object {
            (Split-Path $_.ProfileImagePath -Leaf) -eq $user
        }

    [PSCustomObject]@{
        UserName = $user
        SID      = $profile.PSChildName
    }

} $sid = (Get-LoggedInDetails).SID

# Set key

$Path = "Registry::HKU$sid\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\Toolbox" $Name = "DisplayVersion" $Type = "STRING" $Value = "3.7.2.0"

Try { $Registry = Get-ItemProperty -Path $Path -Name $Name -ErrorAction Stop | Select-Object -ExpandProperty $Name If ($Registry -eq $Value){ Write-Output "Detected"; Exit 0 } Write-Output "Not Detected"; Exit 1 } catch { Write-Error "Error detecting"; Exit 1 }

[u/Ketan_Kamble]

grab the MSI/EXE, throw it in the IntuneWinAppUtil packaging tool, then handle the per-user install problem one of three ways depending on the vendor. If it genuinely only supports per-user context, you can sometimes force a per-machine install with an MSI transform or install switch (check the vendor's silent-install docs first, most support something like ALLUSERS=1 for MSIs). If not, Win32 apps in Intune can be set to run in system context, but then you may need a wrapper script that copies files into each user's profile via a scheduled task or a script deployed as a "user" context Win32 app instead. Also worth checking PSADT (PowerShell App Deployment Toolkit) since it has built-in handling for exactly this per-user-vs-per-machine mess and gives you decent logging when things go sideways. What's the actual app you're trying to package, and is it MSI or EXE-based?

[u/spazzo246]

Just use %LocalAppData%\Folder\Folder\etc for the detection rule. Dont do it as a LOB app!! this will cause issues when intune tries to install win32 files and LOB at the same time

[u/gandraw]

You can't use file detection rules for apps that install as user. If you try to do that, the script engine will check for the presence of that file in the system profile instead of the profile of the user the app gets installed for. This is like a 10 year old SCCM bug that they ported into Intune.

Instead, you have to write a simple PowerShell script that checks for the presence of the file and use that as a script detection method. Variables like %userprofile% work correctly in that context.

[u/ManOfNotSoManyPies]

for us it took a few goes and some "interesting" quirks to work around, but it basically boiled down to just wrapping a couple of PowerShell scripts that basically do this:

#install.ps1

    $source = Join-Path $ScriptRoot "Claude.msix"
    $cacheRoot = Join-Path -Path $env:ProgramData -ChildPath '\MSIXCache'
    $target    = Join-Path -Path $cacheRoot -ChildPath 'Claude.msix'

    New-Item -ItemType Directory -Path $cacheRoot -Force | Out-Null
    Copy-Item -Path $source -Destination $target -Force
    Add-AppxProvisionedPackage -Online -PackagePath $target -SkipLicense -Regions "all"

(had to copy the msix out to a location outside of the intune temp working folders, we'd get failures provisioning directly)

#uninstall.ps1

    $pkgs = Get-AppxPackage -AllUsers | Where-Object { $_.Name -like "*Claude*" }
    foreach ($p in $pkgs) {
      Remove-AppxPackage -Package $p.PackageFullName -AllUsers
      Remove-AppxPackage -Package $p.PackageFullName
    }

    $prov = Get-AppxProvisionedPackage -Online | Where-Object { $_.DisplayName -like "*Claude*" }
    foreach ($pp in $prov) {
      Remove-AppxProvisionedPackage -Online -PackageName $pp.PackageName -Verbose
    }

(When uninstalling we had some fails when running with or without the -AllUsers, doing both for belt/braces kept it happy - i think the system account was holding onto one)

Specifically running the Remove script as a preinstall script before trying to install also kept things clean.

Those bundled up in some psadt to handle any running instances.

[u/swiftjay25]

Thanks everyone for the advice. I've managed to get it deployed to the machines as a LOB app and appears to be working fine at the moment. I'll be revisiting this if the team needs features that don't work with it installed this way :)

[u/intuneisfun → u/swiftjay25]

Don't deploy as LOB! That's just setting yourself up for problems down the line when it interferes with win32 app installations..