This video presentation and demonstration provides viewers with a technical overview of Windows Installer custom actions and how they may be employed. A demonstration of how to go about creating an "MSI Wrapper" (an MSI setup that launches a command line installation) is provided using Wise Package Studio's Windows Installer Editor. Note: This presentation is also available with the demo utilizing InstallShield AdminStudio.
Running Time: 13:50
This training video introduces the viewer to Windows Installer AppSearch and how it may be used. The demonstrations provided utilize Wise Package Studio covering- creating a System Search entry, showing the value of the AppSearch property in a Windows Installer Dialog, using AppSearch as a condition for a custom action and using AppSearch with LaunchCondition.
Running Time: 21:03
This training video explains transform files and walks you how to determine the contents of a transform file you may receive from a vendor or co-worker using Package Studio, AdminStudio, ORCA and a freeware tool from the Office Resource Kit.
Running Time: 10:29
Creating a driver installation in an MSI can be a challenging task. One of the more popular methods to achieve this is to use Microsoft's Driver Installation Framework (DIFx).
Microsoft provides documentation on DIFx, however it is limited and doesn’t provide any examples.
This article provides a step by step working example of how to achieve this task. For this purpose, we are going to create a Windows XP installation for a Signed Driver: ‘Synaptics Touchpad’ with Wise Package Studio.
Step by Step - Creating a driver installation with DIFx using Wise Package Studio
1. Create a new Windows Installer (WSI) file
Work bench –> Tools–> Windows Installer Editor
If you do not get the ‘New Installation File’ window shown below, select File –> New from the main menu inside Windows Installer Editor
(by default, the last edited .WSI file will be opened).
Select Windows Application
Inside Installation Expert, complete the relevant fields under Product Details and General Information
As this will be a Driver only installation we are renaming the default Wise feature from ‘Complete’ to ‘Drivers’.
Note: If your own installation is to also contain non driver files (e.g. captured application files). Ensure there is a SEPARATE feature which will contain these.
Installation Expert –> Features
Rename the default feature from ‘Complete’ to ‘Drivers’
2. Next, we add the DIFxApp Merge Module to the ‘Drivers’ Feature
Merge Modules –> Add
Select the DIFxApp Merge Module and click Next then Finish
(if the Module is not present select ‘Download’ then ‘Wise Web Site’ to obtain it)
Note: Make sure you are using at least version 2.0 of DIFxApp Merge Module.
The DIFxApp Merge Module should then be visible.
3. Create a folder EXCLUSIVELY for driver files.
Note: If there is more than one driver (not the case with our example), there must be a SEPARATE folder for EACH driver and associated files.
Open the Filesview, then in the bottom window Right Click on ‘Program Files’ and select ‘New Folder’
For purposes of our example, we are calling the new folder 'TouchpadDriver'
Name the folder and click OK
4. Add the relevant driver files
To save experiencing a common problem (this issue will be detailed later), ensure the synpd.inf file is added FIRST. Doing this step ensures the .inf file becomes the KeyPath for the component to contain the driver files.
Highlight the ‘TouchpadDriver’ folder in the bottom left window, then select ONLY the synpd.inf file in the top window and click the Add File button.
The synpd.inf file should be visible in the bottom right window as shown below.
Next, add the remaining files to the ‘TouchpadDriver’ folder:
Check the ‘TouchpadDriver’ folder is highlighted in the bottom left window, then select the remaining files in the top right window and click the Add File button.
Tip: Some drivers have several different folders containing the relevant files. If this appears to be the case, check the entries of the .inf file to see if there are references to files in a subfolder(s).
If so, you may need to modify the file path entries in the .inf file, to allow all the files to be in ONE root folder.
All files for a specific driver need to be in one root folder along with the .inf file for a successful installation via DifX.
5. Configure Driver Installation Options
Double click on the synpd.inf file in the bottom right window to set driver options.
Installation Expert –> Files –> synpd.inf
Select the Driver tab
What to do if there is no Driver tab
Note: If the Driver tab IS present, skip to the next section: ‘Configure Driver Installation Options (Continued)’
This is a common problem with a relatively straight forward solution.
Open Setup Editor from the bottom of your screen and select the Components tab at the top of the left window.
Expand out each component in the left window and look in the relevant Files section until you find the synpd.inf file.
In our example below, the component containing the .inf file is called synpd.inf. We can see that there is a small yellow key icon beside the in the synpd.inf file in top of the right window.
This means that the file is the KEYPATH for the component it is in.
Setup Editor –> Components
If the yellow key is NOT present beside the .inf file then it needs to be enabled:
Right Click on the synpd.inf file and click Set as Key
Note: If you are familiar with using the MSI Tables, the same as above can be achieved there: Reference synpd.inf in the File table to find the relevant component name.
Then, edit the KeyPath of the matching entry in the Component table.
Configure Driver Installation Options (Continued)
Under the Driver tab, ensure the ‘Use DIFxApp to install this driver file’ option is enabled.
Enable the DIFxApp Installation Options to meet your preferences (these are described below).
DIFxApp Installation Options
Retain better-matching Pnp function drivers
Enabling this option will keep an existing Plug and Play driver on the computer if it is seen to be a better match (“better match” means if there is a signed and/or newer driver already on the computer this will be retained and the driver in this installation will not be installed).
If you clear this checkbox, the installation's driver will be installed and over-ride any existing driver on the computer.
Prompt for missing device
Enabling this option gives a prompt and the end of the installation. This will occur if the matching device to the driver is NOT connected to the computer.
Note: Even if this option is enabled, the prompt will NOT appear under a silent install.
Create entry under Add/Remove Programs
This will add an entry under Add/Remove Programs for the driver(s) installed in ADDITION to the standard entry for the MSI installed.
Configure the above DIFxApp Installation Options to your preferences then click OK to confirm.
OS Specific Launch Condition
Once all the steps above have been completed, consider what version of OS the driver is intended for. An ‘accidental’ rollout of out a Windows XP Driver Package to a Windows 2000 PC may not give very desirable results!
The best safeguard is to condition the installation so it will only install on the intended OS.
This can be achieved through setting System Requirements.
Under Installation Expert in the left window select System Requirements.
The relevant options to configure are Windows Version and Windows NT Version. These are shown highlighted in the right window below. Double click to edit them.
In the case of our example our driver is intended for Windows XP, so we have set Windows Version (i.e. Windows 95, Windows 98 etc) to ‘Not supported’.
Also the Windows NT Version has been set to ‘Windows XP’.
The Message Text field defines the actual message to display if the OS Condition is NOT met.
Installation Expert –> System Requirements
Once this has been completed, compile your MSI and the Driver Package is ready to go!
Behind the Scenes - What's happening in the MSI Tables
The key table involved for a driver installation using DifX is the MsiDriverPackages table. The use of each column is as follows:
Should have the name of the component containing the .inf file for the driver.
A number which defines the type of driver to be installed, (Signed or Unsigned) along with the specific Installation Options.
Controls then install order of drivers (if there is more than one driver, lowest number installs first).
Setup Editor –> Tables –> MsiDriverPackages
The following are common examples of values for the Flags column:
Signed Driver Installation
7 = Signed driver install (Standard install with no options configured)
6 = Signed driver install + “Retain better-matching PnP function drivers”
5 = Signed driver install + “Prompt for missing device”
3 = Signed driver install + “Create entry under Add/Remove Programs”
Unsigned Driver Installation
8 = Unsigned driver install (Standard install with no options configured)
14 = Unsigned driver install + “Retain better-matching PnP function drivers”
13 = Unsigned driver install + “Prompt for missing device”
11 = Unsigned driver install + “Create entry under Add/Remove Programs”
Note: Officially, the valid range that can be used in the Flags column is a number between 0 – 7.
Because unsigned driver installations are ‘unsupported’ by Microsoft, the range for unsigned driver installations is 8 and above. Any of these options will show up as a table error (in addition it will appear as an ICE error if a validation is run). This is normal.
Tip: For an unsigned driver installation you won’t be able to set the options via the interface in Wise (using the Driver tab of the .INF file). You will need to go into the MsiDriverPackages table and set the Flags value directly.
Wise Package Studio Professional 5.0
by Bob Kelly
I have been an active user of Wise Package Studio since it was Application Integration Suite (v2.0) but the last review was version 3.02, so there is a lot to be said here! And that really is the problem with reviewing a product like Package Studio- it does so much you’d have to write a book to do it justice. Therefore what I will focus on are the features that Wise Package Studio advertise as exclusive features and naturally a few of those things I think are just too cool to let slip by.
First off, aside from the addition of features there has not been very many “changes” since its earlier versions. Most would agree that Wise got their tools right the first time and there is no need for rewrites or major changes to the way things are. What Wise has done is add to its features- enhancing the functionality and value of this suite. We will cover the following features and capabilities of Package Studio 5.0:
- Project Management and Reporting
- The Wise Software Manager
- Package Meta Data Support
- Package Dependencies Support
- Preflight Deployment
- Mobile Device Package Editor
Then we will wrap things up with overall thoughts and any of my obligatory negative comments.
Project Management and Reporting
One of the features I was impressed with when it first became available is the way you can create and document a process within Package Studio. When you have a team of multiple administrators (particularly when you add someone to the team) it is very valuable to have a documented process- “this is the way WE do things”. The sample project has some good details and adding to the list, tools and inline documentation is pretty straight-forward. Since the introduction of this feature, this too has been significantly enhanced.
Aside from simply checking off a box as you complete each step in the process for a given package, you may also configure the project template to automatically update the project status as you go. Answering questions like “when is my package going to be ready?” becomes much easier when you take advantage of the additional project management data you can maintain. Information you may update includes:
- Estimated Completion Date – Manually specified date on which you expect the project to be completed.
- Current Target Date - As work on the package moves along, if you determine that the project will be completed before or after the estimated completion date, this space is provided to specify an updated target date.
- Actual Completion Date – This field is filled in automatically when the project’s status is set to Completed.
- Estimated Hours – Manually entered number of hours you estimate the project will take to complete.
- Hours Completed – You determine if hours are entered by project or by task. If project, you enter the total number of hours for the project, updating the entry as work on the project progresses. If Task is marked, you enter the actual hours for individual tasks and the total of the task hours is entered automatically.
- Remaining Hours – Initially left blank, when work on the project has begun, use this field to record the actual amount of hours remaining to be done. For example, suppose you originally estimated the project to take 40 hours, and 20 hours have been completed. However, because you know the remaining tasks will take 30 hours to complete, you enter 30 hours here. This provides a more realistic number in the % Completed field:
- % Completed – The percent completed is calculated as follows:
- If Remaining Hours is blank:
- % Completed = Hours Completed / Estimated Hours
- If Remaining Hours has a value:
- % Completed = Hours Completed / (Hours Completed + Remaining Hours).
- If Remaining Hours is blank:
A Metrics tab gives you a nice summary of the package and its progress, highlighting the numbers described above. Additionally, if you are using the IIS front end tool for sharing this information via your intranet (Application Gateway), setting a project status to Closed or On Hold in the Project Management tab assigns the same status to the corresponding request in Application Gateway.
Making all this data even more valuable is a highly configurable reports feature that lets you completely control the reports menu in the Workbench application. There are several included reports and you may create your own as .rpt formatted files (Crystal Reports).
Reports may be exported as PDF, html, and any number of spreadsheet and database formats.
Finally, there is a new Management Reports Web application designed to give project leaders, managers, and other non-packaging personnel access to Workbench reports without running Wise Package Studio. This Web application replaces the reports that formerly were available on the Reports tab of Application Gateway.
The Wise Software Manager
The Software Manager lets you import packages and their resources into its Software Manager database, which provides you with a centralized point for managing all applications at any stage of deployment. Once a package is in the Software Manager database, you can view its resources, either on-screen or by running any of the Software Manager reports.
From Software Manager, you set the package's status, which determines whether the package is still in development, available for deployment, or retired. When you set a package as “available” it also moves a copy to an “Available Packages” folder in your Wise Share Point. This is another process related step that can help you when working with others- if the package is not in “Available Packages” you can tell people to leave it alone! Additionally, when a package is available for deployment, you can use the Package Distribution tool from within Software Manager to distribute the package to end users through a distribution system. Wise has partnered with several distribution vendors (not just Altiris) to provide a nice handoff between the package creation and package deployment steps in your process.
For one thing, you can now move an installation directly into a Group Policy Object in Active Directory. Then you can set Active Directory to distribute the installation.
Package Studio support distribution to Software Delivery Solution (Altiris), Tivoli (IBM), LANDesk Management suite (more details below), Active Directory, Microsoft SMS (more details below), Radia (Novadigm), ZENworks (Novell), and ON Command MSI Package Wizard. Additionally you may distribute the package to a network share, FTP server or perform an Administrative Installation to a location of your choosing.
Wise Package Studio now supports Microsoft SMS 2003 the same way it currently supports SMS 1.2 and 2.0:
- Using Package Distribution to prepare a package for SMS deployment
- Converting an SMS installation (.IPF) in Legacy Setup Conversion
- Creating an installation for SMS in Windows Installer Editor (Installation Expert > Microsoft SMS page)
- Creating an installation for SMS in WiseScript Editor (Installation Expert > Microsoft SMS page)
- When you change a package's status to Available, and the package has an associated package definition file (.PDF or .SMS) for use in a SMS environment, the .PDF or .SMS file is created in the Available Packages directory along with the final .MSI.
Wise Package Studio also provides special integration capabilities when installed on the same computer as LANDesk Management Suite. You can use the Package Distribution tool to copy the package to a directory accessible by the LANDesk Desktop Manager. After the package is copied, you can create a Distribution Package Script using the LANDesk Desktop Manager console, and then use LANDesk Management Suite to distribute the package to end user computers. Keep an eye out for my upcoming review of LANDesk here at AppDeploy.
Package Meta Data Support
Available in the Professional and Enterprise editions, you can now add package Meta Data to store additional package information that is not otherwise recorded by Wise Package Studio. For example, you can specify the type of license model the software uses or point of contact for the application. You can specify the name and type of value to be a text string, an external link, true/false or yes/no value. You already have a database and central location for managing packages, why not work in as much documentation as possible? There are no “default” meta data types included, you need to create any Meta data fields on your own. Some information will make more sense to your environment than others, but here are some ideas to get you thinking:
- Text such as: Application description, in-house or COTS software, license model and number of licenses, hardware requirements, comments about the package, or internal point of contact for the application.
- Links such as: to installation instructions, repackaging requirements, hardware requirements, original source location and other package related notes or documentation.
You may define meta data fields in Software Manager (select Setup > Meta Data Fields). This determines the fields that are available for entry and stored in the Software Manager database. They may then be edited for each package in the Package Attributes dialog. This is available in both Software Manager and ConflictManager. Finally, you can view the data in Software Manager in the Package pane or by using its Package Attributes dialog. In ConflictManager, you can view meta data in the Package Attributes dialog. You can even filter the package display by a meta data field.
Package Dependencies Support
In Software Manager, you can define package dependencies. Package dependencies represent the packages that must be installed for a specific package to function and the order in which the dependency packages must be installed.
When you make a package available, check its dependencies. You might not want to make a package available unless its dependencies are available also.
Before distributing a package, check its dependencies to see if you first need to distribute any dependency packages.
Before testing a package, check its dependencies so you can install the dependency packages on the test computer.
Before installing a package, check its dependencies and install them in the correct order. When a package changes, test the packages that are dependent on the changed package, to make sure they still work.
The fact that Wise bothered to address the issue of package dependencies and ordering shows that they know the needs of administrators. There is a very fine line (that seems to move quite a bit) separating the packaging and deployment processes. Like the other Meta data you can provide in Software Manager, this provides a logical place to document package dependencies. However, I would really like to see this feature taken a step further and support the insertion of custom actions or installation conditions into packages to help actually solve the problem of package dependencies. Also keep in mind that while you can set package dependencies in Package Studio Professional, it does require the Enterprise edition to have this dependency information displayed in a Software Manager pane where it is easily viewed.
The Preflight package installs silently with no prompts- or I should say it “performs its operations” silently with no prompts- for the application does not install. As the name implies, this feature lets you create versions of your package to deploy as a test. The key idea being, that by not actually installing the software- you can test in a live environment.
But wait! If the package doesn't do anything, how does it help me determine a successful deployment?
This is where your thin, moving line between packaging and deployment processes makes all the difference. In an environment where you have a strong deployment and reporting mechanism, Preflight Deployment will be of fairly little value. However, if you do not have a consistent or well-documented baseline you are pushing against, this feature has the potential to become quite valuable.
The Preflight version of your package that is created has no user interface sequence at all, and the remaining actions are primarily custom action calls to a Wise diagnostics DLL. The Preflight package performs the following checks:
- Launch Conditions - Records which launch conditions succeed and which fail.
- .NET Framework - Determines if the .NET Framework is required by this installation, and if so, whether or not the .NET Framework is installed on the target computer.
- Connectivity to URL - Extracts URLs from any Launch Web Page, Download File From Internet, or Post Data to HTTP Server custom actions that are found in the original .MSI. It puts them in a table, which is processed on the target computer.
- Open Document Check - Builds a list of document extensions from any OpenDocument custom actions and saves the list in a table. When the preflight package runs, this test checks the registry for support for each extension.
- File Association Check - Checks that any extensions in the preflight package do not overwrite or reassign those already on the target computer.
- Disk Space Check - Evaluates the disk costing and identifies target computers that don't meet the requirements.
- File Security - For read access, it cycles through the files that are installed and queries the target computer for permissions to access the files. For write access, it cycles through the files that are installed and queries the target computer for permissions to create and update files.
- Registry Security - For read access, it cycles through the registry entries that are installed and queries the target computer for permissions to access them. For write access, it cycles through the registry entries that are installed and queries the target computer for permissions to create and update them.
- File Searching - Cycles through the AppSearch table and evaluates conditions attached to each AppSearch action. It then records if any items items specified in AppSearch exist on the target computer.
- Local File Execution - Evaluates custom actions that launch a file via the command line that is expected to exist on the target computer.
Even better, the results of the Preflight package are reported to a Preflight Deployment database via an http call to a DLL which Package Studio installs on an IIS server. Then, from within the workbench application, you can use the Preflight Analysis tool to view the results as they are reported by each execution of your package.
Mobile Device Package Editor
|One thing not provided by Package Studio (or any other repackaging product for that matter) is some help deciding what does and does not belong in your deployment package. The exclusion list has been updated for some time and does a great job of helping you to eliminate items that should never be in your package. However, it traditionally takes experience to learn why some items may cause you problems- and what problems. Lessons that can be costly in some environments. A new tool to complement Package Studio and provide this valuable information is now available, called PackageCleaner. It scans and reports on Package Studio MSI/WSI files and tells you which items you may not want, what they are, what may happen if you leave them in, and even situations where you may need to include them.|
The new Mobile Device Package Editor lets you edit or create CAB files directly. Edit the files, registry entries, and shortcuts of a CAB. If you create a new CAB, you can also specify platform and processor support and output multiple CABs. The Mobile Device Package Editor tool is primarily intended for opening and editing an existing CAB file. Use it to make minor changes to an existing CAB, including changes to files, registry entries, and shortcuts. If you open an existing CAB, you cannot change the supported platforms or processors for the CAB or any individual resource within the CAB. You can also use Mobile Device Package Editor to create new CAB files, but it is recommended that you instead use the Mobile Devices page in Installation Expert, which provides full functionality and saving of CAB file definitions. This Mobile Device page creates an .MSI that installs to a desktop computer and then transfers the mobile device software to the mobile device. The Mobile Device Package Editor creates a CAB file installs directly onto a mobile device.
Package Studio has long been the favorite of many administrators, and with good reason: Wise has provided tools made for Administrators for several years and they do an excellent job of it. I still use and recommend Package Studio on a regular basis and get excited about upcoming releases every time I hear they are on the way. Package Studio provides a well-developed set of tools for those who repackage applications and continue to push the envelope of what a repackager can be with the release of version 5.0.
It has become expected of me to say something negative about every product reviewed- after all, no product is perfect and there is nothing more annoying than a review that sounds like a sales pitch. With that in mind, one thing that has annoyed me since early on has been the Wise progress dialogs. They include two frames, “Current Operation” where you are told what is happening now and an “Overall Progress” frame which contains a progress bar that you would expect to reflect the “overall progress”. Instead, this progress bar actually reflects the progress of the “current operation”. Depending upon what you are doing, several operations may be necessary which results in an “Overall Progress” bar that restarts again and again. It is reminiscent of the movie “Office Space” when Peter is trying to quickly shut down his machine to escape his boss at the end of the day. No, it’s not slow- in fact, I have noticed that version 5.0 is noticeably faster than previous releases, but the progress bar should read simply “Progress” and not “Overall Progress”. And with that said, if that is the best criticism I can come up with for Package Studio- I think I’ve found a winner!