Planning Application Management Deployment

Before you begin deploying Application Management, you should review the sections listed below. These sections provide information regarding issues such as where you should install the Application Management software, how you should organize Application objects in NDS, where you should store application installation files, and whether you should use Novell® Application LauncherTM or Application Explorer.


Selecting NDS Trees and Network Servers

Application Management requires schema extensions to NDS to support new NDS objects and properties. If you have more than one NDS tree, you should extend the schema of all trees where you want to implement Application Management. The installation program lets you extend the schema of one tree at a time. To extend a tree's schema, you must 1) be authenticated to the tree and 2) have Admin equivalent rights to the root.

You also need to decide which servers to install the Application Management software to. The Application Management software consists of three main components: the Application Management snap-in for ConsoleOne®, the snAppShotTM utility, and the Application Launcher and Application Explorer applications.

When you install the Application Management software to a server, all three components are installed. You cannot install specific components only. Because of this, you will want to install the software to any server where:

The Application Management software requires approximately 28 MB of free space on the server.

The installation program lets you install to any servers located in the NDS tree you've selected.


Organizing Application Objects in NDS

Every application you distribute to users must have a corresponding Application object in NDS. The Application object lets you determine the characteristics and behaviors associated with distributing, caching, and uninstalling the application.

When deploying Application Management, you need to consider where to place Application objects in NDS. The primary principle to follow is that an Application object should be placed in a container at the same site as the application's users. The following two sections provide examples:


Single Site

If your NDS tree encompasses one site only, you can place Application objects in any container. For example, if you have a small site consisting of one or two organizations, you may want to create a common APPS container.


Common APPS container under an Organizational Unit

If your site is divided into many organizations, you may want to create a general APPS container for your corporate-wide Application objects and then create APPS containers within each organization container for the organization-specific applications.


Common APPS container and organization-specific APPS containers


Multiple Sites

If your NDS tree encompasses several sites, we recommend that you place your Application objects in the NDS tree at the same site as the users who will be using them. Typically, this will mean that you have APPS containers at multiple sites, as shown below.


APPS containers at three different sites

In the above example, the NDS tree has been established geographically, with each Organization container comprising a different site. Ideally, this is the most efficient way to organize your NDS tree. If you have not organized your NDS tree by geographical location, you can still place Application objects in the same location as the users who will access them, but you will need to discover these locations.

Undoubtedly, you will have an application that you need to distribute to users at all your sites. In this case, you should create multiple Application objects (at least one at each site) for the application.

When giving users access to the application, you would associate the users with the Application object located at their site. Ensuring that users are accessing applications at their own site speeds user access to the applications and reduces cross-site network traffic.

If you have users who travel from site to site, you can set up site lists for any applications you want them to have access to at all sites. An application site list ensures that the user is accessing the application from the site where he or she is located, regardless of which Application object the user has been associated with. For more information about site lists, see Application Object Settings in Administration.


Storing Application Installation Packages

An NDS Application object contains the information required to distribute the application to users. Most applications you distribute will also require either a snAppShot installation package (.AOT, .AXT, .FIL, and .TXT files) or a Microsoft* Windows* Installer package (.MSI and associated files). An installation package contains the actual files that Application Launcher/Explorer will use to install the application to users' workstations. For Application Launcher/Explorer to access an installation package, the package must be located on a network server.

When deciding where to store installation packages, consider the following:


Location of the Application's Users

The same principle that applies to Application objects applies to application installation packages. A package should be located at the same site as the application's users. This reduces cross-site network traffic and decreases the amount of time required to access the application.


Multiple sites, each with the same application installation packages

In the above example, App1 is used at both the Bangalore and Provo sites, so App1's application installation package is stored at each site. The same is true of App2 (Provo and San Jose) and App4 (Bangalore and San Jose).


Application Disk Space Requirements

Disk space requirements for installation packages vary. However, many packages can require substantial amounts of disk space. For example, a package for Microsoft Word requires approximately 400 MB on a server. You need to ensure that the server where you want to place your installation packages has sufficient disk space.


Fault Tolerance and Load Balancing Requirements

If you want to use Application Management's fault tolerance and load balancing features, you will need to store an application's installation package on multiple servers. In the following example, App2 and App5 are stored on two different servers at the San Jose site.


Multiple sites, each with multiple servers to support fault tolerance and load balancing

You should ensure that each server has sufficient disk space for the applications. For more information about fault tolerance and load balancing, see Application Object Settings in Administration.


