Messages

Thanks Adam. I deleted the Putty Application from CM console and deleted the source files from disk. Resynced PMP, deployed Putty, tested installation and it was successful.

Just want to add that I restored the Putty 0.77 version and that installs properly. I will leave that in place until the 0.78 package is fixed.

We are having a problem with the PMP Putty 0.78 package (SCCM). It is failing to install on all computers we have attempted, returning the same error code. The error code is 0x8000(32768). Do not believe we are having any problems with other PMP Application packages installed from the Software Center. As a test, I verified that the WinMerge package installs successfully.

This is a log from AppEnforce.log of one of the computers:

+++ Starting Install enforcement for App DT "PuTTY 0.78 (x64)" ApplicationDeliveryType - ScopeId_F8C75349-4CF6-4711-9C4A-97B6298C64CB/DeploymentType_98cf91a3-634e-4e8b-8c46-cedaf12309db, Revision - 4, ContentPath - C:\WINDOWS\ccmcache\1ec, Execution Context - System   AppEnforce   12/15/2022 9:04:45 AM   22020 (0x5604)
    Performing detection of app deployment type PuTTY 0.78 (x64)(ScopeId_F8C75349-4CF6-4711-9C4A-97B6298C64CB/DeploymentType_98cf91a3-634e-4e8b-8c46-cedaf12309db, revision 4) for user.   AppEnforce   12/15/2022 9:04:45 AM   22020 (0x5604)
+++ Application not discovered with script detection. [AppDT Id: ScopeId_F8C75349-4CF6-4711-9C4A-97B6298C64CB/DeploymentType_98cf91a3-634e-4e8b-8c46-cedaf12309db, Revision: 4]   AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    App enforcement environment:
   Context: Machine
   Command line: PatchMyPC-ScriptRunner.exe /InstallPackage
   Allow user interaction: No
   UI mode: 1
   User token: not null
   Session Id: 1
   Content path: C:\WINDOWS\ccmcache\1ec
   Working directory:    AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    Prepared working directory: C:\WINDOWS\ccmcache\1ec   AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    Prepared command line: "C:\WINDOWS\ccmcache\1ec\PatchMyPC-ScriptRunner.exe" /InstallPackage   AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    Executing Command line: "C:\WINDOWS\ccmcache\1ec\PatchMyPC-ScriptRunner.exe" /InstallPackage with user context   AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    Working directory C:\WINDOWS\ccmcache\1ec   AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    Post install behavior is BasedOnExitCode   AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    Waiting for process 16472 to finish.  Timeout = 120 minutes.   AppEnforce   12/15/2022 9:04:47 AM   22020 (0x5604)
    Process 16472 terminated with exitcode: 32768   AppEnforce   12/15/2022 9:04:49 AM   22020 (0x5604)
    Looking for exit code 32768 in exit codes table...   AppEnforce   12/15/2022 9:04:49 AM   22020 (0x5604)
    Unmatched exit code (32768) is considered an execution failure.   AppEnforce   12/15/2022 9:04:49 AM   22020 (0x5604)
++++++ App enforcement completed (3 seconds) for App DT "PuTTY 0.78 (x64)" [ScopeId_F8C75349-4CF6-4711-9C4A-97B6298C64CB/DeploymentType_98cf91a3-634e-4e8b-8c46-cedaf12309db], Revision: 4, User SID: S-1-5-21-xxxxxxxxx] ++++++   AppEnforce   12/15/2022 9:04:49 AM   22020 (0x5604)

EDIT: Never mind on this post. Installations still taking longer than expected.

I don't have any definitive evidence, but I may have stumbled upon something that can speed up the installation time. While preparing for a Windows 10 Feature Update deployment and doing some research, I discovered this best practices from Microsoft: https://docs.microsoft.com/en-us/windows/deployment/update/feature-update-maintenance-window#step-4-override-the-default-windows-setup-priority-windows-10-version-1709-and-later

