LANDesk iPass Here you go Matt, just click the Edit button at the top of the screen. Visit the Handy Notes section of the maintenance notes to get some tips I've gathered. Brian Lemberger (blemberger@macrovision.com) \\mec-sch\share 1/9 -- Get VMWare or Virtual PC. Or set up test lab. - -Redist. of Win Installer Svc 3.1 --push to all. (no "undo" typically) -Common Problems with Installations- 1. Sketchy support for different OS's. 2. Broken Uninstalls - dont completely remove application or leave bits and pieces
(indeterminate state of target machine)
3. Rollback (fault tolerance) - "graceful exit from failed/aborted installation attempts.
(removes what it did up till the failure point)
4. NO ability for non-privilleged users (requires admin rights) 5. Complex Installation. During/after install the install process asks questions of the user that can be confusing or requires answers that the users dont have.
6. DLL Hell - (DLLs allow for "code sharing"
-Can result in DLL conflicts between incompatible versions of the .dll file.
- a. "Reference counting" - The process by which the OS keeps track of how many and which
applications are referning or using a specific DLL file, so that the .dll is ONLY
removed when NO OTHER applications are referencing it.
- b. "Versioning" - When Product B updates "shared.dll" to ver.2.0 while product A requires
version 1.0 and 2.0 is NOT backwards compatible.
-- Afternoon session:
Problems faced during installations. --||-- Solutions to problems
1 Improper conditions/dependencies --||-- 1.a)Uniform conditions, b)dependency scanning and
merge modules - allow to bundle depend apps and files
into a single MSI package.
2 No Uniform Uninstallation --||-- 2.a)Every MSI creates an entry into Add/Remove Progs in
control panel (however this can be suppressed), b)The
command line uninstall function is available with EVERY
MSI package -> " c:\>msiexec /x <APPNAME> "
3 Failure of / aborting of Install --||-- 3.)Every MSI package has a rollback function built in that
will 'undo' any changes made by the MSI up to the point of
of the failur or abortion.
4 Admin Rights --||-- 4.)MSIs have elevated permissions (as set in gpedit) that
allow users to install at admin level.
5 Too many dialog boxes --||-- 5.)Users don't know what options to choose or are confused by
by the options or dialog boxes.
6 DLL Hell --||-- 6.a)Uniform file version checking
b)Reference Counting
c)Conflict solving
MSIs are considered a declarative technology - They are open format that use relational databases to store all of the application information and use SQL to manipulate the data. -There are approximately 100 tables in the MSI schema
--Layed out as such:
-Each file gets a record in the table
-each registry entry gets a record and so on.
--Merge Modules and transforms both use SQL commands to manipulate and update the MSI database tables.
AS7 allows for the development of project and workflow procedures that simplify the process of creating repackeged MSI applications. Under the workflow tab of AS you can define a custom workflow template, beginning with the user request for a new app, with step by step instructions and help files on how to evaluate that request and begin the process of repacking a legacy installation. [See img: workflow.jpg] Within this workflow, tools and configurations fo those tools are assigned to the specific steps in the process, along with help files, and admin notes to describe each step. The help files must be in .htm format and can be created and stored anywhere, then as the workflow is set up the admin just points the help file for each step to a specific .html file. Once a workflow template is created, the admin can go into the Projects tab and create a new project. When creating the new project, choose the custom workflow that you just created to incorporate a checklist for the steps neccessary to repackage the application. Application Catalog The application catalog is simply a .mdb database that AS uses to keep track of all of the projects and workflows associated. The database can be stored locally, setup over a network share, or installed on SQL server or Oracle database server. By setting it up on a network device, it would allow collaboration among different groups that work on the same package, or can be especially handy for testing packages among different admin groups before they are deployed. AdminStudio REQUIRES a catalog to be present when it starts. By default, AS7 uses sample.mdb, - located in C:\AdminStudio\Shared. This can be changed by choosing CATALOG > Create New > choosing the format and options, then connecting to the new database. The new database can be set as default, so that when AS opens it will open to that .mdb file.
NOTE: The SAMPLE.MDB file that AS loads has example workflow templates and projects preloaded. These make a good reference point for creating new workflows.
Setting up work and development workstations: The IS/Macrovision suggested way of setting up workstations for testing and development is to use VMWare to create a 'machine' that will be the base. It is suggested to create a baseline image that is as close to being 'OS only' as possible - EXPLAINED LATER.
Overview of Application Migration Process Workflow Management Page 16 -Steps in packaging an installation 1.Verify the request Acquire Installation Media Verify Install Instructions Verify that the app will work on the target machine 2.Create Storage Structure Rename the tope level directory to the APPNAME_Version, etc (This is determined by us-should be a standard though) Copy Media, instructions, and documentation to the correct folders SEE AS TrainingDisk directory for examples 3.Is it a LEGACY or MSI installation? This determines whether you will need to repackage the legacy install, or simply create a transform to customize the exisitng MSI file.
See pages 16-18 for specific steps involved.
The most common ways to determine are to:
1.) Try to expand or unzip the .exe using winrar or other compression utility.
2.) Run the .exe under the VMWare and monitor it with filemon (look for *.msi in filter)
4.Validation
These are rules provided by Microsoft for their Windows installer technology. Refered to as ICE - (Internal Consistency Evaluation) -This is all done within Editor and Conflict solver.
5.QA Testing
Policies and test cases are determined by business needs. These are up to the administrator.
6.Conflict Solving
Conflict solve against other installed applications. -This can find errors that will occur when msi package is installed against other existing apps. Some errors can be automatically corrected by the Conflict Solver tool.
7. Distribution Wizard.
Configures the MSI for deployment via various distribution systems.
-- Tuner vs. Editor Tools Tuner is the older tool, however is very powerful. Editor has the ability to do everything that tuner can. (Create .mst files) Organization of Files
Suggested format (see directory structure in training disk) is to create a directory such as:
AppName, version, date, language, etc.
>1. Legacy Setup (INSTALL.EXE or SETUP.EXE and any associated files from the install media)
>2. Documentation (installation instructions - any options needed for the installation and configuration. Where/what/how to install? **Best practice - take screen shots of the setup process to document so that you can go back at a later date and know what you did and how to redo it.)
>3. Repackager and source files (.inc file & application directories that are created by the repackager)
>4. Project Files (.ism file and associated files (.cabs, etc.) The project files can be stored as .XML format and be logged into a source versioning software)
>5. MSI - current revisions of the completed MSI files only.
Things to document** (see page 27)
1. Take screenshots of each panel during the install process 2. Passwords and licensing/serial numbers and codes. *Also may be useful to document licensing for individual installs.* 3. Prerequisites --such as Java Apps require the JRE to be installed prior to installation/launching 4. Test Cases -- applicable testing cases for the specific application 5. Enterprise Standards -- where to install, what icons to include/leave out (not on desktop, etc), what support information to provide in ADD/Remove programs. Is it a quiet install, silent, full, basic? Where are files located (source media/server address)?
Configure VMWare install
Clean installations - network use host only (can use bridged instead) -- What to use for a "standard" or "baseline" image: Two schools of thought regarding what should be on the image: 1.) Base image - what is installed on every machine - including apps like JRE, MSOffice, etc. 2.) Clean/OS only - This helps to identify conflicts within individual packages **Macrovision suggests to user a standard image as close to a base OS as possible. Can include things like MDAC, IE6, etc. *Unanswered question - what about apps that need other progs installed before the new app is installed. - example: needing MSOffice installed before installing ChemOffice - so that it installs the neccessary excel components.
If installing an app that installs drivers or other hardware, then VMWare should not be used - **OR** remove the components/features to prevent drivers from being installed. Best Practices
Snapshot is generally the more accurate capture method. After capturing the install, it is best NOT to open the application, as you do not want to capture changes that occur with the first run of the app. -Instead, the MSI will set these after it is run the first time on the target machines.
Files Involved in Repackager
.nir file - is a registry file that lists hte differences between the before and after snapshots. The files are stored in a folder structure hierarchy corresponding to where they get installed. Options.ini - \AS7.0\Repackager\ - are the analyzer options that get included with the repackager.ini file in C:\adminstudio shared \repackager.ini. Here you can alter what gets excluded. Original target folder - [ProgramFilesFolder] Sample Co\FirstApp is a variable instead of showing C:\program files++** The capture report summary can/should be included in the documentation .irp file - gets put into repackaged output directory.
Monitoring
p.43-48 INSTALLATION MONITORING Can edit setup list -> to launch multiple installers. Can also set analysis options -> These are session based Monitoring produces updated.isr files instead of standard.nir. Both methods provided a log file- in the windows folder of the repackaging system.(host)
Reasons NOT to repackage existing MSI installers:
When a new MSI is created, it creates new component codes, package codes, and product codes for the new MSI. This prevents automatic upgrading through vendor provided updates/upgrades as the upgrade package looks for specific vendor provided codes for upgrade - which will not be present. Transforms DO NOT change the component codes.
InstallScript MSI Installers p.67 - These installers are a hybrid that have been developed over the last several years as more vendors started to adopt Windows Installer Technology. It is based on legacy technology and is a hybrid of InstallScript and MSI
**The best way to package these is to convert to 100% pure MSI files - this ensures that the component codes do not change. Repackager should be able to determine and convert the Installscript installer to a pure MSI.
Summary of Day 1: The first day started with alot of background information about the technologies associated with Installshield and MSIs. There was also alot of discussion on the problems that administrators face when trying to perform installations and then explanations on how MSIs can solve ALOT of those problems. Then we moved into explanations of the various tools within the AdminStudio suite. We began working with a few examples and have begun to learn about 'best practices' that the folks at macrovision have devised over the years to create good MSIs. (I've already seen that I've been doing a few things wrong) We've started to go over work flow management and how to create and maintain the application catalog on a single machine or set it up on a server to allow for more collaboration. Two of the things that they highly suggest - not necessarily in this order - are documentation (go figure) and to make sure that you have a clean baseline (standard) image when capturing the installation - they HIGHLY suggest an app like VMWare to have an easy way to create and image and go back rapidly after capturing your installation. They suggest not using a "base image" - ie the common load set that will be installed onto the users machines as the standard image, but instead to have an image that is as close to "OS ONLY" as possible. So things like SAV and MSOFFICE and the like don't affect the installation of any other files or such. Another thing that I found out was that while installation monitoring may be the newer and faster of the technologies when compared to Snapshot, it is also "relatively less' accurate when creating MSIs of any type of complexity. (Personally I've found that it just doesn't work right in our setup...but anyway... ) So the macrovision suggested method of capturing an installation is to use snapshot. So far everything he has talked about has made alot of sense, and I've caught myself a few times going "OHHH...so that's what that does..." or "Why didn't I think of that?" as he showed us the different tool sets in AS7 and explained best practices of laying out directories for work flow management. One of the biggest takeaways for me from day one is that I shouldn't install AS on the box that I am going to use to capture the setups, but instead should set it up to run remotely and save the output to a remote location as well. This prevents any system files and other application files from being modified, updated, overwritten, or deleted, and prevents the setup files and directories that are being created to store the install information from being included in the MSI. I've also learned that AS7 is better than AS6, and that both are leaps and bounds ahead of 5.5. In addition I've also discovered the joys of working with VMWare and that it would be very beneficial to us - and make my life alot easier - as it would provide for faster MSI re/packaging by not constantly having to re-push images to machines after installing or testing a package. It also allows us to simulate the users machine more accurately, adjusting the available memory, loading test cases / software for conflict identification/troubleshooting/resolution, as well as test patches and stuff like that.
1/10/2006 - Day 2 Chp5 Command Line installations, uninstalls, logging, public properties.
Installing from command line.
MSIEXEC /? to get help and options for Windows Installer MSI Package will not uninstall files and folders it did not install => This prevents user data from getting erased/removed when an application is uninstalled or upgraded.
Advertisement - Partially installs an application -> Shows the shortcut in place, but the actual files are not installed. Similar to AOL applications that come preinstalled on new computers - clicking on the link installs a the application. msiexec /j* /jm = per machine /ju = per user
/f =repair, /a =create ADMIN image /qf, /qr, /qb, /qn= quiet full, reduced, basic, none - alters the user interface when installing from MSI. /qb and /qr can use ! to remove cancel button
Command Line installations, uninstalls, logging, public properties.
- Testing/Test cases.
- Test Plans - Page 73 1.) Build Project (from .ism file)
-Run MSI validation to check for ICE errors
- 2.) Installation - try installing onto clean "base" system - are there any errors?
-Check for dialog boxess as well as checking MSI_Log files in temp directory for any listed errors that occur. 3.) Functionality - Run the application. -Does it work correctly? -a) Check File associations - do files with that file extension open correctly? -b) Test shortcuts on Start Menu, Quicklaunch, etc to verify that the application loads -c) Check menu settings (File, Edit, View) and ensure that the user will be able to configure the application. If these menus do not work, there may be missing registry, COM, or .dll files -d) Can you save? Can you print? - May indicate permissions problems. 4.) Uninstallation - Does it uninstall? Do other apps work? Does the OS work after installation?
Page 76.
- Legacy Differences test - If something doesnt work after creating MSI package - can use this method to determine if the repackager missed components.
1.) Run the MSI package, then take a Snapshot after the .msi install finishes.
2.) Run legacy install (Setup.exe)
3.) Run the snapshot wizard again after legacy install completes
- Any differences between the two outputs in .isr and .inc are what the .MSI file is missing. Check .inc and .isr files - they will list the differences. -Empty file means that the MSI captured everything.
- Any differences between the two outputs in .isr and .inc are what the .MSI file is missing. Check .inc and .isr files - they will list the differences. -Empty file means that the MSI captured everything.
- Clean up Test
1.) Take multi-step snapshot of the system.
2.) Run the installation package (.msi), run the application and check all functionality
3.) Uninstall the application through Add/Remove Programs
4.) Take 2nd snapshot
5.) Check the .isr and .inc files to determine what the uninstaller is leaving behind - may be neccessary to list in REMOVE_FILE table in MSI Editor.
quality monitor Two issues. Stand alone quality monitor to install on test image. - available from install shield. Cant run remotely because of a bug in AS7. Knowledge base article Q111754 for download. Quality Monitor Crash Knowledge base article Q111752 for download. When creating a new project the quality monitor uses ONLY the msi files htat are currently installed on teh machine Creates <filename>.iqm files. - Save to documentation directory. Type Libs, Prog IDs and CLass IDs are all COM objects. Can do run all, and will not give interaction. Lockdown and Runtime testing. - Running app as a different user. Similar to RunAs. Can run shortcut or executable. Can choose run or runas, then select user. Can create and add own test cases. Specify directions and follow those instructions. -Deployment Status.
-- Users see features....components are behind the scenes. -- Can install features from console.
-Generate Report - create HTML report in Project (.iqr) directory-- Shows all class IDs, shortcusts, al componenets
Chapter 6 - Installshield Editor
Help>Contents>Windows Installer Docs - this shows the DB Schema and table layout for .MSI files
- Configuration for Editor Page 95 - Settings for repackager (Genral tab) 1.) Force best practices to limit to one .exe per component (Genral tab) 2.) Uncheck set all users (Directory tab) 3.) Enable "Cleanup unused directories"
1/11/06 File Versioning Rules
1. File to be installed and existing file both have versions
-If file to be installed > version, thehn iti is installed
-If exisitng file > version, then it is retained
2. One file has a version, teh other file does not.
-the file with the version wins - versioned gets retained.
3. Neither has a version. (txt, html, stuff like that)
-File is replaced only if it is unmodified. - This prevents user data from ever being over writting by MSI
a>If a file hash is stored in the MSI, file
b>Date modified date > Date created
Option in Organization/Setupdesign - compnonent can set "NEVER OVERWRITE" to ignore rules and allways keep. v Can force MSI to set a file to overwrite existing file - Choose properties of file within setup design component and select Always Overwrite
Conflict solver can catch conflicting versions or filenames.
- Features
[INSERT DIAGRAM HERE]
-Features are selectable by user of installer -Components are not visible to the user -When a user selects a feature during install, the feature determines which components are being installed. -*Components are what the MSI installer tracks - to determine whether the app is installed, needs to be repaired, and what gets uninstalled
-Components included typical things such as:
-Files -Registry Data -INI files
-*When the application is launched, the MSI checks to see that all components are installed by verifying each "KEY FILE." This allows the installer to ensure that all components are installed without having to check each and every associated file.
- KEY PATH - the key path can be a directory, file, or registry data. However it cannot be an INI file.
***If the installer does not detect the Key File, then it will try to self-heal the application.
- How Repackager creates components
By default - if a component that doesn't contain any files, the MSI does not create a directory. Can be created through the CREATE_FOLDER table in the MSI
- Components can install to exactly ONE destination folder
Component B installs to [HELP] Directory
- -These rules mean that each component does not contain alot of files. It is better to have MANY components with few files, than few components with many files in each. These are hard to verify that they are properly installed.
***There can be one (1) .ocx, .dll, or .exe per component when following best practices.
- Merge Modules
Ensures that the shared components always use the same component code. Example: An app that needs VB6 runtime will include the merge module for VB6Runtime, so that any other application that requires those files will also (continue) to work correctly. -Merge Modules are included in AdminStudio, or more can be downloaded from InstallShield, Microsoft, and other vendors. ***Dependency Scanning will automatically add neccessary Merge Modules to the package. ***Conflict solver does this as well - it IDs components that may be handled better by merge modules
- Properties -If name is declared in all capitals (ie. ALLUSERS=...) then it is a public property. -Public properties can be set in the MSI or through the cmd line -If has lowercase characters, then it is a private property, and can ONLY be set when the MSI is created.
--- 1/12/2006 Setting Permissions Within the component, file, registry, etc you can set the permissions for the files and data structures associated. Right click on the object and choose properties, then click the permissions button on the bottom of hte panel. When setting permissions, you can use Domains, usernames, enivronmental variables, or MSI properties to set the values. EX>
DOMAIN | USER
[%USERDOMAIN] =Sets permissions for the currently logged on domain user using an enviro var.
[LOGONUSER} =Sets permissions based on the MSI property of the currently logged in account
USERS =Sets permissions for ALL users in this defined machine group.
[DIALOGUSERNAME] =If we created a panel that asked for a specified username and password on the
machine then this command would use that info to set permissions to that account.
If you have permissions set on files,etc and want to remove all the custom permissions, goto Direct Editor adn slect the LOCKPERMISSIONS table. This is a listing of all files that have had their permissions altered by the MSI. RELEASE OPTIONS p. 127
Installshield offers ONE-Click install for web downloads - can look into this later.
There are advantages to using SETUP.EXE for creating install packages. Can set the exe to install the Win Installer Service to the correct version for the MSI packaged within. However for most deployment/distribution systems, you will rely on MSIs alone.
Releases laid out by configurations > releases. You can set in here whether every build should generate a new package code. The release wizard allows for a simple way to edit the properties of the release without having to do it all manually. The typical config is:
1.Set to network image -this streams the .cab file into the MSI creating just one file for install.
