Automating Application Objects

The final step in setting up the application distribution environment is automating Application objects. Automating Application objects is the process of setting up scripting, scheduling, and macros to remove required interaction with Application object distribution. This step is optional; however, you might want to use some of the following options to make the application distribution seamless for users.

Manage Application Object Macros

One way to automate Application objects is to use the Macros property page to manage the Application object macros that you create expressly for this Application object and that are used on other property pages of the Application object. You can use all types of macros (including Application object macros) in the following Application object locations:

• Path to Executable (Identification property page)

• Command Line (Environment property page)

• Working Directory (Environment property page)

• Mapping Path (Drives/Ports property page)

• Capture Port Path (Drives/Ports property page)

• Registry Settings Property Page: Key, Name, Value (String only)

• .INI Settings Property Page: Group, Name, Value

• Application Files Property Page: Source/Target, Directory

• Text Files Property Page: Find and Add String

• Icons/Shortcuts Property Page: All locations

Tip

You can put macros within macros. For example:

%TARGET_PATH%=%*WINDISK%\Program FilesEMAIL_ADDRESS=[e-mail].

To access the Macros property page, use the following steps from within ConsoleOne:

1. Right-click the Application object and click Properties.

2. Click the Common tab and select Macros from the drop-down menu.

3. Click Import. Browse and highlight the Application Object template (.AOT or .AXT) file that you created with snAppShot, and then click Open.

   Or click Add and then String to create a new macro template entry. Name the macro and include a value, and then click OK.

   Or click Add Then Prompted and then either String or Drive to create a new macro template entry. Name the macro and include a default value and prompt string, and then click OK.

Tip

For best results, use a UNC pathname for the source path rather than a mapped drive. If you use a mapped drive letter as the source drive, some files might not copy correctly.

Prompted Macros

One way to automate Application objects is to use the Macros property page to set up special prompted macros. Sometimes the user has a different system setup than what the administrator expects.

For example, users might want to place an application on a different drive than what was described in the Application object. Prompted macros enable the administrator to request that the users be prompted for the information. By using the prompted macros feature, the administrator can request the destination drive from the users so that the resulting distribution goes to the specified drive.

To set up prompted macros, access the Macros property panel. Select Add, Prompted, String from within ConsoleOne. A window similar to the one shown in Figure 7.8 is displayed. From the prompted macro window, you can set up the following options for the macro:

• Prompt text Textual information to be displayed to the user when prompting for the macro.

• Macro name Name setup for the macro for install scripts, and so on.

• Default value You can specify a default value for the macro.

• Minimum disk space You can specify a minimum amount of disk space required in setting the macro.

• Maximum string length You can use this option to specify the maximum number of characters allowed for string macros.

Figure 7.8. The prompted string macro property window for Application objects in ConsoleOne.

Special Windows Macros

Another way to automate application distribution is by using special Windows macros. A special Windows macro is one that defines Windows 98 and Windows NT/2000/XP directories. The typical paths are based on default installations and might not match your specific setup. On Windows 98 workstations, macros behave differently if User Profiles are enabled.

The following macros are very helpful for redirecting application files that expect Windows directories to be in a particular location:

%*WinDir% Windows directory, typically c:windows or c:winnt%*WinSysDir% Windows system directory, typically c:\windows\system or c:\winnt\system32%*WinDisk% Drive letter (plus colon) for Windows directory, typically c:%*WinSysDisk%Drive letter (plus colon) for Windows system directory c:%*WinSys16Dir% Windows NT** 16-bit system directory (c:\winnt\system)%*TempDir% Windows temporary directory (c:\windows\temp)

Note

The asterisk character (*) is required syntax for these macros. Don't confuse these asterisk characters with the Novell trademark asterisk.

Login Script Variables

Another way to automate application distribution is by using login script variables. Application Launcher supports the familiar or traditional login script variables; however, not all login script variables are supported.

Table 7.3 displays a list of supported login script macros and what they mean. Alternative macro names are shown in parentheses.

Table 7.3. Login Script Macros

