ZENith 1.52: Enhancing ZENworks for Desktops
Articles and Tips: article
01 Jul 2001
Novell's ZENworks for Desktops goes a long way toward simplifying the management of Windows workstations. If you want to make a good thing better, however, ZENith 1.52 from Performing PCs automates many of the tasks that ZENworks for Desktops allows you to perform.
In fact, ZENith originated from the consulting arm of Performing PCs. These consultants were looking for ways to automate repetitive ZENworks tasks. They created a list of the things they wished ZENworks could do and gave this list to Performing PCs developers. With that, ZENith was born.
I reviewed ZENith 1.52 and found it to be a great add-on tool for ZENworks for Desktops. ZENith 1.52 takes ZENworks functionality to the next level. (ZENith 1.52 requires that you are running any version of ZENworks for Desktops.)
ZENith 2.0 will be available this month. In addition to offering more features, ZENith 2.0 will support ZENworks Firestarter, the next version of ZENworks for Desktops. (For more information about ZENworks Firestarter, see "ZENworks for Desktops: The Next Release," Novell Connection, June 2001, pp. 32-33.)
GOOD, BETTER, AND BEST?
With ZENworks for Desktops, hereafter called simply ZENworks, you no longer have to physically visit each workstation to deploy applications and troubleshoot workstation problems. However, you must still spend some time configuring ZENworks Application objects.
ZENith 1.52 works with ZENworks for Desktops to make managing multiple sites easier. In other words, ZENith 1.52 makes ZENworks more "zen-like."
Three components comprise ZENith 1.52:
GUID Manager
Deployment Manager
Upgrade Manager
You access each component separately from the ZENith 1.52 menu folder that is created when you install the product. You should install ZENith 1.52 on the workstation from which you run ZENworks for Desktops. When you install ZENith 1.52, the installation program also installs online help.
GUID MANAGER
As you are aware, the Globally Unique Identifier (GUID) is a unique 32-digit hexadecimal number that identifies every Application object. ZENworks uses the GUID to track applications that have been installed on workstations.
When users click a ZENworks Application object on their desktop, ZENworks copies the necessary files to the users' workstation and sets up the registry according to the policies you have established. In the registry, ZENworks stamps the GUID to say this application has been deployed. The next time users click the same Application object, ZENworks recognizes that the GUID has already been deployed and simply launches the application.
GUIDs are a good thing, but you must manage them carefully. For example, suppose you deploy four Microsoft Office applications to users' workstations. To launch each application--Word, Excel, Access, and PowerPoint--users click on the corresponding Application object. If these Application objects have different GUIDs and users click on the Word Application object, ZENworks installs all of Office again. If users then click on the Excel Application object, ZENworks once again installs all of Office.
To solve this problem, ZENworks allows you to synchronize the GUIDs. You shift-click the Application object icon for Word, Excel, Access, and PowerPoint and select synchronize. ZENworks generates a whole new GUID and applies it to all four applications. When users click the Word icon, ZENworks installs Office. Then when users click the Excel icon, that GUID is already stamped in the registry; ZENworks simply launches Excel.
ZENith 1.52--The Next Level
After you synchronize GUIDs for a group of Application objects, you cannot synchronize additional Application objects to the same GUID. For example, suppose that some users want to use Binder in addition to the other four Office applications you deployed. To make Binder available, you must create another Application object that has the same configuration but uses another executable, BINDER.EXE.
Because you cannot apply the same GUID to Binder, you must synchronize Binder with the other four applications in the suite, thereby generating a new GUID. As a result, the next time users launch an Office application, ZENworks deploys the entire Office suite. Imagine the ramifications to your company's network if only 10 percent of users launch Word before 9 a.m.
ZENith's GUID Manager enables you to add Binder to the existing Office Application object without changing the GUID. You can synchronize or unsynchronize specific Application objects and retain original GUIDs.
In addition, if you change the GUID, GUID Manager automatically changes any applications that are synchronized to that GUID in that container. For example, if you use GUID Manager to change the GUID for Word and that GUID is synchronized with Word, Excel, Access, PowerPoint, and Binder, GUID Manager automatically changes the GUIDs for the other four products.
Oops! Rewind
You can also use GUID Manager to undo a synchronization that you have already performed. For example, suppose that you use ZENworks to synchronize the GUIDs of several large applications. After you perform the synchronization, however, you realize that you inadvertently included Word in the synchronization. As a result, when hundreds of users log in the next morning, ZENworks will reinstall Word on each of their workstations. At 200 MB for each deployment, the network will quickly slow to a crawl.
Using GUID Manager, you can solve this problem before it causes a network failure. You simply open the workstation registry with the old GUID, copy the GUID to the clipboard, open GUID Manager, paste the old GUID into the new Application object, and synchronize the GUIDs again.
Document, Document, Document
As with all components of ZENith 1.52, GUID Manager documents all of the changes you make. All GUID changes are documented in the Administrator Notes field for each affected object: ZENith logs the old GUID, the new GUID, the time the GUID was changed, and the network administrator who changed the GUID.
This documentation helps you track changes to Application objects. This documentation is also useful if you are synchronizing new Application objects to a group that is already synchronized.
DEPLOYMENT MANAGER
With ZENworks, you can copy an Application object from one location in an NDS eDirectory tree to another location. Copying Application objects to multiple sites takes a substantial amount of time, not to mention that copying is laborious, monotonous work and is error prone. In addition, when you copy the Application object, you lose the associations, linked folders, file rights, and fault tolerance associated with that Application object.
Deployment Manager automates the task of copying Application objects and performs the task in a fraction of the time. For example, Deployment Manager automates the task of selecting destination containers. You can select all of the destination containers to which you need to deploy a particular application and then save this list to use at a later time.
You can create lists according to how your company's network is organized. For example, you can create lists according to geographic locations. Then, when you need to deploy certain applications to every site in the western and northern regions, you can simply use the lists that correspond to those regions.
A Veritable Forest of Trees
Using ZENworks alone, you must export Application objects one at a time and then import them one at a time into the other eDirectory trees. Using Deployment Manager, you can copy Application objects across multiple eDirectory trees. More important, these trees can be running different versions of ZENworks. The only caveat is that you must go from an older version of ZENworks to a newer version.
Deployment Manager deploys applications very quickly. For example, I used Deployment Manager to deploy 15 applications to 20 sites--that's 300 copies of the application--in 12 minutes. That is, the computer took only 12 minutes to process. I spent only 30 seconds configuring and deploying the applications.
Group Associations
When you copy an Application object with Deployment Manager, you can automatically associate that Application object with the same Group object in every location. As a result, you can deploy an application without having to associate that application with each individual Group or container object.
For example, suppose you need to copy the Adobe Acrobat object from the Provo container to the Phoenix container. Also suppose that the Adobe Acrobat object is associated with the Acrobat Users Group object. When you copy this Application object to the Phoenix container, Deployment Manager automatically looks for the Acrobat Users Group object in the Phoenix container and associates the Adobe Acrobat Application object with that group.
If you are deploying an application to which you have yet to establish group associations, you can create Group objects as you go. Then, all you have to do is populate the Group objects with User objects.
Delaying the Inevitable
Deployment Manager also enables you to schedule delays between each Application object deployment. You can schedule a delay for up to 999 seconds. Scheduling such a delay can help prevent an overload that can cause the network to fail.
For example, suppose you deploy Word, Excel, Access, and PowerPoint--which are big applications with 16,000 registry entries each--to 100 sites. Assuming you deploy each application with 16,000 registry entries and 2,000 file entries, the deployment of a single application will increase eDirectory by 2.5 MB. Deploying all four applications will result in a 10 MB increase.
If you copy these Application objects to 100 sites within 1 1/2 hours, you will actually increase the size of eDirectory by 1 GB. This kind of expansion can wreak havoc on your eDirectory replication ring.
On the other hand, if you set a delay of 30 seconds between each Application object deployment, Deployment Manager deploys one Application object to one site and then waits for 30 seconds before deploying the next Application object. As a result, you can leave Deployment Manager running over the weekend without bringing down the network.
Note. Novell provides a solution that overlaps some of the ZENith capabilities--ZENworks for Servers 2. For more information, see "What About ZENworks for Servers?"
UPGRADE MANAGER
Upgrade Manager is an extension of Deployment Manager that allows you to replace an existing application with a new version of that application. For example, suppose you want to upgrade Netscape 4 to Netscape 6. Without Upgrade Manager, you have to search for Netscape 4 and copy the Netscape 6 application into the same container. You then have to note the Netscape 4 associations, add similar associations to Netscape 6, and then delete the associations from Netscape 4.
Upgrade Manager simplifies this process. In fact, you don't even have to know where Netscape 4 is stored; you simply tell Upgrade Manager where to search. Upgrade Manager then searches the specified subcontainers and branches of the eDirectory tree, copies the new application into the same container, and moves all of the relevant associations to the new application.
ZENITH 2.0
As mentioned earlier, ZENith 2.0 is scheduled for release this month. According to Performing PCs, ZENith 2.0 will have a more intuitive interface and a single executable instead of three separate modules. In addition, ZENith 2.0 will allow you to copy policies to other containers just as you copy Application objects.
ZENith 2.0 will perform relative associations of linked folder objects. These relative associations will enable you to deploy Application objects and policies in a single process. With ZENith 2.0, you also will be able to generate site lists.
Pricing for ZENith 2.0 has not yet been announced, but free upgrades will be offered for customers with current versions and upgrade protection.
CONCLUSION
ZENith 1.52 is ideal for anyone who maintains a ZENworks environment across multiple containers or multiple eDirectory trees. ZENith 1.52 is particularly helpful if your company's eDirectory environment is not well planned. With ZENith 1.52, it is irrelevant how many eDirectory trees you have or how haphazard your eDirectory environment is. If you have 30 or 40 eDirectory trees with 300 or 400 containers in each eDirectory tree, ZENith 1.52 will save you considerable time.
Even if you have only one active eDirectory tree, you probably have a test lab that is normally on a separate eDirectory tree. If you test applications in the test lab and then put them on the production eDirectory tree, you can use ZENith 1.52 to quickly copy these applications.
ZENith 1.52 consumes minimal server and workstation resources: ZENith 1.52 does not extend the eDirectory schema and does not run NetWare Loadable Modules (NLMs) or Java applications on the server. ZENith 1.52 does not even store program files on the server. ZENith 1.52 runs only on your workstation.
Every feature in ZENith 1.52 is self-documenting. The Administrator Notes field within each Application object documents every procedure, deployment, upgrade, or other alteration for the Application object.
The price of ZENith 1.52 is U.S. $250 per server with a minimum five-server requirement. You purchase licenses only for servers that are running ZENworks components (servers running NAL.EXE, servers storing .FIL files, servers running the Workstation Inventory Database, or servers containing the ZENworks NWADMIN/ConsoleOne snap-in modules). If you have a large number of servers, quantity discounts are available.
Performing PCs also offers an Upgrade Protection option that ensures you receive all of the product updates for one year. You can download a demo copy of ZENith 1.52 at www.performingpcs.com/zenith/download.html.
Dennis Williams is director of ProductReviews.com, a web site specializing in networking product reviews and product consulting.
What About ZENworks for Servers?
Novell ZENworks for Servers also provides a solution through Tiered Electronic Distribution (TED). On the surface, both ZENith and TED can synchronize application GUIDs, and they both copy application objects. So what are the key differences between ZENith and the ZENworks for Servers TED solution?
The Novell Application Launcher (NAL) Agent for TED in ZENworks for Servers was designed to automate copying and synchronizing applications throughout an enterprise eDirectory tree. Because the ZENworks for Servers solution builds upon the TED architecture, ZENworks for Servers uses scheduling, compression, checkpoint restart, and distribution hierarchies to automatically push applications throughout the enterprise while minimizing bandwidth consumption. ZENworks for Servers provides a "set-and-forget" solution for replicating applications throughout an enterprise, since one application becomes the "master" version for all of the others.
Although ZENith does not automate and schedule the application replication, it still has some advantages. The ability to copy from tree to tree is currently not in the ZENworks for Servers solution. And although ZENworks for Servers can automate application association, it cannot do application associations by example, as ZENith can. In addition, ZENith does not need the additional back-end services that the ZENworks for Servers solution requires.
* Originally published in Novell Connection Magazine
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.