Novell is now a part of Micro Focus

Using the Novell Application Launcher with Windows NT

Articles and Tips: article

DAVE ECKERT
Marketing Manager
Strategic Communications, IntranetWare

01 Apr 1997


Installing and maintaining applications for use by IntranetWare clients can be a time-consuming task, especially when the applications are hosted on Windows NT Servers. This AppNote explains how to do it the easy way with the Novell Application Launcher.

Introduction

Among all the tasks performed by the typical network administrator, perhaps the most visible to the user community are those related to the applications hosted on the network. The job of installing and maintaining applicationsC making them available to authorized usersCcan be very time consuming. The Novell Application Launcher (NAL) offers real benefits in providing centralized management and ease of use for applications on the network.

This AppNote describes the most recent release of NAL and hot to use it on networks which have integrated Windows NT into the Novell network. It begins by describing the installation and general use of NAL. Next, it discusses some special considerations when NAL is used on NT Workstations. The management of applications hosted on NT Servers is then covered. Where possible, it offers suggestions on special techniques or products which simplify the management of networked applications.

This AppNote assumes the use of version 1.1 of NAL available from the Novell Web site at http://www.novell.com, and the use of the newest library files for NWAPP32.DLL and NWAPP16.DLL dated 3-5-97 or later. Please check the web site for the latest information on this product.

Additional information about the Novell Application Launcher and other Novell products mentioned in this AppNote is available at http://www.novell.com or from your authorized Novell Reseller.

Overview of NAL

The Novell Application Launcher leverages the use of Novell Directory Services (NDS) by storing application information in the NDS database. This information is then used by an program executed on the client workstation to provide access to the application.

Using the NetWare Administrator (NWAdmin), the administrator creates and manages "application objects" in the directory. These objects contain the information required to successfully locate and launch applications at the client workstation. The applications themselves may be located on an IntranetWare server, an NT server, or both. Administrators can then assign applications by user, user group, or organization. Software assignment can be done once for a company group or department so that current and future members of this group will automatically gain access to a standard desktop configuration.

The NAL executable is run at the client workstation, displaying icons for the various applications. As changes are made by the administrator the appropriate applications dynamically appear on users' desktops. End-users can have access to all applications assigned to them while administrators can easily manage the access from their management console. Other benefits, such as load-balancing and fault tolerance, are provided by additional properties of the application objects.

Installing NAL

The NAL installer is a Windows-based application which may be run from any version of Windows. All files necessary to support Windows 3.x, Windows 95, and Windows NT workstations are supplied, as well as the administrative snap-in. This 32-bit snap-in to the NetWare administrator requires the 4.11 version of NWAdmin for Windows 95 or Windows NT, which is available from the Novell Web site. The Novell client, with proper access to NDS, is required on all workstations using the product.

By default, the files will be installed to the SYS:PUBLIC directory and additional subdirectories the installer will create. If the SYS:PUBLIC directory is map-rooted to a search drive, be sure to adjust the NAL installation directory so as not to create a PUBLICdirectory under the current PUBLICdirectory.

In general, the new NWAdmin and new NAL should be placed on all file servers running NetWare 4. These new programs are properly supported on older NetWare releases and provide increased capabilities. During the first installation, the Application Launcher causes the NDS schema to be extended. Therefore, the account performing this install must have administrative rights at the root of the tree. The installation process updates any previous versions of the applications launcher that may have existed.

Previously created application objects from NAL 1.0 will require migration to obtain the new benefits of this release. This is accomplished by selecting Migrate from the Tools menu.

Administering Application Objects

Following the installation of NAL, the administrator will install the actual application to the network and create the application objects before activating the client executable.

Installing Networked Applications

The administrator should begin by selecting a previously installed application or installing a new application on the network. There are advantages to installing the application on multiple servers, perhaps in different physical locations. This will allow the use of the load balancing and fault tolerant features.

It is also important to know what, if any, changes will be required at the client workstation. These might include .DLL files that must be locally installed or changes to .INI files or registry settings. Many network applications include a Client Install option to perform these tasks. Future NAL technology will provide tools to assess these required changes.

The administrator must ensure that the application can be run successfully without the use of NAL (browse to the networked application and activate the executable) before attempting to automate the process. Don't forget to implement file rights to access the application on the serverss for those people who will be using the application. Group and container membership simplifies this process. Information on which windowed platforms are capable of running the application must also be determined.

Creating Application Objects

NAL 1.1 uses an application object to hold the information for a networked application. If multiple copies of an application exist an individual application object is created for each instance. These objects may be placed at any location within the NDS tree without regard to the actual location of the application files. All operations are performed using the NetWare Administrator.


Note: If three copies of the word processor are available you may wish to create the objects asWP1, WP2, and WP3. This allows flexibility in placing the objectsand simplifies the fault tolerant implementation described below.

When an application object is created, a window appears (see Figure 1). The path to the executable may be typed in directly, or the browse button to the right of the space may be selected. When typing or browsing the path may include a drive letter or show the UNC path to the application. Because the application may exist anywhere on the network, it is possible to select applications hosted on a variety of servers, including any running on Windows NT Servers (see below for special considerations when applications are hosted on NT).

Figure 1: This window lets you enter the name to be displayed below the application icon and the location of the executable file.


Note: You may wish to make the displayed name of redundant applications the same to avoid confusion.

Check-boxes are used to determine which windowed platforms will be able to display the application object and the icon to be displayed may be modified.

Selecting the Environment page allows optional control over command line parameters, default working directories, and in which windowed mode the application will start.

If UNC paths are not used and the drive mappings are not pre-configured, the Drives/Ports page optionally allows these definitions.

Associating Applications with Users

The only other required operation is to associate the application object with the users who will be allowed to activate it. Selecting the Associations page will display a screen similar to Figure 2.

Applications may be associated with groups, organizations, or individuals. A management strategy which allows group or container membership to control applications will simplify overall administration.

Figure 2: Applications may be associated with groups, organizations, or individuals. A management strategy which allows group or container membership to control applications will simplify overall administration.

When multiple instances of an application are located in different physical parts of the network, you should associate users with the one which is physically closest to reduce network traffic.

Implementing Fault Tolerance

Almost all networks experience temporary equipment and communications failures that occasionally make applications unavailable. The distributed, replicated nature of NDS can ensure that users have access to the application object information even if the network cannot supply the application itself (see Figure 3). NAL offers a fault tolerant feature to provide users alternate services and thereby reduce support calls. A load-balancing feature allows a relatively even distribution of users over multiple instances of an application. (Load balancing assumes fault tolerance.)

Figure 3: Two copies of the word processor are available, WP1 and WP2. The object WP1 is associated with the authorized users and will be displayed to them. If the primary application cannot be located, users will be redirected to the alternate copy automatically. If both copies are available, users will be distributed across both instances, balancing the load.

When WAN links are involved it is reasonable to associate the users and applications which are in the same physical location, offering those on the other side of the communications link as the fault tolerant copies, but not to be selected for load balancing.

Scripting Capabilities of NAL

NAL generally will automatically create the required connection to application servers and release it when the application terminates. However, there may be a need for special operations to occur before the application starts or after it terminates. The Scripts page allows entry of these scripted operations.

Scripting capabilities are the same as the traditional NetWare login script syntax with the exception of some commands such as "write" and "display," which are not supported. This means that drives may be mapped or programs may be executed.

If an application is hosted on a NetWare 3 server or a Windows NT server not controlled by NDS, the scripts may be used to make the connection . These scripts may also be used to copy files or make workstation adjustments such as altering .INI files.

Other Object Information

Additional application object information, such as an application description, is managed on other pages. Future NAL technology will extend this information and include additional pages.

Client Installation

NAL depends on access to the network and NDS. Therefore, it is reasonable to run the client executable from the server. The architecture of the product makes client installation and update simple. The client portion is best launched by using the file NAL.EXE, which is a wrapper. A wrapper performs a few unseen tasks, selects which executable to start based on the environment, and then activates it. In this case, NAL.EXE takes care of several initialization functions and then runs the correct executable, either the 16-bit NALW31.EXE or the 32-bit NALWIN32.EXE. Once the correct executable is started, NAL.EXE terminates.

One of the main functions of the wrapper (NAL.EXE) is to determine the proper launcher executable, based on the operating system of the client. This allows the system administrator to add a single command into a login script without concern. If a user moves from one operating system platform to another the wrapper will automatically adjust. This approach simplifies setup and administration and allows greater flexibility. Because the application objects will only be displayed on platforms able to run them, the system becomes self-configurable.

In general, Novell recommends that the workstation always starts NAL.EXE, located on the file server, rather than going directly to one of the launching executables. Bypassing the wrapper will reduce some of the centralized administration benefits of the Application Launcher. In addition, if the workstation is unable to properly connect to the network and access the NAL.EXE from the server it also will not be able to read the NDS objects or run networked applications. This may cause confusion to the end user.

