We are setting to receive flash background updates from an internal server for our 1200+ enterprise pcs.
We created the server with the open port 443 for HTTPS requests and a SSL certificate for HTTPS access on port 443. However, we are not seeing in the Flash 26 admin guide instructions on creating an application or service that calls out and stores the updates. We only see the mms.cfg file change (which is not enough).
What are we supposed to install on the server that looks for the updates and downloads the files? Do we need to create an IIS server?
Please follow the instructions mentioned on page 21 to configure the server mentioned in the Admin guide.
To confirm, we have to install the IIS role on the windows server, correct? If so I am not seeing that as a prereq on page 21.
There is no such requirement that it should be an IIS server. You could even use Apache server for the same.
I followed the instructions on page 21.
Port 80/443 is allowed.
We can store files.
Downloaded the Background update resource
Exported to the assigned directories after creation.
I installed 18.104.22.168 on the test workstations
set the Mms.cfg to point to the server.
Kicked off the task schedule on the local workstaiton to start the update process.
Do you have activated verboselogging at mms.cfg?
If not, please add the following Line to mms.cfg:
(0 = false, 1 = true)
Could you post the content of the Log?
The Log-Files are located at:
Before updating again about the FlashPlayerUpdateService.exe you should delete the Registry Entry:
I have an identical Issue, but from Adobe i get no Details about the Error Codes:
2017-8-29+13-38-45.795 [info] 1629 server.company.local:8084
2017-8-29+13-38-45.795 [info] 1614
2017-8-29+13-38-45.811 [info] 1615
2017-8-29+13-38-45.811 [info] 1618
2017-8-29+13-38-45.827 [info] 1619 1063
2017-8-29+13-38-45.857 [info] 1629 server.company.local:8084
2017-8-29+13-38-45.857 [info] 1614
2017-8-29+13-38-45.872 [info] 1615
2017-8-29+13-38-45.872 [info] 1618
2017-8-29+13-38-45.890 [info] 1604
2017-8-29+13-38-45.890 [info] 1608
2017-8-29+13-38-45.905 [info] 1631 /pub/flashplayer/update/current/sau/currentmajor.xml
2017-8-29+13-38-45.905 [warning] 1468 183
2017-8-29+13-38-45.921 [warning] 1469 183
2017-8-29+13-38-45.921 [warning] 1470 183
2017-8-29+13-38-45.936 [warning] 1474 183
2017-8-29+13-38-45.936 [warning] 1475
2017-8-29+13-38-45.952 [info] 1432
2017-8-29+13-38-45.952 [info] 1612
2017-8-29+13-38-45.968 [info] 1620
2017-8-31+17-16-1.172 [info] 1614
2017-8-31+17-16-1.204 [info] 1615
2017-8-31+17-16-1.219 [info] 1618
2017-8-31+17-16-1.235 [info] 1604
2017-8-31+17-16-1.235 [info] 1608
2017-8-31+17-16-1.250 [info] 1612
2017-8-31+17-16-1.266 [info] 1620
2017-8-31+18-16-0.85 [info] 1629 servername.domain.com
2017-8-31+18-16-0.101 [info] 1614
2017-8-31+18-16-0.132 [info] 1615
2017-8-31+18-16-0.148 [info] 1618
2017-8-31+18-16-0.163 [info] 1619 1063
2017-8-31+18-16-0.210 [info] 1629 servername.domain.com
2017-8-31+18-16-0.226 [info] 1614
2017-8-31+18-16-0.242 [info] 1615
2017-8-31+18-16-0.273 [info] 1618
2017-8-31+18-16-0.288 [info] 1608
2017-8-31+18-16-0.288 [info] 1604
2017-8-31+18-16-0.304 [info] 1612
2017-8-31+18-16-0.320 [info] 1620
2017-8-31+19-16-0.76 [info] 1629 servername.domain.com
2017-8-31+19-16-0.92 [info] 1614
2017-8-31+19-16-0.107 [info] 1615
2017-8-31+19-16-0.138 [info] 1618
2017-8-31+19-16-0.138 [info] 1619 1063
2017-8-31+19-16-0.201 [info] 1629 servername.domain.com
2017-8-31+19-16-0.217 [info] 1614
2017-8-31+19-16-0.232 [info] 1615
2017-8-31+19-16-0.248 [info] 1618
2017-8-31+19-16-0.263 [info] 1604
2017-8-31+19-16-0.263 [info] 1608
2017-8-31+19-16-0.279 [info] 1612
2017-8-31+19-16-0.295 [info] 1620
Anything on this?
I am not seeing any errors in the log file excerpt you posted. Please do the following:
It's a 64-bit system. But I took all of the install logs and uploaded for you to review. I'm seeing errors now.
I get the normal IIS message at the following
https://server.domain.com/pub/ (403 access denied)
Can we set up a call for tomorrow say 9am pst?
If the files are posted, but you're getting error 404 then your server is not configured correctly and you'll need to troubleshoot why. I found the following article on support.microsoft.com which may be of assistance https://support.microsoft.com/en-us/help/248033/how-system-administrators-can-troubleshoot-an-http-4...
In this case on IIS within Windows 2016, the site binding for https needed to be listing the hostname, port 443, and asterisk (*) for the IP.
Next on the pub, install, and xml virtual directories, they need to be coverted into an application.
All directories will if viewed through a browser will return a 400 type error because there is not landing page. I tested by placing a test.aspx within each directory to confirm it is accessible from a browser. They were accessible.
Running the task schedule originally did not work. I had to then delete the reg key LastUpdateCheck again on the local workstation, reran the task schedule and it worked.
Maria, Do you have instructions for automatically downloading the background update resources automatically, and distributing them automatically to the premade directories on the IIS server to make this a truly seamless process?
To add: The NPAPI does not immediately come down. There either is a delay, or you have to rerun the task schedule a second time. Maria, Is this normal behavior?
We appreciate your timely response.
We have reports that the NPAPI is not responding to the upgrade request at all, while the active x resolves without issue after removing the LastUpdateCheck key. There were hourly automated requests from the updater since the Active x came down yesterday afternoon. Let it go through the night, return in the morning. Still no NPAPI.
This begs two questions:
Why do we even have to go into the registry to "fix" the updater of the program?
Under normal operation you don't. This is for testing purposes only to force the update (and isn't always required)
The NPAPI does not immediately come down. There either is a delay, or you have to rerun the task schedule a second time. Maria, Is this normal behavior?
This is normal behaviour. When Background Updates executes it updates the Player types in the following order, one at a time:
If ActiveX and NPAPI are both installed, the first time Background Updates runs it'll update ActiveX. The next time it runs (in 1 hour), it'll update NPAPI. If PPAPI is also installed, the next time it runs (in 1 hour), it'll update the PPAPI plugin. If ActiveX is not installed, it skips that and goes to the next installed plugin, in the order above.
In the most resent log file you sent, the NPAPI plugin is not installed. The standalone uninstaller (uninstall_flash_player.exe) was executed, which uninstalls ALL Flash Player types (E.g. ActiveX, NPAPI, PPAPI) installed on the system. Then ActiveX Control 22.214.171.124 was installed using the MSI. Then Background Updates was executed and the ActiveX Control was updated to 126.96.36.199. Since only ActiveX Control is installed and it's the latest version, there is nothing to update to.
No. The steps taken were as follows.
Uninstall ActiveX/NPAPI 151 manually. However ActiveX had errors uninstalling.
I used the uninstall tool.
I was then able to install 131 both activex/npapi.
I then ran the updater from task schedule
I deleted the reg key.
It brought down activex, not npapi.
I then had it sit overnight.
No Npapi in the morning.
I was then able to install 131 both activex/npapi.
Looking at the FlashInstall32 (1).log file from the bottom:
0002 00000010 "\\phxutil\sources\Adobe\Flash\UninstallTool\uninstall_flash_player.exe" -force This removes all Flash Player instances from the system.
I'm not concerned with entries prior to line 21924 because whatever was installed prior to line 21924 was uninstalled when the standalone uninstaller was executed, which uninstalled ALL Flash Player types (ActiveX and NPAPI) that were installed on the system.
9/11/17 - afternoon
When Background Updates executes it updates the Player types in the following order, one at a time:
Summary: Will not update without deleting the LastUpdateCheck reg key. Why?
We're investigating this further. I most likely won't have an update until tomorrow.
Also, there's a new version of Flash Player, 188.8.131.52, released earlier today.
Unfortunately, I am not able to reproduce the behaviour you are observing. Both the ActiveX Control and NPAPI plugin are being updated as expected.
I did notice you have a typo in the mms.cfg file, but it doesn’t impact Background Update behaiour. You have SAutoUpdateDisable=0. This should be AutoUpdateDisable=0 (no S).
I performed the following:
This is the behavior you should be observing in your system. Please follow the above steps, exactly as I have, but fix the typo in the AutoUpdateDIsable=1 entry in the mms.cfg file (again, this typo has no impact on the functionality, but you should correct it). I expect the results to be the same. If not, provide new FlashInstall log files.