This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Server 2008 R2 x64 redirection problem extracting msi from setup.exe?
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 13, 2010
09:21 PM
Server 2008 R2 x64 redirection problem extracting msi from setup.exe?
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!
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\
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!
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 14, 2010
01:23 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 14, 2010
04:33 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 15, 2010
01:02 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 15, 2010
08:12 PM
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
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\
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 16, 2010
12:29 PM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Apr 19, 2010
08:29 PM
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!
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!
![](/skins/images/D60DF682EA37BF37032955CE10F3F0BB/responsive_peak/images/icon_anonymous_message.png)