It was making me more than a little crazy, and I don't have far to reach the end of that road as it is... :)
On Mon, Jan 16, 2017 at 8:47 PM, Micheal Espinola Jr < [email protected]> wrote: > WOW, just... wow. Thanks for the follow-up on this! > > -- > Espi > > > On Mon, Jan 16, 2017 at 8:02 AM, Richard Stovall <[email protected]> > wrote: > >> For anyone else that may be seeing the Flash update issues in Chrome. If >> you're using SEP, this may be your issue. >> >> https://bugs.chromium.org/p/chromium/issues/detail?id=651945 >> >> --------- >> >> Symantec has confirmed that this is a known issue. Below is their response >> to our case. >> >> After reviewing this case and the available data (primarily the provided WPP >> logs) I have found that this is a known-issue with the SEP 12.1 and SEP 14 >> products. SEP is attempting to obtain a hash of the Adobe Flash Player file >> 'pepflashplayer.dll'; however, during the hash operation, Chrome is >> attempting to move the file from a temporary folder (where SEP is performing >> the hash) to Chrome's plugin folder; since SEP has a lock on the file, >> Chrome's move operation fails and the plugin update process aborts. >> >> Symantec has identified a fix for this issue and is planning on including a >> resolution in the next release of SEP 12.1 and SEP 14, both due out early >> next year. >> >> It is possible to work around this issue by disabling deferred scanning for >> AutoProtect; however, this is not generally recommended in production unless >> absolutely needed, as it disables scan throttling based on I/O activity. >> >> For more information on disabling deferred scanning, please see the >> following KB document: >> >> How to disable deferred scanning in Auto-Protect for Symantec Endpoint >> Protection >> <https://support.symantec.com/en_US/article.TECH224108.html>https://support.symantec.com/en_US/article.TECH224108.html >> >> It is also possible to work around the issue by temporarily disabling SEP; >> however, this is a potential security issue, as you will be temporarily >> disabling the product from being able to scan files. >> >> >> On Mon, Oct 31, 2016 at 7:10 PM, Micheal Espinola Jr < >> [email protected]> wrote: >> >>> Right, for which if I understand the process correctly, you are >>> dependant on Google Updater to update various components after the fact - >>> that are not a part of the core application update. So, you may have >>> download restrictions in place that are preventing the update of the flash >>> component. This methodology appears to be acknowledged in the top response: >>> >>> Chrome is rolling out some optimizations to the Chrome install process, >>>> whereby the Flash Player component will automatically be installed a few >>>> minutes after the initial Chrome installation. >>> >>> >>> -- >>> Espi >>> >>> >>> On Mon, Oct 31, 2016 at 3:41 PM, Richard Stovall <[email protected]> >>> wrote: >>> >>>> Well, this pretty much explains what I'm seeing. >>>> https://forums.adobe.com/thread/2221587. >>>> >>>> >>>> On Mon, Oct 31, 2016 at 6:23 PM, Micheal Espinola Jr < >>>> [email protected]> wrote: >>>> >>>>> I cant speak for Ninite-driven upgrades, but have you tested Google >>>>> Updater driven upgrades? Perhaps the issue is with Ninite, and not Google >>>>> Chrome itself. Or perhaps you need to review your methodologies inline >>>>> with your download restrictions. >>>>> >>>>> -- >>>>> Espi >>>>> >>>>> >>>>> On Mon, Oct 31, 2016 at 2:36 PM, Richard Stovall <[email protected]> >>>>> wrote: >>>>> >>>>>> Getting back to this. Sorry for the delay... >>>>>> >>>>>> Google is apparently de-emphasizing Flash's use with an eventual plan >>>>>> to drop it completely. (Which I'm all for.) >>>>>> >>>>>> The problem is that it's still alive and well, but updating to Chrome >>>>>> 54.X no longer automatically updates Pepper Flash along with core Chrome. >>>>>> At least on Windows, it looks like they're moving Flash to the *local >>>>>> user profile* and relying on the Chrome Component Updater to >>>>>> download it as necessary. (Check your appdata\local\google\chrome\user >>>>>> data\pepperflash folder.) >>>>>> >>>>>> We manage Chrome updates at work and this is breaking our current >>>>>> system. Very frustrating. May be moving back to Firefox so at least we >>>>>> can keep this stuff up to date. Moving Flash to the local profile seems >>>>>> like a genuinely bad idea. >>>>>> >>>>>> Is no one else seeing issues with this at work? >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Oct 18, 2016 at 10:25 PM, Micheal Espinola Jr < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hasn't Chrome started the phase-out of Flash? However, I'm on 54 >>>>>>> and I can see Adobe's Flash test page fine. >>>>>>> >>>>>>> I'm not aware of any Flash update options relating to current >>>>>>> versions of Chrome. >>>>>>> >>>>>>> -- >>>>>>> Espi >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 18, 2016 at 5:07 PM, Richard Stovall <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> Does anyone know what is really going on with Flash and Chrome 54? >>>>>>>> It doesn't appear to be bundled with Chrome anymore. I use Ninite to >>>>>>>> update Chrome at $work, but now that doesn't work. (Chrome updates, >>>>>>>> but >>>>>>>> Flash does not.) We restrict downloads of .exes and .dlls, so if >>>>>>>> Chrome is >>>>>>>> trying to autoupdate Flash via direct download, that won't work. >>>>>>>> >>>>>>>> I haven't had time to do a deep dive into this. Was hoping someone >>>>>>>> else had seen the behavior and knew for sure what has changed with >>>>>>>> Chrome >>>>>>>> 54 and what the Flash update options are. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> RS >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
