Site hosted by Angelfire.com: Build your free website today!

< href="index.html">Return to Table of Contents

Chapter 9

Configuring Network Applications for Users

Certification Objectives *

From the Classroom *

Networked Applications and Search Drive Mappings *

NAL Features *

Enabling NAL *

snAppShot Basics *

Simple vs. Complex applications *

NDS Object and Property Rights *

Application Objects *

File system rights *

Certification Objectives

Managing applications on an enterprise network can be a difficult business. When it comes to an application upgrade, manually upgrading each workstation requires time for each one, and as the numbers of workstations increase the distribution time for the application increases. Keeping the application installation method and components consistent across large numbers of client workstations is nearly impossible when the installation is manual. When the software manufacturer creates a patch to the software, the administrator must distribute that as well. This leaves the network in various stages of application versions. Which, in turn, causes support problems for help desk staff.

Z.E.N.works includes the NetWare Application Launcher (NAL) to address these issues. NAL includes the ability to:

From the Classroom

Networked Applications and Search Drive Mappings

Before NAL was introduced by Novell in NetWare 4.11, network administrators had to worry about running out of search drive mappings and configuring each workstation to properly run applications. Because the number of network search drive mappings is limited to sixteen, writing login scripts can become complex, if not convoluted, to accommodate the applications needs of users. Fortunately, any applications launched through NAL do not require a search drive mapping to the directory containing the executable, and as a matter of fact, can accessed from another server altogether if load balancing or fault tolerance are enabled. NAL has relieved the administrator from being concerned about the limit on network search drive mappings.

—By Dan Cheung, CNI, MCNE, MCT

Introduction to the NetWare Application Launcher (NAL)

NAL offers a software delivery process secured by and centrally managed through NDS. The administrator uses NetWare Administrator to create and distribute applications. The end user uses the NetWare Application Launcher to access and execute those applications.

Users find NAL very easy to use. The application does not appear in the NAL window unless the user has been associated to the application object in NDS, or inherited that association. In addition, the application icon only appears that is specific to the workstation operating system.

For example, if a user moves between a Windows NT workstation and a Windows 3.1 workstation, the applications in NAL when he uses Windows NT will be only those that the administrator has specified for distribution to NT workstations. The applications in NAL when he is using Windows 3.1 will not include any of the Windows NT specific applications, but may include other applications that were specified for Windows 3.1. This intelligence prevents users from complaining about an application failure when the application should have failed.

Users only have to double-click an icon in the NAL window to launch the application. If the application does not launch, the user can click the File menu and select the Verify option. The Verify option will display any configuration errors with the application object, as in Figure 9-1.

Figure 1: Verify Message

The application icons in the NAL window represent the application objects in NDS. Each application object includes information about drive mappings, printer captures, application switches, etc. The administrator can deliver new applications simply by creating application objects and configuring them in NetWare Administrator, which continues as the single seat of administration.

The NAL application is SYS:PUBLIC\NAL.EXE. It can be executed as part of the login script. Figure 9-2 displays the NAL window.

Figure 2: NAL Window

NAL Features

NAL features the following capabilities:

Software distribution is the ability for network administrators to push or pull applications to desktop workstations. Pushing an application is installing an application in an unattended manner (e.g. requiring no one to select options during installation) over a network to a workstation. Pulling an application is installing an application over a network to a workstation in an attended manner, by having the person at the workstation prompt for installation and/or select options during installation. Automated installation templates can be generated for custom applications through the use of snAppShot templates. Software distribution can be scheduled for after-business or off-peak hours, which enables management of the network bandwidth.

Administrators use NAL to manage applications. It offers the ability to modify registry entries, .INI files, create custom drive mapping and printer captures for the application, and return the workstation to its previous state (of drive mappings, etc.) after the application is exited. Applications are managed according to the operating systems that they are enabled for: Windows 3.1x, Windows 95, or Windows NT Workstation 4.0.

NAL uses the NetWare Administrator as the single seat of administration. Applications are created as application objects in the NDS tree in the same manner as other network resources.

