0x80073CFB: Intune MSIX Package Already Installed Fix

You upload a new build of an MSIX or APPX line-of-business (LOB) app to Intune, and devices that already had the app report 0x80073CFB. Devices that never had the app don’t hit it, because nothing is installed for the new package to clash with.

Microsoft’s Intune app installation error codes list it as: “The provided package is already installed, and reinstallation of the package is blocked.” The Windows packaging reference names it ERROR_PACKAGE_ALREADY_EXISTS and explains when you get it:

You may get this error if installing a package that is not bitwise identical to the package that is already installed. Note that the digital signature is also part of the package. Hence if a package is rebuilt or resigned, it is no longer bitwise identical to the previously installed package.

That’s from Troubleshooting packaging, deployment, and query of Windows apps. The new package has the same name, publisher and version as the one on the device but different contents, so Windows won’t replace it.

I haven’t reproduced this on a tenant for this article. The steps below come from the Microsoft pages linked inline.

Quick Fix checklist

1. On an affected device, open Event Viewer at Applications and Services Logs > Microsoft > Windows > AppXDeployment-Server > Microsoft-Windows-AppXDeploymentServer/Operational and find the error for your package.
2. Run Get-AppxPackage -AllUsers -Name <PackageName> as administrator and compare the installed version with the App version Intune shows for the new upload.
3. If the versions match, increment Version in the package manifest, rebuild, re-sign, and upload the new file to the same Intune app.
4. Only if you can’t change the version: remove the old package for every user on the device, then let Intune install the new one.

What 0x80073CFB means

In MSIX, a package identity stands for one exact set of bits. Howard Kapustein’s Third Rule of MSIX post on Microsoft’s Inside MSIX blog states the rule as “Package identity is unique across space and time” and explains the consequence: “If two packages share the same identity but contain different content, deployment will reject the second package with ERROR_PACKAGE_ALREADY_EXISTS.”

The identity comes from the Identity element in the manifest. Per the Identity element reference, Name, Publisher and Version are required, and Version is a quad like 1.2.3.4. A rebuild or re-sign that leaves those values alone keeps the same identity, so Windows sees the same identity with different content.

The same post shows the text Add-AppxPackage returns when you hit it by hand:

Deployment failed with HRESULT: 0x80073CFB, The provided package is already installed, and reinstallation of the package was blocked. Check the AppXDeployment-Server event log for details.

Why the obvious diagnosis can be wrong

“Already installed” reads like a detection or reporting problem, so the first instinct is to look at Intune’s reporting or to retry the assignment. Neither helps, because Windows refused the install on the device, and it will refuse again on every retry while the installed copy has the same identity.

Each of these ends in the same state, same version with different bits:

• A developer or build pipeline produced a new build without bumping Version.
• The same package was re-signed, for example with a different certificate, and re-uploaded. Microsoft is explicit that the signature is part of the package.
• Two different builds of one version are in circulation, and some devices got the other one first.

Don’t confuse it with nearby packaging codes. The Windows reference lists 0x80073CF3 as ERROR_INSTALL_RESOLVE_DEPENDENCY_FAILED (conflict, missing dependency or wrong architecture) and 0x80073D06 as ERROR_INSTALL_PACKAGE_DOWNGRADE (a higher version is already installed). Microsoft’s Deploy MSIX apps with Microsoft Intune guide describes 0x80073CF3 as a downgrade instead, so if you see that code, read the event log before you trust either label. 0x80073CFB is the one where the versions are equal.

Evidence to inspect

AppXDeployment-Server event log

The Windows packaging troubleshooting page says to start with the AppXDeployment-Server log:

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

Filter for errors at the time Intune reported the failure and look for your package family name. The MSIX deployment troubleshooting page notes that the event detail usually has a more specific error than the one shown in the UI.

From PowerShell, Get-AppxLog gets the app package installation log. Its reference page shows it returning the logs for the most recent deployment, so run it soon after the failure:

Get-AppxLog | Out-GridView

The installed version on the device

Run this from an elevated PowerShell session. Get-AppxPackage needs administrator rights for -AllUsers:

Get-AppxPackage -AllUsers -Name <PackageName>

Compare the version it reports with the App version in the Intune app’s Properties. Equal versions with a 0x80073CFB failure confirm the diagnosis.

Whether the app is provisioned

If the app was deployed in device context, check whether it’s also provisioned. Microsoft’s Enterprise app management page describes how an MDM server provisions a packaged app for all users through the EnterpriseModernAppManagement CSP in the device context. Provisioning stages the app so every user of the device gets it at their next sign-in, and removing a provisioned app “will not remove it from the users that already installed the app.” Check for a provisioned copy:

Get-AppxProvisionedPackage -Online

The verified fix

Fix 1 (recommended): bump the version and re-upload

If you control the package, this is the fix I’d use every time. It’s the first option in the Windows reference, and Intune expects it anyway. The Add a Windows line-of-business app page says: “For the Intune service to successfully deploy a new APPX file to the device, you must increment the Version string in the AppxManifest.xml file in your APPX package.” The MSIX Intune guide says the same for .msix: Intune uses the version number in the manifest to detect updates.

