Registry issue when older package removal fails
Allright, i've got an issue with some registry settings. Background info:
I've packaged an upgrade to an existing repackage. Unfortunately, the older version has to be removed prior to the installation of the newer version. This is where the trouble begins.. [:(]
When i install the repackaged new app/update on a newly installed Windows XP machine, it installs and runs just fine as a standard user. However, when the previous repackaged version is removed, I run into a few errors. A few core dll's are unregistered (fm.dll, urlmon.dll) after the uninstall and some file associations are gone. I've fixed this using a VB uninstall script to remove the older/previous version of the repackaged software using commandline, then re-registering the dll's using the regsvr32 command. After that, the VB script runs a second MSI package restoring the missing file associations.
The machine seems to be running somewhat fine after that, however, when the newer version of the repackaged software is installed after a reboot it shows the user an "Error updating the registy" error. This error isn't present on the newly installed machines (machines without the previous version), so probably the old uninstall "botches" up some things. Ran regmon and found that some keys gave an "acces denied".
Now i'm thinking of adding the keys to the same MSI that handles the file associations repair, and giving users full control to those keys prior to install of the update, just to see if it fixes the error. Normally i would prefer a better method of "repairing" the installation, but unfortunately time isn't really on my side on this one. (Can'r remember the last time it actually was.. ;) )
So i would prefer a quick way to set rights to the registry keys. Quickest way i know of, is to use the "LockPermissions" table in the repair MSI. I was actually wondering if this is going to work at all, because the registry values are going to be overwritten when the newer software version MSI is being installed. Any thoughts on that..? Any hints on another way of setting the registry rights? Read a couple of things about the LockPermission table and SETACLS. Have tried using setacls in the past, but unfortunately never did get that working from within an MSI. So any hints greatly appreciated. TIA!
I've packaged an upgrade to an existing repackage. Unfortunately, the older version has to be removed prior to the installation of the newer version. This is where the trouble begins.. [:(]
When i install the repackaged new app/update on a newly installed Windows XP machine, it installs and runs just fine as a standard user. However, when the previous repackaged version is removed, I run into a few errors. A few core dll's are unregistered (fm.dll, urlmon.dll) after the uninstall and some file associations are gone. I've fixed this using a VB uninstall script to remove the older/previous version of the repackaged software using commandline, then re-registering the dll's using the regsvr32 command. After that, the VB script runs a second MSI package restoring the missing file associations.
The machine seems to be running somewhat fine after that, however, when the newer version of the repackaged software is installed after a reboot it shows the user an "Error updating the registy" error. This error isn't present on the newly installed machines (machines without the previous version), so probably the old uninstall "botches" up some things. Ran regmon and found that some keys gave an "acces denied".
Now i'm thinking of adding the keys to the same MSI that handles the file associations repair, and giving users full control to those keys prior to install of the update, just to see if it fixes the error. Normally i would prefer a better method of "repairing" the installation, but unfortunately time isn't really on my side on this one. (Can'r remember the last time it actually was.. ;) )
So i would prefer a quick way to set rights to the registry keys. Quickest way i know of, is to use the "LockPermissions" table in the repair MSI. I was actually wondering if this is going to work at all, because the registry values are going to be overwritten when the newer software version MSI is being installed. Any thoughts on that..? Any hints on another way of setting the registry rights? Read a couple of things about the LockPermission table and SETACLS. Have tried using setacls in the past, but unfortunately never did get that working from within an MSI. So any hints greatly appreciated. TIA!
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
turbokitty
17 years ago
What tool are you packaging with? LockPermissions works fine (in AdminStudio, it's a pain in the ass with Wise if you have a lot of keys) but it'll overwrite existing permissions.
SETACL works, if you start a new post about the keys you want changed and the permission you want on those keys, you'll have a better response. This post is really long and confusing and I imagine you lost most people after the first paragraph! [:D]
Another point, regsvr32 isn't a good way of registering DLL's. It doesn't create the COM server information. If you can, you should drop the DLL's again in your new MSI and let MSI handle them.
Why does the old version have to be uninstalled instead of patched? It sounds like you've created quite a mess by by-passing the MSI's uninstall feature.
SETACL works, if you start a new post about the keys you want changed and the permission you want on those keys, you'll have a better response. This post is really long and confusing and I imagine you lost most people after the first paragraph! [:D]
Another point, regsvr32 isn't a good way of registering DLL's. It doesn't create the COM server information. If you can, you should drop the DLL's again in your new MSI and let MSI handle them.
Why does the old version have to be uninstalled instead of patched? It sounds like you've created quite a mess by by-passing the MSI's uninstall feature.
Posted by:
neo2000
17 years ago
Thnx for the reply Turbokitty..! Reading it back, it sounds even a bit fuzzy to me. Guess I was a but fuzzy myself when posting it.. ;) (been working on the problems for 48 hours now :( )
The older version of the program was a legacy setup capture in Wise. Repackage worked like a charm and installed just fine. Unfortunately, uninstall it using msiexec /x {pid} doesn't work great. I could use the "remove existing products" option in the newer package using Wise, but i think the results will be the same: a machine that's not functioning properly.
The registry problem is with some keys, so I guess i'll be able to fix it using the lockpermissions table in Wise.
Some dll's/ocx's I had to re-register to make the machine work properly again:
urlmon.dll
fm20.dll (MS Excel plugins)
mscomctl.ocx
Also, the VBS/VBA file associations are gone. Made a MSI to restore the file associations and used the VB i usualy use to remove older applications to re-register the dll's/ocx. Would be nicer actually to include those in the package too, like you say in your post. I'm going to check that out. Thanks so far..!
The older version of the program was a legacy setup capture in Wise. Repackage worked like a charm and installed just fine. Unfortunately, uninstall it using msiexec /x {pid} doesn't work great. I could use the "remove existing products" option in the newer package using Wise, but i think the results will be the same: a machine that's not functioning properly.
The registry problem is with some keys, so I guess i'll be able to fix it using the lockpermissions table in Wise.
Some dll's/ocx's I had to re-register to make the machine work properly again:
urlmon.dll
fm20.dll (MS Excel plugins)
mscomctl.ocx
Also, the VBS/VBA file associations are gone. Made a MSI to restore the file associations and used the VB i usualy use to remove older applications to re-register the dll's/ocx. Would be nicer actually to include those in the package too, like you say in your post. I'm going to check that out. Thanks so far..!
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.