NDS delivers security to applications, using NDS as the foundation. Users must be granted rights to the application object in order to use it.

Users mainly access NAL through its workstation component, the NAL window that displays the icons available to that user. If the administrator grants permission, users can extend the functionality of the NAL Window by creating personal folders, as in Figure 9-3. Users must have the ability to create personal folders granted to them in NDS. Then, it is a matter of the user selecting the NAL File menu and the New Personal Folder option, then typing in the name for that folder. Folders appear under the Personal icon and can be created in a tree configuration. Users can drag application icons from the right-pane and drop on the desired personal folder in the left pane of NAL to organize.

Figure 3: NAL Personal Folders

NAL.EXE uses a wrapper technology. It handles initialization and executes the correct program for the operating system. For example, a user at a Windows 3.1 workstation will execute NAL.EXE and it will execute NALW31.EXE, and then exit, leaving only NALW31.EXE to run. See Table 9-1 for the executables for each operating system.

As a wrapper, NAL selects which application icons to display for the user depending on the operating system currently being used. The wrapper also updates the files on the workstation from those in the SYS:PUBLIC\NALLIB directory. Local workstation files are only updated if the network version is newer than the local version.

Operating System

NAL launched Executable

NAL Explorer

Windows 3.1 NALW31.EXE N/A
Windows for Workgroups 3.11 NALW31.EXE N/A
Windows 95 NALW95.EXE NALEXPLD.EXE
Windows NT Workstation 4.0 NALWIN32.EXE NALEXPLD.EXE
Windows 98 NALWIN32.EXE NALEXPLD.EXE

Table 1: Operating Systems and Associated NAL Executables

The wrapper technology will not launch the NAL Explorer, which is an add-on to the Windows 95/98/NT4 Explorer. Instead the NALEXPLD.EXE application must be explicitly launched, but only for Windows 95/98/NT4. Windows 3.1x does not contain an Explorer interface. NAL Explorer shows the NAL applications directly in the Windows Explorer under the Application Explorer icon, which is added as a top-level folder, such as Figure 9-4 exhibits.

Figure 4: NAL Explorer

Enabling NAL

As a component of Z.E.N.works, NetWare Application Launcher is installed when Z.E.N.works is installed. After installation, the administrator must enable NAL for use by end-users.

When Z.E.N.works is installed, the NDS schema is extended to include properties for the NAL on Users, Groups, Organizational Units, Organizations and Country objects. There are two property pages that affect NAL:

Figure 5: Launcher Configuration

The default state for the Launcher Configuration is to not have any settings. In order to add a setting, the administrator would click Edit and select the options from the configuration dialog, then select the corresponding value. When exiting the dialog, these selections will appear in the Launcher Configuration property page.

In order to place application icons into the NAL window for users, the applications must be added to the Applications property page, shown in Figure 9-6. There are checkboxes on this page that configure where the applications will appear on the end-users’ desktops. Applications are, by default, placed in the Application Launcher window. They can also be placed on the Start Menu, the desktop or the system tray. In addition, the Applications page includes an option to force the application to run. The administrator must click the Add button and locate application objects for these applications to appear on this page.

Figure 6: Application Property page

Configuring NDS and the File System for NAL

Delivering applications to end-users is the main function for NAL. An application appearing in the NAL window depends on application objects being created, and the correct NDS and file system rights being applied so that they can be used. Creating an application can be done through the NetWare Application Launcher snAppShot, or by creating a simple application object in NDS. Further configuration is all handled in the NetWare Administrator, by editing properties of :

snAppShot Basics

Z.E.N.works installation creates the NAL snAppShot application object in NDS. The installing user object is granted access to the application, and when that installer runs NAL, snAppShot appears as an icon, as in Figure 9-7.

Figure 7: Z.E.N.works snAppShot Icon

