Remote Launch Fails on Server 2022 and Windows 11 Systems that have been STIGed.

cornerbowlsoftware commented 3 months ago

WiX Version

5.0.0

.NET or MSBuild or Visual Studio Version

Visual Studio Version 17.10.4

HeatWave Version

1.0.4.5

Windows Version

Server 2022 and Windows 11

Repro Repo

No response

Repro Steps

STIG a Windows 2022 Server or Windows 11 Enterprise workstation.
Upload a bundled installer to the target system.
Write custom code to Impersonate as a domain admin or a GMSA then Remote Execute via Remote WMI.

Actual Result

The following file is generated on the remote system in the:

c:\windows\temp\Setup_20240822115512_Failed.log

With the following contents:

[06EC:0380][2024-08-22T11:55:12]e000: Error 0x80070002: Failed to find local per-user appdata directory. [06EC:0380][2024-08-22T11:55:12]e000: Error 0x80070002: Failed to initialize internal cache functionality. [06EC:0380][2024-08-22T11:55:12]e000: Error 0x80070002: Failed to initialize engine state.

Expected Result

The installer should create several log files all that include the name of the product in the filename and the installer should successfully complete.

When manually run with a domain admin on the system, the installer completes as expected. This works as expected with Wix3.

Acknowledgements

[X] I acknowledge that this is a fully completed bug report. It is not a question or attempt to get help debugging my issue (because those should be sent to Discussions).

bevanweiss commented 3 months ago

There's a lot of things going on in your report. I think you're going to need to do some work to separate them.

You're running with some kind of locked down STIG, but you haven't indicated what rules apply to it. You likely need to do some investigation yourself into what specific aspect of the STIGs that you are apply results in the problem. I assume you tested the deployment scenario without the STIGs (i.e. your use of the 'custom code to Impersonate as a domain admin or a GMSA then Remote Execute via Remote WMI')?

The line in the source code that is the cause for the error message you are seeing is here: https://github.com/wixtoolset/wix/blob/1011c5609bc12ded5188dc76484fc5075d24617c/src/burn/engine/cache.cpp#L222

You should confirm that when executing via your remote custom code that the executing user does indeed have a valid Local AppData folder (CSIDL_LOCAL_APPDATA).

bevanweiss commented 3 months ago

@robmen / @barnson thoughts on deferring the failure on retrieving the cache locations until first usage? It does seem a little 'strange' that burn will fail if it can't prepare the per-user cache AND default per-machine cache locales (plus potentially the custom per-machine cache location), when it's actually possible that two of them are never used.

I'm thinking that the failure to prepare the location(s) could be logged, with the string left as 'null', and only in GetRootPath where they are used would it error out if a requested path was not available.

cornerbowlsoftware commented 3 months ago

@bevanweiss I agree there is a lot going on here. Thanks so much for the source code location. That helps me understand a little bit more. Yes, I think a lazy use of the paths would be ideal, because, as you say '... it's ... possible that two of them are never used'.

I would imagine Wix3 has these same calls however, my previous software version is using Wix3 and side-by-sided, my server is able to remote install the Wix3 version without issue.

bevanweiss commented 3 months ago

I would imagine Wix3 has these same calls however, my previous software version is using Wix3 and side-by-sided, my server is able to remote install the Wix3 version without issue.

It looks like WiX v4 brought in the changes that appear to be tripping things up. https://github.com/wixtoolset/wix/commit/6d7a275edafb3ae0f3cff94d66503a82dafb71f7

Easiest way forward would be if you could find a way to have the Local AppData work for the remote execution pathway. I'm unsure why it wouldn't just work for a domain admin, since they should have a Local AppData directory (and as you say, it works when run locally). For a GMSA.. this is less likely though..

There are some considerations with not doing the upfront checks however. Since it means there's a greater chance of having to abort installation mid-way through.... which is undesirable. There might be some other approaches though, like having a fall-back for the default per-machine / per-user locations if either is not accessible (i.e. perhaps instead of the Local AppData directory, there's another location that could be attempted).

cornerbowlsoftware commented 3 months ago

@bevanweiss thanks for all your information on this. Actually, I was baselining with the domain admin. My client actually wants to use GMSA. I was hoping a fallback option could be implemented if that's a possibility.

I am currently using Remote WMI to extract the system temp directory from the registry then dumping the file in that location. Then next, I remote execute. Are you suggesting I try to set the working directory to the local appdata directory? I imagine I would run into the same issue as Wix5.

I see in the source code all the errors that are now being thrown. That's definitely an issue for my clients if the directories are not used thus throwing a false positive and preventing the software from installing.