Messages

Makes sense! Thanks for your input!

Hey Ben!

Not really -- I'm searching for that option on "Updates" (software update packages), not for "ConfigMgr Apps" which, as you've shown, the option already exists.

Thanks!

Hey Hugo!

As a best practice, what would be your recommendation about certificates management? Should we remove old (expired) certificates from devices, and republish all software updates signed with the new certificate? Or would you recommend to keep both certificates (new and old) on devices, and leave already-published updates as-is?

While both options do work, I was wondering if Patch My PC has insights and best-practice recommendations.

Thanks!

Hello!

It is mandatory for our organization to have user-facing text description in French. We observed that, for software updates generated by Patch My PC, the default description added at packaging time is English-only, and there does not seem to be a way to customize it. Not possible, also, to clear the default text and leave it empty.

As a comparison, the localized description can be customized for configmgr apps -- thus, we can set custom text in French that is re-used by the Publishing Console at every repackaging.


Any idea, except completely hiding software updates deployments in Software Center?

Hey Hugo!

Thanks for the reply! Looking at it in our dev environment, and I do see the feature. Glad it's already present in the Publishing console!

Thanks Pete!

I'll document that for our IT team, that an app that should not sync anymore must be deleted manually both from SCCM and from storage.

I'll also open an idea to enhance the Publishing console, and see what the devs think.
#Edit: PATCHMYPC-I-3297

Wooooh nice! Thanks for the follow up!

[Steps to replicate:]

Hello!

Steps to replicate:

• In the Publishing console, under the "ConfigMgr Apps" tab, check the box next to an application to enable this app's creation in SCCM. For this test, let's use "Git (x86)";
• Run Publishing Service Sync, and wait for the sync to complete;
• Go in SCCM. Observe that a Git (x86) application has been created successfully;
• Return to the Publishing console. Untick the box in front of "Git (x86)" ConfigMgr App;
• Run Publishing Service Sync, and wait for the sync to complete;
• Go in SCCM. Observe that a Git (x86) application still exists. Its sources also continue to exist in the deployment type's source folder.

Is that the normal and expected behavior?
Did I miss an option somewhere in the Publishing console to remove an app (and its retained previous versions) when it gets unticked from the list of apps to sync?

If so, that's something I'll need to document when I do a knowledge transfert to my colleagues, and to remember to do some manual cleanup if and when an app gets unticked.

Thanks!

No problem, thanks Priscilla!

We are contemplating activating this setting globally, so while we are not currently affected by this situation, we will be in the future. No rush though.

Thanks Ben!

We're evaluating deploying Powershell 7 on all of our devices, so we were simply wondering if that could have adverse effects on patches installation which have a pre- or post-script. Based on your answer, that won't cause any issue.

Hello!

I think I found an issue in the Publisher Settings console (version: 2.1.16.0). After I set a custom location to create logs on "All Products", if I disable log management on a specific update then re-enable log management on it, the Folder path for that update has reverted to Patch My PC's default location.

Steps to replicate:

• Under the Updates tab, right-click on "All Products", and select "Manage installation logging". In 'Folder Path', type a custom location (i.e. 'C:\MyLogs');
• Scroll down on a specific product (i.e. "Adobe Acrobat DC Continuous (x64)"). Right-click on it, select "Manage installation logging", and uncheck 'Enable logging'. Click 'OK';
• On "Adobe Acrobat DC Continuous (x64)", right-click on it, select "Manage installation logging", and check 'Enable logging'. Observe that 'Folder path' is now filled with 'C:\windows\ccm\logs\PatchMyPCInstallLogs'.

Expected behavior: since I have selected a custom logging location on "All Products", I would have expected that when re-enabling log management the 'Folder path' to be filled with my globally-configured custom folder path.


Strangely, the other settings seem to persist when disabling then re-enabling log management:

• Under the Updates tab, right-click on "All Products", and select "Manage installation logging". Check 'Enable verbose logging', 'Prefix the log with computername', 'In case of installation failure...' and set a secondary location;
• Scroll down to "Adobe Acrobat DC Continuous (x64)". Right-click on it, select "Manage installation logging", and uncheck 'Enable logging'. Click 'OK'.
• On "Adobe Acrobat DC Continuous (x64)", right-click on it, select "Manage installation logging", and check 'Enable logging'. Observe that all the settings are still enabled;
• Still on "Adobe Acrobat DC Continuous (x64)", uncheck 'Prefix the log with computername', then uncheck 'Enable logging'. Click 'OK';
• On "Adobe Acrobat DC Continuous (x64)", right-click on it, select "Manage installation logging", and check 'Enable logging'. Observe that 'Prefix the log with the computer name' is unchecked.

Though if you uncheck 'In case of installation failure...', the secondary location is emptied, and checking the option again would not fill it with the globally-configured secondary location.

Hello!

Quick question: for ".ps1" pre-scripts and post-scripts, is the interpreter always Windows Powershell? Looking at PatchMyPC-ScriptRunner.log, I can observe that:

Code Select Expand

<...>
Running script preinstall.ps1 ScriptRunner 2023-08-23 2:50:30 PM 1 (0x0001)
Running PowerShell Script. ScriptRunner 2023-08-23 2:50:30 PM 1 (0x0001)
Running C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe -ExecutionPolicy Bypass -file "preinstall.ps1" ScriptRunner 2023-08-23 2:50:30 PM 1 (0x0001)
Exiting With code: 0 ScriptRunner 2023-08-23 2:50:31 PM 1 (0x0001)
<...>
I have set nowhere which version of Powershell to prefer, so I'm assuming ScriptRunner is responsible of selecting the appropriate one. I'm wondering if it will always default to Windows Powershell, or if it might at some point detect that PS7 is present and use it, or if it looks at a favorite interpreter somewhere, etc. ?

Thanks!

Thanks, that's what I feared.

From what I understood of the Patch My PC product is that it downloads the latest updates from the various providers, creates an update/an application based on your instructions/customizations, and injects the newly-created objects in SCCM. Next, what you do with the objects is up to you, and Patch My PC is not aware of it. Hence it's inability to track installations.

I've been looking at adding a post-install script to my updates that would generate something after installation completes. I would prefer not to rely on SCCM for that; creating a custom WMI class for hardware inventory and adding an instance in it for every install could work, but I would lose stats on deleted devices. I was then messing with creating an event in Windows' events logs, and capture that using Microsoft Monitoring Agent/Azure Monitor Agent and feed it in Log Analytics, but I've been having issues with our proxy. That's why I asked if you had anything native to Patch My PC.

I'll submit an idea and see how people react to it. 
PATCHMYPC-I-2972 - Dashboard to track number of installations accomplished by Patch My PC

No problem, I'll try to find a device we have not remediated yet -- or simply replicate in lab, and send the logs tomorrow!

Hi all,

We are currently reviewing Patch My PC, and I've ben tasked to find a way to count the number of installation that were realized by a Patch My PC update or configmgr app. Is there a way I can track that kind of statistics?

Currently, we allow apps that rely on a native updater (i.e. Google Chrome, or Adobe Acrobat/Reader) to auto-update using their built-in mechanism. On top of that, we've enabled these updates in Patch My PC. We want to quantify the number of updates that were done by PmP vs those completed by the auto-update mechanism.

Thanks!