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
- :
- Re: Installer Failures
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
‎Feb 07, 2012
10:32 AM
Installer Failures
This question actually relates to InstallShield 8 but I'll post it here, since the other forums seem to get very little traffic AFAICT.
My application's InstallShield setup file (setup.exe) has been downloaded by about 40 oir so users. A significant number of them are reporting seeing an error message like this when they try to run the installer:-
The same dialog box usually then shows an error message which is either Access denied or The path is too long or The path was not found
Any idea what's goind on? The affected people are almost always in a non-English locale if that helps to shed any light on the issue.
[Edit...] I've noticed that the problem often seems to happen when the user's name has an accented character such as René or Göran. Is there something inside InstallShield that I need to be setting up to accommodate this situation?
My application's InstallShield setup file (setup.exe) has been downloaded by about 40 oir so users. A significant number of them are reporting seeing an error message like this when they try to run the installer:-
Unable to save file C:\WINDOWS\Downloaded Installations\[A-LONG-GUID-NUMBER-HERE\Mixbus.msi
The same dialog box usually then shows an error message which is either Access denied or The path is too long or The path was not found
Any idea what's goind on? The affected people are almost always in a non-English locale if that helps to shed any light on the issue.
[Edit...] I've noticed that the problem often seems to happen when the user's name has an accented character such as René or Göran. Is there something inside InstallShield that I need to be setting up to accommodate this situation?
(12) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 08, 2012
06:35 AM
Have you selected 'Cache MSI Locally' from the Releases Setup.exe tab ?
If so, have you chosen a location for it that is restricted access or non-exsistant on their system.
Perhaps the user account of the installer does not have 'Admin' priveleges on that machine (for Access Denied).
Not sure about the other errors unless those are generated for a non-existent folder.
If so, have you chosen a location for it that is restricted access or non-exsistant on their system.
Perhaps the user account of the installer does not have 'Admin' priveleges on that machine (for Access Denied).
Not sure about the other errors unless those are generated for a non-existent folder.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 08, 2012
07:44 AM
Thanks for the prompt reply Jonathan. The only thing I can find which looks similar to what you descibed is under Releases->SingleImage. There's an entry called Cache Web Download which allows me to set a local cache path (currently set to [WindowsFolder]Download Installations. That does seem to match my problem but I'm guessing it isn't exactly what you meant. My installation package builds a conventional setup.exe file. It doesn't download anything from the web AFAIK. Seems like I'm in the right region but should I be looking somewhere else?
[Edit...] Ah - I've just realised what must be happening.! These particular customers must be running the setup file directly from our server instead of downloading it locally! I'll try modifying that setting Jonathan and see if it solves the problem. Thanks for the tip.:cool:
[Edit...] Ah - I've just realised what must be happening.! These particular customers must be running the setup file directly from our server instead of downloading it locally! I'll try modifying that setting Jonathan and see if it solves the problem. Thanks for the tip.:cool:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 09, 2012
03:30 AM
I'm using 2012 InstallShield so my appologies if the item doesn't exist in your version.
I think it is a pretty essential bit of functionality so I'd expect it to be there.
It caught me out when I tried deliberately deleting a file from the installed s/w folder and seeing how the windows installation recovery coped.
It too complained about a missing msi in an obscure folder.
Which is when I realised I needed to cache the msi file on the system where our s/w was installed.
Good Luck.
I think it is a pretty essential bit of functionality so I'd expect it to be there.
It caught me out when I tried deliberately deleting a file from the installed s/w folder and seeing how the windows installation recovery coped.
It too complained about a missing msi in an obscure folder.
Which is when I realised I needed to cache the msi file on the system where our s/w was installed.
Good Luck.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 09, 2012
04:18 AM
Thanks again Jonathan - BTW....
What would you recommend as a suitable folder? My initial thoughts were either to pick the user's personal folder or maybe the Windows 'temp' folder. But on my system, neither of those folders seem to have any rights set for "Trusted Installer". I suppose I should choose a folder that InstallShield will have access to but I don't know what would be a reliable choice. 😞
jonathanqis wrote:
Have you selected 'Cache MSI Locally' from the Releases Setup.exe tab ?
If so, have you chosen a location for it that is restricted access or non-exsistant on their system.
What would you recommend as a suitable folder? My initial thoughts were either to pick the user's personal folder or maybe the Windows 'temp' folder. But on my system, neither of those folders seem to have any rights set for "Trusted Installer". I suppose I should choose a folder that InstallShield will have access to but I don't know what would be a reliable choice. 😞
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 09, 2012
08:05 AM
In InstallShield 2008, the default value of the cache path was changed, so you may want to change the value in your project accordingly. Here's the information from the InstallShield 2008 release notes:
New Default Value for the Cache Path Setting for a Release
The default value for the Cache Path setting for a compressed release in the Releases view is now set to [LocalAppDataFolder]Downloaded Installations. The previous default value was [WindowsFolder]Downloaded Installations, which may not be available to users on locked-down systems.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 11, 2012
07:19 AM
Many thanks Debbie. On a separate (but related) topic, is there a way to guarantee that the user will have full access rights to whichever folder he chooses when running my InstallShield setup.exe file? I've assumed that if the user opts to install for "Me Only" he / she would be granted full rights to their chosen installation folder but that doesn't always seem to hold true. Is there anything I can stipulate when I'm building the setup.exe file that will guarantee this?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2012
08:34 AM
There aren't enough details in this thread to know what's going on. For example, which operating systems are you targeting? Is the installation creating the folders, or your application? Are the folders in some sort of shared location? You may want to take a look at a log file and see if that helps you identify the problem. If you have trouble finding the problem in the log file, consider posting the log file in the community, and maybe someone can help you narrow down the problem.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 13, 2012
09:17 AM
Thanks Debbie. As usual, your reply has prompted me to take a closer look at my project settings. Firstly, my InstallShield project currently specifies [ProgramFilesFolder]Mixbus as the default install destination (i.e. [INSTALLDIR]). That folder has a subfolder called "etc" into which we install some preliminary config files. These folders get created at install time by the InstallShield installation wizard. The actual config files get overwritten when the user first runs our app. Some users (mostly running Windows 7, from what I can tell) are seeing run time errors indicating that it wasn't possible to open the config files. We're assuming (probably reasonably) that this is because the user doesn't have write access to the "etc" folder.
However, now it gets interesting... on looking at my project I've discovered that any folder created by InstallShield can be created with specific permissions. I seem to be able to specify permissions under two columns:- 'Domain' and 'User'. I'm not sure though what I need to type into those boxes. The help info window for Destination Permissions recommends not defining any permissions but maybe I should experiment with some. What would you recommend I type into the 'Domain' and 'User' boxes?
Also, does InstallShield create a log file at install time? If so and you can tell me where it's likely to be, I'll ask my user to look for it, next time this happens.
However, now it gets interesting... on looking at my project I've discovered that any folder created by InstallShield can be created with specific permissions. I seem to be able to specify permissions under two columns:- 'Domain' and 'User'. I'm not sure though what I need to type into those boxes. The help info window for Destination Permissions recommends not defining any permissions but maybe I should experiment with some. What would you recommend I type into the 'Domain' and 'User' boxes?
Also, does InstallShield create a log file at install time? If so and you can tell me where it's likely to be, I'll ask my user to look for it, next time this happens.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 14, 2012
02:33 PM
Only administrators have write access to files and folders in Program Files on Windows 7 machines. You may want to consider resolving this from the application side (not from your installation) by having the application store any user-writable files in a location that a standard user can write to, such as CommonAppData or LocalAppData. Otherwise, you could manifest your application's .exe file run with elevated privileges.
As another alternative, you configure your installation to set the permissions on your etc folder to allow users to write to it.
KB article Q104807 has information on how to log an installation.
I hope that helps.
As another alternative, you configure your installation to set the permissions on your etc folder to allow users to write to it.
KB article Q104807 has information on how to log an installation.
I hope that helps.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 15, 2012
03:16 AM
Thanks again Debbie, especially for that KB link which I'll look into later.
I must admit, practical experience has taught me that with the huge variety of Windows installations, there's actually no folder (except for 'My Documents') which guarantees write access for any specific user. Even the folder returned by CSIDL_PERSONAL isn't guaranteed to be writable! So I think that if I can get the installer to configure the folders, it'll hopefully be my best shot.
In case anyone else needs to know how to do this, I discovered that I can set permissions based on 'classes' of users. These can somehow be qualified by the addition of a 'domain' but I'm not sure what effect that has and it doesn't seem to be essential. You can leave the Domain field empty if you like. For the relevant components, what I did was to set up two classes of user:- 'Administrators' and 'Users'. For each entry, I specified the required permissions (in my case, they were the same for both cases). This seems to have done the trick. As usual with Windows, it probably won't work on every system. For example, Win7 Home Edition doesn't seem to have Administrators or Users. It seems to just have one class of user called 'Everyone'. However, 'Everyone' seems to have full access to everything - so it should still work, even if it doesn't work (if that makes sense!)
I must admit, practical experience has taught me that with the huge variety of Windows installations, there's actually no folder (except for 'My Documents') which guarantees write access for any specific user. Even the folder returned by CSIDL_PERSONAL isn't guaranteed to be writable! So I think that if I can get the installer to configure the folders, it'll hopefully be my best shot.
In case anyone else needs to know how to do this, I discovered that I can set permissions based on 'classes' of users. These can somehow be qualified by the addition of a 'domain' but I'm not sure what effect that has and it doesn't seem to be essential. You can leave the Domain field empty if you like. For the relevant components, what I did was to set up two classes of user:- 'Administrators' and 'Users'. For each entry, I specified the required permissions (in my case, they were the same for both cases). This seems to have done the trick. As usual with Windows, it probably won't work on every system. For example, Win7 Home Edition doesn't seem to have Administrators or Users. It seems to just have one class of user called 'Everyone'. However, 'Everyone' seems to have full access to everything - so it should still work, even if it doesn't work (if that makes sense!)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 18, 2012
03:29 AM
Grrr.... no, that solution doesn't work. It does work on English language systems but the problem is that you need to specify each class of user using a hardwired string. So you need to set permissions for 'Users' say - or 'Administrators' When a Portuguese customer tried this, we quickly realised that in Portugal, the 'Users' group is called 'Utilizadores' . Our setup.exe file failed with error 1609 and refused to continue - so that was the end of that.!
Debbie, this feature needs to work in the same way that pre-defined folders work - e.g. [LocalAppData] is used for convenience within my InstallShield project - but in the outside world it gets translated to whichever folder is relevant on the end-user's system. The same idea (or something similar) needs to work for setting user permissions.
Is anything like this implemented in the latest version of InstallShield? If so, this would be a good excuse for me to upgrade.
Debbie, this feature needs to work in the same way that pre-defined folders work - e.g. [LocalAppData] is used for convenience within my InstallShield project - but in the outside world it gets translated to whichever folder is relevant on the end-user's system. The same idea (or something similar) needs to work for setting user permissions.
Is anything like this implemented in the latest version of InstallShield? If so, this would be a good excuse for me to upgrade.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Feb 21, 2012
09:51 AM
In InstallShield 2010, new methods for setting permissions were introduced. These new methods have support for localized names for SIDs. It sounds like that's what you may need. For more information about the different types of permissions support, see Securing Files, Folders, Registry Keys, and Windows Services in a Locked-Down Environment. The permission method that's in the version of InstallShield that you are using is what's called "traditional Windows Installer handling" in that help topic.
![](/skins/images/A5EADE085F77DE82FB3B14D6B307AE6A/responsive_peak/images/icon_anonymous_message.png)