1. Передісторія Начальство поставило задачу: потрібно підтримувати в актуальному стані Flash Player....
2. Автоматизація
3. Скрипт для автоматичного скачування оновлень
4. Скрипт для перевірки оновлення та оповіщення по e-mail
5. використані ресурси
6. UPD2
7. УВАГА! Важливі зміни з Extended Support Release

Передісторія

Начальство поставило задачу: потрібно підтримувати в актуальному стані Flash Player. Масштаби: ~ 15000 комп'ютерів, на половині з яких FP дійсно потрібен.
Здавалося б, у чому проблема - робимо доменну політику, запихає MSI пакет і радіємо ... Але не тут-то було! Структура компанії сильно розподілена, тобто в віддалені точки з каналом ~ 1 Мбіт на 20 компів пропхати політиками навіть 15Мб вже проблема - вранці співробітники включають комп'ютер і по півгодини чекають завантаження, поки все скочується і поставиться (або просто відвалиться з таймаут). Не кажучи вже про те, що комп'ютери в подібних офісах мають неприємну властивість періодично з домену випадати.
Потрібно було інше рішення, яке буде працювати незалежно від політик, ніяк не напружувати користувача, мінімально використовувати канал (хоча б щоб качали в повному обсязі одночасно). Варіанти з скриптами з очевидних причин теж не підійшли.
Виручив, як зазвичай, Гугл: виявилося, що можна підняти внутрішній сервер оновлення та налаштувати на нього вбудоване засіб поновлення FP. При цьому на клієнти потрібно буде тільки розповсюдити файл настройок. Подробиці під катом.

Налаштування сервера оновлень

1. Отримуємо ліцензійну угоду
Для поширення свого ПО Adobe вимагає отримати ліцензійну угоду. Не будемо порушувати умови використання і отримаємо ліцензію (благо, це зовсім не складно): FlashPlayer: Adobe Runtimes / Reader Distribution License Agreement . Ліцензія видається строком на рік. Після закінчення можна відправити запит ще раз.
2. Піднімаємо веб-сервер
Платформа ролі не грає, в моєму випадку крутиться N-ним сайтом на IIS під Win2012. Ресурсів воно практично не жере навіть при тому, що вже ~ 3000 комп'ютерів налаштовані на цей сервер.
Налаштування сервера:

• Доступ по портам 80, 443 (http, https відповідно).
  Перший потрібен, власне, для скачування, по другому FP ходитиме за XML-кою актуальної версії.
• Дійсний сертифікат https.
  Я виписував сертифікат на основі кореневого корпоративного, який за замовчуванням є на всіх машинах.
• Лістинг директорій.
  Чи не перевіряв роботу без нього - в документації просять, я вирішив зробити як написано.

Докладно зупинятися на налаштуванні сервера не буду.
Для наочності назвемо сервер FlashPlayerUpdate.domain.local.
3. Завантажуємо ресурси і викладаємо на сервер
У корені веб-сервера створюємо дерево директорій: / pub / flashplayer / update / current / sau /.
Дерево директорій на моєму сервері:

Якщо ви запросили ліцензію на першому кроці, то у відповідь має прийти лист з посиланням, звідки завантажувати FlashPlayer - проходимо по цій самій посиланням. Якщо не прийшло, або не запитували, то йдемо сюди: https://www.adobe.com/products/flashplayer/distribution3.html і завантажуємо архів за посиланням "Download Background Update Resources":

Extended Support Release або Public Release

Тут потрібно зробити ремарку. На сторінці 2 варіанти завантажень: стандартний (Public) і Extended Support Release. У моєму випадку важлива стабільність роботи і не потрібні нові фічі, тому був обраний варіант ESR. При цьому я додав собі деяку кількість геморою: паблік версію можна безпосередньо викачувати скриптом з сайту Macromedia. Як викачувати ESR, я так і не нагугліть, тому в моєму випадку оновлення контенту на внутрішньому сервері відбувається в ручному режимі.
В кінці статті доклав 2 скрипта PowerShell: для автоматичного оновлення (тільки для стандартної версії; легко портується на bash), для перевірки оновлень і сповіщення по e-mail (для будь-якої версії, в т.ч. ESR).

