During build light.exe fails to run with LGHT1105 error

[chris-rossi]

Our build system has started returning an error that it cannot run light.exe after the past weekend. While building our project we get the following error:

light.exe : error LGHT1105: Validation could not run due to system policy. To eliminate this warning, run the process
as admin or suppress ICE validation.

My whole team of 5 is getting this error this week despite it working in the past. We tested in non-Intune managed environments and found that the build was able to complete with error but when we added Intune to the system the build began to fail. At the moment we have work arounds for this but it is impacting our development process. We have tried running the build with elevated privileges as the error message recommends but the error persists.

We also encounter this error while trying to validate any MSI using Orca.

[robmen]

Sounds like a policy change in Intune now prevents you from running validation (which actually executes an install to run the ICEs). The Event Viewer might show which exact policy is blocking you.

I hope you have a productive conversation with your IT department.

[aplum]

As both the developer and the IT department, unfortunately the previous answer wasn't terribly helpful. I knew what was causing the issue (AppLocker), but had no idea why, nor how to best fix it. The following is the result of my conversation with myself – if @chris-rossi could post the result of their conversation with IT that might also be helpful to someone!

Problem

Same errors as @chris-rossi. While trying out AppLocker on my machine, I started getting "light.exe : error LGHT1105" when trying to build an MSI using electron-builder, which uses WiX. Orca also started giving the "Validation Failed", "The validation engine could not start" error.

TL;DR solution

AppLocker is the reason for these errors. There is no rule you can set up to allow MSI validation to succeed. There are two options. They are not good options.

1. Delete all AppLocker rules for Windows Installer and uncheck "configured" for it. Or change it to "audit only" instead of "enforce rules".
2. If you have local admin rights, rename C:\Windows\System32\AppLocker\Msi.AppLocker to Msi.AppLocker.temp-disabled before starting a build, then rename it back after the build.

This seems like a bug in AppLocker or Windows Installer, or maybe related to this: "AppLocker will not allow any elevated and sandboxed processes launch". 🤷‍♂️

Full details

Logs

There doesn't appear to be much logging about the error.

• Nothing in Event Viewer > Applications and Services Logs > Microsoft > Windows > AppLocker > *.
• In Event Viewer > Windows Logs > Application: Error, event ID 1008, source MsiInstaller, "The installation of C:\Users\username\AppData\Local\Temp\ ICE2CAA.tmp is not permitted due to an error in software restriction policy processing. The object cannot be trusted."
• After enabling Windows Installer logging:
  • Nothing in C:\Windows\Temp.
  • This log at C:\Users\username\AppData\Local\Temp\MSI*.LOG. The log is the same regardless of whether AppLocker rules allow the file. My MSI is unsigned, but I also tried validating a signed MSI and the log still said "not digitally signed".

=== Verbose logging started: 2023-05-18  9:06:39  Build type: SHIP UNICODE 5.00.10011.00  Calling process: C:\Program Files (x86)\Orca\Orca.exe ===
MSI (c) (90:E0) [09:06:39:954]: Engine created on writable database - enabling validation mode.
MSI (c) (90:E0) [09:06:39:954]: SOFTWARE RESTRICTION POLICY: Verifying package --> 'C:\Users\username\AppData\Local\Temp\ICE2CAA.tmp' against software restriction policy
MSI (c) (90:E0) [09:06:39:954]: Note: 1: 2262 2: �DigitalSignature 3: -2147287038 
MSI (c) (90:E0) [09:06:39:954]: SOFTWARE RESTRICTION POLICY: C:\Users\username\AppData\Local\Temp\ICE2CAA.tmp is not digitally signed
MSI (c) (90:E0) [09:06:39:959]: SOFTWARE RESTRICTION POLICY: SaferIdentifyLevel reported failure.  Assuming untrusted. . . (GetLastError returned 87)
MSI (c) (90:E0) [09:06:39:959]: The installation of C:\Users\username\AppData\Local\Temp\ICE2CAA.tmp is not permitted due to an error in software restriction policy processing. The object cannot be trusted.

