Novell is now a part of Micro Focus

A Practical Guide to Using Novell Application Launcher (NAL) 2.01

Articles and Tips: article

SALLY SPECKER
Senior Consultant
Novell Consulting

01 Jan 1998


Any complete network management system should provide a solution for software distribution. NAL 2.01 is the latest version of Novell's server-to-client software distribution utility. NAL is not part of the ManageWise 2.1 product, nor does it require ManageWise. Rather, NAL is a separate utility which is free of charge and can be downloaded from Novell's current NAL web site:

http://www.novell.com/products/managewise

This AppNote is intended to give you a very good start with understanding what NAL is, how to install it, how to set up and distribute applications, and some general ideas and guidelines for its usage. Novell will be placing white papers, tips/tricks, customer solutions, and other useful information about NAL on their web site:

http://www.novell.com

Additionally, there are Technical Information Documents (TIDs) about NAL available on Novell's support site:

http://support.novell.com

Introduction

NAL allows network administrators to create Application objects which, in Novell Directory Services (NDS) terminology, are simply leaf objects in the NDS Tree. These Application objects will represent the software applications (e.g., Corel WordPerfect or Microsoft Word for Windows) to be distributed to users. One Application object is created for each software application to distribute. Within the Application object, the network administrator sets up such application dependencies as:

  • Drive mapping or UNC path to the executable file.

  • Printer ports to capture for printing from this application.

  • Registry and INI entries necessary to run the application.

  • Actual program files necessary to run the application.

There are many more controllable application dependencies (i.e., NAL Properties) which will be discussed throughout this AppNote.

After Application objects are set up, the network administrator simply "associates" these Application objects to the appropriate NDS container, group, or user. When a user logs in, these applications are distributed based on one of these three associations.

NAL is the only software distribution utility on the market which completely leverages NDS, meaning that all the information associated with an Application object (such as the dependencies listed above) is stored within the NDS database. This eliminates network administrators having to manage a separate NAL database. Additionally, by using NDS as the central repository, access is highly secure. Another benefit of NAL is that all administration is done from the familiar NetWare Administrator (NWAdmin) utility.

NAL works tightly with the both the Windows 95 and Windows NT Registries, supporting roaming profiles. NAL can automatically detect when your profile is running on another machine and download components necessary to run your NAL-defined applications.

NAL gives network administrators the option of "pulling" or "pushing" software to workstations. Pull distribution surfaces an application icon on the user's desktop. Clicking this icon either launches the application, first making any necessary workstation configuration changes, or runs an installation program only, placing the application on the user's hard drive while again making any necessary workstation configuration changes.

Push distribution does the same as pull distribution (above) except it is done without user intervention. In NAL terminology, this is referred to as a "Force Run." This works well in scenarios where certain software needs to reside on workstations like operating system patches, network client updates, client-side electronic mail software, etc. It is also useful when you want a certain application to automatically be run on a user's workstation after login.

As with any software application, the network administrator decides on the architecture of the system. For laptops you might want all of the software on the local drive. Whereas for desktop computers, you might want to run the application from the server. NAL offers software distribution for both cases.

NAL makes it easy to deliver new and updated applications to users, reducing the cost of administering workstations and the overall cost of network management. NAL enforces standard desktops for users and can be a very effective way to control exactly what users see and can do at their workstations. Users cannot delete NAL-delivered application icons. Additionally, if users accidentally delete any file(s) associated with an NAL-delivered application, they can simply right-click that application icon and select Verify. This restores the application files and configuration settings. So with NAL, application control is in the network administrator's hands--not the user's.

Note: If you don't want users performing this Verify step above, you could take advantage of the Remote Control feature in ManageWise and perform this step yourself. Either way, no "visit" to the desktop is necessary.

Networking Operating System Requirements

These are the Network Operating System (NOS) requirements:

  • A Novell NetWare 4.10 or later (NDS) server is required to support Application objects.

  • Your applications to be distributed can reside on either NetWare 4 or Windows NT Servers.

Note: You can distribute applications off Windows NT Servers if the workstation is running both the Novell and Microsoft network client software. Distribution of applications off NetWare 3 servers is not supported.

Client Requirements

These are the requirements for User workstations:

  • Windows 3.1x, Windows 95, or Windows NT

  • Latest version of Client 32 for DOS/Windows, Windows 95, or Windows NT; or Virtual Loadable Module (VLM) client software 1.2.1

  • A Directory Services connection must be made; no Bindery connection

These are the software requirements for Administrator Workstations:

  • Windows 95 or Windows NT

  • Latest version of Client 32 for Windows 95 or Windows NT; or Workstation Manager 1.0

  • NetWare Administrator (NWAdmin) 4.11 or later

Product Components

NAL 2.01 consists of four product components: two for administrator functions and two for user functions.

Administrator Components

The two administrator components are the NAL Snap-in and snAppShot.

NAL Snap-In. This is a Windows DLL that extends NWAdmin, making it possible to create and properly display Application objects. NAL Snap-In adds Application object to the NDS Tree, which supports Windows 3.1x, Windows 95, and Windows NT. Earlier versions of NAL added three separate Application objects for each of these three operating systems. This Application object has 17 property pages, all of which will be discussed later.

