Server 2008 R2 x64 redirection problem extracting msi from setup.exe?

[shmooerific]

Hello,

We have a product that is distributed as a setup.exe. When we try to run the setup file on Server 2008 R2 x64 from a service running as Local System, we get a 2203 error (file not found).

As far as we can tell, the msi is extracted to C:\Windows\sysWOW64\config\systemprofile\AddData\Local\Downloaded Installations\\.msi but the system tries to run it from C:\Windows\system32\config\systemprofile\AddData\Local\Downloaded Installations\\.msi.

Even more interesting, this only seems to be an issue on Server 2008 R2 x64 (32 bit OS versions, Server 2008 regular x64, Vista x64, XP x64 all seem to be okay so far).

As well, the setup.exe also works okay if run as a user (rather than from the service as Local System). We suspect this is because the [LocalAppDataFolder] for the user is not affected by redirection.

Does anyone know if this is a known issue, or the best resolution?

Also a noob question, the only setting I can find in our ism file that is set to "[LocalAppDataFolder]Downloaded Installations" is the Media->Releases->Setup Package->Cache Path setting. Does this setting also control the extraction path for extracting the msi from the setup.exe, or is this configured someplace else?

Thank you very much for your assistance!

[MichaelU]

If you're going to install the MSI from system context - presumably this is automated - it may be better to perform an administrative installation somewhere (setup.exe /a) and work with the extracted MSI files directly. You can then also schedule any prerequisites this process excludes the same way you're scheduling the main installation.

[shmooerific]

Hi Michael,

Thank you very much for your response to my enquiry.

Yes, you are correct that we are trying to automate an installation from system context. We are in the early stages of adding update management to our product. Not surprisingly, this led to our attempting to run our installer silently in a process spawned by our service (which is running under Local System). We then found this redirection issue on Server 2008 R2 x64. Note that our service is 32-bit.

Do you recommend doing an administrative install with /a as the only/best way to control the directory to which the msi file(s) are extracted?

When I could not find an option to control the extraction path within the InstallShield interface, I was not sure if I was missing something, or if the packager is not supposed to control this at packaging time.

If the extraction path is not configurable at packaging time, would you be able to confirm which path is used?

Also, would you be able to confirm whether the default is affected by the setting of "Media->Releases->Setup Package->Cache MSI Locally"? (That is, is the "Cache Path" setting used to extract and run the msi if "Cache MSI Locally" is set to "yes"?)

And finally, would you know if this redirection problem with Server 2008 R2 has been previously reported?

Thank you again for your assistance, and my apologies for bombarding you with so many questions. For someone new to both InstallShield and Windows Installer, this issue is a rather esoteric one.

[MichaelU]

The Cache MSI Locally setting does allow you to specify where you want the MSI to go. If the pre-chosen path is inaccessible, it will usually prompt the user. However in your case from the original post, it was accessible so did not do this; it merely lost track of where it actually was. According to the documentation, it looks like you can also override this at installation-time by passing /b"C:\Cache\Path\Here" to setup.exe.

[shmooerific]

Hi Michael,

Thank you again for taking the time to look at this issue with me.

Yesterday afternoon we did find the \b in the command line options, and were able to confirm that if we choose a Cache Path not affected by 32/64-bit redirection then our setup.exe is able to install successfully from the system context even on Server 2008 R2 x64. (Yay!)

Similarly, we can confirm that if we set "Cache MSI Locally" to "no" then our setup.exe installs successfully.

So we will be able to adjust our installer (or our update manager) according to the discussed possible work-arounds, which is great news.

For the sake of the InstallShield product, I do wish to point out that we have worked around the scenario rather than solving it head-on. The original symptom still exists that if:

1) a product maker sets "Cache MSI Locally" to "yes", and
2) accepts the default "Cache Path" in [LocalAppDataFolder], and
3) is installing a 32 bit setup.exe from a 32 bit service running as Local System

then this will succeed on most versions of Windows (including Server 2008 R1 x64), but fail on Server 2008 R2 x64 because the path redirection causes the msi to be unpacked to C:\Windows\sysWOW64\config\systemprofile\AddData\Local\Downloaded Installations\\.msi but the system tries to run it from C:\Windows\system32\config\systemprofile\AddData\Local\Downloaded Installations\\.msi.

Is there a proper channel through which I should report this as a potential bug/issue for future investigation?

Thanks again for your assistance,

Debra

[MichaelU]

Bugs can be reported through your maintenance contact, but I'm having a hard time convincing myself whether this is a bug or a limitation. This issue stems from our 32-bit bootstrap writing to C:\Windows\system32\config\systemprofile\... which gets redirected to C:\Windows\syswow64\config\systemprofile\... behind our backs. Then when we pass the location to Windows Installer, we tell it C:\Windows\system32\config\systemprofile\... which it accesses without redirection, thus fails to find it. The only way I can see to resolve this would be for us to disable redirection when we are extracting files, and it's not immediately clear what bad repercussions that might have.

[shmooerific]

Hi Michael, thanks for your response.

I can't say for certain whether it is a bug or a limitation... but since the behaviour changed between versions of Windows while we continued to use the same version of InstallShield, I suppose that is already an argument in your favour. 😉

Nonetheless, I felt it is something I preferred to report so that your team is either a) able to investigate how the interactions with the OS are performed, b) hassle Microsoft regarding the change in behaviour, or c) mark it as a known limitation and somehow document it so the next unfortunate soul can figure out the issue faster. 🙂

Thanks again for your help!