SnAppShot simplifies the installation of applications that make changes to .INI files and the Registry. SnAppShot runs in the background on a client workstation while an application is being installed. {q6}During the installation, snAppShot records the changes that are made to the workstation’s configuration files, then stores the information in a binary Application Object Template (.AOT) file. The information that is recorded in the .AOT file consists of:

SnAppShot also records the new files added to the workstation, and stores them as .FIL files. The configuration information can be stored in an .AXT file. This is a text-based template that the installer can edit before the file is imported as an object into NDS.

Exam Watch: An .AOT file is an Application Object Template written in binary format and created by snAppShot. An .AOT file represents the changes made to the configuration files of a workstation during an applications installation.

SnAppShot uses a four step process for creating applications.

  1. First, snAppShot runs a discovery process to see what is on the workstation before the setup process is executed. This sets a baseline with which snAppShot can compare later.
  2. Second, the application is installed.
  3. Third, snAppShot runs a second discovery process to see what is on the workstation after the setup process is executed. This automatically prompts a comparison of the two discoveries.
  4. Fourth, snAppShot writes the .AOT file to store the configuration information.

Exercise 9-1 Running snAppShot on a 32-bit Application

  1. From the NAL window, double-click the Z.E.N.works snAppShot icon. You will see the dialog in Figure 9-8.

  2. Figure 8:Z.E.N.works snAppShot
  3. The Standard option will use Novell’s default options. The Custom option allows the administrator to specify drive mappings, registry information and other configurations as part of the installation. The Express option uses a previously created Preferences file for the configuration information. Select the Custom option.
  4. The next screen will prompt for the preferences file. Accept the snAppShot Default Settings by clicking Next.
  5. This screen prompts for an application object name and an icon title. When the first box is completed, the second one will default to the first name, however, these can be different, as in Figure 9-9. Click Next.

  6. Figure 9: Application Object name
  7. A box requesting a storage folder for the application files is prompted for next. This storage folder can be temporarily on the workstation, or on a server. Depending on how large the application is, and the size of the local server’s SYS volume, it is best not to place this folder on a SYS volume since it could cause SYS to run out of space, which can cause the server to stop functioning. After selecting a storage folder, click Next. If prompted to create the folder, click OK.
  8. A dialog will suggest placing the .AOT file in the storage folder and give it a default name, which is the same as the application object name. Click Next.
  9. The next screen prompts for the configuration information to capture during setup (Figure 9-10). By default all boxes are checked. It is recommended to retain these settings. Click Next.

  10. Figure 10: snAppShot configuration selections
  11. The next shot will state which drives to scan for file and configuration changes. The default drive letter is C:. Except in the case where the standard desktop configuration has multiple drives, or where program files are stored on the server, this is the correct setting. Click Next.
  12. In order to save Preferences as its own file, the administrator can click the Save Preferences button on the next dialog. Review the settings and click Next.
  13. SnAppShot will start scanning the configuration, as in Figure 9-11.

  14. Figure 11: snAppShot discovery process
  15. After scanning is complete, the snAppShot process will prompt to start the application installation, as in Figure 9-12. Click the Run Application Install button.

  16. Figure 12: Starting the Application installation
  17. From the dialog box, browse through the file folders and select the application setup executable. Install the application through the normal method. SnAppShot remains running in the background. When the application installation is finished, switch to the snAppShot screen and click Next.
  18. The first dialog displayed after that is to specify how the ini files, registry entries and folder and file entries should be handled—the default is to copy the entries always. Each setting should be reviewed for which action is appropriate. When finished, click Next.
  19. The next screen is to select the directory where files should be installed to on the workstation. There is no problem with leaving this blank. Complete this screen and click Next.
  20. Customizing the application for the installing user is the most difficult of installation actions. The next dialog allows this customization. For example, if asked during installation for an e-mail address and having typed in xyz@corp.com, the installer can click the ADD button and add E-MAIL ADDRESS to the variable name and xyz@corp.com in the variable to be replaced. When complete, click Next.
  21. SnAppShot completes the second discovery process and records the information to the .AOT file specified in step 6. When it is complete, snAppShot will display a summary with the success or failure of the discovery processes.

