Novell Home

ZEN and the Art of Application Maintenance: Part One

Novell Cool Solutions: Feature
By Shaun Pond

Digg This - Slashdot This

Posted: 23 Jun 2005
 

Background

The online documentation for ZENworks covers many aspects of how to use the product, but this series of articles aims to give those who are just starting out (and more experienced users too!) some insights into how best to put this into practice, and how to make the most of ZENworks Application Management in the shortest time.

In these articles, we will pay you the compliment of assuming you know how to click on buttons, so you will not be presented with a click-by-click guide, but instead a description of why you need to click on the button.

These articles will cover the best ways to create application objects, take you through all the options in ConsoleOne (and how to use them together!), show you strategies for where to place your application objects, and offer some pointers on using application objects in a large enterprise.

The content of this article is aimed at customers who are using ZENworks 6.5, but much will also apply to earlier versions.

Creating Application Objects

There's a lot of confusion about how best to create application objects: should you use snAppShot? Should you convert everything to MSI? The simple answer is that you should do what is best for that application: there is no one-size-fits-all solution.

Using snAppShot

snAppShot is great for capturing small changes: for example, if you change one setting in an application, where is that information stored? snAppShot can tell you this, and enable you thus to change settings in applications, even when there's no direct method provided by the software developer. snAppShot is also good for old applications that do not have an MSI, or a silent setup option. The biggest thing to beware of with snAppShot is that it is dumb: it captures the changes, but has no idea why the program made the change, or even if the change came from the program you're interested in! You should always examine the application that's created by importing a snAppShot, no matter how simple the change: unless you do, you can never be sure that you have not picked up some change that was made by another process running on your workstation.

Before you start to run snAppShot, you must ask yourself some questions:

  1. Is snAppShot the right tool for this? If you have a silent install (e.g. A /q parameter), or the application is MSI based, use the provided installer instead of snAppShot: snAppShot cannot determine the logic used by the installer, only the end result, and it's then up to you to ensure that the application is copying the correct files, etc. for all circumstances (see next section).


  2. Do I have a "base" PC to run the install? Think about what snAppShot does: it takes a look round your PC and sees what you've got in files, the registry, etc. Then it waits whilst you run the install, then it takes another look, and it works out what the differences are. OK, so you now have a list of all the changes made to that PC -- but what happens if that PC was not a "base" configuration? DLLs, registry keys, other files, may already be present that your new application needs: for example, your new application needs 3dsuperwidget.dll, but the PC on which you run snAppShot already has it. snAppShot will not realize that 3dsuperwidget.dll is required, because the install did not copy it. So your new application does not copy 3dsuperwidget.dll, and when you come to install it on another PC that does not already have that file, the application fails. Make sure that you have a "base" PC, and take an image. Restore the image before you run any snAppShots, so that every snAppShot is run against a "clean" PC.


  3. Do I have the right tools to "clean up" the application? The current version of snAppShot is much better than earlier ones, but it still can be fooled into thinking that a file that's generated by another program or process is part of your application, or it can think that a registry change was made by your install. TID 10081452 was written before ZENworks 6.5 was released, but the information it holds is still valid.

    There are tools that can help you to clean up a snAppShot: there are some free tools to be found in Cool Solutions, and there is the excellent (though not free) AXE tool from Centralis).

Some more tips for getting good snAppShots:

  1. After the install terminates, launch the installed application whilst snAppShot is still running (before you click "Next"): this way you will capture the initial setup, which may involve accepting a license agreement, for example.
  2. Some applications will require a reboot, be careful with these: Windows does a lot of work when starting up, and many files and registry entries are updated. You need to take extra care to ensure you have not caught those entries in your final application.
  3. It's worth considering changing the default for copying files to "copy if newer version" - if the file doesn't actually have a version embedded, then NAL will use the file date instead.
  4. Beware applications that store data in the registry in Unicode: ZENworks doesn't have any tools to manipulate Unicode, so you may need custom code for your application.

Why do I need to do all this work, where's the harm in leaving a few entries in?

With the wrong registry changes, you could render a PC unbootable: at the very least, you could cause yourself support headaches. One example we have seen was every PC in a building having the same IP address. (During the snAppShot, the PC renewed its IP address via DHCP, and was given a different one -- this got stored in the snAppShot, and all users of that application got the same address.) A customer once complained that Group Policies weren't being applied: after a lot of investigation, we determined that the policy was applying, but that a force-run application was undoing the change immediately!

What do all those things in ConsoleOne do?

In this section, we will cover all of the options that you would use for an application created from a snAppShot, or one that you have created from scratch, called a "Simple Application" in ConsoleOne. In later sections, we will cover the differences with MSI, Web, and Terminal Server applications.

