Software Installation on Windows

Software ‘pushes’

History

In the initial usage of Active Directory among the administrative units at SFU, a GPO was created (SS Software Installs) to send out software using the “magic” MSI push scheme recommended by Microsoft to the HCCC department (the first unit to be managed). This would ensure that all the machines in HCCC would be as similar as possible, and if an upgrade was required, it would be easy to send out the upgrade to everyone with just a few clicks.

As all the units came under management, it was envisioned that each would have their own administrator and each administrator would closely mimic a default setup.

There would therefore be a number of GPOs installing software, each GPO controlling as few as a single machine machine and hopefully no more than twenty to thirty.

However, as AD deployment became more widespread, there was no increase in the number of support staff, and hence no increase in administrators. The initial software install GPO was then deployed more and more widely, eventually controlling over two hundred machines.

This strategy worked quite well as machines were slowly but surely added to the network. Where it worked poorly was when large packages needed to be sent out to all the machines; neither the network nor the fileserver could handle the load of hundreds of machines installing hundreds of megabytes of files.

(At the end of the day, there’s only a 100 mbit link to the fileserver – to send Office to 200 machines would take over 20 hours, assuming nothing went wrong)

The only solution was to create a number of GPOs for each unit. This solved the en masse dissemination issue but created a management problem. It was now difficult to determine which machine/group/OU was running what software.

Also, the magic method does not supply any feedback as to success or failure of the install; Desktop Support doesn’t know until the user calls to complain, something normally considered unacceptable in a professionally managed organization.

Solution:

The master SS Software Installs GPO is going to (eventually) be removed completely. In it’s place will go a large number bunch of nearly identical GPOs, most of which already exist. The existing GPOs or the new ones will have a Startup script defined, named

Master_Push_Software_Script_CSV.cmd

This script will be called with a parameter, for example

ACS_DESKTOP

so that the actual command line will be

Master_Push_Software_Script_CSV.cmd ACS_DESKTOP

The script will take the command line parameter and use it as a lookup into a CSV file. From that information, it will build another script, and that script will then call a whole series of even more scripts that finally do the actual work of installing the software.

A line from the CSV file looks like

aisg_desktop 11 desktop 7.0.1.0 7.0.4 7.0.7 8.0.22.0 10.1r11

The script builder will interpret the line to mean

install McAfee with Patch 11

install a desktop config of Eudora, version 7.0.1.0

install Quicktime 7.0.4

install Adobe Reader 7.0.7

install Flash 8.0.22.0

install Shockwave 10.1r11

So, a script (called with a parameter) builds another script that then calls a whole bunch more scripts.

There will obviously be a large number of entries in this CSV file, but it will now be VERY simple to upgrade small groups (if the upgrade is large) or large numbers of machines if the upgrade is small. Just as importantly, it will be possible to see at a glance what software people are supposed to have.

The scheme is also extensible, so as we require more things to be installed, it’s easily done. (Full blown Acrobat, for example, is just another entry in the database.)

Two more things. A “0″ in a field means don’t install it (maybe for licensing reasons, maybe because we want to phase in an install). A “99″ in the field means uninstall it (maybe Quicktime turns out to have a horrible security whole for which there is no patch. Fill in a 99 and the software disappears at next reboot).

The Scripts

The scripts that actually push out the software are all quite similar. They

check to see if the software requires installation, either because it’s not present or the wrong version

if installation is required, copy all the files to the local machine. (this is the fix for the network problems of last December). If the file copy fails, email an administrator to say so and then just quit.

uninstall the old version (if required), emailing if the uninstall fails

install the new version “silently”, emailing yet again in the event of a failure.

apply any SFU specific (registry) settings

Local Storage

A close examination of network usage during script execution showed that there is a great deal of file server activity for each line of each script, a lot like our Eudora problem, and in some ways worse.

This is because the CMD interpreter (CMD.EXE) reads a single line of a script, then executes it, then reads the next, then executes it, and so on. So the actual network activity becomes

Check permissions to read a directory

Change to this directory

Check permissions to read a file

Request a handle to the file

Open the handle

Read a line from the handle

Close the handle

Close the file

Execute the line, and repeat .. all of the above, for each line.

Since the scripts are each hundreds of lines long, that’s a LOT of activity.

So this software install scheme copies all the scripts (and all the little helper utilities) to the local computer, and runs them from there. It was discovered that things run 2 to 3 times quicker when the scripts are local.

This was rather surprising; consider that the Quicktime script is about 1k and Quicktime is 60 MB, but with the script local, the install takes place in half the time. (The Quicktime install files are local in both cases).

This scheme makes so much of a difference to install times that all the Logon/Logoff and Startup/Shutdown scripts will be converted to be simple two line scripts of the form

Copy \\fileserver\original_script.cmd c:\windows\scripts
Call C:\windows\scripts\original_script.cmd

That is, the working bits of the script will stay exactly the same, they’ll simply be run from the local hard drive.

This change should speed things up for people and also reduce cases where people don’t get their drives mapped (because the server/network was too busy).

Application Specific Tweaks

McAfee AntiVirus

Configuration of the McAfee AntiVirus properties are done using a tool supplied by Network Associates, known as McAfee Installation Designer (MID). The full listing of all the options set or modified are beyond the scope of this document. A typical configuration begins with MID copying the settings from the local machine, the correct assumption being that it’s easiest to configure things using the actual application, rather than a rarely used tool.