After the .AOT file is created, it can be imported into NDS as an object, then associated to a Container object or User or Group. Since the .AOT file is binary, it can be changed to a .AXT file, which is text-based in order to be edited. The administrator can import both .AOT and .AXT files into the NetWare Administrator as application objects. In order to change a .AOT file to a .AXT file, a tool is available in the NetWare Administrator under Tools | Application Launcher Tools | AOT/AXT File Tools | AOT _ AXT. The file can be changed back to an .AOT file using the same menu AXT _ AOT option.

Exam Watch: snAppShot performs a baseline discovery, the application installation, a post-installation discovery, comparison of the discoveries and writes an .AOT file with the configuration changes.

Simple vs. Complex applications

Simple applications are those that do not require any configuration file changes or supporting files such as .DLL files. An example of these applications is RCONSOLE.EXE included in NetWare 5. Setting up a simple application does not require snAppShot. Instead, the administrator creates an application object in NDS and then associates it to the User, Group or a container object.

Exam Watch: When an application is associated with a container object, or with a Group object, any user objects added later as members of the container object or the group automatically are granted access to the network application object through inheritance.

Complex applications are those applications that require any configuration file changes and files to be copied to the workstation. Complex applications require snAppShot.

Exercise 9-2 Create a Simple Application Object

  1. In NetWare Administrator, navigate to the context where the application will reside.
  2. Right-click the container object and select Create from the pop-up menu.
  3. Select Application from the Object Creation dialog box, and click OK.
  4. The application creation wizard starts. Select the first option for simple application creation (Figure 9-13). Click Next.

  5. Figure 13: Simple applications with application object creation wizard
  6. In the next screen, type in the name for the application object, and then state the path to the application executable. Note that the path should be in a universally accessible format, such as \\SERVER\VOL\PATH\APPLICATION.EXE.
  7. Click Next. The application object is created and ready for use.

NDS Object and Property Rights

When the network administrator installs Z.E.N.works, the administrator’s user object requires the Supervisor Object right to the NDS tree [root]. This is due to the fact that Z.E.N.works extends the NDS schema.

NDS rights are not required for accessing the application objects, however, associations are required for the application icons to appear in the NAL window. Associations are set on the User, Group, or container object Applications page. To enable an application for all users within a container object,

  1. Right click the container.
  2. Select details.
  3. Click the Applications property page.
  4. Click the Add button.
  5. Navigate the tree until the desired application objectis available in the left pane window.
  6. Click the application object, then click OK.
  7. The application object will appear in the Applications window.
  8. Select the options for the Application to launch from, or leave the default for the application to appear in the Launcher (NAL) window.

The Launcher can be further configured in NDS through the Launcher Configuration property page. The following are the defaults for Launcher configuration.

Configuration Option

Function

NDS Default

Allow Users to Exit Users can exit NAL Yes
Display Icon on Desktop Displays the Application Explorer icon on the desktop Yes
Display Start Menu Shows the Start Menu icons in the NAL window No
Enable Folder View Shows Folders in left pane Yes
Enable Manual Refresh Allows users to select F5 to refresh NAL and look for new applications Yes
Enable Personal Folders Allows users to create personal folders No
Enable Timed Refresh Automatically refreshes NAL to look for new apps No
Enable Log In Users are able to login from NAL File menu Yes
Expand Folder View on Startup Expands the tree view when NAL starts up No
Name Icon on Desktop Changes the application explorer icon name Application Explorer
Read Group Objects for Applications This option enables the user to read group objects for the associated application objects Yes
Save Window Size and Position Retains the window size upon reboot Yes
Set Application Inheritance Level Sets the number of the levels of tree to walk to look for applications 1
Set Refresh Frequency The number of seconds to wait between timed refreshes 3600 seconds
Specify E-Mail Attribute Sets the e-mail contact Mailbox ID

Table 2: Launcher Configuration options

