Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

License Error 1625

MSI 1625: This Installation Is Forbidden by System Policy – How to Unblock

12 min read Updated October 4, 2026 Installers, Runtimes & App Deployment

Fix it now

1625 is ERROR_INSTALL_PACKAGE_REJECTED: this installation is forbidden by system policy. It is a deliberate refusal rather than a fault in the package or the machine, and re-downloading will not change it. Three mechanisms produce it – the Windows Installer policy, AppLocker, and Software Restriction Policy – and each leaves a different trace, so the first job is finding out which one is speaking.

Run these in an elevated Command Prompt, then open the report

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer"
gpresult /h %USERPROFILE%\Desktop\gp.html
  1. Check the installer policy first. A DisableMSI value of 1 disables the installer for unmanaged applications; a value of 2 disables it for everything, including repairs, reinstalls and install-on-demand.
  2. Check AppLocker: Event Viewer, Applications and Services Logs, Microsoft, Windows, AppLocker. Event 8007 is logged when AppLocker blocked the named script or MSI, and only in Enforce rules mode.
  3. Check Software Restriction Policy, which writes its decisions into the Application log naming the blocked program.
  4. Fix the rule at its source – the domain policy or the local security policy – then run gpupdate /force and retry.
  5. On Windows Home there is no policy editor, but the policy values are still honoured, so read and correct them in the registry directly.

AppLocker needs the Application Identity service running to enforce anything. If rules appear to be ignored rather than enforced, check that service before rewriting the rules.

If the package installs and a second, unrelated one does too, you are done. If it still refuses, the next section separates the three gates that share this error number.

Why it happens

The Windows Installer policy is the bluntest of the three and the easiest to check. It is a machine policy under HKLM\Software\Policies\Microsoft\Windows\Installer, and Microsoft documents the values precisely: 0 enables the installer for all applications and allows every install operation; 1 disables it for unmanaged applications while leaving managed ones working, blocking non-elevated per-user installations; 2 disables the installer for everything, with no installs allowed at all, including repairs, reinstalls and on-demand installation. It applies regardless of where the package came from or who is running it.

AppLocker is the application control mechanism, and it treats installer packages and scripts as their own rule collection separate from executables. When it blocks a package it writes event 8007 into its own channel with the file name, and Microsoft is specific that 8007 appears only when the enforcement mode is Enforce rules – in Audit only mode you get 8006 instead, which tells you what would have been blocked. Enforcement also depends on the Application Identity service running, which the AppLocker documentation lists among the system services required.

Software Restriction Policy is the older mechanism, still present and still deployed. It works from a default level plus exceptions by path, hash, certificate or zone, and it records its decisions in the ordinary Application log rather than a dedicated channel. Two further codes belong to a different gate again: 1640 and 1645 both concern installing from a remote session. Microsoft’s wording for 1640 is that the current user is not permitted to perform installations from a client session of a server running the Terminal Server role service, and 1645 is that Windows Installer does not permit installation from a Remote Desktop Connection.

Windows Installer is disabled by policy

You have this one if DisableMSI exists under the installer policy key with a value of 1 or 2, and every package fails identically.

  1. On a domain machine, find the policy setting it and correct it there rather than on the client.
  2. Run gpupdate /force and confirm the value has changed or gone.
  3. On a standalone machine with the policy editor available, set Turn off Windows Installer back to Not Configured or Disabled.
  4. Where no editor exists, remove the DisableMSI value from the registry key directly after exporting it.

A value of 1 is not a broken setting: it permits managed installations and blocks unmanaged ones. If your deployment tool installs successfully and a user double-clicking the same package does not, that is 1 doing its job.

An AppLocker rule is blocking the package

You have this one if Event 8007 appears in the AppLocker channel at the moment of the failure, naming the file.

  1. Read the event to see which rule matched and on what condition.
  2. Add a rule permitting the package. Prefer a publisher rule over a path rule, so a moved or renamed file does not slip past.
  3. Confirm the Application Identity service is running, since rules are not enforced without it.
  4. Refresh policy with gpupdate /force and retest on one machine before rolling the change out.

