Fix CS_E_INVALID_VERSION (0X80040167) – Corrupt AD Software Install Data

The real cause: corrupt software installation data in AD

You're seeing CS_E_INVALID_VERSION (0x80040167) when trying to deploy software through Group Policy — or during any COM-based software installation operation that reads from Active Directory. What's actually happening here is the software installation data stored in the CN=Class Store container under your domain's System partition has become corrupted. The version field in one or more msiPackageRegistration objects doesn't match what the Group Policy client expects.

This almost always happens after a domain controller restore from backup, a botched ADSI Edit operation, or a third-party tool that modifies software installation objects directly. I've seen it most often on Server 2008 R2 and Server 2012 R2 domains that were restored from a backup that was older than the tombstone lifetime.

Let's walk through the fixes — start with the quickest one, then fall back to the nuclear option.

Fix #1 (most common): Delete the corrupt SDP entries in ADSI Edit

This is the fix I've used more than any other. You're going to delete the specific msiPackageRegistration objects that have bad version data. The system will recreate them on the next Group Policy refresh.

1. Open ADSI Edit (it's a feature you may need to install under Remote Server Administration Tools).
2. Connect to the Default Naming Context of your domain.
3. Navigate to CN=Class Store,CN=System,DC=yourdomain,DC=com.
4. Expand the CN=Class Store node. You'll see child containers like CN=Packaged Software and CN=Published Software.
5. Look for objects with objectClass=mspRegistryContainer or objectClass=msiPackageRegistration. These are the SDP entries (Software Deployment Packages).
6. Right-click each msiPackageRegistration object and select Delete. Don't delete the containers themselves — just the package registration objects inside them.
7. After deleting all of them, close ADSI Edit.
8. Open a command prompt as Administrator and run gpupdate /force to force a Group Policy refresh.
9. Try your software installation operation again.

The reason this works: When the Group Policy client refreshes, it reads the software installation policy from the GPO itself (which lives in the SYSVOL folder), not from the corrupt Class Store data. The client re-creates the Class Store entries from the policy files. This clears the bad version numbers that caused 0x80040167.

One caveat: This deletes ALL published and assigned software packages from the Class Store. Users won't be able to install or repair software from Add/Remove Programs until the GPO refreshes. That's usually a minute or two. Plan this during a maintenance window if you have a strict change control policy.

Fix #2: Restore the Class Store from a known-good backup

If deleting entries doesn't fix it — or if the corruption is deeper (e.g., the container itself is missing attributes) — you'll need to restore the Class Store data from a system state backup of a domain controller that predates the corruption.

1. Identify a domain controller that has a system state backup taken before the corruption occurred. The backup must include the Active Directory database (NTDS.DIT) and SYSVOL.
2. Perform an authoritative restore of CN=Class Store,CN=System,DC=yourdomain,DC=com. Here's the recipe:

# On the DC you're restoring, boot into Directory Services Restore Mode (DSRM).
# Restore the system state from backup using Windows Server Backup or your preferred tool.
# After the restore, run these ntdsutil commands:

ntdsutil
activate instance ntds
authoritative restore
restore subtree "CN=Class Store,CN=System,DC=yourdomain,DC=com"
quit
quit

# Then reboot normally.

This marks the Class Store subtree as authoritative, so it will replicate out to all other domain controllers, overwriting the corrupt data with the good version from the backup.

Why this works: An authoritative restore sets a higher version number on the restored objects than any other DC's replicas. So the restored data wins replication conflicts. The key is the backup must be from before the corruption — otherwise you're just restoring the same bad data.

I've only needed this twice in my career. The first fix (deleting SDP entries) resolves 90% of cases. Reserve this for when you've confirmed the corruption isn't limited to package registration objects — maybe the container itself got hosed or someone ran a recursive attribute deletion.

What not to do

• Don't delete the entire CN=Class Store container. That container is system-critical. If you delete it, COM-based software installation on your domain breaks completely — you'll get CS_E_CLASS_STORE_ERROR instead. You don't want that.
• Don't run a non-authoritative restore of the entire AD database. That'll pull the corruption back from another DC that has the same bad data. Must be authoritative on the specific subtree.
• Don't ignore the actual GPO. Sometimes the corruption is in the GPT.INI or the .adm files in SYSVOL. Check the GPO version counter. If it's spiked unusually high (like 65535), that's a different problem — one you fix by resetting the version counter, not by touching the Class Store.

Quick-reference summary table

That's it. Start with ADSI Edit, delete the bad packages, refresh Group Policy. Nine times out of ten you're done in ten minutes. If not, you've got the authoritative restore in your back pocket.