The Set Application Inheritance Level affects NDS inheritance by limiting the number of levels that the tree is "walked" for custom settings. NDS Inheritance for NAL works in this manner:

  • NAL seeks configuration settings at the lowest object, the leaf object, or the lowest container object.
  • Then NAL walks the tree towards the [root], collecting the custom settings at each level.
  • NAL continues until it reaches an object that has been designated as the "top" of the inheritance tree.
  • When NAL finds a custom setting, it applies it. If it does not find a custom setting for an option, it uses the defaults shown in Table 9-2.

The administrator can designate an object as the top of the inheritance tree by selecting the option for Use Object as Top of Inheritance Tree on the object’s Launcher Configuration property page. When the Set Application Inheritance Level for a User object is set to 0, NAL does not look for application objects. When it is set to 1, NAL looks only in the immediate container for application objects. When set to 2 or higher, NAL will navigate the tree towards the [root] for that same number of levels. If the Set Application Inheritance Level is set to –1, then NAL always looks all the way to the [root].

Because applications can be applied to a user object through explicit association, or through the inherited applications from Group objects or parent container object, the administrator can not see all the applications at once within the user object, or the container objects. Instead, NetWare Administrator contains a tool to view the inherited applications.

Exercise 9-3: View the Inherited Applications for a User

  1. In NetWare Administrator, navigate the tree until the user object is displayed.
  2. Click the User object so that it is highlighted.
  3. Click the Tools menu
  4. Click Application Launcher Tools
  5. Select Show Inherited Applications.
  6. Click the plus signs next to the container objects displayed in order to view the application objects (Figure 9-14).

Figure 14: Displaying inherited applications
   

Application Objects

There are two NAL objects in the NDS schema:

  • Application folders
  • Application Objects

The administrator may wish to organize applications for the end-users in a hierarchical folder structure, which is much the same as a file directory structure. In order to do this, the administrator creates an Application Folders object in a container, then creates folders within the Folders property page in a tree structure. After the tree structure of folders is created, the administrator can add application objects to the folders. Once a folder is populated by an application object, it will appear in the NAL window (Figure 9-15).

Figure 15: Application Folder object

Application objects have an extensive list of properties. Many of these are directly related to the application’s configuration settings. Table 9-3 lists the application object properties.

Property

Property page

Function

