Messages

The update is big enough that making it a separate product in the publishing service was a good call.  We've heard from some people that 2.x breaks things and they need to stay on 1.x.

The worst part of the 2.x silliness is that .NET 5 is end-of-life.

I see, thanks.  I'm thinking we're still better off ripping the user-based installs out and replacing them with the system-based install.  Either way, it'll be a somewhat heavy-handed extension of ConfigMgr in order to properly inventory these user-based installs for targeted deployments.  My colleague found a very good article that outlines using Config Baselines and custom hardware inventory classes in order to achieve this:  https://www.scottjfairchild.com/blog/17/how-to-inventory-microsoft-teams-zoom-and-other-user-based-applications

Interestingly enough, I do see that you support updating the user-based installs of Zoom Meetings in Intune.  Can this not be back-ported into ConfigMgr?

Hi,

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.

Thanks Adam!

Does the pre-script run before or after the Manage Conflicting Processes functionality occurs?

You mean the post-script will not run, right?

Ah, I never saw that Manage Process List button in the conflicting processes window!  Thanks.

Hi,

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?)...

Thanks

Hi Andrew,

Yes, it's definitely an issue with the VS Code installer.  The question was really how or if we could work around it in an automated way.  The pre-script idea is great, I just haven't had a chance to implement it yet.  I'll report back when I do!

Yes, we do.

If code.exe is still running by the time it gets to the pre-script, then you know it didn't close properly by the "manage conflicting processes" workflow.

Great info, thanks!  I'll probably give this a try.

It nearly seems random, and the volume of issues appears to be relatively low.  But if enough people complain we may have to do that.

I'm still curious as to why the command to stop code.exe is failing with access denied when running as admin.  I was able to stop it manually.  Is there a way I can modify the update execution?  I would like to try and introduce something similar to this:

EDIT:  Code change

Code Select Expand

If (error 5) {
  Start-Sleep -Seconds 30
  Try to kill code.exe again
  If (good) {
    Try to update again
  }
}

I did see that, but I didn't make the change because I generally like to run my apps in roughly the same configuration as a typical user.  I would consider this a workaround, and it's not something we could easily manage on the scale of thousands of endpoints.

Sorry, just noticed that wasn't the file you asked for, haha.  Here you go.

The PowerShell extension, the Remote WSL extension, and then three themes.

Hey Adam, sure.  Here you go.

Hi,

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.