Novell Home

Disconnected NAL

Novell Cool Solutions: Feature
By Steven Wootton

Digg This - Slashdot This

Posted: 19 Mar 2001
 

Current Version: ZENworks for Desktops 3

Overview

One of the frequently requested features for the Novell Application Launcher (NAL) arrived in ZENworks for Desktops 3. Administrators have long used the ability of NAL to distribute and administer applications based on Novell's directory administration. However, this functionality has always been limited to users that are physically attached to the Local Area Network. With the introduction of the new disconnected feature, mobile users can use NAL while physically disconnected from their network.

This article discusses the nuts and bolts details of the Application Launcher Disconnected Feature.

Disconnected NAL allows users to be able to have most of their regular NAL functionality while not connected to their NDS tree. These disconnected features include:

  • Launch
  • Distribute
  • Verify (self-heal)
  • Uninstall

At the very least NAL will attempt to perform any pre/post login or distribution scripts, map drives etc. It is left up to the administrator to setup their application objects to properly take advantage of the new disconnected feature.

Disconnected State

NAL 3.1 is currently dependent on the Novell Client32 to determine its connection state. A workstation can be in any of the following connection states:

  • Completely connected
    Can send/receive packets; connected to an NDS Tree and at least one NDS server.
  • Semi Connected
    Connected to a physical LAN and connected to some but not all NDS trees.
  • Disconnected
    No physical connection to a LAN, or not connected to any NDS trees.

The NAL icon in the system tray will change to a disconnected icon only when it determines that it is in a purely disconnected state. This means that as long as at least one tree is found on the network, the icon should stay in a connected state. Once in a disconnected state, the user must either manually restart NAL or select "Work Online" from the NAL context menu. Since the Client32 is not designed to work when disconnected, it will cause a system hang as it tries to contact its network resources. Therefore, NAL should avoid contacting the client once it has determined that it is disconnected. NAL checks its overall connection state upon the following events:

  • NAL startup
  • Application Launch/Distribution
  • When a user right-clicks on the system tray icon to show the context menu.
  • When a user right-clicks on the main NAL icon on the desktop to show the context menu.
  • During a manual or timed refresh.

Please note that NAL will not check its connection state during its regular "heartbeat" every 2 seconds, as this would cause unnecessary network traffic on the LAN.

NAL uses the following steps to determine if it is connected or disconnected to the network. Once any of the steps fail, the process will not continue to check other connection information. It will also set the registry entry specified in Step 1 to be "FALSE". NAL does this to prevent the Client from constantly retrying its network resources, which will cause a system hang for up to 10 seconds.

  1. NAL first checks HKLM\Software\NetWare\NAL\1.0\Connected to see if it is set to be "TRUE" or "FALSE". If set to "FALSE" NAL will immediately return that the connection is not up. If the registry entry does not exist or is set to be "TRUE" then it will go on to Step 2.
  2. NAL next asks the client if it is installed and responding. This is accomplished by calling its initialization API call "NWCallsinit". If this call fails then the connection is not up. This means that if the client is not installed it will always be in a disconnected state.
  3. NAL next scans for any connections to NDS trees. If zero are found then NAL will immediately return that the connection is not up.
    Note: this means that even though a user might still be connected to a network, if an NDS tree cannot be found NAL will go disconnected.
  4. NAL next checks the local connection table to make sure that at least one connection reference to an NCP server can be found. This is not limited to NetWare, any NDS server should respond to this query.
  5. Once it has been determined that at least one connection reference exists, NAL will now get the default or primary connection reference.
  6. Finally NAL will get a connection handle to the default connection reference and ask the connected server to return its Date and Time. If this request fails then NAL will return disconnected.

These final steps are necessary because although there may be a connection reference, sometimes these connections can be cached from previous sessions. The retrieval of the date and time ensures that the server is actually out on the network alive and kicking.

Troubleshooting

Engineering added several debug statements to this routine. To view these debug statements add the following registry key: HKLM\Software\NetWare\NAL\1.0\Debug. Add the "Library" registry value under the newly created key. Now restart NAL and check for a newly created file called ZAPPLIB.LOG (usually found in your temp directory).

