Automating Software Installation With MSI Packages

Download Report

Transcript Automating Software Installation With MSI Packages

Automating The
Windows Software
Installation Process
Dan Gorrell
Network Administrator
S.J. Quinney College of Law
University of Utah
[email protected]
(801)587-7957
The 1L Software Shuffle





150-200 new students each year
Each new student needs standard law-school
applications to be installed. (Printing Account
Client, Antivirus, Research Software)
Each application needs to be installed and
configured identically
Students are generally unaware of installation
procedures and best practices.
Students bring a wide variety of existing
hardware and software to the table
Additional Changes, As Needed




Existing applications may need to be
upgraded or patched
New applications may be added to the
“Law School Suite” of applications
Software may need to be removed from
student laptops
Instead of 150-200 new students, we are
dealing with the entire student population
To complicate things further




While students may use their laptops under
restricted user contexts, applications often
require administrative rights to install
Applications often require file and registry
security tweaks to run properly under restricted
user accounts
Law students are not generally able to perform
these tweaks themselves
What happens when a law student decides to
“clean their hard drive” and deletes application
critical files or settings?
Typical “Solutions”





Install each application by hand (20-30 minutes
per student)
Apply patches manually, as problems arise
Repair applications as students break them,
usually by reinstalling them
Script as many of these operations as possible
and create new scripts to deal with problems as
they surface
Do your best to educate students and hope they
get it right
The Ideal Solution






Software would be installed automatically
Every installation would be identical
Essential files and registry keys would be
replaced if the user deleted them
Security settings on files and registry keys would
be set as a part of the installation process
Software would be updated automatically
If needed, software would be removed
automatically (Software could be there, and
back again)
So how do we get there?




Windows Installer
MSI based installation packages
Installations, upgrades, and rollbacks will be
managed centrally via Group Policy
As a further point of interest, all of these
technologies are FREE, assuming that your
clients are running a professional version of
Windows and you are running Active Directory
on your network. If not, you can still use a
subset of these features, but you won’t get the
“Ideal Solution”
Windows Installer




Windows Installer runs as a service on a user’s
computer and provides a plethora of new
options to deal with these problems
Windows Installer installs software contained in
MSI packages
Windows Installer can allow restricted users to
install software under a temporarily elevated
user context
Windows Installer provides “self healing”
capabilities to your MSI-based applications
Configuring Windows Installer



Windows Installer doesn’t require special
configuration to work. It just needs to be
running
If a laptop is up to date, and if the student
hasn’t disabled it, it should be there
The latest version (2.0) can be downloaded from
Microsoft’s website
95, 98, ME -
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=CEBBACD8-C094-4255-B702-DE3BB768148F
NT and 2000 - http://www.microsoft.com/downloads/details.aspx?FamilyID=4b6140f9-2d36-4977-8fa1-6f8a0f5dca8f&DisplayLang=en
XP – Windows Installer 2.0 is included
MSI Files




MSI Files are the “new breed” of setup files…
they improve on “setup.exe”
MSI Files are actually database files that contain
information about every file, registry key, and
.INI manipulation that needs to be in place for a
piece of software to install properly
MSI files can also contain information about
what security settings need to be implemented
for these files and registry keys
MSI files are “open” and a wide variety of tools
are available to help you work with them
Vendor Supplied MSI Files



Since their debut in Office 2000, MSI files
have been increasingly used by vendors to
deliver Windows applications
As such, many of the applications you
want to deliver to your students may
already have the necessary MSI files
Depending on the complexity of the
application, you may need to tweak the
MSI file to install the way you want it to
A Simple MSI: Adobe Reader 6.0



The installation process for Adobe Reader
is really quite simple
The only option that can be configured
during installation is the program folder
The default program folder is probably
acceptable so we don’t need to tweak this
MSI at all to use it in our environment
Installing an MSI in “Silent Mode”


Installing an application in “Silent Mode” can help you
determine if it will deploy properly or if it needs
additional tweaking
The following command will install our Adobe Reader
MSI in “Silent Mode”
msiexec /i “Adobe Reader 6.0.msi” /q

If your application runs properly after being installed in
“Silent Mode”, chances are it will work well with our
software deployment solution (be sure to test ALL of the
features of the program)
A Trickier MSI: NAI VirusScan 7.0



NAI also ships an MSI file with their
VirusScan product
Their installation has quite a few more
options than Adobe’s did
Chances are that you will want to
customize this installation before
deploying it to your students
Configuring VirusScan Manually
During the installation process, we are
required to enter the following information,






License Type
License Acceptance
Region
Setup Type
Desired Components
Alert Manager
Information





Repository Locations
Scanning
Preferences
Start-Menu Options
System Tray Options
Password Options
And VirusScan STILL Isn’t Configured!