Application Icon Title Identification Displays the title of the icon in NAL
Path to executable file Identification Represents the path and file for the application.
Install Only Identification Excludes the path to executable—is used with snAppShot to copy files to a local workstation.
Run Once Identification Utilizes a version stamp to add information to the HKCU\SOFTWARE\NETWARE\NAL in order to prevent the app from running more than once for that user.
Order Icons Identification Places this icon in a certain order in the NAL window
Icon Order Identification Identifies which place the icon is placed in the NAL window
Application Icon Identification Enables the administrator to change the icon used in NAL.
Operating System System Requirements Enables the administrator to select which operating systems will be allowed to execute this application.
Display icons on machines with RAM System Requirements Specifies the minimum amount of RAM required for the app.
Display icons on machines with free disk space System Requirements Specifies the minimum amount of free disk space required for up to three disk drives in order for the application to run on a workstation – useful for installation files.
Command line parameters Environment Specifies start-up switches for the executable.
Working directory Environment Displays the working directory used as the default for a File | Save.
Run Environment Selects the window size as normal, minimized or maximized.
Windows NT WOW Environment Selects a Shared (unprotected) 16-bit DOS virtual DOS machine (VDM) or Separate (protected) VDM session for Windows NT. If an application crashes in a Shared VDM, then all apps sharing it will fail at the same time.
Enable error logging to file Environment Specifies a file to be used as an error log.
Clean up Network Resources Environment NAL will clean up resources such as mapped drives and captured printers.
Monitor Module Environment When an executable uses a wrapper technology, such that one application spawns the next, the Monitor Module Name selects which executable to monitor for the network resource cleanup.
Show Distribution Progress Distribution Turns on a progress bar for the users when a new application is being distributed to a workstation.
Prompt user before distribution Distribution Allows a user to confirm the distribution of an application.
Distribute Always Distribution Forces the application to be distributed every time.
Prompt user for reboot Distribution Allows or disallows the user to confirm for a reboot
Use version stamp to trigger distribution Distribution If an administrator makes changes to an app, can redistribute those changes by assigning a later version number.
Folders Folders Allows the administrator to create a custom folder for the application, or link it to an application folder object.
Description Description Displays detailed, custom information about the application.
Drives Drives/Ports Enables custom drive mappings.
Ports Drives/Ports Enables custom printer captures.
Run Before Launching Scripts Allows the administrator to create a script using NetWare’s scripting language to execute prior to the application.
Run After termination Scripts Allows the administrator to create a script using NetWare’s scripting language to execute after the application exits.
Enable Load Balancing Fault Tolerance With multiple application servers, this option allows distribution of the application "load" across multiple servers.
Enable Fault Tolerance Fault Tolerance With multiple application servers, this option allows a different server to be selected if the initial one crashes.
Contacts Contacts User objects that are contacts for the application.
Associations Associations User, Group and container objects allowed to use the application.
Administrator Notes Administrator Notes Text field that is not viewable by users that can be used to track changes to the application object.
Macros Macros Customizable fields used in the distribution of the app.
Registry Settings Registry Settings Modifications to the registry are displayed, and can be edited, in this property page.
INI Settings INI Settings Modifications to .INI files are displayed, and can be edited, in this property page.
Application Files Application Files Files that are targeted to be copied to the workstation upon application distribution.
Text Files Text Files Modifications to text files are displayed, and can be edited, in this property page.
Schedule Schedule Enables restriction of times for the app to run. This can be used to keep distributions from occurring during peak network usage hours.
Icons/Shortcuts Icons/Shortcuts Used to specify which icons and shortcuts are placed on a workstation at distribution.
File Rights File Rights Enables custom file rights needed to run the application. The user will gain these rights during the application execution.
Termination Termination Enables a custom exit from an application, such as sending a message to the user to save their data before closing.
Application Site List Application Site List When an enterprise network consists of multiple sites that users travel between, the use of an application site list will enable the nearest server to a user to execute an application, rather than a static server.

Table 3: Application Object Properties

Application objects are the core of an application and the distribution of it. The application object properties can customize its behavior (Figure 9-16). Multiple application objects can be created for the same application, but simply be customized according to the application object settings in order for the application to work on different systems.

Figure 16: Application object properties

File system rights

When Z.E.N.works installs, it automatically places the NAL files in the SYS:PUBLIC directory of the servers on which it is installed. By default, all users are granted the read and file scan rights to this directory. However, in an enterprise network, the file system rights may not be set up for all file servers the same way. The administrator must ensure that NAL files are in a file server directory in which users have the Read and File Scan rights.

Exam Watch: Read and File Scan rights are required to execute NAL.EXE. NAL is installed to the SYS:PUBLIC directory by default during Z.E.N.works installation.

Each application object has a property page for File system rights (Figure 9-17). These file system rights are automatically granted to a user while that user is accessing that application. The administrator simply adds the rights required to the File Rights property page of the application object.

Figure 17: Application object file rights

Launching Network Applications with NAL

In addition to configuring NDS, the administrator must make sure that the correct file system rights are applied to the NAL files for users, and that NAL is executed from the correct login scripts. The login script syntax in a pure Windows environment (that is, Windows 3.1x, Windows 95/98, Windows NT 4), is @\\SERVER\SYS\PUBLIC\NAL.EXE. In a mixed environment, the administrator will want to specify an IF %PLATFORM="WIN95" THEN statement before the NAL executable line, and an END statement after, replacing WIN95 with WIN31 or WINNT or WIN98 for the other operating systems. The @ command is used instead of a # command, since it will allow the login script to continue process during the execution of the external command. The # command waits until the external command completes before going forward. Table 9-4 lists the NAL.EXE switches and their functions.

Switch

Syntax

Function

