Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Application Packaging Best Practices for Windows XP: Introduction

Created: 15 May 2007 • Updated: 09 Apr 2009 | 9 comments
Language Translations
Scott Hardie's picture
0 0 Votes
Login to vote

Frequent contributor Scott Hardie has written a 6-part series to share his Application Packaging experiences from the field. If you live by the saying, "the best teacher is experience" you'll enjoy the insights Scott shares in this series.

Editor's Note: Here's a list of the other articles in this series: Introduction, Part 1, Part 2, Part 3, Part 4, Part 5.

Contents

Introduction

Application packaging is the process of identifying application components and determining how those components should be installed and configured on client workstations. This process involves taking commercially or internally developed setups and creating packages that can easily be deployed to client workstations without user or administrator intervention. Windows XP introduces a new built-in service, the Windows Installer service, which manages the installation of software, manages the additions and deletions of software components, monitors file resiliency, and maintains basic system recovery by using rollbacks. All managed applications will be packaged in a .MSI format to take advantage of the Windows Installer technology within Windows XP. Managed applications are defined as applications maintained by system administrators then distributed and installed for end users via Altiris Software Delivery Solution or Group Policy. Unmanaged applications may be installed using the .MSI format but are not mandatory. Unmanaged applications are defined as applications installed by the end user and not distributed via a managed software distribution method.

Windows Installer is made of up of three key components:

  • Windows Installer Service
    This operating system resident installation service provides a consistent standard for installing, maintaining and uninstalling applications.
  • A standard Windows Installer package format
    The Windows Installer based packages are saved in an .MSI format. This is a self-contained database file containing requirements and instructions that the Windows Installer uses when installing or uninstalling applications. Typical instructions in Windows Installer packages include:
    • What application is being installed
    • What files should be copied or deleted
    • What shortcuts should be used, and with what, if any, command line parameters
    • What changes should be made to the registry
    • What Windows XP services should be added
    • How Windows XP services should be controlled
    • What changes should be made to .INI or files
  • A management API for applications and tools
    This API enables the Windows Installer service to manage all file paths on behalf of the application.

The diagram below illustrates the basic interaction between an application and the Windows Installer Service.1

Refer to the Windows Installer Service White Paper for additional information on this new technology.

For some applications, a Windows Installer package (.MSI) is available from the vendor of the product. These packages are considered native packages and in addition to installing or removing applications, they are self-repairing and can install the features of the application on an as-needed basis.

If a native Windows Installer package cannot be obtained, a Windows Installer package can be created with a third party package-authoring tool, such as Wise for Windows Installer. Wise for Windows Installer will be the package-authoring tool standard for you to create .MSI packages. Wise for Windows Installer can also be used to customize native Windows Installer packages by creating Windows Installer transforms (.MST) to meet business specific needs. The Windows Installer transforms are associated with a Windows Installer package (.MSI) at deployment time. Refer to the Quality Packaging Process2 for more information.

All managed Windows Installer packages should be maintained in a global application repository and distributed via Altiris. This document will cover the application packaging process using the package-authoring tool Wise for Windows Installer.

Additional information about the Wise for Windows Installer package-authoring tool can be obtained at the WISE Solutions Web Site.

Note: Some application packages may require customizations that cannot be completed with Wise for Windows. A scripting tool such as Wise InstallMaster or Windows Scripting Host is recommended to complete additional customizations needed to package some applications.

Application Packaging Lab Requirements

This section will provide an overview of the tasks required for establishing a packaging lab computing in the COE environment.

  • Packaging / Site OU

    - The Customer's Packaging team will setup and configure the Packaging \ Site OU as packaging lab(s) are established throughout the customer environment.

  • Packaging Server

COE Member Server (Example: Server Name\Apps\Altiris\Wise Share Point)
At least one server in the customer's domain is configured to the COE server standard. This server will be used for storing application packages during the packaging and certification process. This server will also be used for installing and testing network applications. The server can be built initially in the Production Site OU and the Customer's Packaging team will move the server when configuring the Packaging / Site OU.

COE Terminal Server
The packaging servers for terminal server do not require Citrix MetaFrame to be installed to complete the application packaging process. Application packaging for terminal server can be completed on a standard Windows Terminal Server.

The customer will provide and configure a packaging file server for the Regional Certification Sites. File servers for other packaging labs will be the responsibility of each Business Unit.

  • Packaging workstation(s)

    The Packaging workstations will reside on the network but not be included in any Altiris collections for software distribution. The workstation's image will contain all base applications installed. The Packaging workstations should be a 'Clean Machine' with only the COE build operating system and the package-authoring tool installed. When authoring .MSI packages the packager should re-image the workstation to ensure that each application is packaged on a 'Clean Machine'.

  • Testing workstation(s)

    Testing workstations will reside in the Production Site OU and be used to by the packagers install and test .MSI packages, Windows Installer Technology and application functionality. These workstations should contain the standard COE build operating system along with the core and standard applications that will be installed on all PCs.

