Data Centers

ZENworks tips and tricks

Novell's ZENworks can provide you with quick solutions to your network's management problems. Ron Nutter describes scenarios that he's encountered while implementing ZENworks, and he explains the troubleshooting techniques that he applied.

Getting ZENworks up and running is pretty straightforward; the real key is to figure out how to run a problem application or to get an MS-DOS application to work correctly when it needs special drive mappings. In this Daily Drill Down, I’ll take you through several scenarios that I’ve encountered while working with ZENworks, and I’ll show you how to get things to work properly.

Getting a problem application to launch
I spent the better part of 1998 designing and implementing a nine-state, 30-office network for a national utility. ZEN was a real timesaver when it came to deploying applications. We encountered two applications that would run fine when they were launched outside of ZEN, but they wouldn’t work when they were invoked from the application launcher.

One of the applications was a terminal emulator that was designed to talk to two different IBM AS/400s over TCP/IP. After installing the program, I noticed a lengthy command-line string that pointed to a session configuration file (it used the .ws extension). I carefully copied this command-line string into the Command Line Parameter field on the Environment tab of the ZEN object with which I was working. When the ZEN object was executed, an error message appeared, indicating that one or more files couldn’t be found.

Using the Windows file extension association process to my advantage, I created a batch file that said Start Windows NT realized that this file wasn’t an executable, but it recognized the extension and knew that the file could be used by another program. NT took over at that point, started the application that could use the file I was trying to run, and told the application which command-line parameters to use. All I had to do was to enter the drive mapping, including the name of the batch file (for example, f:\apps\terminal.bat), in the Path To Executable File field on the Identification tab for the ZEN object with which I was working. The application then launched normally.

UNC versus explicit file path
When you’re creating a ZEN object, you can set the path to an executable file by using UNC (Universal Naming Convention) or by using an explicit path to the file. You’ll see UNC on many NT-based networks. Using UNC can save the system administrator from having to set up complex login scripts to map one or more drive letters so that applications can run.

If an application installs itself with the UNC naming convention, the first step that you should try when you create a ZEN object for that application is to copy the UNC paths to the appropriate areas in the ZEN object window. Then, you need to try running the application. If you get an error, the next step will ask you to use regular drive mappings to get to an application.

When you’re using NT as the desktop OS, be careful about what you use for drive mappings. Windows 3.x and Windows 9x will see a drive mapping, such as f:\public\client32, and will be able to see files in f:\public and f:\home from a single drive mapping. NT, however, will treat this drive mapping command as a map root, and the workstation will see files only in f:\public\client32 and the directories below that level. In the past, I’ve had success with using a generic type of drive mapping in the container login scripts. I map a drive letter to the root of each volume on the server and then add the path to the executable and to the Working Directory field (on the Environment tab). If you have any command-line parameters that reference a configuration or other file, you’ll need to edit the Command Line Parameter field to show the explicit path, too.

Mapping and unmapping drives on the fly for problem MS-DOS applications
At some point while working with ZENworks, you’ll find that some applications must have things their way. MS-DOS accounting applications seem to be at the top of this list. You can accommodate these types of programs by using the Launch Scripts or the Drive/Ports tool. Launch Scripts has been my favorite, and I usually can get it to work with an application that doesn’t like the environment that’s presented by the Drive/Ports tool. The reason for this fact may be due, in part, to the differences between the two tools.

Launch Scripts offers two text windows—one for commands that must be run before the application in question is started and another for commands that must be run after the program is terminated (to restore the environment for use by other applications). If you remember the NetWare 2.x/3.x days, you’ll quickly see what you need to do. In the Run Before Launching text box, you enter the map commands and/or printer capture statements in order to set up the environment you need. In the Run After Termination text box, you delete the drive mappings and release the printer capture commands.

If you choose the Drives/Ports tool, the environment appears to be setting up as the application starts, rather than before it starts. Another drawback is that you can’t remove the changes you’ve made if you want to restore the environment for other applications.

Documenting how you set up the ZEN objects
Keeping good documentation on how (and why) you set up a particular ZEN object can be important when you’re troubleshooting. The Administrator Notes tool allows you to keep this information with the object itself so that you can retrieve the information easily.

Reporting application problems to the SNMP console
Knowing that an application isn’t working correctly means making a lot of calls to the help desk. Using the Reporting function in the ZEN object for an application can give you an idea that a problem exists without your having to pour thousands of dollars into yet another specialized management package that will give you that information.

You can choose either to log events to a file or to generate an SNMP trap. Either one or both of these options can be used with any of the ZEN application objects. Logging to a file is a good option to start with. That way, you establish a record in case users complain that an application isn’t working; the log file will give you some idea of when the problem started. The problem with this option is that it requires you to check the log file periodically or to create a program that will look for this file, and any additions to it, automatically and alert you to the problem.

Using the Log Events Via SNMP Traps option, you have a little more control over the situation. You can record specific events (for example, a failure to launch or distribute the program). This information is sent to the destination that’s specified in the SNMP policy in a container package. When setting the SNMP Trap Target Policy in the Container package, specify how often the policy should be acted on—every certain number of days, hours, minutes, and/or seconds. Unlike with some management systems, you have the ability to specify a Trap Target address by IP or IPX address. For those of you who haven’t worked with SNMP much, if the console to which the trap is being sent isn’t turned on, the trap (or error message) is thrown away and not re-sent while the workstation is up. For this reason, you’ll want to have at least a UPS on the management workstation so that it can always receive the error message. Better yet, have two management consoles operational so that one system is always available to record the problem.

