Adobe Flash Internal Update Server - mms.cfg replaced and new schedule task

[fernandom2258471]

I implemented the Adobe Flash Internal Update Server. More than 80k machines are connected to the server. All good till a few releases ago.

I've noticed 2 additional steps that auto update made:

1) replaced my mms.cfg (containing all the info the the server and config) by one almost empty with no server info like this one:

SilentAutoUpdateEnable=1

AutoUpdateDisable=0

the original one was:

AutoUpdateDisable=0

SilentAutoUpdateEnable=1

SilentAutoUpdateServerDomain=myserver

SilentAutoUpdateVerboseLogging=1

AVHardwareDisable=0

RTMFPP2PDisable=0

LegacyDomainMatching=1

LocalFileLegacyAction=1

2) Created a new windows task schedule ran with user's credentials:

Adobe Flash Player NPAPI Notifier

running: C:\WINDOWS\SysWOW64\Macromed\Flash\FlashUtil32_29_0_0_140_Plugin.exe -check plugin

Do you happen to know what is going on ? this new mms.cfg file is breaking the auto update and the task is poping up to users update via internet.

Please help !

[_maria_]

Hi fernandom2258471​,

The Adobe Flash Player NPAPI Notifier was introduced in version 29.0.0.113.  The Notification Update mechanism for the NPAPI plugin was moved from Flash Player itself to this new Task.  This is similar to the Adobe Flash Player PPAPI Notifier task for the Notification Update mechanism.

There was a bug in 29.0.0.113 that the Notifier Task was not correctly parsing the mms.cfg file if it was saved in UTF-8 w/BOM.  This was fixed in version 29.0.0.140.  It's possible this is what you are experiencing.  Can you please provide the following files from an impacted system (all files from the same system):

• original mms.cfg file deployed to the system
• mms.cfg file created after the installation
• FlashInstall log file(s) saved at:
  • 32-bit OS: C:\Windows\System32\Macromed\Flash\FlashInstall32.log
  • 64-bit OS: C:\Windows\System32\Macromed\Flash\FlashInstall64.log AND C:\Windows\SysWOW64\Macromed\Flash\FlashInstall32.log

Upload the files to cloud.acrobat.com/send using the instructions at How to share a file using Adobe Document Cloud , or post them to a file sharing service that doesn't require user log on to access.  Post the link to the uploaded files in your reply.

Thank you.

--

Maria

[fernandom2258471]

the mms.cfg is the file modified b the installer

the myfile-mms.cfg is my mms with all the config I need

https://files.acrobat.com/a/preview/6229a9e7-cfe3-4ea8-892e-24f6b4351b20

[_maria_]

Thank you for providing the files.  We'll investigate further.

[fernandom2258471]

Maria,

While you're investigating this issue,

Do you have any info why users are receiving a popup to update Flash even when the SilentAutoUpdateEnable=1 ?

Thanks !!

[_maria_]

Hi,

I am unable to reproduce the behaviour using your mms.cfg file (the one named myfile-mms.cfg).  Th file you provided appears to be saved in UTF8 format, which was not impacted by the bug I mentioned previously.

Reviewing your installation log files, I noticed the most recent upgrades were in the order:  28.0.0.163 (installed using the msi installer), background update to 29.0.0.113, background update to 29.0.0.140.  Based on this, I

• posted 29.0.0.113 Background Update installer to my test server
• installed 28.0.0.161 NPAPI using the MSI
• posted your mms.cfg file (modifying it to use my test server) to the client machine
• triggered the Background Update
  • the system was updated to 29.0.0.113.  The mms.cfg file was not replaced.
• triggered the Background Update again
  • the system was updated to 29.0.0.140.  Again, the mms.cfg file was not replaced.

I did notice that you are using a very old (2 years old) Flash Player uninstaller to uninstall Flash Player.  Since this file is 2 years old it doesn't include the MSI GUIDs for any subsequent release and will not remove some Flash Player related registry entries.  It's recommended to always use the latest Flash Player uninstaller, posted at Uninstall Flash Player for Windows

Do you have any info why users are receiving a popup to update Flash even when the SilentAutoUpdateEnable=1

A system configured for Background Update may still receive update notifications.  Systems configured for Background Updates are also configured for Notification Updates.  Since Background Updates checks for an update every day, and Notification Updates checks for a system once per 7 days, the system is usually updated via Background Updates.  However, a system will revert to Notification Updates after 7 failed attempts to install via Background Updates.  This is a fail-over state to prevent the system from never updating.  This only happens if a system is using the Adobe servers for Background Updates.  Systems configured to use local Background Update server will not be notified (via Update Notification dialog window) an update is available.

