In this fourth installment in the series, application packaging pro Scott Hardie focuses on the intricacies of packaging network applications. Scott also does a great job listing and describing troubleshooting tools and utilities that every application packager should know about.

Contents

Network Applications
Troubleshooting Utilities

Network Applications

Network Applications are defined as programs in which the application executable resides on a file or application server. In these instances icon(s) and minimal configuration settings (if necessary) may be required on the workstation for the application to run properly. A .MSI package can be created to make the necessary changes on the workstation. Whenever possible, terminal server is the preferred method for running shared applications. In instances where a shared application is not a suitable candidate for terminal server, the application can then be run from a server. The .MSI packages for network applications will be distributed via Altiris.

Additional Best Practices for Network Applications

Determine the feasibility of running application on Terminal Server.

• Follow the instructions accompanied with the software to install application on the server. The server installation will NOT be included in the workstation .MSI package. For packaging and testing, grant the Site-ARC-Netapps security group the appropriate permissions for the application directory(s) on the server.
• UNC path names should be used to access other network resources. (i.e. dedicated application servers)
• Shortcuts for Network Applications will be placed under Start - Programs - Network Applications. Additional folders can be created under the Network Applications folder for Network applications with multiple shortcuts.
• The App Paths registry key will be used to append additional directories to the search path for an application to run properly. This will ensure the application can access the directories needed to run the application. If an application only requires the working directory of the network application to run, the App Path registry entries are not required.
  
  Example:
  HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\
  CurrentVersion\App Paths\ENTUSR32.EXE

  Name	Type	Data
  Default	REG_SZ	W:\HYSOFT\ R4_32\ENTUSR32.EXE
  PATH	REG_SZ	W:\HYSOFT\\ R4_32;W:\HYSOFT\CDA

• Access to network applications will be granted based upon Windows XP security group membership. The security group will grant permissions to the application directory(s) on the server also be used to distribute application via SMS. The business units will be responsible for creating the local Windows XP security group, maintaining group membership and applying necessary permissions to application directories on the server.

Standard .MSI package settings for Network Applications

Network application (.MSI) packages for will be split into 2 packages. All Network Applications will have a Current User installation at a minimum. The need for a local machine .MSI package will vary based upon the nature of the application.

Current User installation

Defined as shortcuts, HK_CURRENT_USER registry entries and user specific configuration files/settings required for the Network application. The current user .MSI will be installed via SMS in the current user's context. Network applications will always have a Current User .MSI. If these files or paths can be redirected to the server then this would be the preferred best practice for a Network application installation. The current user .MSI files should be saved with a CU (current user) following the application name and version.

Local Machine installation

Defined as HKLM and HKCR registry entries, system environment variables and files located on the local drive were all user scenarios do not have sufficient access (i.e. C:\Program Files, %SystemRoot%..). The local machine .MSI would be installed via SMS using the SMS software distribution account and install using the ALLUSERS property. Depending on the configuration of the Network application, a local machine .MSI does not have to be created for all network applications. If the files or paths can be redirected to the server then this would be the preferred best practice for a Network application installation. The local machine .MSI files should be saved with a LM (local machine) following the application name and version.

• The following registry key will be defined in the network application package:

  HKEY_CURRENT_USER\Software\SET

  Name	Type	Data
  Network Applications	REG_SZ	1

  This registry key will reside in the CurrentUser component and set with a condition to only install for the Current User .MSI packages.
• Shortcuts should be placed or moved to the CurrentUser component.
• Standard property name for specifying a working directory will be WRKDIRPATH.
• A standard property of LOCALMACHINE has been created to distinguish between the Current User and Local Machine .MSI packages.
• Standard custom actions have been created to set the ALLUSERS property accordingly and delete shortcuts from Start - Programs - Network Applications menu folder. The following table provides details of each custom action.

The additional custom actions for shortcuts are required to overcome a shortcoming in the Windows Installer 1.1 service. These custom actions will ensure that network application shortcuts are uninstalling consistently for all users of a workstation. This is a bug with the Windows Installer 1.1 service, which was corrected in the Windows Installer service 2.0 release.

Troubleshooting Utilities

Because of the user scenarios and various levels of security permissions, all applications will not run or function properly under all user scenarios. Most application problems are related to security permissions or older applications with specific environment problems.

Here are a few examples of application problems that can be encountered :

• Application tried to write to the root of c: at runtime
• Application has hard coded paths for install or for data files
• Application tries to write to HKLM\Software or some other restricted part of the registry at runtime
• Application tries to write to its own installation directory eg. \Program Files\appname
• Application tries to write anywhere below c:\WINNT

To combat these problems or at the very least to identify the areas where the application is failing, some analysis tools will have to be used to isolate the root cause of the problem. The tools listed below should be packaged and stored on \\servername\Wise Share Point\PackagingTools.

• FILEMON - a freeware tool that monitors the HD for any writes/reads while an application is running.
• REGCOMP - a registry comparison utility.
• REGMON - a freeware tool for monitoring the registry for create/open/delete requests by the system or a running process or application.
• SCRIPTIT - a utility to start a process, monitor active windows and processes, send keys to open windows, etc.
• SNAGIT - a screen capture tool.
• Windows XP Support Tools - contains the Windows XP support tools such as Dependency Walker which is invaluable for tracking DLL dependencies.
  To fully understand the analysis process, two of the tools above are explained in greater detail below.

FILEMON and REGMON:

