Documentation (Included in Download As Well)
Version
This document is for version 1.4. Please see the script for
version history information
License
MSISources is licensed under the GNU General Public License.
See "license.txt" or
http://www.gnu.org/copyleft/gpl.html
Script and Documentation Updates
For updates to this script and documentation visit
http://desktopengineer.com/
Windows Installer's "resilience" features and "run from
source" (usually running from the network) require pointers to the location of
the original MSI installation file. These pointers are in the local MSI
database which is actually part of the registry. When a Windows 2000
implementation is done exactly according to the "assumed Intellimirror
approach" - these embedded pointers can be made to behave fairly well.
However, when part or all of the assumed server side infrastructure is not
available, these pointers can be sticky glue from hell.
If You Are Just Starting Your Windows Installer or Windows
2000 Deployment
Windows Installer relies on some type of network level file
server and share abstraction to operate in a multi-site enterprise.
MSI Repositories must be local to the computers they serve. If you
centrally build images to be deployed across multiple physical sites, the MSI
package pointers will be to the location of the build master. This is a
common scenario when deploying syspreped images across multiple physical
sites.
If you are in the beginning stages of planning a Windows
Installer deployment and will not have any kind of NOS share abstraction
(Active Directory published DFS Share or Netware NDS Published Volume) then
consider using drive letter mappings for your MSI repository. At first
this may seem like a cast back to the past, but in reality, drive letters have
always provided site level abstraction of replicated content with very little
planning and effort (compared to an enterprise DFS design). Since drive
letters will not give you fault tolerance, you should also add a second server
to each source list - usually a central server at the network topology "center"
of your network. This server(s) reference could be a UNC if you are short
of standardized drive letters. It is best if this server is not also the
main distribution server for that site. This ensures that failure or
scheduled maintenance of a specific site's MSI repository will not cause errors
for self-healing and deployments that occur when that site's MSI respository is
unavailable.
General Approach of msisources.vbs
When doing the research for this script I was originally
contemplating some type of global search a replace for all MSI paths on a
computer. I quickly found that this was not practical for the following
reasons:
- Although all packages have a source list and the initial
install location is the first item on the list, this information cannot be read
through the MSI APIs. Navigating the registry to find this information
can be difficult since MSI Package IDs are not exposed in a clear form.
- Although InstallDir can be read by MSI APIs, not all
packages have InstallDirs - they are only required when a package is registered
in the uninstall key or is installed to be run from it's source.
- Any global search and replace would potentially need to
preserve the subpath after the drive letter or UNC of the original path.
Because not all paths can be retrieved, reliably finding this subpath is not
possible.
- Some MSIs are installed during the base OS build and
therefore point to MSI files in the Windows 2000 directory structure and should
not be repointed.
- Some MSIs are extracted the TEMP location and
installed from there. Repointing these with their included subpaths would
not make any sense since the subpath is in the profile of the user who
installed the package.
Manage What You Know
I decided that the best approach would be to only operate on
packages that you know you want to repoint. This is done by using
msisources to dump a current list of package codes and any known path
information for them. This control file is then edited to remove any
packages that should not be changed as well as adding literal path or subpath
information for each package. msisources is then run against the new
control file to change only the package paths of the managed
packages.
Typical Operation
If you are testing MSI sources, use the included batch
file to backup the registry keys that will be affected.
1. Dump Existing Paths
Use "cscript msisources.vbs controlfile=packages.txt
dumpmsipaths=yes" to dump a list of all existing Package Codes, InstallDir,
Package Name, Package Version and Package File Name each separated by the "|"
character. This file will look like this:
{5430FF10-2B31-11D3-8F75-00C04F8DD7E3}||Block Diagrams
Help|6.0.1000|SR1_BLOCK_DIAGRAM_HELP.MSI
{5430FF20-2B31-11D3-8F75-00C04F8DD7E3}||Project Schedules
Samples|6.0.1000|SR1_PROJECT_SCHEDULES_SAMPLES.MSI
{6F716D8C-398F-11D3-85E1-005004838609}|C:\WINNT\System32\|WebFldrs|9.0.3501|webfldrs.msi
{26DC3A40-3ECC-11D3-A300-006008A88CA8}||CAD Drawing
Display|6.0.1000|SR1_CAD_DRAWING_DISPLAY.MSI
{C98E7A73-C3F7-4201-8FCD-317B9E5585DD}|D:\W2KSUPP1\|Microsoft Windows 2000
Server Resource Kit: Supplement 1|5.0.2092|w2000rk.msi
2. Edit Control File
To manage the path of a specific package, add the subpath or
paths to the second field and remove any lines that do not pertain to managed
packages. For example:
{5430FF20-2B31-11D3-8F75-00C04F8DD7E3}|packages\project
templates|Project Schedules
Samples|6.0.1000|SR1_PROJECT_SCHEDULES_SAMPLES.MSI
{26DC3A40-3ECC-11D3-A300-006008A88CA8}|packages\cad;final\cad|CAD Drawing
Display|6.0.1000|SR1_CAD_DRAWING_DISPLAY.MSI
{C98E7A73-C3F7-4201-8FCD-317B9E5585DD}|packages\W2KSUPP1\|Microsoft Windows
2000 Server Resource Kit: Supplement 1|5.0.2092|w2000rk.msi
3. Run msisources in "reroot" mode
The reroot mode of msisources will cause each new root to be
added to each subpath of each package and the entire list stored to the
sourcelist. The first derived root will become the first sourcelist root
and the "installdir" (if one previously existed) which is the first place this
package will look for self-healing, optional component installation and "run
from source" components.
For instance if the sample file "packages.txt" were edited
as mentioned above and this command line was run : "cscript msisources.vbs
controlfile=packages.txt roots=\\srv1\share\;f:\files reroot=yes
clearlist=yes" It would result in the following source lists:
Project Schedules:
\\srv1\share\packages\project templates
f::\files\packages\project
templates
CAD Drawing Display
\\srv1\share\packages\cad
f::\files\packages\cad
\\srv1\share\final\cad
f::\files\final\cad
Windows 2000 Resource Kit
\\srv1\share\packages\W2KSUPP1
f::\files\packages\W2KSUPP1
Examine the following registry keys to observe any testing
changes
HKEY_CURRENT_USER\Software\Microsoft\Installer\Products
HKEY_CLASSES_ROOT\Installer\Products
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
"clearlist=yes" ensures that any previous entries in the
sourcelist and installdir are removed before adding the new list. If you
only want to add to an existing list (eg - if you need to run multiple passes
of msisources.vbs to get the desired source lists), do not include the
"clearlist" switch.
Other Items Supported By msisources.vbs
Literal Mode
Msisources also supports a literal mode where all paths are
literal. An example command line and control are below:
{5430FF20-2B31-11D3-8F75-00C04F8DD7E3}|\\srv1\shr3\packages\project
templates|Project Schedules
Samples|6.0.1000|SR1_PROJECT_SCHEDULES_SAMPLES.MSI
{26DC3A40-3ECC-11D3-A300-006008A88CA8}|d:\packages\cad;\\srv2\shr7\final\cad|CAD
Drawing Display|6.0.1000|SR1_CAD_DRAWING_DISPLAY.MSI
WARNING: Literal mode does not support subpaths
(paths that do not begin with a drive letter or share UNC name)
"cscript msisources.vbs controlfile=packages.txt
addtoall=r:\allpackages clearlist=yes"
Would result in:
Project Schedules:
r:\allpackages
\\srv1\shr3\packages\project templates
CAD Drawing Display
r:\allpackages
d:\packages\cad
\\srv2\shr7\final\cad
Once again the first path for each package becomes the first
sourcelist entry. "addtoall" is an optional argument.
Literals with Reroot
If an "addtoall" list is used in conjunction with reroot
mode, the addtoall list is a treated as a literal list and it added to the
sourcelist after all the reroot paths are built.
Automatic Script Host Management
msisources.vbs will automatically change to cscript host if
it is run in wscript. This protects your script operation when "cscript"
is left off of the command line.
Reporting Problems and Requesting
Improvements
If you find bugs in this script or make any improvements,
please contact me at darwin@desktopengineer.com.
msisources.exe