1. Increment Version in the Identity element of the manifest. Keep the quad format.
2. Rebuild and re-sign the package. The Publisher must still match the signing certificate subject, per the Identity reference.
3. In the Intune admin center, go to Apps > All apps, select the app, then Properties > Edit next to App information, and upload the new file under Select file to update.
4. Confirm App version now shows the new version, then save.

Devices with either of the old same-version builds update to the higher version. The Inside MSIX post says deployment “will then update to the newer package, regardless which variant was previously installed.”

Fix 2: remove the old package everywhere, then reinstall

Use this when you can’t change the version, for example a vendor package you can’t rebuild. Microsoft’s wording is “Remove the old package for every user on the system before installing the new package.” On a shared device, that means every user plus the provisioned copy.

From an elevated session:

# Remove the package for every user account
Get-AppxPackage -AllUsers -Name <PackageName> | Remove-AppxPackage -AllUsers

# If Get-AppxProvisionedPackage -Online listed it, remove the provisioned copy as well
Remove-AppxProvisionedPackage -Online -PackageName <ProvisionedPackageName>

I haven’t run these against a device for this article. Remove-AppxPackage documents -AllUsers, which needs administrator rights and works off the parent package type. For a bundle, its reference says to use -PackageTypeFilter with Get-AppxPackage and specify the bundle. Remove-AppxProvisionedPackage only stops the package from installing for new user accounts; it doesn’t touch existing users, which is why both commands are there. Add -WhatIf to Remove-AppxPackage first if you want to see what it would remove.

At scale, an Intune Uninstall assignment for the old app is cleaner than scripting it, and the MSIX Intune guide lists Uninstall as an assignment type that removes the app from targeted devices. Microsoft doesn’t say whether that covers every user profile and the provisioned copy, so check one device with Get-AppxPackage -AllUsers and Get-AppxProvisionedPackage -Online before you roll it wider. Once the old copy is gone, assign the new package as Required; the MSIX guide says devices receive and install the app during the next Intune sync cycle.

What not to waste time on

• Resyncing or reassigning the app. The device will keep refusing the same identity.
• Treating it as a certificate trust problem. Trust failures are separate errors; the MSIX troubleshooting table lists 0x8BAD0042 for an untrusted signing certificate.
• Removing the app for the signed-in user only on a shared device. Other users and the provisioned copy still hold the identity.

Prevention checklist

• Make a version bump part of every build that will ship, including a re-sign with no code change.
• Never upload two different files with the same Version to Intune, or to any other channel the same devices use.
• Before you upload, check that the App version Intune reads from the package is higher than what’s in production.
• Keep Publisher in the manifest matched to the signing certificate subject when you rotate certificates.
• After a fix, check one previously affected device in Event Viewer and with Get-AppxPackage -AllUsers before you call it done.

Related ZakitPro articles

• ESP fails with Another installation is in progress, if you’re mixing LOB and Win32 apps during Autopilot.
• The Intune app packaging decision matrix, for when MSIX is the right package type.
• Win32 app installed but Intune says failed, a different “it’s on the device but Intune disagrees” problem, for Win32 apps.

FAQ

What does 0x80073CFB mean in Intune?

It’s ERROR_PACKAGE_ALREADY_EXISTS. A package with the same identity is already installed, the new one isn’t bitwise identical, and Windows blocks the reinstall.

Why do I get 0x80073CFB after re-signing an MSIX with the same version?

Microsoft says the digital signature is part of the package, so a re-signed package is no longer bitwise identical to the installed one. Increment the version before you re-sign.

How do I fix 0x80073CFB without changing the version?

Remove the old package for every user on the device, and remove the provisioned copy if there is one, then install the new package.

Sources

All retrieved 2026-10-23.

• App installation error codes for Microsoft Intune, Microsoft Learn: 0x80073CFB in Intune’s error code list.
• Troubleshooting packaging, deployment, and query of Windows apps, Microsoft Learn: ERROR_PACKAGE_ALREADY_EXISTS, the two fixes, 0x80073CF3, 0x80073D06, and the AppXDeployment-Server log path.
• Third Rule of MSIX, Inside MSIX blog (Microsoft): package identity and the Add-AppxPackage error text.
• Identity element, Microsoft Learn: Name, Publisher, Version attributes.
• Add a Windows line-of-business app to Microsoft Intune, Microsoft Learn: update steps and the increment-the-version note.
• Deploy MSIX apps with Microsoft Intune, Microsoft Learn: version-based update detection and the Uninstall assignment.
• MSIX deployment troubleshooting, Microsoft Learn: event log detail and 0x8BAD0042.
• Enterprise app management, Microsoft Learn: provisioning for all users and removal behavior.
• Get-AppxPackage, Remove-AppxPackage, Get-AppxLog, Get-AppxProvisionedPackage and Remove-AppxProvisionedPackage, Microsoft Learn.