Windows Installer has a documented policy that changes who executes a package. When it is enabled, a standard user can install a package with elevated privileges without a prompt, and the installer's actions run in a privileged context. The setting is a pair of registry values that must both be present, and it appears in configuration baselines precisely because enabling it is easy and remembering it is hard.
What the setting does
Microsoft documents AlwaysInstallElevated as a Windows Installer policy. When the policy is enabled for both the machine and the current user, Windows Installer runs installation packages with elevated privileges. The documentation describes the intent plainly: it allows users without administrative rights to install software that requires system-level changes.
The mechanism is the installer's own engine. msiexec reads the policy, and if it is set, the engine runs the package's custom actions in an elevated context rather than the caller's. A package's custom actions can execute arbitrary commands, write files anywhere, and modify services. That is what an installer is for.
The consequence follows directly. A user who can run msiexec against a package they authored can execute code as SYSTEM, without exploiting a memory-corruption bug and without a privilege-escalation chain. The exposure is a configuration the organisation chose, and the exploitation is the feature working as documented.
Why both keys matter
The policy exists at two scopes: HKEY_CURRENT_USER and HKEY_LOCAL_MACHINE, under the Windows Installer policy path, with the value name AlwaysInstallElevated. Microsoft's documentation states that the setting must be enabled in both locations for the behaviour to apply.
That two-key requirement is the reason an audit that checks only one location produces false negatives. A machine-wide value that is set while the per-user value is absent does nothing for a standard user. A per-user value set by a user in their own hive is meaningless without the machine value. Both present is the condition, and both are registry values a scanner can read.
The two scopes also imply different remediation paths. The machine value is a policy an administrator set, likely through Group Policy or an imaging baseline. The per-user value can be written by the user's own process, which means a user who wants the behaviour can set half of it themselves and only needs the machine half to exist.
How it accumulates in real environments
The setting rarely appears because someone decided to weaken a machine. It appears because a software deployment requirement was solved once with a policy, and the policy outlived the requirement.
The common origin is a legacy installer that assumed elevation. Rather than repackage it, an administrator enables the policy on a department's machines so the install completes without a support call. The policy is applied through a Group Policy object, the ticket is closed, and the setting remains after the application is retired.
The second origin is an image. A base image built for a lab or a training environment includes the setting because users needed to install tools. The image is later reused for a production build, and the registry value travels with it without anybody reading the full baseline.
The third origin is a third-party application's own installer, which sets the machine value as part of its prerequisites. The application is legitimate, the requirement was real, and the policy stays after the application is removed.
Detection that works
Read both values explicitly and report their combined state rather than a boolean per key. The useful output is a list of hosts where both are present, because those are the hosts where the documented behaviour applies.
Include the per-user hive in the scan where the tooling supports it. A machine-wide scan alone answers half the question, and the half it misses is the one a user can influence.
Correlate with installation activity. An MSI executed from a user-writable directory by a standard user is the behaviour this policy enables, and the event records for installation are the place the two facts meet.
Remediation that sticks
Remove both values, then find the requirement that caused them. Removing the policy without addressing the deployment need produces a support ticket that re-enables it within a month.
Where a specific installer genuinely needs elevation, use a deployment tool that runs it as an administrator rather than a policy that grants the capability to every package. The distinction is between one approved package and an open capability.
Verify the removal across the estate rather than on the host that was reported. A Group Policy object that set the value will set it again on the next refresh unless the object itself is changed.
The review question
For a host with the policy enabled, the question is not whether someone could use it. It is which users on that host can write an MSI to a location they control, and whether anything would notice the installation. On a workstation with a single user and no installation monitoring, the capability is available and unobserved.
References
Microsoft, AlwaysInstallElevated property: https://learn.microsoft.com/en-us/windows/win32/msi/alwaysinstallelevated
Microsoft, Windows Installer documentation: https://learn.microsoft.com/en-us/windows/win32/msi/alwaysinstallelevated