LOGIN SCRIPT MACRO	DEFINITION
DAY2	Numeric day of the month. For example: 01, 10, 15, and so on.
FILESERVER (FILE_SERVER)	Name of the NetWare file server of eDirectory* monitored connection. For example: APPS_PROD.
FULL_NAME	Full name attribute of the User object. For example: Jane Doe.
HOUR24 (24HOUR)	Time of the day according to a 24-hour clock. For example: 02, 05, 14, 22, and so on.
HOUR (HOURS)	Hour of the day. For example: 0 = 12, 13 = 1, and so on.
LAST_NAME	Last name of the current user (also known as the user's eDirectory Surname attribute).
LOGIN_NAME	First eight bytes of the user's eDirectory object name. For example: jsmith.
MINUTE (MINUTES)	Current minute. For example: 02, 59, and so on.
MONTH	Current month number. For example: 01 for January, and so on.
NDAY_OF_WEEK	Numeric day of the week. For example: 1 for Sunday, and so on.
NETWORK (NETWORK_ADDRESS)	Workstation network address. For example: 01010120.
OS_VERSION	Version of the OS. For example: v5.00. (Win3 shows DOS version, Win 98 and NT/2000/XP shows Windows version).
OS	OS type. For example: MSDOS, WIN98, WINNT, and so on. (Win3 shows MSDOS.)
PLATFORM	Platform running. For example: WIN, W98, WNT and so on.
PHYSICAL_STATION (P_STATION)	MAC address. For example: 0000C04FD92ECA.
REQUESTER_CONTEXT	Context of the requester (for the selected tree).
SECOND (SECONDS)	Number of seconds. For example: 03, 54, and so on.
SHORT_YEAR	Short year number. For example: 97, 00, and so on.
WINVER	Windows version. For example: v3.11, v4.00, and so on.
YEAR	Full year number. For example: 1997, and so on.

eDirectory Attribute Macros

Another useful tool in automating application distribution is using eDirectory attribute macros. Application Launcher supports macros that pull information from the attributes of the currently logged-in user, the current Application object, or from the attributes of other eDirectory objects.

An example of using eDirectory attribute macros is a GroupWise* Application object that runs OFWIN.EXE with a command-line parameter:

/@U-@USERNAME@

USERNAME can be replaced with a macro that uses a user's eDirectory* common name (CN):

/@U-@%CN%@

If the eDirectory object name is the same as the e-mail login for GroupWise, every user who runs the application has the correct username passed into GroupWise.

Table 7.4 displays variables that are defined by an attribute in an eDirectory object that can be used as eDirectory attribute macros.

Table 7.4. eDirectory Attribute Macros

ATTRIBUTE MACRO	EDIRECTORY OBJECT ATTRIBUTE
%CN%	Common Name (user's object name or login name)
%DN%	User's Full Distinguished Name (used with Application Launcher only)
%Given Name%	Given Name
%Surname%	Last Name
%Full Name%	Full Name
%Telephone Number%	Telephone
%Home Directory%	Home Directory
%Email Address%	E-mail Address
%Mailbox ID%	Mailbox ID

Environment Variables

Another useful tool in automating application distribution is using environment variables. The following are some examples of environment variables that Application Launcher supports:

• %NWLANGUAGE%

• %TEMP%

• %PATH%

Note

The value of the variable must not exceed the length of the Application object name; otherwise, the variable fails.

Schedule Application Pre-Install

Another useful tool in automating application distribution is to schedule application pre-install. Earlier in this chapter, you read about using the Pre-Install property panel for Application objects to set schedules of when the application will be pre-installed to the workstation. Set up large application distributions to be pre-installed in advance so that the objects are locally available to users. This provides you with the following safeguards:

• Low network bandwidth can't inhibit deployment of the application.

• You know for certain that all workstations are set up and ready to deploy the application.

• You don't need to stagger workstation installs over a period of time, making the transition much easier for users.

Schedule Application Availability

Another useful tool in automating application distribution is scheduling application availability. Earlier in this chapter, you read about using the Scheduling property panel for Application objects to set schedules of when the application is available. You can use this to help automate when users can access the Application object.

Create Application Scripts

Another useful tool available to automate application distribution is the use of the Scripts property page to set up scripts that are executed automatically each time the application is launched and closed. Unlike environment parameters, scripts can overwrite existing drive mappings and printer ports.

The two types of application scripts are the startup script and the post-termination script. Run before launching (or startup) scripts are executed after the environment is set and before the application is launched. Run after termination (or post-termination) scripts are executed after the application is closed and before the network resources are cleaned up.

The following are some examples of how you can use application scripts:

• To provide extra mappings beyond those defined on the Drives/Ports property page

• To provide a mapping to override another mapping

• To run other applications

• To log in to other servers or eDirectory* trees

• To terminate applications under certain circumstances

The following are examples of script syntax:

#ipconfig.exe /renew

This example runs the ipconfig application to renew the DHCP configuration, pausing the script processing until Calculator returns control.

@ ipconfig.exe /renew

This example runs the ipconfig application to renew the DHCP concurrently with the remainder of the script processing.

To create Application object scripts, use the steps listed in the "Creating Pre-Install Scripts and Launch Scripts for Application Objects" section, earlier in this chapter.

Tip

Clean-up commands (for cleaning up the changes made by the pre-launch script) should be placed in the post-termination script. The post-termination script is run after Application Launcher detects that the application has terminated.

The following is a list of scripting commands that Application Launcher does not support:

• CLS

• DISPLAY

• EXIT

• FDISPLAY

• INCLUDE

• LASTLOGINTIME

• NO_DEFAULT

• NOSWAP

• PAUSE

• PCCOMPATIBLE

• SCRIPT_SERVER

• SET_TIME

• SWAP

• WRITE

The following is a list of actions that Application Launcher scripting does not perform:

• Output anything to the screen

• Display errors

• Pause