Messages

Done!

It's 1.5.3.0.

[DisplayMessageBox: "VMware Product Installation" - "This installer requires you to restart your system to finish installing Microsoft VC Redistributable and then re-run the installer.]

Good afternoon PatchMyPC Support

We are encountering issues with VMWare Tools not upgrading successfully, even though initially it looks as though it has installed. Specifically, we are looking at version 11.0.0.15108

Looking at logs from a particular machine, we can see Event logs that indicate that VMWare Tools is being installed (see VMWare 1 image). It then indicates that it has successfully installed the update (see VMWare 2). The machine then rebooted to complete updates 20 minutes later. Some hours later, we then get an event from WindowsUpdateFailure stating 'Updates have failed on this server' (see VMWare 3). The PatchMyPC-SoftwareDetectionScript.log file shows that all day today it hasn't been able to detect the so-called installed version (VMWare 4) and Control Panel still indicates that version 10.3 is installed.

From investigating further, the vminst.log file (see VMWare 5) located under C:\Windows\Temp indicates the following: 
DisplayMessageBox: "VMware Product Installation" - "This installer requires you to restart your system to finish installing Microsoft VC Redistributable and then re-run the installer.

I can supply the whole log file if needs be, but it suggests that this update needs two reboots, one for redistributables and then one for the tool themselves.

Please can you advise whether this behaviour can be changed, as it is somewhat confusing when reporting on installation successed and failures.

Russell

Thats appears to have fixed the issue - thank you!

Apologies - I have just double checked and this machine is actually a Windows 7 PC. The other machine experiencing this problem as well is also Windows 7. So the version of Powershell will be older, likely 2.0

It should be Powershell 5.0 as most machines are currently on Windows 10 1709.

Having tried that, I now see a new issue:

    In-line script returned error output: Method invocation failed because [System.Version] doesn't contain a method name
d 'Parse'.
At C:\Windows\CCM\SystemTemp\6dcf40f1-e8ac-4aa1-aaae-b9ffa2ffa7cc.ps1:118 char:
35
+     return [System.Version]::Parse <<<< ("0.0.0.0")
    + CategoryInfo          : InvalidOperation: (Parse:String) [], RuntimeExce
   ption
    + FullyQualifiedErrorId : MethodNotFound

Method invocation failed because [System.Version] doesn't contain a method name
d 'Parse'.
At C:\Windows\CCM\SystemTemp\6dcf40f1-e8ac-4aa1-aaae-b9ffa2ffa7cc.ps1:118 char:
35
+     return [System.Version]::Parse <<<< ("0.0.0.0")
    + CategoryInfo          : InvalidOperation: (Parse:String) [], RuntimeExce
   ption
    + FullyQualifiedErrorId : MethodNotFound

You cannot call a method on a null-valued expression.

I have attached another screenshot.

Russell

Heya

I was wondering how possible it would be to have an option for Updates and Applications to be synched separately on the Publishing Platform.

At the moment, running a sync triggers that both updates and applications download and publish to SCCM at the same time. It would be beneficial to us to separate this, so that updates can be triggered automatically and likewise with applications at different times.

The reason for this is because we would want to delay synching applications that are going to auto-update in our SCCM task sequences, until adequate testing has been performed on the updates that have been released. If we force applications to update straight away, it means that any new machines built will have the latest versions installed, bypassing any testing we might be currently doing.

[When a new version of an application is released, delay the in-place application upgrade by XX days]

Hey PatchMyPC.

We'd like to be able to use the functionality of the following setting under 'Base Install Options':

When a new version of an application is released, delay the in-place application upgrade by XX days

Currently this value goes up to 14. I would like to set this to 30, so that we can perform adequate testing over a longer period before releasing the new versions to live.

Can this limit please be increased?

Russell

I have just emailed them over, taken from an example machine with the issue

Heya

So on some machines that has been fixed with this preview. However I have noticed a different error occurring on some machines, which still presents the 0xfffffff error code.

AppDiscovery reports the following:

In-line script returned error output: Get-ItemProperty : The member "UninstallString" is already present.
At C:\Windows\CCM\SystemTemp\4ac20652-7723-43df-b9fe-0e3a51c6a08a.ps1:105 char:
21
+     Get-ItemProperty <<<<  $regpath -Name $propertyNames -ErrorAction Silentl
yContinue | .{process{if($_.DisplayName -and $_.UninstallString) { $_ } }} | Se
lect-Object DisplayName, DisplayVersion, UninstallString, PSChildName, Publishe
r, InstallDate | Sort DisplayName
    + CategoryInfo          : NotSpecified: ( [Get-ItemProperty], ExtendedTy
   peSystemException
    + FullyQualifiedErrorId : AlreadyPresentPSMemberInfoInternalCollectionAdd,
   Microsoft.PowerShell.Commands.GetItemPropertyCommand

I have attached an image for reference.

Russell

[Get-ItemProperty $regpath | .{process{if($_.DisplayName -and $_.UninstallString) { $_ } }} | Select-Object DisplayName, DisplayVersion, UninstallString, PSChildName, Publisher, InstallDate | Sort DisplayName]

Hey PatchMyPC

I have an issue to report regarding the PowerShell Script that is being used to detect your pre-made SCCM applications.

Issue:
Particular machines trying to deploy an application are reporting an error code of 0xffffffff. The Error Description in SCCM for the deployment is 'Script execution failed with error code -1'

Symptoms:
The AppDiscovery.log file on the affected machines display the error in more detail, stating:

In-line script returned error output: Get-ItemProperty : Specified cast is not valid.
At C:\Windows\CCM\SystemTemp\9f53767d-d483-4ff6-9523-d65e723a65d6.ps1:103
char:5
+     Get-ItemProperty $regpath | .{process{if($_.DisplayName -and
$_.UninstallStr ...

In reference to the particular line of the script, it is trying to run:
Get-ItemProperty $regpath | .{process{if($_.DisplayName -and $_.UninstallString) { $_ } }} | Select-Object DisplayName, DisplayVersion, UninstallString, PSChildName, Publisher, InstallDate | Sort DisplayName

Cause:
The problem, as reported on GitHub (see: https://github.com/majkinetor/au-packages/issues/15) is that Get-ItemProperty cannot interpret invalid DWORD entries. On the affected machines, due to bespoke custom applications installed, invalid DWORD entries exist within the Uninstall areas of the registry. Therefore, the script fails at this point and fails to evaluate whether the app is installed, thus preventing it from being deployed.

Because we allow software to be freely installed, there is an infinite possibility that an application generating a bad DWORD registry entry can be installed to any of our machines. This would stop ANY PatchMyPC application from deploying, as this part of the script is generic.

Can a fix be implemented for this please? I have attached images for reference.

When downloading TeamViewer 14.5.5819, I am seeing the following in the PatchMyPC log file:

"The hash of file downloaded is different than the file hash in our catalog. Hash errors happen when vendors release updates that aren't available in our catalog yet. This error should be resolved in the next catalog update. Additional details:Hash from catalog [Ur5/CaG9Ds2dVmDKwENa11r/uYU=] doesn...t match downloaded update hash of [J8bS6xk5q5P51Bg+PTN6J/hMihU=]"

Are you able to assist so I can get this downloaded successfully? I can confirm that other downloads are working fine.

Hi there

We currently deploy the TeamViewer Quick Support (QS) app, which is a standalone executable that can run from any directory.

Do TeamViewer updates via PatchMyPC cater for the QS app, or would it only work for the full installation of TeamViewer?

Thanks Justin - I actually tested earlier that with 0.71 the update seemed to work to 0.72, so we will use the base install for 0.72 to update everyone already on 0.66.