Note: Be sure to delete the registry value when you are finished troubleshooting, otherwise this file will continue to grow forever.

Configuration

By design the default configuration should be adequate for most administrators. Any application distributed using NAL 3.1 will automatically get enough information cached to the local drive to be able to launch and uninstall the application while disconnected. However, there are always exceptions that need to be handled. Some administrators may rely heavily on network-dependent applications that may not make any sense to have available while disconnected. These applications include:

  • Database Client applications
  • Some Client Server applications
  • Any application that depends on a network mapping or print capture
  • Any application that relies on a persistent connection to any network

In these cases NAL has the ability to have these applications NOT be available while disconnected. This is accomplished by unselecting the "Disconnectable flag" found on the Identification->Icon Page on the ConsoleOne ZfD3 application snapin page. Please note that although the application will not be available while disconnected, a portion of the app will still be cached so the uninstall feature can still be performed. Additionally, a warning message has been added to ConsoleOne warning the administrator after modifying a network dependent application feature that the application is marked "disconnectable". Please note that not all NDS dependent macros will work while an application is disconnected. %CN% is supported.

Probably the most overused and least understood configuration item related to disconnected NAL is the "Force Cache" check box found on the association page. Many administrators mistakenly believe that in order for an application to be able to be "taken on the road" that they need to check this box. This is not true, this check box actually will cause all the install files necessary to redistribute or reinstall the application to be placed on the local hard drive. Although this step is necessary to be able to "Verify" or "Self heal" while disconnected, it also has the effect of eating up valuable hard disk space. These file are compressed while in the cache.

In past releases of NAL, administrators used the Version Stamp application object attribute to help determine when a new version of the application object is to be rolled out. Once an administrator changed the version stamp, NAL would re-distribute the application the next time it was launched. This attribute was changed in NAL 3.1 to be called the Version Number, and while this new attribute retains the functionality of the old version stamp, it forces the administrator to use a number that can be used to determine an application's age. The later the number, the more up-to-date the application object is. This is needed by disconnected NAL to determine which application object to use when multiple copies exist in several caches. After upgrading to NAL3.1, all existing application objects will NOT get forced down again. The default version number will be set to be "0".

The administrator has been given the following new Launcher Configuration Settings to help configure Disconnected NAL:

Auto-Start NAL -- When set to "yes" this causes naldesk.exe to place a shortcut in the user's Startup folder. This causes Windows to launch the application the next time the system starts its user session.

This feature is useful for laptop users that need to have NAL auto start while disconnected. It is recommended to disable the nalexpld.exe or nal.exe programs in the login script while this feature is in effect. This will avoid a second copy of the NAL window or explorer to attempt to start every time the user logs in while connected to the LAN.

The shortcut points to either nalwin32.exe or naldesk.exe depending on which program (nal.exe or nalexpld.exe) was originally launched. Since disconnected users have no access to the network to utilize the nalstart.exe update features, these shortcuts point to the final executable. Here is the normal path of execution when NAL launches.

NALEXPLD.EXE > NALSTART.EXE > NALDESK.EXE

NAL.EXE > NALSTART.EXE > NALWIN32.EXE

Typically administrators use the NAL window when they want to completely lock down their workstations. Some even set it to be the shell instead of EXPLORER.EXE. Administrators use the NAL Explorer (NALDESK.EXE) when they want to take advantage of the default Microsoft Explorer interface. For example, when they want icons to appear/disappear on their desktop, start menu, quick launch bar, and system tray.

Enable Manage Applications -- This setting is turned off by default. This feature is designed to be used by advanced users only.

Once enabled, users will get a new context menu item labeled "Manage Applications". As the name implies, users can manage their NAL delivered applications. Users can Install, uninstall and cache their associated applications. When caching an application using this dialog, both the launch and install portions of the cache will be brought down. Users can also move applications from one drive's cache to another drive's cache. Users can also remove applications from a cache to save disk space.

Please note that if the application has been marked to be force cached by the administrator, the application will not be able to be removed from the cache using this dialog.

