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

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

Messages - jhaynes

#1
Hi Andrew,

Thank you for replying. Yeah our environment is certainly abit more unique annoyingly. But thanks for clearing that up in regards to the updating of Android Studio as I will have to inform our Security team this will likely be a permanent thing.

Yeah I have made a collection of devices we want to not have android studio patched for now and created a new ADR to filter out that update.

Thanks again for the info.
Regards,
James
#2
Quote from: Andrew Jimenez (Patch My PC) on October 22, 2024, 09:31:12 AMI think you'll find all of your answers for logs here: https://patchmypc.com/logs

What you are seeing is expected. Typically WSUS updates run from SoftwareDistribution, and ConfigMgr Apps will run from CCMCache.
Thank you for this link! that's useful and I've bookmarked.


Quote from: Spencer (Patch My PC) on October 22, 2024, 10:03:55 AMHey James,

Thanks for reaching out to support!

That is expected behavior as all content deployed from SCCM is downloaded to the local cache (CCMCache). Updates are then copied over to the SoftwareDistribution folders since that's what the WUA uses to process the updates. Products that do not have any right-click options enabled on them from the PMPC Publisher, will not output logging info in the scriptrunner.log

It's possible, content was cleared out in the CCMCache for those updates but left over in the SoftwareDistribution folder.

We can also look at the following ConfigMgr logs (like CAS.log which will show you if ConfigMgr downloaded the file and WIndowsUpdate.log (which will show you if the WUA downloaded the file).

https://patchmypc.com/collecting-log-files-for-patch-my-pc-support#update-troubleshooting-client-logs:~:text=Third%2DParty%20Software%20Updates%20Failing%20to%20Install%20on%20Client%20Devices

I also came across this post from Jason Sandies indicating the same behavior:
https://techcommunity.microsoft.com/t5/windows-servicing/location-of-windows-updates-download-with-configmgr/m-p/2144311


Okay, thank you both clarifying this and very quickly too! This has been a misunderstanding on my part then as I assumed with them being apps that they would always show under the CCM Cache folder. What you've said makes sense and what you said about the CCMCache folder.

Feel free to close this please as you've cleared this up for me.

Thanks again,
James H
#3
Hi all,
I have a 2 part query.

Query 1
I recently had some users complain about getting an error (attached) with Android studio when opening which I later found was due to PMP pushing the latest version of Android Studio.

So, to give context it seems when an older version of Android Studio is installed which in our case is Giraffe | 2022.3.1 (Not verified if the error occurs with any other older versions, just Giraffe atm)

Patch my PC would deploy the latest Android Studio version which as of now is Ladybug | 2024.2.1
When this happens upon opening Android studio you would get the attached error, which seems related to a plugin.

However, should this type of updating happen? Shouldn't PMP only update the current version? So, essentially only push build updates in this case for Giraffe | 2022.3.X
From what I can tell, as it's not obviously clear looking at Android Studio Developer Releases the below versions are technically still in support and getting periodical updates?

Ladybug            | 2024.2.1
Koala Feature Drop | 2024.1.2
Koala              | 2024.1.1
Jellyfish          | 2023.3.1
Iguana             | 2023.2.1
Hedgehog           | 2023.1.1
Giraffe            | 2022.3.1
Flamingo           | 2022.2.1

Either way if this is expected, the users that are complaining about this error are actually required to stay on the Giraffe version of android studio. So, I have had to employ a exemption by setting up another ADR and collection.

Query 2 - following on from just above
Which by the way seems a rather excessive way of excluding specific machines from a specific update but the only way I know it can be done. Unless there is a better way I don't know of?
 
I read these two docs on exemptions that helped me setup exemptions.
How to Use Automatic Deployment Rules (ADRs) with Patch My PC Updates
How to Remove Already Published Third-Party Software Updates

But in our estate/environment where we have multiple studios and many projects, often some projects require staying on specific versions or builds of apps/software. So, were going to end up with quite alot of PMP ADRs just for exemptions.
This also requires ensuring that with any new exemptions, checking the machines are not part of any existing ADRs/collections. Which is why it seems rather extreme if you get where I'm coming from?

So in a constant battle of keeping machines patched this becomes a headache, so is employing ADRs with filters the only way to exclude a group of machines from a specific update due the the limitation of using ADRs?

Regards,
James H
#4
Hi all,

I just want to check the behavior for Config Mgr PMP Updates.
I was under the assumption that all third party app updates delivered by PMP should end up in the CCM Cache? Just like WSUS updates/content? I'm guessing this maybe not always the case?

And that I should be able to see these updates in the PatchMyPC-ScriptRunner.log?

For some new updates such as Helix Core Apps, Wacom Tablet app, Android Studio I did not see these in the CCM Cache folder. I didn't see them in the PatchMyPC-ScriptRunner.log either well apart from Android Studio that did show in here.

This threw me at first but after further reviewing Updates Deployment log I saw PMP delivering these, however these updates are showing as Windows updates?
I saw in event viewer the Windows Update client is delivering these and updates and installing from the SoftwareDistribution folder which is used by Windows Updates so, this also threw me as I didn't look at the updates deployment log until after this.

So, I just wanted to check that this is expected behavior? Just so I know in future when log diving / troubleshooting.

Regards,
James H