COE Terminal Server
These servers will be used to test the .MSI installation, Windows Installer Technology application functionality and multi-user capability. These workstations should contain the standard Terminal Server build operating system, core applications and Citrix MetaFrame. Refer to Appendix A for additional information on setting up testing environment.

  • End User Testing Workstations

    End User testing workstations will be used primarily by the SME or technical owner to review the completed package before moving to pilot phase. Altiris software distribution and end user testing should be tested at the same time. If necessary, end user testing workstations can also be setup at the local packaging labs to validate application functionality.

  • Packaging Tool

    A licensed copy of the packaging-authoring tool (Wise Package Studio Professional 7.x) installed on Packaging workstation.

  • Application Media

    The original media of application(s) to be packaged with any specific instructions needed for installing and configuring the application.

Application Packaging Best Practice for Customers (Local\Citrix\Server)

In preparing applications for customer's new Common Operating Environment (COE), adherence to the following best practices is required to promote a consistent, high-quality product across all packaging sites.

  • During the installation of an application, customization should be kept to a minimum. It is recommended to use default settings when installing applications as much as possible.
  • Applications should be installed to the following locations:
    - Local Client - C:\Program Files\%application%
                          C:\Apps\%application% (Recommended for 16 bit apps only)
    - Citrix Client - Drive Letter:\CSAPPS (%PROGRAMFILES%\%application%)
    - Server Client - \\ServerName\Install\NetApps\%application%
    - The customer standard for utilizing network applications should support UNC paths as a best practice.
    **Note for Network Client application - If an application will be run from a dedicated application server, refer to the Application Data and Installation Directories document from XCEND for additional information.
  • User specific application configuration data will reside in the following locations:
    - Local Client - C:\Documents and Settings\%username%\Application Data\%application% (hidden folder by default)
    - Citrix Client - Drive Letter:\WINDOWS
    - Server Client - \\ServerName\Documents and Settings\%username%\Application Data\%application%
    *Note for Local Client applications - If data will be shared amongst multiple users of the same workstation, the data should be placed under C:\DATA\%application%
    **Note for Server Client applications - Shared application data should be placed under \\ServerName\Install\NetApps\%Application%\Data\
  • Applications or drivers shared amongst multiple applications will be installed to the following locations:
    - Local Client - C:\Program Files\Common Files\%application%. (ie. Sybase ODBC drivers)
    - C:\Common\%application% (For shared applications which won't install to Program Files\Common Files)
    - Citrix Client - Drive Letter:\CSAPPS\Common Files\%application%
    - Server Client - \\ServerName\Install\NetApps\%Application%\Common Files\
  • Do not place shortcuts to documents, help, or uninstall files in the Start Menu or on the desktop.
  • All .MSI packages will be automated with no user intervention required. The end user should not be prompted for additional information during the initial installation or re-installation of an application. Only a progress bar will be displayed during installation.
  • All .MSI packages created in-house should be in a compressed format.
  • All .MSI packages will be configured to install Per-Machine (ALLUSERS=1), exception with vendor packages that require ALLUSERS=2 to function properly.
  • Licensed (Managed) local application packages should be distributed to the workstation instead of the user.

Application Packaging Process

This process can be used as a guide for creating Windows Installer packages using Wise Package Studio. Since Windows Installer packages will vary in complexity, this document outlines what should be included at a minimum. Some Windows Installer packages may require additional options not included in the instructions below. Refer to the Windows Installer SDK to accomplish various tasks using Wise for Windows Installer. The Windows Installer SDK is installed with the Wise Package Studio software and accessed from the Help menu.

Note: All applications should be packaged using an account with local admin rights on the Packaging workstation.

Standard Settings and Templates

To streamline and ensure consistency in the application packaging process, some standard Wise Package Studio settings and standard .MSI templates have been created by XCEND for use to which we make available for our customers.

  • The default template will be modified with a ChangeMe value where modifications are required before and after a Setup Capture and during MSI editing. The ChangeMe value will identify that the correct template is stored on the Wise SharePoint and serve as a value to set as default value during automation programming.
  • During editing of a WSI to apply the correct template to a project set the APPLYTEMPLATE property to blank and save the project; this action will apply or update the current project with the latest template settings stored on the server SharePoint and append a date time stamp as the new value for APPLYTEMPLATE property.
  • The template is applied by going to the Property table and setting the value of APPLYTEMPLATE to NULL, then Save the project.
  • Below is a brief overview of these changes which will be discussed further later in the documentation.
  • Some properties have been added to the template for future use scenarios with default value set to Optional

XCEND- WFWI Customizations

  • The Windows Application.wsi is the share point templates directory should hold all the customizations with the customer packaging standards.
  • SetupCapture has been configured with pre-defined file, registry and directory exclusions. See Appendix A for more details.

Standard WFWI Template
Customer specific templates have been created with standard settings and selections which should be included in all .MSI packages created in-house. Two customized templates have been created to address the application packaging needs for customers.

XCEND Template
This template is designed to address the packaging needs for both FAT and Thin Client applications. The standard settings are detailed in Appendix.

Naming Convention
A standard naming convention has been defined to easily identify an application and determine the application package type. The naming convention should be as follows:

AAAAAAAAAAAAVVV_XY

AAAAAAAAAAAAVVV - Up to 15 characters for application name and version (no spaces)
_XY - (codes to determine Package Type and .MSI Origin)

The codes have been defined as the following:

Package Type: (X)  
T=Transform Application package requires a .msi and .mst file to install properly.
L=Local (FAT) Application package only requires a .msi to install properly.
S=Server (Network) Application package is a workstation or client install for an application running from a server.
C=Citrix (Thin) Application package is to be installed on a terminal server.
MSI Origin: (Y)  
N=Native The .MSI package was provided by a 3rd party vendor.
R=Repackaged The .MSI package was created in-house by a CustomerNameapplication packager.
W=Wrapper The .MSI package serves as a wrapper and calls the original application setup installation via a custom action. This option should be used only if an application cannot be repackaged into a .MSI.

The standard naming convention should be used for the application package directory and all associated files created in-house.

e.g. \\ServerName\Apps\Altiris\Wise Share Point\Projects\ICAClient601_LR\ICAClient601_LR.WSI
       \\ServerName\Apps\Altiris\Wise Share Point\Projects\ICAClient601_LR\ICAClient601_LR.MSI
       \\ServerName\Apps\Altiris\Wise Share Point\Projects\ICAClient601_LR\ICAClient601_LR.DOC

1 Windows Installer: Benefits and Implementation for System Administrators - 2001
2 The Case for Quality Assurance in Enterprise Software Packaging - 2003

Application Packaging Best Practices for Windows XP: Part 1

Comments 9 CommentsJump to latest comment

Brad Horrocks's picture

Great information! One question... you note: "All applications should be packaged using an account with local admin rights on the Packaging workstation." No problem there, however, what if users don't have admin rights? How do you adjust the package so users don't run into problems?

0
Login to vote
Scott Hardie's picture

[quote=brocks26]Great information! One question... you note: "All applications should be packaged using an account with local admin rights on the Packaging workstation." No problem there, however, what if users don't have admin rights? How do you adjust the package so users don't run into problems?
[/quote]

Check out Altiris Application Control to elevate the users rights without giving them Admin access.

Thanks,

James "Scott" Hardie
Vice President of Technology Services
shardie@xcendgroup.com
http://www.xcendgroup.com

James "Scott" Hardie
Security Architect
Security Business Practice
Symantec Corporation
www.symantec.com
__________________________________
Office: (810) 588 9464
Mobile: (810) 588 9464<

0
Login to vote
AngelD's picture

Although Altiris Application Control is a nice way to elevate permissions for a process to run under administrative rights it would be more preferred to redirect the resource under the user's profile or HKCU if possible and if not then change the permissions on resources that requires elevate permissions to have a more controlled client environment from a security perspective.

To check if the application requires administrative permissions at serten time you usually run file- and/or regmon or similar tools as an admin (use runas) and then launch the application as the logged in user (non-admin user) to check for "Access Denied" status during usuage of the application. Then you need to change the permission on those resources that gave you the "Access Denied" status. This could take some time but will in the end give you more control of resources that the user are able to modify.

0
Login to vote
Firewater's picture

Many thanks for this Scott!  Excellent source of reference material which is invaluable as it is clearly based on experience.

0
Login to vote
rayalavinodkumar@gmail.com's picture

nice articele ...which is useful for learners

0
Login to vote
wanchoo_s's picture

Thanks a lot for sharing the stuff.

0
Login to vote
nanya's picture

Application packaging is the process of identifying application components and determining how those components should be installed and configured on client workstations. This process involves taking commercially or internally developed setups..

What does taking commercially or internally developed setups means?

0
Login to vote
EdT's picture

Commercially developed setups refers to those applications where the setup process has been created by the application vendor and you or your company have bought the application for internal use.

Internally developed setups refers to those applications created by developers within your organisation, for which the setups have been created by the developers themselves.

In practice, there is little to differentiate the two categories, except that the in-house developers are usually more accessible if there are any packaging issues, than the developers at external vendors.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

+1
Login to vote