Default Cache Location -- This setting is used to determine where to place the master cache. The master cache is used to store information necessary to run applications that have already been distributed while connected to a LAN.

Other caches also store application object information but they are more static. The master cache is constantly being checked against the live network so the user can go disconnected at any time with little interruption. The default cache location defaults to the user Windows System drive. Typically users have extra room on this drive to handle temporary files. Administrators can change this drive to be any drive letter they choose to select. Once changed the cache will get copied to the new area during the user's next manual or timed refresh.

Please note that the old cache area will NOT get cleaned up automatically.

Process Application Function

When an application gets launched for the first time, NAL performs a very complicated series of tasks to get the application installed and ready to launch. With the introduction of disconnected NAL, some new logic was needed. NAL must now determine what files and application object information to process every time an application is launched. NAL relies heavily on the new version number to determine the proper application object to process. Here are the new steps NAL performs each time an application is launched:

  1. First determine if the application is associated to the user in a connected tree. If the application is NOT associated, we assume the icon must have come from a cache (typically a CD). We then tell NAL to process the application from the cache.
  2. If the application is associated, we need to get the version number of the application on the network. We then compare this number against the version found in the local cache (if it exists). If the version numbers equal, we then use the cached version because it's faster and does not use valuable network bandwidth. If the cache version is greater than the network then we use the cached version. If the network version is greater then we process the application from the network.

    Note: because of our dependence on the version number, administrators need to make sure the number gets bumped each time an app object gets modified. This is especially important if portable caches are being used on removable media!
  3. Once an application has been distributed we now cache the launch information necessary to be able to launch the application when disconnected. This information takes very little disk space, usually about 32K. Caching this information is also necessary to be able to know what files to remove when the application gets uninstalled.

The Cache

Going forward, the nalcache will become a component that NAL will depend on heavily. Nalcache is required for the following features/enhancements:

  • Ability to launch applications while disconnected
  • Ability to uninstall applications while both connected and disconnected
  • Ability to Conserve network bandwidth while launching an application
  • Ability to Conserve network bandwidth while retrieving the application list from NDS (ZfD 4.0) -- during a NAL Refresh.

As stated above, the default location of the cache is found on the local drive that contains the System32 directory. The directory is called "NALCACHE" and should be hidden. This cache can store all the information necessary to launch, verify, and uninstall an application.

Each application stored in this area can have two types of caches. The first, more commonly found cache is called the "Launch Cache".

Launch Cache

This cache stores all the information needed to be able to launch or uninstall an application while disconnected. Usually the amount of space needed for this cache is very small. All applications launched through NAL 3.1 will at least have a "Launch Cache" even if they are marked not disconnectable.

The uninstall feature relies on the launch cache so this cache must exist for every application that has been distributed. If this cache gets removed manually, NAL will put it back down during its next refresh. Most of the "Launch Cache" also gets updated every manual or timed refresh. The only attributes that do not get updated every refresh include:

  • Files
  • Ini File Settings
  • Shortcuts
  • Registry Settings

With Support Pack 1, NAL will only bring down these attributes if the application object has been modified in any way (including adding a new association). This is an easy way for NAL to skip updating any applications that have not changed in any way.

These settings need to stay the same as when the application first got installed so the uninstall will remove only the items NAL added. If we changed them every time an administrator added a new file then NAL would fail trying to remove a file that never got distributed. If an administrator adds a new file and want to make sure the user will get it uninstalled, the administrator will need to bump the version stamp. The next time the application gets launched the new version should get put down and a new cache will overwrite the old one. The following table gives a brief description of the various files that may show up in the launch cache:
(Note: * indicates that the attribute is not kept up to date every refresh.)

File Name

Description

DSATTR.BIN

Contains all of the DS attributes of the application object

FOLDERS.BIN

Contains the list of folder locations where the application should show up in the explorer

COMPLETE.BIN

Last file to be written out, if this file doesn't exist then NAL will assume it's a bad cache and re-cache it. The file stores the complete NDS name of the application object.

STRM1.BIN

Stream file containing the application object's Icon

STRM2.BIN

Stream file containing all text file modifications