=== Verbose logging stopped: 2023-05-18  9:06:39 ===

Attempted solutions

I had AppLocker deployed via GPO. DLL rules are not enabled. The only "deny" rule was for an unrelated packaged app. I created local AppLocker rules to allow path * for Everyone for exe, msi, script, and appx. After a gpupdate, validation still fails in Orca, despite the AppLocker rules effectively being "everyone can run anything except this one (definitely unrelated) appx". Note that while MSI validation fails, installation works fine (as does blocking installation if the AppLocker rules don't allow it).

I removed the GPO from my machine and set up AppLocker locally instead. The following is all with only local AppLocker policies (and no "deny" rules). Throughout all of this, AppIDSvc was running as appropriate, gpupdate was run as needed, and some rebooting was done for good measure.

• With the same "everyone can run anything" rules: Orca validation fails.
• Uncheck "configured" for everything except MSI (MSI still set to "enforce"), one MSI rule "allow path * for Everyone": Orca validation fails.
• Change MSI to "audit only" with everything else still not configured: Orca validation succeeds.
• Change MSI back to "enforce" so that Orca validation fails. Uncheck "configured" for MSI; now everything is not configured, but there's still the one "allow *" MSI rule: Orca validation fails. Delete the MSI rule: Orca validation succeeds.
  • MSI "configured" with no rules: Orca validation succeeds. Add one "allow *" MSI rule: Orca validation fails.

Renaming C:\Windows\System32\AppLocker\Msi.AppLocker to e.g. Msi.AppLocker.temp-disabled causes Orca validation to start working immediately (no gpupdate required). Renaming it back causes Orca validation to fail immediately. This solution is inspired by this post, and Microsoft docs also point in this direction.

Misc notes about managing AppLocker

Much of this isn't directly relevant to the issue at hand, but might help someone with their AppLocker debugging. This was tested with local policies, but I believe it would also apply to policies from GPOs.

For policy changes to take effect, gpupdate must be run. Changes seem to reliably take effect immediately after the gpupdate – unlike with SRP where on some machines changes would take effect immediately, others required a restart or two, and a few updated when they felt like it.

Regarding AppIDSvc, it seems best to just leave it running all the time. Restarting it never helps, and can only hinder. Some observations:

• Whether or not AppIDSvc is running seems to have no effect on rules being enforced (tested for exe and MSI).
• It seems that AppIDSvc needs to be running during both making the local policy changes and the gpupdate. If AppIDSvc is stopped during either of these, or even if it's restarted between them, the changes will not take effect immediately. They might take effect eventually (or after another gpupdate or two?), at least in the case where it's restarted between.
• Some people say they don't need to configure AppIDSvc to start automatically, and that Windows will manage it on its own. Maybe this is true for deployments via Intune, but I tried this for deployments via GPO and local policy, and AppLocker didn't take effect unless I started or configured AppIDSvc myself, even after multiple restarts.

While renaming or deleting C:\Windows\System32\AppLocker\Msi.AppLocker immediately disables the MSI policy, the same is not true for Exe.AppLocker. Restarting AppIDSvc doesn't make a difference, though maybe there's another service that would. Restarting the machine will work, assuming no AppLocker policies are applied to your machine anymore (e.g. useful if you messed up while disabling AppLocker and have blocked yourself from running any exe's).

[BMurri]

Validation uses the Windows Installer's elevated engine. That engine can be accessed via the MSI APIs by Windows accounts in two states: interactive or elevated. Anything else (aka non-elevated service account) results in failure. It's entirely possible that AppLocker removes account permissions that the APIs use to validate elevated engine access, and/or that Intune did the same.

There's been a longstanding effort (with no progress in approximately a decade) to replace the validation's backend with something more build-server friendly. Latest whispers are that it'll be in WiX v5 if someone is willing to step forward NOW to tackle it, otherwise it might slip to v6 at the earliest (note that I haven't verified that timing yet).