Скачаний архів розпакувати в папку / pub / flashplayer / update / current / sau / на сервері.
4. Поширюємо на клієнти файл конфігурації
Залежно від розрядності системи:

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

Поширювати можна будь-якими способами. Я використовував поєднання доменної політики і сервера адміністрування антивіруса (для комп'ютерів, які вилетіли з домена).
У файлі включаємо тихе автообновление, прописуємо інтервал оновлень (в днях), шлях до нашого сервера, і на всякий випадок логирование, щоб простіше було діагностувати проблеми, якщо вони виникнуть:
AutoUpdateDisable = 0 SilentAutoUpdateEnable = 1 AutoUpdateInterval = 2 SilentAutoUpdateServerDomain = FlashPlayerUpdate.domain.local SilentAutoUpdateVerboseLogging = 1
Якщо все було зроблено вірно, то Flash Player на клієнтських машинах повинен почати оновлюватися за розкладом (згідно наведеним файлу вище - раз на 2 дні). Зазвичай сервіс поновлення Adobe запускається раз на годину для перевірки умов поновлення - в цей час Updater повинен побачити файл конфігурації, переналаштувати поновлення згідно прописаним налаштувань і сходити на новий сервер перевірити версію.
Тобто приблизно через годину після поширення файлу конфігурації можна дивитися логи на сервері на предмет запитів на перевірку версії.

Автоматизація

Як класичний представник айтішной братства, я терпіти не можу рутинну ручну роботу і просто ну ніяк не міг не автоматизувати процес перевірки та викачування нової версії. Однак, як зазначено вище, поки я не знайшов способу викачувати версії ESR з сайту Macromedia, тому скриптом тільки перевіряю поновлення. Пропозиції вітаються.

Скрипт для автоматичного скачування оновлень

Логіка роботи: скрипт в тупу викачує файли оновлення безпосередньо з Macromedia для версій 11,15,16,17,18,19 (якщо якусь версію вже прибрали з сайту - скрипт просто ругнётся, що не зміг завантажити і пропустить) і кладе з заміною на сервер оновлення. Ніяких перевірок версій. На етапі тестування я використовував цей скрипт: запускав через шедулера на сервері ночами.
При бажанні можна схрестити цей скрипт і наступний і отримати повну автоматизацію з перевіркою версій, оповіщенням і скачуванням тільки при наявності оновлень.
Параметри скрипта:

• * FPRoot - шлях до кореневої папки сервера оновлень. Локальний, або мережевий. Природно, у користувача, від якого буде запущений скрипт, повинні бути права на запис в цю папку.
• FPDownloadRoot - шлях на сайті Macromedia. За умовчанням установлюється, але можна змінити при необхідності.
• DownloadProxy - проксі сервер, якщо використовується в компанії. Писати повністю: http: // proxy.domain.local.
• ProxyCreds - ім'я користувача для авторизації на проксі.
• UserAgent - для зміни юзерагента, з яким PowerShell піде качати. Наприклад, у нас на проксі обмеження по UserAgent-ам, я ходжу з агентом Internet Explorer.
• Force - відключити перевірку сертифікатів командлет 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 ' "
Всі параметри можна захардкодіть в скрипт, якщо лякають довгі рядки запуску.

Скрипт для перевірки оновлення та оповіщення по e-mail

Перевірка оновлень йде по стандартній версії, але оскільки оновлюються вони одночасно (security-фікси ніхто не відміняв), то проектують і для ESR. Для роботи скрипта потрібно створити в корені веб-сервера (поруч з папкою pub) файл CurrentPublic, в який вписати поточну публічну версію для ActiveX (для перевірки використовується саме версія ActiveX).
Логіка роботи: скрипт порівнює версію, отриману з файлу CurrentPublic з вашого сервера з версією на сервері Macromedia. Версію на сервері дивиться за логікою автообновлялкі: спочатку шукає в XML поточний мажорний білд, йде в папку з мажорним і там дивиться повний білд.
Параметри скрипта:

• * FPIntServerRoot - Адреса нашого сервера. Наприклад: FlashPlayerUpdate.domain.local
• FPDownloadRoot - шлях на сайті macromedia. За умовчанням установлюється, але можна змінити при необхідності.
• ESR - перевіряти ESR версію (без цього прапора перевірятиме публічну).
• DownloadProxy - проксі сервер, якщо використовується в компанії. Писати повністю: http: // proxy.domain.local.
• ProxyCreds - ім'я користувача для авторизації на проксі.
• UserAgent - для зміни юзерагента, з яким PowerShell піде качати. Наприклад, у нас на проксі обмеження по UserAgent-ам, я ходжу з агентом Internet Explorer.
• Force - відключити перевірку сертифікатів командлет Invoke-Webrequest (точніше, змусити довіряти всім сертифікатам).
• * MailTo - e-mail адреси, на які будуть приходити повідомлення.
• * MailFrom - від кого будуть приходити повідомлення. Наприклад: [email protected]
• SmtpServer - smtp-сервер, через який буде здійснюватися відправка повідомлення.

* - обов'язковий параметр
Приклад використання:
. \ FPCheckUpdate.ps1 -FPIntServerRoot 'fp-update.domain.local' -ESR -Proxy 'http: //proxy.domain.local' -UserAgent InternetExplorer -Force -MailTo '[email protected]', 'support @ company .com '-MailFrom' [email protected] '-SmtpServer' smtp.company.com '

використані ресурси

UPD

Злегка запізнілий апдейт від 17.06.16.
З моменту написання статті Adobe встигли 2 рази поміняти порядок доступу до сторінки завантаження FlashPlayer'а. В результаті тепер щоб отримати доступ до сторінки для скачування, потрібно спершу авторизуватися в Adobe ID. Тобто варіант з парсинга сторінки на предмет версії ESR більше не прокатує.
Морочитися з авторизацією, отриманням-відправкою cookie через PowerShell поки не став. В результаті переробив скрипт для перевірки ESR на сторінку distribution3 , Яка може пропасти в будь-який момент. Поки так, далі буде видно.
Я ще на початку року ставив питання на форумі Adobe на тему перевірки оновлень версії ESR. Обіцяють щось придумати, але поки віз і нині там.

UPD2

Днями на сторінці поширення Flash Player (посилання на яку ви отримали, отримавши ліцензію на поширення) з'явилася наступна інформація:

УВАГА! Важливі зміни з Extended Support Release

Спочатку випуск Extended Support Release створювався з метою звести до мінімуму час, який витрачають ІТ-адміністратори на сертифікацію кожного нового випуску Flash Player: Extended Support Release обмежував зміни, що вносяться до випуск, до змін в системі безпеки і виправлень критичних функціональних неполадок. На той момент функціональних змін в кожному випуску Flash Player було набагато більше, ніж змін в системі безпеки. Однак зараз ситуація змінилася: кількість попереджувальних і відповідних заходів безпеки набагато перевищує функціональні зміни. На практиці Extended Support Release більше не захищає ІТ-організації від величезної кількості змін, що вносяться до стандартні випуски Flash Player, а лише знижує функціональні ризики. У зв'язку з цим було прийнято рішення припинити випуск Extended Support Release і сконцентруватися на розробці тільки стандартних випусків. Орієнтація тільки на стандартні випуски дозволить нам виявляти більше гнучкості в прийнятті відповідних заходів безпеки і надалі працювати над тестуваннями і новими технічними рішеннями в сфері безпеки.
Щоб надати організаціям достатньо часу на тестування та сертифікацію, підтримка і оновлення Extended Support Release триватимуть до 11 жовтня 2016 г. Потім організаціям потрібно перейти на стандартний випуск.