Controlling application availability with Schedule
There are times when you’ll want to prevent users from accessing a certain application. Before ZENworks, you pretty much had to rely on the honor system, or you had to disable login to the server and prevent the workstations from accessing any resources on the server until you had finished the task at hand.

Using the Schedule tool of the ZEN application object, you have the option of restricting access to an application object over a series of days or on certain days every week. To do so, click the Set Schedule In drop-down arrow and select Range Of Days. You’ll notice that the days under the Days Available label appear to have a pushed-in appearance. Click on the days for which you wish to restrict access.

The next step will be to restrict the time of day that the applications will be available. You need to click on the small clock icon to the right of the Start Time label. A Time Input window will appear that will allow you to set the start and stop times for the application. Drag the arrow on the time line to set the earliest time that you want the application to be available to users. Repeat the process by using the bottom-sliding arrow to set the latest time that you want the application to be used. Then, click OK to return to the previous window.

The start and stop times for the application should be entered for you. Depending on how resource heavy the application is when it starts (that is, the number and size of files that you must access when you initialize the application before users can open it), you may want to think about staggering the availability of the application once its start time arrives. If you enter a start time of 15 minutes, the times at which the application becomes available to users will be staggered over 15 minutes. That way, the server and/or network won’t slow to the point at where almost all work comes to a stop until the applications have finished the initialization process. If you have a small number of users (less than 15), it may not be a problem.

Controlling application availability with specific system requirements
You’re probably using one or two applications that will run correctly only if another application has already been installed (a situation that’s also known as application dependency), a certain amount of disk space is available, or a certain environment variable has been set on a system. Not meeting one or more of these requirements can mean that an application may fail on a random basis or, worse yet, that important information being recorded in a file is not being recorded correctly. Using the System Requirements tool in the ZEN application object with which you are working will allow you to specify certain criteria that must be met before the application will be allowed to start.

For example, suppose you use an accounting application that must have at least 20 MB of disk space available. You begin by clicking the Add button in the System Requirements window and clicking Disk Space. When the Disk Space Requirements window appears, you can choose to check the available disk space in the Windows System Directory, Windows Directory, Windows Temp directory, or a specific drive letter—depending on where your application is looking for free space so that it can run correctly. After selecting the drive letter to watch, you need to choose the qualifier for checking for disk space. The default selection of Greater Than Or Equal To probably will work in most situations; choose that option.

The last step that you will need to take is to specify how much available disk space you need. Enter that value in the entry field to the left of the MB label and click OK to return to the System Requirements window. While there is no limit to the number of conditions that you can specify, I suggest entering only those criteria that you know will become a problem if they don’t exist.

Keeping the number of icons manageable
As you grow more comfortable with how ZENworks can help make your job easier, you will start using it for more and more applications. To keep things neat and easy to manage, you may want to think about where the ZEN application objects are stored in the NDS tree. You can establish an NDS container called Applications in which to store all of the ZEN application objects. This approach will keep you from confusing those objects with usernames and will make the applications easier to access.

If you have more than a few Organization or Organizational units in your tree, you may want to think about putting those applications that are used by a certain NDS container in the same container as those users. This arrangement will make granting access to the application object easier since you can grant rights based on container membership automatically. This approach also can make user setup a little less of a hassle, depending on the amount of employee turnover that your company experiences. If you have applications that several departments use, you’ll probably want to place these applications in the base of the tree so that they are equally close to all user objects.

Depending on how often you make changes to an application object, consider making a backup copy of all ZEN application objects in a special container. That way, if the object becomes corrupted or if changes are made to the object that aren’t recorded and problems start occurring, you can restore the settings for that object. There is no right or wrong way to approach this situation. You have the option in NWAdmin to move the objects to a container at a later time, should your needs change.

Options for running NAL at the workstation
The main job of deploying applications at the workstation is handled by the Application Launcher application (affectionately know as NAL). There are several methods of running this program at the workstation. The easiest method is to put the following line in the container login script:
Make sure that you replace the drive letter with the one that you have mapped to SYS.

You also can put a link to NAL.EXE in the startup folder of the workstation. However, users will receive an error message when they turn on their workstation and NAL tries to start (especially if the workstation is a portable) but they are not attached to the network. It’s also possible to bypass the startup folder when you start Windows. Novell TID (Technical Information Document) #2937365 describes the pros and cons of each option in detail.

Keeping up with the latest info on ZENworks
Novell has done a really good job of showing administrators how to use ZENworks properly for their companies. One site that you should visit on a regular basis is ZENworks Cool Solutions . This site is updated several times a week with little nuggets of information on how to use the software that you have effectively and how to make it work for you.

Another good site to visit is the product support page for ZENworks . Here, you’ll find the latest TIDs and fixes from Novell without having to go on the proverbial treasure hunt. This site is updated on a daily basis, and you have the option of looking at the TIDs posted in the last seven, 14, or 30 days without having to use specific keywords to search.

As you should begin to see, ZENworks is a very flexible and versatile package. Since beginning its life as a proof of concept as to what was possible from NDS, it has become a very versatile and flexible application and workstation management tool.

Ronald Nutter is a senior systems engineer in Lexington, KY. He's an MCSE, Novell Master CNE, and Compaq ASE. Ron has worked with networks ranging in size from single servers to multiserver/multi-OS setups, including NetWare, Windows NT, AS/400, 3090, and UNIX. He's also the help desk editor for Network World. If you’d like to contact Ron, send him an e-mail . (Because of the large volume of e-mail that he receives, it's impossible for him to respond to every message. However, he does read them all.)

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Editor's Picks

Free Newsletters, In your Inbox