CS_E_PACKAGE_NOTFOUND 0X80040164 – Active Directory package gone missing

You got 0x80040164. It's annoying, and it's almost always because something changed in Active Directory while the local client still thinks the package exists.

The error reads: No package in the software installation data in Active Directory meets this criteria. This usually rears its head when you try to install or remove a program that was originally deployed through Group Policy Software Installation (GPSI), but the underlying MSI or the GPO itself got deleted or moved. The client machine holds on to a stale reference in the local HKCU or HKLM registry, and when the installer runs, it looks up AD for the package—and finds nothing.

The fix: kill the orphaned AD package reference with ADSI Edit

Skip the GUI gymnastics. The straight path is to use ADSI Edit to remove the stale package entry from the domain’s software installation data. Here’s the exact sequence:

1. On a domain controller (or a machine with RSAT tools installed), open ADSI Edit. You can launch it from Administrative Tools or just type adsiedit.msc in the run box.
2. Right-click ADSI Edit in the left pane and choose Connect to. In the dialog, pick Default naming context and click OK.
3. Navigate down this tree: DC=yourdomain, DC=com → CN=System → CN=Policies → CN={GPO-GUID} → CN=Machine → CN=Microsoft → CN=Windows → CN=Group Policy → CN=Software Installation. Yes, it’s deep.
4. In the right pane, you’ll see entries that look like CN={Package-GUID}. Right-click the one that matches the program name in the error, choose Delete, and confirm.
5. Reboot the client machine. The error should be gone.

If you don’t know the GPO GUID: run gpresult /h gp.html on the client, open the HTML file, and look under Software Installation for the GPO display name. Then cross-reference that with Get-GPO -Name "DisplayName" in PowerShell to grab the GUID. Or just brute-force search the CN=Policies container in ADSI Edit—you’ll find it eventually.

No ADSI Edit access? An alternative: on the client, delete the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\State\Machine\Software\Installation and the corresponding user key under HKEY_CURRENT_USER. Then run gpupdate /force and reboot. This forces Windows to re-read AD, but if the GPO is gone, it’ll just silently remove the reference. I’ve seen this work more often than not.

Why this happens

What’s actually happening here is that Group Policy Software Installation stores package metadata in two places: the AD container under CN=Software Installation and the local registry. When the original GPO is deleted, the AD container entry stays put unless the GPO was removed through proper gpupdate /force on the client. The client registry entry doesn’t get cleaned up because Windows doesn’t automatically revert local policy state when a GPO is removed—it just marks the GPO as not applicable. That stale registry entry points to a package GUID that no longer exists in AD.

The error code 0x80040164 is COM error CS_E_PACKAGE_NOTFOUND, which means the client’s COM+ catalog (used by Windows Installer) queried AD for the package and got back a null result. The 0x8004 prefix indicates a configuration store error, not a file-system or network issue. So the root cause is always a mismatch between what the client thinks is deployed and what AD actually has.

Less common variations

Sometimes the error appears during an Office or Visual Studio repair installation. In those cases, the culprit is a stale entry in the Windows Installer configuration cache, not Group Policy. Run msiexec /unregister then msiexec /regserver as admin, then try the repair again. If that fails, use MsiZap.exe (from the Windows SDK) to nuke the orphaned product code—Msizap.exe T {ProductCode}. But be careful: Msizap can break other installers if you zap the wrong GUID.

Another variant: the error shows up after you migrate from on-prem AD to Azure AD or a different domain. The software installation data doesn't transfer—it's a per-domain object. You’ll need to re-deploy the application via Intune or a new GPO. There’s no migration path for this; the old packages die with the old domain.

Rarely, the issue is permission-related: the client machine account doesn’t have Read access to the CN=Software Installation container. Check delegation on the OU. If authenticated users lost read rights, you’ll see this error even if the package exists. Give Authenticated Users the Read permission on the container and propagate it.

Prevention

Don’t delete a GPO that deploys software until every client has either installed the package or had the software removed via a separate GPO. The safest workflow: create a new GPO that sets the package to Uninstall, deploy it, wait a few days for all clients to report back, then delete the original GPO. This ensures the registry state on every machine is clean.

If you’re forced to delete a GPO in an emergency, run gpupdate /force on all affected clients from a PowerShell script. Something like Invoke-GPUpdate -Computer (Get-ADComputer -Filter * -SearchBase "OU=Computers,DC=domain,DC=com").Name will push the update. After that, manually check a few machines for leftover package references in ADSI Edit and the registry. It’s tedious but beats the support ticket flood.

Finally, document every GPO GUID and package GUID in your change log. When you know exactly what GUID to search for in ADSI Edit, the cleanup takes 30 seconds instead of 30 minutes.