Copy link to clipboard
Copied
Hi,
We use to have "Global Notifications Settings panel" in settings manager to notify users about the update. When packaging application for deployment we uncheck the notify update by copying settings.sol to all users and future user template preferences(/Users/$user/Library/Preferences/Macromedia/Flash\ Player/macromedia.com/support/flashplayer/sys/settings.sol). Last few days we are not able to find "Global Notifications Settings panel" in the settings manager.
We get the following error "The requested URL /support/documentation/en/flashplayer/help/settings_manager05.html was not found on this server." in the settings manager URL.
We use mms.cfg to disable autoupdate in Flash Player System preferences. Do we still need to use settings.sol file to suppress the Notify option in "Global Notifications Settings panel" or leave it since the "Global Notifications Settings panel" is not available?
OS X 10.10.2
Adobe Flash Player 17.0.0.134
Thanks & Regards,
Karthikeyan
1 Correct answer
Hi Karthikeyan,
The update tab of the online settings manager (http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager05.html‌) was recently removed. You should no longer need to check for this.
Thanks,
Chris
Copy link to clipboard
Copied
Hi Karthikeyan,
The update tab of the online settings manager (http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager05.html‌) was recently removed. You should no longer need to check for this.
Thanks,
Chris
Copy link to clipboard
Copied
Thanks for the reply Chris.
So we don't need settings.sol to disable the user notification only mms.cfg will suppress all the update options?
Thanks & Regards,
Karthikeyan
Copy link to clipboard
Copied
That's correct! Just deploy the mms.cfg and you're set.
Windows 64 location - c:\windows\syswow64\macromed\flash
Windows 32 location - c:\windows\system32\macromed\flash
osx location - /Library/Application Support/Macromedia/
Copy link to clipboard
Copied
Thank You Chris.
Copy link to clipboard
Copied
Curious, the Check Now button requires admin rights, but the Install Now button takes the user to a web page.
Is there a supported method to grey out both of these buttons?
Thanks,
Don
Copy link to clipboard
Copied
Currently there isn't a supported method to gray out the buttons.
Both installation methods require Admin rights to install. Flash Player writes to protected file system location and the OS requires Admin rights to write to the location.
Copy link to clipboard
Copied
Yep, got it.
What about the other tabs...did we lose the ability to manage their settings?
Copy link to clipboard
Copied
No, other settings are the same. Flash Player has always required Admin rights to install, this isn't something new.
Copy link to clipboard
Copied
I meant we were able to manage the settings under the Storage, Camera and Mic, Playback, and Advanced tabs.
Did we lose the ability to manage these settings, once the directive became to not deploy settings.sol?
Copy link to clipboard
Copied
[update] Sorry, I misread your post earlier.
I've been trying to find a reference to the directive to not push settings.sol in our documentation, but I'm not finding it the administrator guides (I only went back a few versions). That said, it sounds like reasonable guidance. I was just curious about any context that might definitively clue me in to the reasoning at the time.
While you could probably configure a player instance the way that you want it, then push out a settings.sol by default, I don't believe that's a use-case that we've explicitly designed for, and could be problematic over the long term, should we need to change the implementation in the future. Historically, decisions to support clever solutions have come back to haunt us as painful engineering constraints and intractable legacy problems. Should we find ourselves in a position where changing the handling of settings.sol is necessary to solve an engineering issue, having multiple supported paths for enterprise client configurations could force us into a painful stance where we have to make a hard break with compatibility, which we try diligently to avoid.
My guess is that this has already happened in the past, which led to the original guidance, or it's a very real concern for a particular domain expert at a given point in time. It *is* an internal configuration file, and with a codebase that's been in active development since 1997 and the number of places inside the player that it intersects with, it's plausible that we've made design assumptions along the way about it's availability and integrity. At the very least, it would be difficult to definitively assert the inverse.
The supported path for configuring client behavior in an enterprise environment is to distribute a customized mms.cfg to your clients. There's a comprehensive list of directives in the system administrator's guide, here: Adobe Flash Player Administration Guide for Flash Player | Adobe Developer Connection
As a general rule, mms.cfg directives take precedence over user settings, so even if the relevant panels are available, users shouldn't be able to override your settings. For any high-risk scenarios, it would probably be worth double-checking that assumption for peace of mind, but it should hold true and we'd be happy to help if bugs bubble up through that evaluation.
If you're running into a scenario that you can't solve with the current set of directives, we'd definitely like to know about it. We invest a lot of time and effort into making life easier for network administrators, and when it's feasible, we're happy to try and provide additional pain relief.