/a NAL /A=<application object distinguished name>
NAL /A=<tree>;<application object distinguished name>		 Runs the specified application. If NAL is not running, it is started minimized while the app runs.
/c NAL /C="Customized Title" NAL loads with a title bar using this display
/h NAL /H Hides NAL while running
/min NAL /MIN Runs NAL minimized
/max NAL /MAX Runs NAL in full screen
/norm NAL /NORM Runs NAL in normal screen window
/s NAL /S Makes NAL the OS shell, displaying shutdown instead of exit
/u NAL /U Unloads NAL after all NAL launched apps have exited
/u! NAL /U! Unloads NAL and leaves any NAL launched apps open

Table 4: NAL Switches
Tyler has implemented NAL on his network, and has created a container login script with the line: NAL /C="NetWare Secured Programs for Tyler". An error occurs with the line, and when Tyler fixes that error he finds that everyone has his name on his or her title bar. What did Tyler do to fix the original error, and how can he fix the name problem? Tyler realized that NAL was not being executed as an external command. He changed the line to @\\SERVER\SYS\PUBLIC\NAL /C="NetWare Secured Programs for Tyler". In order to change the name problem, Tyler should write the following command: @\\SERVER\SYS\PUBLIC\NAL /C="NetWare Secured Programs for %FULL_NAME".

From the end-user’s perspective, the NAL window is automatically launched upon login when NAL is executed from a login script. The user simply navigates through folders in the left pane of the NAL window, if folders have been enabled. Upon finding the application, the user can double-click selected applications in the right pane in order to execute the application.

Certification Summary

NetWare Application Launcher (NAL) is the component of Z.E.N.works that handles application management and software distribution. NAL centralizes application administration by creating application objects in Novell Directory Services (NDS). The application objects can then be secured using NDS Security.

NAL is installed as a component of Z.E.N.works. Users will require the Read and File Scan file system rights to the NAL files. Applications will need to be created and associated to container objects, groups or user objects.

SnAppShot is the application included with NAL that is used to configure applications for software distribution. SnAppShot uses the following steps:

  1. Discover the baseline "pre-installation" configuration
  2. Install the application
  3. Discover the "post-application" configuration and compare
  4. Write the configuration information to a .AOT file.

The information stored in an .AOT file is registry settings, .INI file changes, text file changes, macro information, files and folders to be copied. The .AOT file is a binary file. It can be transferred to a .AXT file which is text based, and vice versa. The tools for file conversion are in the NetWare Administrator.

There are two types of applications: simple and complex. A simple application is one that does not require any configuration on the workstation in order to run. A complex application may require registry entries, INI file changes, text file changes and multiple files to be copied. Creating an application object in NDS is done with the application object creation wizard. This is initialized in the NetWare Administrator.

The container object, User and Group objects all have NDS properties that are related to NAL. These are located in the Launcher configuration page and the Applications property page. These properties are inherited from the lowest leaf object and walked up the tree towards the [root]. Inheritance can be controlled through the Set as Top of Inheritance Tree or Set Application Inheritance Level in these property pages.

The application object and the application folder object are both NDS schema extensions for NAL use. The application folder object is used to organize applications in the NAL window for end users. The application object includes configuration information for applications. Multiple application objects can be created for a single executable file.

NAL.EXE has multiple switches used to configure how the NetWare Application Launcher is executed. These switches can be used in a login script. Launching an application can either be done from the command line or by double-clicking application icons in the NAL window.

