Installing a suite in system context - file system redirection problem? att: MichaelU

[don_walker]

This problem occurs on Windows 7 64-bit. We have a suite built with IS 2014 that installs properly when run by an admin user. However, we have a customer using SCCM who experiences failures when they push the install with SCCM, which runs the install in system context. I have been able to recreate the problem using System Internals psexec utility to run the suite with the -s parameter. The first package the suite tries to install is an msi package that fails with the following message:

MSI (s) (2C:A4) [14:52:36:799]: Note: 1: 2203 2: C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\{A7C4B3C0-F3A0-426A-A043-E13DBA123E52}\SSCERuntime_x86-ENU.msi 3: -2147287037

which says the msi file isn't there. This is technically correct as file system redirection actually places the file in:

"C:\Windows\SysWOW64\config\systemprofile\AppData\Local\Downloaded Installations\{A7C4B3C0-F3A0-426A-A043-E13DBA123E52}\SSCERuntime_x86-ENU.msi"

MichaelU addressed a similar problem in his post https://community.flexerasoftware.com/archive/index.php?t-192926.html

Michael, could you, or someone else confirm that I have correctly determined the problem. If so, the implication is that any suite created with default settings will fail when run from SCCM or similar services that run the install in system context. I understand that the fix is to set the Cache Path to a directory that will not be redirected. In reviewing the list of properties available at the suite level it appears that either CommonAppDataFolder or CommonDocuments would be safe locations. Comments?

[MichaelU]

It appears that this is an almost identical case. Some of the low level mechanics are slightly different, namely whether msiexec.exe is invoked, or MsiInstallProduct is called, but fundamentally both cases involve a filesystem redirection on the 32-bit side that isn't reflected on the 64-bit side. I think this case may only affect Suites that include 64-bit packages (or reference 64-bit paths), but I'd have to run some tests to verify.

I agree that CommonAppDataFolder seems like a good alternative target, but I haven't run through the full set of implications.

[don_walker]

Thanks for your prompt response. Some additional comments and questions follow:

1. Since we've started in the forum I would prefer to continue discussions here. However, I have an active support contract and can log a formal bug report if you want me to. Let me know.

2. I'm not aware of any explicit references to 64-bit paths or packages in the suite. All our own msi files are for 32-bit apps. However, we do include a number of standard Microsoft rediistributables. I've attached a copy of the suite .issuite file.

3. Whatever the technical reasons that you are not applying file system redirection consistently I have to say that I consider this a moderately serious bug because of the impact it has on what I assume is a standard practice with SCCM. I will note that we don't have SCCM installed here and that what I know about SCCM comes from Google searches If there are any SCCM experts reading this I would appreciates comments.

.

[MichaelU]

Hmm. There are some lingering references to having had 64-bit packages in your project (just display names for 64-bit redists that look like imported prerequisites); if those were included last time you tested, they should have caused this package to be 64-bit aware. In fact there's a lot of lingering cruft in that package that I would prefer not to have to consider here; have you tried creating a fresh minimal suite project that reproduces this problem?

Regarding point 3, the end result matches what you say, but the problem is more that Windows doesn't offer a way for a 32-bit application and a 64-bit application to agree on file paths. Typically %LOCALAPPDATAFOLDER% refers to a single location, but in the case of the system account, it gets split by the 64-bit filesystem redirection. Then when both the 32-bit bootstrap and the 64-bit helper both reference "C:\Windows\system32\config\systemprofile\AppData\Local\Downloaded Installations\...", they implicitly describe two different locations. How do we know which of those locations is the "correct" one?

But whatever the theory, I do understand that this is a problem in practice. It would help us track it if you do put in a support request, and make it possible to work with real files confidentially. Our support team can help you isolate exactly which scenarios result in this behavior (i.e. confirm or deny my hypothesis of the 32-bit only package behaving differently), and that in turn will help us address it more clearly, and may even uncover other workarounds.

[don_walker]

Continuing on point 3, anytime the suite setup.exe passes a path from a 32-bit-component to a 64-bit component it should pass the actual path, rather than a path is could be subject to redirection. Stackoverflow has a suggested way to determine the actual path at https://stackoverflow.com/questions/23650436/how-to-get-actual-path-of-redirected-path

I plan to file an official support request and will update here when that is done.

Thanks again for your responses.

[MichaelU]

Great, thanks. We took a preliminary look at GetFinalPathNameByHandle, and it does look like it could be the basis of a solution. However, as we will probably have to do a full regression test cycle on this fundamental a change (one that could break UNC paths, etc. if improperly handled), I would suggest other workarounds for now.

[don_walker]

I've submitted the formal bug report. it is Case #00485691