Messages

Thanks for the correction. After deleting and re-creating it works.

Should the error already be fixed? No update has arrived on our server yet. Or does the application have to be deleted again?

The Powershell detection script for PowerToys contains an error.

Line 30 is incorrect:
$AppToSearch = 'Microsoft Power BI Desktop*(x64)' 

This prevents the app from being installed if Microsoft Power BI Desktop has already been installed. I just deleted the application again on the SCCM and downloaded it again. The error comes back.

[x64]

We have analyzed the problem.

The Powershell Detection Method Script ("C:\Program Files\Patch My PC\Patch My PC Publishing Service\Detection Method Scripts\Mozilla Firefox ESR 68.2.0 (x64 en).ps1"), which is stored in SCCM at the Deployment Type, checks for the 32 instead of 64 bit version (line 24: $AppToSearch = 'Mozilla Firefox*ESR*(x86 en)' ...). This was already the case in the previous version.

Please correct the detection script!

[German]

Mozilla Firefox ESR (x64 de) is installed executable but not detected correctly by the SCCM agent. (AppEnforce.Log: ...+++ Application not discovered with script detection...).

I have already deleted the SCCM application and the source directory several times. All other selected applications are working fine.

The error has been occurring in our environment since the first release of the separate German Firefox ESR version about two weeks ago. Unfortunately I haven't come to the error report yet.

I just saw in the log that the download of the LibreOffice x64 version on Sunday took only 3 minutes 42 seconds (=222 seconds). The days before were always more than 5 minutes (=300 seconds) required for the download.

Since the required download time obviously varies a lot, an increase to 600 seconds would be very helpful for us in any case.

Thanks for the adjustment! With the registry key DownloadTimeout=600 and the new preview version 1.5.4.2 all current downloads were successful for the first time!
The only thing that doesn't seem to be right is the display in the log. There I still see "Download timeout is 300000 milliseconds".

Thank you for the implementation!!! The configuration of the Download Timeout works.

But could you raise the configurable upper limit to at least 600 seconds?

There is still a download that obviously takes longer than 5 minutes (http://ftp.osuosl.org/pub/tdf/libreoffice/stable/6.2.7/win/x86_64/LibreOffice_6.2.7_Win_x64.msi).

Could you check whether a configuration of the download timeout time would be possible?
Unfortunately, there are problems with a few large downloads or certain download providers due to the currently fixed limitation to 100 seconds.

I repeated the tests because I didn't really trust the very high values of yesterday. This time I used the Powershell function Start-BitsTransfer. The download times are much shorter and probably more comparable with Patch-My-PC.

http://ftp.osuosl.org/pub/tdf/libreoffice/stable/6.1.6/win/x86_64/LibreOffice_6.1.6_Win_x64.msi	195 sec
http://armdl.adobe.com/pub/adobe/acrobat/win/AcrobatDC/1901220035/AcrobatDCUpd1901220035.msp	120 sec
https://cdn.devolutions.net/download/Setup.RemoteDesktopManager.2019.1.39.0.msi	21 sec

The Remote Desktop Manager was probably a temporary problem yesterday.

On the basis of these measured times an extension of the timeout to 300 seconds would seem to be good.

I ran some tests on the server with the download URLs aborted by Patch-My-PC using the Powershell function Invoke-WebRequest (which has a -TimeoutSec switch for extending the timeout). Whether the values would be comparable with the .Net download function you used, I cannot estimate.

http://ftp.osuosl.org/pub/tdf/libreoffice/stable/6.1.6/win/x86_64/LibreOffice_6.1.6_Win_x64.msi	640 sec
http://armdl.adobe.com/pub/adobe/acrobat/win/AcrobatDC/1901220035/AcrobatDCUpd1901220035.msp	539 sec
https://cdn.devolutions.net/download/Setup.RemoteDesktopManager.2019.1.39.0.msi	1468 sec

But the main reason seems to be that these sources provide the files only with limited bandwidth.

As already written, for all other downloads we use, the 100 sec time window seems to be sufficient for the download.

I'll check that out.

Please consider the following note. If you are using the HttpClient from .Net, then the download time can be extended via the Timeout property.  It is 100 seconds by default, which corresponds to the time where the download is currently aborted in Patch-My-PC (which may also be a coincidence) https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient.timeout?view=netframework-4.8

The problem was solved with one of the last preview updates. I also had to delete the affected SCCM applications and source directories.

Thanks for the help!

Yes, as a workaround this is possible. However, I would like to avoid manual downloads in the future.

In principle, we can also switch off the virus scan for these downloads on the proxy as a workaround. Then the downloads will be forwarded to the Patch-My-PC service as supplied by the source. However, I would like to avoid this for security reasons.

I haven't done a network capture yet. However, most other downloads work fine. The proxy always waits for the complete download to complete, so that it can perform a virus scan before forwarding it to the client. For the affected products the download is obviously too slow to download the file within 100 seconds, check for viruses and then forward it to the Patch-My-PC service. I currently assume that adjusting the proxy timeout to e.g. 300 seconds could solve the problem.

However, I will check again in the next few days via network capture whether there could be another cause.