MSI 1730 and 1925: You Must Be an Administrator to Install or Remove This

Fix it now

Windows Installer is refusing to change machine-wide state for an account that is not entitled to change it. 1925 is the install-time refusal; Microsoft publishes 1730 as the removal-time one. Neither is a fault in the package and neither is fixed by reinstalling anything.

whoami /groups
net localgroup Administrators
msiexec /i "C:\path\to\package.msi"
msiexec /x {ProductCode}

1. Read the whoami /groups output. You need the Administrators group present and enabled, and a high mandatory integrity level; if either is missing you are not actually elevated.
2. Install from that prompt rather than from Explorer. To remove a product, use the product code rather than the original file.
3. If elevation succeeds and the install still fails on a managed machine, run gpresult /h %USERPROFILE%\Desktop\report.html and read the Windows Installer settings under Administrative Templates.

Do not enable AlwaysInstallElevated to make the prompt go away. It lets any user install any package with full system rights and is a documented privilege-escalation weakness.

If the package installs or removes cleanly from the elevated prompt you are finished. If not, the next section explains what the installer is actually checking.

Why it happens

A Windows Installer package can install for everyone on the machine or for the current user only. A per-machine install writes into Program Files and the machine registry hive, so it needs administrative rights, and the installer checks for them before it starts rather than failing halfway through and rolling back. 1925 is that check failing, and its published text says so: you do not have sufficient privileges to complete this installation for all users of the machine.

1730 is the same check at removal time, and its published wording is narrower than most write-ups suggest – it is about removing an application, not installing one. The product was registered per-machine, so undoing it means undoing machine-wide changes. This is what bites when a machine set up by an administrator is handed to a standard user: the applications work perfectly and nothing can be removed.

740 and its HRESULT form 0x800702E4 are the operating system saying the same thing one layer down. Microsoft publishes 740 as ERROR_ELEVATION_REQUIRED, “The requested operation requires elevation”. You meet these when a script, a scheduled task or a wrapper executable launches setup without requesting elevation, so no prompt ever appears and the call is refused outright.

Full reference

The published wording

That last row is worth internalising because it generalises. Any code of the form 0x8007xxxx is a Win32 error wrapped as an HRESULT, and the last four hexadecimal digits converted to decimal give you the number to look up. It turns a great many opaque installer codes into something you can read.

Which situation you are in

Removing a product without the original media

Uninstalling a per-machine product needs its product code, not its MSI file. The uninstall entries under the registry list installed products, and MSI-based ones are keyed by product code in braces. Reading that branch is safe and read-only:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" /s /f DisplayName

reg query "HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" /s /f DisplayName

The second command is the 32-bit view on 64-bit Windows, and it is where most desktop applications actually appear. Take the key name in braces and pass it to msiexec /x.

msiexec /x removes the product and its registration immediately, and with /qn there is no confirmation at all. Check the product code before you run it, and make sure anything you need has been backed up.

What a standard user can and cannot do

• A package authored for per-user installation writes into the user profile and the user hive only, and needs no elevation. Whether one exists is decided by the package author.
• A per-machine package cannot be made to install per-user by passing a property at the command line. If the author did not build it that way, it does not work that way.
• Windows Home enforces the same rules as Pro. What it lacks is the local Group Policy editor, so installer policy is inspected through the registry or your management tooling instead.
• Running as the built-in Administrator bypasses the filtered token, but it is not a fix for a policy restriction and it is not a supported way to run day to day.
• If a machine needs software installed by people who are not administrators, that is a deployment design question, not an error to work around.

Every code this article covers

Confirm the fix worked

1. Rerun the install from an elevated prompt and confirm it finishes without an error dialog.
2. Check the product appears in Settings, Apps, Installed apps.
3. From the same elevated prompt, confirm msiexec /x {ProductCode} is allowed against a test package.
4. If the failure was in a deployment tool, rerun the deployment and confirm the tool records a success code rather than 1925.
5. Run whoami /groups once more and keep a note of what a genuinely elevated session looks like on this machine.

Questions people ask about this