Note that the MID tool can create either a full fledged installer (for new installations) or simply a set of changes, in the form of a CAB file. This CAB file need merely be dropped into the appropriate location (%Programfiles%\Network Associates\Virusscan\MID) and within a minute or two, the settings will be read and activated.

Microsoft Office:

All MS Office tweaks are contained in a number of Transforms, created by the Office Resource Kit Custom Installation Tool. The transforms to date are

Install Office with the working directory set to U:\Documents, but no Outlook

Install Office with the working directory set to U:\Documents, including Outlook

Install Office with the working directory left as default (My Documents), but no Outlook

Install Office with the working directory left as default (My Documents), including Outlook

Adobe Acrobat Reader

To allow Adobe Reader to be installed unattended through a startup script, the following steps were taken.

Adobe Reader Downloader was downloaded from the Adobe web site

Downloader was launched, which auto retrieved the “full” package and began an automatic install

At the Next prompt, the ENU folder was grabbed from %programfiles%\Adobe\Acrobat 7.0\Setup Files\ENUBIG and copied into \\ais-fs1.sfu.ca\sw\adobe\reader_7.0.7\Base files

Auto setup cancelled

Adobe Install Tuner (previously installed) was run, and an MST was created.

An administrative install of Reader7 was done, from \\ais-fs1.sfu.ca\sw\adobe\reader_7.0.7\Base files to \\ais-fs1.sfu.ca\sw\adobe\reader_7.0.7

Several problems were noted as this software was being pushed out.

While this software should upgrade all previous versions, it was discovered that it would not upgrade 7.0.0 A special is test is therefore done by the installation script, and if 7.0.0 is detected, it is uninstalled, followed by a reboot. A normal 7.0.7 install then ensues.

Reader 7.0.5 was manually installed by a few admins by logging in as an administrator, mapping a drive to our standard P: and then running the MSI from P:. This creates a problem during the unattended upgrade to 7.0.7, as a reference is required to P: (the original installation source), which of course does not exist. The upgrade then fails and the script (eventually) times out. Therefore, a similar test as above is done, and Reader 7.0.5 is removed if discovered.

Flash

Adobe/Macromedia Flash Player is now distributed as an MSI, and so can be installed and removed through our standard scripted method. The one glitch is that the parameter ALLUSERS=1 must be added to the MSIEXEC command line, so that All Users get to use the software and so that the uninstaller (running as the system account) can find the keys to remove it.

One annoyance did appear with version 8.0.24.0 (the most recent at time of writing). Flash does not store the current version in the registry, and so a key file must be examined for version information. In Flash 8.0.22.0, the key file is FLASH8.OCX, but in 8.0.24.0, the key file is named FLASH8A.OCX, making for a bit of a convoluted series of tests.

Shockwave

Adobe/Macromedia Shockwave Player is a lot like Flash Player, in that it is now distributed as an MSI, and so should be easy for us to roll out. Sadly, there is a bit of a trick required if an unattended install of Shockwave 11 is to succeed.

The MSI must be edited with an MSI editor (Microsoft’s ORCA being a perfectly good choice). The installer tries to create and then remove (for no apparent reason) a number of files and folders in the user’s profile, only there is no profile for the System account (the currently “logged on” user) during startup. A number of fields in the MSI’s internal database must be either edited or removed; being in a bad mood at the time, they were removed, as follows:

In the ‘InstallExecuteSequence’ table, the entry where ‘Action’ is ’setPROFILE’ is removed

In the ‘CustomAction’ table, the entry where ‘Action’ is ’setPROFILE’ is removed

In the ‘Component’ table, all entries where ‘Component’ is ‘CreateFolder’ or ‘RemoveFile’ are removed

In ‘FeatureComponents’ table, all entries where ‘Component’ is ‘CreateFolder’ or ‘RemoveFile’ are removed

In ‘CreateFolder’ table, Drop all entries where ‘Component’ is ‘CreateFolder’ are removed

In ‘RemoveFile’ table, all entries where ‘Component’ is ‘RemoveFile’ are removed

Again, the ALLUSERS=1 parameter must be included on the MSIEXEC command line or the application will not uninstall unattended, delivering up the annoying (and not at all correct) error message

This action is only valid for products currently installed.

Quicktime

Quicktime presented a challenge to push out. Version 7.0.4 of the Quicktime only installer was downloaded. (There is also a version that includes iTunes, but given Apple’s unenviable record with security patches for their Windows software -understandable, one supposes- it was decided that iTunes would not be installed). The installation was begun, getting to the point where one had to Choose Setup Language. At this point, the files inside the bundle had been decompressed to two directories inside of %TEMP%. One of the directories contained a single EXE (annoyingly, of the same name as the initial program, QuicktimeInstaller.EXE). The other directory contained a number INI files. All files were copied to another folder that was to be the basis for our unattended install and the installation terminated.

The INI files were in fact language choices, and the only way to specify this unattended was through an MST. ORCA was brought out again and language 1033 (English Unicode) was defined, an MST was created and given the imaginative name of 1033.MST. As with the Adobe products, an ALLUSERS=1 parameter is required, and so the complete commandline looks like

MSIEXEC.exe /I QuicktimeInstaller.exe /t 1033.MST /Passive /log %TEMP%\qt.log