Errors Due to Security Settings
Many Windows Installer errors complaining that they cannot find, read or write a file/registry value can be attributed to insufficient access. Even logged on as a local administrator this can be the case.
Ensure both you and the computer's SYSTEM account have proper access. "Change" permission should be sufficient. Look in the application log in the Windows Event Viewer (eventvwr.exe) to determine the source of the problem. Not enough detail there? Turn on Windows Installer logging to see exactly where the problem is taking place as well as what Win32 error code is being returned by the error. Together, you should be able to determine exactly what the problems is (at which point the solution should be easily apparent).
Ensure both you and the computer's SYSTEM account have proper access. "Change" permission should be sufficient. Look in the application log in the Windows Event Viewer (eventvwr.exe) to determine the source of the problem. Not enough detail there? Turn on Windows Installer logging to see exactly where the problem is taking place as well as what Win32 error code is being returned by the error. Together, you should be able to determine exactly what the problems is (at which point the solution should be easily apparent).
0 Comments
[ + ] Show comments
Answers (2)
Please log in to answer
Posted by:
Robo Scripter
19 years ago
Good reminder Bob,
I would submit however that the verbose log is very cumbersome for many of those readers who may not have been doing msi's since Orca was the only tool we had.
Microsoft has a free log analyzer tool that make sifting through the log much easer.
The following link will get users to the Analyzer Page;
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/wilogutl_exe.asp
Kind Regards,
I would submit however that the verbose log is very cumbersome for many of those readers who may not have been doing msi's since Orca was the only tool we had.
Microsoft has a free log analyzer tool that make sifting through the log much easer.
The following link will get users to the Analyzer Page;
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/wilogutl_exe.asp
Kind Regards,
Posted by:
~G~
19 years ago
In regards to File/Registry Permissions, I am wondering what people have found to be the best way to implement these modifications.
For example, our main client that we create/deploy MSI packages for, has at each site, two separate Windows 2000/2003 Domains. One Domain is locked down quite considerably, E.g.: GPO Restrictions etc... the other Domain has slightly more relaxed security. Furthermore, a requirement for this client, is that all applications must be delivered/removed via MSI package and GPO's, unless it can be proven without a doubt that it is impossible.
Unfortunately, what we are finding, is that packages created on the less secured Domain (which work perfectly) sometimes no longer function when transferred to the more secure Domain, due to the Restrictions. Removing the Restrictions is not an option, so we are now trying to make everything work on the more secure Domain first.
We initially (using WinInstall 8) edited the registry/file permissions within the MSI's to grant additional permissions and the applications worked perfectly. However, the problem with this, is that those permissions are Domain specific. So firstly, you have to be able to see the Domain on which you want to grant the permission and secondly, it hard codes the Domain name into the package, such that transferring it to another Domain is impossible, without modifying the permissions in the package in WinInstall again, which can end up being a considerable amount of re-work.
We have also looked at doing the Registry/File permissions modifications via GPO's with GPMC, but the Registry/File structure must already exist on the PC/Server you are using (or you have to create it on the fly) for you to be able to do this. Once again this is painful and seems overly complicated.
Has anyone else found a better way of doing this at all?
Thanks.
For example, our main client that we create/deploy MSI packages for, has at each site, two separate Windows 2000/2003 Domains. One Domain is locked down quite considerably, E.g.: GPO Restrictions etc... the other Domain has slightly more relaxed security. Furthermore, a requirement for this client, is that all applications must be delivered/removed via MSI package and GPO's, unless it can be proven without a doubt that it is impossible.
Unfortunately, what we are finding, is that packages created on the less secured Domain (which work perfectly) sometimes no longer function when transferred to the more secure Domain, due to the Restrictions. Removing the Restrictions is not an option, so we are now trying to make everything work on the more secure Domain first.
We initially (using WinInstall 8) edited the registry/file permissions within the MSI's to grant additional permissions and the applications worked perfectly. However, the problem with this, is that those permissions are Domain specific. So firstly, you have to be able to see the Domain on which you want to grant the permission and secondly, it hard codes the Domain name into the package, such that transferring it to another Domain is impossible, without modifying the permissions in the package in WinInstall again, which can end up being a considerable amount of re-work.
We have also looked at doing the Registry/File permissions modifications via GPO's with GPMC, but the Registry/File structure must already exist on the PC/Server you are using (or you have to create it on the fly) for you to be able to do this. Once again this is painful and seems overly complicated.
Has anyone else found a better way of doing this at all?
Thanks.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
