Video Screencast Help

Endpoint Management Community Blog

Showing posts tagged with Wise Packaging
Showing posts in English
Deepanshu | 25 Nov 2008 | 1 comment

Many Times during packaging or troubleshooting we need to work on services. So there is an executable present in windows\system32\sc.exe which can be very useful for this purpose. Below is some information and command lines on this.

Service Control - Create, Start, Stop, Query or Delete any Windows SERVICE. The command options for SC are case sensitive.

Syntax

SC [\\server] [command] [service_name] [Options]

commands:

query [qryOpt] Show status
queryEx [qryOpt] Show extended info - pid, flags
GetDisplayName Show the DisplayName
GetKeyName Show the ServiceKeyName
EnumDepend Show Dependencies
qc Show config - dependencies, full path etc...
networkchic | 19 Nov 2008 | 1 comment

Here is a sample Flag File which we deploy with all packages. It's placed at the end of the script and verifies a successful install.

We create a perm. directory on C named 'Installs' and every package deployed and installed on the machine drops a flag file here. We use cumulative .txt files for apps that are receiving upgrades and it places a line of text after the last line in the file and describes what the upgrade did.

License: AJSL
By clicking the download link below, you agree to the terms and conditions in the Altiris Juice Software License
Support: User-contributed tools on the Juice are not supported by Altiris Technical Support. If you have questions about a tool, please communicate directly with the...
piyushnasa | 18 Nov 2008 | 0 comments

There are five properties which are required by every Microsoft installer to identify itself from other MSI.

These properties are required to be present in every MSI.

These are the five properties:

  1. Product Name: It is the name of the application you mention in your MSI.
  2. Product version: This is the version of the product which you give.. like 1.0.0 etc..
  3. Product code: It is the unique GUID for your MSI.
  4. Product language: This is the numeric value of product and should be one of those entries mentioned in Template summary property in Summary information stream.
  5. Manufacturer: This is the name of the manufacturer of the product.

For future upgrades, it is recommended to add Upgrade code property in the package.

WiseUser | 14 Nov 2008 | 0 comments

Command line to apply multiple transforms:

Msiexec.exe /i {path}.msi TRANSFORMS=T1.mst;t2.mst

Value Supercedence:

If t2.mst contains any property or any update that t1 has made, the installation will take the final transforms value.

Ex: If t1.mst sets a reg value HKCU\Software\Test\Enviorment =0

And if T2.mst sets a different value to the same registry HKCU\Software\Test\Enviorment =1

then the instalaltion will take the reg value as 1.

Deepanshu | 12 Nov 2008 | 7 comments

This is something different thean what you think. I was working on a package for which I want to hide the Add\Remove Program entry but when I look into the following registry hive for systemcomponent entry it was not there:

HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\{ProductCode}

Now what to do? I thought, I will make an entry at this hive with my product code, then I will create a Registry Key As follows:

SystemComponent=1 

And it works! If you face the same type of issue it may be useful for you.

R-Vijay | 11 Nov 2008 | 0 comments

Here are some component guidelines which you need to follow in your application MSI. This will solve many issues like installation fix and automatic package repairs.

Always remember,

  • HKLM + HKCU in same component are not allowed
  • HKCR + HKCU in same component are not allowed
  • HKCU + Files in same component are not allowed. (Exception where the files are going to user profiles and key path is HKCU key path)

Also, when you design a custom component having HKCR or HKLM components, do check the Auto increment option; this helps the machine maintain a stable state.

WiseUser | 11 Nov 2008 | 1 comment

The following are the best practices recommended by Microsoft in creation of a package. It's a good list to keep handy.

  1. Match Components in previous versions of the .MSI
  2. Add all executable files to their own components
  3. Add all .TLB Files to their own components
  4. Group Matching .HLP and .CNT Files together
  5. Group Matching .CHM and .CHI Files together
  6. Put registry keys associated with files or components in matching component
  7. Put Current user registry keys in their own component
  8. Put non-Current User registry keys in their own component
  9. Group all non-executable files to their own component
  10. Name new non-advertised shortcuts by destination directory
  11. Group non-keypath resources by resource type
  12. Create new components for resources not matching other criteria
WiseUser | 10 Nov 2008 | 0 comments

When we create a Windows Installer file by using Visual Studio .NET, we do not have the option to designate that your package is to be advertised.

We can advertise the package only by using a command-line option during the installation. At the command prompt, we can explicitly list the features that we want to advertise or we can advertise all the features.

To explicitly list the features, we must use a command that is similar to the following:

Msiexec.exe /i {PATH}\.msi ADVERTISE=Feature1,Feature2,Feature3

If we want to use this command, the features must be present in the Feature column of the Feature table in the Windows Installer file.

To advertise all the features, we must use a command that is similar to the following:

Msiexec.exe /i {PAth}\.msi ADVERTISE=ALL

Raman | 04 Nov 2008 | 5 comments

Ever had query on Wise Package Studio? Here is the website that will answer your queries. It is designed for the beginner.

http://www.dawnstar.com.au/wpshelp/

WiseUser | 04 Nov 2008 | 3 comments

The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed.

This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in a call to MsiDoAction.

A deferred execution custom action enables a package author to specify system operations at a particular point within the execution of the installation script.

The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead the installer writes the custom action into the installation script.

  1. Should be placed between install initialize and install finalize.
  2. Does not have access to MSIDATABASE in deferred...