Has anyone seen the issue before when .net patches (and sometimes office patches) fail to install via Bigfix but will install manually ?
We are seeing this on a handful of machines. Bigfix shows the patch is relevant for the target machine, attempts to install it but gets a 1642 return error. The logs would suggest when the patch is installing it doesn’t think it is relevant.
If I RDP to the box as admin and install manually it works fine and then patch becomes non relevant in Bigfix. This is using a downloaded version from MS.
It works on 99% of the estate. There is nothing in common with the failing 1%.
So the error (which is coming from the upgrade itself not from BigFix) means:
The installer cannot install the upgrade patch because the program being upgraded may be missing, or the upgrade patch updates a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch.
It seems its a common issue as you can google a ton of responses about this that are outside of BigFix
You could check the %WINDIR%\TEMP folder (of whatever your %TEMP% path is for SYSTEM account) and see if there are logs from the install the Bigfix client initiated and see if those may give any info. Logs for Office are usually names opatchinstall(xx).log (xx being an incrementing number). I think .Net patch logs start as “dd_NDP” followed by the version of .NET and KB number.
We get this too and the point which has been ignored is that the hotfixes install when run interactively but bomb with the 1642 error when run from a Bigfix action. So the error message suggests that whilst .NET & Office are installed, within the context from which the action runs they appear to not be installed.
We have a very consistent build process and most clients install OK, but some fail and having once failed they will always fail the .Net or Office upgrade. We can even remove .Net and reinstall from a Bigfix action and the patches will still fail in Bigfix and work interactively.
The location and naming standards for the logs is as above. The only difference in the logs between a working and non-working patch execution is
MsiDeterminePatch Sequence failed for product code {GUID}, error: 1605
MsiXmlBlog: this patch is not applicable
The BigFix context is running as the SYSTEM account, and by default in 32-bit mode. To test whether either of these is causing an issue, try using psexec from https://microsoft.com/sysinternals
Use psexec -i -s \windows\syswow64\cmd.exe to open a 32-bit command prompt in SYSTEM context, and see whether the patch installer gives an error when run from that command prompt. If it does, then try a new psexec -i -s \windows\system32\cmd.exe and see whether that also gives an error.
If only the first fails, then it’s a problem with 32-bit redirection and easy to solve.
If both fail, then it may be a problem running under the SYSTEM account, which may be more difficult.
As this is only a problem for a small number of your clients, it’s probably not the fixlet itself, but something wrong on those machines.