--

Maria

[fernandom2258471]

Hello Maria,

I am not sure how to fix the mms.cfg issue on my side . It also happens when I install Flash 29.0.0.140 using msi and then upgrades to 29.0.0.171 via auto update server.

About the system notification/popup:

Do you know what is the executable file that makes this check ?

Maybe :FlashUtil32*Plugin.exe ?

I was just wondering about blocking its execution via another system, will this action interfere on the Auto Update ?

[_maria_]

I am not sure how to fix the mms.cfg issue on my side . It also happens when I install Flash 29.0.0.140 using msi and then upgrades to 29.0.0.171 via auto update server.

The bug I mentioned is only in 29.0.0.113, where the NPAPI Notifier Task was not honoring the mms.cfg file entries if the file was saved in UTF-8 w/BOM.  It was fixed in 29.0.0.140, therefore, if 29.0.0.140 is installed, the behavior you describe shouldn't be happening.  The file you provided is saved in not UTF-8 w/BOM.  You can also save the file in ANSI format, which was not impacted by the bug.

I tested using your mms.cfg file again and I'm still unable to reproduce the behaviour.

For the NPAPI & PPAPI plugin, the Notifier Task makes the update check.  If an update is found, a RunOnce registry entry (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce > FlashPlayerUpdate) is created with the process that launches the Update Notification dialog window upon system login.  For the NPAPI plugin, it is:

• 32-bit OS: C:\Windows\System32\Macromed\Flash\FlashUtil32*Plugin.exe
• 64-bit OS: C:\Windows\SysWOW64\Macromed\Flash\FlashUtil32*Plugin.exe

When the Update Notification dialog window displays, what is the FlashUtil process name that is running?

On a system that the had the Update Notification dialog display, please do the following:

* Open registry editor

* navigate to HKEY_CURRENT_USER\Software\Macromedia\FlashPlayerUpdate

* look for the proc entry

* What is the data value listed (this will be the process that launched the Update Notification dialog window)

What are the client operating systems?  I've been testing on Windows 7 64-bit, but if you're using a different OS, I'll test on that version as well.

[fernandom2258471]

Hello Maria !

Tested several times saving the mms.cfg file using many differents encoding - same results, as soon as the update is applied, the cfg file is replaced by that almost empty one. . This is something hard to figure out the reason. So far, any 29.0.0.x upgrade replaces the mms.cfg, after doing this the auto update is broken as no server info is in place anymore.

I am testing using windows 8.1 64bit and windows 10 64bit.

Is it OK if I block both files from being executed ?

• 32-bit OS: C:\Windows\System32\Macromed\Flash\FlashUtil32*Plugin.exe
• 64-bit OS: C:\Windows\SysWOW64\Macromed\Flash\FlashUtil32*Plugin.exe

I think this is the easiest way of preventing the popup I suppose.

[_maria_]

What directory are you saving the mms.cfg file in?

I had tested on Windows 7 64-bit, but will test on Windows 8.1 64-bit and Windows 10 64-bit

[fernandom2258471]

32-bit OS: C:\Windows\System32\Macromed\Flash\

64-bit OS: C:\Windows\SysWOW64\Macromed\Flash\

[_maria_]

Thank you for confirming.  Those are the correct locations.

What are the file encodings you have tried using?  Did you try ANSI?  If so, did that fail?

Did you try running the latest uninstaller, to completely remove all previous versions and orphaned artifacts (left behind when using the old version uninstaller)?  If not, please try this.

How are you deploying Flash Player? Please provide your exact test steps.  For example:

1. install Flash Player (using msi? exe?)
   1. Are you installing manually, or deploying using a software distribution tool?  If the latter, which one?
2. post mms.cfg file
3. run backgound update
4. etc.

Do you have log files from a different machine you can provide?

[fernandom2258471]

Hello Maria,

Yes, I tried ANSI and also UTF-8 with no BOM.

The install of the package enabling the auto update server (by placing the mms.cfg with all the info needed) was performed via Microsoft SCCM to all the machines, the install is the msi + a mst file. I will post all these files along with the logs.

I've used the with no success. Same results after installing Flash manually using msi.

Uninstall Flash Player for Windows

https://files.acrobat.com/a/preview/5c1019fd-6589-4fa9-974a-9da5a5534d1e

FlashInstall32.log (another machine)

FlashInstall64.log (another machine)

install_flash_player_29_plugin.mst (mst file used during installtion using msi via SCCM)

mms.cfg (original mms file with all my config)