Snap-In also adds two new NWAdmin property pages for Container and User objects: Applications and Launcher Configuration; and one new NWAdmin property page for the Group object: Applications (the same property as for Container and User objects).

Note: The majority of the settings in both these Property pages will be discussed during relevant sections throughout this AppNote. By setting them at the container or group level, they apply to all users in that container or group. By setting them at the user level, they apply to just that user.

A container's default Launcher Configuration property is "Use Default Settings." The following table shows what this means:


Setting

State

Exit Launcher

On

Log In

On

Refresh Icons

On

View Folders

On

Create Personal Folders

Off

Save Window Size and Position onLocal Drive

On

Enable Timed Refresh

Off

Enable Times Refresh

3600 seconds (if above is on)

Inherit Container Application

1 Level

To modify any of these, simply select the button next to "Use Current Settings" and modify the above properties, as appropriate.

A user's default Launcher Configuration property is "Use Parent Container Settings" which uses the above chart, then, by default.

Additionally, the NAL snap-in also adds:

  • An "Export Application Object" selection in the Tools menu.

  • A "Show All Inherited Applications" selection in the Tools menu.

  • A "Migrate Application Objects" selection in the Tools menu.

NAL snAppShot. When used with the NAL Snap-in, snAppShot provides for advanced server-to-client software distribution capabilities. snAppShot will be discussed in a separate section later.

User Components

The two user components are the NAL Window and the NAL Explorer.

NAL Window. This is the workstation component that displays the icons of NAL-delivered applications set up for the user. The NAL Window can be run on Windows 3.1x, Windows 95, or Windows NT workstations.

SYS:PUBLIC\NAL.EXE is the executable file for the NAL Window. It is a wrapper technology meaning that NAL.EXE takes care of several initialization functions and then runs the correct executable: either NALW31.EXE or 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.

Note: It is recommended that the workstation always start NAL.EXE rather than going directly to one of the launching executables. Additionally, if you run NAL.EXE from a login script (which is generally the way to do it) then you don't have to anticipate the operating system of the attaching client.

Customizing NAL Window. The top line of the NAL Window displays "Novell-delivered Applications for <user name<", which is the user's distinguished NDS name. You can customize this by putting a Full Name property on the User object.

Also, the NAL Window displays all NAL-delivered applications for the user when the Tree folder is selected. If you select just an individual folder, you see just the applications associated to it. Applications show up in these separate folders based upon the NDS object (i.e., container, group, or user) they are associated with.

Note: This folder view in the NAL Window might be confusing to users. If so, it can be disabled by turning off the "View Folders" option in the container or user's Launcher Configuration property. In this case, users will only see the Application icons and not any folders.

If you do leave the folder views on, you can customize the name of these folders by:

  • Putting a Description property on the container or group's NDS object.

  • Putting a Full Name property on the user's NDS object.

  • There is currently no way to customize the Tree folder displayed here.

For example, the network administrator could put a Description of "Common Applications" on a container, assuming they apply to everyone in that container, and put a Description of "Sales Applications" on the Sales container or Sales group, for applications specific to salespeople. This type of customization allows the network administrator to group applications under descriptive folder names for their users.

NAL Explorer. This is an option to using the NAL Window. It lets network administrators deliver applications not only into the NAL Explorer Window but also into the Windows Explorer, the Start Menu, the System Tray, the Desktop, or any combination of these. NAL Explorer can only be run on Windows 95 or Windows NT 4.0 workstations. NAL Explorer requires a newer version of SHELL32.DLL for Windows 95 which is part of the Microsoft Windows 95 Service Pack 1 Update.

SYS:PUBLIC\NALEXPLD.EXE is the executable file for the NAL Explorer. When installed, it will add a NAL Explorer folder on the desktop. To uninstall the NAL Explorer (the only way to remove the NAL Explorer folder from the desktop) execute NALEXPLD /U. You may have to reboot your workstation for this process to finish. This removes NAL Explorer from the desktop, removes the DLLs installed, and cleans the registry settings from this program.

During the installation of NAL Explorer, the following folders and files are added or updated:

  • File C:\Novell\Client32\Nalexp32.dll added

  • File C:\Novell\Client32\Nls\English\Nalexp32.cnt added

  • File C:\Novell\Client32\Nls\English\Nalexp32.hlp added

  • File C:\Novell\Client32\Nls\English\Nalexprs.dll added

  • File C:\Novell\Client32\Nwapp32.dll added

  • Registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ Windows\CurrentVersion\Explorer\Desktop\NameSpace\{CF8EF420-3DF3-11d0-AC35-00C04 FD9338A} added

  • Registry key HKEY_CURRENT_USER\Software\NetWare\NAL\1.0\Session added

You can also customize the NAL Explorer Window. The NAL Explorer delivers a slightly different view than the NAL Window. Specifically, you do not see the "Novell-delivered applications for <user name<" at the top of the window nor do you see all Application objects associated to a user when you select the Tree folder. Rather, selecting this Tree folder opens up a second window showing individual folders and application objects within these folders.