The Identification Tab - Icon

Application Icon Title: pretty self-explanatory, but do beware if you're creating one application based upon an existing one -- remember to change this, so you don't end up with two icons that look the same!

Application Icon: if you've used snAppShot , you'll probably have an icon displayed here, otherwise you can point to a file (EXE,DLL, ICO) to extract one. Various versions of ZENworks have had issues with extracting icons from files, but current versions should be fine.

Disconnectable: this refers to the ability to launch an application when you're disconnected from the network. Checking this box is not, in itself, enough to give you the icon when you're disconnected: for example, if you create an application and associate it to a user, they can see the icon on their desktop. If they then disconnect and start NAL, there's no icon there! In order for an icon to be available when disconnected, two things must happen:

  • The Disconnectable box must be checked.
    AND
  • Either the application must have been executed at least once, or on the Associations tab, "Force Cache" must be checked (we will cover references to the Associations Tab in later articles).

Wait on force run: applications that are marked "Force Run" on the Associations tab will try to launch as soon as NAL loads. If it's important that the applications run in a particular order, or that two do not run at the same time, then this option needs to be checked. As you might imagine, it works in conjunction with the next option, which gives a numerical value to the order. There is nothing significant about the numbers you use, but it is very important that you keep track of them: ZENworks does not do a sanity check on the numbers you use, nor is there a nice easy way to show the relationship (you can do an nlist, looking for "application:icon order" but it's up to you to determine which applications are associated where, to see what order they're going to run in). We'd recommend that you ensure that you have significant gaps in the number you use for the order value (perhaps start 50,100,150, etc) to allow for the easy addition of new applications in the sequence: this avoids having to renumber applications later.

Show progress: normally, when an application runs, there is a small progress box displayed. This is very useful for large applications, as it shows the user that something is happening. However, for many small applications, you don't necessarily want to confuse the user by having a message displayed for a very brief moment -- consider unchecking this box for all applications which the user doesn't need to know about.

The Identification Tab - Description

The string you enter into this box performs two purposes: firstly the user can see the contents if they right-click on an application icon and choose properties, and secondly, this is the information that's displayed if you select "Prompt before distribution" (See Distribution Options, Options tab, this will be covered in the next article).

The Identification Tab - Folders

If you use one of the NAL options that groups applications (Start menu, NAL window with Show Folders enabled, etc.), you may find that applications are not grouped in the way you might expect: by default, NAL will group applications under a folder that has the same name as the object that holds the association (e.g. .Workstations.Provo.West.Americas.ACME). This is almost certainly not what you want the user to see.

There are several ways you can improve on this:

1. For Containers and groups, if you fill in the Description attribute on the General page for the associated object,

that field will be displayed instead of the NDS name.


You can combine folders: if you give the same description to more than one folder, they will appear combined:




To get a more user-friendly title for the user's folder, just ensure that they have the Full Name attribute filled in:


This makes it a little more friendly, but it is very limited: you can't have sub-groupings, and the only groupings are based upon which object has the application associated to it, which may be meaningless to the user. In most circumstances, you'd want Linked or Custom folders.

2.Linked and Custom Folders

Custom Folders look simplest, as the folder structure only needs to be defined within the application itself. However, there are limitations: you cannot have two applications in the same folder (so you need a folder for every application!), and the folder structure needs to be specified in each application:





Note the two check boxes for application Launcher and Start Menu: if these are unchecked, then the application will not appear in the Custom Folder for that view. The result looks like this:


or, if you're using NAL Explorer, the Start Menu looks like this:

Linked Folders, on the other hand, allow you to link an application into a pre-defined hierarchy, stored in a Linked Folder object.

In the application Folder object you created, you can add folders to the hierarchy, and you can also add applications to the hierarchy.

Once you have defined your folders, you can go to application objects and add them into the folder structure, at whichever point is appropriate.



Note that you don't get empty folders: if there are no associated applications for display in a folder, it does not appear.

The Identification Tab - Contacts


If you have specialist applications, where a particular help desk may need to be contacted, for example, this option allows you to enter one or more users objects. When the user of the application needs help, if they right-click on the icon, and choose Properties, then click on the Help Contacts Tab, they'll get a list of the user specified (showing their Full Name, not their eDirectory name), their phone number, and their email address. If you have Windows-based email running, the user can click on the email button to send an email to the person.

(Note that the user must have read rights to the Telephone Number and email attribute of the designated contact for these to be displayed!)

The Identification Tab - Administrator Notes

These notes can be used by you to keep any information that's relevant: they can't be seen by the user.

That's the end of this first article: next we'll delve into the mysteries of Distribution, and beyond...


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

© 2014 Novell