MSIexec - Adobe Flash Player plugin 29.0.0.140.log

afterautoupdate-mms.cfg (file created after auto update to run and install the new version)

[_maria_]

Thank you for the additional information and files.  We will investigate further.  I probably won't have an update until Monday at the earliest, but will keep you posted.

[fernandom2258471]

Thank you very much for all the efforts spent on this case.

Its quite important to me to get it resolved since I have 80.000+ machines using this update method, and it worked smoothly !

You have a very good weekend !

[_maria_]

Hi fernandom2258471 ,

Thank you for providing the additional log files and .mst file.  Having the .mst file was instrumental in researching the issue.

When reviewing the .mst file we noticed a few issues with it.

The mms.cfg file is being included as a component of the MSI installer.  This results in the mms.cfg file being removed when the MSI is uninstalled.  You can verify this by running the MSI file with your transform applied.  Verifying the mms.cfg file was deployed, and then uninstalling.  You'll see the mms.cfg file is also removed.  Repeating this using the MSI installer without applying the transform file results in the mms.cfg file not being removed when Flash Player is uninstalled.

Every Flash Player installer (MSI, EXE, Background Update, etc) first performs a check to determine if Flash Player already exists on the system and if it does the installed version is removed before installation proceeds.  If the installed Flash Player was installed using the MSI installer, then msiexec is used to uninstall, which removes all components installed by the given MSI installer.  In your case, since you're including the mms.cfg file as a componenet of the MSI installer, when the Background Update runs and the MSI is removed, it's also removing the mms.cfg file that was included as a componenet of the MSI installer.

On a 32-bit OS, the mms.cfg file is saved at C:\Windows\System32\Macromed\Flash.  On a 64-bit OS, the mms.cfg file is saved only at C:\Windows\SysWOW64\Macromed\Flash.  These are were Flash Player looks for the mms.cfg file in the different system architectures.  Using your .mst file, on a 64-bit OS, the mms.cfg file is being deployed to C:\Windows\System32\Macromed\Flash AND C:\Windows\SysWOW64\Macromed\Flash.  While this doesn't cause an issue per se, having the file in the System32 directory on 64-bit is useless as Flash Player doesn't read the file from this location, but it can lead to confusion when troubleshooting issues.  We recommend deploying the file to the single location Flash Player expects it to be at.

We recommend removing the mms.cfg file deployment from the mst so that it's not included as a component of the MSI that is then uninstalled when the MSI is removed.  Doing this should resolve the behavior your observing.

--

Maria

[fernandom2258471]

Hello Maria !

You're correct about mms.cfg.

As soon as I install without the mst or with the file being removed from mst the mms.cfg is not replaced by auto update.

Very good ! This part is done !

Only need to figure out the last part:

The popup users received when the Notifier task schedule runs.

I tried to block both

• 32-bit OS: C:\Windows\System32\Macromed\Flash\FlashUtil32*Plugin.exe
• 64-bit OS: C:\Windows\SysWOW64\Macromed\Flash\FlashUtil32*Plugin.exe

However, if this file is blocked, a machine that ran the auto update successfully cannot install the next version:

E.g.: If a machine has 29.0.0.113 then is auto updated to 29.0.0.140 cannot receive the 29.0.0.171

I believe the auto update uninstalls using the blocked executable. Is that correct ?

Do you know a way to suppress the popup without having this file blocked ?

Thanks !

[_maria_]

The file you are proposing to block (FlashUtil32*.exe) is used in the Notification Updates workflow, it's not used in Background Updates, which is what you are implementing to update the client systems, therefore, the clients should update from 29.0.0.140 to 29.0.0.171 via Background Updates, not Notification Updates.

If you have a properly formatted mms.cfg file, and you remove it from the mst file, so that it's not being deployed as a component of the MSI installer, you shouldn't have to block any files.  The Notification Update workflow is essentially blocked when using internal server for Background Updates, which is what you're implementing.  The behaviour you were observing is due to the improper deployment of the mms.cfg file as a component of the MSI file.

[fernandom2258471]

Hello Maria !

I am testing the behavior of background updates having our antivirus system blocking the flashutil32*.exe as mentioned before.

No update is performed if the file is blocked from execution...

Another behavior I noticed: not possible to uninstall it via Control Panel - access denied even with full admin rights.

The uninstall utilizes this executable to perform the action, perhaps the background update has the same process when uninstalling/installing the new version, therefore not able to uninstall due to the file block.

[_maria_]

Ah, yes. Sorry.  The FlashUtil file is used for several tasks, including uninstalling.  I apologize, I forgot about that.