Two-Minute Drill

  • NAL offers a software delivery process secured by and centrally managed through NDS. The administrator uses NetWare Administrator to create and distribute applications. The end user uses the NetWare Application Launcher to access and execute those applications.
  • An application does not appear in the NAL window unless the user has been associated to the application object in NDS, or has inherited that association. The application icon only appears that is specific to the workstation operating system.
  • Users double-click an icon in the NAL window to launch an application. If the application does not launch, the user can click the File menu and select the Verify option. The Verify option will display any configuration errors with the application object. If the administrator grants permission, users can extend the functionality of the NAL Window by creating personal folders.
  • The application icons in the NAL window represent the application objects in NDS. Each application object includes information about drive mappings, printer captures, application switches, etc. The administrator can deliver new applications by creating application objects and configuring them in NetWare Administrator.
  • Software distribution is the ability for network administrators to push or pull applications to desktop workstations. Automated installation templates can be generated for custom applications by using snAppShot templates. Software distribution can be scheduled for after-business or off-peak hours, which enables management of the network bandwidth.
  • NAL offers the ability to modify registry entries and .INI files, create custom drive mapping and printer captures for the application, and return the workstation to its previous state after the application is exited. Applications are managed according to the operating systems that they are enabled for.
  • NDS delivers security to applications, using NDS as the foundation. Users must be granted rights to the application object in order to use it.
  • NAL.EXE uses a wrapper technology. NAL selects which application icons to display for the user depending on the operating system currently being used. The wrapper also updates the files on the workstation from those in the SYS:PUBLIC\NALLIB directory. Local workstation files are only updated if the network version is newer than the local version.
  • NetWare Application Launcher is installed when Z.E.N.works is installed. After installation, the administrator must enable NAL for use by end-users.
  • When Z.E.N.works is installed, the NDS schema is extended to include properties for the NAL on Users, Groups, Organizational Units, Organizations and Country objects. There are two property pages that affect NAL: Launcher Configuration, and Applications.
  • The main function for NAL is delivering applications to end-users. An application appearing in the NAL window depends on application objects being created, and the correct NDS and file system rights being applied so that they can be used.
  • Z.E.N.works installation creates the NAL snAppShot application object in NDS. The installing user object is granted access to the application, and when that installer runs NAL, snAppShot appears as an icon.
  • SnAppShot simplifies the installation of applications that make changes to .INI files and the Registry. SnAppShot runs in the background on a client workstation while an application is being installed. During the installation, snAppShot records the changes that are made to the workstation’s configuration files, then stores the information in a binary Application Object Template (.AOT) file.
  • SnAppShot also records the new files added to the workstation, and stores them as .FIL files. The configuration information can be stored in an .AXT file, a text-based template that the installer can edit before the file is imported as an object into NDS.
  • After the .AOT file is created, it can be imported into NDS as an object, then associated to a Container object or User or Group. Since the .AOT file is binary, it can be changed to a .AXT file, which is text-based in order to be edited. The administrator can import both .AOT and .AXT files into the NetWare Administrator as application objects.
  • Simple applications are those that do not require any configuration file changes or supporting files such as .DLL files. An example of these applications is RCONSOLE.EXE included in NetWare 5. Setting up a simple application does not require snAppShot.
  • When the network administrator installs Z.E.N.works, the administrator’s user object requires the Supervisor Object right to the NDS tree [root] because Z.E.N.works extends the NDS schema.
  • Associations are required for the application icons to appear in the NAL window. Associations are set on the User, Group, or container object Applications page. The Launcher can be further configured in NDS through the Launcher Configuration property page.
  • The Set Application Inheritance Level affects NDS inheritance by limiting the number of levels that the tree is "walked" for custom settings. The administrator can designate an object as the top of the inheritance tree by selecting the option for Use Object as Top of Inheritance Tree on the object’s Launcher Configuration property page.
  • To organize applications in a hierarchical folder structure the administrator creates an Application Folders object in a container, then creates folders within the Folders property page in a tree structure. After the tree structure of folders is created, the administrator can add application objects to the folders.
  • Application objects have an extensive list of properties. Many of these are directly related to the application’s configuration settings. The application object properties can customize its behavior. Multiple application objects can be created for the same application, but simply be customized according to the application object settings in order for the application to work on different systems.
  • Z.E.N.works automatically places the NAL files in the SYS:PUBLIC directory of the servers on which it is installed. By default, all users are granted the read and file scan rights to this directory. The administrator must ensure that NAL files are in a file server directory in which users have the Read and File Scan rights.