These two tools will probably be used in conjunction with each other when tracking problems with applications. Both of these utilities must first be run as an Administrator before logging in as a Workstation user to use them. This will enable the tools to be properly registered and the necessary files copied to a folder that in the environmental path.

Once logged in as a workstation user, run both of these tools by using the RunAs command tool launch tools using an Advanced user account. You will see a mass of entries appearing and so you must start to carefully place a filter on them to exclude unnecessary processes from being captured. Processes such as rvtscan.exe, system, winlogon.exe, explorer.exe are common exclusions however, exclusions it will always be dependent upon the application. One important thing to put in the highlight section of the filter is ACCDENIED in Regmon and ACCESS DENIED in Filemon, as these error messages will isolate the root cause for the application failure.

Once the problem areas have identified in either the registry and\or the file system for an application to run as a Workstation user, log in as an administrator on the workstation and grant modify or full control permissions to the appropriate locations. Permissions should not be granted directly to the following file system or registry locations:

• Restricted Areas within the Registry and File System

  • Registry

    • HKEY_LOCAL_MACHINE\SOFTWARE
    • HKEY_LOCAL_MACHINE\HARDWARE
    • HKEY_LOCAL_MACHINE\SYSTEM

  • File System

    • C:\
    • C:\APPS
    • C:\APPS\DATA
    • C:\PROGRAM FILES
    • C:\WINDOWS
    • C:\WINDOWS\SYSTEM
    • C:\WINDOWS\SYSTEM32

Below are some samples of FILEMON and REGMON captures:

FILEMON

16:36:04	MSACCESS.EXE:1016	IRP_MJ_CREATE	C:\program files\CompanyNameInduction\Cresentsys.mdw	ACCESS DENIED	Attributes: N Options: Open 	
16:36:04	MSACCESS.EXE:1016	IRP_MJ_CREATE	C:\program files\CompanyNameInduction\Cresentsys.ldb	ACCESS DENIED	Attributes: N Options: OpenIf 	
16:36:14	MSACCESS.EXE:1016	IRP_MJ_CREATE	C:\program files\CompanyNameInduction\Cresentsys.mdw	ACCESS DENIED	Attributes: N Options: Open 	
16:36:14	MSACCESS.EXE:1016	IRP_MJ_CREATE	C:\program files\CompanyNameInduction\Cresentsys.ldb	ACCESS DENIED	Attributes: N Options: OpenIf 	
16:36:14	MSACCESS.EXE:1016	IRP_MJ_CREATE	C:\program files\CompanyNameInduction\cresent.mdb	ACCESS DENIED	Attributes: N Options: Open 	
16:36:14	MSACCESS.EXE:1016	IRP_MJ_CREATE	C:\program files\CompanyNameInduction\cresent.mdb	

REGMON

1193	89.72615961	BUSOBJ.EXE:764	EnumerateValue	HKLM\System\CurrentControlSet\Control\Nls\Locale\00000408	SUCCESS	""	
1194	89.72618503	BUSOBJ.EXE:764	EnumerateValue	HKLM\System\CurrentControlSet\Control\Nls\Locale\00000409	SUCCESS	"1"	
1195	89.72622330	BUSOBJ.EXE:764	QueryValue	HKLM\System\CurrentControlSet\Control\Nls\Language Groups\1	SUCCESS	"1"	
1196	89.72627108	BUSOBJ.EXE:764	QueryValue	HKLM\System\CurrentControlSet\Control\Nls\Locale\00000409	SUCCESS	"1"	
1199	89.73104263	BUSOBJ.EXE:764	CloseKey	HKCR\CLSID	SUCCESS	Key: 0xE25E2FE0	
1200	89.73108146	BUSOBJ.EXE:764	CloseKey	HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer	SUCCESS	Key: 0xE2659B20	
1201	89.73245678	BUSOBJ.EXE:764	CloseKey	HKLM	SUCCESS	Key: 0xE129F5A0	
1202	89.73255512	BUSOBJ.EXE:764	CloseKey	HKLM\SOFTWARE\Business Objects\BusinessObjects\5.0\BusObj Configuration\General\Directories\User Library	SUCCESS	Key: 0xE2618C40	
1203	89.73259004	BUSOBJ.EXE:764	CloseKey	HKLM\SOFTWARE\Business Objects\Shared\General\5.0\Directories\Document	SUCCESS	Key: 0xE277C8A0	

Once the appropriate permissions have been applied, log in as a Workstation user and test the application functionality. The necessary permission changes should be clearly documented in the Appname.txt file for the application package.

.MSI to .WSI Conversion (Other Tools are Available on this Menu)

Use the MSI to WSI Conversion Wizard to convert existing .MSI files to Wise project (.WSI) files. Typically, .MSI files are redistributable installation files that contain compressed files. These files generally do not have associated source paths. Project files compiled into an .MSI, do not contain compressed files but instead contain paths to source files. This process may be necessary if the application is not currently installed on the workstation but the source files and paths are needed to make adjustments to the .MSI.

To convert a .MSI file to a .WSI file and extract source files, do the following:

1. Open the .MSI package in Windows Installer Editor.
   
   

   Click to view.

2. Select Tools menu option, and then select MSI to WSI Conversion...
   
   

   Click to view.

3. In the MSI to WSI Conversion Wizard, enter the New Source Directory for files to be extracted.
4. Click Next
   
   

   Click to view.

5. On the File Sources screen, review the new source path location and use the Change Path button to alter the source path location if necessary.
6. Select the location of the WSI file to be created, Click Finish to Create WSI File.

The files will be extracted to the appropriate location and a .WSI will be created.