• Welcome to Support Forum: Get Support for Patch My PC Products and Services.

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.

Show posts Menu

Topics - Jared


I wanted to ask how others are handling this, or if we're missing something about the way PatchMyPC works.  PatchMyPC application updates (I believe with both ConfigMgr and Intune) are unable to update applications that were 1.) installed manually by a user and 2.) installed to the user's profile, rather than the system.

Zoom Meetings is a good example.  We do not use Zoom in our organization, but if a user joins an external Zoom meeting, the Zoom Meeting client will install to their user profile.  PatchMyPC is unable to update this.  Zoom is obviously quite popular, so now we have many unpatched versions of Zoom Meetings in environment.

Zoom is popular enough where it may make sense to simply deploy the client to the entire workstation environment, but there are many other applications that can be installed in the user profile but where it does not make sense to deploy globally.

Just looking for feedback on this topic.  Thanks.

I'm currently testing the Cisco AnyConnect bundle operations described in your article here.  So far this is working great for me, but large scale AnyConnect upgrades have a very high failure rate in our experience.  We've always done AnyConnect upgrades with a Task Sequence in ConfigMgr, and I'm trying to siphon the functionality from the task sequence into the Pre/Post script solution in PatchMyPC.

One of the things we do is kill all the AnyConnect processes before attempting to install the Core module.  If the Core fails, we attempt to kill the processes again, and repeat this several times.

So my question is:  Will the post script run even if the initial upgrade of the Core module fails?  If it does, that makes my solution easier since I can just attempt to kill the processes and reinstall the Core again in the post script.

If it does not, I can add a pre script to the Core upgrade to kill the AnyConnect processes.  But I think I'll only get one shot at that.  I can't run the pre script multiple times, and I probably shouldn't attempt to install the Core module from the pre script (or maybe I could, and then the actual upgrade would effectively take no action?)...


Just following up on this topic, which was covered in August 2020 here.  Since this thread, the app has been added to the list of recommended applications to automatically close.

We've enabled auto-close, but we're still getting reports of the error described in the original thread.  I saw it on my own system yesterday with the update to 1.58.2.  When I went to manually reinstall the app, setup continued to complain that five instances of Visual Studio Code were still running.  I tried to use the Automatically close the applications option in setup, but this failed.  I had to manually kill all five instances of code.exe before setup would continue.  Perhaps a similar force-quit needs to be coded into the VS Code update?  It doesn't seem like Microsoft is going to be fixing this any time soon.