After all of this, we are pretty close to
where we want to be, but…
We haven’t scheduled DAT file updates
We haven’t scheduled any full-system
scans
We are deploying ancient DAT files,
though we do perform an update after
installation
Remember, MSI Files are “Open”




Because MSI is an “Open” installation method,
vendors can supply their own tools for
customizing their MSI files
Whenever deploying an application, check the
documentation to see if such tools exist
Fortunately for us, McAfee/NAI does provide
such a tool
The NAI Installation Designer application allows
us to create a customized MSI package that will
install exactly as we want
A Vendor Supplied MSI
Customization Tool
Testing Our Custom MSI

As we did with Adobe Reader, we will want
to test our MSI by running a “Silent
Install” to determine if it works or not
msiexec /i vse700.msi /q

Doing so shows that our MSI installs
properly and with our custom settings and
so we are ready to deploy this application
If There Are No Vendor Tools



If the vendor of your application does not
supply tools for customizing their MSI, you
can still do so, but it is trickier
A number of tools exist, some of which
are free, that allow direct editing of MSI
files
Let’s take a look at two of them,
Microsoft’s Orca, and WinInstall LE by
OnDemand Software
Microsoft Orca
OnDemand Software’s Winstall LE
One Final Note On Vendor MSIs




Many vendor supplied MSI files require you to
do an “administrative install” of the MSI before
deploying it to users
Administrative installs reorganize files into a
format better suited to network installations
They may also allow you to “hard-code”
licensing information into the MSI
Check with your vendor to see if this is required
for your particular application
What if there is no MSI?
Legacy applications
 Applications without a vendor
supplied MSI package
 Custom applications developed “in
house”, or by a contractor

Grow Your Own (MSI)



Legacy application installation methods can be
used to create an MSI package through a
process called repackaging
Repackaging generally involves taking a “before”
snapshot of a system, installing a piece of
software, configuring it to work the way you
want and taking an “after” snapshot
The two snapshots are then compared and the
deltas are saved in an MSI package
Repackaging Best Practices






Start with a clean machine – Windows only
Close all other programs, including antivirus
Do not do anything between snapshots except
for configuring the software
Go through the created MSI with an editor and
clean out anything that is not related to your
application
Do not repackage an application if the vendor
has already supplied an MSI file
Repackage one application at a time
Repackaging With WinInstall LE




Download and install the latest version (2003) of
WinInstall LE on the machine that you will later
use to edit your MSI file
www.ondemandsoftware.com
Copy Discoz.exe from the applications program
folder onto your MSI creation machine
Alternatively, you could map to a network drive
that contains Discoz.exe
Run Discoz.exe to begin the repackaging process
After The “Before” Snapshot




After the “Before” snapshot completes you can
install your application
You can also perform any custom configuration
that you would like to deliver to your end user
So long as the configuration data is stored in a
file, registry key, or .INI file, it will be included in
your deployed application
When you are finished, run Discoz.exe again to
take an “After” snapshot
After The “After” Snapshot




Once the “After” snapshot completes, your basic
MSI is ready to fine tune and deploy
It is a good idea to open the MSI in WinInstall
LE, or some other MSI editor and verify that
nothing unrelated was included in the package
While you are there, you can also specify which
files are vital to your application and should be
“self-healing” and which shouldn’t
You can specify the user permissions that should
be set on each of the files and registry keys via
their property sheet in WinInstall LE
Testing Your Home Grown MSI


When repackaging software, it is
especially important to test all of the
software’s features to make sure they
work properly
Repackaged software (generally) doesn’t
require user interaction and so doubleclicking the MSI is as good a test as a
“quite install”
Group Policy




Group policy allows you to push software
out to individual users or computers
Group policy works with Windows Installer
to install your software automatically and
in an elevated security context
Group policy can push out upgrades and
patches to keep your software current
Group policy can also “pull back” software
when it is no longer required
Configuring Group Policy To Deploy
An MSI Package
1.
2.
3.
4.
5.
6.
7.
Open “Active Directory Users And Computers” on a domain
controller
Right click on the OU that contains the machines you want to
deploy the software to and hit properties
Select the “Group Policy” tab and hit “New”
Name your new policy whatever suits you best and open its
properties
Expand “Computer Configuration”, then “Software Settings”,
right click on “Software Installation” and hit New->Package
Then browse to the location of the MSI file that you want to
deploy and select it. (Use a UNC path accessible to your
clients)
Select “Assigned” in the dialog box that appears and hit “Ok”
Group Policy / MSI Deployment
Demonstration
To Learn More Check Out



The Definitive Guide To Windows Installer
Technology For System Administrators http://www.wise.com/ebook
Windows Installer SDK http://www.microsoft.com/msdownload/pl
atformsdk/sdkupdate/
AppDeploy Website’s FAQ’s and Articles http://www.appdeploy.com