permission after reboot
Posted 08 June 2005 - 18:51
an admin upgrades software on a machine. during upgrade a file that is locked needs to be replaced and re-registered so a reboot is required at the end of install.
but.. the admin leaves and the regular user logs on (who only has user access).
when that user logs on does Windows Installer tries to complete the install but can not since the user does not have admin privledges to replace or register files. what happens?
is there a way around this? or should one just flash up a dialog before rebooting that requests that the admin log back in to complete the install?
Posted 09 June 2005 - 04:54
Posted 09 June 2005 - 08:12
Note that this question is valid in other scenarios, eg. when the sequence demands an immediate reboot before continuing. (For instance, MDAC was installed, but a reboot is required before Setup can access some databases...)
One would think that the installation would only continue when the original user logged on again - other users may have insufficient priviliges. Suppose any user would do: what if the software is installed with ALLUSERS empty (install for this user only)?!
I can think of more tricky issues (eg. what if account of original user is deleted?), better hope for the best.
Posted 09 June 2005 - 23:22
Unless there is a direct solution, i would probably suggest adding some text to your finish dialog, telling the current user that they must login after they reboot with the same user.
Posted 10 June 2005 - 17:23
i'm still trying to determin if what Zweitze is happening. if that's the case then why are we getting a runtime error. its hard to determine whether or not the DLL is replace during shutdown and startup of a reboot.
Posted 10 June 2005 - 20:30
On Windows 95, 98 and Me the files that should be replaced are listed in Win.ini (or System.ini, I forgot).
On Windows NT, 2000, XP and 2003 the files are listed in the registry, I believe in HKLM\SYSTEM\CurrentControlSet\Control\...
On Windows 9x/Me, note that the files will be replaced *before* the long file name drivers are active, therefore this may fail on long file names - another reason to stick to short file names for the time being.
On Windows NT based systems, the files will not be replaced when you boot with 'last known good configuration'.
Also remember, certain system files cannot be replaced - but they are part of the OS kernel. From Windows 2000 on, trying to do so will report an error.
I suggest to check whether the files are listed for replacement (by checking ini-files/registry), and creating a log (maybe some condition prevented installation of that component).