Showing posts with label computers. Show all posts
Showing posts with label computers. Show all posts

Wednesday, August 12, 2015

Updating Adobe Flash Player with batch files and SCCM 2012

I've been faced with updating a lot of (to me) computers with the current version of Adobe Flash Player due to the recent vulnerabilities in Flash. I haven't found a good way to be notified of a new release, so my browser is now set to open a tab with the version of Flash available.

Of the over 4000 Windows computers I am attempting to keep updated, over 90% have Adobe Flash Player installed, with either the ActiveX or NPAPI version installed (or both). I'm using SCCM, so I deploy Flash Player as a MSI package. And it seemed like I would deploy an update, then a new vulnerability and update would crop up, so a new deployment/upgrade cycle began again. I'm not fond of this Flash Update Ouroboros so I wrote a script to simplify things.

First, the script for ActiveX:

@echo off
REM Run via SCCM against collection of devices with old Flash Player ActiveX

:VERSION
REM set current Flash version
SET CurrentVersion=18.0.0.232
SET CurrentMajorVer=18

:GRACEFUL_UNINSTALL
REM attempt to gracefully uninstall Flash
wmic product where "name like 'Adobe Flash Player%%ActiveX' AND NOT version like '%CurrentVersion%'" call uninstall

:INSTALL_CURRENT_FLASH
REM install current Flash from distribution point
%Comspec% /c msiexec /i "\\server\software\FlashPlayer\%CurrentVersion%\install_flash_player_%CurrentMajorVer%_active_x.msi" /qn

:END

Next, the script for NPAPI Plugin:

@echo off
REM Run via SCCM against collection of devices with old Flash Player Plugin

:VERSION
REM set current Flash version
SET CurrentVersion=18.0.0.232
SET CurrentMajorVer=18

:GRACEFUL_UNINSTALL
REM attempt to gracefully uninstall Flash (old versions "Plugin" new ones "NPAPI")
wmic product where "name like 'Adobe Flash Player%%Plugin' AND NOT version like '%CurrentVersion%'" call uninstall
wmic product where "name like 'Adobe Flash Player%%NPAPI' AND NOT version like '%CurrentVersion%'" call uninstall

:INSTALL_CURRENT_FLASH
REM install current Flash from distribution point
%Comspec% /c msiexec /i "\\server\software\FlashPlayer\%CurrentVersion%\install_flash_player_%CurrentMajorVer%_plugin.msi" /qn

:END

The only real difference is the Uninstall and Install section to reflect ActiveX vs Plugin. The script uses WMIC to look for any Flash Player that is installed but not current, uninstalls it, then installs the current version based on the variables set in the script. Assuming you create the folder with the version number and the current packages, the script can be edited and used to update computers quickly.

On a higher level, I'm using System Center Configuration Manager to limit my collection of devices so I am only running the updates on the computers that need it (that would be an entire other post). While I think that you could just use a GPO to push this, be aware that all systems would end up with Flash Player installed even if it didn't have it installed before. By targeting only the systems that already have Flash Player, I am updating computers but not increasing my vulnerability surface area.

Naturally, I considered installing an update server, but I haven't figured out Adobe's documentation on this. For now, this batch file does the job for me.

To update your packages and script when Adobe releases a new Flash Player,

  1. create a new folder named after the current version on a distribution server (i.e. \\server\software\FlashPlayer\18.0.0.999)
  2. download the Adobe Flash Player distribution packages (sign up here) via your custom URL obtained from your Adobe Distribution Agreement email and put them in the folder you just created, and
  3. update the "CurrentVersion" and "CurrentMajorVer" variables in the batch files, then
  4. deploy.
Enjoy. The lack of additional explanation is mainly due to my intention to remind Future Me what I was doing when I forget my methodology and to give other IT guys a starting point for ideas on updating Flash Player en masse.

Tuesday, March 31, 2009

Worried about Conficker?

Are you worried about Conficker? It's set to go off on April 1st.

It only affects Windows computers, so if you're running Macs or Linux machines, don't worry about it. (Mac users, don't feel too smug, as the recent PWN to OWN demonstrated an exploit of a fully updated Mac in mere seconds).

There's a fairly detailed analysis at Windows Secrets. If you think you might have Conficker, try visiting http://www.symantec.com/ or http://www.mcafee.com/; if you cannot, you may have it.

To remove Conficker, visit http://www.bdtools.net/ and download BitDefender's single-PC conficker removal tool. If that doesn't work on the infected PC, download it from another and run it on the infected PC.

If you are a network admin, go get Nmap (see also this) and run the following command:
nmap -PN -T4 -p139,445 -n -v --script=smb-check-vulns --script-args safe=1 [subnet]
where subnet is something like 192.168.1.0/24 -- you can thank Doxpara for that.

I would also suggest that you use OpenDNS. They have been blocking conficker since February, and there's more detail here. Seriously, sign up for OpenDNS if you are not using it yet; it's free and does more than just provide DNS. I've talked about them before, but not enough.

Thursday, October 02, 2008

Rant: some people shouldn't be sysadmins

Argh. I just got off a client's system where their 'sysadmin' had messed things up so badly it took me 30 minutes to realized he had misconfigured up his DNS server, that his computers were part of a domain but all logging on locally, and the server and workstations were using two different sets of DNS servers even though he is running DHCP. None of it makes sense! And the users just want to do their jobs and go home.

It is soooo frustrating to fix other people's messes. And I know the guy is paid more than I am because he's the sysadmin for a large national vanline agent. *sigh* Where can I get a gig like that, where people overpay you and don't know you are out of your depth?

Thursday, July 03, 2008

Uptime of 38 Years, 4 Months, 3 Weeks


There's no way this is accurate, since I installed this system myself, but I came across a UNIX system that claimed an uptime of 38 years, 4 months and 21 days. If that were true, this would literally be one of the first UNIX systems ever. Must be a math error...

Monday, June 02, 2008

Coincidence?

My laptop died the day after this comic came out... what a coincidence...?