Using ZENworks to Distribute and Manage Applications on a Network
Articles and Tips: article
Product Manager
Novell, Inc.
01 Oct 1998
All of that great functionality from the Novell Application Launcher is now included in ZENworks, along with new help desk and remote control features to make the network administrator's job easier and less time-consuming.
- Introduction
- Application Distribution with ZENworks
- Help Desk Utilities
- ZENworks' Remote Control Utility
- Summary
Introduction
Novell ZENworks is directory-enabled workstation management software that lets you more efficiently manage your network's applications and Windows workstations, thus reducing network administration costs. ZENworks incorporates the technologies previously offered as Novell Application Launcher and Novell Workstation Manager, along with a new remote-control help desk utility.
The name ZENworks stands for Zero Effort Networks, since it reduces the costs and complexities of maintaining network PCs and delivers zero effort networking for users. With ZENworks, you can centrally create and manage policies and mandatory user profiles with the NetWare Administrator (NWAdmin) utility and Novell Directory Services (NDS). ZENworks automatically creates hardware inventories for all your Windows NT and Windows 95 workstations in NDS. It gives you the tools you need to centrally (or decentrally) distribute, manage, and update applications on Windows-based workstations across your network.
This is the third in a three-article series about implementing ZENworks in a NetWare network. Previous AppNotes covered how to install the product, how to use it to perform a hardware inventory, and how it can help manage the various aspects of users' desktop configurations.
This AppNote looks at how ZENworks simplifies application distribution and management, and how its help desk utilities can help users contact the appropriate individuals for support, and how support personnel can use the remote-control feature to resolve problems without having to leave their desks.
Application Distribution with ZENworks
Perhaps the largest cost associated with managing networked workstations is distributing applications to those workstations. Even if the application is server-based, application files and registry entries are usually still required to be made at the workstation for the server-based applications to run. The Novell Application Launcher (NAL) decreases the costs associated with application distribution and management by leveraging NDS.
The methodology behind NAL is to use the snAppShot utility, which ships with ZENworks, to create a template that contains a listing of every modification that must occur at the workstation for an application to run. This includes application files, registry entries, *.INI files, and so on. The snAppShot utility takes a "snapshot" of a workstation, prompts the administrator to install the application, takes another snapshot of the workstation after the installation is complete, then compares the two (before and after) to create a template with a precise list of every modification that occurred on that workstation when the application was installed (see Figure 1).
Figure 1: The opening screen for the snAppShot utility that comes with ZENworks.
After starting the snAppShot utility, the administrator first enters the name of the Application Object that will be created in NDS, along with the application icon title that will be displayed to the end-users through ZENworks (see Figure 2).
Figure 2: Specifying the Application Object name and the icon name.
Next, the administrator is asked for the directory where the application installation template (named NETSCAPE.AOT in this example) will be created (see Figure 3). The snAppShot utility will also copy the files that need to be installed on the workstation's local hard drive to this directory while it monitors the application installation.
Figure 3: Entering the location to copy the application files.
The administrator is then asked to select the workstation drives that will be scanned before the application is installed (see Figure 4). This pre-scan will be used after the application installation is complete to determine what changes have occurred on the workstation due to the installation.
Figure 4: Indicating which drives to scan on the workstation.
The snAppShot utility is only run once for each application to create the template that will then be used by NDS to distribute applications. Figure 5 shows snAppShot doing the first scan of the workstation that will be used to create the template.
Figure 5: The snAppShot utility indicates its progress as it performs the first scan of the workstation.
Once snAppShot has done the initial scan/inventory of the workstation, the administrator is asked to install the application (see Figure 6). SnAppShot will monitor the installation and copy every file that is installed to a specified directory. These files will be used during the installation of the application to the users' workstations.
Figure 6: Prompt to run the application's installation program.
The administrator is next asked to input the directory into which the application will be installed on the workstation's local hard drive (see Figure 7).
Figure 7: Inputting the application's install directory.
Once the application installation is complete, snAppShot scans the workstation again to determine the modifications that were made during the installation. A progress screen is displayed during this process.
When the second scan has been completed, snAppShot generates the template that will be used for distributing the application to mass users (see Figure 8).
Figure 8: Generating the application template.
With this template created, the network administrator can use it to create an Application object within NDS that logically represents the application. In this example, we will create the Application objects in the Organizational Unit (OU) named Applications. This is done using the NWAdmin utility by right-clicking on the OU and choosing the Create option, as shown in Figure 9.
Figure 9: Creating the Application object in the NDS tree.
To create an NDS Application object using a template, first select the appropriate option as illustrated in Figure 10.
Figure 10: Selecting the appropriate create option for an NDS Application object.
Next, select the template file (*.AOT) that was created using the snAppShot utility. Enter the location on the users' hard drive where the application will be installed (if the application is to be installed locally). The administrator is also asked to input the location where the template and application source files are stored on the network, as shown in Figure 11.
Figure 11: Entering the source and target locations where the application will be installed.
Before the NDS Application object is actually created, you have the chance to review the configuration settings, as shown in Figure 12.
Figure 12: Final review of the Application object settings before object creation.
Once created, the NDS Application object appears in NDS in the Applications container. Users, groups, or containers are then associated with the Application object. In this example, the New York container has been associated with the Netscape application, which means every user in the New York container will be able to use and access the Netscape application, as seen in Figure 13.
Figure 13: The newly created Application object associations screen.
Once the association has been made between the user and the application, the application's icon is displayed to the end users, as shown in Figure 14.
Figure 14: The Application object's icon as seen by the end user.
The first time the end user double-clicks on the icon, the application is installed, using the template that was created with the snAppShot utility, and then launched. Subsequently, when the end user double-clicks on the icon, ZENworks realizes that the application does not need to be installed and simply launches the application.
ZENworks' Self-Healing Feature
Once the application is installed, ZENworks is able to sense if the configuration of the application has been damaged and is able to automatically heal the application. For example, suppose you are an end user who has been working on a document that must be delivered to your boss by 5:00 p.m. After putting the finishing touches on the document, you try to save but receive an error message that you do not have enough disk space to save the file. And it's 4:55 p.m. by now!
In a panic, you start deleting files from your hard drive to free enough space to save your file. You do not care what files you are deleting. The only thing you are thinking about is getting this document to your boss. In your haste, you delete some of the *.DLL files that are required for Netscape to run. In the typical scenario, the next morning when you attempt to launch Netscape an error will be generated. You will call the help desk and say, "Everything was working last night when I left, but today Netscape will not work and I did not change anything!"
However, if ZENworks is being used to manage the applications, ZENworks detects that Netscape is unable to launch and will automatically attempt to "heal" the application (see Figure 15).
Figure 15: ZENworks can automatically detect if files are missing to run an application.
ZENworks verifies that every modification to the workstation that is required for the application to run is present. In this case, ZENworks will detect which *.DLL files have been deleted, and then copy them to the workstation and launch Netscape. No call to the help desk will be necessary and you will not experience any downtime.
Launch Nearest Application
A new feature of ZENworks is the ability for NDS to seamlessly direct the user asking for an application to the server that is closest to the end user. This functionality is known as Launch Nearest Application. Many organizations have "application" servers on which the applications that are used throughout the organization are stored. Many of these servers are identical, in that the same applications are installed on each server. In this configuration, ZENworks is able to sense where the individual requesting the application is located, and seamlessly instruct the workstation to pull the application from the closest server.
Now using this scenario, a user can travel between locations within an organization and ZENworks will guarantee that the applications are delivered to the end user from the closest server. For example, a user could be in New York City one day and London the next. If ZENworks is being used to manage the applications, ZENworks will automatically deliver the application to the end user from the appropriate location. When in New York City, the user will use the application installed on the server in New York City. When in London, the user will use the copy of the application that is installed on the server in London.
Users will be more productive because they will not be using applications that are being executed from a remote server across a slow link. WAN traffic will be significantly reduced because ZENworks is directing the end users to pull the applications from the servers local to the end users.
File System Rights Assignment
The file system rights that are necessary for an end user to execute or install an application from the server can now be assigned from within the NDS Application object. The rights are granted to the desired users when the assignment is made in NDS. This functionality will be enhanced in the very near future so that the rights are granted when the end user executes the application through NAL. With dynamic rights assignments, end users will not even be able to see the files on the server unless the application is being executed.
Leveraging NDS
While there are competing application distribution and management products in the market, ZENworks stands because it leverages NDS, which is already populated with information such as username, title, and so on. ZENworks does not require another completely separate database to be created and managed for application management.
One of the most powerful features of the application management solution within ZENworks is the ability to use macros to customize the application for each users as the application is distributed. A great example of this is the POP3 e-mail address that must be input within Netscape if users want to use the e-mail features of the Netscape Navigator. Network administrators are faced with a real dilemma since this e-mail address must be unique for every user within an organization.
Within ZENworks, well-known NDS variables such as %LOGIN_NAME, %CN, %USERNAME, and others can be used and ZENworks will input the appropriate values based upon the corresponding user values within NDS. The more data that is in NDS, the more administrators can customize the applications as they are deployed. For example, using the %CN NDS variable causes the users' login name to automatically be put into the POP3 e-mail address field in Netscape. The application is then customized as it is deployed to each user.
Help Desk Utilities
The final component of ZENworks is a set of help desk utilities that helps end users get information to the appropriate individuals that can help to resolve the problem and allows these individuals to remotely troubleshoot the problem through a secure remote control solution.
Accessing Help Desk Information
One of the problems that was identified by Novell as the ZENworks product was being defined was the fact that many end users did not know where to go to get help when problems occurred. And often when the appropriate individuals were contacted, the end users were not able to give the necessary information to troubleshoot the problem.
To resolve these issues, a help request solution was defined and built into ZENworks. The Help Request Solution is configured through the Help Desk Policy in the User Policy Package, as illustrated in Figure 16.
Figure 16: The Help Desk Policy located in the User Policy Package.
The help request system is based on defining policies within NDS that direct end users to the appropriate individuals who can help them when problems do occur. Within NDS, the administrator inputs the name, e-mail address, and telephone number of the individuals that are qualified to resolve problems: this information is then listed under the Help Desk Policy, as seen in Figure 17.
Figure 17: Contact information of appropriate help desk individuals found in the Help Desk Policy.
The Help Desk Policy can be configured so that end users are able to send e-mail for help, telephone for help, or both. In the example above, end users using this Help Desk Policy have the ability to telephone for help and send trouble tickets through the MAPI interface (delivery mode can also be configured for GroupWise).
The front-end application is then delivered to the end users. This is very simple through the application distribution solution within ZENworks. When a problem does occur, end users simply need to double-click the help request application (see Figure 18) and all the information they need to get the necessary help is displayed.
Figure 18: The help desk application object's icon as seen by the end user.
In many cases, the first question asked of end users is "What is your context?" Since most end users do not want or need to know their context within the NDS tree, they are unable to answer this question, making it more difficult for the help desk to resolve the problem. The help request system that is displayed to end users contains the end user's full NDS name and the full NDS name of the workstation which is currently being used (see Figure 19). This information allows the end users to quickly and accurately provide the necessary information for the help desk to resolve issues in a timely manner.
Figure 19: User information previously entered in NDS is displayed in the Call for Help.
If the user is sending an e-mail request, the user's context and the context of the workstation the user is currently using are sent along with the message. This allows administrators to quickly navigate to the appropriate user account and Workstation object in NWAdmin.
Reporting Error Messages
Another one of the problems that was identified by Novell as the ZENworks product was being defined was that when data such as error messages is given to the help desk staff, it is often incorrect. With ZENworks, end users are able to cut and paste the error message into the help request interface which they can then e-mail to the appropriate individual. Because the correct error messages are provided to the help desk, the help desk is able to investigate the problem and resolve the issue quicker and more accurately.
ZENworks' Remote Control Utility
There is a tremendous difference in costs to resolve problems when the help desk is able to resolve the problem without having to physically visit the workstation. The costs of resolving a problem is typically 6-7 times higher if someone from the help desk has to physically visit the workstation. This difference in costs is usually caused by the fact that the help desk technician is stopped by 4-5 additional individuals who have "tiny" problems. Often, what should be a 10 minute service call turns into an hour due to these end user needs.
Concerns About Remote Control Solutions
When we asked the organizations we polled in creating ZENworks if they had contemplated deploying a remote control solution to reduce the costs of troubleshooting and configuring networked PCs, at least one or more of the following objections were voiced:
Existing solutions are not secure.
Existing solutions cause traffic problems.
Existing solutions are difficult to navigate.
Because of these concerns, many organizations were unwilling or unable to deploy remote control solutions. Because remote control solutions can have such a significant impact on total cost of ownership, Novell decided to resolve the above concerns and enable organizations to confidently and effectively deploy remote control solutions by directory-enabling these solutions.
Security. Existing remote control solutions can be secured by defining a password that must be correctly input in order to take control of a remote PC. However, if that password is ever compromised, an individual could control any PC in the organization that has the remote agent loaded. ZENworks resolves this security concern by securing remote control access through NDS. Any individual wanting to remotely control a user's workstation must have rights to the workstation within NDS.
If the individual does not have the necessary rights within NDS to the workstation he/she desires to control, remote access will never be granted. All of the benefits and security of NDS and NetWare are leveraged to provide a secure remote control solution.
Traffic. Some existing remote control solutions depend on the workstations that are allowed to advertise themselves. These workstations broadcast their availability on a regular basis (as often as 1-2 times per minute). A large network with many workstations that implements such a solution will see large amount of traffic suddenly introduced. This additional traffic could require additional segmentation to occur as well as reduce performance for everyone on the network.
The remote control solution in ZENworks does not rely on workstations to advertise their availability. Because an NDS object is created within NDS for every workstation on the network and each object contains the workstation IPX and IP addresses, ZENworks is able to send a packet directly to the workstation to be controlled when remote access is desired. Because NDS knows the exact address of every workstation on the network, workstations do not have to advertise their availability and ZENworks' remote control solution does not introduce any additional traffic to the network.
Navigation. The final concern that is commonly voiced by help desk individuals about existing remote control solutions is that it is very difficult to navigate to the desired workstation. Many of the existing solutions base their navigation and selection of workstations to be controlled on IPX or IP addresses. Unless the organization is better than most at tracking these addresses, the help desk will not know which address corresponds to the individual that is requesting help.
ZENworks is able to resolve this concern by navigating through the NDS tree through the easy- to-use NWAdmin interface to the desired Workstation object. As previously demonstrated, the help request system identifies both the end users' and workstations' contexts, which can then be very easily and quickly located within NDS by the help desk.
Configuring the Remote Control Policy
On Windows 95 and 3.x platforms, a single DLL must be running at the workstation for the remote control to function. This DLL can be executed from the login script or ZENworks without requiring a physical visit to the workstation.
Windows NT requires that a service be installed, which is accomplished through an installation program. NTSTACFG.EXE is the installation program and it is copied to the public directory during the ZENworks installation.
The ZENworks installation also creates an NDS Application Object that can be used to deploy the NT remote control service to the NT Workstations. The remote control service can also be installed through the custom installation option in the Novell Client Installation program, or through the supplied .AOT template.
Within NWAdmin, the administrator can configure settings such as the protocol to be used and the signals or prompts that will display to the end user when a remote control session is requested.
The Remote Control Policy is configured under both the User and Workstation Policy Packages. There are remote control policies in both policy packages because there may be users or workstations that you never want to be remote controlled. Before an individual can remote control a user/workstation combination, both policy packages are checked and the most restrictive settings are enforced (see Figure 20).
Figure 20: The Remote Control Policy found under the User and Workstation Policy Packages.
Navigating to the workstation that is to be controlled is simple through the NDS tree structure. Administrators are able to remotely control the desired PC by going to the details of that PC. This resolves the concern about the difficulty in navigating to the PC that is to be remote controlled.
When the remote control button in the workstation's Remote Control property sheet is clicked, NDS verifies that the individual requesting remote control has been granted sufficient rights.
If the individual does not have sufficient rights, remote control access is not granted. If the individual has sufficient rights, remote control access is granted depending on whether the end user agrees to be remote controlled (if the Remote Control Policy has been configured to require permission).
Note: Another way to navigate to the PC you want to remote control is to access the properties of the user that is using the PC.
This resolves the primary concern about existing remote control solutions: security. The remote control solution in ZENworks is secured through NDS.
The other concern that Novell discovered in their research of current remote control solutions was the traffic that is generated on the PCs as they advertise their availability to be controlled. The remote control solution that was demonstrated above does not depend on a service advertising itself on all available PCs. Part of the data that is stored in every workstation that is created in NDS is the IPX and IP address of the workstation. Because NDS knows the exact address of every workstation on the network, the remote control solution in ZENworks is able to send packets directly to the workstation that is to be controlled, without requiring the workstations to advertise themselves.
Additional data is stored in each workstation object within NDS, such as a list of the last 10 individuals that have used the workstation.
Novell believes the remote control solution in ZENworks is superior to existing solutions because the three common concerns and obstacles to implementing remote control are resolved. By leveraging NDS, ZENworks is able to provide an efficient and secure remote control solution.
Summary
ZENworks will save organizations money. As the first and only directory-enabled workstation management suite in the world, ZENworks takes advantage of the dynamic power of NDS to efficiently distribute your network applications and reduce support costs. ZENworks also makes it easier for users to obtain the support help they need and provide necessary information to help desk personnel.
* 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.