Note: All the customization options mentioned under Customizing the NAL Window (above) also apply here.

Which of these two user interfaces a network administrator chooses to use is a design decision and is also dependent upon the client operating system. You generally would not use both on the same workstation. Many network administrators prefer the NAL Explorer because it allows them to distribute applications to a user's Start Menu, from where Windows 95 and Windows NT users are used to launching their applications.

Rights Requirements

There are different rights requirements for NDS and the file system.

NDS Rights. Supervisor Object rights to the [ROOT] of the NDS Tree are needed when the network administrator installs NAL, as NAL extends the NDS base schema to support Application objects and adds new properties to existing objects (as discussed above). As always, an NDS "Health Check" should be performed before installing any application which extends the schema to ensure that NDS is properly synchronized among all servers in the Tree.

No manual assignment of NDS rights is necessary for users to access Application objects. Read and Compare "All Property Rights" will automatically be assigned to any container, group, or user a network administrator associates with an Application object.

Users need Read and Write property rights to their User object's NRD: Registry Data and NRD: Registry Index properties to create personal folders. This assignment is not automatically given. Personal folders allow users to create their own folders and move NAL-delivered applications into these folders. The "Create Personal Folders" must be turned on (remember the default from the table above is off) in either the container's or user's Launcher Configuration property to support this feature.

File System Rights. Users accessing NAL need file system rights to:

  • The directory in which NAL is installed (default is SYS:PUBLIC).

  • The directories where the applications to be distributed reside.

Note: A future release of NAL will support automatic assignment of file system rights when a user launches a NAL-delivered application and will remove these rights when the NAL-delivered application is exited.

Installation

NAL 2.01 installation software consists of two executable files:

  • SETUPNAL.EXE -This installs three of the four NAL product components mentioned earlier (i.e., NAL Snap-In, NAL Window, and NAL Explorer) into a default directory of SYS:PUBLIC. The steps for installing NAL are discussed below, under the "Running SETUPNAL.EXE" section.

  • SETUPSNP.EXE - This installs the fourth NAL product component mentioned earlier (snAppShot) into a default directory of C:\SNAPSHOT. Remember that snAppShot is an administrator utility and does not need to be installed on user workstations. The steps involved for installing snAppShot will not be discussed as it is a very straight-forward installation process. Using snAppShot will be discussed later.

During installation of NAL snAppShot, these files are intalled:

  • Folder C:\Snapshot\Nls added

  • Folder C:\Snapshot\Nls\English added

  • Folder C:\Windows\Profiles\Kprior\Start Menu\Programs\NAL snAppShot added

  • File C:\Snapshot\Deisl2.isu added

  • File C:\Snapshot\Nls\English\Dvjres16.dll added

  • File C:\Snapshot\Nls\English\Dvjres32.dll added

  • File C:\Snapshot\Nls\English\Snapshot.cnt added

  • File C:\Snapshot\Nls\English\Snapshot.hlp added

  • File C:\Snapshot\Snappe16.exe added

  • File C:\Snapshot\Snappe32.exe added

  • File C:\Snapshot\Snapshot.exe added.

  • File C:\Windows\Powerpnt.ini updated

  • File C:\Windows\Profiles\Kprior\Start Menu\Programs\Envoy\Envoy Viewer.lnk added

  • File C:\Windows\Profiles\Kprior\StartMenu\Programs\InfoCentral \InfoCentral.lnk added

  • File C:\Windows\Profiles\Kprior\Start Menu\Programs\NAL snAppShot\snAppShot.lnk added

  • File C:\Windows\Profiles\Kprior\Start Menu\Programs\NAL snAppShot\Uninstall snAppShot.lnk added

  • File C:\Windows\Wavemix.ini updated

Running SETUPNAL.EXE

Log in to a server in the NDS Tree where NAL is to be installed. Remember to log in as a user with Supervisor Object rights to the [Root] of the Tree. Next, Close all applications on the workstation you are using. If NAL 1.1 has previously been installed in this Tree, make sure no users are running it as NAL 2.01 will automatically upgrade NAL 1.1 Application objects during the installation process.

Note: NAL 1.0x Application objects are not automatically upgraded to 2.01. However, NAL 2.01 offers a migration utility that creates NAL 2.01 Application objects based on existing NAL 1.0x Application objects. The migration utility is available from the Tools menu in NWAdmin and this selection will only be active if you select a NAL 1.0x object in the Tree to migrate. Refer to the on-line Help (within NWAdmin) on "Migrating Application Objects from 1.0x to 2.0x" for more information.

Run SETUPNAL.EXE and respond to the prompts below (italicized). Notice that it says Novell Application Launcher 2.0 even though you are installing NAL 2.01. This was intentional because NAL 2.01 was primarily a maintenance release from NAL 2.0.

Choose Destination Location. It is recommended you install to the default SYS:PUBLIC directory. Make sure that your mapping to SYS:PUBLIC is not a Root mapping.

SETUPNAL.EXE installs product files in the following directory structure:

SYS:PUBLIC SYS:PUBLIC\NLS\ENGLISH SYS:PUBLIC\WIN95 SYS:PUBLIC\WIN95\NLS\ENGLISH SYS:PUBLIC\WINNT SYS:PUBLIC\WINNT\NLS\ENGLISH

Additionally, a NALLIB directory structure will be created under the directory in which you installed NAL:

SYS:PUBLIC\NALLIB\WIN31\NLS\ENGLISH SYS:PUBLIC\NALLIB\WIN95\NLS\ENGLISH SYS:PUBLIC\NALLIB\WINNT\NLS\ENGLISH

They contain login files which get updated by NAL prior to activating the launcher on the client.

Do You Want to Extend the NDS Schema? You must extend the schema to use NAL (it is a one-time process per NDS Tree). It can be done now or after the NAL installation is complete. If you select Yes, Setup extends the schema in the NDS Tree that contains the directory in which you are installing the NAL software. If you select No, the first time you open NWAdmin after NAL is installed, a prompt will ask you on which NDS Tree you want to extend the schema. Select the appropriate NDS Tree and click Modify.

Note: If you have NAL 2.0 installed in your Tree, you will not be asked to extend the schema as the schema does not change from NAL 2.0 to NAL 2.01.

Do You Want Setup to Create Sample Application Objects? It is recommended you select Yes so that after installation, you can explore Application object properties. The context-sensitive Help available on each of these properties is very helpful in learning about NAL's features. These sample Application objects (i.e., NWAdmin95, NWAdminNT, and snAppShot) will be placed in the server context on which you are installing the NAL software and can safely be deleted at any time.

Note: If you have NAL 2.0 installed in your Tree, you will not be asked to create sample Application objects.

Do You Want to View the Readme? It is recommended you select yes to view READNAL.TXT. The Appendix contains caveats, limitations, and known problems network administrators should be aware of.

Using NAL to Distribute a "Simple" Application

After NAL is installed, you are ready to start distributing applications to users. A simple application is (for our purposes here) one which does not require any Registry changes, INI file changes, nor DLLs at the workstation. In this case, setup only requires two steps (assuming the user already has file system rights to where the application is located):

  1. Create the Application object name and specify the Path to executable file. This is done the same way as you would create any NDS leaf object, i.e., by highlighting the container where you want the Application object to reside, selecting Create from the Object menu, and selecting the Application object in the "Class of New Object to Create" window. Then:

    1. Give the Application object a name.

    2. Enter the "Path to executable file", which can either be a drive mapping or a UNC path. If you use drive mappings, ensure that the user also has this same drive mapping; otherwise, the distribution will fail.

    For convenience, put a check-mark next to "Define additional properties" so the Property Pages for the Application object will automatically be brought up so you can associate this application object. If you don't do this now, you can always highlight any object in the NDS Tree and bring up its Property Pages by selecting Details from the Object menu in NWAdmin. Properties and Details are synonymous in NDS terminology.

  2. Associate the Application object to a Container, Group, or User. This association is made from the Application object's "Associations" property page. By associating an Application object to a container, any existing or new user created beneath this container will automatically receive the application. Or, if you require a more restrictive software distribution, you can associate to either a group or a user.

Note: An Application object must be associated with a container, group, or user for it to be delivered to workstations. For all practical purposes, this can be considered a required property. It is also a good property to check if the application is not showing up on workstations, by ensuring the proper association was made. Currently you cannot associate NAL objects to an Organizational Role.

After these two steps are performed, user(s) will be distributed the application when either NAL.EXE or NALEXPLD.EXE is run. If a user were to already have one of these two NAL windows open on the desktop, the Application object would appear if the user pressed the F5 (Refresh) key or after 3600 seconds (10 minutes), assuming the "Enable Timed Refresh" option is turned on (remember the default is off) and the "Refresh Icons" is left at its default of on. When the "Enable Timed Refresh" setting is turned on, 3600 seconds is by default (and is customizable) how often NAL walks the Tree to see if any new Application objects have been associated to a user, any groups a user belongs to, or any parent containers relative to a user object in the Tree.

Note: Setting the Enable Timed Refresh option too low will cause additional traffic on your network.

Inheriting Applications

At some point, a network administrator will want to know what applications are being delivered to a user and through what associations. This is accomplished by highlighting a User object and then selecting the "Show Inherited Applications" option under the Tools menu in NWAdmin.

NAL calculates the applications to be distributed to users in this order:

  1. All applications associated directly with the User object.

  2. All applications from any groups the user is a member of.

  3. All applications from parent containers above the user. This last calculation is dependent upon the "Inherit Container Applications" setting in the Launcher Configuration property (see "Container Association Considerations" below).

Note: Currently there is no way to allow the network administrator to prioritize applications as they are distributed to users; however, this prioritization could be somewhat controlled based on the above.

This "Show Inherited Applications" option will categorize the applications into the different areas where the application(s) will show up (for example, Launcher, Start Menu, Desktop, or System Tray). Remember that users need to be running the NAL Explorer to have applications distributed to the Start Menu, Desktop, or System Tray. This option also shows if the application is a Force Run "push" application.

