wixtoolset / issues

WiX Toolset Issues Tracker
http://wixtoolset.org/
129 stars 36 forks source link

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

Open cornerbowlsoftware opened 2 weeks ago

cornerbowlsoftware commented 2 weeks 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

  1. STIG a Windows 2022 Server or Windows 11 Enterprise workstation.
  2. Upload a bundled installer to the target system.
  3. 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

bevanweiss commented 2 weeks 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 2 weeks 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 2 weeks 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 2 weeks 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 2 weeks 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.

cornerbowlsoftware commented 2 weeks ago

This is a major issue with STIGed machines. I have multiple customers experiencing this issue requiring them to manually run around and install the software manually. Basically any remote installation in the defense industry is going to fail. This is really huge, enough so I may have to roll back to v3.

barnson commented 1 week ago

"STIG" is too vague. Which release? Which configurations?

cornerbowlsoftware commented 1 week ago

@barnson Windows 11 Enterprise released July 17th 2024

https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_MS_Windows_11_V2R1_STIG.zip

Now how it's been implemented, I don't have that information.

I will reach out to verify the systems are not running Server 2022 or 2019. I don't care so much about 2016 even though that's approved.

cornerbowlsoftware commented 2 days ago

I have reverified the GMSA account is the issue. So in order for remote installation to work using a GMSA account the following issue needs to be resolved. Again Wix3 does not have this issue so the code changes in v4 or v5 have busted this functionality.

[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.

cornerbowlsoftware commented 1 day ago

@barnson @bevanweiss This is a major issue for the largest employer in the world. I am at a point where I have to rollback all my installers to Wix3 so my customers can properly install software on their classified networks. Please can you provide me with an update so I can let my customers know and so I can start the process of rolling back if this bug is not going to be fixed?

bevanweiss commented 1 day ago

If you want official support, you should contact FireGiant (http://www.firegiant.com)

cornerbowlsoftware commented 1 day ago

@bevanweiss Ok thanks.