Fix CS_E_OBJECT_NOTFOUND 0x80040169 in Active Directory

This error shows when Windows can't find software installation data in Active Directory. Usually happens during Group Policy Software Installation (GPSI) when the target folder is missing or corrupted.

You're pushing out an MSI through Group Policy Software Installation (GPSI), and suddenly Windows throws up 0x80040169 — CS_E_OBJECT_NOTFOUND. The exact message reads: "There is no software installation data object in Active Directory."

This error typically blows up when you try to assign or publish an application via a GPO that targets Windows 10 or 11 workstations. It can also show during gpupdate /force on a machine that's supposed to install software from AD. I've seen it most often after someone deletes a GPO's software installation container by accident, or when the AD replication breaks and a domain controller doesn't have the object.

What's actually broken

Active Directory stores software installation data in a specific object under each GPO's cn=<GUID>,cn=Policies,cn=System,dc=<domain> path. The container is called cn=Software Installation. If that object is missing — either because it was deleted, never created, or the GPO is corrupt — Windows can't read the list of applications to install.

The real fix is creating that object back, then re-linking the MSI. Don't waste time chasing ghosts in Group Policy Management Console (GPMC). You need ADSI Edit.

What you'll need

Domain admin rights
ADSI Edit installed on a domain controller (or RSAT tools on a member server)
The GPO's GUID — you'll get this from GPMC

Step-by-step fix

Open ADSI Edit — go to Administrative Tools > ADSI Edit, or run adsiedit.msc.
Connect to the domain — right-click ADSI Edit in the left pane, choose Connect to.... Make sure Configuration is selected, then click OK.
Browse to the GPO — expand the tree: CN=Services > CN=Public Key Services > CN=GPO. Wait — that's not right for software installation. The correct path is under CN=System,CN=Policies. Let me reorient you:
Actually, for software installation data, the object lives in the domain partition, not the configuration partition. Disconnect from Configuration and reconnect to Default naming context (your domain).

So: right-click ADSI Edit > Connect to... > select Default naming context, pick one of your domain controllers, click OK.

Now expand: DC=<yourdomain>,DC=<suffix> > CN=System > CN=Policies. You'll see a list of GUID-named folders. Each one is a GPO.

After expanding CN=Policies, you should see entries like CN={31B2F340-016D-11D2-945F-00C04FB984F9}. That's the Default Domain Policy. Your GPO will have a similar GUID.
Find your GPO's GUID — open GPMC, find the GPO that's failing, right-click it, choose Properties, and look at the General tab. Under Unique ID, you'll see the GUID. Write it down.
Back in ADSI Edit, locate the GPO's folder under CN=Policies. Click on it. You should see at least two objects inside: CN=Computer and CN=User. Under each, there should be a CN=Software Installation object. If it's missing from CN=Computer (where most software installs go), that's your problem.
Create the missing container — right-click on CN=Computer (or CN=User if the software is user-targeted), choose New > Object. Select class container, click Next. For the name, type exactly: Software Installation. Click Finish.
After clicking Finish, you should see a new CN=Software Installation appear under that GPO's Computer node. If you don't see it, press F5 to refresh.
Re-add your software package — go back to GPMC, edit the GPO. Navigate to Computer Configuration > Policies > Software Settings > Software installation. Right-click Software installation (the empty node), choose New > Package, point to your MSI's network share path (UNC). Choose Assigned, click OK.
You should see the package appear in the right pane. Run gpupdate /force on a test machine to verify.
Force replication — open Command Prompt as admin on the domain controller where you made the change. Run repadmin /syncall /AdeP. This ensures the new object replicates to all DCs.
After replication completes, run gpresult /r on a test workstation to confirm the GPO is applying and the software installation section is populated.

If it still fails

Check these three things in order:

Permissions — right-click the GPO in GPMC, go to Delegation. Make sure Authenticated Users (or your target security group) has Read and Apply Group Policy.
64-bit weirdness — if your MSI targets 64-bit systems, make sure you're editing the GPO from a 64-bit machine. The Software installation node sometimes acts flaky on 32-bit MMCs.
Wait for replication — if you forced replication but the client still errors, check the event log on the client: Application and Services Logs > Microsoft > Windows > GroupPolicy > Operational. Look for event ID 4016 or 4017. They'll point to the specific DC that's missing the object.

One last thing — if the GPO was originally created on a retired server, the GUID might still exist in AD but the Software Installation container never got created because the old server died mid-write. In that case, delete the whole GPO from GPMC (backup first), recreate it, and re-link. That nukes the orphaned GUID and gives you a clean slate.