View Full Version : Install locked files with main user rights

02-09-2005, 10:01 AM

I allow to install our application with main user rights. If some files are locked then BATCH_UNINSTALL is set to TRUE and at the end of the installation the user shall reboot the computer. In the registry the locked files are listed under HKEY_LOCAL_MACHINE\SOFTWARE\InstallShieldPendingOperation.

If the computer is rebooted (with main user rights) then the locked files are not updated and the registry entries are still there.

Must I always use admin rights to get the correct functionality?

Thanks in advance

12-05-2005, 09:41 AM
We have the same problem. Can anybody help?

09-08-2006, 09:43 AM

We have the same problem also. When our installer (created with DevStudio 9) encounters a locked file, it creates a .RRA file which is equal to the one from the update package. Upon reboot, the destination file (previous locked file) should be replaced with the RRA file to complete the installation. But this never happens and the key "InstallShieldPendingOperation" with all values are still listed in the registry! O.S. is Windows 2000 SP4.

I can't imagine that, except for Heikki and svdben, I'm the only one struggling with the same problem. Does somebody know a solution for this problem?


09-20-2006, 10:14 AM
Nobody has ever experienced the same kind of problems???

Please help me if you have any ideas.

09-22-2006, 06:56 AM
Installshield does not handle security rights with a system e.g. Windows 2000.

The Windows security system, starting with Windows NT, requires you to set proper rights for any object in the system or else you may not perform the action e.g write to a folder in the file-system.

The Administrators group is normally allowed to write/read/execute/... on the most objects in the NT security system.

A user that wants to write/execute files should therefore belong to the Administrators group.

So.... where does this leave us?

In my own programs I usually check whether or not the user installing is an administrator or not. If the user is not an administrator I warn/deny them to install with the message 'You are not an administrator...'.

You can see the security system settings for a specific folder/file by starting the Windows Explorer, select an item, right-click, select 'Properties', then select the 'Security'-tab and, 'Voilá!', you see what a certain user/group is allowed to do with this object.

The allowed operations for a certain user and folder in the filesystem can be seen if you e.g start Windows Explorer, right-click on the 'Program Files'-folder, select 'Properties' and then select the tab 'Security'.

The list shows you what a certain user is allowed to do with this folder.

The code I use is enclosed below.

function OnBegin()
//Note: Second parameter is ignored...
MessageBox("You must have ADMINISTRATORS rights to install this program!",SEVERE);


09-22-2006, 07:09 AM
Thanks for your reply.

We require that our users must have Power User rights. With these rights one can write in our application's installation folder ("C:\Program Files\company\application") and write to HKLM in the registry. But even with these rights - which should be sufficient - the files locked during the update process will not be replaced upon rebooting. Any ideas?


09-27-2006, 11:21 AM
It seems like InstallShield is (in Win2K at least) creating the "InstallShieldPendingOperation" registry key when the user doesn't have administrator rights. When the computer restarts, the registry key remains and nothing is being done. Is this a way for InstallShield to tell us that something could not be done???

10-04-2006, 05:00 AM
We have experienced problems with IS 10.5 when DCOM was not active for a certain user. The symptoms of this that installshield died a horrible death. Maybe this is another scenario where you don't see IS failing thus leaving registry unchanged as well?

10-04-2006, 08:30 AM
Okay, after some more comprehensive tests, I discovered the following regarding installation of files that are locked / in-use (Win2K Power User scenario):

Although the user has sufficient rights (Power User) to write to the destination directory ("C:\Program Files\Company\Product") after a reboot, the system registry keys that need to be written to tell the O.S. what files to copy/install at restart, are only writable when the user has administrator rights!! Therefore, IS decides to write the copy-actions to a special registry key: "InstallShieldPendingOperation". This key only gets 'solved' when the user installs another update and when the user has administrative rights(!) But this is practically never the case, since he hadn't these rights earlier!

Conclusion: due to Windows' concept of user rights, in certain circumstances (locked files) the program requires the administrator privileges to update all components. Without these rights it can't perform the neccessary actions, because it needs help from the O.S.. This is because certain files could already be in-use when the system has restarted completely.

As far as I understand, Windows Vista addresses these issues by its new "User Account Control". But for earlier Windows (NT-family) versions, we're left where we are.....and administrator privileges are the only solution.

See also Macrovision / InstallShield documentation Q100193 and Q111249 (Win9x issues).