Adobe Flash Player内部更新サーバー

背景

当局はタスクを設定します。FlashPlayerは最新の状態に保つ必要があります。 スケール：〜15000台のコンピューター。その半分は本当に必要です。

問題は次のように思われます-ドメインポリシーを作成し、MSIパッケージをプッシュし、喜んでいます...しかし、そこにありました！ 会社の構造は高度に分散されています。 政治家を20 MBの〜1メガビットのチャネルで15 MBまでリモートポイントにプッシュすることはすでに問題です-朝、従業員はコンピューターの電源を入れ、すべてがダウンロードされて配信されるまで（またはタイムアウトが発生するまで）30分ダウンロードを待ちます。 このようなオフィスのコンピューターには、定期的にドメインから脱落する不快な能力があるという事実は言うまでもありません。

ポリシーに関係なく機能し、ユーザーに負担をかけず、チャネルの使用を最小限に抑える（少なくとも全員が同時にダウンロードするわけではない）別のソリューションが必要でした。 明らかな理由でスクリプトを使用したバリアントも適合しませんでした。

Googleはいつものように助けてくれました。内部更新サーバーを上げて、その上に組み込みのFP更新ツールを構成できることがわかりました。 この場合、顧客は設定ファイルを配布するだけで済みます。 カットの下の詳細。

更新サーバーを構成する

1. ライセンス契約を取得します

アドビは、ソフトウェアを配布するためにライセンス契約を必要とします。 利用規約に違反せず、ライセンスを取得します（ 残念ながら 、これはまったく難しいことではありません）： FlashPlayer：Adobe Runtimes / Reader Distribution License Agreement 。 ライセンスは1年間発行されます。 有効期限が切れたら、リクエストを再度送信できます。

2. Webサーバーを上げる

プラットフォームは役割を果たしません。私の場合、Win2012の下でIISのN番目のサイトをオンにします。 このサーバー上で〜3000台のコンピューターが既に構成されていても、実際にはリソースを消費しません。

サーバー設定：

• ポート80、443でのアクセス（それぞれ、http、https）。
  実際には、最初の1つがダウンロードに必要であり、2番目のFPは現在のバージョンのXMLバージョンを使用します。
• 有効なhttps証明書。
  ルートの企業証明書に基づいて証明書を作成しました。これはデフォルトですべてのマシンにあります。
• ディレクトリ一覧。
  私はそれなしで仕事をチェックしませんでした-彼らはドキュメントで尋ねます、私はそれが書かれているのでそれをすることにしました。

サーバーの構成については説明しません。

明確にするために、サーバーFlashPlayerUpdate.domain.localを呼び出します。

3. リソースをダウンロードしてサーバーにアップロードする

Webサーバーのルートで、ディレクトリツリーを作成します： /pub/flashplayer/update/current/sau/ 。

サーバー上のディレクトリツリー：



最初のステップでライセンスをリクエストした場合、FlashPlayerをダウンロードするためのリンクが記載されたメールが返ってきます。このリンクをクリックしてください。 受け取っていない場合やリクエストしていない場合は、 https ： //www.adobe.com/products/flashplayer/distribution3.htmlにアクセスし、「 バックグラウンド更新リソースのダウンロード 」リンクを使用してアーカイブをダウンロードします。




ダウンロードしたアーカイブをサーバーの/pub/flashplayer/update/current/sau/フォルダーに/pub/flashplayer/update/current/sau/します。

4. 構成ファイルをクライアントに配布する

システムの容量に応じて：

• 32ビット：C：\ Windows \ System32 \ Macromed \ Flash \ mms.cfg
• 64ビット：C：\ Windows \ SysWOW64 \ Macromed \ Flash \ mms.cfg

どんな方法でも配布できます。 ドメインポリシーとウイルス対策管理サーバーの組み合わせを使用しました（ドメインから飛んだコンピューター用）。

ファイルで、サイレント自動更新をオンにし、更新間隔（日数）、サーバーへのパス、および念のためにログを指定します。これにより、問題が発生した場合に診断しやすくなります。

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

すべてが正しく行われた場合、クライアントマシン上のFlash Playerは、スケジュールに従って更新を開始する必要があります（上記のファイルによると、2日ごとに1回）。 通常、アドビの更新サービスは1時間に1回起動して更新条件を確認します。この時点で、アップデーターは設定ファイルを確認し、規定の設定に従って更新を再設定し、新しいサーバーに移動してバージョンを確認します。

つまり、構成ファイルが配布されてから約1時間後に、サーバー上のログでバージョンを確認する要求を確認できます。

自動化

IT兄弟の代表として、私は日常の手作業に耐えられず、新しいバージョンの確認とダウンロードのプロセスを自動化することしかできませんでした。 ただし、上記のように、Macromedia WebサイトからESRバージョンをダウンロードする方法を見つけるまで、スクリプトの更新のみをチェックします。 提案を歓迎します。

更新を自動的にダウンロードするスクリプト

パブリックバージョンのみ！

動作のロジック：スクリプトは、アップデートファイルをMacromediaからバージョン11,15,16,17,18,19に愚かな方法で直接ダウンロードします（一部のバージョンが既にサイトから削除されている場合、スクリプトは単にダウンロードできずスキップすることを誓います）更新サーバー上の置換。 バージョンチェックなし。 テスト段階では、このスクリプトを使用しました。夜間にサーバー上のシェダーを介して実行しました。

