Strange MSI behavior. Works interactively or via .cmd, but not via startup script
I am trying to deploy an Admin Studio-created .msi file via a startup script.
The msi creates a directory, copies files, adds a couple of permissions to the installed files, and adds a couple of registry settings. That's it.
Double-clicking the msi works to install it. The files come down with their security settings, the registry entries get created, and most importantly, the app gets listed in Add/Remove programs.
I've created a batch (.cmd) file to call the .msi silently, and the functionality above also works as expected.
The next step is to call the .cmd file in our machine startup scripts (gpo). The startup script does run the cmd file, and this does kick off the .msi installation silently. The files get installed, the registry keys also come down (so the application is usable), BUT the app doesn't appear in Add/Remove Programs. It DOES appear in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{guid_goes_here}. When you right-click the msi and try to uninstall, it tells me that this action is only valid for products that are installed. There is no rollback due to failure.
I have the logs to point out the differences between an interactive install and a the startup script one, if needed.
We tested a Microsoft-supplied msi file, (the Windows 200 Resource Kit installer) under the same conditions. The interactive install (double-click, or user-called .cmd file) works as expected, but we get the same thing happening when we try to deploy this using a startup script.
Therefore, we believe that this is an environmental or permissions issue, rather than a problem with any .msi itself.
We think that startup scripts use the system account, but don't really know how to troubleshoot much further. We've added Authenticated Users read permission to the share that the .msi is on, but this didn't fix it.
Can anyone help?
Glenn
The msi creates a directory, copies files, adds a couple of permissions to the installed files, and adds a couple of registry settings. That's it.
Double-clicking the msi works to install it. The files come down with their security settings, the registry entries get created, and most importantly, the app gets listed in Add/Remove programs.
I've created a batch (.cmd) file to call the .msi silently, and the functionality above also works as expected.
The next step is to call the .cmd file in our machine startup scripts (gpo). The startup script does run the cmd file, and this does kick off the .msi installation silently. The files get installed, the registry keys also come down (so the application is usable), BUT the app doesn't appear in Add/Remove Programs. It DOES appear in HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{guid_goes_here}. When you right-click the msi and try to uninstall, it tells me that this action is only valid for products that are installed. There is no rollback due to failure.
I have the logs to point out the differences between an interactive install and a the startup script one, if needed.
We tested a Microsoft-supplied msi file, (the Windows 200 Resource Kit installer) under the same conditions. The interactive install (double-click, or user-called .cmd file) works as expected, but we get the same thing happening when we try to deploy this using a startup script.
Therefore, we believe that this is an environmental or permissions issue, rather than a problem with any .msi itself.
We think that startup scripts use the system account, but don't really know how to troubleshoot much further. We've added Authenticated Users read permission to the share that the .msi is on, but this didn't fix it.
Can anyone help?
Glenn
0 Comments
[ + ] Show comments
Answers (0)
Please log in to answer
Be the first to answer this question
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.