The document indicates that the default configuration for update installation Priority is Low and that you may need to change this to Normal in order for feature updates to install in a timely fashion. The way to do this is create the file: %systemdrive%\Users\Default\AppData\Local\Microsoft\Windows\WSUS\SetupConfig.ini that includes a [SetupConfig] key with property/value: Priority=Normal. I have done this on several computers, including my workstation. Since doing this, it seems like all updates, not just W10 Feature updates, are installing much faster. This includes Patch My PC updates. Could just be my imagination, or maybe not. The location of SetupConfig.ini shows nothing to indicate that it is only for Windows 10 Feature updates. This needs some more validation, so if anyone wants to give it a try, I would like to hear your results.

Thanks. I have already declined and purged those from the database back when I stopped syncing them. I am well familiar with the misery of WSUS's terrible database housekeeping lol. I had to work with Microsoft support because SCCM syncs were failing. It took me about a week of running the spGetObsoleteUpdatesToCleanup + spDeleteUpdate stored procedures just to get WSUS functional. Unless something has changed in newer versions, WSUS built-in maintenance doesn't delete obsolete updates from the database; only the files on disk. I have a SQL job that runs those SPs weekly and it has kept performance pretty optimal.

Thanks Cody. This is good to know. I do have catalogs enabled for Adobe, Dell and HP. I am going to disable Adobe and HP and see if that makes a difference. We no longer need Adobe because of PMP and we are phasing out HP, so don't need that either. I had already disabled SUP sync for those Products some time ago, so I guess there is not point in having Catalogs enabled.

As for the issue, I have not confirmed the extent as we have only recently started using third-party patching a great deal now that we have PMP. I have only seen this on my test computers as well as my workstation. It is not of concern yet as we are slowly rolling out third-party updates available from PMP. But as we add more products, it may cause total patch times to increase. We do have a pretty generous maintenance window for our workstations, so I am not too concerned at tis time.
We are not using any cloud or internet based management yet, but that may be something to consider in the future. We only have on-premise management and have recently started evaluating Co-management.

Thanks again. I will take a look at WindowsUpdate.log when I get a chance to do some testing.

Thanks Andrew. I just checked my Client Settings and we do not have the setting "Allow clients to download delta content when available" enabled.

I doubt this is anything specific to Patch My PC, but I've noticed that it seems to take much longer for ConfigMgr clients to install third-party updates than it does to install Microsoft updates on my computers. More specifically, it seems to take longer to start the installation. For example, if I initiate an installation of several Microsoft updates and several Patch My PC updates, the Microsoft updates will begin to install and finish much quicker than third-party (Patch My PC) updates to start and finish. Is this typical? I perform regular database maintenance on the SUSDB, such as deleting obsolete updates and declining updates that I do not need. I know when unused updates build up in the database, it can cause clients to take a long time to scan.

The only thing I can see going on while the client is waiting to start the installation of an update is the WmiPrvSE.exe being highly active. Once the installation starts, it pretty much goes idle. I know the client uses WMI host for much of its work. What is it doing when it goes to install these updates? Is it scanning all updates every time it install a third-party update? If so, why does it not seem to do this for Microsoft updates? I have also looked at scanagent.log and UpdatesHandler.log and there doesn't seem to be a too much going on in there during this time.

Thanks Cody. I got the SSRS reports installed and found what you are referring to in the "Sub -Third-Party Updates By Device" report. It is the column InfoURL in the dbo.v_UpdateInfo view. Microsoft updates look to always have that populated with a URL, where third-party updates have a blank value (not null). That should work fine, though I can see that non-Patch My PC third-party updates may come back with that query (HP and Dell updates), but that is a very limited scope in our environment as we don't typically deploy those.

Hi. We have just purchased Patch My PC and I am in the process of getting it setup. I have custom SSRS reports for displaying data on "needed" and "failed" updates for our computers. I am building a report just for third-party updates and looking for a simple way to query for just Patch My PC updates. I am using the dbo.v_UpdateInfo view to pull in a list of update names. I thought to use the ArticleID column, WHERE ArticleID LIKE 'PMP%' but I have noticed PMP updates do not always being with PMP. There is no Vendor column, nor do I see any type of vendor uid in this view. SCCM console can filter on Vendor, so it is obviously possible. Any suggestions appreciated. Thanks.