Internal Adobe Flash Player Update Server

Prehistory

The authorities have set the task: you need to keep the Flash Player up to date. Scales: ~ 15,000 computers, half of which need FP.

It would seem, what the problem is - we make the domain policy, we push the MSI package and we are happy ... But it was not there! The structure of the company is highly distributed, i.e. to remote points with a channel of ~ 1 Mbps for 20 computers, the politicians even push through 15mb already a problem - in the morning the employees turn on the computer and wait half an hour for the download, until everything is downloaded and installed (or just fall off by timeout). Not to mention the fact that computers in such offices have the unpleasant property of periodically falling out of the domain.

It was necessary to have another solution that would work regardless of the politician, not to strain the user, to use the channel as little as possible (at least so that not everyone downloaded simultaneously). Options for scripts for obvious reasons, too, did not fit.
')
Gained, as usual, Google: it turned out that you can raise the internal update server and configure the built-in FP update tool on it. In this case, clients will only need to distribute the settings file. Details under the cut.

Configuring the update server

1. Get the license agreement

Adobe requires a license agreement to distribute its software. We will not violate the terms of use and get a license (good, it's not difficult at all): FlashPlayer: Adobe Runtimes / Reader Distribution License Agreement . The license will be valid for a year. Upon expiration, you can send the request again.

2. Raise the web server

The platform does not play a role, in my case it spins the N-th site on IIS under Win2012. It practically does not eat resources even though ~ 3000 computers are already configured on this server.

Server Settings:

• Access by ports 80, 443 (http, https respectively).
  The first one is needed, in fact, for downloading, the second FP will go for the XML version of the current version.
• Valid certificate https.
  I wrote out a certificate based on the root corporate, which by default is on all machines.
• Directory listing.
  I did not check the work without it - they ask in the documentation, I decided to do it as written.

I will not dwell on setting up the server.

For clarity, let's call the server FlashPlayerUpdate.domain.local .

3. Download resources and upload to server.

At the root of the web server we create a directory tree: /pub/flashplayer/update/current/sau/ .

Directory tree on my server:



If you have requested a license in the first step, then the reply should receive a letter with a link from where to download FlashPlayer - we follow this link. If it didn’t come, or didn’t request it, then go here: https://www.adobe.com/products/flashplayer/distribution3.html and download the archive using the link “ Download Background Update Resources ”:




Unzip the downloaded archive to the /pub/flashplayer/update/current/sau/ folder on the server.

4. Distribute the configuration file to customers

Depending on the capacity of the system:

• 32-bit: C: \ Windows \ System32 \ Macromed \ Flash \ mms.cfg
• 64-bit: C: \ Windows \ SysWOW64 \ Macromed \ Flash \ mms.cfg

You can distribute it by any means. I used a combination of domain policy and antivirus administration server (for computers that flew out of the domain).

We include silent autoupdate in the file, set the update interval (in days), the path to our server, and just in case logging, so that it is easier to diagnose problems if they arise:

 AutoUpdateDisable=0 SilentAutoUpdateEnable=1 AutoUpdateInterval=2 SilentAutoUpdateServerDomain=FlashPlayerUpdate.domain.local SilentAutoUpdateVerboseLogging=1 

If everything was done correctly, then Flash Player on client machines should start updating according to the schedule (according to the above file above - once every 2 days). Typically, the Adobe update service runs once an hour to check the update conditions — at this time, Updater should see the configuration file, reconfigure updates according to the settings specified, and go to the new server to check the version.

That is, about an hour after the distribution of the configuration file, you can watch the logs on the server for version checking requests.

Automation

As a classic representative of the IT fraternity, I can not stand the routine manual work and just could not help automate the process of checking and pumping out a new version. However, as noted above, until I found a way to download the ESR versions from the Macromedia site, the script only checks for updates. Suggestions are welcome.

Script to automatically download updates

Only for the public version!

The logic of work: the script downloads the update files directly from Macromedia for versions 11,15,16,17,18,19 (if some version has already been removed from the site - the script just swears that it could not download and skip) and puts it from by replacing the update server. No version checks. At the testing stage, I used this script: I started it through the server on the server at night.

If you wish, you can cross this script and the next one and get full automation with version checking, alerts and downloading only with updates.

Script Parameters:

• * FPRoot - path to the root folder of the update server. Local, or network. Naturally, the user from whom the script will be launched must have write access to this folder.
• FPDownloadRoot - the path to the Macromedia site. It is set by default, but can be changed if necessary.
• DownloadProxy - proxy server, if used in the company. Fully write: http: // proxy.domain.local.
• ProxyCreds - username for proxy authorization.
• UserAgent - to change the user agent with whom PowerShell will download. For example, we have a restriction on UserAgents on a proxy, I go with an Internet Explorer agent.
• Force — disable Invoke-Webrequest cmdlet certificate verification (more precisely, make all certificates trust).

* - required parameter

Usage example:

 powershell.exe -command "& '.\FPUpdater.ps1' -FPRoot '\\FlashPlayerUpdate\pub\flashplayer\update\current\sau' -DownloadProxy 'http://proxy.domain.local' -ProxyCreds 'DOMAIN\UserName' -UserAgent 'Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko'" 

All parameters can be hard-coded into the script if long startup lines are frightened.

Script to check for updates and e-mail alerts

Updates are checked for the standard version, but since they are updated at the same time (no one has canceled the security fixes), it will also be available for ESR. For the script to work, you need to create the CurrentPublic file in the root of the web server (next to the pub folder), in which you CurrentPublic enter the current public version for ActiveX (the ActiveX version is used for testing).

Work logic: the script compares the version obtained from the CurrentPublic file from your server with the version on the Macromedia server. The version on the server is based on the auto-update logic: first, it looks in XML for the current major build, goes to the major folder, and it looks for the full build.

Script Parameters:

• * FPIntServerRoot - The address of our server. For example: FlashPlayerUpdate.domain.local
• FPDownloadRoot - the path on the macromedia site. It is set by default, but can be changed if necessary.
• ESR - check the ESR version (without this flag, it will check the public one).
• DownloadProxy - proxy server, if used in the company. Fully write: http: // proxy.domain.local.
• ProxyCreds - username for proxy authorization.
• UserAgent - to change the user agent with whom PowerShell will download. For example, we have a restriction on UserAgents on a proxy, I go with an Internet Explorer agent.
• Force — disable Invoke-Webrequest cmdlet certificate verification (more precisely, make all certificates trust).
• * MailTo - e-mail addresses to which notifications will be sent.
• * MailFrom - from whom notifications will come. For example: FPUpdater@company.com
• SmtpServer - smtp-server through which the message will be sent.

* - required parameter

Usage example:

 .\FPCheckUpdate.ps1 -FPIntServerRoot 'fp-update.domain.local' -ESR -Proxy 'http://proxy.domain.local' -UserAgent InternetExplorer -Force -MailTo 'admin@company.com','support@company.com' -MailFrom 'FP@company.com' -SmtpServer 'smtp.company.com' 

Resources used

• Adobe Flash 11.2 Background Updates from an Internal Server
• Adobe Flash Player Administration Guide

UPD

Slightly late update from 06/17/16.

Since writing this article, Adobe managed to change the order of access to the FlashPlayer download page 2 times. As a result, now to get access to the page for download, you must first log in to your Adobe ID. Those. the option of parsing the page for the ESR version no longer rolls.

Fooling around with authorization, getting-sending a cookie via PowerShell has not yet become. As a result, I redid the script to check the ESR on the distribution3 page, which can disappear at any time. While so, then we will see.

At the beginning of the year I asked a question on the Adobe forum on the subject of checking for ESR version updates. They promise to come up with something, but for now, it's still there.

UPD2

The other day on the Flash Player distribution page (the link to which you received after receiving a license to distribute) the following information appeared:

ATTENTION! Important changes from Extended Support Release

Initially, the Extended Support Release was created with the goal of minimizing the time that IT administrators spend on certifying each new release. Flash Player: Extended Support Release limited the changes to the release to security changes and fixes for critical functional issues. At that time, there were far more functional changes in each release of Flash Player than changes in the security system. However, now the situation has changed: the number of proactive and security response measures far exceeds functional changes. In practice, Extended Support Release no longer protects IT organizations from the huge number of changes made to the standard Flash Player releases, but only reduces functional risks. In this regard, it was decided to discontinue the Extended Support Release and concentrate on developing only standard releases. Focusing only on standard editions will allow us to be more flexible in adopting security response measures and continue to work on testing and new technical solutions in the field of security.

To give organizations enough time for testing and certification, Extended Support Release will continue to be supported until October 11, 2016 . Organizations will then need to upgrade to the standard release.