If you want an application to show up in the Start Menu for a user, you would go back to where the association was made (either to a container, group, or user) and set this up under this object's Applications Property page. This is also where you would set up a Force Run distribution.

Container Association Considerations

When calculating applications to be distributed to users, NAL (by default) only looks in the user's immediate parent container for container-associated Application objects (the actual Application objects can reside anywhere in the Tree). This default is due to either the container's Launcher Configuration property of "Use Default Settings", or the user's Launcher Configuration property of "Use Parent Container Settings".

If you do associate an Application object with a container which is at a level(s) higher in the Tree than the user's immediate parent container, you will need to adjust the "Inherit Container Applications" property by entering a value in the "Levels" box as appropriate:


0

NAL won't look forcontainer-associated Application objects

1

NAL looks at the immediate container forcontainer-associatedApplication objects (default)

2

NAL looks up two containers forcontainer-associated Application objects

3

NAL looks up three containers forcontainer-associated Application objects, etc.

-1

NAL looks up to the [Root] forcontainer-associated Application objects

As an example, if an Application object has been associated with a container one level above a user's immediate parent container, the user's immediate parent container's "Inherit Container Applications" property would need to be modified to a "2" setting before any user in that container would be distributed the application. Optionally, you could set this at the User object level to control this for just a specific user.

Note: Users will not see NAL-delivered applications associated with parent containers unless this is set correctly! This is a good troubleshooting tip to remember.

You need to be careful with this inheritance. Even though you could associate Application objects at the highest container in the Tree (e.g., O=) and let these "flow down" to all users by using a -1 to have NAL search up to the [Root], this could cause additional traffic on your LAN/WAN, depending upon your partitioning and replica placement.

Design Considerations

As with any other NDS object resource in the Tree, you should try and place Application objects close to the users who will be accessing them. Ideally, these Application objects should be within the same NDS partition as the user. It is not recommended to have users access Application objects in remote NDS partitions (i.e., partitions across WAN links) for performance and accessibility reasons.

Application objects have a Schedule property so that you can control when users are delivered applications. This is useful in the scenario where you want to distribute a large Service Pack to all users. You probably would not want this to occur at 8:00 a.m. when all users log in. Additionally, you may not want this distribution to occur on weekends when there are no technical support people on-site. In this scenario, you could make the Application object available Monday through Friday at 8:00 a.m. Then to avoid all users downloading the Service Pack at 8:00 a.m. when they log in, you could set the "Spread from Start Time" to 120 minutes. The application then becomes available on a random basis between the hours of 8:00 a.m. through 10:00 a.m. Refer to context-sensitive Help for more information on an Application object's Schedule property.

Application Object Properties

Now is a good time to look at other Application object properties, remembering to use the context-sensitive Help for additional information. This section is intended to give you a description of each property and some possible implementation ideas. However, understanding your application and testing applications to be distributed in a lab environment is important before final distribution to your users. Even if this testing process were to take 3-5 days, think of the time you'll save not having to "touch" hundreds or thousands of desktops!!

Identification Property Page

This section describes the various properties of the Identification Property Page.

Application Icon Title. This is a mandatory property. This text appears as the caption beneath the NAL-delivered application. The default is the name you used when you created the Application object; however, this can be changed and can be different from the name of the Application object in the Tree.

Path to Executable File. This points to where an application's executable is located. This can be edited if you later move the application to another location. This option will distribute any Registry or INI changes, if necessary, the first time the user launches this application, then will launch the executable file. Successive launches of this application will simply launch the executable file.

Install Only. This mutually exclusive with Path to Executable File. This option is used when there isn't an application to be run and for updating or installing applications, service packs, etc. on a workstation.

Prompt User For Reboot . This option allows you to control if and when a workstation reboot should occur after an application has been installed.

Run Once. This option is useful when you are distributing a Service Pack which only needs to be installed once. The Application object disappears from the NAL or NAL Explorer Window after it has been run once. In this scenario, you might also consider setting this Service Pack Application object up as a "Force Run" so that it runs once without user intervention.

Distribute Always. This will force a distribution, along with any Registry or INI settings, every time a user launches the application (vs. how the distribution works in Path to Executable File discussed above). Distribute Always is useful when you want to ensure that certain Registry or INI settings are present or updated every time an application is run, not just the first time.

Change Icon. A default NAL icon is used unless one is selected here.

Version Stamp. This is a tool to assist with upgrading applications. This stamps the workstation with a text string (in the Registry) which represents the version of the application (although this text string may or may not have anything to do with the actual version of the product). As an example, you could type in a string to coincide with the first distribution of this application. Then, if you later change some property of the Application object, you could enter a different string and these new property changes will become effective the next time the user launches the application. This process would not need to be used if the application was set up as Distribute Always. You would change the version stamp if you wanted to do any of the following: have the distribution re-triggered, have a Run Once application re-appear/run, or re-trigger a scheduled application during the current scheduled period.

GUID (Globally Unique Identification). This is how NAL tracks information about Application objects and is displayed for informational purposes only.

Environment Property Page

This section describes the Environment Property Page.

Command Line Parameters. For special start-up switches for the application's executable.