Event 8006 rather than 8007 means the policy is in Audit only mode and did not actually block anything. If you have 8006 and a failed install, something else refused it.

Software Restriction Policy is blocking it

You have this one if The Application log names the blocked program at the moment of the attempt, on a machine with a restrictive default level.

  1. Open Local Security Policy, or the domain policy, and find Software Restriction Policies.
  2. Add a targeted rule for the deployment staging folder, or a certificate rule for the vendor’s signature.
  3. Avoid loosening the default level; a narrow exception is the safer change.
  4. Refresh policy and retry.

The install is being run from a remote session

You have this one if 1640 or 1645 rather than 1625, and the person installing is connected over Remote Desktop.

  1. Install from the console, or use a deployment tool that runs in the machine context rather than in the user’s remote session.
  2. On a session host, put the server into the appropriate install mode before installing per-machine software.
  3. Confirm the package installs per-machine rather than per-user, which is the correct model on shared session hosts.
  4. Where policy deliberately prevents remote installation, route the request through your deployment process rather than working round it.

You are on an edition with no policy tooling

You have this one if Windows Home, no policy editor and no local security policy console, and no obvious way to see what is blocking the install.

  1. Inspect the policy registry keys directly. The values are honoured on Home even though the editors are absent.
  2. Check HKLM\Software\Policies\Microsoft\Windows\Installer and the equivalent key under HKCU for values placed there by software or by a previous administrator.
  3. Export anything you find, then remove the values you did not intend to be there.
  4. If the machine needs to be managed properly rather than repaired once, an edition with the management tools is the honest answer.

Full reference

The Windows Installer machine policy values

DisableMSI Effect
0 Windows Installer is enabled for all applications; all install operations are allowed
1 Disabled for unmanaged applications, still enabled for managed ones; non-elevated per-user installations are blocked, while per-user elevated and per-machine installs are allowed
2 Always disabled for all applications; no installs are allowed, including repairs, reinstalls and on-demand installations

The key is HKLM\Software\Policies\Microsoft\Windows\Installer, and other values there are worth knowing while you are looking: DisablePatch stops patches being applied, DisableRollback stops rollback files being written – Microsoft advises against using it unless it is absolutely essential – and TransformsSecure requires transforms to be cached where the user cannot write to them. All of them can produce refusals that look like a broken package.

Which log recorded the refusal

Mechanism Where it records the decision
Windows Installer policy No event; the evidence is the registry value itself
AppLocker Its own channel under Applications and Services Logs, Microsoft, Windows, AppLocker – event 8007 when a script or MSI was blocked under Enforce rules
AppLocker in audit mode Event 8006 in the same channel: allowed to run, but would have been blocked if the policy were enforced
Software Restriction Policy The ordinary Application log, naming the blocked program

Only one of the three will have recorded anything at the moment you tried, which makes this a quick elimination rather than a guessing game. Check the registry value first because it takes ten seconds, then the AppLocker channel, then the Application log.

AppLocker and Windows editions

The old rule that AppLocker enforcement was an enterprise-only feature no longer holds, and acting on it will send you down the wrong path. Microsoft’s current requirements state that AppLocker policies are supported on all editions of Windows 10 version 2004 and newer with KB 5024351, and on Windows 11, with the full set of rule collections including Windows Installer. It is only on Windows versions older than 2004 that Group Policy-deployed AppLocker policies were limited to Enterprise and Server editions, with MDM-deployed policies supported on all editions. So a Windows Pro machine can be enforcing AppLocker, and the edition tells you nothing about whether it is.

Working with the policy rather than round it

  1. Establish which mechanism refused the install before changing anything. Three gates share one error number and they have three different owners.
  2. On a managed machine, take the answer to whoever owns the policy. Editing the client is a diagnostic at best; the value returns at the next refresh.
  3. Where a rule genuinely needs to change, prefer the narrowest possible exception: a publisher rule over a path rule, a staging folder over a drive.
  4. Test on one machine with gpupdate /force before rolling the change out, and confirm no new block events were written.
  5. Document the exception where it will be found again. An undocumented AppLocker exception is a future incident.

