1
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Microsoft PowerToys 0.17.0 (x64) Detection Script Error
« on: May 19, 2020, 08:14:34 AM »
Thanks for the correction. After deleting and re-creating it works.
Patch My PC Support
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages: [1] 2
2
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Microsoft PowerToys 0.17.0 (x64) Detection Script Error
« on: May 13, 2020, 06:11:55 AM »
Should the error already be fixed? No update has arrived on our server yet. Or does the application have to be deleted again?
3
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Microsoft PowerToys 0.17.0 (x64) Detection Script Error
« on: May 08, 2020, 11:48:37 AM »
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.
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.
4
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Mozilla Firefox ESR (x64 de) is not discovered after installation
« on: December 19, 2019, 02:27:19 PM »
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!
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!
5
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Mozilla Firefox ESR (x64 de) is not discovered after installation
« on: December 05, 2019, 11:03:59 AM »
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 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.
6
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: October 14, 2019, 06:24:38 AM »
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.
Since the required download time obviously varies a lot, an increase to 600 seconds would be very helpful for us in any case.
7
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: October 14, 2019, 01:58:59 AM »
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".
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".
8
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: October 11, 2019, 06:34:28 AM »
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).
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).
9
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: September 18, 2019, 12:52:49 AM »
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.
Unfortunately, there are problems with a few large downloads or certain download providers due to the currently fixed limitation to 100 seconds.
10
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: August 14, 2019, 12:20:13 PM »
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.
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.
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.
11
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: August 13, 2019, 09:50:56 AM »
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.
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.
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.
12
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: August 12, 2019, 12:03:02 PM »
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
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
13
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Problem with detection of successfully installed applications
« on: August 12, 2019, 11:45:12 AM »
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!
Thanks for the help!
14
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: August 12, 2019, 11:42:13 AM »
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.
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.
15
Report Publishing/Download/Hash Issues (Enterprises Using ConfigMgr and Intune) / Re: Timeout when downloading large files
« on: August 12, 2019, 11:27:18 AM »
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.
However, I will check again in the next few days via network capture whether there could be another cause.
Pages: [1] 2