必要に応じて、このスクリプトと次のスクリプトをクロスさせ、バージョンチェック、アラート、および更新がある場合にのみダウンロードすることで完全な自動化を実現できます。

スクリプトパラメータ：

• * FPRoot-更新サーバーのルートフォルダーへのパス。 ローカルまたはネットワーク。 当然、スクリプトを起動するユーザーには、このフォルダーへの書き込み権限が必要です。
• FPDownloadRootは、Macromedia Webサイトのパスです。 デフォルトで設定されていますが、必要に応じて変更できます。
• DownloadProxy-プロキシサーバー（会社が使用している場合）。 完全に書き込むには： http：// proxy.domain.local。
• ProxyCreds-プロキシ認証のユーザー名。
• UserAgent -PowerShellがダウンロードするユーザーエージェントを変更します。 たとえば、UserAgentにプロキシ制限があるため、Internet Explorerエージェントを使用します。
• 強制 -Invoke-Webrequestコマンドレットの証明書検証を無効にします（より正確には、すべての証明書を信頼します）。

*-必須パラメーター

使用例：

 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'" 

長い起動ラインが怖い場合は、すべてのパラメーターをスクリプトにハードコーディングできます。

更新および電子メールアラートを確認するスクリプト

更新の確認は標準バージョンに従って実行されますが、同時に更新されるため（セキュリティ修正をキャンセルした人はいません）、ESRでも機能します。 スクリプトを機能させるには、Webサーバーのルート（ pubフォルダーの隣）にCurrentPublicファイルを作成する必要があります。このファイルに、 ActiveXの現在のパブリックバージョンを入力します （検証にはActiveXのバージョンが使用されます）。

作業ロジック：スクリプトは、サーバーからCurrentPublicファイルから受け取ったバージョンとMacromediaサーバー上のバージョンを比較します。 自動更新ロジックに従ってサーバーのバージョンを確認します。最初にXMLで現在のメジャービルドを検索し、メジャービルドのフォルダーに移動して、そこで完全なビルドを確認します。

スクリプトパラメータ：

• * FPIntServerRoot-サーバーのアドレス。 例： FlashPlayerUpdate.domain.local
• FPDownloadRoot-マクロメディアWebサイトのパス。 デフォルトで設定されていますが、必要に応じて変更できます。
• ESR -ESRバージョンを確認します（このフラグがなければ、パブリックを確認します）。
• DownloadProxy-プロキシサーバー（会社が使用している場合）。 完全に書き込むには： http：// proxy.domain.local。
• ProxyCreds-プロキシ認証のユーザー名。
• UserAgent -PowerShellがダウンロードするユーザーエージェントを変更します。 たとえば、UserAgentにプロキシ制限があるため、Internet Explorerエージェントを使用します。
• 強制 -Invoke-Webrequestコマンドレットの証明書検証を無効にします（より正確には、すべての証明書を信頼します）。
• * MailTo-通知の送信先の電子メールアドレス。
• * MailFrom-通知の送信元 。 例： FPUpdater@company.com
• SmtpServer-メッセージの送信に使用されるsmtp-server。

*-必須パラメーター

使用例：

 .\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' 

使用したリソース

• 内部サーバーからのAdobe Flash 11.2バックグラウンド更新
• Adobe Flash Player管理ガイド

UPD

2016年6月17日のわずかに遅い更新。

この記事の執筆以来、AdobeはFlashPlayerダウンロードページへのアクセス順序を2回変更することに成功しました。 そのため、ダウンロード用のページにアクセスするには、まずAdobe IDにログインする必要があります。 つまり ESRバージョンのページを解析するオプションはロールバックしなくなりました。

PowerShellを介した認証、Cookieの送受信にだまされてはいません。 その結果、 Distribution3ページでESRをチェックするスクリプトを再作成しました。このページはいつでも消えます。 これまでのところ、さらに詳しく見ていきます。

年の初めに、アドビのフォーラムで、ESRバージョンの更新を確認するトピックについて質問しました 。 彼らは何かを思いつくと約束しますが、今のところ物事はまだあります。

UPD2

先日、次の情報がFlash Player配信ページ（配信ライセンスを受け取ったときに受け取ったリンク）に表示されました。

注意！ 延長サポートリリースでの重要な変更

当初、延長サポートリリースは、IT管理者が新しいFlash Playerの各リリースの認定に費やす時間を最小限に抑えるように設計されていました。延長サポートリリースは、リリースに対する変更をセキュリティシステムの変更に限定し、重大な機能上の問題を修正しました。 当時、Flash Playerの各リリースには、セキュリティの変更よりもはるかに多くの機能的な変更がありました。 ただし、状況は変化しています。予防的および対応的なセキュリティ対策の数は、機能の変更をはるかに超えています。 実際には、Extended Support Releaseは、標準のFlash Playerリリースに加えられた膨大な数の変更からIT組織を保護しなくなりましたが、機能上のリスクを減らすだけです。 この点で、延長サポートリリースを中止し、標準リリースのみの開発に集中することが決定されました。 標準リリースのみに焦点を当てることで、セキュリティの対応をより柔軟に行うことができ、セキュリティの分野でのテストと新しい技術ソリューションに引き続き取り組みます。

組織にテストと認定のための十分な時間を提供するために、延長サポートリリースのサポートとアップグレードは2016年10月11日まで続きます。 その後、組織は標準エディションに切り替える必要があります。