STRM3.BIN*

Stream file containing all files to be copied to the workstation

STRM4.BIN*

Stream file containing registry settings to be modified during initial distribution

STRM5.BIN*

Stream file containing ini file settings to be modified during initial distribution

STRM6.BIN*

Stream file containing shortcut files to be modified during initial distribution

STRM7.BIN

Stream file containing all macros (usually just source path macro)

STRM8.BIN

Stream file containing schedule information

STRM9.BIN

Stream file containing system requirements inventory information

STRM10.BIN*

Stream file containing administrator notes

STRM11.BIN

Stream file containing shutdown script

STRM12.BIN

Stream file containing startup script

STRM13.BIN*

Stream file containing registry settings to be applied always

STRM14.BIN*

Stream file containing ini file modifications to be applied always

STRM15.BIN*

Stream file containing files that are copied always

STRM16.BIN

Stream file containing text file modifications that are modified always

STRM17.BIN*

Stream file containing icons that are modified always

STRM18.BIN

Stream file containing environment settings

STRM19.BIN

Stream file containing pre distribution scripts

STRM20.BIN

Stream file containing post distribution scripts pre-install schedule

STRM21.BIN

Stream file containing pre schedule information

Install Cache

The second type of cache stored in the NALCache is called the "Install Cache". This cache stores all the application files that get copied down to the workstation as part of the distribution. This cache takes up a lot more space than the launch cache, especially applications like MS Office 2000. These files are compressed and renamed in the cache so they are not easily recognizable. We used the following naming convention when caching these files.

Under the launch cache an "install" subdirectory will appear. This directory holds the install cache. Each file will follow the naming convention #nal.#.

  • The first number is simply the number of the file found in the copy file stream.
  • The second number after the "nal" is the attribute number as returned by Windows.

We use the attribute number to restore the file's original attributes when the file gets distributed. The original name of the file is stored in the file copy stream in the launch cache. The compression uses a proprietary compression based on industry standard ZLIB compression.

This cache should only get created if the application is marked "Force Cache" or "Distribute Always". If any application is marked "Distribute Always" we have to assume that the administrator will want to force down the application regardless of whether the application is disconnected or connected.

Removable Media

The disconnected feature comes with a nice sub-feature which allows users to be able to launch and verify applications found on any removable media. These media can include a removable disk (ie JAZ or ZIP) but typically is used with compact disks or DVD drives. This ability makes it possible for administrators to burn a CD, drop it in the mail, and have a mobile user actually install and use an application completely isolated from the home network.

The user simply takes the CD and puts it in the drive. An autorun.inf file automatically causes NAL to kick off a refresh (NAL must be running). The refresh should find the CD in the drive and display the icons based on their location masks. There is no concept of user association with this functionality. The assumption is made that physical ownership of the CD means the user has all rights to use that application object. If the removable media is not a CD, then the user may need to kick off a single manual refresh to see the new application icons. System requirements are still checked so some icons may not be displayed that don't match the workstation resources.

To setup a removable cache simply follow these steps:

  1. Go to the "Tools" menu in ConsoleOne and select "Application Launcher Tools". Then select the "Create Virtual CD" menu option, which should start the "Create Virtual CD" wizard.
  2. The first dialog is designed to accept a list of pre-existing applications that will be included on the virtual CD. Make sure you choose applications that are marked disconnectable.
  3. You can select the locations where you would like the disconnected icons to appear. Even the force cache item is available if you want the install files forced down to the user's local drive to allow self-healing.
  4. Now select the "Next" button and select a temporary area to store your virtual CD.
  5. The days to disassociate feature is useful when the administrator would like to force the user to periodically put the physical CD back in the system to prove ownership. If the user cannot produce the physical CD, the application will get automatically uninstalled. If the number of days is not specified then the application will never get disassociated. (Works much better post SP1.)
  6. After pressing the "Finish" button you should now see a hidden "Nalcache" subdirectory. Simply move this directory and the autorun.exe, and autorun.inf files to the root of your removable media, and your virtual CD should be complete.

    Note: the autorun files are not necessary for non-CD removable media solutions.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell