Modifying the Setstart Client Installation Script

Sometimes you can automatically migrate the existing low risk programs using the PGC Migration Wizard, but at other times you need to create a new client installation script. The Setstart client installation script sets up shortcuts on the desktop or Start menu that run the application from the distribution point where Setstart is found. The wizard uses Setstart to migrate programs. You can use the script to create a new configuration command line or customize it to provide any other client-side modifications you need. You can use these client installation scripts within the manual migration sequence of the wizard, or you can use them to re-create the programs in SMS 2.0.

If your application requires registry changes or other changes on the client, you can edit Setstart.ipf within SMS Installer to add any necessary client modifications that are not already included. Or, you can use any of a variety of packaging and scripting tools to create client and server setup programs for these applications, using the concepts and suggestions described in this chapter.

  To open the Setstart client installation script in SMS Installer

1. Install the SMS Installer from the \\<SiteServer>\SMS_<SiteCode>\SMS_Inst\<Platform> directory of your SMS site server by running the Smsinstl.exe program.
2. Launch the SMS Installer from the Start menu by selecting Programs, Microsoft SMS Installer, Microsoft SMS Installer 32.
3. Open the Script Editor mode.
4. Open the Setstart.ipf file from the %BORK%\SMS\PGCMigWz directory on your Microsoft BackOffice 4.5 Resource Kit installation.

   Set up SMS Installer on a reference computer if you want to use the script for software distribution.

These steps prepare you to examine the Setstart client installation script, or to modify it to create a custom script for your application. For more information, see Chapter 13, “Creating Self-Extracting Files with SMS Installer,” in the SMS 2.0 Administrator’s Guide.

Whenever you create a server-based application using Setstart.ipf, you need to create it so that these concepts, explained in the following sections, are taken into account:

• Server-based file references
• Removal support for clients
• User and system-specific references
• Repeated installations

Managing Server-Based File References

When a user runs a shared application on a distribution point, you start the application from the client computer, but the application is run from within the package directory on the distribution point.

When you create or modify client installation scripts for an application, be sure the following conditions are met:

All references to the application’s location refer to the application image on the distribution point.

When clients run the application, the directory from which the application runs is usually set to the application image on the distribution point. All command lines must point to the directory where the application runs, including the command lines of any shortcuts that you create. Otherwise, the application will not be able to find auxiliary files. For that reason, if you use Setstart, then Setstart must be in the directory where you want the application to run.

The Setstart client installation script points the command lines to the directory on the distribution point where Setstart is found by using the EXEPATH variable. This variable is set to %INST%, which is an internal SMS Installer variable containing a path to the directory that contains the Setstart script that is executing. Setstart takes advantage of the fact that the installed application files are in the same directory as the Setstart script.

The following excerpt from the Setstart client installation script shows how these references are handled for paths from the start menu and paths from program groups:

If CL_GROUP Equals (Ignore Case) "Start" then    Set Variable CL_GROUP to %CSTARTMENUDIR%    Create Shortcut from %EXEPATH%\%CL_EXE% to         %CL_GROUP%\%CL_NAME%.lnkElse    Add Icon "%CL_NAME%" to Program Manager Group "%CL_GROUP%"    Command: %EXEPATH%\%CL_EXE% %CL_ARGS% Icon %CL_ICON% Dir: %CL_DEFDIR%End Block

All files that must be local to the client are copied to the client, and all their file references must resolve correctly.

Any files that must be local to the client should be copied to the client computer, and depending on how the application accesses them, they must be referenced by full path names or included in the user’s %PATH% environment variable.

All necessary OLE and file associations have been registered.

Set up the required file associations and OLE registrations within the client installation script. The SMS Installer includes the Set up Associations option on the Associations tab of the User Configuration Attribute that can set up file associations. It also includes the Change registry on target computer option on the Registry tab of the User Configuration Attribute that can change the target computer’s registry. You can modify Setstart to include any modifications you need.

If the setup requires a drive letter connection to the distribution point and then references that drive letter in its pointers to the application image, force a persistent drive letter connection to the package on the distribution point. (Applications requiring a specific drive letter connection fail to run if the drive letter is not available or is not connected to a proper server.)

  To set the drive letter option

1. Navigate to Programs under the package in the SMS Administrator console.

Systems Management Server   Site Database (site code - site name)      Packages         package            Programs

2. Right click on Programs. In the Program Properties dialog box, click the Environment tab and select Requires specific drive letter. Also select the Reconnect to distribution point at logon option.

   This option causes Windows to reconnect the drive at each logon. Be careful to coordinate drive letter mappings with other programs that require a specific drive letter, such as logon scripts.

Setting Up Removal for Client Applications

When you create client programs for software distribution, consider whether you want these programs to remove themselves when you no longer need them. These programs can only remove themselves if you create an uninstall script. Create this script using the SMS Installer or other installation tool, or use a text editor. You must register the uninstall program with the Add/Remove Programs mechanism in the client registry. This task can be done within the client installation script.

When you set up the removal process, make sure that:

