I've done this many times with Flash Player (and other software). What you want to do is:
Use ORCA to edit it with any customization that you want and save it as a transforms (or save it as a whole new MSI, whatever works for you).
Put that new MSI (and transforms) on your software deployment share.
Add this software (and transforms) to your existing policy....
I tried the Always wait for the network at computer startup and logon - Enabled setting from the answer by @Evan Anderson, but it wasn't until I added this setting below as well that allowed the software to install. Not sure if it was a combination of both settings or not. It's working now, so I'm leaving both settings.
In a Group Policy applied to these ...
Need-for-speed properties to tweak:
MSIFASTINSTALL (try it, maybe 3 or 7)
FASTOEM (think twice, must read documentation)
DISABLEROLLBACK (understand what it means, can cause custom actions in MSI package to fail to run! It depends on the MSI design - look for commit- and rollback custom actions)
Security software can be suspended to speed ...
The directory %SystemRoot%\Installer and its contents must never be meddled with. An unserviceable system almost always results. Same goes for WinSxS, Driver Store & GAC.
Using administrative installations (please skim linked answer) is a general purpose measure to
reduce the size of the %SystemRoot%\Installer folder for future deployments. ...
Lessmsi provides a command line as well as interactive application for retrieving any attribute from the .msi.
Interactively, open the .msi then go to Table view and select or type "Property". However while this gives the property names it doesn't give the valid values for said property.(Or I haven't discovered the right place to look.)
Command line to ...
As far as I know, it is not possible to cancel a suspended MSI installation from the command line using MSIEXEC (it has no parameter for that).
Anyhow, you might try running the following command:
REG DELETE HKLM\Software\Microsoft\Windows\CurrentVersion\Installer\InProgress
This key is created when there is an installation in progress. Deleting it should ...
If it's an MSI, you're better off using Group Policy Software Deployment rather than a batch. It does exactly what you're looking for without having to test for previous installs.
As for your actual question:
What will practically happen if we keep just this command in the script, and a user who already has this package installed logs on, and the script ...
I checked this again, and here is some updated information:
It is possible to suppress the MSI GUI and set an external GUI implemented by a third party. This external GUI is able to receive messages from msiexec.exe as it performs the installation. This is mostly to implement a custom progress bar, but it seems you can also intercept most other error ...
Unfortunately, AD GPO software pushes are hard to troubleshoot. Your best bet is to turn on install logging and reviewing the file for what went wrong. Interpreting that file can be tricky and well beyond the scope of this question.
Turning logging on is described in KB314852, which describes how to turn on Windows Installer logging via GPO.
Open the ...
I believe the upgrade is the best-practise method for doing so. I have used this method quite extensively in the past without problems.
Add the new MSI as another Package in the Group Policy object, choosing the Advanced deployment method. It should be detected as an upgrade to the previously deployed Flash Player. If it's not you can add it to the updates ...
I've had horrendous numbers of seemingly random failures (see my note at the conclusion of this answer) with some of the v9, v10, and v11 Adobe Flash MSI's not uninstalling or upgrading properly, leaving the MSI database on the PC in a state that makes me wary. I've ended up resorting to using a startup script that:
Checks the HKEY_LOCAL_MACHINE\SOFTWARE\...
There is no way to disable this behavior for an msiexec command containing a syntax error. You could wrap the command into something like the following. It uses .NET Automation to look for the "usage" window and deal with it in-script.
Add-Type -AssemblyName UIAutomationClient
Add-Type -AssemblyName UIAutomationTypes
# Note the invalid argument '/...
Just heard back from support. This is a known issue in 6.2.2, and a fix is already in the pipeline for release in an upcoming version. I can't promise you a version number, but you can watch release notes for defect number SPL-95121.
You may want to test the SyncForegroundPolicy group policy setting. When enabled, you should see the Software Installation splash banner before the logon dialog.
"This policy setting determines whether Group Policy processing is synchronous (that is, whether computers wait for the network to be fully initialized during computer startup and user logon)...
Keep in mind that GPO installs run as SYSTEM. This causes unexpected behavior in some poorly written installers. If you really want to simulate a GPO installation, you'll grab a copy of psexec and run psexec -s msiexec -i path\to\msi /qb
Chances are that the add-in requires a user to be logged in. You might be able to work around this by using the GPO ...
If you are deploying a software installation package that is not user-specific and requires elevated permissions, that should be part of the machine group policy. In that case, it would not install in the context of the user, but as local system. User accounts should not have elevated permissions.
From msiexec.exe /?:
msiexec /Option <Required ...
This behavior can be disabled by setting the policy value to 0. Additionally, NOGOOGLEUPDATEPING=1 can be passed to the installer to prevent the omaha ping. See http://crbug.com/80567 and http://crbug.com/96243 for details.
I can confirm the problem is triggered by WMI queries to the Win32_Product class. But as documented in this other question below, you cannot use the Win32reg_AddRemovePrograms if you don't have SCCM/SMS installed and even if you do would have to use Win32reg_AddRemovePrograms64 to get a list of 64bit programs
If Tomas answer doesn't solve the problem you could try the MsiZap.exe Utility.
It basically also removes the metadata left by MSI installations, but it doesn't require you to find out all the locations where the information is stored.
E.g. deleting the inProgress information:
or delete rollback information:
I would just avoid going via msiexec.exe altogether. This is possible by going via the Windows Installer API using scripts or code.
You can go via COM automation using VBScript / VBA / VB, or using DTF which is a .NET wrapper for the Windows Installer API that's easier to work with from .NET languages such as C#.
You could even go directly via C++ to the raw ...
The most likely cause of this is that you ran the MSI silently via WMI and interactively when logged onto the server (short of the install never having run at all). Is this what you actually did? There are also other reasons that can cause the same problem. We would need to see the content of the update.cmd file to be sure.
To deal with the silent versus ...
Assuming it's a .NET application, the developer likely embedded a manifest that causes the application to request elevation when run. The manifest is named application.exe.manifest and needs to define the AssemblyName as the name of the program itself, so naturally renaming the .exe file will break the manifest and cause it not to prompt.
The workaround is ...
There is also a very helpful GUI tool called Product Browser which appears to be made by Microsoft or at least an employee of Microsoft.
It can be found on Github here Product Browser
The latest version as of (10/9/20) is available here
I personally had a very easy time locating the GUID I needed with this.