Working Directory. Path to the application's working directory. This will be the default directory when users do a "save" within the NAL-delivered application.

Run: Normal (Default); Minimize application when run; or Maximize application when run.

Windows NT 16-bit Windows on Windows "WoW" Support. This only applies to Windows NT.

  • Shared (Default)--Runs the Windows 16-bit application in a shared (unprotected) 16-bit virtual DOS machine (VDM). If this application crashes, all 16-bit applications sharing this space will also crash. This option allows 16-bit applications to communicate with each other.

  • Separate--Runs the Windows 16-bit application in its own protected 16-bit VDM. If this application crashes, only it will crash and not affect any other application. 16-bit applications cannot communicate with each other.

Enable Error Logging to File. The path to a file where any errors will be logged if an application fails to launch or install. No status is tracked here except for errors (although this will be enhanced in the future). Users need file system rights to write to this file in order for it to work. This log file will record the time, date, workstation, user, and error text.

Clean Up Network Resources. When left at the default of on, NAL will clean up resources allocated, such as drives mapped, printer ports captured, and connections made to file systems for accessing the application. In essence, NAL is cleaning up licensed connections.

Monitor Module Name. This option is effective when Clean Up Network Resources is on. Some applications, like WordPerfect, are actually wrappers, i.e., WPWIN.EXE runs WPWIN7.EXE and then terminates, while WPWIN7.EXE continues to execute. In this case, NAL would be monitoring WPWIN.EXE and would quit monitoring it before the application is really done. Monitor Module Name allows the network administrator to type in the name of the actual executable file that is going to run (WPWIN7.EXE in this case) and NAL can then monitor it for termination. Knowing your application (as mentioned earlier) is important here. Generally speaking, the symptoms requiring this property are that the application runs fine outside of NAL, but generates errors when run within NAL.

Drives/Ports Property Page

Any drive mappings or printer ports captured here are set when a user launches the application and are automatically "cleaned up" when a user exits the application, assuming the Clean Up Network Resources option (discussed above) is on. This is useful for eliminating unnecessary licensed connections vs. a licensed connection always being used if these commands are set within a NetWare login script. You could potentially eliminate all application drive mappings and printer port captures within a login script if using all NAL-delivered applications!

Description Property Page

This gives users more detailed information on the application other than what they see as the caption (from the Application Icon Title property above). Users would right-click on the NAL-delivered application and then select Properties to view this description.

Fault Tolerance Property Page

This actually allows you to set up both fault-tolerant and load-balanced Application objects.

Enable Load Balancing. You could enable this feature for a site which has several applications servers. You would set up separate Application objects for the applications which reside on these different servers. NAL would then use a random number to distribute the load among the applications on these servers; NAL does not distribute the load based upon server CPU utilization. You would probably design load balancing for servers on the same side of WAN links. Load balancing assumes fault tolerance. Remember you currently have to assign file system rights to the applications on these different servers.

Enable Fault Tolerance. There are design considerations here. If your client has its primary NDS connection on one of the servers where the Application object is pointing to and that server "crashes," you will get error messages when you try to re-launch another Application object on a different server in the fault tolerant list. (This is actually a client software issue vs. an NAL issue.) So, when designing this feature, your Application objects in the Fault Tolerant list should not be on the server where you have your primary NDS connection if you want fault tolerance to protect you from a server "crash". It will still work in this scenario if something happens to the application but the server still remains up. If you have more than two Application objects in the Fault Tolerant list, NAL simply selects the next object by going down the list in order. Fault Tolerant servers might be across WAN links. Remember you currently have to assign file system rights to the applications on these different servers.

Scripts Property Page

Both pre-launch application and post-termination application scripts are available. The commands used here are the same as the ones used in NetWare login scripts. However, you should view context-sensitive Help for the login script commands which are not supported. All login script variables will work. Any drive mappings or printer ports captured here are not cleaned up, even if Clean Up Network Resources is turned on.

Contacts Property Page