The program registers itself with the Add/Remove Programs mechanism in the client registry.

For the program to be removed when it is no longer advertised, you must create a key for it under \HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Current Version\Uninstall as directed in the Microsoft Windows 95 logo program. The program must create an UninstallString value with the command line to be executed for removal of the program. If the program is not appropriate for display in the Add/Remove Programs control panel applet, you can create an equivalent QuietUninstallString value instead.

Although it is not required, the uninstall command line should usually be unattended and silent.

The SMS Installer (like most installation script tools) automatically creates the necessary registry keys for program removal and also creates the uninstall script. As the Installer setup script such as Setstart executes, it writes each command it performs to a log file. This log file is then used to create the uninstall script (Uninstal.ipf) by undoing all the actions that were done by the installation script. The default uninstall script is stored in the Uninstal.ipf (Uninstal.exe) file.

When you have an uninstall key and an uninstall program, you can set up the removal process in the SMS Administrator console in the Advanced tab of the Program Properties dialog box. Select Remove software when it is no longer advertised and enter the uninstall key in the Uninstall Registry Key textbox. You should perform this step for each SMS software distribution program that you install on clients that should have uninstall support.

The uninstall command line and all files required for removal must be local to the client.

Everything required to remove the application from the client must be local to the client in order to successfully remove the application. The application cannot be dependent on any files on the distribution point for its removal. An application’s removal from the client is triggered when there are no advertisements remaining for the application. In many cases, the package information and package source files have already been removed from the client access points (CAPs) and distribution points before the client detects that the advertisement has been revoked. SMS Installer Uninstall scripts always use only local resources for uninstalling, as long as the install script is local.

Handling User-Specific and System-Specific Requirements

User-specific requirements are client-side modifications that must be executed once by each user who logs on to the computer; for example, creating entries under HKEY_LOCAL_USER in the registry, or setting up user-specific Start menu entries or shortcuts on the desktop. System-specific requirements are modifications that need to be executed only once on each client; for example, installing a set of DLLs on the computer or creating entries under HKEY_LOCAL_MACHINE in the registry. When applications are installed on servers but run from clients, some modifications to the clients are user-specific, while others are system-specific.

Each SMS software distribution program can be set to run once for each user or once for each computer.

  To set this option

1. Navigate to Programs in the SMS Administrator console.

Systems Management Server   Site Database (site code - site name)      Packages         package            Programs

2. Right click, select the Program Properties dialog box, and then choose the Advanced tab. Then, set Run once for first user who logs on or Run once for every user who logs on as the value for When program is assigned.

You must set up user-specific and system-specific modifications in separate programs, since the When program is assigned setting applies to the entire program. However, you can coordinate the execution of the two programs on clients by setting the user-specific program to have a dependency on the system-specific program.

When the user-specific program is executed on the client, if the system-specific program has not been previously executed on the client, it runs prior to the user-specific program. Each program can be set to run in either the logged-on user’s context or a local administrator context.

Typically, the dependent and depended-upon programs will be in the same package, but you can also create dependencies on programs within other packages. The depended-upon program must be on distribution points available to the client running the dependent program. If you do create dependencies on other packages, ensure that all required packages will be available to the clients. If a depended-upon program cannot be executed, the dependent programs are not executed.

To set up dependent programs for user-specific and system-specific modifications, create a program for user-specific modifications and a second program for system-specific modifications. Then, in the Program Properties dialog box of the dependent program (the user-specific modifications, the one you want to run last), select the Advanced tab and select Run another program first.

Allowing Repeated Installations

Sometimes you need to set up a client installation script to be repeatedly installed when distribution points change or when applications are repaired. In such cases, you must make sure that if the client installation script is repeatedly run, the references to the application image are rewritten to the current distribution point.

For example, by default the client always executes the application from the distribution point. You can set up a recurring assignment for the client installation script itself, such as once per day at logon, to force the client to re-select a distribution point each time the client installation script is executed. Using this method gives the following benefits:

• Provides limited fault tolerance by avoiding distribution points that are currently unavailable.
• Provides ongoing load balancing.
• Adjusts clients based on changes to the distribution point list.
• Performs continual verification of the application’s proper setup on the desktop.

If the client installation script provides suitable behavior when run repeatedly, and the program is assigned (mandatory) to clients, you can specify that the setup program reruns at intervals by setting up a recurring assignment schedule.

A recurring assignment (such as, once per day) can also be combined with an event-driven assignment (such as, at logon) to create a recurring event-driven assignment (such as, run at logon once per day). If more than one logon occurs during the day, the script would only be run once, and if no logon event occurred for several days, the script would wait to run until the next logon event occurred. If you set up a recurring assignment, disable the countdown dialog box on clients.

  To disable the countdown dialog box

1. Navigate to Client Agents in the SMS Administrator console

Systems Management Server   Site Database (site code - site name)      Site Hierarchy         site code - site name            Site Settings                Client Agents

2. Right-click and then select Advertised Programs Client Agent. In the Properties dialog box, on the Notification tab, clear Provide a countdown.