Using Application Launcher or Application Explorer

To receive distributed applications, users must have either Application Launcher or Application Explorer running on their workstations.

Both Application Launcher and Application Explorer can be used on Windows 95/98 and Windows NT*/2000 workstations. The main difference is that Application Launcher can replace the Windows desktop, providing greater administrative control of users' workstations, while Application Explorer extends the Windows desktop and allows users to access Application objects from multiple locations (Quick Launch toolbar, system tray, desktop, and so forth).

Depending on your needs or your users' needs, you may want some users to run Application Launcher and some users to run Application Explorer. You can accomplish this by configuring users' login scripts to launch the appropriate application executable. See Starting Application Launcher and Application Explorer for more information.

IMPORTANT:  Users who plan to run in disconnected mode (disconnected from NDS) must connect to NDS and the network at least one time to have Application Launcher/Explorer copied to their computers.

Users should not run both Application Launcher and Application Explorer on the same workstation at the same time, unless you run Application Launcher as the Windows shell and then start Application Explorer using the I/ startup switch (NAL.EXE /I) through the login script.

For information about using Application Launcher as the Windows shell, see Using Application Launcher as the Windows Shell in Setting Up Application Launcher/Explorer in Application Management in the Administration guide.

For information about Application Explorer startup switches, see Application Launcher/Explorer Command Line Switches in Setting Up Application Launcher/Explorer in Application Management in the Administration guide.


Associating Applications with Users or Workstations

To give users access to applications, you associate the applications with the users or with the users' workstations. When you associate an application with a user, the application is available to the user regardless of the workstation from which the user logs in to NDS. When you associate an application with a workstation, the application is available on that workstation only.

Associating applications with users is the most common way to distribute applications. If you choose to associate applications with workstations, you should be aware of the following:

For more information about associating applications with users or workstations, see Distributing Applications in Administration.


Distributing Applications in a Terminal Server Environment

Application Management supports application distribution to users running in a Microsoft Windows Terminal Server or Citrix* MetaFrame environment. When using a terminal server, you should consider the following:


Metering Software Licenses

Application Management integrates with Novell Licensing Services (NLS) to enable you to track an application's usage and comply with the application's license agreement. When a user launches an application that has been configured as part of NLS, Application Launcher/Explorer checks to make sure that a license is available before running the application.

To use Application Management's software metering, you need to:

Because NLS administration is performed through NetWare Administrator, software metering is not available in a pure Windows 2000 environment.

As you install NLS, you should follow the installation and deployment guidelines provided in the NLS documentation. NLS does not need to be installed before you deploy Application Management. You can, at any time, start using NLS in combination with Application Management to meter software licenses.


Reporting Application Management Events

Application Management supports reporting on the success or failure of the following events:

The above events can be recorded using one or any combination of the following reporting methods:


Sending Events to a Database

Application Launcher/Explorer can record events to most ODBC-compatible databases, provided:

ZfD includes a Sybase* database that you can install. Sybase is also used for the Workstation Inventory database. If you plan to use a database for Application Management reports and you also plan to use Workstation Inventory, you can use the same database installation for both purposes.

NOTE:  While the same database installation can be used for both Application Management and Workstation Inventory, each component still uses its own database file. Application Management creates a NAL.DB database file and Workstation Inventory creates a MGMTDB.DB database file.

Because the main requirement for Application Management reporting is that the database be at the same site as the users, you should follow the instructions provided for Workstation Inventory to deploy your databases, and then choose one or more database to use for Application Management reporting. For information about Workstation Inventory deployment, see Workstation Inventory.

The Sybase database installation requires approximately 19 MB on a network server. However, as with all reporting databases, the database can expand rapidly to consume large amounts of disk space.

Detailed instructions for setting up database reporting are included in Setting Up Database Reporting.


Sending Events as SNMP Traps

If you use a management console to collect SNMP traps, you can have Application Launcher/Explorer send SNMP traps to the console. The use of SNMP traps requires the following:

Detailed instructions for setting up SNMP traps reporting are included in Setting Up SNMP Trap Reporting.


Sending Events to a Log File

You can have Application Launcher/Explorer record events to a log file. This can be an individual log file located on the user's workstation or a common log file on a network server. When using a common log file, users must be given Read and Write rights to the log file, but Application Launcher/Explorer will automatically authenticate them to the log file location.

Detailed instructions for setting up log file reporting are included in Setting Up Log File Reporting.