Users could access this to see whom to contact if they are having a problem with their application by right-clicking on the NAL-delivered application and then selecting Properties to view the Contact person, their Phone Number, and their E-mail Address (assuming these properties are set on the contact user's NDS object and that users have the Read Object right to view these NDS properties).

Note: The NAL Explorer does not show the Phone Number property (but the NAL Window does). This has been reported to Engineering and will be fixed.

Associations Property Page

This controls which containers, groups, or users will be delivered the application, and was discussed earlier. If the bottom level of your Tree is set up based upon functional areas (e.g., Accounting, Sales, etc.) container-based application distribution becomes a very powerful feature. You could associate an Accounting application to the Accounting container. Then, any new users hired (and therefore added) to the Accounting container would automatically receive the Accounting software distribution!

Schedule Property Page

An example for use of this property was discussed earlier. Refer to the context-sensitive Help for additional examples.

System Requirements Property Page

This page controls the operating system on which the NAL-delivered application will appear (i.e., Windows 3.x, Windows 95, Windows NT) and effectively replaced the need for the three separate Application objects in earlier versions of NAL. This property can also control application delivery based upon type of processor, amount of physical RAM (on Windows 95 and Windows NT), and free disk space. This is a good Property Page to check out for troubleshooting purposes if a NAL-delivered application is not appearing on a certain workstation!

There are seven more Application object Property Pages which will be discussed after the snAppShot section because this is generally the utility they are used with.

NAL snAppShot

Earlier we discussed how to distribute a simple application. Now, we will discuss how to distribute a "complex" application. For our purposes here, a complex application is defined as one which requires Registry changes, INI file changes, and DLLs at the workstation. With the release of NAL 2.0, a separate administrator utility called snAppShot was included to facilitate this type of complex distribution. snAppShot will:

  • Take a snapshot of the machine you're running snAppShot on (a "before" picture).

  • Ask you to install the application you want to distribute.

  • Take another snapshot of the machine to discover the changes made by the application's installation program (an "after" picture).

  • Generate an Application Object Template (AOT) with the changes between the "before" and "after" snapshot. An AOT is simply a file which is readable and editable with the NWAdmin utility.

This snAppShot-generated AOT file is then used when creating the Application object in NWAdmin. All of the discovered application dependencies (e.g., Registry settings, INI file entries, DLLs, application files, etc.), in addition to any others you set, will then be part of the application distributed to users.

Note: snAppShot (which is installed by executing SETUPSNP.EXE) should be run on a workstation similar to the workstations to where you'll be distributing the software. The application you want to distribute should not have been previously installed on this workstation because it would already have the Registry and/or INI settings, DLLs, etc. on it. Ideally, you should set up a dedicated "clean" workstation for using snAppShot and should thoroughly test this process in a lab environment before actual implementation. It would be beneficial to have a quick way to revert back to the original workstation configuration (e.g., by using a utility like Ghost). You can find out more information regarding the Ghost software utility at http://www.ghostsoft.com.

In the following example, let's assume we will be distributing the client side portion of Microsoft PowerPoint to the default directory of C:\MSOFFICE. Run C:\SNAPSHOT\SNAPSHOT.EXE from the administrator's workstation, follow the prompts, and fill in the required information (italized) as follows:

  1. Enter a name for the application you will install. This will be the Application leaf object name in the Tree.

  2. Enter a short description for the application. This short description will be used as a caption for the icon and is what the user will see in the NAL or NAL Explorer Window.

  3. Directory and file name for the template you will create. This is where the AOT file will be created and stored. Installing to a network drive allows others to use this AOT file and is easier for centralized management.

  4. Directory for application files (network directory recommended). This is where FIL files will be stored. As mentioned earlier, snAppShot keeps track of all the files that an application's Setup program installs to the workstation, copying and storing them as a series of FIL files. Additionally, a FILEDEF.TXT file will be created here, which is a complete listing of the application files which will become part of the AOT.

    It is recommended that you put the application's AOT file in the same directory as the corresponding application's FIL files for organizational purposes. A suggested directory structure is:

    \\file_server_name\<volume<\AOTFILES\Windows31\<appname< \\file_server_name\<volume<\AOTFILES\Windows95\<appname< \\file_server_name\<volume<\AOTFILES\WindowsNT\<appname<

    Windows 95 and Windows NT applications may not need to be placed in separate directory structures.

    It is not recommended to place the FIL files on the SYS volume, as they can be very large (depending upon the size of the application you're distributing) and could fill the SYS volume very quickly.

  5. Modify the lines for your Windows drive and Boot drive, if necessary. The default for both is C:

  6. Include/Exclude Screen. You would modify these settings to set the scope of discovery for snAppShot. For example, if you were installing this application to a network drive, you would need to include this in the Drives to Include box because, by default, snAppShot only watches the C: drive for files copied. If you did not want snAppShot to track certain files (e.g., DLLs which may already be more current on user workstations), you would specify this in the Exclude Files box. Again, understanding your application and any customization you may want is necessary here and why lab testing is important.

    snAppShot is now ready to take a "before" picture of your workstation, incorporating the discovery scope set in step 3, INI files, icon groups, and the Registry. When this process is complete, you are ready to run the application's Setup program (step 7).

  7. Run Setup Program.

    You do not have to use snAppShot to run the setup program. You can go to the Start Menu or anywhere else and run it, or make changes by hand.

  8. Waiting for Setup to Finish.

    This screen indicates the application's setup is complete. Select Next to continue.

  9. Install Directory. Enter the path where the software was just installed. This is for the creation of installation macros. Macros are a property of Application objects and will be discussed later. Although Macros are not required, they are a very powerful component of NAL.

    snAppshot now performs an "after" snapshot, discovering the changes made during the application's setup in step 4, the scope of discovery set in step 3, and the macro information from step 6, storing this information in the AOT file.

  10. Completed. The snAppShot process is finished when a "Completed" window is displayed, showing you a summary screen of where the template file (AOT) and the application files have been placed. Now the Application object needs to be created in NWAdmin, using this AOT file.

Creating the Application Object from the AOT File

The steps for creating the Application object are essentially the same as the ones we used to create the "simple" Application object. However, you must select "Use this wizard with an application object template". This will gray-out the "Application object name" and "Path to executable file" options we manually filled in during the simple application distribution and will instead prompt you through the rest of the creation process (steps are numbered):

  1. Use the Browse button next to the "System application templates" window to select the AOT. Notice the Object name and Description you previously assigned are automatically filled in.

    You can customize where NWAdmin (technically the NAL Snap-in) will look by default when you browse here for AOT files. This is done by creating the file APPSNAP.INI in the same directory as the snap-in. For Windows 95 this would be SYS:PUBLIC\WIN95 and for Windows NT this would be SYS:PUBLIC\WINNT. Then enter the following:

    [Aotfiles] Path=\\file_server_name\<volume<\AOTFILES (assuming the suggested subdirectory structure in Step 2 of the snAppShot section)

    Now you are most of the way to the AOT file and only need to browse down a level or two (depending upon the structure you have set up). The default location to look for AOT files is ..\NALLIB\AOTFILES, which would translate to SYS:PUBLIC\NALLIB\AOTFILES).

  2. Target Directory. This is the directory on the workstations where the application will be installed.

  3. Source Directory. This is the directory where the application FIL files were just placed (Step 2 of the snAppShot section).

    A summary screen is then displayed and the Application object is created, using the AOT file. You will notice the creation of the Application object here takes longer than during the simple distribution. This is because the AOT file is being read into the Application object.

Remaining Property Pages

Now, let's discuss the seven Application object Property Pages which we didn't cover earlier. Many people question how to use these seven Property Pages. As you will see, snAppShot does most of the work for you by "discovering" these application dependencies, giving you a point of reference which you can customize later, if necessary.

Administrator Notes Property Page. An informational text field (not viewable by users) which can be used to track changes made to the Application object or any other special requirements. The NAL Snap-in automatically fills in which AOT file was used to create this Application object here, for informational purposes.

Registry Settings Property Page. These are the Registry settings which will be made when this application is distributed to workstations, as discovered by snAppShot. You can manually make any necessary modifications, additions, or deletions to these Registry settings for customizing this software distribution, if necessary, as you would using REGEDIT.

INI Files Property Page. These are the INI files which will be customized when this application is distributed to workstations, as discovered by snAppShot. Again, you can manually make any necessary modifications, additions, or deletions for customizing this software distribution, if necessary.

Application Files Property Page. This contains a list of files required to run the application (which correspond to the FIL files stored on the volume, referenced in FILEDEF.TXT), as discovered by snAppShot. If there was a certain file you did not want copied down to the workstation, you would simply delete it from here. Also, if during your testing process, you discovered there was a conflict with DLLs, you could remove them from here and send down all DLL files necessary for the workstation in a separate distribution. Notice the use of %SOURCE_PATH% and %TARGET_PATH% here which are used by Macros (next).

Macros Property Page. The SOURCE_PATH points to the location of the FIL files and uses a drive mapping. Therefore, users would need to have this same drive mapping for the distribution to be successful. You might consider changing this to a UNC path to eliminate users having this drive mapping. TARGET_PATH points to where the application will be installed.

Macros are a very powerful NAL feature. They allow you to use this page to manage the macros that are used in these other Application object locations:

  • Path to Executable File

  • Command Line Parameters

  • Working Directory

  • Drives to be Mapped Path

  • Ports to be Captured

  • Registry Settings Property Page

  • INI Files Property Page

  • Application Files Property Page

  • Text Files Property Page

  • Icons/Shortcut Property Page

If you set up an application which used the %TARGET_PATH% macro throughout several of these locations and this path changed, you would simply change the TARGET_PATH here, which would then be reflected throughout the other locations.

As another example, you could export this Application object (from the Tools menu in NWAdmin) to another AOT and then use NWAdmin to create another Application object for another server, import the exported AOT, and simply change the SOURCE_PATH to reflect this new server.

Note: A future release of NAL will have a utility to copy Application objects from one container to another and then make the necessary modifications. Until then, this is a solution.

Text Files Property Page. Records changes to workstation files such as CONFIG.SYS and AUTOEXEC.BAT, as discovered by snAppShot.

Icons/Shortcuts Property Page. These are the icons which will be created at the workstation when this application is distributed, as discovered from snAppShot. You should remove these if you do not want the user accessing this application from shortcuts but rather you want them running the application only from within NAL.

Now, when a user logs in who is associated with this Application object, PowerPoint will be installed to their workstation (incorporating the changes from the AOT file), and subsequently launched, if you:

  • Set this Application object's "Path to Executable File" as C:\MSOFFICE\ POWERPNT\POWERPNT.EXE.

  • Customize any other necessary Properties from the Property Pages discussed above.

  • Associate this Application object to the appropriate container, user or, group.

Note: This distribution will have no trouble occurring on Windows 95 workstations because there is no security with Windows 95. However, if this application is being distributed to Windows NT (which does have local security), the user will need to have Administrator privileges in order for the distribution to be successful. A future release of NAL will resolve this issue.

Summary

This AppNote has shown you the power of NAL and has given you the background necessary to start distributing applications with NAL. NAL is a superb example of the power of NDS. It is entirely practical and has been demonstrated that applications can be distributed worldwide to thousands of users within a day.

* 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