Messages

Thanks for testing. This should be resolved in today's catalog update, please let us know if you continue to experience this issue tomorrow.

Can you try toggling that application off and on in the publisher, click "apply" then right click, republish then resync?
We added a new script to the application to block norton from installing and I am thinking it is not being enabled correctly. Toggling the app off and on should set the settings correctly and allow a republish.

We'll definitely keep an eye out, and if you are able to determine how to block updates, please let us know and we will add it to the product. Thanks!

I just did some additional searching and it does not seem that Amazon has added this feature. I did notice multiple complaints about this same issue on their boards however.

SCCM uses WSUS for it's update deployments, so that part should be just fine.

Your method should still work, and if you are on the Basic license, I believe that is how you have to manage things generally. We do have more automated methods available on the Enterprise plan if you are interested.

I have seen iTunes act odd before, but always have a hard time replicating and determining what the actual issue is. I haven't heard anything about Dropbox updates causing problems though.

Thanks for reporting, we'll keep an eye out for additional issues!

So I was working on this and noticed that there are release notes for an even newer version. https://www.cisco.com/c/en/us/td/docs/security/vpn_client/anyconnect/anyconnect48/release/notes/b_Release_Notes_AnyConnect_4_8.html#Cisco_Reference.dita_6d81e53e-c14c-46de-b5d7-c4e3ed2e58c2
We'll be adding that version to the catalog early next week instead.

I was unable to repro in our test environment. SCCM 2003 TP and Windows 10 2004.

This is excellent, we will work to reproduce the issue and try to get it on Microsoft's radar. Thanks again for bringing it to our attention!

Hello,

We're not currently tracking this issue, but will set up a Windows 10 2004 system in our lab and see if we can reproduce. We'll keep you updated on what we find.

Turning out to be trickier than expected... We'll keep investigating!

Thnx a bunch for your trouble!
Btw, why not switch to detection by file version? Chrome on a x64 system always gets installed to "C:\Program Files (x86)\Google\Chrome\Application", and on a x86 system to "C:\Program Files\Google\Chrome\Application", right?

You would think so, but that isn't always the case. We do use file version, but rely on the path provided by that registry value to get the Google Chrome path. Literally the only difference between the Google Chrome and Beta installer is where they are installed, which is why we haven't been able to differentiate between the two.

An alternative for you for now could be to set a CI or Group Policy to set the reg key "SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\chrome.exe\Path" to the path where Google Chrome <non-beta> is installed such as

Code Select Expand

C:\Program Files (x86)\Google\Chrome\Application

Turning out to be trickier than expected... We'll keep investigating!

We're looking at this now. I think we found a good alternate path to look for that wont pull the beta.

I think the native ConfigMgr App Export/Import are going to be your best bet here. If you export with content it should be a relatively pain-free process, so long as the signing certificates are trusted in the offline environment.

We are investigating this as an install method. Please see https://ideas.patchmypc.com/ideas/PATCHMYPC-I-204. Thanks!