Export HKLM\Software\Policies\Microsoft\Windows\Installer before editing it. If a domain policy is setting the value it will return at the next refresh, so editing the client tells you what the block was without fixing anything – which is useful, as long as you know that is what you are doing.

When a licence is the actual fix

Be clear about what an edition upgrade does and does not solve here. The policy values that produce 1625 are honoured on Windows Home as well, and you can inspect and remove them with the registry editor at no cost – so if you only need to clear this error once, buying anything is unnecessary. It also will not buy you out of AppLocker: Microsoft now supports AppLocker policies on all editions of current Windows, so Pro adds nothing there either. What Pro genuinely adds is the tooling and the management model. Microsoft lists Group Policy, support for Active Directory and BitLocker device encryption among the Pro features Home does not have, which is the difference between guessing at registry values and reading a policy that somebody owns. If this machine has to be managed rather than repaired, Arco supplies Windows 11 Pro upgrade licences and will confirm whether the device can take an in-place edition upgrade rather than a rebuild.

Every code this article covers

Code What it points at Source
1625 ERROR_INSTALL_PACKAGE_REJECTED: this installation is forbidden by system policy Microsoft Learn
1640 ERROR_INSTALL_REMOTE_DISALLOWED: the current user is not permitted to perform installations from a client session of a server running the Terminal Server role service Microsoft Learn
1645 ERROR_INSTALL_REMOTE_PROHIBITED: Windows Installer does not permit installation from a Remote Desktop Connection Microsoft Learn
Event ID 8007 AppLocker: the named script or MSI was prevented from running; logged only when the enforcement mode is Enforce rules Microsoft Learn
Event ID 865 Widely reported as the Application log entry Software Restriction Policy writes when it blocks a program, but no current Microsoft documentation page could be found publishing that number, so treat the number as unverified and read the Application log for entries naming the blocked program instead not found in current Microsoft documentation

Confirm the fix worked

  1. The installation starts rather than returning 1625.
  2. No new AppLocker 8007 events, and no new Software Restriction Policy entries in the Application log, at the time of the attempt.
  3. gpresult /h shows the setting you changed now carrying the value you intended.
  4. A second, unrelated package installs, which proves the block was policy-wide rather than specific to one file.
  5. The result survives a gpupdate /force, so you know a domain policy is not about to put it back.

Questions people ask about this

Can I bypass the policy locally?

On a machine you own, yes: the values are in the registry and you can remove them. On a managed machine, no, and you should not try. The policy exists because somebody decided it should, and the correct route is a request to whoever owns it.

Do I have to buy Windows Pro to fix this?

No. The blocking settings are registry values that Home honours and that you can inspect and remove for nothing. Pro is worth buying when you want the management tooling and domain join, not as a way of clearing one error.

Why do my AppLocker rules seem to be ignored?

Check the Application Identity service first – AppLocker lists it among the system services it requires, and rules are not enforced without it. Then check the enforcement mode: event 8006 rather than 8007 means the policy is in Audit only mode and is reporting rather than blocking.

Is AppLocker still Enterprise-only?

No, and assuming so will waste your time. Microsoft’s current requirements state that AppLocker policies are supported on all editions of Windows 10 version 2004 and newer with KB 5024351, and on Windows 11. The edition-based restriction applied to Group Policy deployment on older versions.

Which policy is blocking me, if there are several?

Let the evidence tell you. The installer policy leaves a registry value and no event, AppLocker writes to its own channel, and Software Restriction Policy writes into the Application log. Only one of the three will have recorded anything at the moment you tried.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix Error 1601 and 1719: Windows Installer Service Could Not Be Accessed License Error 0x80070005: Access Denied During Install When Endpoint Protection Blocks It Free Fix MSI 1618: Another Installation Is Already in Progress – Clearing the Lock Free Fix 0x800F0906 and 0x800F081F: .NET Framework 3.5 Will Not Enable on Windows
← Back to Knowledge Base