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.
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.
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:
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.
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.
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.
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.
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:
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.
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).
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.
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.
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.
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.
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.
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:
Novell Client and Application Launcher/Explorer: The Novell® ClientTM must be installed on the terminal server so that users can log in to NDS when they access the terminal server. Application Launcher/Explorer should be included in each user's login script so that it is started when a user logs in to NDS. For additional information about starting Application Launcher/Explorer, see Starting Application Launcher and Application Explorer.
Software Distribution: You can configure an Application object so that the application will be installed to the terminal server one time (in a standard location) or once for each user (in a non-standard location such as a user directory). The method you choose depends on the application requirements and how you want to utilize the terminal server's resources. To install a Microsoft Windows Installer package (.MSI and associated files) on the terminal server, the user must be a member of the Administrators group. Microsoft Windows Installer does not allow non-administrator users to do installations from a terminal client session.
User Associations: An application must be associated with terminal server users through their User objects and the Application object in NDS. This process is identical to associating the application to non-terminal server users.
Multiple Users with the Same NDS Username: If you have multiple users on the same terminal server who log in to NDS via the same User object, you need to make sure to configure Application Launcher/Explorer to not remove the icons from a user's desktop when he or she exits Application Launcher/Explorer. Otherwise, the icons will disappear from the desktops of all users who are logged in through the same User object. This is configured through the Application Launcher/Explorer's Enable Automatic Icon Cleanup option (ConsoleOne > User object > Application Launcher tab > Launcher Configuration page > Edit > User page). For additional information, see Configuring Application Launcher/Explorer in Setting Up Application Launcher/Explorer in Application Management in the Administration guide.
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.
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:
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.
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.
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.