Updating Files

Another function of the wrapper is to update appropriate files on the local workstation prior to activating the launcher on the client. The set of files that NAL.EXE updates on the workstation is located in the NALLIBdirectory, which is directly below the directory where NAL.EXE is executed. This directory is typically SYS:PUBLIC\NALLIB when the product is installed in the default location. Depending on the platform, the wrapper updates appropriate files needed by the client executable. The local files are updated only when the network copy is newer than the local copy.

On Windows 3.x, NAL.EXE will copy the cross-platform NetWare libraries to the WINDOWS\SYSTEMdirectory. The NWAPP16.DLL file from SYS:PUBLIC is also copied to WINDOWS\SYSTEM as needed. This is a supporting .DLL for the client launcher. It is copied to the local workstation to avoid Windows errors if the user removes or loses the connection to the server where NAL.EXE was executed.

On Windows 95, NAL.EXE copies launcher files to the NOVELL\CLIENT32 directory and runs the launcher from there. This is done to avoid Windows errors if the user removes or loses the connection to the server where NAL.EXE was executed.

On Windows NT, NAL.EXE copies the launcher files to the WINNT\SYSTEM32 directory and runs them from that location.

On all Windows platforms, NAL.EXE will update the GUI login files as needed.

Executing NAL.EXE from a Login Script

The administrator can start NAL.EXE by adding it to any login script. The use of the wrapper simplifies this, as the administrator does not need to anticipate the operating system of the attaching client. When networked applications are centrally managed the launching technology can adjust to operating system variations.

Updating the GUI files was explained in the previous section. On Windows 3.x and Windows 95, the Application Launcher requires the newer versions of the GUI login files in order to run scripts properly. If the newer versions of the files are not present, NAL does not run scripts when an application is launched. It is important to note that the GUI login files cannot be updated while GUI login is running. Therefore, if NAL.EXE is run from a login script, none of the GUI login files can be updated using this process.

If the GUI login files must be updated, you can create an application object that points to NAL.EXE. After the login script finishes, the end user can run that application to have the GUI login files updated. NAL.EXE will not open a second instance of the launcher, but terminate after the update is performed. You might label this application Update Client.

In much the same way, you may wish to create other "update" objects to simplify workstation management. Future NAL technology will offer "run once" and "run on schedule" application objects to perform these tasks automatically.

Special Administrative Features

There are two special features in NAL.EXE that let the optional file NALINIT.INI change the way NAL.EXE functions. NAL.EXE looks for a file named NALINIT.INI in the current directory and in the path. If NALINIT.INI is found, NAL.EXE looks for settings in the [Init] section. The possible settings are SkipUpdate and SkipLaunch.

If SkipUpdate is set to 1, NAL.EXE does not copy any files. You would use SkipUpdate if you did not want NAL to change any files on the local workstation and you wanted NAL.EXE to always run NALW31.EXE or NALWIN32.EXE from the server.

If SkipLaunch is set to 1, NAL.EXE does not run NALW31.EXE or NALWIN32.EXE, but performs the update and then terminates. You would use SkipLaunch if you wanted NAL.EXE to update GUI login files on a local workstation but not start the launcher itself.

NAL.EXE functionality is not affected if the value of a setting is 0BODY> or if the setting is not included in NALINIT.INI. Obviously, setting both options to 1 at the same time instructs NAL.EXE to perform no function and therefore should not be done.

Normal Client Operation

Once the administrator has established application objects and provided for client activation, NAL is very simple to use. As stated above, it is easy to activate NAL from the login script.

The NAL 1.1 includes optional containers on the left-hand side, where application icons can be stored conveniently in user folders or system folders. The details on an organizational unit or a user will display a Launcher Configuration page (see Figure 4) which controls the ability of users to add or modify these folders. This reduces the clutter on the user desktop and simplifies the central management of multiple applications.

Figure 4: Launcher Configuration enables timed refreshes and the ability to inherit application objects from other containers. Once established, the application objects do not change frequently and you may wish to refresh only upon command to reduce network traffic or set a long refresh interval.

Upon startup, the user is presented with a window containing icons which represent the applications. Only those applications associated with the user will be displayed. An installation with many applications, sorted into folders, would look like Figure 5.

Figure 5: Client view of available applications.

Future NAL technology will further extend desktop integration by allowing applications to appear on the desktop, in the taskbar, or as part of the standard Explorer utility. This approach makes access very transparent and promotes ease of use.

When an application is selected by a user, the NAL performs the tasks necessary to run the application based on information obtained from the application object in the directory. These tasks include attaching to the required server (either Novell or NT), selecting an alternate server when required, enabling printers, and performing required startup functions. Future NAL technology will also perform registry and .INI file modifications.

When the application is terminated, the NAL removes appropriate connections and restores the workstation to its previous state. This helps reduce the use of network resources and licensed connections.

Workstation Considerations

NAL requires access to Novell Directory Services and functions supplied by the Novell client software. This client software is available for Windows 3.x, Windows 95 and Windows NT. Because NDS provides background authentication, applications may be hosted on any NetWare 4 server in the network without requesting a username and password.

Novell's client software continues to support NetWare 3 servers using bindery services. During the login process it is possible to attach to any required NetWare 3 servers and establish permanent drive mappings. These can be used by NAL to activate applications without additional user intervention. Novell includes its NetSync software to assist in managing older NetWare 3 accounts through NDS.

If applications are also hosted on NT servers (see below), the client workstations will require Microsoft networking software as well. Users must have access to these file servers, and Novell software described below will assist in managing those user accounts.

When the workstation is running Windows NT version 3.51 or 4.0, there are additional considerations. Unlike its predecessors, the NT Workstation has a local security system which prevents unauthorized users from accessing any part of the workstation. Prior to using the workstation, a user must have a valid account and password on the workstation in addition to the network. If applications need to be run by any authorized user on any available workstation, there can be a significant increase in administration.

The Novell IntranetWare Client for Windows NT contains the Workstation Manager. This product allows central management of local security using NDS and NWAdmin. User accounts may be automatically created and managed on the local workstation and user profiles may be maintained on the network. This enables a user to login at any workstation and have their familiar desktop configuration appear. By saving data in the network, rather than on the local machine, users may easily move from workstation to workstation.

Hosting Applications on NT Servers

In some cases an NT Server is required to host an application. Until recently, this could dramatically increase the cost of administering the network by requiring the installation and maintenance of Microsoft Domains. The domain contains the information necessary to authorize users to the NT Server and allow access to applications and services.

The Novell Administrator for Windows NT allows this information to be created and maintained in NDS and synchronized automatically to the NT Domain. When a user is created, or when he or she is given access to a new application, the administrator may make them a member of the domain for the application server as shown in Figure 6.

Figure 6: In this example, the user is part of the group that accesses applications on the NT Server named WUZZLE.

An account is automatically established with access rights as a "domain user." Since the NT Server has been set to allow "domain user" group members the right to access a common area where the applications are located, no additional administration is required.

In prior examples we activated a word processor on a NetWare server. NAL can also manage applications hosted on NT servers (see Figure 7). Other than than the application's location on in a common area accessible to any domain user, all other aspects of the application object are the same, including the ability to define load-balancing and fault-tolerant alternative servers. These alternatives may be other NT servers or NetWare servers, as defined by the administrator. This ability to provide fault-tolerant access to applications hosted on NT servers is unique to the Novell Application Launcher and provides additional cost-saving benefits to the network.

Figure 7: In the application object screen, the word processor is located on an NT Server in the "common area" known as "shareDATA" which is accessible to any "domain user".

In some cases applications are restricted to certain users (see Figure 8). Because only certain users are given rights to see the special application object, general users will not even see this icon on their workstation.

Figure 8: The "Group Membership" tab shown allows the administrator to permit selected users to access more private applications than would be allowed to generally authorized users. These pre-defined NT groups would have additional rights beyond those of a "domain user." Membership in a Domain Group.

Applications hosted on NT servers that require the use of an NT workstation would be marked as such. This also inhibits the display of these application icons when a user travels to a non-supported workstation. Future NAL technology will enforce more granular workstation requirements, such as minimum hardware or OS version level.

Summary

The Novell Application Launcher simplifies your overall network management by enabling you to centrally deploy networked applications to Windows­based desktops throughout your organization. As a result, you dramatically reduce the time and cost of administering your company's productivity tools.

NAL ensures that the most current versions of applications are available to those employees authorized to use them. By providing consistent, fault-tolerant access to applications, even as users move from workstation to workstation, support calls can be reduced dramatically.

By simplifying the user interface to applications hosted on the most appropriate platform, NAL enables greater flexibility to your network.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.

© Copyright Micro Focus or one of its affiliates