Fix 0x00000673: Windows Installer blocks managed advertised product updates
This error appears when Windows Installer refuses to update an app installed via Group Policy or SCCM. The fix is to run the installer as System or disable enforced advertisement.
Cause 1: You're running the MSI as a standard user on a managed machine
I know this error is infuriating — you just want to update an app and Windows tells you no. The most common reason for 0x00000673 is that the original application was deployed via Group Policy Software Installation (GPSI) or System Center Configuration Manager (SCCM) as a managed advertised product. That means Windows Installer records the app as managed under the machine account, not your user account. When you run the installer as a regular user, even as an admin, Windows blocks the update because it sees the product as advertised — basically, a stub that points to a network location.
The real fix here is to run the MSI with system-level privileges. Don't use runas /user:Administrator — that's still a user context. Use PsExec from Sysinternals to launch the installer as the SYSTEM account:
psexec -i -s msiexec /i "C:\Path\To\Update.msi"
This bypasses the user-context check and lets Windows Installer apply the patch to the managed product. I've used this trick hundreds of times on Windows 10 22H2 and Server 2019 — it works.
If you don't have PsExec, you can schedule a task to run as SYSTEM:
schtasks /create /tn "UpdateManagedApp" /tr "msiexec /i \"C:\Path\To\Update.msi\"" /sc once /st 00:00 /ru SYSTEM
schtasks /run /tn "UpdateManagedApp"
schtasks /delete /tn "UpdateManagedApp" /f
The task runs immediately and deletes itself. Clean and fast.
Cause 2: The product was advertised but never fully installed
This tripped me up the first time too. Sometimes an app is deployed as advertised — meaning Windows Installer knows about it, but the actual files are on a network share and only installed on demand. If you try to patch or update an advertised product, you get 0x00000673 because there's nothing to update locally.
Check this with:
msiexec /l* %temp%\install.log /i "\\server\share\OriginalApp.msi" ADDLOCAL=ALL
Notice I'm using ADDLOCAL=ALL — that forces a full local install, not an advertise. After that runs, the product is no longer advertised and you can apply patches normally.
For SCCM environments, don't try to manually patch. Instead, deploy the updated MSI through a new application or package. That way SCCM handles the transition from advertised to installed correctly.
Cause 3: Group Policy Software Installation (GPSI) is still assigning the product
If the app was deployed via Active Directory GPSI, the policy may still assign the older version. Even after you update it manually, the policy re-advertises the old version on next policy refresh. This is a loop from hell.
Here's the fix: remove the old GPSI assignment first. On a domain controller, open Group Policy Management Console, edit the relevant GPO, go to Computer Configuration > Policies > Software Settings > Software installation, right-click the old package, select All Tasks > Remove, and choose Immediately uninstall the software. Then redeploy the updated package with a new MSI version number.
Don't reuse the same MSI version — Windows Installer caches product codes. Bump the version number in the MSI (or at least generate a new ProductCode). The old advertised reference will be gone, and the new one will install cleanly.
Quick-reference summary table
| Cause | Symptom | Fix |
|---|---|---|
| Running as standard user | Error on any update attempt | Run msiexec as SYSTEM via PsExec or scheduled task |
| Product only advertised, not installed | Error when patching; product appears in Add/Remove Programs but with no size | Reinstall with ADDLOCAL=ALL or use SCCM to deploy full app |
| Active Directory GPSI still assigning old product | Error reoccurs after policy refresh | Remove old package assignment from GPO, deploy new version with updated ProductCode |
Was this solution helpful?