• | Table of Contents
• | Index
Novell® ZENworks™ for Servers 3 Administrator's Handbook
By Brad Dayley, Lisa DaNae Dayley, Rob Tanner
Publisher | : Que
Pub Date | : April 10, 2003
ISBN | : 0-7897-2986-5
Pages | : 512

Novell ZENworks for Servers(ZENworks stands for Zero Effort Networking) is the cross-platform solution for server content and configuration management. It provides server consistency across Windows, Linux, Solaris and NetWare platforms, enables intelligent network automation, and increases management efficiency so everything works together as on Net. As a result, organizations get a stable server environment and significantly reduce networking costs.

Novell's ZENworks for Server 3 Administrator's Handbook guides the reader through the potential rough spots. It explains how ZENworks for Server 3 functions and affects NetWare, Windows, Linux and/or Solaris networks.


• | Table of Contents
• | Index
Novell® ZENworks™ for Servers 3 Administrator's Handbook
By Brad Dayley, Lisa DaNae Dayley, Rob Tanner
Publisher | : Que
Pub Date | : April 10, 2003
ISBN | : 0-7897-2986-5
Pages | : 512

Copyright
Foreword
Welcome to Novell Press
Preface
Who Should Read This Book?
 | How This Book Is Organized
About the Authors
Acknowledgments
We Want to Hear from You!
Reader Services
Chapter 1. Introduction to ZENworks for Servers 3
 | What Is the Purpose of ZENworks for Servers 3?
 | What Is the Relationship Between ZENworks for Desktops and ZENworks for Servers 3?
 | What Are the Benefits of Using ZENworks for Servers 3?
Chapter 2. Installing ZENworks for Servers 3
 | Planning for ZENworks for Servers 3 Deployment
 | Verifying Installation Prerequisites on Your Servers
 | Installing ZENworks for Servers 3
Chapter 3. Understanding What Is Placed on Your Servers
 | Management and Monitoring Services
 | Policy-Enabled Server Management Services
Chapter 4. Setting Up ZENworks for Servers 3 in Your Tree
 | Understanding General ZENworks for Servers 3 Architecture
 | Starting Up ZENworks for Servers 3 in Your Network
Chapter 5. Setting Up Server Policies
 | Discussing ZENworks for Servers 3 Policies
 | Setting Up a Distributed Policy Package
 | Setting Up a Container Policy Package
 | Setting Up a Service Location Policy Package
 | Setting Up a Server Policy Package
 | Setting Up a Container Policy Package—Search Policy
 | Setting Up a Service Location Policy Package—The SMTP Host Policy
 | Setting Up a Service Location Policy Package—The SNMP Trap Targets Policy
 | Setting Up a Service Location Policy Package—The Tiered Electronic Distribution Policy
 | Setting Up a Service Location Policy Package—The ZENworks Database Policy
 | Setting Up the Server Policy Package—The NetWare Set Parameters Policy
 | Setting Up the Server Policy Package—The Scheduled Down Policy
 | Setting Up the Server Policy Package—The Scheduled Load/Unload Policy
 | Setting Up the Server Policy Package—The Server Down Process
 | Setting Up the Server Policy Package—The Server Scripts Policy
 | Setting Up the Server Policy Package—The SNMP Community Strings
 | Setting Up the Server Policy Package—The Text File Changes Policy
 | Setting Up the Server Policy Package—ZENworks for Servers
 | Setting Up the Server Policy Package—The Copy Files Policy
Chapter 6. Setting Up Tiered Electronic Distribution
 | Understanding the General Architecture for TED
 | Introducing the Components
 | Discussing TED Configuration in Your Network
 | Configuring TED Systems
 | About the TED Distributor
 | Discussing the Parent Subscriber
 | Discussing the TED Subscriber
 | External Subscriber
 | About TED Distribution
 | About TED Agents
 | About the TED Channel
 | ZENworks for Servers Web-Based Management
Chapter 7. Understanding and Creating Server Software Packages
 | Understanding Server Software Packages
 | Creating a Server Software Package
 | Installing a Server Software Package on the Target Server
 | Updating Server Software Packages
Chapter 8. Understanding ZENworks for Servers 3 Management Services
 | Understanding ZENworks for Servers Management Components
 | Planning Your Network Management Services
Chapter 9. Preparing and Using ZENworks for Servers 3 Network Discovery
 | Understanding Network Discovery
 | Using Network Discovery
 | Using the Atlas
Chapter 10. Using ZENworks for Servers 3 Traffic Analysis
 | Understanding LAN Traffic Analysis
 | Setting Up LAN Traffic Analysis
 | Analyzing Network Traffic
 | Setting Up ZENworks for Servers 3 Traffic Analysis Agents
Chapter 11. Using ZENworks for Servers 3 Alarm Management
 | Understanding Alarm Management Components
 | Managing ZENworks for Servers 3 Alarms
 | Using ZENworks for Servers 3 Monitoring Services
Chapter 12. Using ZENworks for Servers 3 Server Management
 | Using ZENworks for Servers 3—SMNP Agents to Manage Servers
 | Using ZENworks for Servers 3 Server Inventory
Chapter 13. Making the Most of ZENworks for Servers 3 Reporting
 | Reading ZENworks for Servers 3 Reports
 | Using ZENworks for Servers 3 Reports
Chapter 14. Using ZENworks for Servers 3 Web-Based Management
 | Accessing the ZENworks for Servers 3 Web-Based Management Role
 | Administering TED Objects
 | Creating TED Objects
 | Monitoring TED Distributions
 | Using the Remote Web Console Tool
Chapter 15. Troubleshooting ZENworks for Servers 3
 | Troubleshooting Policy and Distribution Services
 | Troubleshooting Traffic Analysis
 | Troubleshooting Alarm Management
 | Troubleshooting Server Management
 | Troubleshooting Server Inventory
 | Troubleshooting NetWare Errors
Appendix A. ZENworks for Servers 3 Database Schemas
 | Database Class Associations and Attributes
 | Using the ZENworks for Servers 3 MIB Browser
Appendix B. ZENworks for Servers 3 Console Commands
 | ZENworks for Servers 3 Policy Engine
 | TED Distributor/Subscriber
Appendix C. ZENworks for Servers 3 Resources
 | Novell Support and Online Documentation
 | ZENworks Cool Solutions
 | Novell Consulting Services
 | Novell Technical Support Services
Index


Copyright

Copyright © 2003 by Novell, Inc.

All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.

Library of Congress Catalog Card Number: 2003100657

Printed in the United States of America

First Printing: April 2003

06 05 04 03 4 3 2 1

Trademarks

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized. Novell Press and Que Publishing cannot attest to the accuracy of this information. Use of a term in this book should not be regarded as affecting the validity of any trademark or service mark.

Novell, NetWare, GroupWise, ManageWise, Novell Directory Services, and NDPS are registered trademarks; Novell Press, the Novell Press logo, NDS, Novell BorderManager, ZENworks, and Novell Distributed Print Services are trademarks; CNE is a registered service mark; and CNI and CNA are service marks of Novell, Inc. in the United States and other countries. All brand names and product names used in this book are trade names, service marks, trademarks, or registered trademarks of their respective owners.

Warning and Disclaimer

Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The author and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.

Credits

Acquisitions Editor

Jenny Watson

Development Editor

Emmett Dulaney

Technical Editor

Ron Tanner

Managing Editor

Charlotte Clapp

Project Editor

Andy Beaster

Indexer

Heather McNeill

Team Coordinator

Vanessa Evans

Interior Designer

Gary Adair

Page Layout

Stacey Richwine-DeRome

Dedications

For D, A & F!

—Brad Dayley

For the ABC's

–especially the big B

—Lisa DaNae Dayley

For my Peach Queen, who gives me a reason. And to my engineering buddies who are fun to work with and make great stuff.

—Ron Tanner


Foreword

We are a society of connectivity and service. We carry our cell phones, our PDAs, and our laptops and demand connectivity to any resources that we need or want. We have become accustomed to the Internet and its perpetual service that can provide us data 24x7x365. When we do attempt to connect to a Web server that is down, some of us grumble while others move on to competitors to find what they need. Our businesses depend on being in constant contact with our employees, partners, and customers. We must provide constant services, with maximum efficiencies and security.

The cornerstone device of the worldwide network and any business or community network is the powerful server. The server provides the muscle that is required to keep the network functioning and providing the data and features that a hungry connected community requires. Not only must that server function at peak performance, but it must also be able to thwart attacks and viruses that threaten to dismantle stability and business vitality. The server must not fail. The server must perform. The server must be up to date with the latest security measures.

As businesses grow through partnerships it becomes imperative that communication flows freely and securely between corporations. Orders, inventories, sales, contact data, and price and parts lists must be updated constantly and shared appropriately across diverse systems and corporate networks. For you and your partners to work effectively and beat the competition you must be coordinated.

We are placing more demands on our servers, and consequently we are also placing a greater responsibility on our IS&T departments to keep the servers up and accessible to everyone in the system. Not only is IS&T required to keep existing systems up; they must continue to manage an ever growing, sprawling network of servers. They require a solution that is powerful enough to provide the ease of traditional centralized management of any server and that still enables them to monitor and maintain control at each of the diverse server locations. IS&T requires the tools to manage this mass of server power not only through central consoles but through the Internet itself, managing servers anywhere in the world, whether they are connected into your company's private network, the Internet, or a partner's private network. Making sure the data is where it needs to be to make your business strategy sound and the most effective.

ZENworks takes this need seriously. With ZENworks for Servers 3, Novell, Inc. has examined your needs and provided your IS&T department with the tool they need to effectively manage your servers and keep this vital resource functioning. ZENworks combines its SNMP management of network devices with its directory-enabled policy management to provide an all-encompassing product to fully support the servers in your network, providing self-managed servers and freeing your IS&T staff so that they can help you move your company to the next level. And ZENworks knows that your network of servers is not going to be homogenous; therefore its cross-platform solution provides support for any mix of servers you may have, including NetWare, Windows, Linux, and Solaris. Indeed, with ZENworks for Servers 3 providing SNMP and trap management, alarm monitoring, policy-based server management, and Tiered Electronic Distribution (which enables the efficient and secure transfer of applications, patches, virus updates, and any amount of corporate data to any other server in the world) you are set to succeed.

Novell ZENworks for Servers 3 Administrator's Handbook is concentrated exclusively on the deployment and use of ZENworks for Servers in any computing environment. This book covers many aspects and features of ZENworks for Servers, including more advanced subjects, and can make the installation, deployment, troubleshooting, and use of the product a smooth and rewarding process. This book should be in every administrator and server manager's library.

Brad Anderson
Vice President and General Manager
ZENworks
Novell, Inc.


Welcome to Novell Press

Novell Press, the world's leading provider of networking books, is the premier source for the most timely and useful information in the networking industry. Novell Press books cover fundamental networking issues as they emerge—from today's Novell and third-party products to the concepts and strategies that will guide the industry's future. The result is a broad spectrum of titles for the benefit of those involved in networking at any level: end user, department administrator, developer, systems manager, or network architect.

Novell Press books are written by experts with the full participation of Novell's technical, managerial, and marketing staff. The books are exhaustively reviewed by Novell's own technicians and are published only on the basis of final released software, never on pre-released versions.

Novell Press at Que Publishing is an exciting partnership between two companies at the forefront of the knowledge and communications revolution. The Press is implementing an ambitious publishing program to develop new networking titles centered on the current versions of NetWare, GroupWise, BorderManager, ManageWise, and networking integration products.

Novell Press books are translated into several languages and sold throughout the world.

Wes Heaps
Publisher
Novell Press, Novell, Inc.


Preface

The computer industry has made incredible progress with information sharing since the introduction of local area networks (LANs) in the 1980s. These advancements have produced services and tools that increase user productivity while decreasing their workload. Since the very infancy of the LAN industry, sharing of resources has been at the very root of the value of the use of LANs. One of the most vital resources in the network is the server—the large, expensive computer system that can supply facilities to many thousands of users, giving them access to capabilities that they do not have available on their desktops.

Since the introduction of ZENworks for Desktops, Novell has recognized the value in managing resources through the directory. This significantly reduces the cost of managing any resource, enabling the administrators of the network to handle more services and focus on the needs of the business. Novell has now moved this concept into managing the server. Within the directory, the administrator can set system parameters and policies to govern the behavior of their servers in the tree. These policies can affect as little as one server, or as many servers as are in the tree. With a single instruction to the directory literally all servers in the network can be modified.

In addition to managing the behavior of the servers, Novell with ZENworks for Servers 3 has given us a scalable distribution service that can efficiently transfer bundles of files to any or all servers in the network. Administrators can construct packages and bundles of files and have them efficiently distributed across the hall or across the world. The servers unpack and store these bundles on their local file systems. We no longer have to spend our time forever copying applications and files all across our servers in the network.

This book is your guide to leveraging ZENworks for Servers 3 to distribute files across the network and to maintain and manage your NetWare servers. This book provides steps to set up and use the advanced features of ZENworks for Servers 3 to cut your administrative efforts and costs, while making the network environment much more effective for your company.


Who Should Read This Book?

This book is for anyone responsible for setting up or maintaining a Novell network. If you are a network administrator, support technician, CNE, or consultant, this book gives you the edge you need to effectively manage servers and distribute files across all the servers in the network. You will save valuable time by using the advanced features of ZENworks for Servers 3 that keep your servers exactly at the settings you specify; even if someone walks up to the server and changes the settings, they will be automatically changed back to your administered value.

This book also shows you how to effectively use the distribution services to send all of your files anywhere on the network and have them placed on the servers you want—making them available to all the users of the servers, wherever they may be.


How This Book Is Organized

This book is organized into the following chapters to guide you through installing ZENworks for Servers 3, setting up ZENworks for Servers 3 in NDS, and then leveraging the advanced features of ZENworks for Servers 3 to reduce your network management costs.

Chapter 1: Introduction to ZENworks for Servers 3

This chapter discusses the basic high-level components of ZENworks for Servers, the purpose for the system, and the benefits of installing ZENworks for Servers 3 in your network.

Chapter 2: Installing ZENworks for Servers 3

Chapter 2 discusses methods and checklists that will help you prepare and install ZENworks for Servers 3. It walks you through pre-installation steps that will help you prepare and install the product quickly and correctly. Chapter 2 also covers pre and post upgrade steps to migrate from ZENworks for Servers 2.

Chapter 3: Understanding What Is Placed on Your Servers

This chapter discusses each of the components that you can choose in the install process and describes where the files are placed on the server. This chapter also reviews the processes that need to run on your server in order for the components of the system to function.

Chapter 4: Setting Up ZENworks for Servers 3 in Your Tree

This chapter reviews, at a high level, the various objects that will be introduced into your tree and what basic function they perform. Additionally, Chapter 4 reviews the high-level steps that you need to take to get ZENworks for Servers 3 functioning in your tree.

Chapter 5: Setting Up Server Policies

This chapter discusses each of the various server policies that are introduced into the network with ZENworks for Servers 3. Chapter 5 reviews each policy carefully and describes how to set up these policies and make the most of directory-enabled management.

Chapter 6: Setting Up Tiered Electronic Distribution

Chapter 6 discusses the general architecture of Tiered Electronic Distribution (TED) and describes each of the components of the system. The chapter also describes each of the management processes that are required to get files properly distributed efficiently across any tree and any size network. It also covers the manipulation of the objects in the tree to use TED effectively.

Chapter 7: Understanding and Creating Server Software Packages

This chapter reviews the process to create server software packages, which constitute a set of files that are to be placed into the server and installed into the system. These packages can use TED to be distributed across the network and then automatically installed on any destination server.

Chapter 8: Understanding ZENworks for Servers 3 Management Services

Chapter 8 reviews and describes all of the various applications and tools provided with ZENworks for Servers 3 that will help you manage and monitor your network more effectively.

Chapter 9: Preparing and Using ZENworks for Servers 3 Network Discovery

This chapter discusses the use of the network discovery tools that scan your network to create and store network topology maps, which will help ZENworks and you be aware of all the devices that are attached to your network.

Chapter 10: Using ZENworks for Servers 3 Traffic Analysis

Chapter 10 discusses how to set up a system to monitor the traffic that is crossing a segment of your network. This monitoring information will help you in analyzing your traffic patterns in an effort to keep your network functioning at peak performance.

Chapter 11: Using ZENworks for Servers 3 Server and Alarm Management

Chapter 11 delves deeper into the SNMP system. It reviews how to set up the system and make it work efficiently so that you can be notified when a server is experiencing problems or reaching administered thresholds on their resources.

Chapter 12: Using ZENworks for Servers 3 Server Management

This chapter reviews the features that are in ZENworks for Servers 3 that can be used specifically in managing any NetWare or Windows NT/2000 servers in your network. This includes the ability to monitor resources, perform hardware and software inventory, and remote management of server configuration.

Chapter 13: Making the Most of ZENworks for Servers 3 Reporting

This chapter reviews the various reporting capabilities that are available in the ZENworks for Servers 3 product. This chapter also discusses how to manage and customize these reports for your specific needs.

Chapter 14: Using ZENworks for Servers 3 Web-Based Management

This chapter discusses how to access and configure the ZENworks for Servers 3 plugins to the Novell iManage interface that allows you to manage your ZENworks for Servers 3 network from a Web browser.

Chapter 15: Troubleshooting ZENworks for Servers 3

This chapter reviews several of the components of ZENworks for Servers 3 and how to perform some diagnostics to determine why these components are not functioning as expected. This chapter also walks you through several repair procedures that you can follow to get the system back up and running.

Appendix A: ZENworks for Servers 3 Database Schemas

This appendix discusses the several different databases, the various tables, and the attributes of these tables, all of which are used in ZENworks for Servers 3.

Appendix B: ZENworks for Servers 3 Console Commands

This appendix covers the commands that can be entered on the various consoles that are present on the NetWare server, or in an NT/2000 box. Currently, only the ZENworks for Servers 3 policy engine, TED distributor, or TED subscriber can receive console commands.

Appendix C: ZENworks for Servers 3 Resources

This appendix lists other places one can go to find out and get more help with their ZENworks for Servers 3 implementation.


About the Authors

Brad Dayley is a software engineer on Novell's Critical Problem Resolution team. He has nine years of experience installing, troubleshooting, and coding Novell's products. He codeveloped an advanced debugging course used to train Novell's support engineers and customers and is the coauthor of Novell's Guide to Resolving Critical Server Issues and ZENworks for Desktops Administrator's Handbook.

DaNae Dayley has a bachelor's degree in advertising copywriting from Brigham Young University and has owned and operated her own digital media services business for eight years. She provides a wide range of services from copywriting and graphic layout to digital video editing and publishing. DaNae's current biggest project is keeping track of her husband and three sons wherever their Jeep will take them.

Ron Tanner is a networking computer professional who has been with Novell since 1993; he is currently a ZENworks Product Manager, defining future ZENworks products. Prior to being with Novell, Ron worked at AT&T Bell Laboratories developing advanced networking systems. Ron has been involved with the ZENworks project since its inception.


Acknowledgments

Our sincere gratitude goes out to the following persons, without whom this book could not have come in to being:

To Ann Marie Miller, thank you for the hard work you did to ensure the quality and success of ZENworks for Servers and for taking the time to make certain we had what we needed to complete this book.

To the ZENworks for Servers 3 team, thanks for introducing the directory to the server—making administration of the most vital network resource, the server, even easier and more reliable. And thanks for giving us a great distribution service to make getting files there a snap. We're looking forward to many new versions to make the product even better.

To all of those in Novell who allowed us to pick their brains, thanks. Specifically, we would like to mention the following individuals (with apologies to any whose names we have forgotten): Ty Ellis, Ken Muir, Roy Studyvin, Krishnan R, Brian Vaughan, and Jon Pomeroy.


We Want to Hear from You!

As the reader of this book, you are our most important critic and commentator. We value your opinion and want to know what we're doing right, what we could do better, what areas you'd like to see us publish in, and any other words of wisdom you're willing to pass our way.

You can email or write me directly to let me know what you did or didn't like about this book—as well as what we can do to make our books stronger.

Please note that I cannot help you with technical problems related to the topic of this book, and that due to the high volume of mail I receive, I might not be able to reply to every message.

When you write, please be sure to include this book's title and author as well as your name and phone or email address. I will carefully review your comments and share them with the author and editors who worked on the book.

Email: | feedback@novellpress.com
Mail: | Mark Taber Associate Publisher Que Publishing/Novell Press 201 West 103rd Street Indianapolis, IN 46290 USA


Reader Services

For more information about this book or others from Novell Press or Que Publishing, visit our Web site at www.quepublishing.com. Type the ISBN (excluding hyphens) or the title of the book in the Search box to find the book you're looking for.


Chapter 1. Introduction to ZENworks for Servers 3

ZENworks for Servers 3 is an extremely robust tool that is geared toward reducing the overhead of managing large groups of servers in an enterprise environment. This guide helps you through the potential rough spots as you introduce ZENworks for Servers 3 into your network. It also explains a little bit about how ZENworks for Servers 3 functions and affects your NetWare, Windows, Linux, and/or Solaris network and servers. This chapter introduces you to the purpose and advantages of using ZENworks for Servers 3 on your servers and in your network.


What Is the Purpose of ZENworks for Servers 3?

ZENworks for Servers 3 is a server management system. ZENworks stands for zero-effort networks; the name reflects the minimal effort required for you to manage the servers in your network. The goal is to reduce the total cost of ownership (TCO) of dealing with the network by reducing the effort necessary to manage servers. ZENworks for Servers 3 focuses on several areas of server management, which are discussed in the following sections.

Server Management Through Policies

A problem that many server administrators have to deal with is ensuring that all the parameters on a server are appropriate and that no one has been messing around with those server's parameters. Additionally, they may need to change a server parameter on each of hundreds of servers. With ZENworks for Servers 3, the administrator can change that one parameter on all the servers in your network with a single mouse click.

In ZENworks for Servers 3, you can manage selected servers or all the servers in the network through policies that are stored in your directory. These policies enable you to specify such items as server parameters and how a server should shut down (called a downing policy). As ZENworks for Servers 3 continues to mature, many policies that describe server behavior and response will be implemented into the product.

By placing these policies in Novell eDirectory, ZENworks for Servers 3 allows you to enforce a common set of values and behaviors for the servers in the tree. You can associate these policies to any individual server, a group of servers, or to a container higher in the tree and affect all servers below that container. Changing a single value in the policy automatically effects change on all the servers that are associated with that policy—either by direct association or by containment.

Tiered Electronic Distribution

In many environments, files and systems need to reside on many servers across a diverse network. Often an administrator must spend many hours or write many tools to transmit files across the network to many different servers. You may, for example, have several application servers in your network—many in different parts of the world—and you need to make sure that the application files on each of these servers are identical to the golden image that you have in the network. Today, you have to manually copy these files or write some homemade tool to do the work for you. With ZENworks for Servers 3, and, more specifically, Tiered Electronic Distribution (TED), these files can be easily transmitted across the world to all the required servers.

In ZENworks for Servers 3, the administrator goes into eDirectory and administers a set of agents called distributors and subscribers. These agents, through the directory, discover the files that need to be transmitted across the network and efficiently transmit them across to the specified servers in your network. All administration of these agents is stored in eDirectory objects, allowing you to effect change efficiently and completely through the directory.

After these files are received on the target server, the system invokes a local agent to unpack the bundle and deliver it to the specified file directories. TED can move any type of file through the network. TED can distribute files to NetWare, Windows NT/2000, Linux, and Solaris environments.

Server Software Packages

TED, described in the preceding section, is a terrific way to move files through your network to be placed on your servers in or outside your tree. One type of file group that TED can move is called a Server Software Package. These Server Software Packages are sets of files and scripts that describe how the server files are to be automatically installed on a server. Can you imagine the savings if you could move a support pack for your servers through your network with TED and have it automatically installed on all your servers? It's going to save a tremendous amount of time having the system automatically upgrade all your servers with a few commands in the directory.

You, as the administrator, simply go into ConsoleOne. After you're there, you administer a server package. This includes generating a script to load or unload NLMs, services, or Java components; logging out users; and so forth, before and after exercising the installation of the files. You can describe when the Server Software Packages should be installed, on what versions of the server, and so forth. With all this control, you can install the package with confidence.

SNMP Services

The management services that you have become accustomed to in ManageWise are in the ZENworks for Servers 3 product. Additionally, the SNMP services that enable you to receive SNMP alerts and then act on them are also included in the ZENworks for Servers product.

From within ConsoleOne, you can navigate through an updated map of your network, browsing for alerts and looking at the current status of any server or router in your network. This physical view of the world is seamlessly merged with the logical view presented in eDirectory, enabling you to move effortlessly between the two to quickly make any administration changes that require your attention.

Alarm Management Services

ZENworks for Servers 3 continues to provide the alarm management services that were provided in the ManageWise product. ZENworks for Servers 3 enables you to continue to set alarm thresholds on each of the measured attributes for your network or individual server. When these alarm thresholds are hit, the console in ConsoleOne displays the information and follows the procedures that you have outlined with regard to notifying the proper personnel.

Server Inventory and Trending

ZENworks for Servers 3 also performs inventory for each of the NetWare and NT/2000 servers that are in your network. This inventory is stored in a ZENworks database stored on your designated server in the network. From this inventory information you can generate reports, with various options to help you get a handle on the hardware that you have in your network.

Additionally, the trending information is stored in ZENworks for Servers 3, enabling you to get some longer-term information on the performance and behavior of your servers. This enables you to anticipate problems before they happen and get the changes into your network before you see the effects of the problem.

iManage Interface

You have access to a majority of the functionality of ZENworks for Servers 3, particularly in dealing with a specific server, in the iManage interface that is supplied in the NetWare 6 product. iManage is a Web-based interface that runs on NetWare 6 and Windows NT/2000 servers and enables the administrator to manage many aspects of Novell's eDirectory via a browser on any desktop. This can prove extremely useful when you need to make changes to your network quickly while you are on vacation. ZENworks for Servers 3 delivers the plug-ins necessary for the NetWare server that enable you to manage your ZENworks for Servers environment from the iManage interface.

Common Management Console

ConsoleOne is the common administration tool that Novell is using to manage all its products. This allows you to have only a single tool to use and understand to manage all Novell products. Also, with all the administration functionality in a single place, there can be some synergy between the server management and eDirectory management, enabling you to move seamlessly between the logical and physical views of your network.


What Is the Relationship Between ZENworks for Desktops and ZENworks for Servers 3?

The name ZENworks originally was released as the name of a desktop management system. Since then, ZENworks has turned into a product brand name for Novell, and the original ZENworks is referred to as ZENworks for Desktops.

ZENworks for Desktops is considered a separate product and continues to have its own independent releases, development cycles, and feature sets. But some overlap exists between the two products. The ZENworks for Desktops 3 version, for example, has shipped with the capability to interact with the Tiered Electronic Distribution portions of ZENworks for Servers 3, enabling you to transmit application objects and files throughout your network.

ZENworks for Servers 3 uses the same Sybase database engine that ZENworks for Desktops uses to store its inventory and other information. ZENworks for Servers 3 automatically creates tables in its own database files and uses the same Sybase engine that the ZENworks for Desktops installs. The two ZENworks products reuse several of the objects in the tree, and they both follow the same concepts of the policies. The only difference is that ZENworks for Desktops introduces workstation policies, whereas ZENworks for Servers 3 brings server-related policies into the system.


What Are the Benefits of Using ZENworks for Servers 3?

Using the ZENworks for Servers 3 product in your network environments has significant advantages. The greatest benefit comes from the effect of leveraging existing information that is currently in your directory and combining this with the new components and tree extensions provided in ZENworks for Servers 3. By building relationships in the directory between servers and policies that govern their behavior, enormous management potential is gained and is easily available to the administrator. Using the eDirectory tree and its hierarchical nature enables you to manage all the servers in your tree from one place in the tree, or to delegate to local administrators in subcontainers.

ZENworks for Servers 3 also is an easy extension of the current administration system. All the administration requirements for ZENworks for Servers 3 may be administered via snap-ins that are provided and that plug directly into the ConsoleOne administration utility. Additionally, ZENworks for Servers 3 uses the familiar rights associated with your tree to govern the features' accessibility, protecting them from unauthorized users.

The total cost of ownership (TCO) dealing with servers can be significantly reduced through ZENworks for Servers 3. Not only can you be proactive in monitoring and repairing your systems, but you can also ensure that the latest patches and system parameters are being delivered and installed automatically on your systems. This alone should yield a considerable reduction in downtime with your systems. Additionally, the work required to keep common files across the network up to date is minimized as TED is implemented in your system.


Chapter 2. Installing ZENworks for Servers 3

One of the biggest keys to using software tools effectively is to properly plan, prepare, and install them. Properly installing a software product enables you to get started faster and avoids problems later on. This chapter discusses methods and provides checklists that help you plan, prepare, and install ZENworks for Servers 3.


Planning for ZENworks for Servers 3 Deployment

The most important step to take when installing ZENworks for Servers 3 is to sit down and write out a detailed deployment plan. The deployment plan needs to include all NetWare and Windows NT/2000 servers, as well as Unix servers that will be part of your TED channel. You should identify the role(s) that each server will play in your ZENworks for Servers management tree.

Preparing a Network Map

One of the best ways to start planning your ZENworks for Servers deployment is to create a map depicting the layout of the servers that will be impacted by the ZENworks for Servers installation. The map should include the server's name, IP and IPX addresses, and the protocols installed, and it should show the LAN connections, including segment and router information, to the other servers.

One of the most common methods for creating a network map is by using the physical location—for example, group the servers based on the building, city, or country in which they are located. Another common method for creating a network map is by organizing your servers based on their function—for example, group the servers based on the departments they service, such as development, sales, marketing and human resources.

It may be useful to create more than one map and either choose the one that is the easiest to understand, or use them both to help you better understand how ZENworks for Servers 3 will be deployed.

Planning for Management and Monitoring Services

After you create your network map, you need to add data about the ZENworks for Servers 3 roles that the servers will have. We recommend that you first identify the servers' management and monitoring roles.

Management and monitoring services are composed of several agents that are placed on various servers throughout your network. You may place all or a single agent on any of these managed servers, depending on your desired level of monitoring for the target server. The following sections describe the elements that you need to define on your network map to plan for installing ZENworks for Servers 3 management and monitoring services.

Management Site

The first element that you need to identify is the management site. A management site is basically a group of servers that are all managed and monitored from a single point on the network. Many networks have only one management site. You should, however, consider things such as geographical locations, LAN/WAN connections, and administrator roles when defining your management site.

If, for example, you have two offices, one in San Francisco and the other in New York, and each has its own set of servers as well as its own IT staff, you would probably want to create two management sites—one in each city.

After you identify your management site locations, group all servers that you want to be managed into one of the management sites.

Management Server

After identifying your management sites and group of servers, you need to identify one management server for each site that will act as the collection point for management data across the site. All the information, alarms, inventory, and so forth that are captured from other servers in the management site are stored on this management server.

Managed Servers

Next you need to identify target servers that will be managed in each site. Each managed server contains the server management agent, which collects statistics about the server and generates alarms, sending this information to the management server when administered targets are exceeded. This server may also collect statistics about itself and store the data for trending analysis. You may want to include the management server as a managed server as well.

Management Console

After you identify the managed servers, you should take the time to identify at least one management console for each site, although one management console could manage multiple sites. The management console is a desktop client that runs ConsoleOne and contains the plug-ins necessary to manage the service and the servers. You can install the management console plug-ins at the same time you install management and monitoring services, so it's best to install from your management console workstation.

Traffic Analysis Agents

You also need to identify one traffic analyisis agent for each segment on the network. This agent monitors LAN traffic on the segment and performs statistical analysis on the traffic on the segment.

Planning for Policy-Enabled Server Management

After identifying the management and monitoring elements on your network map, you need to identify elements for policy-enabled server management. Policy-enabled server management services comprise several components that can be installed separately on different servers. These components are such items as a TED distributor/subscriber an inventory server, and a remote managed server. The policy-enabled server management components act independently of the management and monitoring services, so you don't need to consider your management sites when planning their roles.

The following sections discuss the elements that you need to define on your network map to plan for installing ZENworks for Servers 3 policy-enabled server management.

TED Servers

The first elements you should define on your network map for policy-enabled server management are the TED distributors and TED subscribers. TED distributors and TED subscribers are NetWare, Windows NT/2000, or Unix servers that act together as a channel to deliver soft ware bundles throughout your network. A distributor transfers the software bundle to a subscriber (and can be a subscriber itself) and receives bundles from another distributor. (See Chapter 6, "Setting Up Tiered Electronic Distribution," for more information about the TED servers.)

Identify the channels to which you want to distribute software bundles, and then identify the servers as distributors, subscribers, or both.

ZENworks for Servers Database

After you identify the TED servers on your network map, you need to identify a NetWare or Windows NT/2000 server on which to create the ZENworks for Servers database. This database stores log messages detailing the TED distribution process, including errors and successes. Use a server that is readily accessible for the TED channel servers as well as your management console.

Inventory Servers

Next you need to identify ZENworks for Servers inventory servers. The inventory servers collect inventory data from other servers on the network. The inventory servers work together in a tree form to collect inventory data and push it up to the central database. Each inventory server can also have its own database that contains inventory data from its level and below. Inventory servers can have the role of standalone, root, intermediate, or leaf. (See Chapter 12, "Using ZENworks for Servers 3 Server Management," for more information about these roles.)

First, identify on your network the servers that you want to use to collect inventory data. Next draw a tree diagram to show the flow of inventory data to a root server. Finally, identify which servers will have a database stored on them.

Inventory Agents

After identifying the inventory servers, define which servers you want to scan and collect inventory data from. These servers will run an inventory scan agent that collects the inventory data and transfers it to an inventory server.

After you mark on your network map all servers that will host the inventory agent, assign them to an inventory server. You do not need to assign them to a leaf server; they can be assigned to an intermediate or even the root server. But each agent that is assigned to an inventory server represents work that a server must perform, so take some time to distribute the load to servers that can handle the pull.

Remote Managed Servers

The final items to identify on your network map are servers that you want to manage remotely. These servers need to have the ZENworks for Servers 3 remote management agent installed on them.


Verifying Installation Prerequisites on Your Servers

After completing your network map, you need to verify that the servers on the map meet the minimum requirements to install ZENworks for Servers 3. The following sections and Tables 2.1–2.15 provide a prerequisite checklist that you should run through, as well as the minimum requirements for each of the ZENworks for Servers components discussed previously in this chapter.

Table 2.1. Management Console Requirements

REQUIREMENT

WINDOWS NT

WINDOWS 2000

Novell Client

4.81 or later

4.81 or later

Windows Service Pack

6a or later

2 or later

ConsoleOne

1.3.3

1.3.3

ConsoleOne Disk Space

70MB

70MB

Internet Explorer

5.0 or later

5.0 or later

Table 2.2. Management Server Requirements

REQUIREMENT

NETWARE 5.1

NETWARE 6

Novell eDirectory

8 or above

8 or above

Support Pack

3

1 ("R" only)

JVM

1.3.1 from Companion CD

1.3.1 from Companion CD

JVM Disk Space

105MB

N/A

Memory

256MB

512MB

CPU Speed

Pentium III

Pentium III

Disk Space

17MB free + 8GB or more for discovery/alarm data

17MB free + 8GB or more for discovery/alarm data

ConsoleOne Disk Space

40MB

40MB

Miscellaneous

Fixed IP address Long name support

Fixed IP address Long name support

Table 2.3. NetWare Managed Server Requirements

REQUIREMENT

NETWARE 4.2

NETWARE 5.1

NETWARE 6

Support Pack

Latest

3

N/A

Memory

256MB

256MB

512MB

CPU Speed

Minimum OS Requirement

Minimum OS Requirement

Minimum OS Requirement

Disk Space

1MB + additional for trend data

1MB + additional for trend data

1MB + additional for trend data

Miscellaneous

Valid IP/IPX address Long name support SNMP Services installed

Valid IP/IPX address Long name support SNMP Services installed

Valid IP/IPX address Long name support SNMP Services installed

Table 2.4. Windows Managed Server Requirements

REQUIREMENT

WINDOWS NT

WINDOWS 2000

Novell Client

4.8

4.8

Windows Service Pack

6 or later

2

Memory

64MB

128MB

CPU Speed

250 MHz Pentium

Pentium II

Disk Space

2.5MB + additional for trend data

2.5MB + additional for trend data

Table 2.5. NetWare Traffic Analysis Server Requirements

REQUIREMENT

NETWARE 4.2

NETWARE 5.1

NETWARE 6

Support Pack

Latest

3

N/A

Memory

620KB free

620KB free

620KB free

CPU Speed

Minimum OS Requirement

Minimum OS Requirement

Minimum OS Requirement

Disk Space

1.5MB + additional for trend data

1.5MB + additional for trend data

1.5MB + additional for trend data

Miscellaneous

Valid IP/IPX address Long name support

Valid IP/IPX address Long name support

Valid IP/IPX address Long name support

Table 2.6. Windows Traffic Analysis Server Requirements

REQUIREMENT

WINDOWS NT

WINDOWS 2000

Windows Service Pack

6 or later

2

Memory

620K free

620K free

CPU Speed

250MHz Pentium

250MHz Pentium

Disk Space

2.5MG 5MB + additional for trend data

2.5MG 5MB + additional for trend data

Internet Explorer

5.0 or later

5.0 or later

Table 2.7. NetWare Policy-Enabled Server Management Server Requirements

REQUIREMENT

NETWARE 5.1

NETWARE 6

Support Pack

3

N/A

JVM

1.3.3

N/A

JVM Disk Space

105MB

N/A

Cache for ZfS Database Space

32MB

32MB

Memory

384MB minimum 512MB recommended

384MB minimum 512MB recommended

CPU Speed

Pentium II

Pentium III

ZfS Disk Space

35MB

35MB

ConsoleOne Disk Space

70MB

70MB

Table 2.8. Windows Policy-Enabled Server Management Server Requirements

REQUIREMENT

WINDOWS NT

WINDOWS 2000

Windows Service Pack

6a or later

2

Memory

256MB

256MB

CPU Speed

Pentium II

Pentium III

Disk Space

35MB

35MB

ConsoleOne Disk Space

50MB

50MB

Table 2.9. Unix Policy-Enabled Server Management Server Requirements

REQUIREMENT

LINUX

SOLARIS

OS Version

Red Hat 7.1 or above

8 or above

Machine Type

IBM-compatible PC

Sun Microsystems

Supported Processors

Intel for Linux

Intel for Solaris or SPARC for Solaris

Memory

128MB minimum 256MB recommended

128MB minimum 256MB recommended

CPU Speed

200MHz Pentium

N/A

Disk Space

150MB

195MB

Policy-Enabled Server Management Web Management Requirements

Before you can install the policy-enabled server management Web components, your NetWare 6 and Windows NT/2000 servers must have the following installed (see the ZENworks for Servers 3 installation manual for instructions on obtaining and installing):

  • Apache Web Server

  • Jakarta Tomcat Servlet Gateway

  • Novell iManager

Before you can manage ZENworks for Servers 3 by using the policy-enabled server management Web components, your management console must have of the following components installed:

  • Windows 95/98— Novell Client 3.31

  • Windows NT/2000— Novell Client 4.81

  • Internet Explorer Version 5.0 or later

Table 2.10. NetWare Inventory Server Requirements

REQUIREMENT

NETWARE 5.1

NETWARE 6

Novell eDirectory

8 with Certificate Server v2.03 and LDAP

8 with Certificate Server v2.03 and LDAP

Support Pack

3

N/A

JVM

1.3.3

N/A

JVM Disk Space

105MB

N/A

Memory

256MB

512MB

CPU Speed

Pentium II

Pentium II

Inventory Disk Space

35MB without database 50MB with database

35MB without database 50MB with database

ConsoleOne Disk Space

70MB

70MB

Miscellaneous

NetWare volume other than SYS Valid IP address Long name support

NetWare volume other than SYS Valid IP address Long name support

Table 2.11. Windows Inventory Server Requirements

REQUIREMENT

WINDOWS NT

WINDOWS 2000

Novell eDirectory

8 or above

8 or above

Windows Service Pack

6a or later

2

Memory

256MB

256MB

CPU Speed

200MHz Pentium

Pentium II

Disk Space

35MB without database 50MB with database

35MB without database 50MB with database

ConsoleOne Disk Space

50MB

50MB

Table 2.12. Inventory Database Server Requirements

REQUIREMENT

NETWARE 5.1 OR 6

WINDOWS NT/2000

Database

Sybase ASA 7.0.1.1540 Oracle8i can be used as an alternative

Sybase ASA 7.0.1.1540 Oracle8i can be used as an alternative

Memory

256MB minimum 512MB recommended

256MB minimum 512MB recommended

CPU Speed

200MHz Pentium

Pentium II

Disk Space

1.5GB leaf level 20GB root level Varies from 1–25 GB

1.5GB leaf level 20GB root level Varies from 1–25 GB

The inventory database server memory and disk space requirements are in addition to the inventory server requirements. Therefore, if you install both the inventory database and the inventory agents on the same server you need to have enough memory and disk space to satisfy the requirements for both.

Table 2.13. NetWare Inventoried Server Requirements

REQUIREMENT

NETWARE 5.1

NETWARE 6

Policy-enabled Server Management

Subscriber

Subscriber

Support Pack

3

N/A

JVM

1.3.3

N/A

JVM Disk Space

105MB

N/A

Memory

256MB

512MB

Table 2.14. Windows Inventoried Server Requirements

REQUIREMENT

WINDOWS NT

WINDOWS 2000

Policy-enabled Server Management

Subscriber

Subscriber

Windows Service Pack

6a or later

2

Memory

256MB

256MB

Disk Space

35MB without database 50MB with database

35MB without database 50MB with database

Table 2.15. Windows Remote Management Requirements

REQUIREMENT

WINDOWS NT

WINDOWS 2000

Policy-enabled Server Management

Distributor (to set up security)

Distributor (to set up security)

Novell eDirectory

8 or above

8 or above

Windows Service Pack

6a or later

2

Disk Space

2MB

2MB

Prerequisite Checklist

The following is a checklist of items that you should verify before attempting to install ZENworks for Servers 3:

  • Latest Novell Client. You should download and install the latest Novell client on your management console and installation workstation(s).

  • DNS Name Resolution. Verify that you have the correct DNS name resolution for your installation and management console workstations, as well as all servers you identified on your network map.

  • eDirectory Connection. Verify that your installation and management console workstations are able to connect through eDirectory to the servers on which you are installing ZENworks for Servers components.

  • ConsoleOne. Verify that your management console workstation is running at least version 1.3.3 of ConsoleOne. This is included on the companion CD with ZENworks for Servers.

  • Novell eDirectory. Verify that your servers are running Novell eDirectory version 8 or above.

  • Support Packs. Install the latest support pack on your NetWare 5 and 6 servers.

  • Java Virtual Machine. Make certain that JVM 1.3 is installed on your Netware servers.

  • Service Packs. Install at least the Windows NT Service Pack 6a and Windows 2000 Service Pack 2 on your Windows NT and 2000 servers respectively.

  • Apache Web Server. Install the Apache Web server on Windows servers that require it.

  • Jakarta Tomcat Servlet. Add Jakarta Tomcat to any Windows Servers on which you installed the Apache Web server.

  • Internet Explorer. Verify that any workstations that you want to manage ZENworks for Servers 3 are using the Web-based tools from a workstation that has Internet Explorer version 5 or above installed.


Installing ZENworks for Servers 3

After you create your network map identifying the servers in your network and the ZENworks components that need to be installed on them, verify that the servers meet the minimum requirements for their components, and complete the prerequisite checklist, you are ready to install ZENworks for Servers 3.

Because the ZENworks for Servers 3 installation guide clearly outlines the procedure to install and upgrade each of the ZENworks for Servers 3 components, we will not discuss those in this book.


Chapter 3. Understanding What Is Placed on Your Servers

This chapter and the following sections discuss the changes that occur on the server when you install various feature sets of ZENworks for Servers 3. The hardware and software requirements of the servers are discussed in Chapter 2, "Installing ZENworks for Servers 3." It is often important to understand the changes that occur on your systems to make good evaluations on where to install the system and to better know how the changes impact the service your servers provide.


Management and Monitoring Services

The management and monitoring services features of ZENworks for Servers 3 are broken into several components for installation. Each component includes applications and system files that will be copied to specified servers. The following subsections discuss the changes for each component added to a server.

Management Site Services

Management site services enable you to perform SNMP trap monitoring—using any SNMP management console to receive and interpret SNMP traps—on the systems and to view status and inventory information about each of your servers. The management site server contains the databases and the services software that are responsible for collecting the SNMP trap information and placing it into the database. Additionally, the management site server runs the discovery and the reporting software to provide information on the servers. Management site services are made up of the components discussed in the following subsections.

Alarm Management

Alarm Manager is a software module in Java that collects the alarms that are sent to it from the various server agents across the network. The responsibility of the Alarm Manager is to take the SNMP alarms that are sent from the various server agents, to categorize them, and to place them into the database on the site server.

Installing this component places the agent on the server and adds a line to execute the NMA5.NCF (a script file to load the alarm management agent) to the AUTOEXEC.NCF, so the agent will be loaded when the server is started. This agent is the host for the SNMP messages. For more detailed information about alarm management, refer to Chapter 11, "Using ZENworks for Servers Alarm Management."

Databases

Several portions of the database for the management services are stored on the site server. An atlas or mapping database keeps track of the topology maps. In addition, entries in the database keep track of the alarms that the Alarm Manager stores.

This service installs an empty Sybase database, \zenworks\mms\db\mw.db, onto the server and prepares it to receive topology, logging, and inventory information about the network.

Role-Based Services

In addition to the objects that are stored in the tree, some code in the system checks your authentication object and sees what roles you have in the system. Based on these roles, specific SQL statements are used to retrieve only specific items in the database. This effectively limits the scope of the devices that individuals can manage.

Additionally, selected functions can be given to these roles to enable users to perform management functions. For additional information on role-based services, see Chapter 8, "Understanding ZENworks for Servers 3 Management Services."

Autodiscovery

As part of the installation, the NetExplorer discovery modules, discussed in Chapter 9, "Preparing and Using ZENworks for Servers 3 Network Discovery," are stored on the management site server. These modules launch various NLM and Java components to perform the discovery of all the devices on the network. After the full discovery of the network is done and stored in the database, the discovery can be placed into automatic mode. Automatic mode enables the system to monitor the network to keep the topology and system up to date. To discover more information about autodiscovery, see Chapter 9.

MIB Tools

Several MIB tools are also stored on the management site server. These tools are used to create and compile MIBs for inclusion into the monitoring and alarming services. MIBs are management information base text files that define what certain SNMP traps are and how to resolve them into English. This enables the ZENworks for Servers 3 system to understand any SNMP device and decipher its communication and data information. For additional information on the MIB tools, see Chapter 8, "Understanding ZENworks for Servers 3 Management Services."

Server Management

Server management is achieved by placing an agent onto the server. This agent samples various components of the operating system and device and then, based on the administered information in the fault management system, it sends SNMP traps to the Alarm Manager to notify the system when a reading is out of alignment. Additionally, this agent takes measurements of the system when requested and saves that information for use in trending and remote monitoring of the servers.

This agent also responds to SNMP messages that are sent to it from the management console to perform various tasks, including sending data for immediate views or modifying configuration parameters on the server.

Traffic Analysis

Selecting Traffic Analysis places a traffic agent on the server. This agent monitors the packets sent on its segment and records information about the system's performance. Traditionally, you should have only a single traffic agent on a segment. The agent can be placed on either NetWare or Windows NT/2000 servers.

Inventory Management

Inventory Management enables you to perform hardware and software scanning of your servers and has this information stored in the inventory database. This information can then be retrieved via ConsoleOne views on the screen or through reports that the system has performed. You can perform inventory management for both NetWare and Windows NT/2000 servers. Inventory Management comprises the elements discussed in the following two subsections.

Inventory Agent

The inventory agent, ZENInvServer, runs either as a Java process on a NetWare server or as a service on a Windows NT/2000 server. The inventory agent performs both the hardware and software scanning of the server. An additional agent is installed on Windows systems that, when contacted by the management system, performs the scan. When the scanning is completed, the information is stored in the inventory database.

Database

The inventory database is located with the management site services and is stored in the zeninv.db database file. This database is also loaded with the Sybase system on the management site server by adding the zeninv.db entry into the mgmtdbs.ncf file, which loads the Sybase engine. As the inventory agents collect data from the servers, their information is stored in the database. A report of the inventory information can be requested via the ConsoleOne snap-in.

Remote Management

ZENworks for Servers 3 provides a Java remote console program. This program runs from ConsoleOne and enables you to perform a remote console, much like RCONSOLEJ. This requires that the agent for remote console be running on the servers you want to control.

ConsoleOne Snap-ins

Managing your servers and the alarms associated with them is performed via ConsoleOne. For the system to properly manage the eDirectory objects, and to interface with the topology and logging database, several ConsoleOne snap-ins, such as atlas.jar, must be loaded. These snap-ins are stored in the ConsoleOne snapins\mw directory at installation.


Policy-Enabled Server Management Services

Policy-enabled server management services enable you to manage the server via policies in eDirectory. Additionally, these services enable you to activate the electronic distribution capabilities of ZENworks for Servers. With TED, you can transmit files across the network and have them placed on any server in the network that has a TED subscriber agent loaded. The policy-enabled server management services are made from the following components.

Server Policies and Packages

This set of software from the system enables you to manage your NetWare, Windows NT/2000, Linux, and Solaris servers from eDirectory. These features include the capability to create policies in a server policy package and then have these policies applied to the servers that are associated with the policy package.

The server software packages represent a set of software files that are constructed into bundles of server software (NLMs, EXEs and so forth) that can be distributed with TED and then installed on the NetWare, Windows NT/2000, Linux, and Solaris servers. The package enables such controls as unloading and loading NLMs or services prior to installation.

For more information on server policies see Chapter 5. A more detailed discussion of server software packages is found in Chapter 7.

The following sections discuss the items that are installed on the identified servers when Server Policy and Packages services are installed.

Server Manager Engine

The Server Manager Engine is a Java program that receives policies through a policy package and applies these policies to the server where this engine is running. The files that are required for the Server Manager engine are stored on the SYS volume in the SManager directory.

The files in the SManager directory are a set of Java libraries and modules that, when run on the server, construct the engine. Additionally, several NLMs are also stored in this directory. These NLMs are helper programs that the Java applications call to perform actions on the server.

To be able to run the Server Manager Engine, each of the servers must be able to run the Java environment and load the several helper NLMs.

AUTOEXEC.NCF Modifications

In the process of the install, the AUTOEXEC.NCF file may be modified. The line SYS:\ZENWORKS\PDS\SMANAGER\ZFS.NCF is added to load the ZFS.NCF file.

The ZFS.NCF file, when executed, starts up the NLMs required for the server to communicate with other servers participating in the ZENworks for Servers system. The file also starts up the Java system with the programs to perform the management functions that control policies being set on servers and software packages being extracted on the subscribers.

Remote Web Console

Remote Web Console is an HTTP service that enables you as an administrator to connect with a browser and receive HTML screens with information from the various distributors and subscribers in your network. You can have as many remote Web consoles in the network as you want, but you do not need a remote Web console on every server that you are managing. You need only one in each geographical location, and from there you can manage all the servers in the system. The Remote Web Console is started on the server with the sys\rwc\rwc.ncf file. If you chose to allow the installer to modify AUTOEXEC.NCF, this command is also added to start the RWC process each time the system restarts.

ConsoleOne Snap-ins

ConsoleOne snap-ins for administration of policy and distribution services are installed on the server or local workstation based on the installation choices. The various snap-ins for policy services are stored in the snapins\zen directory (ZENworks for Desktops 4 also stores some snap-ins in this same directory), whereas the Distribution Services snap-ins are stored in the snapins\ted directory of ConsoleOne.

Policies Database

When you request that a database be placed on the server, the install checks whether the proper Sybase engine has been installed on the server and whether the ZENworks for Servers database is present.

The system makes sure that the Sybase database engine is installed on the server. This database engine is stored in the \zenworks\dbengine directory of the volume you chose during installation. Additionally, the system installs the ZENworks for Servers database called zfslog.db, located in the \zenworks\pds\db\. Although several different databases are stored for the ZENworks for Servers product, this one is the repository for logging the events and activities of the server management engine that enforces and applies policies and for the TED distributors and subscribers. This database, unlike the site management database file, can coexist on a server that has ZENworks for Desktops 3 inventory database. The site management database uses a different version of the Sybase engine to load it.

During the install, the file SYS:\SYSTEM\MGMTDBS.NCF is created or modified to launch the Sybase database with the zfslog.db database files. Several databases may be open on the server at the same time to enable the various aspects of ZENworks for Servers to access their separate databases at the same time. There is only one instance of the actual Sybase NLM, but the several different databases are simultaneously accessible.

Tiered Electronic Distribution

Tiered Electronic Distribution, also referred to as TED, is the system that enables the network to transfer bundles of files, called distributions, across the network to several server destinations. TED has been designed and implemented to be efficient in the network and to handle the scalability needed for the enterprise networks.

The behavior of the TED system is managed via eDirectory objects in the tree. From there, you can identify the sets of files to move and the destinations where the files should arrive. More details concerning the functionality of TED can be found in Chapter 6, "Setting Up Tiered Electronic Distribution."

The TED system is made up of several Java components and some NLMs and DLLs that help in providing direct file support. TED is composed of a distributor that sends distributions to entities called subscribers. The subscribers, when completed with the reception of the distributions, verify their contents and then activate software modules called agents, which are responsible for the unpacking and installation of the distributions. The distributor and subscribers need to be active on the server at all times, whereas the agents are launched only when needed and are terminated when their work is complete. In ZENworks for Servers 3, the distributor and subscriber are combined into a single Java component.

Distributor

The distributor is responsible for sending files to subscribers throughout the network. The distributor is launched on the server by loading the SYS:\ZENWORKS\PDS\TED\TED.NCF file. The TED.NCF file determines whether the server is a distributor and then starts up the Java system, if it is not already running, and starts up threads for the distributor process. The distributor then authenticates into eDirectory and collects the configuration information for itself and all the subscribers to which it sends distributions. If you chose to allow the installer to modify AUTOEXEC.NCF, this command is also added to start the distributor process each time the system restarts.

Subscriber

The subscriber is responsible for receiving files from distributors or "parent" subscribers, which are subscribers who are told to forward files on to another subscriber. The subscriber is launched on a NetWare server by loading the SYS:\ZENWORKS\PDS\TED\TED.NCF file and is a service on Windows NT/2000, Linux, and Solaris servers that can be configured to launch automatically when the system is started. If you chose to allow the installer to modify AUTOEXEC.NCF, this command is also added to start the subscriber process each time the system restarts.

Database

The TED system logs information into the logging database to enable you to run reports against the system. The TED system shares the zfslog.db database with the policy services.


Chapter 4. Setting Up ZENworks for Servers 3 in Your Tree

This chapter provides a quick overview of the ZENworks for Servers system and a high-level view of the changes that occur within your tree when you install ZENworks for Servers. Be sure to understand this system and how it impacts your current Novell Directory Services installations. Other chapters get into the details of installation (see Chapter 2, "Installing ZENworks for Servers 3") and feature execution.


Understanding General ZENworks for Servers 3 Architecture

Novell ZENworks for Servers 3 requires some changes to your directory tree structure (namely, new objects and attributes in the schema) and installs the latest ConsoleOne along with the snap-in extensions to ConsoleOne that ZENworks for Servers 3 requires. Additionally, several components are required on your servers if they are to be able to use the system. This section details the changes that are needed to implement ZENworks for Servers 3 into your network.

Learning about ZENworks for Servers 3 Objects

When you install ZENworks for Servers 3 into your tree, it not only copies the executable files necessary to run the software, but it also extends the schema in your tree. The schema extension in your tree introduces several new objects and attributes to your system. The following is a high-level list of the changes to your schema.

  • Container package object. This object collects for your administration all the policies that are available to be associated with a container. You create one of these objects when you want to affect a container policy. One such policy is the search policy, which affects the limit and order of searching for all ZENworks services in and below the container.

  • Database object. This object represents the database in the network where you are storing such information as logs of ZENworks activity and events, as well as hardware and software inventory information. The service location package object refers to this object and can represent the same database used by ZENworks for Desktops. ZENworks for Desktops and ZENworks for Servers share the same database object; however, they each have their individual configuration parameters that can be independently configured for each product. This object has separate configuration attributes. You get to the configuration by pressing the Properties button.

  • MW account object. This object contains the username and password that the services use to retrieve information from the management domain.

  • MW domain object. This object represents the management domain of information (that is, the database that contains the discovered components in the network). All queries and reports against management information are referenced relative to this domain.

  • MW scope object. This object holds a SQL query that retrieves out of the domain (database) the set of devices that a particular associated user may view and manage.

  • MW service object. This object is an extension of the SAS object and contains additional information to identify the specific ZENworks for Servers 3 management service and relationships with the domain and other management objects. The services on the various servers, which need access to the system, log in to eDirectory by using this object.

  • NT server object. This object is being introduced to represent an NT/2000 server in the network. Other eDirectory objects can then reference this NT/2000 server object to identify the server that has their service. Currently, this object stores the DNS name of the server along with the other traditional server fields.

  • Policy objects. Several policy objects are introduced into the tree, representing policies that are contained in the Server policy packages. Currently in ZENworks for Servers 3, over seven different policies, such as workstation policies, are created and used in the ZENworks for Servers system.

  • RBS module object. This object is a container object that can contain task objects. This is basically a grouping of task objects.

  • RBS role object. This role object identifies the set of tasks that a role can perform. The set of tasks is referenced to the task object or to a module object that contains a set of tasks.

  • Remote Web Console object. This object controls the configuration for the Remote Web Console used in communicating via a browser to the policy and distribution services such as a distributor and a subscriber. The object can specify such items as requiring SSL for the connection.

  • SAS service object. This object may already be in the tree if you have SAS installed (which is normal for NetWare 5 and above, but not in NetWare 4). This object provides a Directory Services authentication method for the agents and services that are running on the servers. The agents and services log in to the directory via these objects. It is discussed here because it will be new for some systems.

  • Server group object. This object enables the creation of a group of servers. This is useful when you want to apply a Server Policy package to a group of servers.

  • Service location package object. This package collects the policies that are in the system that are related to locating services in the network. Currently these policies include the ZENworks Database Location Policy, ZENworks License Policy, TED Policy, and others. You can create them by selecting File [image] New [image] Policy Package in ConsoleOne.

  • Server package object. This object collects all the policies that are available for servers. The policies for servers in the ZENworks for Servers 3 product include such policies as the Server Downing Policy, the Scheduled Down Policy, and the Set Server Parameters Policy. Other server policies that are compatible with this object are also included in the ZENworks for Desktops 4 product.

  • TED channel object. This object represents and holds configuration parameters for the channel, which is a logical grouping of distributions. A subscriber subscribes to a channel to receive distributions that are placed into the channel.

  • TED distribution object. This object represents and holds information about the files to transmit through the network. The channel object refers to this object to identify the distributions that are sent. In a distribution object, you must identify the distributor that is performing the transmission.

  • TED distributor object. This object represents and holds configuration parameters for the distributor on the specified server. As the distributor activates, it retrieves information from its object in the tree to autoconfigure itself. The distributor is responsible for sending files from itself to any subscribers specified in the system.

  • TED external subscriber object. This object represents a subscriber that is not an integral part of the tree. This is a subscriber that is governed by an object in another tree. This object stores the IP address of the remote subscriber.

  • TED subscriber group object. This object represents and holds configuration information for a group of specified TED subscriber objects.

  • TED subscriber object. This object represents and holds configuration information for the subscriber that is running on the specified server. The subscriber receives its configuration information out of this object through the distributor. The subscriber itself does not authenticate and retrieve this information from the Directory.

Existing Objects Modified in the Tree

Installing ZENworks for Servers 3 modifies the following objects that are already in your tree to enable the new attribute zenpolPolicy to be part of these objects: country, locality, organization, organizational unit, group, server, and server group. The zenpolPolicy attribute enables each of these objects to be associated with a ZENworks for Servers 3 policy or policy package. These changes should not increase these objects more than 128 bytes.

In addition to these changes, the server object is modified to also contain a group membership attribute. This enables the server to be associated with groups and maintain links from the server object back to the various groups with which it has membership. Depending on the number of groups with which the server is associated, this attribute consumes approximately 128 bytes for each group membership.

The server object is also extended so that it may contain a new attribute to associate it with an SAS service object. This attribute should take only about 128 bytes.

Discussing Policy Packages and Policies

To help in the administration of all the features and policies of ZENworks for Servers 3, the various policies are conveniently grouped into policy packages. These policy packages are logical groupings of policies that are valuable for a server or service.

Policy packages may be associated with the various appropriate objects. Server packages, for example, may be associated with a single server, a group of servers, or a container. A single policy package may also be associated with several servers, groups, and containers.

Because each ZFS service looks for policies by searching up the tree from its corresponding object in the directory, it is desirable to keep this search from proceeding too far up the tree. Therefore, ZENworks for Servers 3 (along with its companion ZENworks for Desktops 4) includes a search policy found in the Container policy package. This policy limits the number of container levels and the search order that all ZENworks for Servers 3 systems use to discover and apply policies.

Various services are used by the ZENworks for Servers 3 system, and these services are located by the Service Location Policy package. This package is associated with a container and identifies where SNMP traps and the database are located, for example. The applications in the system then use the database that is specified in the location policy.


Starting Up ZENworks for Servers 3 in Your Network

After you have installed ZENworks for Servers 3 into your tree and onto your servers, you need to do some administration to get the product really rolling in your system. This section talks about the basics that you need to do to get the product working in your environment. Subsequent chapters discuss these areas in greater detail.

Starting Up Management and Monitoring Services

Several steps must be accomplished before you can begin the management and SNMP monitoring services for your servers in the network. The management and monitoring services require that several components of the system be up and active. These components are as follows:

  • Management Site Services. This is the server that holds the database and receives all the discovery information and the SNMP traps. This information is stored in the database, and then other agents are activated to perform actions on the information. This must be a NetWare 5 or 6 server. This site server also holds the discovery and MIB tools.

  • Management Console. This is the desktop that is running ConsoleOne and enables you to view the maps, statistics, data, and alarms that have been discovered in the system. ZENworks for Servers 3 installs a local copy of ConsoleOne on the administrator's workstation at installation time. This application is run on a Windows 32 desktop.

  • Server Management. This is an agent that is responsible for monitoring the server and watching for events that warrant an SNMP trap. These traps are then sent to the management server. These agents are run on each NetWare or Windows NT/2000 server that you want to monitor.

  • Traffic Analysis. This is an agent that can run on either a NetWare or a Windows NT/2000 Server and needs to be run on only one server for each managed segment. The data from this agent is also sent to the management server.

  • Inventory Management. An inventory agent exists for both a NetWare and a Windows NT/2000 Server. These agents need to be installed on each server and the inventory is transmitted to the inventory database, stored on the management site server.

  • Remote Management. This is an agent that enables you to perform remote control of the managed servers (that is, servers with the management agent on them). The Windows NT/2000 Server agent is the same as the remote control agent shipped in ZENworks for Desktops 3, and the NetWare agent is a Java remote control agent you place on your NetWare servers. Both these agents are controlled by an interface in ConsoleOne, available on your management console.

To get the basics for management and monitoring services going in your tree, follow these steps after management and monitoring has been installed:

  1. Create an SNMP Trap Target policy, if you want to manage your trap targets through policies, and associate the policy with your managed servers.

  2. Perform the discovery of the network by running the NetExplorer agent on the NetWare Management Server. Allow the system to find the devices (this usually takes hours, depending on the size of the network) and construct the topology map.

  3. Log in to the network via ConsoleOne on your Management Console workstation and drill down into the maps to view information about your servers.

See Chapters 9 and 10, which deal with management and monitoring servers, for more details and discussion on additional features.

Starting Up Policy-Enabled Server Management Services

Policy-enabled Server Management services enable you to control many behaviors of the server via policies that are defined in eDirectory and then associated with the servers. The TED component of Policy-enabled Server Management Services in ZENworks for Servers 3 enables you to transmit files through the network to various server destinations and have those files placed on the remote servers. The distribution is controlled via eDirectory, enabling you to easily manage the distribution services.

To get policy management running in your network, follow these basic steps on each server you installed the Policy-enabled Server Management Services:

  1. Ensure that the file SYS:\ZENWORKS\PDS\SMANAGER\ZFS.NCF is part of your AUTOEXEC.NCF file so that the server starts up the policy engines on the server at each boot.

  2. Create a Server Policy Package in eDirectory by using ConsoleOne and turn on the specific policy that you want applied to your server or servers.

  3. Associate the Server Policy Package, using ConsoleOne, with the servers that enforce the activated policies.

After you have the policy package in eDirectory and have it associated with servers in your tree, these policies are enforced on those servers the next time the agents refresh their policies from eDirectory.

To activate the distribution services in your tree, follow these high-level steps in your system:

  1. Install the Distribution Services from the CD. When you install the services, you can specify where you want the distributor and the subscriber for your distributions. Traditionally, you have a single distributor send the data to several subscribers. The install also creates the objects in the directory for administering the system.

  2. Make sure the distributor and the subscriber are running on the systems. The distributor and subscriber both run from the \ZENWORKS\PDS\TED\TED.NCF file on NetWare servers and as services on Windows NT/2000, Linux, and Solaris servers.

  3. Create a distribution. The distribution has a set of files that you want to have distributed across the network. When you create the distribution, you associate it with the distributor (a particular server).

  4. Create a channel. The channel contains a logical grouping of distributions to which subscribers can subscribe. Make sure to associate at least one distribution and at least one subscriber to the channel.

  5. Resolve certificates. The first time you start the distributor, it creates a public and private certificate set. The public certificate must be copied to the \ZENWORKS\PDS\TED\SECURITY directory on every subscriber that receives or passes along distributions from the distributor. This is a simple process, but very important. You can right-click the distributor object in ConsoleOne and choose Resolve Certificates to have ConsoleOne automatically copy the distributor's public certificate to all the subscribers that need it.

The system should now activate the distributor, which collects the files defined in the distribution and then sends them on to the channel's subscribers. The subscribers should then receive the distribution and unpack it on their respective servers. This happens according to the schedules for the various objects. Remember that the distributor agent needs access to a ZENworks for Servers license to function. For more information about TED, see Chapter 6, "Setting Up Tiered Electronic Distribution."


Chapter 5. Setting Up Server Policies

This chapter provides discussion on setting up policies in the directory and administering them so that they are effective on servers. Additionally, it discusses each of the various policies that are available with ZENworks for Servers 3 and how they function.


Discussing ZENworks for Servers 3 Policies

ZENworks for Servers 3 introduces policies to the servers in your network. These policies are configuration or functional behaviors that may be applied to one or many elements or devices in the network. These policies function similarly to those introduced to the network environment by the ZENworks for Desktops product. Unlike policies in other ZENworks products, ZENworks for Servers 3 has moved to distributed policies for most of their functions. This allows the administrator to send policies to servers that are not in the same tree or have any eDirectory association. The agents running on the server DO NOT walk the tree looking for the policies that are associated directly or indirectly with the server. The agents, when they receive the Policy Distribution package, extract the package and then apply the configuration and other features that are activated in the policies. The only exceptions are that the inventory agents on the server look for a Server Package and a Service Location Package to determine their configuration and database, and that the distributor looks for a TED policy in a Service Location Package, associated to a subscriber and/or distributor object.

Only the distributor in ZENworks for Servers 3 looks for policies for the distributor and the destination subscribers. The distributor uses the Search Policy that may be activated in the Container Policy package to determine the search's behavior. The Search Policy may notify the distributor to walk only to a container, for example, rather than to walk all the way to the root of the tree (potentially crossing WAN boundaries) looking for all the policies. You need to be careful how you place policies and where the search policy is located to ensure an efficient and minimal walking of the NDS tree.

In addition to the server policies and the search policy (in the container policy package) the distributor in ZENworks for Servers 3 looks for information concerning resources to use in the directory. These resources are identified in the Service Location Policy package. This package is traditionally created directly after installation, but this chapter also discusses this policy package and what resources are used in this package for ZENworks for Servers 3.

Although ZENworks for Servers 3 now delivers policies through the Policy Distribution Package, the traditional policies are still supplied and supported in ZENworks for Servers 3 administration tools so that the system can continue to provide policies to your ZENworks for Server 2 systems while you are in the process of migrating.

Understanding Platform-Specific Policies

ZENworks for Servers 3 allows the administration of specific policies for each platform that is supported in the ZENworks for Servers 3 system. By having a policy that is categorized for each type of platform, the administrator can make unique policies for each system. Each server receives the policies in the distribution package and executes the administrative configurations for its platform.

If you want to send a different set of polices to different groups of servers, then you must create a unique channel for each group of servers and subscribe the servers to the appropriate channel. Then you create a unique Policy Distribution Package for each set of servers and place each package in the appropriate channel. The servers subscribed to the channel receive and implement the policies in the package. Remember you can have a subscriber subscribe to any number of channels.

ZENworks for Servers 3 not only incorporates policies for NetWare; it has added policies for Windows, Linux, and Solaris.

Plural Versus Cumulative Policies

ZENworks for Servers 3 has both plural and cumulative policies available in the system.

Cumulative policies are policies that can be activated in multiple policy packages effective for the server. All these policies would be applied to the server regardless of how they become effective for the server. If a server, for example, had two effective server policy packages (two distribution packages coming from the same channel, or two packages each coming from a different channel), and both these policy packages had set parameters activated, then all the set parameters in both the policy packages could be applied to the server. Not all policies are cumulative policies. Not all cumulative policies are plural policies.

Plural policies are policies where more than one instance of the policy may exist within the same policy package. Text file changes policy, for example, is a plural policy. You may create multiple text file changes policies so that several files may be changed by a single policy package. The plural policies have an Add button on their tab, enabling you to add multiple instances of the policy. All plural policies are cumulative, meaning that the plural policies from all the extracted policy packages are applied to the server.

Conflicts in policies can occur and measures exist to handle them. A possible conflict would be if the same set parameter existed in several policies that were effective for a specific server in NDS. When this occurs, the result is that the last policy that is applied to the server wins. The last policy applied is the package with the latest extraction time.


Setting Up a Distributed Policy Package

In ZENworks for Servers 3 most policies are delivered to servers through a Distributed Policy Package that is created and then placed into a Distribution that is then put into a channel for delivery to servers. These policies do not become effective until the policy distribution is delivered and extracted on the target server.

To create a Distributed Policy Package and a Distribution, perform the following:

  1. Create a Channel (see Chapter 6, "Setting Up Tiered Electronic Distribution," for more details).

  2. Create a Policy Distribution Package by doing the following:

    1. Browse to the container where you want to have the policy package. This can be in any container regardless of who will distribute or receive the package.

    2. Create a policy package by right-clicking and choosing New [image] Policy Package or by selecting the Policy Package icon on the toolbar.

    3. Select the Distributed Policy Package object in the Wizard panel and click Next.

    4. Type the package's desired name in the Policy Package Name field and select the container where you want the package to be located. The Container field will already be filled in with the selected container, so you should not have to browse to complete this field. If not, click the Browse button next to the field and browse to and select the container where you want the policy package stored. Click Next.

    5. Select the Define Additional Attributes field to go into the properties of your new object and activate some policies. Click Finish.

    6. Check and set any policies you want for this package and click OK.

  3. Create a Distribution (see Chapter 6 for more details).

    1. Choose a Policy Distribution type for the Distribution and add the created Distributed Policy Package object to the list of policy packages in the Distribution.

  4. Place a Distribution in a Channel and activate the Distribution (see Chapter 6 for more details).

ZENworks for Servers 3, through TED, then creates the Distribution and sends it to all the subscribers in the channel. The subscribers in turn receive the package and extract the package. When the package is extracted the policies in the package are applied to the agents on the target server.


Setting Up a Container Policy Package

To have a container policy package affect the policies, you must first create the policy package. To create a Container Policy Package, do the following:

  1. Start ConsoleOne.

  2. Browse to the container where you want to have the policy package. Remember that you do not have to create the policy package in the container where you are doing the associations. You can associate the same policy package with many containers in your tree. It is a good idea to have at least one Container Policy Package on every segment of your WAN.

  3. Create the policy package by right-clicking and choosing New [image] Policy Package or by selecting the Policy Package icon on the toolbar.

  4. Select the Container Policy Package object in the Wizard panel and click Next.

  5. Type the desired name of the package in the Policy Package Name field and select the container where you want the package to be located. The Container field will already be filled in with the selected container, so you should not have to browse to complete this field. If not, click the Browse button next to the field and browse to and select the container where you want the policy package stored. Click Next.

  6. Select the Define Additional Attributes field to go into your new object's properties and activate some policies. Click Finish.

  7. Check and set any policies you want for this Container Policy package and click OK.

The following subsections describe each of the fields and property pages that are available in the Container Policy package.

Introducing the Policies Page

The Policies page lists the set of available policies and those that are active. Figure 5.1 shows this policy page. Because no platform-specific policies are currently in the Container package, only the General page of the Policies tab is available.

Figure 5.1. The Container Package policy page.

After you create a Container Package, you can activate policies. When you click the check box to the left of a policy within the policy package, that policy becomes active. An active policy is designated by a check in the check box. You can modify the details of any particular policy by selecting the policy and clicking the Properties button.

The Reset button on the Policies page resets the selected policy back to the system defaults for that policy.

Understanding the Associations Property Page

The Associations page of the Container Policy Package displays all the locations in the tree (containers) where the policy package has been associated. These associations do not necessarily reflect where the policy package is located in the directory. The agents that are associated with servers that are in or below those containers have this policy package enforced. Clicking the Add or Remove buttons enables you to add or remove containers in the list that are associated with this policy package.

Defining the NDS Rights Property Pages

The eDirectory Rights property page is made up of three pages. You can get to each of the pages by clicking the small triangle to the right of the page name and then selecting the page you want to be displayed.

These pages enable you to specify the rights that users have to this object in the directory. The following subsections briefly discuss each of these pages. These eDirectory Rights pages are displayed for every object in the tree.

Trustees of This Object Page

On the This Object page you can assign objects as trustees of the Container Policy Package. These trustees have rights to this object or to attributes within this object.

If the user admin.novell has been added to the trustee list, this user has some rights to this object. To get into the details of any trustee assignment (to modify the assignment), you need to click the Assigned Rights button.

When you click the Assigned Rights button, after selecting the user you want to modify, a dialog box appears that enables you to select either [All Attribute Rights] (meaning all the attributes of the object) or [Entry Rights] (meaning the object, not implying rights to the attributes).

From within the Assigned Rights dialog box, you may set the rights the object may have on this package. You can set those rights on the object as well as any individual property in the object. The rights that are possible are the following:

  • Browse. Although not in the list, this right shows up from time to time (especially in the effective rights screens). This right enables you to view this information through public browse capabilities.

  • Supervisor. This identifies that the trustee has all rights, including delete, for this object or attribute.

  • Compare. This enables the trustee to compare values of attributes.

  • Read. This enables the trustee to read the values of the attribute or attributes in the object.

  • Write. This enables the trustee to modify the attribute's contents.

  • Add Self. This right enables the trustee to add himself or herself as a member of the list of objects of the attribute. If, for example, this right were given on an attribute that contains a list of linked objects, the trustee could add himself or herself (a reference to his or her object) into the list.

If you want to add the object as a trustee to an attribute, you need to click the Add Property button to bring up a list of properties or attributes that are available for this object.

From this list, you can select a single attribute. This attribute is then displayed in the Assigned Rights dialog box. From there, you can select the attribute and then set the rights you want the trustee to have for that property. A user does not require object rights to have rights on a single attribute in the object.

Remember that rights flow down in the tree, and if you give a user or an object rights at a container level, those rights continue down into that container and any subcontainers until that branch is exhausted or another explicit assignment is given for that user in a subcontainer or on an object. An explicit assignment changes the rights for the user at that point in the tree. Inheritance rights filters may also be placed to restrict this flow of rights down into the tree.

Inherited Rights Filters Page

The Inherited Rights Filters page enables you to set the inherited rights filter (IRF) for this object. This filter restricts the rights of any user that accesses this object, unless that user has an explicit trustee assignment for this object.

You can think of the IRF as a filter that lets only checked items pass through unaltered. Rights that bump up against an IRF are blocked and discarded if the item is not checked. If, for example, a user who had write privileges inherited at some point above (they were explicitly granted that right at some container at or above the one they're in) were to run into an IRF for an object or attribute that has the write privilege revoked (that is, unchecked), when the user got to that object his write privilege would be gone for that object. If the object were a container, he would lose write privileges for all objects in that container and subcontainers.

You can effectively remove supervisor privileges from a portion of the tree by setting an IRF with the supervisor privilege turned off. You must be careful not to ever do this without someone being assigned as the supervisor of that branch of the tree (given an explicit supervisor trustee assignment at the container where the IRF is done), or you will make that part of the tree permanent (that is, you will never be able to delete any objects in that branch of the tree). ConsoleOne helps to keep you from performing this mistake by giving you an Error dialog box that keeps you from putting an IRF on the [Entry Rights] of the object with the supervisor right filtered away without having first given an explicit supervisor assignment on the same object.

Effective Rights Page

The Effective Rights property page enables you to query the system to discover the rights that selected objects have on the object that you are administering.

Within this page (see Figure 5.2) you are presented with the distinguished name (DN) of the object whose rights you want to observe. Initially, this is your currently logged-in user running ConsoleOne. You can click the Browse button to the right of the Trustee field and browse throughout the tree to select any object.

Figure 5.2. Effective Rights page.

When the trustee object is selected, you may then move to the properties table on the lower half of the screen. As you select the property, the rights box to the right changes its text to reflect the rights that the trustee has on that property. These rights may be via an explicit assignment or through inheritance.

Looking at the Other Property Page

This page may or may not be displayed for you, depending on your rights to the plug-in that now comes with ConsoleOne. This page is particularly powerful and should not be used by those who do not have an intimate knowledge of the schema of the object in question and its relationships with other objects in the directory. The intention of this property page is to give you generic access to properties that you cannot modify or view via the other plugged-in pages. The attributes and their values are displayed in a tree structure, allowing for those attributes that have multiple types (are compound types that consist of, say, an integer and a distinguished name, or a postal code that has three separate address fields).

Every attribute in eDirectory is defined by one of a specified set of syntaxes. These syntaxes identify how the data is stored in NDS. For this page, ConsoleOne has developed an editor for each of the different syntaxes that are currently available in eDirectory. When an attribute is displayed on this page, the editor is invoked to display the data and then modify it should the user click a specific attribute.

If the syntax for an attribute were a string or an integer, for example, an inline editor is launched enabling the administrator to modify the string or the integer value on the screen. More abstract syntaxes such as an octet string require that an octet editor be launched, giving the administrator access to each of the bytes in the string, without interpretation of the data.

The danger with this screen is that some applications require that there be a coordination of attribute values between two attributes within the same object or across multiple objects. Additionally, many applications assume that the data in the attribute is valid, because the normal user interface checks for invalid entries and would not allow them to be stored in the attribute. If you should change a data value in the Other page, no knowledge of related attributes, objects, or valid data values is checked because the generic editors know nothing about the intention of the field. Should you change a value without making all the other appropriate changes or without putting in a valid value, some programs and the system could be adversely affected.

Rights are still in effect in the Other property page and you are not allowed to change any attribute values that are read-only or that you do not have rights to modify.

Using the Rights to Files and Folders Property Page

This page in the property book is present in all objects in the directory. This property page enables you to view and set rights for this object onto the volumes and specific files and folders on that volume.

You must first select the volume that contains the files and folders in which you are interested. You can do this by clicking the Show button on the right and then browsing the directory to the volume object. Selecting the volume object places it in the window labeled Volumes. When that volume is selected, you can then go to the Add button to add a file or folder of interest. This brings up a dialog box enabling you to browse to the volume object; then clicking the volume object moves you into the file system. You can continue browsing that volume until you select the file or directory for which you are interested in granting rights.

Selecting the file or folder in the lower pane displays the rights that the object has been granted on that file or folder. To modify the rights, simply click on or off the rights that you want to have explicitly granted for the object.

You can also see the effective rights that the object has on the files by clicking the Effective Rights button. This displays a dialog box, allowing you to browse to any file in the volume and have the effective rights displayed (in bold) for the object. These effective rights include any explicit plus inherited rights from folders higher in the file system tree. Remember that any user who has supervisor rights to the server or volume objects automatically gets supervisor rights in the file system.


Setting Up a Service Location Policy Package

A Service Location Policy package contains a set of policies that are associated with only containers. These policies are expected to identify the location of resources that other ZENworks for Servers 3 agents, throughout the network, need. These resources are associated through the container to all agents that are working on behalf of the objects in the container and subcontainers.

If, for example, you have set up a service location policy package associated with container A, and activated the database location policy specifying that the database is located on server A, then all the server agents that are on the servers whose server objects are located in or below container A look in the tree and walk up the tree to find the service location policy package associated with container A. In this policy, they would find that the database where they should store their events or logging information is located on server A, because the database location policy in the service location package would be active. The agents would then contact the database on server A and send it their information. The distributor retrieves all associated Service Location Policy policies that are associated with target subscribers and includes this information in each distribution that is sent to that subscriber.

To have a service location policy package to identify resources in the network, you must first create the policy package. To create a Service Location Policy Package, follow these steps:

  1. Start ConsoleOne.

  2. Browse to the container where you want to have the policy package. Remember that you do not have to create the policy package in the container where you are doing the associations. You can associate the same policy package to many containers in your tree.

  3. Create the policy package by right-clicking and choosing New [image] Policy Package or by selecting the Policy Package icon on the toolbar.

  4. Select the Service Location Policy Package object in the Wizard panel and click Next.

  5. Type the desired name of the package in the Policy Package Name field and select the container where you want the package to be located. The Container field will already be filled in with the selected container, so you should not have to browse to complete this field. If not, then click the Browse button next to the field and browse to and select the container where you want the policy object stored. Click Next.

  6. Select the Define Additional Attributes check box to go into the properties of your new object and activate some policies. Click Finish.

  7. Check and set any policies you want for this Service Location Policy package and click OK.

The following subsections describe each of the fields and property pages that are available in the Service Location Policy package. eDirectory Rights, Other, and Rights to Files and Folders pages are described earlier in the chapter in the "Setting Up a Container Policy Package" section.

Explaining the Policies Property Page

All the policies are activated within the Policies property page. Initially, the page is on the General policies. Currently in the Service Location Policy, no platform-specific policies are available, so no drop-down menu is present on this page. The Policies page lists the set of available policies and those that are active. Figure 5.3 shows this policy page.

Figure 5.3. Service Location Package policy page.

After you create a Service Location Package, you can activate policies. If you click the check box to the left of a policy within the policy package, that policy becomes active. An active policy is designated with a check in the check box. To modify the details of any particular policy, select the policy and then click the Properties button.

The Reset button on the Policies page resets the selected policy back to the system defaults for that policy.

Understanding the Associations Property Page

The Associations page of the Service Location Policy Package displays all the locations in the tree (containers) where the policy package has been associated. These associations do not necessarily reflect where the policy package is located in the directory. The agents that are running on servers in or below those containers have this policy package enforced. Clicking the Add or Remove buttons enables you to add or remove containers in the list that are associated with this policy.

Only two policies are used from the Service Location Package: the TED policy that is bundled automatically with distributions and the ZENworks Database policy that is read by the server inventory agents. All other policies must be defined in a Distributed Policy Package for ZENworks for Servers 3.


Setting Up a Server Policy Package

A Server Policy Package contains a set of policies that are associated with servers, either directly or by association with a server group or container. The server inventory agents use only the ZENworks Inventory policy in ZENworks for Servers 3. All other policies must be activated, distributed, and extracted through a Distributed Policy Package to be effective. Defining and activating the policies described in the following sections in a Distributed Policy Package is as described, except all policies are in the Distributed Package rather than in separate packages.

Creating a Server Policy Package

To have a server policy package, you must first create the policy package. Follow these steps:

  1. Start ConsoleOne.

  2. Browse to the container where you want to have the policy package. Remember that you do not have to create the policy package in the container where you are doing the associations. You can associate the same policy package to many containers, server groups, or servers in your tree.

  3. Create the policy package by right-clicking and choosing New [image] Policy Package or by selecting the Policy Package icon on the toolbar.

  4. Select the Server Policy Package object in the Wizard panel and click Next.

  5. Type the desired name of the package in the Policy Package Name field and select the container where you want the package to be located. The Container field will already be filled in with the selected container, so you should not have to browse to complete this field. If not, then click the Browse button next to the field and browse to and select the container where you want the policy object stored. Click Next.

  6. Select the Define Additional Attributes check box to go into your new object's properties and activate some policies. Click Finish.

  7. Check and set any policies you want for this Server Policy package and click OK.

The following subsections describe each of the fields and property pages that are available in the Server Policy package. eDirectory Rights, Other, and Rights to Files and Folders pages are described earlier in the chapter in the "Setting Up a Container Policy Package" section.

Setting Up the Policies Property Page

All the policies for servers are activated within the Policies property page. Initially, the page is on the General policies. As other platforms are selected, additional policies are displayed. You can select which platform to display by placing the mouse over the small triangle to the right of the word "Policies" in the tab (see the next few sections for specifics). This activates a drop-down menu that enables you to select which platform-specific page you want to display. These platforms include Netware, Windows, Linux, and Solaris.

After you create a Server Policy Package, you can activate policies. If you click the check box to the left of a policy within the policy package, that policy becomes active. An active policy is designated with a check in the check box. To modify the details of any particular policy, select the policy and then click the Properties button.

The Reset button on the Policies page resets the selected policy back to the system defaults for that policy.

The Add button enables you to add new, configurable policies to the policy package.

The following sections briefly discuss each of the policy pages, and then I cover the specifics of each policy.

General Policies

When you first go into the properties of the server policy package, you are presented with the Policies property page. The policy page first displays the General category. All the policies that are activated in the General category will be active for all server platforms supported by ZENworks for Servers 3 that have this policy package associated, either directly or indirectly. Currently, the policy that is available for all platforms is the ZENworks for Servers 3 policy. The plural policies that are available for all platforms (by clicking the Add button) are the Copy Files and the Text File Change policies.

Figure 5.4 shows the initial property page of the workstation policy package.

Figure 5.4. Server Policy Package, General property page.

As you can see from the image, only one policy is available to all the platforms supported by ZENworks for Servers 3: the ZENworks for Servers (configuration policy). This, as well as all the other policies, is discussed later in this chapter.

To activate a policy, you simply need to select the box to the left of the policy. You can then go into the details of the policy and set additional configuration parameters on that specific policy.

Windows Policies

Within the Policies tab, you can select the Windows policy page. This page displays the policies that are available for Windows servers. These policies include Server Down Process and ZENworks for Servers. The plural policies that are available for the Windows platform (by clicking the Add button) are Scheduled Down, Server Scripts, Copy Files, Text File Changes, and Scheduled Load/Unload. See Figure 5.5 for a sample of the Windows policies page.

Figure 5.5. Server Policy Package, Windows Policies property page.

If you select the ZENworks for Servers policy on the Windows page, it supersedes that selection on the General page. The policies are not merged together, but only the platform-specific policy is used instead of the policy set in the General category. If the ZENworks for Servers policy is selected in the General tab and in the Windows tab, agents on a NetWare system use the Windows-specific ZENworks for Servers policy rather than the policy in the General tab.

NetWare Policies

Within the Policies tab, you can select the NetWare policy page. This page displays the policies that are available for NetWare servers. These policies include Server Down Process, SNMP Community Strings, and ZENworks for Servers. The plural policies that are available for the NetWare platform (by clicking the Add button) are Scheduled Down, Server Scripts, Copy Files, Text File Changes, Scheduled Load/Unload, and NetWare Set Parameters. See Figure 5.6 for a sample of the NetWare policies page.

Figure 5.6. Server Policy Package, NetWare Policies property page.

If you select the ZENworks for Servers policy on the NetWare page, it supersedes that selection on the General page. The policies are not merged together, but only the platform-specific policy is used instead of the policy set in the General category. If the ZENworks for Servers policy is selected in the General tab and in the NetWare tab, agents on a NetWare system use the NetWare-specific ZENworks for Servers policy rather than the policy in the General tab.

Linux Policies

Within the Policies tab, you can select the Linux policy page. This page displays the policies that are available for Linux servers. These policies include Server Down Process and ZENworks for Servers. The plural policies that are available for the Linux platform (by clicking the Add button) are Scheduled Down, Server Scripts, Copy Files, Text File Changes, and Scheduled Load/Unload. See Figure 5.7 for a sample of the Linux policies page.

Figure 5.7. Server Policy Package, Linux Policies property page.

If you select the ZENworks for Servers policy on the Linux page, it supersedes that selection on the General page. The policies are not merged together, but only the platform-specific policy is used instead of the policy set in the General category. If the ZENworks for Servers policy is selected in the General tab and in the Linux tab, agents on a NetWare system use the Linux-specific ZENworks for Servers policy rather than the policy in the General tab.

Solaris Policies

Within the Policies tab, you can select the Solaris policy page. This page displays the policies that are available for Solaris servers. These policies include Server Down Process and ZENworks for Servers. The plural policies that are available for the Solaris platform (by clicking the Add button) are Scheduled Down, Server Scripts, Copy Files, Text File Changes and Scheduled Load/Unload. See Figure 5.8 for a sample of the Solaris policies page.

Figure 5.8. Server Policy Package, Solaris Policies property page.

If you select the ZENworks for Servers policy on the Solaris page, it supersedes that selection on the General page. The policies are not merged together, but only the platform-specific policy is used instead of the policy set in the General category. If the ZENworks for Servers policy is selected in the General tab and in the Solaris tab, agents on a NetWare system use the Solaris-specific ZENworks for Servers policy rather than the policy in the General tab.


Setting Up a Container Policy Package—Search Policy

A Search Policy governs the behavior of the ZENworks for Servers 3 agents as they search for all other policies. With all the ZENworks for Servers 3 agents, there could be some significant walking of the tree as they search for the policies, especially if the tree is of a significant depth. This is the reason why ZENworks for Servers 3 has this search policy. Often, the performance of your network searching with ZENworks for Servers 3 is not significant until you cross a partition boundary. When you cross a partition boundary, the system must make a connection and authenticate to another server. This is particularly time-consuming should the system need to cross a WAN link.

The search policy tells the ZENworks for Servers 3 agents how far up the tree they should search and what order (object, group, container) should be followed to find the policies. Remember that the order is significant because often the first policy found governs the behavior of the system. In ZENworks for Servers 3 only the distributor and the server inventory agents use the Search Policy; all other agents receive their policies through the Distributed Policy Package and therefore are not required to search the tree. Defining and activating the following policies in a Distributed Policy Package is as described except all policies are in the Distributed Package rather then in separate packages.

NDS Rights, Other, and Rights to Files and Folders pages are described earlier in the chapter in the "Setting Up a Container Policy Package" section.

Looking at the Search Level Page

This page enables the administrator to identify how far up the tree the ZENworks for Servers agents should traverse in their search for policies. Figure 5.9 shows this page.

Figure 5.9. Search Level page of a Search Policy within a Container Policy package.

The following fields may be administered in the Search Level features of the Search Order policy:

  • Search for policies up to. This field enables you to specify the container in the tree that will complete the search. The choices that can be made through the drop-down list may be any of the following:

    • [Root]. Search up to the tree's root.

    • Object container. Search up to the container that holds the object that is associated with the policy. If you were searching for a server policy package, for example, the object container would be the context of the server object.

    • Partition. Search up the tree to a partition boundary. Crossing a partition boundary causes connections to other systems in the tree. This option is available for performance considerations.

  • Selected container. This searches up to the specified container. When this option is chosen, the Selected Container field is activated and you can then browse in this field to the desired container.

  • Search level. This field enables you to specify an additional level of containment beyond that given in the Search for Policies Up To: field. A search-level value of 0 causes searches to be limited to the specified container. A search level of a positive numerical value enables searching up to the specified container and then continues searching upward through the number of levels specified by the positive number. Should the search level be a negative number, the search proceeds only up to the number of levels specified below the specified container. Suppose the value of Object Container is selected, the object is in the Provo.Utah.Novell container, and the search level is 0. The searching stops at the Provo.Utah.Novell container. If the search level is 2, the searching continues to the Novell container. If the search level is –1, no policy is found because the object container is already above the search level.

At first, it may seem that no reason exists for having a negative search level, but there is some value in having this option. Suppose that your tree is set up as Organization.Region.Company, where Organization is the container that is given to each organization in the company and Region represents the area of the company. Now suppose that you want policies to be effective only for each organization. You could set up one single search policy at the Region.Company level with a selected container of Region.Company and a search level of –1. This would enable each organization to have a customized policy and ensure that no organization's policies would impact another because the search would stop at the Organization level.

Describing the Search Order Page

This page enables the administrator to identify the order in which the agents should go looking for policies. The default is object, then group, then container. This policy enables the administrator to change this order.

You can modify the search order by selecting the item in the search order list and then clicking the up or down arrows to rearrange the list. Clicking the Remove button removes the selected association type. Clicking the Add button adds that association type to the search order.

Because the first policy that is found has the greatest significance in the system's behavior, you should be sure that you have the order set (from top to bottom) in the way that you want to find that first policy.

You should be aware that it is a good idea to use the search order policy. Because many ZENworks for Servers 3 features stop walking up the tree when a policy is found, it is wise to make policies search on object, container, and then group. The proximity of these objects in the tree is always going to be closer to the partition on the server. The object is obviously always the closest in the tree to the server object. Next, the container is the closest in the tree-walking scenario because the container must be known for the object to be found in the tree. Consequently, the container is very close in the local replica to the object. Groups, however, can be stored in any container, and they could be in a completely different part of the tree than the object. Therefore, the potential amount of walking of the tree with a group is significant. With any significant walk of the tree there is a corresponding performance cost, and you should consider this as you manage your tree and search policies.

Understanding the Refresh Interval Page

This policy page enables the administrator to identify whether the Policy Manager should refresh the set of policies from NDS and how often to check NDS for new or changed policies. The Policy Manager in ZENworks for Servers 3 is an agent that resides on the server and is responsible for getting ZENworks for Servers 3 policies and enforcing them on the server. This page gives this refresh interval configuration to this agent. If the check box is not selected, meaning the agent should not refresh from NDS, the agent gets the policies only at initialization time—and only again should the server or the agent be restarted. If the check box is checked, the agent checks for any changes or new policies every time the interval has passed.


Setting Up a Service Location Policy Package—The SMTP Host Policy

Several of the features in ZENworks for Servers 3 include the capability to have information and events emailed to identified users. To send the email, the agents must contact the SMTP server in your environment and send the email through that system. This policy enables you to specify the IP address of the SMTP host that the agents associated with this policy (through inheritance) use.

The "Setting Up a Container Policy Package" section earlier in the chapter describes NDS Rights, Other, and Rights to Files and Folders pages.

The SMTP Host page enables administrators to identify the IP addresses of the SMTP mail servers in their environments. Figure 5.10 shows this page.

Figure 5.10. SMTP Host page in the SMTP Host policy of the Service Location Package.

Just place your cursor in the SMTP Host field and type the IP address of the SMTP mail host. This field saves only the IP address. You can type in the DNS name of the SMTP host, but it will be saved as the IP address. The field queries DNS to resolve the IP address and then saves that address here.


Setting Up a Service Location Policy Package—The SNMP Trap Targets Policy

In ZENworks for Servers 3, several agents send an SNMP message to a central server that stores these messages and enables you to print reports on the traps. These traps can identify whether a policy has been successfully applied, whether a distribution was sent successfully, and other potential successes and failures.

The SNMP Trap Targets policy identifies the location of the service that is accepting and recording the SNMP messages from the server agents.

NDS Rights, Other, and Rights to Files and Folders pages are described earlier in the chapter in the "Setting Up a Container Policy Package" section.

Figure 5.11 displays the Trap Targets policy page. The service on the workstation walks the tree to find this policy and uses the service location stored in this policy as the destination of the SNMP messages.

Figure 5.11. SNMP Trap Targets policy page of the Service Location Policy Package.

After you bring up the policy page, you may add as many trap targets as you want. The service on the server sends the SNMP message to all the specified trap targets. Click the Add button and specify whether the destination can be achieved with an IP address, an IPX address, or a DNS name. After selecting the type, a dialog box appears in which you can type either the address or the DNS name of the target service.

After you add the trap targets, you need to specify how often that policy should be applied to the SNMP agents on the service location. Select the Policy Schedule tab shown in Figure 5.11. From the Policy Schedule tab, you simply identify the policy schedule type that you want to apply. When the scheduled time arrives, the system retrieves the SNMP Trap Targets policy and applies it to the agents on the server. The details concerning your choices for the schedule are described in the "Setting Up the Server Policy Package—The SNMP Community Strings" section later in the chapter.

NOTE

This Schedule Policy tab replaces the SNMP Trap Target Refresh policy that was found in the Server Policy Package in earlier versions of ZENworks for Servers.


Setting Up a Service Location Policy Package—The Tiered Electronic Distribution Policy

In a ZENworks for Servers 3 TED system, you can define several configuration items in this policy that are applied to the components in the TED system. Using this policy keeps you from having to administer these items in each of the subscribers or distributors that you create in the network. This policy is found by association and is not placed in the Distributed Policy Package. This policy will be found by the distributor walking the tree, from the perspective of itself or the subscriber, and then including this policy in the standard distribution.

The "Setting Up a Container Policy Package" section earlier in the chapter describes NDS Rights and Other pages.

Understanding the Settings Policy Page

This page is found under the General tab and represents some general configuration settings that are effective for any associated distributors and/or subscribers. Figure 5.12 shows this page.

Figure 5.12. Settings property page of a Tiered Electronic Distribution policy object.

On this property page, you may enter the following settings:

  • Input rate (bytes/sec). This represents the number of bytes per second that you allow a subscriber to consume for all distributions for input. The default is for the system to send at the maximum rate possible on the server. If you choose to enter 4096, for example, the subscriber shall not exceed receiving 4K bytes per second for incoming messages. This setting does not change the I/O rate for the distributor when gathering distributions via the FTP or HTTP agents, which always consume as much bandwidth as possible.

  • Output rates based upon distribution's priority (bytes/sec). This represents the number of bytes per second that you allow a distributor to consume for all subscriptions, based on the distribution's priority. If you entered 4096 into the low priority category, for example, the distribution whose priority is set for Low will not exceed sending 4K bytes per second.

  • Maximum concurrent distributions. Each time the system is going to perform a distribution, it creates a Java thread that handles the distribution to the subscriber. This value identifies the maximum number of threads that you allow the distributor or subscriber to create to service the sending of the distributions.

  • Connection timeout (seconds). The default for this is 300 seconds. You can also enter your own timeout value. When the timeout value is exceeded, the distributor fails the distribution and retries the distribution every 2 minutes for the next 30 minutes (as long as it is still in its scheduled window). If, after all 15 retries, the distribution still has not succeeded, the distributor fails and cancels the distribution and does not attempt to distribute it again until the next scheduled time for the channel to be distributed.

  • Working Directory. This identifies the directory where the distributor or subscriber stores its distribution files. The agents on the distributor, when they are called to collect the files and compress them into the distribution file, store the files in this working directory. The agents on the subscriber use this working directory to uncompress the files before copying them to their final destination. It is not recommended to use the SYS volume because of the potential system problems should that volume become full.

  • Parent Subscriber. This enables you to identify whether the associated subscribers should receive distributions from the specified parent subscriber (as opposed to getting them directly from the distributor).

  • Disk space desired to be left free (MB). This enables you to establish a buffer on your hard drive so that a certain percentage of it will always be free. This is extremely important for large packages so that there is still enough drive space to install the application after it is delivered.

Defining the Messaging Property Page

The Messaging property page is under the General tab and can be configured if you click the active tab and select the messaging under the drop-down menu on the tab (by pressing the small triangle in the tab). Figure 5.13 shows a sample of a messaging page. Unless you are having some problems and are diagnosing some issues, it is not recommended to request a message level higher than 4.

Figure 5.13. Messaging property page of a Tiered Electronic Distribution policy object.

For each of the appropriate fields, you may enter one of the following message levels:

  • Level 6. This level includes all the other levels, plus developer trace information.

  • Level 5. This level includes all Level 4 messages, in addition to trace information, which notifies the observer of the modules that are being executed. This level also captures and displays all Java exceptions.

  • Level 4. This level includes all the Level 3 messages and, in addition, informational messages that identify key points in the system.

  • Level 3. This level displays any warnings that were encountered in the system in addition to all the Level 2 messages.

  • Level 2. This level displays the successes that were satisfied by the system and also includes all the Level 1 messages.

  • Level 1. This level displays only errors that were encountered in the system.

  • Level 0. This level displays no messages.

You can administer the following configuration parameters on the Message property page:

  • Server Console. This item identifies the level of messages that are displayed on the distributor or subscriber console (not the main server console).

  • SNMP Trap. This identifies the level of messages that should be sent as an SNMP trap to the SNMP host. The SNMP Host policy must be defined and active in an effective (for the distributor or subscriber object) Service Location package for traps to be sent.

  • Log file. This identifies the level of messages that should be stored in the log file. Additionally, you can configure the following about the log file:

    • Filename. This is the filename of the log file. The default location for a distributor is SYS:\TED2\DIST\DIST.LOG and SYS:\TED2\SUB\SUB.LOG for a subscriber. You should probably change the location of the log file, because it can grow as well. The log file may adversely affect the system because it is located on the SYS volume by default.

    • Delete log entries older than X days. In this parameter, you identify the number of days (X) worth of log entries that should remain in the log file. The default is 6 days. Therefore, any log entries that are older than 6 days are cleared from the log file. The process of removing the old entries from the log happens once every 24 hours.

  • Email. With the email option, you may specify the level of messages that are sent in an email to the identified users. The SMTP Host policy in the ZENworks for Servers 3 Service Location Policy Package must be active and the package must be effective for the distributor or subscriber object to enable it to discover the address of the SMTP host and send the email. If this is not specified, the email is not sent.

In addition to identifying the level of messages, you must also specify who should receive these messages. To add users to the list, and have them receive the messages, you must select whether you want to add an NDS User or Group or specify an email address in the drop-down menu. When you select a user, you are asked to browse to the user in the directory, and the system takes the email address attribute from the user and uses that as the address for the user. Should you choose a group, all the users in the group are sent the email message, and the email attribute is used for each of those users. Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS User attributes you want to identify as containing the email address. It is expected that the attribute you identify will contain a valid email address.

If you choose to enter an explicit email address, rather than selecting a user or a group, you may choose the E-mail Address choice from the Add button. You are prompted to enter a valid email address. The entered email address is assumed to be valid and is shown as the User Name field in the table with an N/A in the Address Attribute field.

Learning About the Variables Property Pages

Variables enable you to substitute a variable name in the distribution with the value specified for the subscriber. When you create a distribution, you can, for example, use variables in the volumes and directory names. When the distribution is sent to the subscriber and the extraction agent is called, the agent replaces these variables with their defined value in the subscriber object. If no value is given, the variable name (including the %—percent sign) is used for that value.

The variables defined in this policy are additions to the variables defined in any associated subscriber. If you define the same variable in the effective policy and directly in the subscriber object, the variable definition found directly in the subscriber object is used.

Unlike ZENworks for Servers 3 policies and software distribution packages, the TED software performs only basic substitution of variable to value and does not allow you to reference an NDS object or its attribute. This eliminates the requirement that the subscriber have access to NDS and all the objects in the tree. This would be especially difficult if the subscriber were an external subscriber—not even in the same tree as the distributor!

If you created a distribution and specified %DEST_VOLUME% as the volume name, for example, when the subscriber extracts the files, the agent substitutes the variable DEST_VOLUME defined in this property page with the value. If DEST_VOLUME is not defined, a directory called %DEST_VOLUME% is created in the SYS volume.

Remember to be consistent in your conventions and your variable names. You should probably come up with a set of common variables that you define with each subscriber that you set up. When you create a distribution, you can then use these variables in defining the directories in which the distribution will be placed. Remember, determining which subscribers receive the distribution is based purely on who subscribes to the channels where you place the distribution. If you are not consistent in your variables across all subscribers, you may inadvertently send a distribution to a subscriber that does not have the variable defined. This results in the distribution being extracted in a place you do not expect (probably on the SYS volume). Some variables that you should consider defining in each of your subscribers include the following:

  • DEST_VOLUME. Define this variable as the volume that receives the distribution after it is extracted.

  • DEST_APPVOL. Define this to be the volume where your applications are stored.

  • DEST_APPDIR. Define this to be the directory under the application volume where you place your applications.

Looking at the Schedule Property Page

This policy page enables you to specify how often the associated distributor software on the server goes to NDS and reads the configuration information for itself, the distributions for which it is responsible, the channels with which its distributions are associated, and the subscribers that are subscribed to those channels. The default value is Never, which means that the associated distributors read information from NDS only when it is first loaded on the server, anytime you reboot or restart the server or distributor process, or if you explicitly refresh the distributor from the distributor console or from the distributor object in ConsoleOne.

This page enables you to select when the configuration should be read and applied: Never, Daily, Monthly, Yearly, Interval, or Time.

After you select when you want the configuration applied, you have additional fields to select in the lower portion of the screen. The following sections discuss the various options.

Never

This option loads the distributor with the configuration information only when it is first loaded on the server, or after each reboot or restart.

Daily

When you choose to have the configuration applied to the system daily, you need to also select when the changes will be made.

This schedule requires that you select the days when you want the configuration applied. You select the days by clicking the days you want. The selected days appear as depressed buttons.

In addition to the days, you can select the times the configuration is applied. These start and stop times provide a range of time where the configuration will be applied.

You can have the configuration also reapplied within the time frame specified per hour/minute/second by clicking the Repeat the Action Every field and specifying the time delay.

Monthly

Under the monthly schedule, you can select on which day of the month the configuration should be applied or you can select Last Day of the Month to handle the last day, because all months obviously do not end on the same calendar date (that is, 30 days hath September, April, June, and November, all the rest have 31 except for February…).

After you select the day, you can also select the time range when the configuration is reread and applied.

Yearly

You would select a yearly schedule if you want to apply the configuration only once a year.

On this screen, you must choose the day on which you want the configuration to be applied. This is done by selecting the Calendar button to the right of the Date field. This brings up a Monthly dialog box where you can browse through the calendar to select the date you want. This calendar does not correspond to any particular year and may not take leap years into account in its display because you are choosing a date for each year that will come along in the present and future years.

After you select the date, you can also select the time range when the configuration should be read and applied.

To keep all the distributors from simultaneously accessing NDS, you can select Randomly Dispatch Policy During Time Period. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Interval

This schedule type enables you to specify how often to repeatedly read and apply the configuration. You can specify the interval with a combination of days, hours, minutes, and seconds. This type of schedule waits for the interval to pass before applying the configuration for the first time and then for each sequence after that.

Time

This enables you to specify a specific calendar date and time when the configuration is applied. When the current date on the server is beyond the identified date, the configuration is applied.


Setting Up a Service Location Policy Package—The ZENworks Database Policy

Many of the agents in the system want to record information into the ZENworks database that is installed on your system. The ZENworks for Servers 3 agents record logging and other information directly to the database and do not rely on the SNMP system to record events. For these agents to discover in which database they should place their information, they walk the tree from the object representing the system they are supporting until they find an active ZENworks Database Location policy in an associated Service Location Policy Package, or as far up the tree as their effective Search Policy allows.

The Database Location policy then refers to a ZENworks database object in the directory (which was created at installation time), which in turn contains the DN or the IP address of the server that is supporting the database. The system also uses other information in the database object.

The Database Location page enables you to browse to the database object in the directory that represents the database that you want to use. All policy engines and distributor agents associated with this policy then log information into this database. Figure 5.14 is a snapshot of this page.

Figure 5.14. Database Location page of the Database Location policy in a Service Location Policy Package.

In ZENworks for Desktops 3, only the inventory agent for the server looks for this policy. Other agents must be given this policy through the Distributed Policy Package.

NDS Rights, Other, and Rights to Files and Folders pages are described earlier in the chapter in the "Setting Up a Container Policy Package" section.

To set the Inventory Management database, you must go to the Inventory Management Database tab, click the Browse button to the right of the field, and then browse to and select the database object that you want. This places the DN of the database object into the field.

To set the Policy/Distribution Management database, you must go to the Policy/Distribution Management Database tab, click the Browse button to the right of the field, and then browse to and select the database object that you want. This places the DN of the database object into the field.

NOTE

ZENworks for Servers 3 cannot use the database until a database location policy is set and found by the policy engines and distributor agents. Remember that Service Location Packages can be associated only with containers, not directly with servers or with server groups.


Setting Up the Server Policy Package—The NetWare Set Parameters Policy

This policy is a plural policy, which means that you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select NetWare Set Parameters for the policy and type a unique policy name.

After you add the policy, you are guided through a wizard to collect potential parameters. Because the set parameters on NetWare are dynamic and can be enhanced by various sets of NLMs, there isn't a known set of set parameters. Consequently, ZENworks for Servers 3 walks you through a wizard that goes to an identified NetWare server (the server must be running the ZENworks for Servers Policy engine) and queries the server for the set of parameters. This list is then transmitted back to the wizard.

To complete the wizard and to administer the policy, follow these steps:

  1. Click the Add button and select the NetWare Set Parameters policy. Give your policy a name and click OK. When you are back at the policy page, select your new policy and click the Properties button. Click the Add button in the Set Commands window to activate the wizard. The Wizard screen appears, as shown in Figure 5.15.

    Figure 5.15. In the ZENworks for Servers Wizard, select server page for set commands in a Service Location Policy Package.

  2. Click the Browse button and browse the NDS tree to the server that has a representative set parameter list. Select that server. Click the Next button. This causes the wizard to query the server and retrieve all possible set parameters. The screen shown in Figure 5.16 is displayed with the list of potential parameters.

    Figure 5.16. In ZENworks for Servers Wizard, select parameters for set parameters policy in a Service Location Policy Package.

  3. Select the set of parameters that you want to have contained in the policy. You can select an entire category by clicking the check box next to the category, or you can open the category and select individual set parameters. After you select the set of parameters you want to administer the policy, click the Finish button.

  4. You are placed back in the policy with the list of only the categories and/or the parameters that you selected in the wizard. To administer an individual parameter, select the parameter and click the Edit button.

  5. When you click the Edit button, you are presented with a dialog box that is unique for each parameter type. From this dialog box, you may administer the value of the parameter. You may also select one of the following choices: console, autoexec.ncf, and startup.ncf. These choices administer how the parameter is given to the server. Each of these choices is defined as follows:

    • Console. The command is passed to the server console by the policy engine.

    • Autoexec.ncf. In addition to passing the command to the console for immediate activation, the set parameter is placed into the autoexec.ncf file so that, following a reboot, the server sets the parameter.

    • Startup.ncf. In addition to passing the command to the console for immediate activation, the set parameter is placed into the startup.ncf file so that, following a restart, the server sets the parameter.

  6. Complete the list of parameters and click the OK button to apply the policy. The policy engine, on its next refresh cycle, collects this policy and applies it to the servers that are associated with this policy.


Setting Up the Server Policy Package—The Scheduled Down Policy

This policy is a plural policy, which means that you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Scheduled Down for the policy and type a unique policy name. After you do this, you can activate and modify the policy. Figure 5.17 displays a sample scheduled down policy.

Figure 5.17. Procedure page of the scheduled down policy in a Server Policy Package.

This policy enables you to schedule that the server reset, restart, or down at a particular time.

You can select one of the following server options:

  • Reset server. This downs the server and performs a warm boot of the machine.

  • Restart server. This downs and then restarts the server.

  • Down server. This downs the server.

On the Policy Schedule page, you may specify the time frame when you want the server to be reset, restarted, or downed. The details concerning your choices for the schedule are described later in the chapter in the "Setting Up the Server Policy Package—The SNMP Community Strings" section.


Setting Up the Server Policy Package—The Scheduled Load/Unload Policy

This policy is a plural policy, which means that you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Scheduled Load/Unload for the policy and type a unique policy name. After you do this, you can activate and modify the policy. Figure 5.18 displays a sample scheduled load/unload policy. This policy enables you to specify when you want to have a selected set of NLMs or Java processes loaded or unloaded on the server.

Figure 5.18. Scheduled Load/Unload page of the Scheduled Load/Unload policy in a Server Policy Package.

In this policy, select whether you want to load an NLM or Java class, or unload a process, by using the drop-down menu to the left of the Add button. After you make your selection, an entry is placed on the left side of the screen. Corresponding to this entry are some parameters that are displayed and edited on the right. By selecting the entry on the left, you can administer the values on the right. You can edit the entries on the left by selecting the entry (as you do in Windows), and this enables you to change the name to something more useful.

In the fields on the right, you enter the name of the NLM or Java class and any parameters that are needed for the process.

When you are loading a process, you can enter the NLM or classname and also specify the parameters that you want passed to these processes. Additionally, you can specify whether you want to wait for the loaded NLM or Java class to terminate before continuing onto the next item in the list. Make sure you check this box only if you are expecting the process to complete and exit on its own; if you are just loading monitor.nlm, the policy must wait for a long time before it can move on to the next item.

When you are unloading a process, you can enter the name of the NLM or the Java class name. Additionally, you can specify whether you should wait for the termination to complete before proceeding in the list.

After you enter several items in the list, you can select an item and move it up and down the list. This is significant because the items are processed in the order specified, from top to bottom. By selecting any item and moving it about in the list, you can order the loads and unloads in a sequence that is necessary for your process.

On the Policy Schedule page, you can specify the time frame when you want the system to perform this policy. The details concerning your choices for the schedule are described later in the chapter in the "Setting Up the Server Policy—The SNMP Community Strings" section.


Setting Up the Server Policy Package—The Server Down Process

The Server Down Process policy enables you to specify what should happen when the server receives a command to go down. This catches the instances when the user types the down command on the console; this process does not catch any other down request (done programmatically). You can even specify that other servers notify you if the downed server does not come up after a certain amount of time.

The "Setting Up a Container Policy Package" section earlier in the chapter describes NDS Rights.

Describing the Down Procedure Page

The Down Procedure page enables you to specify the procedure that should be followed when the server is downed. Figure 5.19 displays this ConsoleOne page.

Figure 5.19. Down Procedure page of the Server Down Process policy in a Server Policy Package.

The following options on the page are activated when the check box is checked:

  • Follow this procedure when a down server is triggered. This activates or does not activate the procedure identified on this page. If this check box is not checked, this policy will not be in effect for the associated servers. You can specify, when activated, how many minutes the server must wait before it actually performs the down process.

  • Disable login before downing. This effectively runs the disable logins command on the server, disallowing anyone from logging in to the server. You can specify how many minutes before the downing process you want to disallow anyone from logging in to the server. If the number of minutes specified in this field is greater than that specified in the Follow This Procedure When a Down Server Is Triggered field, the disabling of logins occurs immediately when the down request is given.

  • Drop connections before downing. This drops all the current connections on the server before downing the server. You can specify the number of minutes before the actual downing of the server when you want the connections dropped. If the number of minutes specified in this field is greater than that specified in the Follow This Procedure When a Down Server Is Triggered field, the connections are dropped immediately when the down request is given.

Discussing the Ordered Unload Page

By selecting the small triangle drop-down control on the Down Process page, you can select the Ordered Unload page. This page enables you to specify a set of NLMs and Java processes that you want unloaded and the order in which they are to be unloaded before the downing of the server actually begins. Figure 5.20 displays this property page.

Figure 5.20. Ordered Unload page of the Server Down Process policy in a Server Policy Package.

When you select with the Add button to unload either an NLM or a process, a dialog box prompts you to enter the name of the NLM or the process. After entering the name of the NLM or process, click the OK button on the dialog box and the NLM or process name appears in the Ordered Unload page. After you have more than one process or NLM in the list, you can select an item in the list and then move it up or down in the list by clicking the up or down arrows.

Before the server is downed, these systems are unloaded on the server. This is useful if you have such processes or NLMs as databases or other programs that are caching items in memory and need to flush those buffers onto disk. This can be done, usually, by unloading the process or NLM. This can keep your data integrity solid instead of pulling the server out from under these processes, not allowing them to save their data.

Looking at the Reporting Page

The Reporting page is under the Notification tab. The purpose of this page is to identify some companion servers, whose responsibility it is to send notifications if the server that is associated with this policy does not come up after a specified time. When the server is told to go down, it contacts these companion servers and places a scheduled entry to send a notification message. When the server comes back up, and the policy engine is restarted, it contacts these servers again and removes the scheduled entry for the notifications. If the server and the policy engine do not come up in the specified time, these companion servers fire the scheduled entry and send the specified notification messages. These companion servers must also be running the policy engine for this to work. Figure 5.21 displays this page.

Figure 5.21. Reporting page of the Server Down Process policy in a Server Policy Package.

The Send SNMP Alert If Server Is Not Up After a Number of Minutes check box turns on or off the monitoring of the server. You can specify the number of minutes that these other "watcher" servers wait before they send their SNMP alerts notifying you that the server that was downed is not coming back up.

You then must click the Add button and browse the tree to identify the servers that are to monitor this behavior. After you specify more than one server, you can order the servers to identify which server has first responsibility to monitor the downed server. When the ZENworks for Servers 3 engine gets the event that signals the down, it attempts to contact the servers in this list (in order) to notify them to watch for when the server comes back up. If the server in the list cannot be contacted, the engine goes to the next server in the list.

Introducing the Broadcast Message Page

The Broadcast Message page is under the Notification tab. This page enables you to specify the broadcast messages that are sent to the connected users as the system is being taken down. You can specify whether the message should be sent, how many times you want the message sent before the system goes down, the contents of the message, and an additional trailer that tells the users how long before they will be disconnected from the server. Figure 5.22 shows a snapshot of this page.

Figure 5.22. Broadcast Messages page of the Server Down Process policy in a Server Policy Package.

The number of times to send the message before dropping connections or downing the server (if Dropping Connections is not checked) is divided evenly into the number of minutes specified in the Down Procedure page. If, for example, you stated that the server should go down 10 minutes after the request and you specify that the connections should be dropped 4 minutes before downing, the number of minutes that a user has left on the server is 6 minutes (10–4). The number of messages are divided into the 6 minutes and spaced evenly across that time.

If you include the line that states the number of minutes left, the x in the line is calculated the same way as described in the preceding paragraph, minus a broadcast cycle. You subtract one cycle so that the last message is displayed at the beginning of the last cycle (rather than the end).

About the Targeted Messages Page

The Targeted Messages page enables you to send specific email messages to a selected set of users, to notify them of the downing of the server. Figure 5.23 displays a sample of this page.

Figure 5.23. Targeted Messages page of the Server Down Process policy in a Server Policy Package.

The Send Email to Selected Users When Server Is Going Down check box turns off or on this feature. The Email Message box displays the message that is sent to each of the specified users. You are not able to change or customize the message that is sent.

To add users to the list, and have them receive the message, you must click the Add button and select whether you want to add an NDS User or Group, or specify an email address explicitly. When you select User, you are asked to browse to the user in the directory, and the system takes the email address attribute from the user and uses that as the address for the user. Should you choose a group, all the users in the group are sent the email message and the email attribute is used for each of those users.

Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS User attributes you want to identify as containing the email address. It is expected that the attribute you identify contains a valid email address.

If you choose to enter an email address explicitly, rather than selecting a user or a group, you may choose the Email Address choice from the Add button. You are prompted to enter a valid email address. The entered email address is assumed to be valid and is shown as the User Name field entry in the table with N/A in the Address Attribute field.

You can place any number (based on the limits of NDS) of users, groups, or email addresses into the page, and each of them are sent the email message when the server has been requested to go down. The email users get just one message, at the very beginning of the downing process. This gives these users the maximum amount of time to connect to the server and stop the downing process should they desire. They can connect to the server and, via the policy engine console or via Remote Web Console, cancel the down process.

Exploring the Conditions Page

This page enables you to specify conditions when the down server request should not be honored. Figure 5.24 displays this page.

Figure 5.24. Conditions page of the Server Down Process policy in a Server Policy Package.

You must select the Use Conditions in Downing Server? check box to make the conditions effective. Then you can add any number of conditions that you want to identify. If any of these conditions are true, the server does not honor the down server request. Select any of the following choices from the drop-down menu:

  • File Open. Specify whether an identified file is currently open on the server. If that file is open, the system does not allow the down request.

  • NLM or Java Loaded. Specify whether a particular NLM or Java application is currently loaded on the server. The system checks to see whether the NLM or Java application is loaded before it performs any unload of NLMs or Java applications that were specified in the Ordered Unload page. So, if you have an NLM or Java application in the Unload page and in the conditions, the down is halted if the NLM or Java application is loaded.

  • Server Connected. If the identified server is currently connected to the server, the down request is denied.

  • User Connected. If the identified user has a current connection to the server, the down request is denied.

  • Number of User Connections. Specify the number of active connections with which, if exceeded, the down will not be allowed. If, for example, you specify 15 as the number of active connections, and there are 16 or more connections, the down request is denied.

    NOTE

    These are active connections, which include server and agent connections, not just authenticated user connections.

  • Workstation Connected. Identify the workstation that, when connected, halts the down request. You cannot specify a group of workstations, but must identify them individually.

NOTE

This feature functions only when you have ZENworks for Desktops installed in your tree.


Setting Up the Server Policy Package—The Server Scripts Policy

This policy is a plural policy, which means that you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Server Scripts for the policy and enter a unique policy name. After you do this, you can activate and modify the policy. Figure 5.25 displays a sample Server Script policy.

Figure 5.25. Script policy page of the scheduled load/unload policy in a Server Policy Package.

This policy enables you to specify a set of scripts that you want to have run on your server.

You add a script to the policy by clicking the Add button. When you click the Add button, an entry is placed in the left window and you can edit the name of the script. After you name the script, you can choose the type of script that you will be creating. The choices of script types are currently NCF, NETBASIC, and PERL. After you identify the script type, you are free to type the script in the provided window. ZENworks for Servers provides no syntax checking or validation for the script you enter. You may enter ZENworks for Servers variables into the script and they will be processed prior to the script being executed.

You can add multiple scripts of any of the available types into this one policy. The scripts are executed in the order shown on the administration screen (from top to bottom). If you want to reorder the running of the scripts, you must select a script name from the left pane and click the up or down arrows to move the script into a different order.

When the ZENworks for Servers policy engine launches this policy, it creates a temporary script file (in its working directory) that contains the specific script, and then launches the corresponding NLM that works with the identified script, passing the NLM the name of the script to run. Consequently, netbasic.nlm and perl.nlm must already exist on the server where the script is to be run. These are normally installed with the standard NetWare server. Regardless whether a script fails or succeeds, the engine proceeds on to the next script.

On the Policy Schedule page, you may specify the time frame within which you want the system to enforce this policy. The details concerning your choices for the schedule are described in the next section, "Setting Up the Server Policy Package—The SNMP Community Strings."


Setting Up the Server Policy Package—The SNMP Community Strings

This policy enables you to specify the various SNMP community strings that are used in your system for the various levels: Monitor, Control, and Trap. Figure 5.26 displays a snapshot of this simple screen. NDS Rights are described earlier in the chapter in the "Setting Up a Container Policy Package" section.

Figure 5.26. SNMP Community Policy page of the SNMP Community Strings policy in a Server Policy Package.

In this page, you simply need to go to each of the fields and type in the community string that you want configured. These community strings are placed into the SNMP agents on the server, causing the SNMP agents to reset their strings to these values.

The Policy Schedule page enables you to customize (outside of the package default schedule) when you want the community strings applied to the system.

This page enables you to select when the package should be applied: Daily, Weekly, Monthly, Yearly, Relative, Run Immediate, Event, Interval, or Time.

After you select when you want the package applied, you must select additional fields in the lower portion of the screen. The following sections discuss the various options you have with scheduling the package.

Package Schedule

This option runs this policy based on the schedule that has been identified for the entire policy package. This is the default for all policies.

Daily

When you choose to have the policy applied to the system daily, you need to select when the policies are enforced.

This schedule requires that you select the days when you want the policy applied. You select the days by clicking the days you want. The selected days appear as depressed buttons.

In addition to the days, you can select the times the policies are applied. These start and stop times provide a range of time where the policies will be applied.

You can have the policy also reapplied within the time frame every specified hour/minute/second by clicking the Repeat the Action Every field and specifying the time delay.

Weekly

You can alternatively choose that the policies be applied only weekly.

In this screen, you choose on which day of the week you want the policy to be applied. When you select a day, any other selected day is deselected. After you select the day, you can also select the time range in which the policy may be applied.

To keep all the policies from simultaneously applying to the servers, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it retrieves and applies the policy.

Monthly

Under the monthly schedule, you can select on which day of the month the policy should be applied or you can select Last Day of the Month to handle the last day, because all months obviously do not end on the same calendar date.

After you select the day, you can also select the time range within which the policy may be applied.

To keep all the policies from simultaneously applying to the servers, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it retrieves and applies the policy.

Yearly

You select a yearly schedule if you want to apply the policies only once a year.

On this screen, you must choose the day on which you want the policies to be applied. This is done by selecting the Calendar button to the right of the Date field. This brings up a Monthly dialog box where you can browse through the calendar to select the date on which you want your policies to be applied. This calendar does not correspond to any particular year and may not take into account leap years in its display because you are choosing a date for each year that will come along in the present and future years.

After you select the date, you can also select the time range within which the policy may be applied.

To keep all the policies from simultaneously applying to the servers, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it retrieves and applies the policy.

Relative

This option enables you to repeat the policy every x unit of time. The specified time can contain days, hours, minutes and/or seconds. You may specify each length of time by typing the number of each unit in each of the respective fields.

After you identify the intervals, the policy is applied, and the system does not apply the policy until the next specified interval has passed.

Run Immediately

In the Run Immediately option, the system runs the policy immediately upon administration (or refresh of the server). You can then also specify how often to repeat the policy by selecting the Repeat the Action Every field and identifying the delay time. After the policy is applied, the system reapplies the policy after each of the intervals has passed.

Event

When you choose this option, the policy is applied when certain events have occurred. The events that you can select are as follows:

  • System Startup. This applies the policy just after the system has started up.

  • System Shutdown. This applies the policy just before the system is shut down.

  • Custom Event ID. This is a third-party event. This is to be a Java class event that is identified by a third party that they can plug into the ZENworks for Servers policy engine. This feature is currently not documented in ZENworks for Servers. At some future time, the team may provide documentation on the methods to register with the system.

Interval

This schedule type enables you to specify how often to repeat the policy. You can specify the interval with a combination of days, hours, minutes, and seconds. This is very similar to the Run Immediate type, except that this type waits for the interval to pass before applying the policy for the first time.

Time

This enables you to specify a specific calendar date and time when the policy is to be applied. When the current date on the server is beyond the identified date, the policy is applied.


Setting Up the Server Policy Package—The Text File Changes Policy

This policy is a plural policy, which means that you can create multiple instances of this policy in a single policy package. You create this policy by clicking the Add button at the bottom of the main Server Policy Package screen. When you click the Add button, you are prompted to select a policy and to name the policy. You need to select Text File Changes for the policy and enter a unique policy name. After you do this, you can activate and modify the policy. Figure 5.27 displays a sample Text File Changes policy.

Figure 5.27. Text File Policy page of the text file changes policy in a Server Policy Package.

This policy enables you to specify a set of text changes that you want done on ASCII text files on your server.

You enter a requested text file change by clicking the Add button. After clicking the Add button, you are prompted to identify the name of the text file and the name of the change script. You can have multiple change scripts for each file you identify. Make sure you enter the complete filename (including path) for the name of the text file to change. The changes are applied to the specified file in the order shown. Should you wish to change the order of the changes or the order of the files, select the item and move it in the list by clicking the up or down arrows.

The first setting you should make is to choose the change mode that corresponds to this change policy. You may choose either Prepend to File, Append to File, or Search File as one of your modes.

Prepend to File

When you choose to prepend text to the file, the right side of the Administration page changes to display a large text box. You may enter any text strings that you want in the text box. Click OK to store this entry. When the policy is applied, the exact strings that you typed are placed as the first lines in the file.

Append to File

When you choose to append text to the file, the right side of the Administration page changes to display a large text box. You may enter any text strings that you want in the text box. Click OK to store this entry. When the policy is applied, the exact strings that you typed are placed as the last lines in the file.

Search File

Should this change be a Search File change, you need to administer the following additional information to make the change effective:

  1. Identify the search type that you need for this change. The search type may be Sub-String, Whole Word, Start of Line, End of Line, or Entire Line. The following describes the meaning of each of these search types.

    • Sub-String. Search for the search string in any of the text. The text specified may be contained anywhere in the file, even in the middle of a word. If you have the substring of day, for example, the following text would all match with this substring: today, day, yesterday, daytime, and so forth.

    • Whole Word. Search for the string such that it is surrounded by white space or is at the beginning or end of a line. If you have the string of day, for example, only the word day would be a match. The words today, yesterday, daytime, and so forth do not constitute a match.

    • Start of Line. This is a successful match if the beginning of a line (first line of file, or characters following a carriage return) starts with the string, regardless of whether the string is a whole word or not. To continue the example, if you had the string day, this type would match only with the following lines: daytime is set, day by day, and so forth.

    • End of Line. This is a successful match if the end of a line (characters preceding the carriage return or end of file) contains the string, regardless of whether the string is a whole word or not. With the example, if you had the string day, this type would match only with the following lines: the time to act is today, day by day, and so forth.

    • Entire Line. The entire specified string must consume the entire line of text (from text following a carriage return, or beginning of the file, to the next carriage return, or end of the file), including any white space. It must be an exact match of every character, other than the carriage returns, on the line. If your string were day, only a line with the single word day in it would match.

  2. Specify the search string that you're trying to match. Enter this into the Search String field.

  3. Identify whether you want the search to be case-sensitive by selecting the check box to make the search identify a match only if the case matches.

  4. Change the Find All Occurrences field if you want to find only the first occurrence of the string in the file. The default is to have this field checked, meaning that all occurrences in the file have this policy applied to them.

  5. Choose a result action that is applied to the string after it is located in the file. The possible actions are Delete All Lines After, Delete All Lines Before, Prepend to File If Not Found, Append to File If Not Found, Replace String, Replace Word, Replace Line, and Append Line. The following describes each of these choices and their resulting actions:

    • Delete All Lines After. All lines (characters following the next carriage return) are deleted from the file. The file is basically truncated, ending with the line that held the first matching string. Obviously, searching for all occurrences is not effectual when this is the resulting action, because a match truncates the rest of the file.

    • Delete All Lines Before. All lines (characters before and including the previous carriage return) are deleted from the file. The file is reset such that it begins with the line that held the first matching string. With this result action, another search continues and if another match is found, all the lines before it are deleted as well.

    • Prepend to File If Not Found. This action places the replacement text in the file at the very beginning of the file should the search string not be found in the file. This action only adds text; it does not delete or modify text.

    • Append to File If Not Found. This action places the replacement text at the end of the file should the specified search string not be found. This action only adds text; it does not delete or modify text.

    • Replace String. This action takes the matching string and removes it from the file, placing the replacement string in the exact location of the deleted string. If the replacement string is of a different length than the search string, the surrounding characters are shifted to the left or right depending on whether less or more room is required. Basically, the new text is inserted in the location where the search string was removed.

    • Replace Word. This action takes the word where a substring was matched and replaces the whole word (from space or beginning of line to space or end of line) with the replacement text. If the substring were day, for example, the following words would be replaced with the replacement text: day, today, daytime, and so forth.

    • Replace Line. This action takes the line where the match has occurred and removes the complete line from the file. The replacement text is placed in the same location where the removed line was located in the file.

    • Append Line. This action appends the replacement string to the line that contained the match. The matching string is not removed from the file; the only change is the addition of text to the end of the line.

  6. Specify the new string. In the text box that is provided, you need to supply the text that will be applied to the file, based on the action that was specified.

Policy Schedule Page

On this page, you can specify the time frame when you want the system to apply this policy. The details concerning your choices for the schedule are described in the "Setting Up the Server Policy Package—The SNMP Community Strings" section earlier in the chapter.


Setting Up the Server Policy Package—ZENworks for Servers

This policy contains the configuration information that is used by the ZENworks for Servers 3 engine that is the controlling process on the server. The engine is responsible for taking care of communicating with NDS, watching the schedule of all policies, and launching subprocesses to apply the various policies to the server. This policy applies to the configuration of the engine itself. Figure 5.28 shows this screen.

Figure 5.28. Messaging page of the ZENworks for Servers policy in a Server Policy Package.

In this policy, you may set the messaging level you want for each of the various components available to you for notification: Server Console, SNMP Traps, Log File, and E-mail Message. You may set a different level of messages for each of the various notification conduits. The Server Console refers to the ZFS screen that is on the server when the engine is running. You may choose from any of the following choices:

  • Level 6. This level includes all the other levels plus developer trace information.

  • Level 5. This level includes all Level 4 messages in addition to trace information, which notifies the observer of the modules that are being executed.

  • Level 4. This level includes all the Level 3 messages and, in addition, informational messages that identify key points in the system.

  • Level 3. This level displays any warnings that were encountered in the system in addition to all the Level 2 messages.

  • Level 2. This level displays the successes that were satisfied by the system and also includes all the Level 1 messages.

  • Level 1. This level displays only errors that were encountered in the system.

  • Level 0. This level displays no messages.

When you specify that messages are going by email, you can identify any number of users or groups of users or a specified email address.

Adding Users to the List

To add users to the list, and have them receive the message, you must click the Add button and select whether you want to add an NDS User or Group, or specify an email address. When you select a user, you are asked to browse to the user in the directory and the system will take the email address attribute from the user and use that as the address for the user. Should you choose a group, all the users in the group are sent the email message, and the email attribute is used for each of those users. Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS User attributes you want to identify as containing the email address. It is expected that the attribute you identify will contain a valid email address.

If you choose to enter an email address explicitly, rather than selecting a user or a group, you may choose the Email Address choice from the Add button. You are prompted to enter a valid email address. This entered email address is assumed to be valid and is shown as the User Name field in the table with N/A in the Address Attribute field.

You can place any number (based on the limits of NDS and the Java control) of users, groups, or email addresses into the page, and each of them are sent the email messages.

Discussing the Configuration Page

This page enables you to configure some additional parameters in the ZENworks for Servers 3 engine. Figure 5.29 displays this page.

Figure 5.29. Configuration page of the ZENworks for Servers policy in a Server Policy Package.

In this page, you may configure the following information:

  • Console Prompt. This enables you to specify the prompt that you want to have displayed on the ZFS console screen.

  • Working Directory. This specifies the working path on the server that the engine should use for its temporary files.

  • Purge Database Entries. You can specify the number of days old that a database log entry can be before it is removed from the ZFS database.

Several variables can be used in this and other places in ZENworks for Servers 3. These variables are enclosed in % (percent signs) and can be a defined set, an environment variable from the server, an attribute of the server object, or an attribute of a specified NDS object. The order is as follows:

  1. If the string between the percent signs is a predefined variable, that value is placed in that string. Predefined variables are one of the following:

    • LOAD_DIR. The directory where the NetWare server was loaded.

    • TREE_NAME. The name of the tree where ZENworks for Servers is located.

    • WORKING_PATH. The working directory for the temporary files.

    • SERVER_DN. NDS distinguished name for the server object.

    • IP_ADDRESS. IP address of the server.

    • BASE_PATH. The base path of where the ZENworks for Servers policy engine is located (for example, SYS:\SMANAGER).

    • SERVER_NAME. Name the server was given at install time.

  2. If the string has the format %object distinguished name;attribute%, the attribute value of the specified object is placed in the string. The string %rtanner.novell:username%, for example, would return the value of the username attribute in the object rtanner.novell.

  3. If the string has no semicolon, the system looks for an environment variable of that name and replaces the value in the string.

  4. If no environment variable exists with that name, the name is assumed to be a server attribute and the system attempts to place the attribute's value in the string.

Introducing the ZENworks for Servers Port Configuration Page

ZENworks for Servers 3 has added the port configuration panel to enable you to specify the port number used by the ZENworks Web Server. Typically, you should leave the port number at the default. But if you need to modify it because of a conflict, you can change the port number by using the up or down buttons to increment or decrement the port number.


Setting Up the Server Policy Package—The Copy Files Policy

The Copy Files policy is a plural policy that enables you to configure ZENworks to copy or move files on a server from one location to another. The Copy Files policy can be an extremely powerful tool that you can use for file distribution or synchronization on a server.

The following is a list of parameters that can be configured from the file copy policy:

  • Source Path. Specifies the full path where the files to be copied are located. (You can use the following wildcards in the path: *, ?, and ???.)

  • Target Path. Specifies the full path where the copied files are to be placed. (You can also use wildcards in the target path.)

  • Include Subfolders. Tells ZENworks to include all files in all subdirectories beginning from the directory that ends the path. If this box is not checked, only the files in the directory at the end of the path are copied.

  • Maintain Attributes. Tells ZENworks to maintain the file attributes in the target path's file system.

  • Overwrite Destination Files. Specifies whether you want ZENworks to overwrite files of the same name in the destination directories. If this box is not checked, files of the same name are not replaced.

  • Maintain Trustees. Tells ZENworks to maintain the file's trustee attributes. You should plan carefully whether you want ZENworks to maintain the files' trustees so that users do not gain access to files they should not.

  • Retry Times. If this box is checked, ZENworks retries overwriting a locked file the number of times specified.

  • Kill Connection of Open Files. If this box is checked, ZENworks kills any connection that has the file open so that it can be overwritten. You should use caution when setting this option because it can result in users losing data.

  • Error Processing. Selecting Fail On Error (enabled by default) stops the file copying process when an error is encountered in copying. Selecting Continue On Error causes file copying to continue on with the next file.

  • Operation. Specifies whether you want ZENworks to copy or move the files identified in the Source Path. Moving has the advantage of freeing up disk space in the source location. But if you are trying to synchronize or replicate files, you need to use the Copy feature.

WARNING

Make certain that you do not have any read-only files or directories in the copy files locations. ZENworks for Servers 3 applies the attributes to the locations prior to copying the files. Therefore, if you set a directory to read-only and ZENworks tries to copy it, ZENworks creates the directory in the destination location, sets it to read-only, and then error on every file it tries to copy into that directory.

Use the following steps to configure a copy files policy from within ConsoleOne:

  1. Right-click the Server Package and select Properties from the drop-down menu.

  2. Select the Policies tab for one of the following platforms: General, Linux, Solaris, Windows, or NetWare.

  3. Click the Add button.

  4. Select Copy Files.

  5. Specify a policy name and click OK.

  6. Select the Copy Files policy you created and click the Properties button to display the File Copy page.

  7. Click the Add button to add a new file or directory.

  8. Edit the name of the file copy to a descriptive name. (Local File Copy #n is the default.)

  9. Set the options for the file copy as shown in Figure 5.30.

    Figure 5.30. File Copy page of the ZENworks for Servers policy in a Server Policy Package.

  10. Select the Schedule tab and schedule the policy.

  11. Click the OK button to apply the policy.


Chapter 6. Setting Up Tiered Electronic Distribution

This chapter discusses the construction, deployment, and administration of the ZENworks for Servers 3 Tiered Electronic Distribution (TED) subsystem. As part of ZENworks for Servers 3, TED provides a mechanism to enable you to reliably transmit files from server to server throughout your entire network, independent of eDirectory trees and server platforms. TED is designed to be a high-end distribution service that can handle the complexity of a very large network made up of multiple eDirectory trees as well as NetWare, Linux, Windows, and Unix servers.


Understanding the General Architecture for TED

To get the most out of ZENworks for Servers 3 Tiered Electronic Distribution, you need a high-level understanding about the architecture of TED. This section discusses the components of TED and how to consider placing them into your network.


Introducing the Components

Tiered Electronic Distribution in ZENworks for Servers 3 comprises the following components:

  • Distributor. This is a Java software process that runs on a NetWare server and as a service on a Windows NT/2000 Server. This software is responsible for distributing the files to the subscribers in the network. The distributor also calls on some TED agents to collect the files and bundles them into a distribution that can then be sent to the subscribers (see the next item).

  • Subscriber. This is a Java software module that may run on a NetWare or as a service on a Windows NT/2000 Server. The subscriber is responsible for receiving software distributions from distributors or parent subscribers. The subscriber also calls TED agents, when appropriate, to perform additional actions on the distributions after they are received.

  • Parent subscriber. A Java software package that runs on a NetWare or a Windows NT/2000 Server. This module fulfills two purposes. The parent subscriber is first a subscriber and can receive and extract distributions for the server on which it resides. However, it additionally has the responsibility of forwarding some distributions on to other subscribers, when instructed. This module is the same software as the subscriber; the only difference is that the requests sent to parent subscribers have additional information that instructs the subscribers to act as parent subscribers and pass the distribution on to at least one other subscriber, thus reducing the number of subscribers to which the distributor must actually pass the software. This means any subscriber can become a parent subscriber by simply listing it in the routing hierarchy on a distributor object, or by listing it as a parent subscriber in any subscriber object.

  • Routing Table. Each distributor has a routing table that contains a hierarchical list of subscribers who can receive distributions, as well as pass them on to other subscribers.

  • TED agents. These are Java modules that are started by the distributor or the subscriber and have a specific function. For example, there are agents whose job it is to collect files and collapse them into a distribution package suitable for transmission to subscribers. There are also agents who are responsible for expanding these distributions and placing the extracted files on the servers that have received the distribution.

  • Certificates. Distributors create certificates to provide secure distributions by issuing them to all subscribers receiving distributions from that distributor. For a subscriber to accept distributions from a distributor, it must have a certificate in its security directory from that distributor.

In ZENworks for Servers 3, the distributor and subscriber are the same Java software component. Whether the component behaves as a logical distributor, parent subscriber, or subscriber depends on the function that it must currently perform. Several logical TED components may reside on the same server. For example, you may have a server that is both a distributor and a subscriber, and agents when creating and extracting files from a distribution.

eDirectory Objects

TED uses objects in the directory to help direct and control its configuration and behavior in the network. The following objects are associated with TED components:

  • Distributor object. This object may be placed anywhere in the tree and holds the configuration information for the distributor.

  • Subscriber object. This object contains some configuration information that the subscriber uses. This object is never actually accessed by any subscriber (removing the need for a subscriber process to access eDirectory); instead, the distributor reads the configuration information from the subscriber objects and sends this configuration information to the subscriber agents with every distribution.

  • External subscriber object. This object refers to a subscriber that is outside the distributor's tree. The configuration information for this subscriber is contained in a subscriber object in its own tree or in a local configuration file. This object is used to enable TED to distribute across tree boundaries or to servers that are not in any tree.

  • Subscriber Group. This object represents a set of subscriber objects with common channels. You can configure the channels for the subscriber group and then assign subscriber objects as members of the group to share the channels.

  • Distribution object. This object represents the collection of files that you want to transmit as a bundle across the network to various subscribers. A distribution is owned by a single distributor. That distributor is responsible for collecting, packaging, and distributing all the files listed in the distribution object.

  • Channel object. This object represents a set of distributions and subscribers that are grouped together. When you place a distribution into a channel, all subscribers associated with the channel receive the distribution. When you place a new subscriber into a channel, all distributions associated with the channel are sent to the subscriber.

When you install TED components, you can specify which servers in the network will be distributors and subscribers and their relationship with any channels. The channel relationship can also be constructed after the installation process through ConsoleOne.

The following list describes the relationships of the various components of TED:

  • Distributors create certificates and copy them to subscribers for distribution security. Distributions are built on the distributor server. The same distributor sends the distribution to any of the subscribers (or parent subscribers) that will be receiving the files.

  • Subscribers subscribe to channels to obtain distributions. A subscriber subscribes to many channels and receives all the distributions that are placed in each of the channels. External subscribers are subscribers that subscribe to a channel in an eDirectory tree to which they do not belong (that is, to the tree where they get their configuration information).

  • Parent subscribers are identified either as a parent in the routing hierarchy list in any distributor object or as the parent subscriber in any subscriber object.

  • Channels are collections of distributions and subscribers. Subscribers and distributions are associated with the channel. Essentially, the channel describes a set of subscribers that should receive the set of distributions. Distributions from many distributors can be placed in a single channel.

  • Distributions are collections of files that are sent in the TED system. Each distribution belongs to a single distributor and can be placed in multiple channels. A distribution may be placed in any number of channels, and the distributor is responsible for sending the distribution to all the subscribers that are subscribed to the channels.

TED also uses digital certificates and message digests of the distributions to verify the contents and originators of the distributions. When a distributor is doing the gathering process (that is, the agent is actively collecting the files and placing them in the distribution file), it runs a message digest on the distribution. When the distributor is sending the distribution, it sends a header to the subscriber that includes the digest and other information—all digitally signed with the distributor's signature. When the subscriber receives the header, it checks the distributor's digital signature with the digital certificate that it has for the server. (You need to install this certificate on the subscriber through ConsoleOne or manually.) If the signatures match, the subscriber proceeds with the download. When the download is complete, the subscriber runs its own message digest on the file and compares the results with the digest the distributor placed originally in the header. If they match, the file is deemed valid and the subscriber proceeds to schedule the agents to handle the unpacking of the distribution.


Discussing TED Configuration in Your Network

You need to consider how you want to lay out TED into your tree and network. You need to take into account any WANs that you must use for your distributions and be careful to minimize the amount of traffic transmitted over a WAN link. TEDs from ZENworks for Servers 3 are designed to handle anything from the smallest network to large enterprises and can be configured to help minimize this traffic. However, you must set up TED and administer its functions to get these gains.

Examining a Simple Layout

To help in the explanation, let's take an example of a simple and then a complex tree and discover the best method to lay out TED components to get the best performance for your network. Look first at Figure 6.1, which shows a simple tree.

Figure 6.1. Simple example tree for TED distribution.

As you can see in Figure 6.1, the tree (SIMPLE_TREE) contains a tree that is assumed to be all in a single campus where no WANs are involved. The TED configuration for this setup can be fairly simple, because there are only eight servers in the system. To not overburden a distributor or a parent subscriber, you should not have a distributor or parent subscriber support more than 40 subscribers. Because there are not going to be more than eight subscribers in the network, this simple example needs only a single distributor and eight subscribers (one on each server, including the distribution server).

The number of channels that you want is based on the types of distributions that you would expect to perform or the time schedules within which you want the distribution sent. It is recommended that you base your channels on the types of distributions you expect to send or the schedules you want to keep, rather than the destination. For example, you should name your channels Sales Data, Base Engineering Apps, Virus Patterns, Europe Off Hours, and so forth. By naming your channels this way (rather than Building1, for example), it will be clear by the name of the channel what type of distributions can be expected to be transmitted to the subscribers attached to the channel. You can have any number of channels in the directory, and a subscriber can subscribe to any number of channels, so there is no reason to limit the channels that you create.

In the SIMPLE_TREE, we create three channels: Sales Apps, Eng Apps, and Sales Data. We place a distributor on server A because the sales data is written on this server, and a distributor on server B because it holds all the golden images of the engineering applications. We place a subscriber on each of the other servers and associate them with the appropriate channels. Figure 6.2 displays the same tree with all the channels, distributors, and subscribers in place. Subscribers G and H both subscribe to channels Sales Data and Sales Apps. Subscribers B, C, E, F, and G subscribe to the Eng Apps channel.

Figure 6.2. Channels, subscribers, and distributors for the simple example tree.

This layout is used because of the needs of each of the servers, regardless of their location in the network or the tree.

Looking at a Complex Layout

Now let's take a look at a more complex tree, one that includes some WAN traffic to cross container boundaries. Figure 6.3 is a demonstration of this type of tree.

Figure 6.3. WAN example tree for TED distribution with channels, subscribers, and distributors.

In the WAN tree you can see Provo, Paris, Honolulu, and Sydney. Provo is in the United States, Paris in France, and Sydney in Australia, so a WAN is required to interconnect these sites. There is an added complexity that is not shown: To get to Sydney from Provo you must first make a WAN hop in Honolulu and then the final WAN hop to Sydney. To throw in a twist, we'll have a sales server in the mix, server 7, that is getting information from a Sales channel from somewhere in the tree.

Because WANs are involved, you want to minimize the traffic that must go over the WAN lines. You can accomplish this by placing a parent subscriber at each of the WAN sites and then connecting each of the destination subscribers in the target WAN to that parent. In the case of Sydney, we need to have a parent subscriber send the distributions to another parent subscriber in Sydney, because it is a two-hop scenario.

We look at only two channels: one called Sales Data (collected and distributed by an unshown distributor) and one called TID Data that is used to transmit all the TID files that are collected at the main Provo site and then transmitted to each of the support sites across the world. We would want to set up the following channels, distributors, and subscribers to support the WAN tree (see Figure 6.4).

Figure 6.4. Subscribers, distributors, and channel configuration for the WAN example tree.

As you can see, there are two channels: the TID channel in Provo and the Sales channel that is somewhere in the tree. (It is really not relevant where the channel is located.) We have connected subscribers 3, 4, 5, and 6 to the TID channel in NDS. We have also made sure that subscriber 7 is connected to the Sales channel. The distributor is simply shown to exist in the Provo LAN and is not fully shown in the tree. Suffice it to say that it exists on a server in Provo in the same tree as shown.

Now we must define the parent subscribers in the network for distributor 1 (in the Provo LAN) to be the most efficient in its use of the WANs. If we do not define parent subscribers, the distributor transmits to each subscriber directly. This results in the same files being transmitted to Paris twice, to Honolulu three times, and to Sydney twice, for a total of seven WAN transmissions. See how this would work out by looking at Table 6.1. As you can see, they each take one hop except for Sydney, which requires a hop through Honolulu and then to Sydney.

Table 6.1. WAN Hops for WAN Tree Transmissions

LAN

# OF WANS

TO SUBSCRIBER

Paris LAN

1

Subscriber 3

Paris LAN

1

Subscriber 4

Honolulu LAN

1

Subscriber 5

Sydney LAN

2

Subscriber 6

Sydney LAN

2

Subscriber 7

Now we can describe in NDS the network's parent subscribers. This can be done in one of two ways: as a routing hierarchy in the distributor object, or as a parent subscriber identification in each "child" or "leaf" subscriber (see Figure 6.5).

Figure 6.5. Subscribers, distributors, and channel configuration for the WAN example tree.

The quickest way to define this would be to go to distributor 1's object in the tree and define the following routing hierarchy:

  1. Subscriber 3

    1. Subscriber 4

  2. Subscriber 5

    1. Subscriber 6

      Subscriber 7

This would state to the distributor that when it is distributing its collections, subscriber 3 will service subscriber 4, and subscriber 5 will service subscriber 6, who then services subscriber 7. If you look at the behavior of TED when this is done, the following transmissions occur over the WAN (see Table 6.2).

Table 6.2. Optimized WAN Hops for WAN Tree Transmissions

LAN

# OF WANS

TO SUBSCRIBER

Paris LAN

1

Subscriber 3

Local, from subscriber 3

0

Subscriber 4

Honolulu LAN

1

Subscriber 5

Sydney LAN, passed from subscriber 5

1

Subscriber 6

Local, from subscriber 6

0

Subscriber 7

You can see now that we transmit the files only three times over a WAN and have saved almost 233% of the traffic that we would have consumed had we not done parent subscribers.

One annoyance is that when you define the routing hierarchy in the distributor, only that distributor knows of this configuration. You have to go to all the distributors in that LAN and put this same routing hierarchy into their objects. This can also be a great benefit, because it enables you to set up different distribution routes depending on the distributor that is sending the information. For example, you might have a financial information distributor, but you may not want that financial information passing through a certain subscriber. By defining a separate distribution hierarchy on the financial distributor, you can eliminate certain servers from ever getting the financial information. To save you some aggravation with having to describe your whole network, you can leave the leaf node subscribers out of the routing hierarchy definitions and identify their parents in their own objects. The distributor automatically discovers this and includes it in the routing list. (See the "Construction of a Routing Hierarchy" section of this chapter for more information.)

Looking at a Tree Spanning Layout

Now let's take a look at some example of spanning distributions across tree boundaries. ZENworks for Servers 3 also enables you to distribute software independent of trees by using external subscriber objects (discussed later in this chapter). You can get benefits from spanning distributions across trees in various ways.

You might want to span trees if you need to maintain similar distributions in each of your trees. Imagine that you have one tree for your corporate office in Houston and another tree for your manufacturing plant in Detroit. The distance and dissimilar functions of the two sites makes having a single tree unreasonable, but both sites use the same accounting and payroll system, which needs to be updated occasionally. The value of an external subscriber is for the occasional use of sending the accounting and payroll distribution from the corporate tree to the manufacturing tree, instead of duplicating the distribution creation work for the same distribution in both trees.

You might also want to span trees if you need to send a distribution outside your firewall, perhaps to another business. Let's say your business manufactures a product that is distributed by one company and then sold by a third company. You could create an external subscriber for both the distributor and the reseller. Then you could create a distribution for product schedules and the like. That way a single distribution could update not only the appropriate offices in your own business, but your distributor and reseller as well, and all three companies can stay current.

Examining Capacities and Restrictions

It's a good idea to review some of the issues that you should watch in your network to make sure that you don't attempt to overburden your servers with distribution work. This concern is relative to the number of dependents a distributor must support and where distributors must be in the network.

Looking at Dependents

As was mentioned earlier, you should attempt to not overburden any distributor or parent subscriber with more than 40 direct dependents. This can be difficult to manage, and you need to keep a careful eye on how you configure your subscribers and distributors to keep this from becoming a problem. The issue is that you really don't know at the beginning which distributors will be sending to which subscribers, because that determination is based purely on which channel you chose to place the distribution. The easiest way to keep this all working well is to think about your TED distribution network from the bottom up as you are constructing the system. As you place subscribers into the network, choose a hierarchy of well-known parent subscribers, making sure that no branch of your TED network is overburdened.

For example, imagine that you start with the TED distribution network shown in Figure 6.6.

Figure 6.6. Phase1 hierarchy of subscribers in TED distribution network.

As shown in Figure 6.6, subscribers 3 through 63 are set up so that they each use either subscriber 1 or 2 as the parent subscriber. Subscribers 66 through 84 use subscriber 64 as their parent subscriber. In the figure, the levels of the hierarchy (levels 1–4) are labeled to help you understand where in the structure each of the subscribers reside. Now, when you want to add more subscribers, you can either place them hierarchically, under some other subscribers at level 2, or you can create a new level 1 and go from there. Just keep in mind that you want to keep the TED distribution hierarchical tree balanced somewhat so as to not overburden any one subscriber or distributor.

This leveling approach works well for a single LAN. When you move into multiple LANs and introduce a WAN link, you need to have this leveling in each of the LANs in your network and then describe in the distributors how you may efficiently move from one WAN to the next, based on their locations. For example, distributor X may only have one hop to LAN Y, but distributor M may have two. So, the routing hierarchy defined in distributors X and M will be different with regard to how to most efficiently get to LAN Y.


Configuring TED Systems

There are several algorithms that you should know to help you determine the best configuration of TED components. The following sections shed some light on how the internals of TED components function.

Construction of a Routing Hierarchy

The distributor is responsible for constructing a routing hierarchy when it sends each distribution. The following describes the steps that the distributor follows to construct the hierarchy:

  1. The distributor discovers all the subscribers (that is, leaf subscribers) that are to receive this distribution.

  2. The distributor looks into the routing hierarchy that has been administered in its eDirectory object. For each subscriber, it looks to see whether that subscriber is in its hierarchy list. If it is, it sends the distribution to that subscriber following the routing hierarchy defined in the distributor object.

  3. If the subscriber is not found in the administered list, the distributor looks in the subscriber's object to see whether it has identified a parent subscriber. If a parent subscriber is identified, the distributor then looks for the parent subscriber in its routing hierarchy list.

  4. If the parent subscriber is in the routing hierarchy list, the distributor follows the hierarchy described to get to the parent subscriber and then tack the end-node subscriber onto the route to get the distribution to the subscriber.

  5. If the parent subscriber is not in the distributor's routing hierarchy list, the distributor sends the distribution directly to the identified parent subscriber (identified in the subscriber's object) or directly to the subscriber (when no parent subscriber is identified).

You should note that in the algorithm the distributor does not go to the subscriber and get its parent and then go to the parent and get its parent, and so forth, trying to construct the hierarchy of subscribers. The distributor goes up only one level in your TED distribution hierarchy. Therefore, you must, if you have more than one level of subscribers, describe n–1 levels in the routing hierarchy in each distributor object. You can then leave the last level undefined in the distributor, defining it in each subscriber object (or in a TED policy that affects each subscriber) instead.

The following is a list of guidelines you should use when constructing your routing hierarchy:

  • Include at least one parent subscriber on each LAN segment. This significantly reduces the amount of traffic across a WAN link.

  • Include multiple parent subscribers on each LAN that has 40 or more subscribers. The performance of distributors and parent subscribers is significantly reduced when they are assigned more that 40 subscribers.

  • Make certain that any subscribers that are not included in a distributor's distribution round are assigned to a parent subscriber on the same LAN.

Designing Distribution Routes

Now that you understand how to construct a route hierarchy, you should consider the following when designing your Distributor's routing hierarchy:

  • Distribution Route. A distribution route should represent the most efficient path to any given segment of your LAN or WAN. A distribution route is made up of a list of parent subscribers that are responsible for transferring distributions through the channel. The distribution route should use parent subscribers to minimize the workload for a distributor by spreading the workload of distributions.

  • End-Node Subscribers. An end-node subscriber is the last subscriber in a distribution route to receive a distribution. End-node subscribers do not need to be added to the routing hierarchy, because they receive only the distributions.

  • Distribution Topology. The distribution topology is the LAN/WAN topology that the distributions must follow on their assigned routes. You should consider your WAN topology design and the number of subscribers on each LAN and then build the routing hierarchy to reflect your network topology.

  • Multiple Distributors. By using multiple distributors you can place the same subscribers under each of them, effectively creating the same distribution route for each distributor.

  • Reuse Subscribers. A subscriber can be used more than once, as long as you have multiple distributors to assign it to. However, you should be careful not to overload the subscriber.

Scheduler Interactions

As you introduce yourself to the various components of the TED system (distributor, subscriber, distribution, channel), you will discover that each component has its own independent scheduler to determine when its work is done. That seems clear enough at first, but it becomes confusing as you try to jumble how the schedules of these various components can keep or enable a successful distribution.

This section briefly examines the various schedulers for each component and how they can play together to create a functioning TED system in your network. The following list looks at each of the components and the responsibility the scheduler plays:

  • Distributor schedule. Determines when the distributor reads eDirectory for the configuration information for itself, its distributions, and any channels and subscribers it interacts with. It discovers the channels and subscribers by looking at any distributions that it has in any channels and the subscribers that are hooked to these channels. The distributor also looks for the eDirectory objects for any TED policies that may affect the configuration of itself, channels, or subscribers, and includes them in its configuration information. The information for a subscriber is collected from eDirectory when the distributor schedule fires, and it reads the information from eDirectory. Any changes to the subscriber objects or policies that affect the subscribers need to be made in eDirectory prior to the distributor refresh schedule firing. This information is then sent on to the subscribers when a distribution is given to them.

  • Distribution schedule. This schedule determines when the agents on the distributor server will be activated to perform any gathering of the files and compact them into the single distribution file. This process must be completed before the channel begins its processing or the distribution needs to wait until the next channel cycle. The gathering does not occur if the distribution is inactive or does not belong to a channel with active subscribers. ZENworks for Servers 3 has added downstream control that forces all downstream distributors to stop distributions when the send schedule ends. The distributions start up again the next time the send schedule starts.

  • Channel schedule. Determines when the distributor transmits any previously constructed distribution files to any destination subscribers. Any distribution files that have not been constructed when the channel is activated (based on the schedule) have to wait until the next firing of the channel schedule to be transmitted. The transmission is terminated if the time has expired for the channel, and the transmission picks up where it left off on the next scheduled time for the channel.

  • Subscriber schedule. Determines when the subscriber activates the agents on the subscriber server to extract any files from distributions that have been received and have not been processed. The extraction continues after it has started on a particular distribution even if the time has expired for the extraction schedule.

Looking at the network, you would want the time frames to occur in your systems as represented in Figure 6.7.

Figure 6.7. Schedule coordination time frame.

For example, if you schedule your distributor to refresh the configuration each day at the close of the day (say 5:00 p.m.), and then schedule the distribution to gather the files at 6:00 p.m., and then the channels to begin their distributions at 10:00 p.m., and the subscribers to extract at 4:00 a.m., the cycle could be completed in the night. This obviously gets more complicated when you cross time zone boundaries. You could simplify this some by having, possibly, channels for each different area of the world, which would have a different local time to begin the distribution so that the remote site and the local site will be busy at appropriate levels.

NOTE

The channel schedule is "translated" into the distributor's time zone. For example, if the channel schedule says 3:00 p.m. MST and the distributor is in California, the distribution starts at 2:00 p.m. PST. If you have a distributor in New York that also has distributions in this channel, the distribution starts at 5:00 p.m. EST. This means that all distributors with distributions in a channel start sending at the same time, regardless of time zone.


About the TED Distributor

The TED distributor has the responsibility for transmitting a distribution (collection of files) to subscribers throughout the tree and to external subscribers that are found outside the distributor's tree. The distributor calls TED agents to collect the files and compact them into a distribution file that is then sent to the appropriate subscribers.

The distributor is managed by command-line commands (see Appendix B for more details), by the iManager Web management tool, and by a distributor object that is placed in the tree. The following sections discuss each of the pages that can be administered on the distributor object. Traditionally, because the distributor is associated with the server (a distributor object is expected for each server that is running a distributor), it should be named so that the server is clearly known. The default naming by the installation process is Distributor_<SERVERNAME>, and the distributor object is created in the same container where specified.

NOTE

TheTED distributor and subscriber objects should be created only through the installation program on the product CD. This ensures that the NCF files on the servers authenticate with the correct objects in NDS. If you move or rename a distributor object, you need to update the PATH:\ZENWORKS\TED\DIST\DIST.NCF file with the new DN of the distributor object or it ceases to function. All other TED objects can be moved and renamed, but remember to refresh the distributor after any change to these objects.

The distributor is the only TED component that queries NDS and reads its object. The distributor reads its distribution object, the channel objects, and any policies when it starts on the server, when requested through the console with a refresh command, if you right-click the distributor object in ConsoleOne and choose the Refresh Distributor option, or as scheduled in the distributor object. The distributor also reads any subscriber related to the distribution they are to send and relays any updates in the subscriber object and policies (such as the Tiered Electronic Distribution policy in the Service Location Policy package) to the subscriber when the distribution is sent.

Introducing the Settings Property Page

This page is found under the General tab and represents some general configuration settings that are effective for this distributor. Figure 6.8 displays a capture of this screen.

Figure 6.8. Settings property page of a distributor object.

On this property page you may choose the following settings:

  • Input rate. This represents the number of bytes per second that you allow a distributor to consume for all distributions for input (acknowledgments and so forth). The default is for the distributor to send at the maximum rate possible on the server. For example, if you choose to enter 4096, this distributor will not exceed receiving 4KBps for incoming messages. This setting does not affect the rate at which FTP and HTTP distributions are gathered. The distributor will always use as much bandwidth as is available when gathering distributions.

  • High Priority. This represents the number of bytes per second that you allow a distributor to consume for all high-priority distributions' output.

  • Medium Priority. This represents the number of bytes per second that you allow a distributor to consume for all high-priority distributions' output.

  • Low Priority. This represents the number of bytes per second that you allow a distributor to consume for all high-priority distributions' output.

  • Maximum concurrent distributions. Each time a distributor is going to perform a distribution, it creates a Java thread that handles the distribution to the subscriber. This value identifies the maximum number of threads that you allow the distributor to create concurrently to service the sending of distributions. The Maximum Number of Concurrent Distributions value is affected by prioritizing because it is subordinate to the priorities set for the distributions. For example, imagine that you have the concurrent distribution number set to 10 and there are 4 high-priority distributions, 5 medium-priority distributions, and 20 low-priority distributions. Initially, the 4 high-priority distributions are to be sent concurrently; the 5 medium-priority distributions must wait until all 4 high-priority distributions are complete. Then the 5 medium-priority distributions are sent concurrently and only after they are complete are 10 of the 20 low-priority distributions sent.

  • Connection timeout. The default for this is 300 seconds. You can also enter a timeout value that, when exceeded, causes the distributor to fail the distribution and retry it every two minutes for the next thirty minutes (as long as it is still in its scheduled window). If after the retries the distribution still has not succeeded, the distributor fails the distribution, and at the next scheduled distribution time for the channel the distributor will reattempt to send the distribution.

  • Working directory. This identifies the directory where the distributor stores its distribution files. The agents, when they are called to collect the files and compress them into the distribution file, store the files in this working directory. It is not recommended to use the SYS volume because of the potential system problems should that volume become full.

Looking at the Messaging Property Page

The Messaging property page is under the General tab and can be configured by clicking the active tab and selecting the messaging value under the drop-down on the tab (which you find by clicking the small triangle in the tab). Figure 6.9 provides a sample of a Messaging page. Unless you are having some problems and are diagnosing some issues, it is recommended that you use level 4 or lower.

Figure 6.9. Messaging property page of a distributor object.

For each of the appropriate fields, you may enter one of the following message levels:

  • Level 0. This level displays no messages. In the Messaging page, you can administer the following items regarding the behavior of the distributor.

  • Level 1. This level displays only errors that were encountered in the system.

  • Level 2. This level displays the successes that were satisfied by the system and also includes all the level 1 messages.

  • Level 3. This level displays any warnings that were encountered in the system, in addition to all the level 2 messages.

  • Level 4. This level includes all the level 3 messages, as well as informational messages that identify key points in the system.

  • Level 5. This level includes all level 4 messages in addition to trace information, which notifies the observer of the modules that are being executed. This level also captures and displays all Java exceptions.

  • Level 6. This level includes all the other levels plus developer trace information.

You can administer the following configuration parameters on the Message property page:

  • Server Console. This item identifies the level of messages that are displayed on the distributor server console (not the main server console).

  • SNMP Trap. This identifies the level of messages that are sent as an SNMP trap to the SNMP trap target. The SNMP Trap Targets policy must be defined and active in an effective (for the distributor object) Service Location policy for traps to be sent.

  • Log file. This identifies the level of message that should be stored in the log file. Additionally, you can configure the following about the log file:

    • Filename. This is the filename of the log file. The default location is SYS:\TED2\DIST\DIST.LOG. You should change the location of the log file, because it can grow as well and may adversely affect the system if it is located on the SYS volume.

    • Delete log entries older than X days. In this parameter you identify the number of days (x) worth of log entries that should remain in the log file. The default is six days. Therefore, any log entries that are older than six days will be cleared from the log file. The process of scanning for and removing old log entries happens once every 24 hours and is not configurable.

  • Email. With this option, you may specify the level of messages that will be sent as email to the identified users. The SMTP Host policy in the ZENworks for Servers 3 Service Location policy package must be effective for the distributor object to enable it to discover the address for the SMTP host to send the email. If this is not specified, the email is not sent.

    In addition to identifying the level of messages, you must also specify who should receive these messages. To add users to the list and for them to be sent the message, you must select User, Group, or E-mail and click the Add button and specify the NDS User or Group, or an email address. When you select a user, you are asked to browse to the user in the directory, and the system takes the email address attribute from the user and uses that as the address for the user. Should you choose a group, all the users in the group are sent the email message and the email attribute is used for each of those users. Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS User attributes you want to identify as containing the email address. Many administrators store user email addresses in the Internet E-mail Address attribute instead of the E-mail Address attribute. It is expected that the attribute you identify contain a valid email address.

    If you choose to enter an explicit email address, rather than selecting a user or a group, you may choose the Email Address choice from the Add button. You are prompted to enter a valid email address. The entered email address is assumed to be valid and is shown in the Username field in the table with an N/A in the Address Attribute field.

Introducing the Distributions Property Page

This page of the distributor object identifies the defined distributions that this particular distributor is responsible for collecting and sending. You cannot add distributions on this page—they are added or deleted in this list only when the actual distribution object is created or deleted from NDS. You may look at the distribution object, however, by selecting the distribution in the list and clicking the Details button. This launches the property pages for the selected distribution object.

About the Routing Hierarchy Property Page

The Routing Hierarchy property page is one of the most important pages to administer, especially if you have WANs in your tree and you want to be efficient in your distribution of files. Figure 6.10 shows a sample of this page.

Figure 6.10. Routing Hierarchy property page of a distributor object.

On this property page you can define the hierarchy associating the distributor to subscribers. This is the path that the distributor uses in sending distributions to the subscribers. As discussed in the "TED Configuration in Your Network" section, this page defines the route that you want TED to follow when attempting to transmit a distribution from this distributor to any identified subscriber.

On this page you build a hierarchy tree that describes the routes that the distributor must follow. You place a child in the tree by selecting the parent and clicking the Add button. You are then required to browse the NDS tree and identify the subscriber(s) you want to insert. For example, if you wanted the routes shown in Figure 6.4 placed into this distributor, you would perform the following steps:

  1. Select the distributor 1 object in the list (the topmost item). Click the Add button.

  2. Browse NDS and select subscriber 3 in the tree.

  3. Select subscriber 3 in the list and click the Add button.

  4. Browse NDS and select subscriber 4 in the tree.

  5. Select the distributor 1 object in the list and click the Add button.

  6. Browse NDS and select subscriber 5 in the tree.

  7. Select subscriber 5 in the list on this property page and click the Add button.

  8. Browse NDS and select subscriber 6 in the tree.

  9. Select subscriber 6 in the list and click the Add button.

  10. Browse NDS and select subscriber 7 from the tree.

The hierarchy shown in Figure 6.11 should be displayed on the Routing page after you have completed the preceding steps.

Figure 6.11. Routing Hierarchy property page of a distributor object after the route has been entered.

Using the routing algorithm, the distributor now sends any distributions to subscriber 3 that are bound for either subscriber 3 or 4, and sends any distributions to subscriber 5 that are bound for subscriber 5, 6, or 7.

NOTE

The subscriber can be in the routing table and send distributions to other subscribers even if they are not participating in the channel for the end-target subscriber. They simply forward the distribution on and do not extract it on their local systems.

The routing hierarchy must be entered for each distributor object in the tree. If there are no entries in the hierarchy, the distributor relies on only the parent subscriber, which can be defined in the subscriber object to give any type of route other than direct. See the routing hierarchy algorithm described previously to understand how the distributor uses the routing hierarchy and the parent subscribers.

About the Schedule Property Page

The Schedule page (shown in Figure 6.12) enables you to specify how often the distributor software on the server will go to NDS and read the configuration information in its object, the distributions assigned to the distributor, channel information, and subscriber configuration information. The default value is Never, which means that the distributor reads its NDS object only when it first is loaded on the server, or if told to with the console command (refresh), or in ConsoleOne if you right-click the distributor object and choose the Refresh menu option.

Figure 6.12. Schedule property page.

If there is a Tiered Electronic Distribution policy in a Service Location policy package associated with the distributor, the check box for using the policy appears on this page. If there is no policy, the check box is not displayed. When this check box is activated, the schedule described in the policy is used for this distributor. When unchecked, this distributor has its own schedule and the Schedule Type field is available for administration. By default, this check box is checked if you have a TED policy.

This page enables you to select when the configuration should be read and applied: Never, Daily, Monthly, Yearly, Interval, or Time.

After you have selected when you want the configuration applied, you have additional fields to select in the lower portion of the screen. The following sections discuss the various options you have.

Send Distribution Immediately after Building

Selecting this option instructs the TED agent to send the distribution as soon as it is built, regardless of the schedule setting. However, extraction at the subscriber's end is still based on the subscription schedule.

Never

This option loads the distributor with the configuration information only when it is first loaded on the server, after each reboot or restart.

Daily

When you choose to have the configuration applied to the system daily, you also need to select when the changes will be made.

This schedule requires that you select the days when you want the configuration applied. You select the days by clicking the days you want. The selected days appear as depressed buttons.

In addition to the days, you can select the times the configuration is applied. These times—the start and stop times—provide a range of time when the configuration will be applied.

You can have the configuration also reapplied within the time frame every specified hour/minute/second by clicking the Repeat the Action Every field and specifying the time delay.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Monthly

Under the monthly schedule, you can select which day of the month the configuration should be applied, or you can select Last Day of the Month to handle the last day, because all months obviously do not end on the same calendar date.

After you have selected the day, you can also select the time range when the configuration will be reread and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Yearly

You select a yearly schedule if you want to apply the configuration only once a year.

On this screen you must choose the day that you want the configuration to be applied. This is done by selecting the Calendar button to the right of the Date field. This brings up a Monthly dialog box, where you can browse through the calendar to select the date you want. This calendar does not correspond to any particular year and may not take into account leap years in its display because you are choosing a date for each year that will come along in the present and future years.

After you have selected the date, you can also select the time range when the configuration should be read and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Interval

This schedule type enables you to specify how often to repeatedly read and apply the configuration. You can specify the interval with a combination of days, hours, minutes, and seconds. This type waits for the interval to pass first before applying the configuration for the first time and then for each sequence after that.

Time

This enables you to specify a specific calendar date and time when the configuration will be applied. When the current date on the server is beyond the identified date, the configuration will be applied.

Run Immediately

The distributor does not use this schedule type, but it is used by other components. It is described here for the completeness of listing all possible schedulers.

With the Run Immediately schedule type, the schedule causes the activity to occur the first time that the associated object is activated. You may also specify a repeat interval in days, hours, minutes, and seconds. If no repeat interval is specified, the action runs only once until the object is restarted or refreshed.

NDS Rights Property Pages

The NDS Rights property page is made up of three pages. You can get to each of the pages by clicking the small triangle to the right of the page name and then selecting the desired page to be displayed.

These pages enable you to specify the rights that users have to this object in the directory. The following subsections briefly discuss each of these pages. These NDS Rights pages are displayed for every object in the tree.

Trustees of This Object Page

On this page (see Figure 6.13), you can assign objects to have rights as trustees of the distributor object. These trustees have rights to this object or to attributes within this object.

Figure 6.13. Trustees of this Object page.

If the user admin.novell has been added to the trustee list, then this user has some rights to this object. To get into the details of any trustee assignment (in order to modify the assignment), you need to click the Assigned Rights button.

When you click the Assign Rights button, after selecting the user you want to modify you are presented with a dialog box that enables you to select either [All Attribute Rights] (meaning all the attributes of the object) or [Entry Rights] (meaning the object, not implying rights to the attributes).

From within the Assigned Rights dialog box, you may set the rights the user may have on this object. You can set those rights on the object as well as any individual property in the object. The rights that are possible are as follows:

  • Browse. Although not in the list, this right shows up from time to time (especially in the effective rights screens). This represents the capability to view this information through public browse capabilities.

  • Supervisor. This identifies that the trustee has all rights, including delete, for this object or attribute.

  • Compare. This enables the trustee to compare attributes' values.

  • Read. This enables the trustee to read the values of the attribute or attributes in the object.

  • Write. This enables the trustee to modify an attribute's contents.

  • Add Self. This right enables the trustee to add himself or herself as a member of the list of the attribute's objects. For example, if this right were given on an attribute that contained a list of linked objects, the trustee could add himself or herself (a reference to his or her object) into the list.

If you want to add the object as a trustee to an attribute, you need to click the Add Property button to bring up a list of properties or attributes that are available for this object.

From this list, you may select a single attribute. This attribute is then displayed in the Assigned Rights dialog box. From there, you can select the attribute and then set the rights you want the trustee to have for that property. A user does not require object rights to have rights on a single attribute in the object.

Remember that rights flow down in the tree and if you give a user or an object rights at a container level, those rights continue down into that container and any subcontainers until that branch is exhausted or another explicit assignment is given for that user in a subcontainer or on an object. An explicit assignment changes the rights for the user at that point in the tree. Inheritance Rights Filters may also be placed to restrict this flow of rights down into the tree.

Inherited Rights Filters Page

This page (as shown in Figure 6.14) enables you to set the IRF (Inheritance Rights Filter) for this object. This filter restricts the rights of any user that accesses this object, unless that user has an explicit trustee assignment for this object.

Figure 6.14. Inherited Rights Filters page.

You can think of the IRF as a filter that lets only items checked pass through unaltered. Rights that bump up against an IRF filter are blocked and discarded if the item is not checked. For example, if a user who had write privileges inherited at some point above (she was explicitly granted that right at some container at or above the one we're in) were to run into an IRF for an object or attribute that has the write privilege revoked (that is, unchecked), when she got to that object her write privilege would be gone for that object. If the object were a container, she would loose write privileges for all objects in that container or subcontainer.

You can effectively remove supervisor privileges to a portion of the tree by setting an IRF with the supervisor privilege turned off. You must be careful not to ever do this without someone being assigned as the supervisor of that branch of the tree (given an explicit supervisor trustee assignment at the container where the IRF is done) or you will make that part of the tree permanent (that is, you will never be able to delete any objects in that branch of the tree). ConsoleOne helps keep you from performing this action by giving you an Error dialog box that keeps you from putting an IRF on the [Entry Rights] of the object with the supervisor right filtered away without having first given an explicit supervisor assignment on the same container.

Effective Rights Page

The Effective Rights property page (as shown in Figure 6.15) enables you to query the system to discover the rights that selected objects have on the object that you are administering.

Figure 6.15. Effective Rights page.

Within this page you are presented with the distinguished name (DN) of the object whose rights you want to observe. Initially, this is your currently logged in user running ConsoleOne. You can click the Browse button to the right of the Trustee field and browse throughout the tree to select any object.

When the trustee object is selected, you may then move to the Properties table on the lower half of the screen. As you select the property, the Rights box to the right changes its text to reflect the rights that the trustee has on that property. These rights may be via an explicit assignment or through inheritance.

About the Other Property Page

This page may or may not be displayed for you, depending on your rights to the plug-in that now comes with ConsoleOne. This page is particularly powerful and should not be used by those who do not have an intimate knowledge of the schema of the object in question and its relationships with other objects in the directory. The intention of this property page is to give you generic access to properties that you cannot modify or view via the other plugged-in pages. The attributes and their values are displayed in a tree structure, allowing for those attributes that have multiple types (are compound types that consist of, say, an integer and a distinguished name, or postal code that has three separate Address fields).

Every attribute in eDirectory is defined by one of a specified set of syntaxes. These syntaxes identify how the data is stored in eDirectory. For this page, ConsoleOne has developed an editor for each of the different syntaxes that are currently available in eDirectory. When an attribute is displayed on this page, the editor is invoked to display the data and then modify it should the user click a specific attribute.

If the syntax for an attribute were a string or an integer, for example, then an inline editor is launched enabling the administrator to modify the string or the integer value on the screen. More abstract syntaxes, such as octet string, require that an octet editor be launched, giving the administrator access to each of the bytes in the string without interpretation of the data.

The danger with this screen is that some applications require that there be a coordination of attribute values between two attributes within the same object or across multiple objects. Additionally, many applications assume that the data in the attribute is valid because the normal user interface checks for invalid entries and does not allow them to be stored in the attribute. If you should change a data value in the other page, no knowledge of related attributes or objects or valid data values is checked because the generic editors know nothing about the intention of the field. Should you change a value without making all the other appropriate changes or without putting in a valid value, some programs and the system could be affected.

Rights are still in effect in the Other property page, and you are not allowed to change any attribute values that are read-only or that you do not have rights to modify.


Discussing the Parent Subscriber

The TED parent subscriber is first a subscriber, and can receive distributions if they are subscribed to a channel. A parent subscriber has the additional responsibility to take the distribution and pass it along to a set of designated subscribers. In this manner, a parent subscriber acts as a relay transmitter for the distributor and relays the distribution onto other subscribers. Any subscriber can become a parent subscriber without any software change. The subscriber needs to be designated a parent only in either the distributor's routing hierarchy or in a subscriber object.

There is no parent subscriber object that is created in NDS. A subscriber acts as a parent subscriber any time it is identified in either another subscriber object (as that subscriber's parent) or as an entry, with a child subscriber, in the routing hierarchy of any distributor.

A subscriber that receives a route with the distribution that identifies that it should forward the distribution on to other subscribers activates its parent subscriber code and forwards the distribution to all the subscribers in the next level of the route. Identifying a subscriber as a parent only aids the distributor in the construction of the routing for a distribution.

Just like the distributor, a parent subscriber is responsible for sending configuration information to the end-node subscriber. When the distributor sends configuration information to the parent subscriber, it includes all configuration information for any other parent or end-node subscribers to which this parent subscriber is responsible for forwarding distributions. When this parent subscriber has a distribution for a destination subscriber (parent or end node), it bundles the configuration relevant for that destination subscriber and sends it along with the distribution. All configuration information is stored in a configuration file in the TED directory. This file is created or updated when the subscriber process exits.


Discussing the TED Subscriber

The TED subscriber is responsible for receiving and extracting distributions, and validating that they come from an acceptable distributor and that the distribution file is accurate. The subscriber, when the extraction schedule starts, activates TED agents to unpack the distribution and handle the placement of the data in the distribution. If the subscriber should receive, with the distribution, a route that specifies that it send a distribution to other subscribers, the subscriber forwards the distribution to the next level of specified subscribers.

The subscriber system on a server never accesses NDS. The distributor that is sending a distribution to this subscriber is responsible for communicating any information from the subscriber object to the subscriber software. The distributor sends configuration information to the subscriber only if the distributor has a newer revision of the subscriber object or the effective policy. The subscriber stores any changes in a configuration file so that the next time that it is started it loads the configuration information.

All subscribers must have a copy of the digital certificate of the distributor to receive distributions from the distributor. If there is a distribution in the channel that is coming from a distributor for which the subscriber does not hold a copy of the distributor's digital certificate, the subscriber rejects the distribution. You can transmit the digital certificate manually, or ConsoleOne will attempt to contact the subscribers with a UNC path when a distribution is placed in a channel from a new distributor or when a subscriber is added to the channel. Over this connection, the digital certificates of all distributors (that currently have distributions in the channel) are sent and placed on the subscriber's file system. Perform the following steps to secure a copy of the digital certificates of the distributors that may be sent to the subscriber:

  1. Launch ConsoleOne.

  2. Browse to the distributor object of the distributor whose certificate you want to retrieve. Select the distributor object.

  3. Right-click and select Resolve Certificates. You are presented with a dialog box that gives you two radio buttons:

    • Copy certificates to subscribers automatically. This goes to all distributions associated with this distributor and then to all the subscribers that are associated with all the channels in which the distribution is, and also to all subscribers that act as parent subscribers to pass the distributions to the subscribers that are associated with the channels. It attempts to gain access to the subscriber file system with a UNC path and to write the certificate to the sys:\ted2\security directory on the subscriber server.

    • Save certificates to disk. This writes the certificates to the directory specified on the disk.

  4. Choose Save Certificates to Disk and type in the directory name to copy the certificates on your local drive or floppy. Or, click the Browse button to browse to the directory where you want the certificates copied.

  5. Click OK. The certificates are placed in the directory specified.

  6. Take the files written to the directory and copy them to the directory PATH:\ZENWORKS\TED\SECURITY on the subscriber system.

NOTE

You can also use ConsoleOne to automatically resolve certificates for a specific subscriber, rather than a distributor. By right-clicking the subscriber object and choosing the Resolve Certificate option, the subscriber receives all certificates for all distributors that have distributions associated with the channels to which the subscriber is subscribed.

The NDS Rights and Other pages are described in the sections of this chapter that discuss distributors.

About the Settings Property Page

This page is found under the General tab and represents some general configuration settings that are effective for this subscriber. Figure 6.16 displays a capture of this screen.

Figure 6.16. Settings property page of a subscriber object.

On this property page, you can choose the following settings:

  • Input rate. This represents the number of bytes per second that you allow a subscriber to consume for all subscriptions' input, independently. The default is for the subscriber to receive at the maximum rate possible on the server. For example, if you choose to enter 4096, this subscriber does not exceed receiving 4Kbps from any distributor, regardless of the capacity of the subscriber.

  • High Priority. This represents the number of bytes per second that you allow a subscriber to consume for all high-priority subscriptions' output.

  • Medium Priority. This represents the number of bytes per second that you allow a subscriber to consume for all medium-priority subscriptions' output.

  • Low Priority. This represents the number of bytes per second that you allow a subscriber to consume for all low-priority subscriptions' output.

  • Maximum concurrent distributions. Each time that a subscriber is going to relay a distribution (because it is a parent subscriber), it creates a Java thread that handles the sending of the distribution to the child subscriber. This value identifies the maximum number of threads that you will allow the parent subscriber to create to service relaying distributions. The Maximum Number of Concurrent Distributions value is affected by prioritizing because it is subordinate to the priorities set for the distributions. For example, imagine that you have the concurrent distribution number set to 10 and there are 4 high-priority distributions, 5 medium-priority distributions, and 20 low-priority distributions. Initially, the 4 high-priority distributions are sent concurrently; the 5 medium-priority distributions must wait until all 4 high-priority distributions are complete. Then the 5 medium-priority distributions are sent concurrently and only after they are complete are 10 of the 20 low-priority distributions sent.

    NOTE

    The subscriber always creates all the concurrent receiver threads that it needs regardless of this maximum value. There is currently no method to manage the total number of receiver threads.

  • Connection timeout. The default for this is 300 seconds. You can also enter a timeout value that, when exceeded, causes the parent subscriber to fail the distribution and retry the distribution every two minutes for the next thirty minutes (as long as it is still in its scheduled window). If after the retries the distribution still cannot succeed, the parent subscriber fails the distribution and the next time it tries is when the distributor reattempts the distribution. This value is also used for the maximum amount of time a subscriber waits between packets while receiving a distribution from a distributor or parent subscriber.

  • Working directory. This identifies the directory where the subscriber stores the distribution files it receives. The agents, when they are called to extract the files, go to this directory to find the distribution files. It is not recommended to use the SYS volume because of the potential system problems should that volume become full.

  • Parent subscriber. This enables you to specify a parent subscriber from which this subscriber should receive all distributions (as opposed to getting them directly from the distributor). This can be overridden on a per-distributor basis by including the subscriber in the routing hierarchy on each distributor (see the TED Systems section for more information).

  • Disk space to be left free. Specifies amount of disk space that you want to remain in addition to the size of any distribution that is to be received. This enables you to enter a value large enough to also allow room for the distribution to be extracted and installed. The subscriber server receives the distribution only if amount of free disk space on the subscriber server is equal to or greater than the sum of the compressed distribution and the value you entered here.

Focusing on the Messaging Property Page

The Messaging property page is under the General tab and can be configured by clicking the active tab and selecting the messaging value under the drop-down on the tab (which you find by pressing the small triangle in the tab). Figure 6.17 provides a sample Messaging page.

Figure 6.17. Messaging property page of a subscriber object.

For each of the appropriate fields, you may enter one of the message levels described in the section on distributors.

You can administer the following configuration parameters on the Message property page:

  • Server Console. This item identifies the level of messages that are displayed on the subscriber server console (not the main server console).

  • SNMP Trap. This identifies the level of messages that are sent as an SNMP trap being sent to the SNMP trap target. The SNMP Trap Targets policy must be set in the Service Location Policy Package to be effective for the subscriber object. This information is included in the configuration information sent to the subscriber from the distributor.

  • Log file. This identifies the level of message that should be stored in the log file. Additionally, you can configure the following about the log file:

    • Filename. This is the log file's filename. The default location is PATH:\ZENWORKS\TED\DIST\TED.LOG. You should change the log file's location because it can grow, as well, and may adversely affect the system if it is located on the SYS volume.

    • Delete log entries older than X days. In this parameter, you identify the number of days (x) worth of log entries that should remain in the log file. The default is six days. Therefore, any log entries that are older than six days will be cleared from the log file. The process of scanning the log for and removing old log entries happens once every 24 hours and is not configurable.

  • Email. With this option you can specify the level of messages that will be sent as email to the identified users. The SMTP Host policy in the ZENworks for Servers 3 Service Location policy package must be effective for the subscriber object to enable it to discover the address for the SMTP host to send the email. If this is not specified, the email is not sent.

    In addition to identifying the level of messages, you must also specify who should receive these messages. To add users to the list and for them to be sent the message, you must select User, Group, or E-mail from the dropdown list and then click the Add button and specify the NDS User or Group, or an email address. When you select a user, you are asked to browse to the user in the directory, and the system takes the email address attribute from the user and uses that as the address for the user. Should you choose a group, all the users in the group are sent the email message and the email attribute is used for each of those users. Should you not want to use the email address attribute in the user object, you may select the down arrow in the Address Attribute field and select which of the NDS user attributes you want to identify as containing the email address. Many administrators store user email addresses in the Internet E-mail Address attribute instead of the E-mail Address attribute. It is expected that the attribute you identify contain a valid email address.

    If you choose to enter an explicit email address, rather than selecting a user or a group, you may choose E-mail from the dropdown list and click the Add button. You are prompted to enter a valid email address. The entered email address is assumed to be valid and is shown as the Username field in the table with an N/A in the Address Attribute field.

Thinking About the Channels Property Page

This page of the subscriber object identifies the channels that this subscriber is going to receive distributions from. A subscriber may subscribe to many channels. To add a channel to the list, click the Add button and browse in NDS to the channel. Once this channel is added, it appears on the list.

To delete a channel from the list, you must first select the channel and then click the Delete button. The subscriber will no longer accept distributions from this channel.

You can view/edit the property pages of the channel by selecting the channel and clicking the Details button.

The same distribution may be placed in more than one channel. It is possible that the same subscriber may be subscribed to multiple channels, and that more than one channel may want to distribute the same distribution. The distributor and subscriber keep a version number on each distribution and do not send the same distribution more than once to the same subscriber, no matter in how many channels the distribution is.

About the Extract Schedule Property Page

The Schedule property page enables you to specify when and how often the extraction agents are called to dissect the distribution file and extract the files within, placing them in the file system of the server as specified in the distribution. Figure 6.18 shows a sample of this page.

Figure 6.18. Extract Schedule property page of a subscriber object.

If there is a Tiered Electronic Distribution policy in a Service Location policy package effective for the subscriber object, the check box for using the policy appears on this page. If there is no effective policy, the check box is not displayed. When this check box is activated, the schedule described in the policy is used for this subscriber. When unchecked, this subscriber has its own schedule and the Schedule Type field is available for administration. The check box is checked by default if there is an effective TED policy.

This page enables you to select when the extraction agents should do their work on the subscriber server: Never, Daily, Monthly, Yearly, Interval, Time, or Run Immediately.

After you have selected when you want the configuration applied, you have additional fields to select in the lower portion of the screen. The following sections discuss the various options you have.

NOTE

The default is Never. Therefore, the subscriber never extracts the files until you change the schedule. Remember, the configuration of the subscriber does not change until the next distribution, when the distributor sends the new configuration.

Never

This option loads the distributor with the configuration information only when it is first loaded on the server, after each reboot or restart.

Daily

When you choose to have the configuration applied to the system daily, you have the additional need to select when the changes will be made.

This schedule requires that you select the days when you want the configuration applied. You select the days by clicking the days you want. The selected days appear as depressed buttons.

In addition to the days, you can select the times the configuration is applied. These times—the start and stop times—provide a range of time when the configuration will be applied.

You can have the configuration also reapplied within the time frame every specified hour/minute/second by clicking the Repeat the Action Every field and specifying the time delay.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Monthly

Under the monthly schedule, you can select which day of the month the configuration should be applied or you can select Last Day of the Month to handle the last day, because all months obviously do not end on the same calendar date.

After you have selected the day, you can also select the time range when the configuration will be reread and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Yearly

You select a yearly schedule if you want to apply the configuration only once a year.

On this screen, you must choose the day that you want the configuration to be applied. This is done by selecting the Calendar button to the right of the Date field. This brings up a Monthly dialog box, where you can browse through the calendar to select the date you want. This calendar does not correspond to any particular year and may not take into account leap years in its display because you are choosing a date for each year that will come along in the present and future years.

After you have selected the date, you can also select the time range when the configuration should be read and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Interval

This schedule type enables you to specify how often to repeatedly read and apply the configuration. You can specify the interval with a combination of days, hours, minutes, and seconds. This type waits for the interval to pass first before applying the configuration for the first time and then for each sequence after that.

Time

This allows you to specify a specific calendar date and time when the configuration will be applied. When the current date on the server is beyond the identified date, the configuration will be applied.

Run Immediately

The distributor does not use this scheduled type, but it is used by other components. It is described here for completeness in describing all the possible schedulers.

With the Run Immediately schedule type, the schedule causes the activity to occur the first time that the associated object is activated. You may also specify a repeat interval in days, hours, minutes, and seconds. If no repeat interval is specified, the action runs only once, until the object is restarted or refreshed.

Variables Property Pages

Variables enable you to substitute a variable name in the distribution with the value specified in the subscriber. When you create a distribution, you may use variables in the volumes and directory names, for example. When the distribution is sent to the subscriber and the extraction agent is called, the agent replaces these variables with their defined value in the subscriber object. If no value is given, the variable name (including the %—percent sign) is used for that value.

If a Tiered Electronic Distribution policy in a Service Location Policy package is in effect for the subscriber, the check box for using the policy appears on this page. If there is no policy, the check box is not displayed. When this check box is activated, the variables described in the policy are used for this subscriber, in addition to the variables that you define in the subscriber. When unchecked, this subscriber has its own independent variables. If there is a duplicate, the subscriber's definition is used. This enables you to override a specific variable from the policy, while still accepting the other variables from the policy.

Unlike ZENworks for Servers policies and software distribution packages, the TED software performs only basic substitution of variable to value and does not enable you to reference an NDS object or its attribute. This eliminates the requirement that the subscriber have access to NDS and all the objects in the tree. This would be especially difficult if the subscriber were an external subscriber—not even in the same tree as the distributor!

For example, if you create a distribution and specify %DEST_VOLUME% as the volume name, when the subscriber extracts the files, the agent substitutes the variable DEST_VOLUME defined in this property page with the value. If DEST_VOLUE is not defined, then a directory called %DEST_VOLUME% is created in the SYS volume.

Remember to be consistent in your conventions and your variable names. You should probably come up with a set of common variables that you define with each subscriber that you set up. Then when you create a distribution, you can use these variables in defining the directories where the distribution will be placed. Remember, the subscribers that receive the distribution are based purely on who subscribes to the channels where you place the distribution. If you are not consistent in your variable names across all subscribers, you may inadvertently send a distribution to a subscriber that does not have the variable defined; this results in the distribution being extracted in a place you do not expect (probably on the SYS volume). Some variables that you should consider defining in each of your subscribers include the following:

  • DEST_VOLUME. Define this variable as the volume that receives the distribution after it is extracted.

  • DEST_APPVOL. Define this to be the volume where your applications are stored.

  • DEST_APPDIR. Define this to be the directory under the application volume where you place your applications.


External Subscriber

An external subscriber is a TED subscriber that resides on a server not located in the tree of the distributor. The controlling subscriber object of an external subscriber is located in the external tree. The distributor's tree does contain an external subscriber object, which identifies the IP address of the remote subscriber.

An external subscriber object is basically just a pointer to the subscriber service running on a server that has its subscriber object in a different tree. Each subscriber should have exactly one subscriber object, but each may also have many external subscriber objects that point to. For example, if there were a subscriber object in the FORD tree, it would receive its configuration information from a distributor in the FORD tree. There could be an external subscriber object in each of the GM, NISSAN, and BMW trees, but distributors in those trees would send only distribution files, not configuration information, to the subscriber.

The following is a list of important things to note about an external subscriber:

  • A server can be associated with both a subscriber object in one tree and an external subscriber object in another tree.

  • An external subscriber is a server running the subscriber software, but that does not have a subscriber object in the same eDirectory tree as the distributor from which it will receive a distribution.

  • A server that is identified in the external subscriber object's properties in Tree A must be a subscriber in Tree B so that it can receive and extract a distribution.

  • An external subscriber must have a parent subscriber in the tree where its external subscriber object resides. In other words, an external subscriber in Tree B cannot receive distributions directly from a distributor in Tree A.

  • An external subscriber cannot be used as a parent subscriber in the tree where its external subscriber object exists. However, it can be a parent subscriber in its own tree where its subscriber object exists.

  • A subscriber receives its configuration information from a distributor in its own tree because the subscriber's information is stored in its eDirectory object, which is not accessible to TED agents in another tree. Therefore, a subscriber must have received a distribution from a distributor in its own tree before it can receive a distribution from another tree.

  • Variables you may be using in the definition of your distributions must be defined in the actual subscriber object, because anything defined in the tree where the external subscriber object exists is not passed on as part of distributions sent from distributors in that tree.

About the General Property Page

On this page you may identify a parent subscriber for this subscriber. The parent subscriber would be a subscriber object in this tree. You need to click the Browse button to the side of the field and browse NDS to select the subscriber that is to be identified as the parent subscriber.

Discussing the Channels Property Page

On this property page you identify the channels from which this external subscriber will receive distributions. As you recall, any distribution that is placed in a channel subscribed to by this external subscriber will be sent.

Looking at the Network Address Property Page

On this property page, represented in Figure 6.19, you specify the IP address or DNS name of the server that is running the external subscriber.

Figure 6.19. Network Address property page of an external subscriber object.

To administer the address, simply place the cursor in the IP Address or DNS name field and enter the IP address or the server's DNS.


About TED Distribution

The TED distribution object represents the collection of files that are compiled into a distribution file and then sent to the subscriber. After the subscriber receives it, the distribution is extracted from the distribution file and placed in the locations specified in this distribution (with appropriate variable substitution).

All the files that are specified in a TED distribution must reside on the distributor's file system, or the server must have access to HTTP and FTP capabilities to retrieve the files for those agents. After the distribution is defined, it must be placed into a channel or a set of channels to get the distribution transmitted to a subscriber. The files that are specified in the distribution object are collected by the agents on the distributor system and placed into a single distribution file. This file is then transmitted to all the subscribers that are subscribed to the channels where the distribution object is placed.

The distribution is a live object. The distribution objects are sent each time the channel schedule is activated. When the gatherer schedule activates this distribution, the agent is called to collect the files specified and compare them to the previous distribution. If differences have appeared in the files, a new delta package, or an entire distribution, of the distribution is generated and the new revision is sent to the subscribers of the designated channels. This happens each time the gatherer and send schedule activate the distribution. Unless a distribution is expressly identified as a one-time only distribution, it does not become inactive after it has been sent. The distribution continues to be reevaluated, recollected, and redistributed each time the schedule is activated.

NOTE

The distribution does not rebuild based on any file system event, such as an update to a file. The distribution rebuilds strictly based on the gatherer schedule in the distribution, whether the files have changed or not.

If there is no subscriber to receive a distribution (that is, no subscribers in the channel) or the distribution is inactive, or is not associated with any channel, the distribution is never gathered and built, even if the gathering is scheduled.

The NDS Object and Other property pages are described in the distributor section of this chapter.

Looking at the General Property Page

The settings panel of the General property page enables you to specify some settings that are used in the deployment of the distribution. Figure 6.20 displays a typical snapshot of this page.

Figure 6.20. General property page of a TED distribution object.

You can specify the following settings on this General property page:

  • Active. The check box activates or deactivates the distribution. If a distribution is inactive, the distribution is not sent to subscribers even if it is in a channel.

  • Use Digest. This check box activates the TED system to use a digest on the distribution file. The digest is used to verify that the contents of the distribution file have not changed from the distributor to the subscriber (during transmission). When the subscriber receives the distribution, it verifies the digest it calculates with the digest that the distributor computes and places it in a header. If the digests match, the file is unchanged and the subscriber accepts the distribution.

    NOTE

    The generation of the message digest may take significant time, particularly with large distribution files. Be aware that this increases the time it takes to gather and create the distribution file.

  • Encrypt. This check box activates distribution encryption, providing security for the distribution during transit between the distributor and subscriber. Typically, you would only encrypt a distribution that is sent through a firewall. If you enable encryption, you have the option to select either Strong or Weak encryption.

  • Maximum revisions. This value enables you to specify the number of revisions of the distribution that you will keep. Each time that a distribution is collected and a distribution file is created, this constitutes a revision. When the maximum number of revisions has been created, the oldest revision is discarded from disk (unless it is currently being sent to a subscriber, in which case it is discarded on the next distribution cycle). Each subscriber that receives this distribution will keep this number of revisions. This includes subscribers that act as parent subscribers but do not actually subscribe to the channel. You also have the option of choosing to delete previous revisions prior to accepting the next. This is extremely useful in the case of large distributions because the subscriber frees up space for the new version before receiving it.

    NOTE

    When the maximum number of revisions is achieved, the file agent deletes all revisions and creates a new distribution baseline.

  • Priority. Specifies the priority for this distribution, which determines how it will be sent in relation to other distributions. A high priority means it will be sent before all medium- and low-priority distributions.

  • Distributor. This is a display-only field that identifies the distributor that performs the collection and transmission of this distribution. This distributor is specified when the distribution object is created. This distributor is the owner of this distribution. The owner of a distribution cannot be changed.

  • Description. This enables you to have a free-flowing text description of the distribution. This can be used to help in understanding the files and the purpose for the distribution package.

The restrictions panel of the General properties page enables you to specify whether platform restrictions should be specified for the distribution. If there are no restrictions, the distribution is accepted by any subscriber and then extracted on that subscriber. If there are restrictions, uncheck the No Restrictions check box and check the check boxes that correspond to the platforms that accept this distribution. The distribution extracts only on the platforms with a checked check box. ZENworks for Servers 3 enables you to specify the following platforms: NetWare All, NetWare 4.x, NetWare 5.0, NetWare 5.1, NetWare 5.x, NetWare 6.x, Windows Server, Solaris, and Linux.

About the Channels Property Page

In the Channels property page the administrator can select the channels that contain this distribution. This distribution can be placed in any number of channels. All the subscribers associated with each channel are sent this distribution by the distributor associated with this distribution object. Figure 6.21 shows this page.

Figure 6.21. Channels property page of a TED distribution object.

To add this distribution to a channel, click the Add button. You are next presented with a dialog box to browse through NDS to select the channel. After you have selected the channel, it is placed in the list displayed in the Channels box. To delete the channel from the list (removing the distribution from being distributed), select the channel and click the Delete button. To go to the property pages of the channel object, select the object and click the Details button.

Any distributions that are associated with channels also appear in the channel object under the Distributions property page.

Looking at the Agent Property Page

In the Agent property page you specify the agent and the files that will be sent as part of this distribution. The agent determines the type of distribution (for example, local files from the file agent, remote files from the HTTP or FTP agent, software installations from the server software packages agent, and so forth). Figure 6.22 shows this page. After you select the agent that this distribution will use (you can select only a single agent per distribution), the screen updates and you need to give files specification details.

Figure 6.22. Agent property page of a TED distribution object.

NOTE

See the section in this chapter on TED agents for more details about each agent.

Looking at the Schedule

This property page enables you to specify how often and when this distribution should be gathered. Each time the server clock hits the specified scheduled time, the agents are activated and the distribution gathered and compared with the previous version to determine whether any changes have been made. If there have been changes, a new version of the distribution file is created. The actual distribution of the file occurs based on schedules of the channels. Figure 6.23 displays the TED distribution Schedule page.

Figure 6.23. Schedule property page of a TED distribution object.

The following choices are available to you for the scheduling of the distribution: Never, Daily, Monthly, Yearly, Interval, Time, or Run Immediately.

Never

This option loads the distributor with the configuration information only when it is first loaded on the server, after each reboot or restart.

Daily

When you choose to have the configuration applied to the system daily, you have the additional need to select when the changes will be made.

This schedule requires that you select the days when you want the configuration applied. You select the days by clicking the days you want. The selected days appear as depressed buttons.

In addition to the days, you can select the times the configuration is applied. These times—the start and stop times—provide a range of time where the configuration will be applied.

You can have the configuration also reapplied within the time frame every specified hour/minute/second by clicking the Repeat the Action Every field and specifying the time delay.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Monthly

Under the monthly schedule you can select which day of the month the configuration should be applied or you can select Last Day of the Month to handle the last day, because all months obviously do not end on the same calendar date.

After you have selected the day, you can also select the time range when the configuration will be reread and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Yearly

You select a yearly schedule if you want to apply the configuration only once a year.

On this screen you must choose the day that you want the configuration to be applied. This is done by selecting the Calendar button to the right of the Date field. This brings up a Monthly dialog box, where you can browse through the calendar to select the date you want. This calendar does not correspond to any particular year and may not take into account leap years in its display because you are choosing a date for each year that will come along in the present and future years.

After you have selected the date, you can also select the time range when the configuration should be read and applied.

To keep all the distributors from simultaneously accessing NDS, you can select the Randomly Dispatch Policy During Time Period option. This causes each server to choose a random time within the time period when it will retrieve and apply the configuration.

Interval

This schedule type enables you to specify how often to repeatedly read and apply the configuration. You can specify the interval with a combination of days, hours, minutes, and seconds. This type waits for the interval to pass first before applying the configuration for the first time and then for each sequence after that.

Time

This enables you to specify a specific calendar date and time when the configuration will be applied. When the current date on the server is beyond the identified date, the configuration will be applied.

Run Immediately

The distributor does not use this scheduled type, but it is used by other components. It is described here for completeness in covering all of the possible schedulers.

With the Run Immediately schedule type, the schedule causes the activity to occur the first time that the associated object is activated. You may also specify a repeat interval in days, hours, minutes, and seconds. If no repeat interval is specified, the action runs only once, until the object is restarted or refreshed.

About Manual Distribution

TED provides a mechanism for you to send your distributions manually, avoiding the need to contact any subscribers over the wire. You may use this to place a distribution across a WAN link that may not be reliable or where you are going to that location and want to bring the distribution with you. You must first run a wizard to create the distribution file and then rerun the wizard at the destination to bring the distribution into the remote system.

Creating a Manual Distribution

The manual distribution is created through a wizard. Perform the following steps to create the distribution that can be placed on portable media and then manually transported to the destination systems:

  1. Launch ConsoleOne and create a normal distribution and place it into a channel.

  2. Ensure that the distributor has gathered the distribution and the distribution file has been created.

    NOTE

    The easiest way to know whether a distribution has been created is to go to the distributor's working directory and see whether a subdirectory has been created with the name of the distribution. Inside this directory are subdirectories; each named with a time stamp. For example, 'SYS:\TED2\DIST\051400502\'. Each of these directories contains the files that are used in the distribution. The actual distribution file is called distribution.ted.

  3. Launch ConsoleOne and choose TED Manual Distribution under the Tools Menu. This launches the wizard to create the manual distribution media.

  4. Follow the steps of the wizard:

    1. Choose Export a Distribution from TED and Copy to Disk on the first page. Click Next.

    2. Use the Browse button to select the channel that contains the distribution you want to manually create. After you have selected the channel, the wizard displays the list of distributions. Select the desired distribution. Click Next.

    3. Enter the desired name of the distribution file, including the path. The file should have a TED extension. You may also click the Browse button to select a file that already exists on the disk. Click Next.

    4. A summary screen is displayed. Click Finish. At this time, the wizard creates the distribution file in the directory and with the name specified.

  5. Take the file you have created and transport it to the destination location. Perform an import distribution to bring the distribution into the destination subscriber or parent subscriber.
Importing the Distribution

After you have created the distribution and carried it to the destination site (a remote subscriber or parent subscriber), you need to run the wizard again to bring the distribution into the system. Perform the following steps to import the distribution into the remote system:

  1. Make sure the distribution file created with the Export Wizard is accessible to the system. Also, make sure that you have access (through UNC paths) to the destination subscriber or parent subscriber that is to receive the distribution.

  2. Launch ConsoleOne and choose TED Manual Distribution under the Tools menu. This launches the wizard to import the manual distribution media.

  3. Follow the steps of the wizard:

    1. Choose Import a Distribution from Disk to TED on the first page. Click Next.

    2. Use the Browse button to browse to and select the distribution file you have brought to this site. Click Next.

    3. This page of the wizard displays all the known subscribers and parent subscribers that have subscribed to the channel that you selected when you created the manual distribution file. Select the subscribers or parent subscribers that you want to receive this distribution. If you select a parent subscriber, it automatically sends the distribution to all its destination subscribers. Click Next.

    4. A summary screen is displayed. Click Finish. At this time, the wizard copies the distribution file to the subscriber's working directory through UNC paths.

  4. The distribution is not automatically extracted on the subscriber. It is extracted only by one of the following methods:

    1. The channel schedule fires to send the distribution and the distribution is administered to have a Run Immediate schedule. The distributor connects with the subscriber and sees that the latest version of the distribution is already on the subscriber, so it does not resend the distribution. If it is a Run Immediate selection, the subscriber next extracts the distribution. This is possible only when the distributor can communicate with the subscriber over the wire.

    2. The extraction schedule on the subscriber fires, which causes the subscriber to unpack all distributions that have not been done, including the one you just imported.

    3. Manually go to the subscriber console (or through Remote Web Console) and enter the command to request that the distribution be extracted (for example, extract –x tree,DN). If the name of your distribution has a space, you need to put quotes around the entire parameter after the –x—for example, extract –x "simple_tree,my distribution.ted.novell".


About TED Agents

TED agents are Java modules that are activated by either a distributor or a subscriber to either pack up or unpack distribution files. Currently, the following agents are available in ZENworks for Servers 3: the Desktop Application Agent, the HTTP Agent, the FTP Agent, the Software Package Agent, the Policy Package Agent, the RPM Agent, and the File Agent. The following sections discuss the agents and what they do for TED.

NOTE

After you have created a distribution and the agent has performed its gathering process, and then you change the agent used for the distribution (that is, you readminister the distribution object and change to a different agent type), unpredictable behavior may occur. This can impact the effect of versioning, which can lead to failures. You should, when changing to a different agent, go to the distributor's working directory and locate the subdirectory titled the same as the distribution, and then remove all time stamp subdirectories under this distribution directory. This causes the agent to perform a clean build of the distribution, ensuring that the distribution is complete and accurate for the new agent.

About the Desktop Application Agent

The ZENworks for Servers 3 Desktop Application agent enables you to distribute ZENworks for Desktops application objects through the TED channel. This is extremely useful because this effectively enables you to distribute desktop applications throughout your entire network, across tree boundaries, from a single source location.

NOTE

You must install ZENworks for Desktops application management and have at least one application object. The source files for the application object must reside on the distributor's local file system. The subscriber must have Novell's eDirectory installed on it to extract the application object and apply it. ZENworks for Servers 3 cannot extract a desktop application distribution, but they can route it to a NetWare or Windows server that can.

Use the Desktop Application Wizard to create a Desktop Application distribution. The wizard is started when you select Desktop Application from the Distribution Type drop-down list. The wizard first asks you to specify an application object that you want to distribute and then it asks you to set properties that determine how it is delivered.

After you have set up the application object through the wizard, the ZENworks for Servers distributor reads the object's properties in eDirectory and determines the location of the source files. Next it determines the associations with other application objects, application folder objects, chained applications, and containers. It packages the associations data into an XML file and packages it with the application object's source files, including the source files of any associated application objects, into a CPK file to be distributed though the TED channel.

When the package is distributed through the ZENworks for Servers channel, subscriber servers extracts the package, including the source files and XML data, and replicates the application object in their tree locations. The subscriber could be in a different location of the same tree or in an entirely different tree.

The following is a list of the properties that you need to define in the wizard to distribution Desktop Applications through TED:

  • Application Object. You must first specify a valid ZENworks for Desktops application object. After you have created the object, all associated objects are shown on the Type panel of the distribution object.

  • Maintain Source Tree Structure. Selecting this option duplicates the source tree's directory structure at the destination's location, which is the target subscribers' working context. This tree structure is then used to create the ZENworks for Desktops application objects. You must enable this option if you want to use chained applications.

  • Source Root Context. This field specifies a container object to be used as the root container for the ZENworks for Desktops application objects. The distributor records only directory data from that container and its subordinate containers; therefore, when the subscriber extracts the package it applies the application object to its working directory as if the container had actually been the root. You can select application objects from this root container and its subordinate containers.

  • Maintain Associations. Selecting this option maintains the group and container associations of the application object in its source tree by replicating the associated groups or containers at the target location if they do not exist. User and workstation associations in the source location are not replicated.

  • Load Balancing and Fault Tolerance. This setting enables you to specify whether to use automated load balancing, fault tolerance, or neither. If you select Load Balance, ZENworks automatically spreads the Desktop Application distributions of the servers being used. Fault tolerance is effectively automatically accomplished through load balancing because multiple servers are involved. If you specify Fault Tolerance, ZENworks allows a server currently being used for Desktop Application distributions to assume the distribution role of another server that has gone down, however. If you select None, then you can manually configure each application object for load balancing or fault tolerance.

NOTE

After you set the distribution type to Desktop Application, you cannot change it to another type.

WARNING

Do not edit Desktop Application distribution objects manually from the ConsoleOne main window. Always go through the wizards to make changes to these objects. The wizards make all changes necessary for the application distributions to work properly. Manually creating the application distributions can result in applications that are not properly added to the ZENworks distribution channel.

The HTTP Agent

The HTTP agent connects to the specified target and attempts to retrieve the specified file via the HTTP protocol. The construction of the destination path is the same as described in the file agent section. The only difference is when an Add File button is pressed, you are prompted for the URL that references the file that the agent should retrieve. Multiple different URLs can be added to the list. The HTTP agent cannot authenticate to the HTTP server. Also, it cannot get files over a secure (SSL) connection.

The FTP Agent

The FTP agent connects to an FTP server, transfers the specified files from that server into the distributor, and then collects these files into a single distribution file to be sent and extracted in the subscriber.

When you begin defining the files for the FTP agent, you must first specify a New FTP Source by pressing this button (see Figure 6.24). This prompts you for a server name, the login, and the password for this server to retrieve FTP files. Then, you continue to add destination folders as described in the section on file agents. When you attempt to add a file, ConsoleOne immediately attempts to connect to the FTP server and enables you to browse the FTP server, selecting the files that you want to gather at the designated time.

Figure 6.24. FTP Agent property page.

By default, the FTP agent retrieves the files in ASCII mode. If you want to retrieve the files in binary mode, which is required when transferring any file that contains nontext characters, you need to select the Binary Transfer check box. You can specify binary mode only for the entire distribution, so if you need to get some binary files and some text files, you may need to use separate distributions. Using binary mode to transfer text files may corrupt the files if transferring from a Unix FTP server, so be sure to use ASCII mode when getting text files from UNIX servers.

The Server Software Package Agent

This agent is responsible for distributing Server Software packages, which are specific to ZENworks for Servers 3 policy management. In Figure 6.25, which shows the distribution object, you can identify the set of Server Software packages that you want included in the distribution. To construct a Server Software package, refer to the details described in Chapter 7, "Understanding and Creating Server Software Packages."

Figure 6.25. Server Software Package agent, distribution agent of a distribution object.

NOTE

A subscriber that is receiving a distribution that is a server software package must have the ZENworks for Servers 3 Policy and Package agent installed and running (ZFS.NCF). This agent assists in the extraction and installation of these packages.

To add software packages to the distribution, click the Add button and browse to select the .cpk file. After several packages are selected, you can specify the order in which the software packages are to be applied to the subscriber server. You can specify the order by selecting the package and clicking the Up or Down button. To remove packages, select the package and click the Delete button.

Discussing the Policy Package Agent

ZENworks for Servers 3 adds a new distribution type, Policy Package, which enables you to specify policy packages to be distributed directly to the individual servers where the policies will be enforced. Previously in ZfS 2, you associated a Policy Package object with eDirectory Server objects and/or Container objects so that the policy could be effective for the servers.

The policy package agent enables you to specify which servers are to have a given policy enforced by simply creating a distribution for that policy and distributing it to the selected servers. After a target server has extracted the distribution, the policies contained in the distribution are enforced on that server according to the subscriber's distribution schedule.

To create a policy package distribution, simply select Policy Package from the list of distribution types and then click the Add button to navigate through the NDS tree and select policy packages that you want enforced on the subscriber servers in the distribution channel.

Discussing the RPM Agent

Another new distribution type that has been added to ZENworks for Servers 3 is the RPM type. The RPM agent enables you use TED to distribute packages to a Unix platform. This allows any Red Hat Package Manager (RPM) packages you have created to be added to a distribution channel and distributed to your Linux or Solaris servers. Although RPM is not native to all Linux implementations, it is the most commonly used package manager for enterprise environments.

To create an RPM distribution for your RPM package, select RPM from the list of distribution types to bring up the RMP Agent panel. From this screen click the Add from Distributor button to add a RPM package that is located on the distributor's file system, or you can click the Add from FTP Site button to log in to an FTP server and select an RPM package that is located on it.

Discussing the File Agent

This agent enables you to select any file on the distributor file system and place it in a defined directory on the subscriber system. The directories that are specified do not have to exist on the target server; they will be created at extraction time. Figure 6.26 shows a distribution that uses the File agent.

Figure 6.26. File agent, distribution agent of a distribution object.

You begin identifying the target set of files to include in the distribution by clicking the New Target button. This creates a root node displayed on the left panel. Traditionally, this represents the destination volume for the files. ConsoleOne initially places the string %DEST_VOLUME% in this field. You can change the string by selecting the text and clicking the left mouse button. The field clears and you can enter any text string you want, including hard-coded volume names (on the target subscribers) or variable names (don't forget the surrounding percent signs).

You then construct a tree of the file system as you would like it created on the target subscriber. You can add subdirectories by highlighting a directory in the tree and clicking the Add Folder button. You can then highlight the folder name and click the left mouse button to edit the name of the folder (initially it is set as the string "New Folder").

When you want to send a file to the destination subscriber, you first highlight the folder that is the file's parent on the destination subscriber and click the Add File button. This brings up a Browser dialog box, enabling you to browse through the file system of the distributor to the volume you desire and then down into the volume file system. Continue browsing until you find the file you want. Select the file by double-clicking the filename, or by selecting the file and clicking the OK button on the dialog box. The full pathname of the file (as found on the distributor) is displayed as the name of the file in the tree. The actual name of the file when it is transmitted and extracted from the distribution is the file's base name (the filename without any directories), and the file is located under the directories and subdirectories that you have specified in the tree design in the left panel.

Continue to follow the preceding steps until you have all the desired files selected and placed in the desired locations on the target subscriber. Should you need to delete a file or directory, simply select the item and click the Delete button. The file and/or the directory and all subdirectories are removed from the tree display and are not included in the distribution.

The following configuration flags can be placed on the distribution and apply only when the extraction process is occurring on the subscriber:

  • Synchronize Directories. This flag forces the distribution to synchronize the directories specified in the file agent. If this option is set then only the files that are specified in the agent are allowed to exist in the directories specified. This is extremely useful if you need to replicate exact directory structures throughout your network.

  • Verify Distributions. This flag enables the distributor to force the subscriber to extract the current version of the distribution, even if it has already been extracted. This enables the subscriber to refresh the files that were contained in the current version, eliminating any changes that may have occurred since the original distribution occurred.

  • Maintain Trustees. This flag instructs the subscriber to maintain file ownership and trustee data in the files.

  • Retry X times. This flag instructs the agent to attempt to write the file the specified number of times. If the write fails—because the file is open, for example—the agent repeats the attempts the specified number of times before failing.

  • Kill conn on open files. This flag enables the process to drop the connections to the subscriber server for the connection that has the file open, preventing the agent from writing the file. This terminates the session for the user that is currently using the file and he will have to log in to the server again.

  • Fail on Error. This terminates the extraction should a failure occur in writing the files.

    NOTE

    The system does not roll back any files that have been installed at the point of failure.

  • Continue on Error. This causes the agent to skip the file, logging the error if specified, and continue to extract the other files in the distribution.

These options are for the entire distribution and are not specified on a per-file basis.

NOTE

ZENworks for Servers 3 creates the directory structure first and applies the attributes to the directories before copying files. Therefore, if you flag a directory that is to be distributed with the read-only flag, the distribution fails because it cannot copy files to a read-only directory.

The File Agent does not create a new distribution file in its entirety. If there is a previous distribution available, the agent performs a "file-wise" delta where only changed files are included in the new distribution. When the number of revisions reaches the administered maximum number of revisions, the agent removes all previously created versions and creates a completely new "baseline" of the distribution, which consists of all the files specified in the distribution. This is important because each subscriber must extract the various revisions of the distribution in order. If a new subscriber is brought online after the distributor has created eight revisions of a file agent distribution, it needs to send all eight revisions to the subscriber to bring it up to the latest revision. The good thing about this process is that the delta revisions are usually much smaller than the entire (baseline) distribution files. Other agents do not behave this way. The other agents either send the entire distribution file each time, or send a "bit-wise" patch file. With these patching agents, the patch is calculated for and applied directly to the previous revision of the distribution to create a new complete revision of the distribution. When a new subscriber is brought online after the distributor has created eight revisions of a patching distribution, it needs to send only one patch file to the subscriber, which will essentially be the entire distribution.


About the TED Channel

The TED channel basically identifies the group of subscribers that should receive the distributions in the channel. Multiple distributions from multiple distributors can be in the channel. Figure 6.27 displays this object.

Figure 6.27. Channel object.

Discussing the Settings Property Page

On the Settings property page you can specify a description of the channel. This hopefully gives an indication of the type of distributions that are placed in the channel and the type of subscribers. For example, a channel for Engineering Applications would give a good signal that the distributions are applications that are used by engineers in the organization.

You can also activate or deactivate a channel. If a channel is active, the distributions are sent per the channel schedule.

Looking at the Distributions Property Page

This page enables you to specify the distributions that should be included in the channel. From this page, you can add distributions by clicking the Add button and browsing NDS to select the distribution objects. You can also look at the details or remove distributions from the channel in this property page. This can also be done in the distribution objects. If the distribution is associated with the channel in the distribution object, the distribution automatically appears in this list as well.

About the Subscribers Property Page

This page enables you to specify the subscribers that should be included in the channel. From this page, you can add subscribers by clicking the Add button and browsing NDS to select the subscriber or external subscriber objects. You can also look at the details or remove subscribers from the channel in this property page. This can also be done in the subscriber object. If the subscriber is associated with the channel in the subscriber object, the subscriber automatically appears in this list as well.

About the Schedule Property Page

This page enables you to specify the send schedule for all distributions within the channel. The channel schedule determines when the distributions are sent to the subscribers. See the section on distributors in this chapter for more details on the different schedule types available.

NOTE

The channel schedule is converted into the distributor's time zone. All distributors that own distributions that are in this channel start sending at once, regardless of what time zone they are in.


ZENworks for Servers Web-Based Management

The ZENworks for Servers 2 Remote Web Console has been replaced with a Web-based management role snap-in to the Novell iManager utility. This role can be used as an alternative to ConsoleOne for managing TED objects and distributions. ZENworks for Servers 3 Web-based Management is covered in more detail in Chapter 14, "Using ZENworks for Servers 3 Web-based Management." It's a good idea to take some time to become familiar with using this tool because it can be accessed from virtually anywhere you have Internet access to your network.


Chapter 7. Understanding and Creating Server Software Packages

This chapter discusses the creation of Server Software Packages and how you can use them to manage your servers. With Server Software Packages, you can create a package that runs scripts for preinstallation and postinstallation, for loading and unloading of NLMs and Java classes, for installation prerequisites to restrict package installation, and for installing software on your servers after it has been successfully transmitted to the target server through TED or placed on the server manually.


Understanding Server Software Packages

Server Software Packages are much like an installation package that you may be familiar with for other systems. This package system enables you to specify that certain features of the hardware and system be present (disk space, OS version, and so forth), and you can look for the existence of particular files and registry keys or set parameters. You may also specify variables that are substituted into the package when installation occurs to enable you to customize the package for several different target machines. Additionally, you may include the loading and unloading of NLMs and Java classes and the execution of specified scripts both before and after package installation.

A software package is made up of a set of components. You can have any number of components within a software package. Within a component, you can have any number of files and folders that are copied to the server.

About Installation Requirements

Before you can install a software package on the server, the server must satisfy the requirements that have been administered as part of the package. In addition to package requirements, each component may have its own set of requirements that must be fulfilled before it's installed. If the requirements are not met for a particular component, that component will not be installed.

Consequently, only portions of a software package may actually be installed on the server. Additionally, because of the logic placed in the components and the fact that the component is installed prior to the rules for the next component being processed, you can put in some rules in a subsequent component that check for the existence of a previous package component on the server. By doing this, you can have subsequent components fail and not be installed if a previous component has not been installed. You could, for example, have component 2 look for the existence of a file on the server that should have been installed if component 1 was successfully installed. If component 1 does not install properly, component 2 does not run because the file from component 1 is not found on the server.

Focusing on .SPK and .CPK Files

The specifications that you give are all stored in a file with the suffix of .SPK. This file is stored on the file system and contains the configuration information for all components of the package. The .SPK file cannot be sent to a server or installed on a server; it must first be compiled into a .CPK file. At compile time, the ConsoleOne snap-in takes the references to the files in the .SPK file and retrieves the files and places them into the .CPK file so that no references are in the file. All the data for the installation is compacted and stored into the single .CPK file. This complete file can then be used to install the features onto your servers.

The compiled .CPK file can be sent over to the servers via the TED distribution system, or it can be manually copied to those servers (through CDs, Jaz drives, a network, and so forth) and then executed locally. The TED system subscribers (see Chapter 6, "Setting Up Tiered Electronic Distribution," for more information) receive the .CPK file and, if the ZENworks for Servers 3 Policy Manager is running on the server, activate that agent to have it unpack and execute the .CPK file. This can also be done manually by copying the file to the server (or having it accessible from the server drivers, for example, on a CD-ROM) and then entering the command PACKAGE PROCESS <path to .CPK file>. This performs the unpacking and execution of the .CPK file.

Rollback

ZENworks for Servers 3 provides the capability to roll back an installation that has occurred via a .CPK file. The rollback can remove any installation changes that have occurred on the last applied package. You can perform several rollbacks to get back to previous packages. For example, if packages A, B, and C have been applied, you can roll back only C. And after package C has been rolled back, you can roll back package B.

When ZENworks for Servers 3 applies a package, it creates a rollback package in the working directory of the policy engine, under the ROLLBACK subdirectory. Each rollback file is itself a .CPK file and is named by a GUID (globally unique identifier). When you request that a rollback occur, the rollback .CPK file is processed and then deleted. Rerunning the same installation .CPK file (unchanged version) does not create multiple rollback files. But if you recompile the .SPK file, a new .CPK file is created, even if you give it the same name, and the package is installed again on the server even though the .SPK file was unchanged.

You can request a rollback by going to the ZENworks for Servers 3 console and entering the command package rollback. Additionally, you can go through the browser-based management system and request that a rollback occur on the server.

Creating and Managing .SPK Files in ConsoleOne

You create and manage .SPK files in ConsoleOne. The ZENworks for Servers 3 install establishes a new namespace in ConsoleOne to manage these packages. A namespace in ConsoleOne results in a new rooted entry under your My World icon, at the same level as NDS in the ConsoleOne hierarchy display in the left panel.

When you create or insert an .SPK file, an entry is placed in ConsoleOne configuration files that, when ConsoleOne comes up, displays the known software packages without requiring the namespace to search all possible drives to find the .SPK file. Consequently, if you delete the .SPK file from the file system, ConsoleOne is not aware of this and continues to display the software package entry in the Server Software Packages namespace. But if you attempt to modify the package parameters, an error occurs because the file is not found. You need to manually delete the entry from ConsoleOne by choosing the Remove Package entry from the menu.

NOTE

Choosing the Remove Package entry does not remove the .SPK or .CPK files that are associated with the package. You also need to manually remove them from the file system if you no longer want to keep the packages.

Discussing Installation Failures

Should the processing of a .CPK run into problems installing the components (for example, running out of file space), the package installation is aborted, an error log is created, and a message is displayed. The components of the package that were installed are automatically rolled back and uninstalled.


Creating a Server Software Package

You can create Server Software Packages inside of ConsoleOne. When you installed ZENworks for Servers 3 (policies and TED components), there was a snap-in into ConsoleOne that registered itself to ConsoleOne, displaying a new rooted entry under your My World icon in ConsoleOne. The name of this container under My World is called Server Software Packages.

Two methods are used to introduce software packages into ConsoleOne and the system. You can create a new software package, or you can insert a previously constructed software package. When you insert a software package (by choosing Insert Package after you right-click on the Packages container), you are prompted through the wizard to specify the location of the .SPK file. This file is then read, and the information is displayed and is modifiable in ConsoleOne as if the package had just been created. This is the one way that you can reintroduce a package that you had created and then removed from ConsoleOne.

At a high level, the steps to follow in administering a Server Software Package include the following:

  1. Create a Server Software Package and administer any rules associated with installation of the package.

  2. Create components in the software package and administer any additional rules (beyond the package rules), if necessary, for the component to install.

  3. Compile the package and place the resulting .CPK file on the distribution server.

  4. Deliver the package to the target server manually or through Tiered Electronic Distribution.

  5. Install the package. This is done automatically by Tiered Electronic Distribution services and the ZENworks for Servers 3 agent. You can also install the package manually by typing PACKAGE PROCESS <path to CPK file> at the ZFS console.

Creating a New Server Software Package

To create a new Server Software Package, follow these steps:

  1. Launch ConsoleOne.

  2. Select the Server Software Packages container in the left panel of ConsoleOne (the hierarchical browser).

  3. Right-click on the Server Software Packages container to bring up the packages menu and select New Package. This launches the Software Package Wizard that prompts you through the initializations of the .SPK file.

  4. Click Next.

  5. Specify the name of the package and the filename of the .SPK file. You can browse through the file system to find an existing .SPK file to overwrite, or specify the name of a new file. You can give the file any extension you want, but parts of the system expect the extension to be .SPK, so that is your best bet. If you do not enter a suffix, the system automatically puts the .SPK suffix on the package.

  6. Click Next. The basic package is created and an entry is placed in the ConsoleOne Server Software Packages namespace for this new package. The new package is now displayed under the Server Software Packages container.

  7. Right-click the new software package. From the menu, you can choose Properties to set up the package requirements and rules, or New Component to add a new component to the package. You can also choose Remove if you want to delete this package from the namespace. Removing this package from the display in ConsoleOne does not remove the associated .SPK and .CPK files from the file system.

The following sections discuss the package rules administration and the addition of components to your software packages.

About Package Management

When you select a package under the Server Software Packages container, the pathname to the package .SPK file appears in the right view window and you see the administered description of the package (which is empty the first time). To administer the rules and features of the package as a whole, you must right-click the package in the container to bring up the menu choices. From that menu, select Properties. When you select Properties, the screen shown in Figure 7.1 appears.

Figure 7.1. Property pages for package management.

The following property pages are available for administration under the package.

Information on the Identification Property Page

Under the Identification property page, you may administer the name and the description of the package. The name of the package is what appears under the Server Software Packages container in ConsoleOne, and the description appears in the right window of ConsoleOne when the package is selected.

If you select the Disable Rollback check box, this package will not be available for rollback on the installed servers. It will be installed, and the rollback scripts and information will not be created.

Understanding the Requirements Property Page

The Requirements property page enables you to specify the requirements that must be satisfied for any portion of the package to be installed. If any requirement is not satisfied, no component will be installed from the package. Figure 7.2 provides a sample of the Requirements page.

Figure 7.2. Requirements property page for Server Software Package management.

Within the Requirements property page, you may set up any number of requirements that must be satisfied for the package to be installed. You may even set up multiples of the same type of rule (such as two file requirements) for the requirements. Be careful not to place contradictory rules, as this causes the package to never install, because all rules must be satisfied for any portion of the package to be installed on the server.

To add a rule, click the Add button and select the type of rule that you want. The rules appear in the left panel. To administer or modify a rule, select the rule on the left and administer its values in the right panel. To remove a rule, select it and then click the Remove button. The types of rules you can choose from are Operating System, Memory, Disk Space, Set Commands, Registry, File, and Products.dat. The following sections describe each type of rule.

About the Operating System Rule

Within the Operating System requirement, you may choose from the NetWare, Windows, Solaris, and Linux operating systems.

After you choose an operating system type, you may also keep the default, which states that it will install on any version of the operating system. Should you choose to be selective, you can enter the version number (major, minor, revision) of the operating system and then choose one of the appropriate rules to apply to the comparison between the administered value and the actual version number of the target servers. You may choose one of the following:

  • Any. Ignore the version number of the operating system.

  • Less than. The target server version number is less than the entered value.

  • Less than or equal to. The target server version number is less than or equal to the administered value.

  • Equal to. The target server version is exactly the same as the administered value.

  • Greater than. The target server version is greater than the specified version number.

  • Greater than or equal to. The target server is greater than or equal to the specified version.

About the Memory Rule

The memory rule enables you to specify the amount of RAM that must be present on the server. This is not the amount of current free space, but the total amount of RAM that is installed on the server. You may choose the following options on the rule and specify the amount to compare (for example, 128) in megabytes:

  • Less than. The target server has less installed memory than the specified amount of RAM.

  • Less than or equal to. The target server has the same or less than the amount of RAM specified.

  • Greater than. The target server has more RAM than the specified amount.

  • Greater than or equal to. The target server has as much or more than the RAM specified.

NOTE

To get the amount of RAM from the server, enter the command memory on the main server console. This gives you the amount of memory in kilobytes, so divide that number by 1,024 to get megabytes.

About the Disk Space Rule

This rule enables you to specify the amount of free disk space that must be available on the server prior to the package being installed. The amount of free space is specified in megabytes (MB), and you can specify either the SYS volume or a specific volume name. If the specified volume name (for example, VOL1) is not found on the server, the package will not be installed on the server. You can choose from the following rules:

  • Less than. The target server volume has less space than the specified amount.

  • Less than or equal to. The target server volume has the same or less than the amount of disk space specified.

  • Greater than. The target server volume has more space than the specified amount.

  • Greater than or equal to. The target server volume has as much or more than the amount of space specified.

About the Set Commands Rule

Within this rule, you can specify the expected value for any of the possible set parameters. When you select this rule, the Set Parameters Wizard walks you through contacting a server that is running ZENworks for Servers 3 Policy Manager, which retrieves from the specified server the list of potential set parameters. Because different servers with different software installed may have very different set commands, the wizard has you browse for a server running ZENworks for Servers 3 to use as the model server. The set commands from the server you select should represent the other servers in your network. From this list you can choose which set parameters (by category or specific parameter) you are interested in having contained in the rule. After the list is selected, the wizard terminates and the list of chosen parameters is displayed on this page.

Then you can create the rule by selecting the parameter and specifying the value that the parameter must have to enable the package to be installed. If any of the specified parameters are not set as administered, no component of the software package is installed.

About the Registry Rule

This page enables you to place a rule on the existence or value of a registry key from the NetWare registry. You first select whether the registry interest is either a key, a name, or data. Currently, the data values may be represented only as strings, and an exact match is the only type of compare supported.

When you select a key type, you can choose to accept the installation depending on whether the key exists. Then you must specify the key's name.

By selecting the name type on this rule, you can also choose to accept the installation based on whether the name exists in the registry. You must also specify the name to be matched.

When you choose to look for a data value, you must specify whether the data value equals the specified value. Then you must specify the key, the name, and the value of the data. The page is set up to enable you to compare based on several different types of values; currently, the only value type is string.

About the File Rule

With the file rule, you can specify whether a particular file exists on the server. You specify the name of the file (including the volume; SYS is assumed if not specified) and the flag to succeed if the file exists, or whether you want to base the rule on the file's date. Should you choose to look at the file's date, you can choose from the following:

  • Before. The target server file has a date and/or time earlier than the specified date and time.

  • On or before. The target server's file has a time stamp that is the same or before the specified date and time.

  • On. The target server file has the same time stamp as specified.

  • On or after. The target server file has the same time stamp or one that is later than the one specified.

  • After. The target server file has a date that is after the given date and/or time.

After choosing the comparison function, you need to click the Calendar button to be given a calendar control that enables you to select a date and enter a time value for the file.

About the Products.dat Rule

This rule enables you to match strings that are stored in the products.dat file on the server. The products.dat file identifies the various features and NetWare components that have been installed on the server.

This rule enables you to specify the name of the product ID and then look at the version and the description of the ID to see whether a match exists. With both the version and the description, you can identify whether the specified value contains, begins with, or matches the entry in the products.dat file. All comparisons of the values, including the ID, use case-sensitive matching. If the matched ID exists and has the value identified, the package satisfies this rule.

Exploring the Variables Property Page

This property page enables you to specify variables that are used by the installation package to customize the filenames and locations in the software package.

Several variables can be used in this and other places in ZENworks for Servers 3. These variables are enclosed in % (percent signs) and can be a defined set, an environment variable from the server, an attribute of the server object, or an attribute of a specified eDirectory object. The order that ZENworks uses to recognize environment variables is as follows:

  1. If the string between the %s is a predefined variable, that value is placed in that string. Predefined variables are one of the following:

    • LOAD_DIR. The directory where the NetWare server was loaded.

    • TREE_NAME. The name of the tree where ZENworks for Servers is located.

    • WORKING_PATH. The working directory for the temporary files.

    • SERVER_DN. NDS distinguished object name for the server.

    • IP_ADDRESS. IP address of the server.

    • BASE_PATH. The base path showing where the ZENworks for Servers policy engine is located (such as SYS:\SMANAGER).

    • SERVER_NAME. Name the server was given at install time.

  2. If the string has the format %object distinguished name;attribute%, the attribute value of the specified object is placed in the string.

  3. If the string has no semicolon, the system looks for an environment variable of that name and replaces the value in the string. The system looks in both the NetWare and the Java environments for this variable.

  4. If no environment variable exists with that name, the name is assumed to be a server attribute and the system attempts to place the attribute's value in the string.

  5. If the variable is not a server attribute, the unchanged variable string (including the % signs) is used as the value.

Managing Components

After you create a package, you need to add components to the package. The components that actually contain the files are installed on the target server.

To add a component to a package, right-click the package in ConsoleOne to bring up the menu. From the menu, choose the New Component option. After selecting the option, a dialog box prompts you for the component's name. Remember, multiple files can be installed in a single component, and a component can have its own set of rules to enable it to be installed independently in the package. Choose a name that will help you remember the types of files that are in the component. After a name is supplied, the component is created and is displayed under the package title. When you select the component, its description is displayed in the right pane.

To manage a component, right-click the component and select Properties from the menu. After selecting Properties, you are presented with the property book for the component. Figure 7.3 shows a sample property book for a component.

Figure 7.3. Property book for a component of a Server Software Package.

From this property book you can administer the following pages in the component.

Looking at the Identification Property Page

As shown in Figure 7.3, you may administer the name of the component and the description of the component. The name of the component is displayed in ConsoleOne under the package, and the description is displayed in the right panel of ConsoleOne when the component is selected.

Additionally, you can request that an action on the server be performed after the entire package is successfully installed on the server. This is administered at the bottom of the page and has the following values:

  • Do nothing to the server. Continue and perform no particular action.

  • Down the server. Down the server without restarting system.

  • Restart the server. Down the server and restart it, which causes the server hardware to be rebooted.

  • Reset the server. Down the server and reset the server.

Examining the Preinstallation Requirements Property Page

This page enables you to specify various requirements that must be met for the component to be installed on the server. No component will be installed if the server does not meet the package's requirements. In addition to the requirements of the package, the component preinstallation requirements must also be met for the component to be installed. Components may have different requirements, resulting in the possibility of only some components being installed on the server while other components are not installed.

See the section earlier in the chapter on package management that discusses its property page. The same components are available to the package.

Discussing the Preinstallation Load/Unload Property Page

From this page you can request that the system load or unload an NLM or a Java process. Despite what some documentation states, you can unload/kill an NLM process with the unload process request. A sample of this property page is shown in Figure 7.4.

Figure 7.4. Preinstallation Load/Unload property page for a component of a Server Software Package.

To add an action on this page, click the Add button and select whether you want to load an NLM, load a Java class, or unload a process. After an entry is selected, it is placed in the left panel. You can edit the name of the entry by selecting the entry and typing in a new name. In the right panel associated with each entry, you need to provide information such as a filename and any parameters.

Each loading or unloading of processes occurs in the order specified in the left panel. You can rearrange the order by selecting an item in the list and clicking the up and down arrows on the page to move the item either up or down in the list.

Loading an NLM

When you select to have an NLM loaded prior to installation, you need to provide the following information in the right panel:

  • File Name. Enter the filename to be loaded. Be sure to include the full path if the NLM is not in the SYS:\SYSTEM or in the path of the server. The path can include variable names.

  • Parameters. Enter any parameters that you want to pass to the NLM. These parameters can include variable names.

  • Wait for termination. This is a check box that tells the system to wait until the NLM loads, does its work, and then unloads itself before proceeding in the installation process. If the NLM does not terminate and unload, the installation does not continue until you manually unload the NLM.

NOTE

If the software package agent tries to load an NLM that is already loaded on the server, it fails and the entire package is rolled back. It is recommended that you unload the NLM first in the unload parameters (the attempt to unload an NLM that is not currently loaded does not result in a failure) and then ask that it be loaded.

Loading a Java Class

When you select to load a Java process, you must also provide the following information:

  • File Name. The filename, traditionally referred to as the classname, to load into the JVM (for example, com.novell.application.zenworks.ted.Distributor).

  • Parameters. This entry constitutes parameters that you want included on the command line when the process is launched (such as ZENTREE Distributor_ZEN1.servers.novell). This parameter is the parameter passed to the Java process; traditionally, these parameters follow the process name when you launch the Java Virtual Machine.

  • JVM Parameters. This entry contains the parameters to be passed to the Java virtual machine. Traditionally, these parameters are such items as the classpath or other Java configuration parameters. These parameters can include variable names.

  • Wait for termination. This flag tells the system to launch the Java class and then wait for it to run and then terminate. If the class does not self-terminate, the installation does not continue until you manually terminate the Java class.

Unloading a Process

When you choose to unload an NLM or Java process, you must also provide the following information:

  • File Name. The classname, or NLM filename (with the .NLM extension) of the process that the system should attempt to unload. The system first attempts to unload (as if it were an NLM) the filename you specify, and then the system attempts to perform a java –kill by using the name given. If the name matches both an NLM and a Java process, both are terminated. The Java process name must match exactly the process names that appear with the java –show command given at the console.

  • Wait for termination. This flag notifies the system to wait until the process is terminated before proceeding. If the process does not unload, the installation process does not continue until you manually terminate the process.

Start Service

ZENworks for Servers 3 enables you to start a service on a Windows NT/2000 Server when you are distributing a software package to it. This enables you to start any services that will be required for the software package to be applied. When you choose to Start a Service, you must also provide the following information:

  • Service Name. The name of the Windows server you want to start.

  • Wait for this service to start before continuing. This tells ZENworks whether to verify that the service has actually started before applying the software package.

Stop Service

ZENworks for Servers 3 enables you to stop a service on a Windows NT/2000 Server when you are distributing a software package to it. This enables you to stop any services that will interfere with applying the software package. When you choose to Stop a Service, you must also provide the following information:

  • Service Name. The name of the Windows server you want to start.

  • Wait for this service to stop before continuing. This tells ZENworks whether to verify that the service has actually stopped before applying the software package.

About the Script Property Page

You add a script to the policy by clicking the Add button on this property page. When you click the Add button, an entry is placed in the left window and you are allowed to edit the name of the script. After you name the script, you can choose on the right the type of script that you will be creating. The choices of script types are currently NCF, NETBASIC, and PERL. After you identify the script type, you are free to type the script in the provided window. ZENworks for Servers 3 provides no syntax checking or validation for the script you enter.

You can add multiple scripts of any of the available types into this component. The scripts are executed in the order shown on the administration screen (from top to bottom). If you want to reorder the running of the scripts, you must select a script name in the left pane and click the up or down arrows to move the script into a different order.

When the ZENworks for Servers 3 policy engine runs the preinstallation scripts of this component, it creates a temporary script file (in its working directory) that contains the specific script and then launches the corresponding NLM that works with the identified script, passing the NLM the name of the script to run. Consequently, netbasic.nlm and perl.nlm must already exist on the server where the script is to be run. These are installed by default on NetWare servers. Regardless as to whether a script fails or succeeds, the engine proceeds to the next script.

Understanding the Local File Copy Property Page

ZENworks for Servers 3 enables you to specify local file copy operations to be performed when applying a software package. This can be extremely useful if you need to copy or move files that already exist on the local file system to a new directory without making them part of the software package.

Suppose that you have configuration files for a software package that are specific to each server, but they need to be moved to a new location for the software package. You can have ZENworks for Servers 3 move the files as part of applying the software package to the server.

You can set up a local file copy by selecting the Local File Copy tab of the software package Component object and specifying the following options:

  • Source Path. Specifies path to the source file(s).

  • Destination Path. Specifies path to copy the files to.

  • Include Subdirectories. Indicates whether ZENworks includes any subdirectories located under the source path in the copy.

  • Maintain Attributes. Indicates whether to maintain the file attributes (read-only, hidden, and so on).

  • Overwrite Destination Files. Specifies whether ZENworks overwrites files during the copy. This overwrites files regardless of file date.

  • Maintain Trustees. Determines whether ZENworks maintains the file system trustees of objects that are copied. This option is important because improperly setting it could give users access to files that they should not have, or users could lose access to files they need.

  • Retry When Locked. Specifies whether to retry if the file is locked, and if so, specifies the number of times to retry before failing the copy.

  • Kill Connection of Opened Files. Enables you to tell ZENworks to kill a user's connection if a file is locked because the user has it open. Turning on this option has the potential for users to lose data in the file they have opened when their connection is terminated.

  • Error Processing. Enables you to specify whether ZENworks fails or continues when it encounters an error copying a file. This is very useful to enable you to apply the package even if the file copy fails.

  • Operation. Enables you to specify whether ZENworks moves or copies the file. Use the move option unless you need to maintain a copy of the file on the system.

Understanding the Copy File Property Page

This property page handles the placement of source files onto the server. It performs a copy of the specified file (placed into the package) onto the target server. Figure 7.5 displays a sample of this page.

Figure 7.5. Copy File property page for a component of a Server Software Package.

The first step in the Copy File page is to define a file group. A group is a set of files that are copied onto the server into the same root directory. You may have more than one group in the software package to enable you to copy files to a different root directory. You define a new group by clicking the Add button, and the system prompts you for a group name and a target path. The target path may contain variables. Groups are processed in the order shown in the left panel. If you want to modify the order, select a group and click the up or down arrows to rearrange the order of the groups. Folders and files cannot be reordered.

After you create a group, you may add files or directories under that file group to have these files and subdirectories created on the target server under the group target path. Select the addition of either subdirectories (folder) or files from the Add menu after your first group is created. You can also select the creation of additional groups through the Add button.

When you create each item, you have the option of naming the folder or file by editing the item name in the left panel. In the right panel, you may choose options with each type to describe how you want to have the system create or delete your files.

Identifying a Folder

A folder identifies a subdirectory under the target path. Name the folder in the left panel with a click of the mouse, and then type in the name you want. The right panel enables you to select whether this folder should be created or deleted. If it is to be created and already exists, nothing happens. If the folder is to be deleted, this folder and all contained files and subfolders are deleted from the server file system.

Identifying a File

This type identifies a file to be sent to or removed from the target server. Browsing through your file system mapped drives and selecting the file enters the filename. This represents the file's source path (which can be different than the target path you are generating with the series of paths and folders). In the right pane, you administer the following actions associated with the designated file:

  • Copy mode. This identifies the method that should be used when copying the file onto the target server from the package. The choices are as follows:

    • Copy always. This copies the file onto the target server, either creating the file or overwriting an existing file of the same name.

    • Copy if exists. This copies the file only if the file already exists on the server, overwriting the original target file.

    • Copy if does not exist. This copies the file only if the file does not already exist in the specified location.

    • Copy if newer. This copies the file onto a target server only if the file date is newer than the current file on the target server with the same name. If the file does not exist, this does not copy the file to the target server.

    • Copy if newer and exists. This copies the file only if it is newer than the existing file or if the file does not exist in the specified target directory.

    • Delete. This removes the file from the server and does not copy anything from the package.

  • Attributes. This enables you to specify the attributes that should exist on the file after it is placed on the target server. This does not modify any existing file that was not changed in the process. The possible attributes that can be set are Read Only, Archive, Hidden, and Execute.

Discussing the Text Files Property Page

This page enables you to enter multiple text file changes into this single package. Text files changes are edits that you want to occur to existing ASCII files on the server. You create the changes by clicking the Add button at the bottom of the screen. When you click the Add button, you are prompted to enter the name of the file (on the target server) to modify. The name should include the full path to the file to ensure that you are modifying the file you want. You can modify more than one text file by selecting Text File from the Add button menu.

You can also make multiple changes to the same text file by selecting the text file, clicking the Add button, and selecting Change. A new change is placed in the left panel with the cursor at the change name, enabling you to edit the name of the change. The changes are applied to the specified file in the order shown. Should you want to change the order of the changes or the order of the files, select the item and move it in the list by clicking the up or down arrow.

After you select a text file to change, you choose the change mode that corresponds to this change. You may choose either Prepend to File, Append to File, or Search File as one of your modes.

About Prepend to File

When you choose to prepend text to the file, the right side of the Administration page changes to display a large text box. You may enter any text strings that you want in the text box and click OK to store this entry. When the change is applied, the exact strings that you typed are placed before the first lines in the existing file.

About Append to File

When you choose to append text to the file, the right side of the Administration page changes to display a large text box. You may enter any text strings that you want in the text box and click OK to store this entry. When the change is applied, the exact strings that you typed are placed after the last lines in the existing file.

About Search File

If this change is a Search File change, you need to administer the following additional information to make the change effective:

  1. Identify the search type that you need for this change. The search types are as follows:

    • Sub-String. Search for the search string in any of the text. The text specified may be contained anywhere in the file, even in the middle of a word. If you have the substring of day, the following text would all match with this substring: today, day, yesterday, daytime, and so forth.

    • Whole Word. Search for instances of the string that are surrounded by white space or a beginning or end of line. If you have the string of day, only the word day would be a match. The words today, yesterday, daytime, and so forth do not constitute a match.

    • Start of Line. A successful match is identified if the beginning of a line (first line of file, or characters following a carriage return) starts with the string, regardless of whether the string is a whole word or not. If you had the string day, this type would match only with the following lines: daytime is set, day by day, and so forth.

    • End of Line. A successful match is identified if the end of a line (characters preceding the carriage return or end of file) contains the string, regardless of whether the string is a whole word or not. If you had the string day, this type would match only with the following lines: the time to act is today, day by day, and so forth.

    • Entire Line. The entire specified string must consume the entire line of text (from text following a carriage return, or beginning of the file, to the next carriage return, or end of the file) including any white space. The string must constitute the only characters, other than the carriage returns, on the line. If the string were day, only a line with the single word day on it would match.

  2. Specify the search string that you're trying to match. Enter this into the Search String field.

  3. Specify whether you want the search to be case-sensitive by checking the check box to make the search match only if the case matches.

  4. Change the Find All Occurrences field if you want to find only the first occurrence of the string in the file. The default is to have this field checked, meaning that all occurrences in the file will have this policy applied to them.

  5. Choose a result action that will be applied to the string after it is located in the file. The possible result actions are as follows:

    • Delete All Lines After. All lines (characters following the next carriage return) after the string are deleted from the file. The file is basically truncated, ending with the line that held the first matching string. Obviously, searching for all occurrences is not effectual when this is the resulting action, as a match truncates the rest of the file.

    • Delete All Lines Before. All lines (characters before and including the previous carriage return) before the string are deleted from the file. The file is reset so that it begins with the line that held the first matching string. With this result action, another search continues and if another match is found, all the lines before it are deleted as well.

    • Prepend to File If Not Found. This result action places the replacement text in the file at the very beginning of the file should the search string not be found in the file. This action only adds text; it doesn't delete or modify text.

    • Append to File If Not Found. This result action places the replacement text at the end of the file should the specified search string not be found. This action only adds text; it doesn't delete or modify text.

    • Replace String. This action takes the matching string and removes it from the file, placing the replacement string in the exact location of the deleted string. If the replacement string is of a different length than the search string, the surrounding characters are shifted to the left or right, depending on whether less or more room is required. Basically, the new text is inserted in the location where the search string was removed.

    • Replace Word. This result action takes the word where a substring was matched and replaces the whole word (from beginning of line or space to space or end of line) with the replacement text. If the substring were day, the following words would be replaced with the replacement text: day, today, daytime, and so forth.

    • Replace Line. This action takes the line where the match has occurred and removes the complete line from the file. The replacement text is placed in the same location where the removed line was located in the file.

    • Append Line. This action appends the replacement string to the line that contained the match. The matching string is not removed from the file; the only change is the addition of text to the end of the line.

  6. Specify the new string. In the text box that is provided, you need to supply the text that will be applied to the file based on the result action that was specified.
Discussing the Set Commands Property Page

This property page enables you to set parameters on the NetWare server as part of the installation of this package. If there is a policy that also modifies a set parameter, the next time that the policy runs it will reset the set parameter to the value defined in the policy.

To add parameters, you need to click the Add button. This activates a wizard to collect potential parameters. Because the set parameters on NetWare are dynamic and can be enhanced by various sets of NLMs, there is not a known set of set parameters. Consequently, ZENworks for Servers 3 walks you through a wizard that goes to an identified NetWare server (the server must be running the ZENworks for Servers 3 policy engine) and queries the server for the set of parameters. This list is then transmitted back to the wizard and used as a model for other servers in your network.

To complete the wizard and to add parameters to this component, follow these steps:

  1. Click the Add button in the Set Parameters Policy window to activate the wizard.

  2. Click the Browse button and browse the NDS tree to the server that has a representative set parameter list. Select that server. Click the Next button. This causes the wizard to query the server and retrieve all possible set parameters.

  3. Select the set of parameters that you want to have contained in the component. You can select an entire category by clicking the check box next to the category, or you can open the category and select individual set parameters. After you select the set of parameters you want to administer with the component, click the Finish button.

  4. You return to the Set Commands property page with the list of only the categories and/or the parameters that you had selected in the wizard. To administer an individual parameter, select the parameter and click the Edit button.

  5. When you click the Edit button, you are presented with a dialog box that is unique for each parameter type. From this dialog box you can administer the value of the parameter. You can also select one of the following choices that administer how the parameter is given to the server:

    • Console. The command is passed to the server console by the policy engine.

    • Autoexec.ncf. In addition to passing the command to the console for immediate activation, the set parameter is placed into the autoexec.ncf file so that following a reboot the server will set the parameter.

    • Startup.ncf. In addition to passing the command to the console for immediate activation, the set parameter is placed into the startup.ncf file so that following a restart the server will set the parameter.

  6. Complete the list of parameters and click the OK button to have these items set as part of the software package.
Information About the Registry Settings Property Page

NetWare 5 introduced a registry to the server; this page enables you to modify or set registry keys into the server. This page is ignored on previous versions of NetWare. Figure 7.6 shows this page.

Figure 7.6. Registry Settings property page for a component of a Server Software Package.

You add a key to the list by clicking the Add button and then selecting the Key menu entry. Each key may have any number of values based on the value syntax. The possible key types are Binary, Expand String, (Default), Dword, Multi-Valued String, and String.

Each type of key is presented with the value name in the left pane and the actual data value in the right pane. Depending on the type of the value, the right pane has appropriate fields to enable you to enter the values for the registry key.

You can add multiple value or keys to this property page by continuing to click the Add button and selecting the item you want.

About the Products.dat Property Page

See the section earlier in the chapter on package management that discusses this property page. The same rules and modifications are available to the component.

Simplifying the Postinstallation Load/Unload Property Page

This identifies the set of NLMs or Java processes that should be loaded or unloaded after the installation process is completed. See the section earlier in the chapter about preinstallation load/unload for more information.

Outlining Postinstallation Script Property Page

This identifies the set of scripts that should be executed after the installation process is completed. See the section earlier in the chapter about preinstallation scripts for more information.

Compiling the Software Package

After you complete the administration of the software package to include all the files and changes that you want for the installation, you must compile the package before it can be installed on the target server. The compilation process checks the rules and package for any errors, and also retrieves the files that are specified and includes them in the compressed package file. The target package file is expected to have the suffix .CPK. Obviously, because all the files that are to be installed on the target server are contained in the compiled package, the .CPK file will be significantly larger than its .SPK counterpart. So be prepared to consume some disk space for this process.

To compile a package, right-click the package under the Servers Software Packages container on the ConsoleOne main window. Select the Compile Menu choice. This brings up the Compile Wizard, which prompts you for the output filename and places the .CPK suffix on that file, if a suffix is not specified. The wizard then compiles the .SPK file into the resulting .CPK file and places it on the disk as specified. The .CPK file can then be installed on the target server after it has been placed on the distribution server and a distribution object has been created and distributed to the target server, or you can copy the .CPK file to the target server manually.

NOTE

The files defined in the .SPK are drive-dependent, meaning that if you map different drives on another workstation or remap drives, these files may not be found when a compile is requested.


Installing a Server Software Package on the Target Server

After you create a .CPK file by compiling a defined .SPK package, you can place this .CPK file on a target server and request that the ZENworks for Servers 3 system install the package and perform the actions specified in the package.

You can get the .CPK file to your target servers a number of different ways: Copy the file to the server, place the file on external media and take it to the server, or send the .CPK file to the server with Tiered Electronic Distribution.

Sending the File with TED

One alternative is to send your packages through the Tiered Electronic Distribution services available through ZENworks for Servers 3. You can create a distribution that contains a Server Software Package and place this distribution into a channel. When the subscriber receives the software package through the channel, it automatically notifies the policy engine (at extraction schedule time) and begins processing the installation package. See Chapter 6, "Setting Up Tiered Electronic Distribution," for a more detailed description of how to do this.

Copying the File Manually

You can get the .CPK file to the server either by creating a movable media that you can then take to your target servers and mount or by copying the file through the file system to a volume on the target server. Be aware that the .CPK file can be extremely large, depending on the files included in it.

After the target server has access to the .CPK file from its local file system, you can request that ZENworks for Servers 3 process the .CPK file by entering the following command on the ZENworks for Servers 3 policy engine console:

package process <full path to .CPK file>

This spins off a thread that begins the unpacking and installation of the Server Software Package onto the server.


Updating Server Software Packages

When you modify a Server Software Package, the .SPK file automatically updates when you save the changes. The .CPK file, however, is not updated automatically. When you want to update the .CPK file, you need to recompile the package.

If you have set up TED to distribute your software packages, when you update the .CPK file in the same place as listed in TED in a distribution, the package is automatically sent on the next scheduled update (because it is changed) and the changed package is installed on the server.


Chapter 8. Understanding ZENworks for Servers 3 Management Services

One of the most difficult tasks network administrators have is to manage large complex networks made up of numerous servers, switches, routers, and other hardware. That task is daunting for most, and for this reason ZENworks for Servers 3 provides a powerful configuration and management engine that can be operated from a centralized location. ZENworks for Servers 3 provides administrators with several monitoring, management, and reporting tools that help them take control of their heterogeneous networks.

This chapter provides you with an overview of the ZENworks for Servers 3 management components and the console interface you use to monitor and manage your network, as well as some strategic planning that you can do to get the most out of ZENworks for Servers 3 management services.


Understanding ZENworks for Servers Management Components

Several different components are provided with ZENworks for Servers 3, each of which enables you to manage a different aspect of your network. Separately, these components are all useful tools; however, when you use them together they become an extremely powerful management engine. The first step in taking control of your network using ZENworks for Servers 3 is to understand the components that make up ZENworks for Servers 3 Management Services. The following sections cover the main components of ZENworks for Servers 3 Management Services and give you an idea of how they all fit together.

Introducing Management Site Services

The first ZENworks for Servers 3 Management Service component you need to understand is Management Site Services. Management Site Services is actually a collection of components that are used to create, monitor, and manage a management site. A management site is simply an object in NDS that represents and defines a collection of discovered network objects that together make up a group of resources and services.

Collecting network resources and services together into a single management site allows for easier and more powerful management from a centralized location. The following sections describe the components provided with ZENworks for Servers 3 that are used by Management Site Services.

About Network Discovery

The first component of Management Site Services you need to know about is the network discovery component. Network discovery is the process of determining the topology of your network by actively probing your network, searching for services and devices that support management information bases (MIB). After you collect the information about the topology of your network, it can be used to enable you to display, monitor, and manage your network from the management console.

NOTE

For more information about the management console, see the section later in this chapter called, appropriately enough, "About the Management Console."

The following are the two main pieces of software that make up the network discovery component:

  • Discovery software. A group of modules that run on a management server and search the network, discovering devices to build the network topology. This information is stored in the NETXPLOR.DAT file.

  • Consolidator software. Software that runs on the ZENworks for Servers 3 management server. It reads data from the NETXPLOR.DAT file, which was created by the discovery software and populates the ZENworks for Servers 3 database.

Topology Mapping

Now that you understand how the ZENworks for Servers 3 database gets populated, you need to understand the best way to access the information. One of the best tools for accessing information about managed sites is topology mapping through the Atlas Manager. The Atlas Manager is made up of software that reads the ZENworks for Servers 3 database and uses it to create an atlas database and software that displays the network topology in an atlas on the management console. (An atlas database is a database that resides on the management server that contains the data used to create the Network Topology view.)

The atlas is a simple view that can be configured to give you the quickest look at your management sites. You can use this atlas of your network topology as a powerful tool to help you monitor your network for heavy usage, outages, and other problems.

About MIB Tools Administration

The next component for ZENworks for Servers 3 Management Site Services you should know about is the MIB tools. ZENworks for Servers 3 includes tools to help you monitor and manage all SNMP devices on your network. The following are the two main MIB tools you use to administer SNMP devices:

  • SNMP MIB Compiler. Parses a set of predefined SNMP MIB files written in ASN.1 and SNMP V2 format, stores the compiled files in the ZENworks for Servers 3 database, and updates trap definitions in the alarm template database. The MIB Compiler also enables you to set new SNMP alarm templates into ZENworks for Servers 3 so that the SNMP alarm templates can be recognized and interpreted as alarms.

  • SNMP MIB Browser. The MIB Browser takes the compiled MIB and displays the objects in a tree format. The MIB Browser also lets you walk the tree to view and manage the selected MIB objects.

Monitoring SNMP Services

Other components for ZENworks for Servers 3 Management Site Services you need to know about are the SNMP services that run on managed sites to provide information about connectivity and availability of resources and services within the managed group. These services notify the management console whenever the status of what they are monitoring changes. This gives network administrators immediate alarms and information about what is happening on their network.

The following are services that can be monitored by the ZENworks for Servers SNMP agents:

  • DNS. Domain Name System

  • IP. Internet Protocol

  • DHCP. Dynamic Host Configuration Protocol

  • IPX. Internet Packet Exchange

  • FTP. File Transfer Protocol

  • TFTP. Trivial File Transfer Protocol

  • SMTP. Simple Mail Transfer Protocol

  • SNMP. Simple Network Management Protocol

  • NNTP. Network News Transfer Protocol

  • HTTP. Hypertext Transfer Protocol

  • HTTPS. Hypertext Transfer Protocol Secure

  • NFS. Network File System

  • Echo. Network Echoes

  • Time Service. Network Time Services

Discussing Database Administration

Another important component of Management Site Services is administration of the ZENworks for Servers 3 database. ZENworks for Servers 3 includes a powerful CIM-compliant database on the management server. The database acts as a repository for management site information collected from the network. That information can be displayed or formatted in various ways to provide you with specific information you need to manage your network. The information ZENworks for Servers 3 collects from your network is stored in the following three logical databases:

  • Topology database. Contains topology, alarms, and map information.

  • Inventory database. Contains server inventory data.

  • Policy and Distribution Services database. Logs successes and failures for server policies and Tiered Electronic Distribution components.

Using Alarm Management

Another important component of Management Site Services you should be aware of is the capability to manage network alarms throughout the management site. ZENworks for Servers 3 uses alarms to monitor the state of your network and perform predefined actions when an alarm is detected. Alarms recognized by ZENworks for Servers 3 include SNMP traps, connectivity testing, and threshold profiling.

The ZENworks for Servers 3 alarm management system processes SNMP traps and proprietary alarms and then forwards the alarms to subscribing management consoles. You can configure ZENworks for Servers 3 to perform specific actions on an alarm by specifying the desired action in an alarm disposition. The following are some actions that can be automatically performed:

  • Execute a program.

  • Send an email notification.

  • Create an archive.

ZENworks for Servers 3 alarm management enables you to set specific processed alarms to be forwarded to other ZENworks for Servers 3 management servers. You can also forward unprocessed SNMP traps directly to a target address of third-party enterprise management applications.

Controlling Your Network with Role-Based Services

The role-based services component of ZENworks for Servers 3 Management Site Services gives you very tight and manageable control of your network. ZENworks for Servers 3 uses role-based services, defined in NDS, to organize ZENworks for Servers 3 tasks into roles and to assign scope information to each role. Role-based services enable you to organize your network management by specifying the tasks that each user is authorized to perform.

Reporting

The final component of ZENworks for Servers 3 Management Site Services you should be aware of is the capability to generate and use reports. ZENworks for Servers 3 provides reporting services for the generation of statistical reports. These reports can be displayed on the management consoles or exported to popular database and Web formats.

ZENworks for Servers 3 reports are powerful tools to help you understand the state of your network, resolve network problems, and plan for network growth. The following is a list of reports that can be generated by ZENworks for Servers:

  • Health reports. General network health

  • Topology reports. Current network configurations

  • Alarm reports. List of active alarms

  • Server inventory reports. Current server configurations

  • Server policies reports. Current server policy information

  • TED (Tiered Electronic Distribution) reports. Software distribution information

About Server Management

Now that you understand the components involved in ZENworks for Servers 3 Management Site Services, you need to understand the components specifically for server management. The ZENworks for Servers 3 management components enable you to monitor, configure, and control the managed servers and nodes on your network.

ZENworks for Servers 3 Server Management is made up of SNMP-based server management agents for NetWare and Windows NT/2000 Servers, which provide real-time server performance data and information about server alarms and events to network management consoles.

Valuable information about your NetWare and Windows NT/2000 Server can be gained by selecting one of the following views from a server or node in ConsoleOne:

  • Console view. Provides details about the selected server or node. Enables you to display information about the internal components of the node, such as the devices, operating system, and services available.

  • Summary view. Provides details about the server performance, such as alarms generated by the server, CPU utilization, and available hard drive space. Enables you to view summary information about other components, such as processors, threads, memory, and volumes.

  • Trend view. Displays graphical representations of trend parameters, enabling you to monitor the state of a server over various periods of time. Trend data enables you to track the health status of servers and predict potential problems and be ready for upgrading your server configurations.

ZENworks for Servers 3 Server Management components also enable you to configure your NetWare servers as well as execute frequently used commands from the management console.

Analyzing Traffic

In addition to server management, ZENworks for Servers 3 includes powerful tools to help you manage and analyze LAN traffic. The traffic management component provides traffic analysis services that enable a NetWare or Windows NT/2000 server to monitor all traffic on an Ethernet, token ring, or FDDI network segment.

ZENworks for Servers 3 traffic analysis tools can be used to understand the general health of your network, predict problem areas, and plan for future growth. The following are the tools that make up the ZENworks for Servers 3 traffic analysis component:

  • Standard and enterprise-specific RFC 1757 MIB descriptions for remote network monitoring

  • Extensions added to NDS, including Remote Network Monitoring (RMON) agent configuration

  • Network traffic trending and analysis tools to efficiently manage collected data

  • Canned network health report templates for quick report generation

  • Integration with topology maps for easy viewing

  • Performance threshold configuration and profiling for tighter control

  • A view of conversations on network segments and utilization for problem analysis

  • Packet capture tools that collect and display LAN packets for problem analysis

Information About Remote Control

Another important component included with ZENworks for Servers 3 is remote control. The remote control component enables remote server management through the management console.

The remote control agent is installed on each NetWare or Windows NT/2000 Server that you want to remotely control from the management console. The remote control agent ensures that remote control sessions are secure. This enables you to access the NetWare server console or the Windows NT/2000 Server and perform maintenance operations without having to be sitting at the machine, thus saving you a considerable amount of time.

Viewing the Server Inventory

Another important component included with ZENworks for Servers 3 is the server inventory. The server inventory component enables you to quickly view the complete hardware and software inventory of all managed servers. ZENworks for Servers 3 server inventory also enables you to query the centralized database of the managed servers to quickly obtain specific information you require.

The server inventory is created by scan programs that identify each managed server by its distinguished name and the tree name and query the server for data. After the scan data is collected, the scan program sends the scan data report to the inventory components on the inventory server. It is stored in the inventory database on the inventory server for later use.

About the Management Console

The most important component of ZENworks for Servers 3 management services you should become familiar with is the management console. The management console provides access to all the other components, providing you with a single, centralized location from which to manage and monitor your network.

ZENworks for Servers 3 provides several snap-ins to the Novell ConsoleOne management console under the ZENworks for Servers namespace. These snap-ins provide access and control to the ZENworks for Servers 3 management services. (See the next section for information of how to get the most out of your ZENworks for Servers 3 management console.)

Using the ZENworks for Servers 3 Console

Now that you understand the components that are involved with ZENworks for Servers 3 network management services, you need to get an understanding of how to access, control, and monitor them. ZENworks for Servers 3 includes several snap-ins to the ConsoleOne management tool, which expand its capabilities. This section covers how to use the ConsoleOne snap-ins to manage and monitor your network.

Navigating the ZENworks for Servers 3 Namespace

The first thing you need to understand about the ZENworks for Servers 3 console is how to navigate around the ZENworks for Servers 3 namespace. After ZENworks for Servers 3 management services are installed, you have new objects that can be accessed from the main Tree Browse screen in ConsoleOne.

Your network and resources are organized in the namespace as a collection of objects that are arranged in the following specific hierarchy of objects:

  • ZENworks for Servers sites object. The ZENworks for Servers namespace container. Resides at the top of the ZENworks for Servers namespace hierarchy. Expanding this object in ConsoleOne displays a list of management sites.

  • ZENworks for Servers site. Represents a ZENworks for Servers 3 management server. It represents an NDS object that defines a collection of discovered objects that collectively make up a group of services. Expanding the site displays an atlas for the services located there.

  • Atlas. A container object for all objects that were created during network discovery. Expanding the atlas can show a WAN page, an Area page, and an Islands page, including segments.

  • Segments. Network objects that are included within the selected atlas. Expanding a segment reveals a list of server and node objects.

  • Nodes. Individual network entity. Expanding a node shows you a set of details that describe the node.

  • Node details. List of system internal components in one of the following three categories: Devices, Operating System, or Services. You can drill down into the server configuration categories further to display more details about the internal components of the server, such as CPUs, installed software, volumes, kernel, and adapters.

Setting ZENworks for Servers Console Options

Now that you understand the hierarchy of the ZENworks for Servers namespace in ConsoleOne and can navigate through it to find objects, you need to understand what options you have for managing those objects. From ConsoleOne, you can view objects in many different ways, set properties for the object, and perform specific actions on the object. The following sections describe the various options available from the ZENworks for Servers 3 management console.

Understanding Console Views

The first console option you should be aware of is console views. Views are basically different ways of looking at information. ZENworks for Servers 3 provides several different views designed to help you efficiently manage and monitor your network resources. The following is a list of the views that you will be using most often to manage your network:

  • Atlas. Provides a graphical representation of the discovered network topology, the physical location of nodes, node configuration, and alarm information. This is the easiest view to use to quickly understand the status of your managed network sites.

  • Console. Displays the objects contained in the selected container object. This is the view to use to navigate the ZENworks for Servers 3 site. It enables you to quickly expand and shrink containers.

  • Trend. Provides a graphical representation of current and historical trend data by hour, day, week, month, or year. Use this view to monitor network trends, which will help you determine who is using the server, which server is used heavily, troubleshoot network problems, determine how to balance loads across multiple servers, and plan strategies for how to deploy new network resources.

  • Active Alarms. Provides a tabular display of alarm statistics for all current alarms received from segments or devices, per management site. Use this view to determine any current network alerts because it is updated whenever a new alarm occurs on the network.

  • Alarm History. Provides a tabular display of all archived alarms, including the handling status of each alarm.

  • Summary. Provides a tabular view about the selected object's current configuration. The summary view for a server object, for example, displays information about NLMs, memory usage, adapters, network interfaces, disks and disk controllers, volumes, queues, users, connections, open files, and alarms, as well as installed software.

ZENworks for Servers 3 provides several other views for specific objects in addition to the main views already listed. If you select a memory object, for example, you can select a Disk Cache view that displays utilization for disk cache memory. Similarly, if you select a connections object, you can display an Open Files view that displays information and statistics for the connections on the server.

Setting ZENworks for Servers 3 Properties

ZENworks for Servers 3 provides property pages as well as views for its objects. The property pages enable you to modify settings for each individual object. They are accessed the same way other properties pages are in ConsoleOne: you right-click them and select Properties. ZENworks for Servers 3 provides property pages at the following levels in its hierarchy:

  • Site level. Enables you to edit global properties, including alarm dispositions, ZENworks for Servers 3 database settings, SNMP settings, MIB pool entries, and health report profiles.

  • Server level. Enables you to modify SNMP settings for the managed server.

Performing Actions on Managed Objects

Another option available on some managed objects in the ZENworks for Servers 3 management console is the capability to perform an action on the object. The following is a list of actions that you can perform on ZENworks for Servers 3 objects:

  • Capture packets to and from the server.

  • Browse the MIB database for the server.

  • Ping the server's DNS name, IP address, or IPX address.

  • Perform a connectivity test on the server.

  • Open a Remote Management Session to load/unload NLMs, mount/dismount Volumes, and so on.

  • Restart the server.

  • Shut down the server.

Managing Console Views

One of the most powerful and important things you should be aware of in the ZENworks for Servers 3 management console is the capability to manage the console views. From the management console, you have different options to manage each view based on which of the following types of view it is:

  • Tabular. Information is organized and displayed in table format. The Console, Active Alarms, and Alarm History are tabular views.

  • Graphical. The Atlas, Trend, and Summary are graphical views. (The Summary view also contains tabular elements.)

The following sections cover the many options available for you to customize and work with the views to provide you with the most up-to-date and easiest-to-read information about your network.

Changing the Appearance of a View

One of the most useful things you should know about console views is how to modify their appearance. Modifying the appearance can help you make the view easier to read. The following sections cover how to use the ZENworks for Servers 3 console to modify the font, add grid lines, and display the view title.

Changing the Display Font

You may want to change the font in a tabular view to be a different size. If, for example, item names are too long and do not fit in your columns or the columns are too wide for your screen, you may want to make the font size smaller. You may also want to make the font larger to make it more readable.

Follow these steps to change the font used to display text on a tabular view's headings or rows:

  1. Click View [image] Settings [image] Appearance. The Appearance dialog box appears.

  2. Select either the Header Font button or the Row Font button. The Fonts dialog box appears.

  3. Select a font from the Font Name list.

  4. If you want the font to be displayed in bold or italic, select the appropriate check box.

  5. Select the font size from the Size drop-down list.

  6. Click the OK button to close the Fonts dialog box.

  7. Click the OK button to close the Appearance dialog box.

  8. If you want to save the changes you've made to the view, click View [image] Save.
Customizing Grid Lines

Although the views displayed by ZENworks for Servers 3 do not contain grid lines, by default, you may want to add them to make the view more readable. Follow these steps to display horizontal and/or vertical grid lines:

  1. Click View [image] Settings [image] Appearance. The Appearance dialog box appears.

  2. Select one of the following grid line styles from the Style drop-down list: No Grid Lines (default), Horizontal Grid Lines Only, Vertical Grid Lines Only, or Vertical and Horizontal Lines.

  3. If you want to select a color for the grid lines, click the Color button.

  4. Select the color you want to use for the grid lines by using one of the three tab pages; then click OK to close the Color Chooser dialog box.

  5. Click OK to close the Appearance dialog box.

  6. If you want to save the changes you've made to the view, click View [image] Save.
Displaying the View Title

You may want to display the view name in the frame of your current window in ConsoleOne to help you keep track of where you are within the ZENworks for Servers 3 management console. To display the view title, Click View [image] Show View Title.

Modifying Columns in Tabular View

Another modification you may want to make to a tabular view is to modify its columns to make it more readable or fit more data in. The following are operations you can perform on the columns in a tabular view.

Resizing a Column

To resize a column, follow these steps:

  1. Move the mouse pointer to the margin between the columns you want to adjust.

  2. When the pointer changes to a sizing arrow, click and drag the column to the width you want.

  3. If you want to save the changes you've made, click View [image] Save.
Adding and Removing Columns

To add or remove columns, follow these steps:

  1. Click View [image] Settings [image] Column Selector.

  2. To add a column, select the column name from the Available Fields list and click the Add button.

  3. To remove a column, select the column name from the Show These Fields in This Order list and click the Remove button.

  4. Click OK.

  5. If you want to save the changes you've made to the view, click View [image] Save.
Changing the Column Order

To change the column order, follow these steps:

  1. Click View [image] Settings [image] Column Selector.

  2. Select the column you want to move from the Show These Fields in This Order lists and click the Move Up or Move Down button to change the location of the column.

  3. Click OK.

  4. If you want to save the changes you've made to the view, click View [image] Save.
Limiting Views with Filters

An extremely useful way to manage a tabular view is to filter the entries to limit the amount of information displayed. You can set up simple filters by selecting a single criterion or more complex filters by using several criteria and logical relationships as filters.

Follow these steps to set up a filter to limit entries in a tabular view:

  1. Select View [image] Settings [image] Filter.

  2. Select the column by which you want to filter alarms from the first drop-down list.

  3. Select an operator from the second drop-down list. The operator defines how to constrain the column you've selected to a value—for example, equal to, not equal to, greater than, less than, greater than or equal to, less than or equal to, contain, or starts with.

  4. Select a value for the logical operation set in the previous step.

  5. Specify how this filter statement relates to other statements you plan to define by selecting one of the values listed in the fourth drop-down list, described in the following bulleted list.

  6. Click OK when you are finished adding filter statements, and the entries in the view will be filtered according to your criteria.

The following is a list of values that can be used to describe the relationships between different filters for views:

  • End. Last statement.

  • New Row. Adds a new line and you must define a logical relationship between the previous line and the new line.

  • Delete Row. Removes the current filter row from the filter, enabling you to remove unwanted filters without starting over.

  • And. In the case of a filter statement, both filter statements must be met. In the case of a group of filter statements, the filter statements in both groups must be met.

  • Or. In the case of a filter statement, at least one of the filter statements must be met. In the case of a group of filter statements, the filter statements in at least one of the groups must be met.

  • New Group. Begins a new group and a new line that is separated from the rest by an additional drop-down list.

NOTE

Filters apply to the current management session only. When you exit the management console, the filters will be cleared.

Sorting Views

Another useful way to manage a tabular view is to sort the entries. Sorting the entries can be very useful to organize the data obtained from the view.

You can sort the entries based on a single column by simply double-clicking the header of the column you want to use. Double-clicking once sorts the entries in descending order, with the most recent entries first. Double-clicking again sorts the entries in ascending order, with the oldest entries first.

You can also sort a view based on multiple columns by following these steps:

  1. Click View [image] Settings [image] Sort.

  2. Select the first column by which you want the entries sorted from the Sort Items By field.

  3. Indicate whether you want the entries sorted in ascending or descending order.

  4. Select the second column by which you want entries sorted from the Then By field, and then select the ascending or descending sort order.

  5. Repeat Step 4 for each subsequent column for which you want entries sorted.

  6. Click OK to finish and the entries are sorted based on your criteria.
Exporting a View

At any time, you can export a view to a more useful format. This can be useful to put the information on an internal Web site, to store it in a database, or to use it in a document. The following is a list of formats to which ZENworks for Servers 3 views can be exported if you select File [image] Export in ConsoleOne:

  • HTML

  • Comma-delimited .CVS file

  • Tab-delimited text

  • Blank-space-delimited text

Managing Custom Views

ZENworks for Servers 3 enables you to save and use any customizations that you may have done to views. You should customize ZENworks for Servers 3 views to meet your networks needs and organize them by using the steps in the following sections.

Saving a View

At any time, you can save the changes that you have made to a view by selecting the view you want to save and selecting View [image] Saving [image] Save from the main menu. You can also save the view to a different name by selecting View [image] Saving [image] Save As and entering a descriptive name.

Deleting/Renaming Customized Views

If you save several views, you may need to delete some or at least rename them to make view management more structured and easier to understand. Follow these steps to either delete or rename a view in ConsoleOne:

  1. Click View [image] Saving [image] Edit Saved Views.

  2. To rename a custom view, select it from the list and click the Rename button.

  3. To delete a custom view, select it from the list and click the Delete button.

  4. When you are finished managing the custom views, click the Close button.


Planning Your Network Management Services

After you understand the components that make up ZENworks for Servers 3 management services and the console used to manage them, you are ready to begin planning a strategy to configure your network to get the most out of ZENworks for Servers 3. This section covers the steps necessary to understand, plan, and configure your network to maximize the benefits of ZENworks for Servers 3 management services.

Defining Management Groups and Needs

The first step you should take in planning for network management is to define what management groups and needs exist in your network. Virtually all organizations are made up of individual groups, each of which requires its own specific information to function. ZENworks for Servers 3 is flexible enough to fit the business needs of each of the groups if you plan your management strategy correctly.

The first step in defining management groups and needs is to identify the individual groups in your organization. These groups should be organized according to management need types. Look for things such as network resources required, management needs, department location, and so forth.

After you identify the groups that require access to network information, you should begin to define the needs each group has. Determine specifically what information they require, how often they access it, and at what times they access it. For example, group servers that require around-the-clock monitoring for critical services into a single group and servers that are used to compile and generate monthly statistical reports into another group.

Planning Your Network Management Strategy

After you define your management groups and needs, you are ready to plan a network management strategy. Your network management strategy should focus on configuring ZENworks for Servers 3 management to provide an appropriate level of monitoring for your network with a minimal impact on network performance. This may sound complicated; however, it is really only a matter of organizing the groups you created in the previous step into one of the following categories, and then configuring an appropriate polling frequency for each category:

  • Mission Critical. Segments and network devices that need to be actively monitored to ensure high availability. Monitoring on these groups should be set at a high polling frequency.

  • Crucial. Segments and network devices that need to be actively monitored for availability and usage, or groups that host services that require a balance between polling and network performance. Monitoring on these groups can be set from a few minutes to a few days depending on individual needs.

  • Common. Segments and network devices that do not need to be actively monitored. Monitoring on these groups should be set to poll infrequently, or can be done manually at the administrator's request.

NOTE

Devices that are not polled or are polled infrequently can and should be configured to send alarms to the management server. This ensures that you are notified in the event a critical error occurs on the system; however, your network will not incur a performance hit from active polling.

Configuring Your Network

After you define your network group's needs and plan your network management strategy, you should configure your network for optimal discovery and monitoring. ZENworks for Servers 3 management services rely on standard network protocols to monitor and manage devices on your network. The following sections discuss important considerations to ensure that your network channels are consistent and well configured.

Considerations for IP Addressing

ZENworks for Servers 3 aggressively searches for IP addresses during the discovery process. The following is a list of considerations that you should check for devices you want to be discovered and managed by IP addresses:

  • The device must have a valid IP address.

  • TCP/IP must be bound on the designated management console workstations.

  • IP must be bound on the management server.

  • A static IP address must be assigned to the management server.

  • You must verify that a router's addresses are defined in either its management information base (MIB) or seed router table.

  • Routers must have static IP addresses.

  • Verify that the subnet mask configurations on all IP networks are correct.

NOTE

If a subnet mask is too restrictive, you may not be able to discover all the devices in your management site. The discovery process does not support noncontiguous subnet masks, such as 255.255.0.255.

Identifying IPX Transports

After you verify your IP addressing, look for any software that needs to communicate over IPX. After identifying the IPX transport software, verify that it is configured with an IPX/SPX-compatible transport protocol.

NOTE

ZENworks for Servers 3 is fully compatible with the Novell IP compatibility mode driver.

Using IPX Software for NDS and DNS Names Resolution

After you verify your IPX software, check and set up NDS and DNS names for your network devices. ZENworks for Servers 3 uses the server name or hostname instead of the IP or IPX addresses to display maps and configuration views. Set up the most important devices with NDS and DNS names, because they are much easier to understand than network addresses. Name resolution can be in the form of local host files, NDS objects, or bindery tables.

Defining Community Names for SNMP Configuration

After setting up your NDS and DNS names, define the community names for your SNMP configuration. SNMP agents and RMON agents, as well as SNMP-enabled devices, require a community name to be identified. You need to configure each SNMP-enabled device with a community name and trap target destination that includes the ZENworks for Servers 3 management server.

The community name secures communication channels between the manager and the agent from intruders. The names are set to "public" by default; however, you should change the names to something else to prevent outside intruders from accessing information and modifying your system configurations.

Defining Administration Roles

After you configure your network for ZENworks for Servers 3 management, you must define roles that will be used to administer it. You can assign administrators specific, defined roles for your organization, which enables youcompromising network security.

The first step is to define the individuals who will be administering your network. After you have that list of individuals, you should define a scope for each one based on his or her specific access needs. After administrators and their scopes have been defined, they can log in and have access to the specific management components that they need to perform their tasks.

The following sections discuss different types of management roles within an organization.

Understanding the ZENworks for Servers 3 Management Site

The management role you should use most frequently is the management site administrator. The ZENworks for Servers 3 management site sets boundaries for access to object data through role-based services. You create roles and tasks that utilize management functions of ZENworks for Servers 3 in the network container space. This defines the level of access to network objects and information.

You need to develop a strategy for creating roles in a management site that reflects your management organization. Use your list of individuals and the scope of their administration needs to plan for roles that manage printers, monitor network traffic, handle alarms, and manage server systems through your network.

NDS user or group objects can be assigned to appropriate roles, thereby acquiring the permissions of the role. The following are the different levels within a role:

  • Roles. Created for the various network management functions in your organization. This simplifies setting permissions and restrictions to management tools and network data.

  • Tasks. Actions performed that utilize components of ZENworks for Servers 3 management servers based on assigned responsibility.

  • Component/modules. A specific tool that provides a network management function. (For more information about the components included with ZENworks for Servers 3 Management Services, see the first section in this chapter.)

Discussing General ZENworks for Servers Roles

After you define the management site roles for your network, take a look at some general roles to cover any individual and management tasks that are not yet covered.

Several predefined roles exist, or you can define a role by creating an RBS role object in NDS and specifying tasks that the role can perform. The tasks are listed in properties of the RBS task objects in NDS.

The following is a list of predefined roles that ZENworks for Servers 3 creates:

  • RBS Admin role. Responsible for defining, creating, and administrating management roles.

  • Segment Administrator role. Responsible for administrating individual segments, such as adding or deleting users.

  • Segment Manager role. Responsible for maintaining individual segments, such as adding new workstations or protocols.

  • Segment Monitor role. Responsible for monitoring network traffic on individual segments.

  • Server Administrator role. Responsible for administrating specific servers, such as for adding or deleting users.

  • Server Manager role. Responsible for maintaining users and applications on specific servers.

  • Server Monitor role. Responsible for monitoring traffic and services on specific servers.

  • Site Database Administrator role. Responsible for creating and maintaining ZENworks for Servers 3 database sites.

The following is a list of tasks that are available to be assigned to role objects:

  • Alarm Manager. Gives a role the appropriate rights and assignments to manage alarms that are raised on a server or segment level.

  • Database Object Editor. Gives a role the appropriate rights and assignments to manage ZENworks database object through the Database Object Editor tool.

  • DB_ADMIN_TOOL. Gives a role the appropriate rights and assignments to create and maintain ZENworks databases.

  • MIB browser. Gives a role the appropriate rights and assignments to view MIB objects through MIB browser.

  • MIB compiler. Gives a role the appropriate rights and assignments to modify and recompile MIBs by using MIB compiler.

  • Node management. Gives a role the appropriate rights and assignments to manage individual nodes on a segment.

  • Remote ping. Gives a role the appropriate rights and assignments to ping nodes on the network remotely.

  • Traffic management. Gives a role the appropriate rights and assignments to monitor traffic on a server or segment level.

  • Unified View. Gives a role the appropriate rights and assignments to gain access to the unified view for full network administration.

  • ZfS maps. Gives a role the appropriate rights and assignments to gain access to the ZfS maps for a complete graphical view of the network.


Chapter 9. Preparing and Using ZENworks for Servers 3 Network Discovery

Network discovery is one of the first things that must occur before you can begin managing your network by using ZENworks for Servers 3. The manageable devices on the network must be found and stored in the ZENworks for Servers 3 database before they can be configured and managed through ZENworks for Servers 3. This chapter discusses the discovery process and how to set it up on your network to provide you with the best topology maps that you can use to manage your network.


Understanding Network Discovery

Network discovery is the process that ZENworks for Servers 3 uses to scan your network and discern its topology. This section discusses the specific components that are involved in network discovery, the process they use to discover your network topology, and the types of devices that are discovered.

Understanding the Discovery Components

To understand network discovery, you need to understand the discovery components that are running on the ZENworks for Servers 3 management servers. The discovery components are responsible for scanning your network for devices, collecting data, and transferring that data to NetExplorer.

NetExplorer is the main network discovery module. It is responsible for coordinating the discovery components and collecting their data, which is consolidated into a database where it can be managed and used.

The following sections discuss the main discovery components that make up network discovery: the discovery software, the consolidator software, and the Atlas Manager.

About the Discovery Software

The discovery software is software that resides on the ZENworks management server. The discovery software is responsible for polling the network and collecting data about devices that exist on the network. The data collected by the discovery software is stored in the SYS:\SYSTEM\NETXPLOR.DAT file.

The discovery software comprises the following NLMs that run on the discovery server:

  • NXPIP.NLM. Responsible for discovering IP routers on IP networks and sending IP router information to the discovery. It communicates directly with IPCACHE and indirectly with IPGROPER, which are other discovery modules running on the server, to obtain information.

  • NXPIPX.NLM. Responsible for discovering various NetWare systems on IPX networks and sending information about systems to NetExplorer.

  • IPGROPER.NLM. Responsible for detecting IP host addresses and services on an IP network, including DHCP services, DNS names, HTTP, SMTP, FTP, SMTP, and Telnet.

  • NXPLANZ.NLM. Responsible for communicating with traffic analysis agents for NetWare and NT to gather information about all systems communicating on their segments.

NOTE

ZENworks for Servers 3 discovery software uses its server and traffic management agents to obtain discovery information. You should use these agents throughout your network to improve the speed, reliability, and accuracy of the topology maps.

The server management and traffic analysis agents for NetWare use the Service Advertising Protocol (SAP) to identify themselves to other components. To enable the network discovery component to receive the SAP packets that identify manageable devices on the network, configure your routers so that they are not filtering out the needed SAP packets. Use Table 9.1 to configure your routers.

Table 9.1. SAP Numbers for ZENworks Management Devices

COMPONENT

SAP (DECIMAL)

SAP (HEXADECIMAL)

NetExplorer

567

237

NetWare Management Agent

635

27B

NT Management Agent

651

28B

Traffic Analysis Agent

570

23A

Print server

7

7

NetWare server

4

4

Understanding the Consolidator Software

Like the discovery software, the consolidator software resides on the ZENworks for Servers 3 management server. The consolidator takes the information that is collected by the discovery software, cleans it up, and stores it in the ZENworks for Servers 3 database for later use.

The following is a list of tasks performed by the consolidator to collect network information and store it in the ZENworks for Servers 3 database:

  • Reads the NETXPLOR.DAT file

  • Interprets the records in the NETXPLOR.DAT file

  • Verifies that the device is not already discovered

  • Queries the bridge management information base (MIB) on IP networks to discover the MAC addresses of all systems on a port

  • Uses the SN3 agent to get the NDS name for network objects

  • Determines whether additional attributes exist in the discovered device

  • Writes the consolidated information to the ZENworks database

Discussing the Atlas Manager

The Atlas Manager consists of components that exist both on a server and a client. These components are responsible for reading the ZENworks for Servers 3 database, creating a topology database, and enabling a user to browse and manage the network topology.

The server component runs on the ZENworks for Servers 3 management server, where it retrieves discovery information from the ZENworks for Servers 3 database. It then uses that information to create a topology database.

After the topology database is created, the client component of the Atlas Manager can communicate with the Atlas Manager server component. The client component requests topology information from the server component to display topology maps at the client management console. When a user modifies the topology from the client management console, the client component transfers those changes to the server component. The server component then makes the appropriate changes to the topology database.

NOTE

For changes made to the network topology from the client to take effect, you must save the database.

Examining Related Components

Other components exist that are not directly discovery components, but are used during the discovery process. The following are components that NXPIP.NLM, NXPIPX.NLM, and NXPLANZ.NLM use during the discovery process to obtain a full network topology:

  • Traffic analysis agent. The traffic analysis agent discovers all devices on the segments that it is monitoring. The NXPLANZ component uses SNMP to query servers running the traffic analysis agent about the devices on their segments.

  • Server management agent. The server management agents respond to SNMP queries from the NXPIPX component. They provide NXPIPX with usernames and addresses of the workstations that are attached or logged in to them.

  • NetWare Servers. NetWare Servers have internal routing tables stored in their memory. The NXPIPX components query NetWare servers for the information in those tables.

Introducing the Database Object Editor

ZENworks for Servers 3 provides a Database Object Editor (DOE) to supplement the discovery system. Discovery cannot always discover every entity on your network, or it might display incorrect information about some of the entities on your network. The DOE enables you to add the missing entities into the database or edit incorrect information of the entities.

Understanding the Discovery Process

Now that you understand the components that make up network discovery, you need to understand the process that they go through to query your network, collect data about manageable devices, and build a database.

Network discovery occurs in cycles. Each cycle is the process by which one of the discovery modules identifies every device possible, one time. The initial cycle is the first cycle that discovery makes. Although the initial cycle is enough to begin building a topology map, it usually takes several passes to complete the entire network topology.

During the initial discovery cycle, the discovery modules run sequentially; however, after the initial pass, they run independent of each other. The time it takes each module to complete a cycle varies depending on the number of new devices it discovers. When new information is discovered, the discovery modules transfer the data to the NetExplorer, which stores it in a file. Each cycle has the potential to provide the key information NetExplorer needs to identify the device and add it to the database.

The following sections discuss the discovery cycles for each of the discovery modules.

NXPIP

The first sequence in the NetExplorer discovery cycle involves the discovery of IP routers. NXPIP locates its local router by using TCP/IP configuration information and then queries the router for the identity of other routers on the network. NXPIP then queries the MIBs on those routers and collects the IP addresses, interface types, and MAC addresses.

NXPIPX

The NXPIPX discovery begins after NXPIP has completed its first cycle. NXPIPX discovery begins at the management server and uses SNMP, RIP, IPX, and SPX diagnostics to discover attached IPX devices.

NXPIPX begins by examining its own server's routing table and discovers the names of other servers. It then queries each of those servers and repeats the process until no new servers are found.

NXPIPX also reads the connection table of each NetWare server to determine which NetWare clients are logged in to which servers. NXPIPX sends IPX diagnostics packets to the clients to collect additional information about them. NXPIPX also discovers IPX routers in your network.

NOTE

If your clients have IPX diagnostics turned off, they will not be discovered.

NXPLANZ

NXPLANZ begins querying after NXPIPX has completed its first cycle. NXPLANZ obtains a list of all traffic analysis agents from NXPIPX and then uses SNMP to query all servers with the traffic analysis agents loaded. It reads the list of workstations that those servers have observed communicating on the network.

NOTE

At least one server per network segment should be running the traffic analysis agent for the discovery to be complete.

SNMP Community Name

NetExplorer uses the configured community names from NXPCON each time it attempts to access a system by using SNMP. When it encounters a new system, it runs through the list of names configured in NXPCON until it receives a successful response. After the community name is found, it is stored for later reference.

Understanding What Is Discovered

Now that you understand the process that ZENworks for Servers 3 uses to discover devices on your network, you may want to know what types of devices are being discovered. The devices that are discovered by ZENworks for Servers 3 can be categorized into either network systems or network segments. The following sections discuss the devices that are discovered by ZENworks for Servers 3.

Network Systems

The first category of device that the ZENworks for Servers 3 discovery process detects is network systems. Network systems are manageable devices with addresses and/or services associated with them. Network discovery queries the network by using addressing and service requests to find these devices.

The following is a list of network systems that are discovered by ZENworks for Servers 3:

  • NetWare file server. Service type 4. Discovered by NXPIPX.

  • IPX router. Systems with more than one LAN adapter connected to different IPX networks.

  • IP router. System that is configured as an IP router.

  • NetWare print server. Service type 7.

  • NetWare client workstation. Systems that respond to IPX diagnostic requests as IPX workstations.

  • SFT III engines. Discovered by the NXPIPX discovery module. Provides diagnostic information.

  • NetWare Management Agent. Service type 563.

  • NetWare LANalyzer Agent. Service type 570.

  • NetWare Management Agent for NT. Service type 651.

  • Network printers. Discovered if the printer generates a known service type.

  • NetWare Connect. Service type 590.

  • NetWare communications server. Used by NetWare for SAA management products. Service type 304.

  • Management server. Server running discovery modules. Service type 567.

  • Other systems. Any systems that are connected on a segment that is being monitored by the traffic analysis agent.

Network Segments

The other category of device that the ZENworks for Servers 3 discovery process detects on your network is network segments. Network segments are the communication framework that lies underneath the network systems. The network systems use this framework to communicate with each other. Network discovery detects the different network segment topologies and stores that information in the database. The following sections discuss the different types of network segments that are discovered by ZENworks for Servers 3.

LAN and WAN Segments

ZENworks for Servers 3 discovers the typical LAN and WAN segments on your network, provided that they respond with an interface type from the MIB-II RFC 1573 specification. The following is a list of segments that are known by the ZENworks for Servers 3 database:

  • ATM. ATM

  • FDDI. LAN

  • Ethernet. LAN

  • Token ring. LAN

  • X.25. WAN

  • PPP. WAN

  • Frame_Relay. WAN

Source-Route Bridged Token Rings

ZENworks for Servers 3 network discovery also finds source-route bridged token ring segments. How well these segments are discovered and how they appear in your topology map depends on where traffic analysis agents are installed on each of the bridged rings.

NOTE

We suggest that you have the traffic analysis agent loaded on at least one NetWare server on each of your bridged rings to provide you with the best discovery and manageability through ZENworks for Servers.

Transparent Bridges

Network discovery is unable to fully discover transparent bridges. Therefore, because they have the same network number, it consolidates groups of transparently bridged segments into a single segment on the topology maps.

Configuration Changes

Network discovery can detect most changes in your network topology and relay those changes to the Atlas. But if you remove a device from the network, discovery does not detect the removed device unless it is moved to another location in the network.


Using Network Discovery

Now that you understand the ZENworks for Servers 3 network discovery process, you are ready to begin using it to build a topology database from which you can manage and configure your network.

Configuring and using discovery correctly can improve network bandwidth and make administration much easier. This section covers how to start and stop the network discovery, how to monitor its progress, and how to configure it to correctly discover your network.

Starting and Stopping Network Discovery

The first thing you should know about setting up network discovery is how to start it manually, as well as how to stop it. During the installation, you are prompted whether to start the autodiscovery and back-end services. If you select yes to those prompts, Network Discovery automatically launches.

To start the network discovery process and load the back-end services on a server, follow these steps:

  1. Start the ZENworks for Servers 3 database by entering the mgmtdbs command at the ZENworks management server console. This command runs the mgmtdbs.ncf file to load the Sybase database engine and the database.

  2. Start the rest of the needed ZENworks for Servers processes by entering the mwserver command at the server console.

  3. Start the autodiscovery process by entering the netxplor command at the ZENworks management server console. This command runs the netxplor.ncf file, which loads all the discovery modules.

  4. Finally, start the basic services on the ZENworks management server by entering the sloader command at the console. This command runs the sloader.ncf file.

The discovery process runs 24 hours a day while it is loaded. The time required to run the initial discovery and build a complete database of your network varies depending on the size of your network and the load placed on your ZENworks for Servers 3 management server.

NOTE

The ZENworks for Servers 3 network discovery process occurs in the background on your server. If your server is being heavily used, it takes considerably longer for the network discovery to finish. We suggest that you schedule your network discovery to occur during nonpeak hours—over a weekend, for example.

After the management server is up and running, you can start and stop the discovery process by using the following two commands and the ZENworks for Servers 3 management server console:

  • unxp. An NCF file that unloads the discovery files and halts the discovery process.

  • netxplor. An NCF file that reloads the discovery files, creates a new version of NETXPLOR.DAT, begins the initial discovery process, and processes the discovery data.

Checking the Status of the Initial Discovery

After the network discovery process is running, an initial discovery is started. This can take a long time, depending on the size of your network. When the initial discovery is completed, your topology maps in the management console reflect the discovered devices while discovery progresses. You must, however, wait for the initial discovery to complete before the topology maps are updated.

The easiest way to determine whether the initial discovery is complete is to use the NXPCON utility on the management server to look at the status of each NetExplorer module. Each module must complete at least one full cycle to complete the initial discovery and draw a complete network map. The following is a list of modules that can be configured to run during discovery:

  • NXPIP

  • NXPIPX

  • NXPLANZ

To view the discovery status, look at the following information displayed on the NetExplorer Console screen, shown in Figure 9.1:

  • NetExplorer Up Time. Shows the time since the network discovery started running (in the figure, this is just shown as Up Time).

  • NetExplorer System Status. Shows the overall status of network discovery. If the initial discovery process is still running on at least one module, the value is Initial Cycle in Progress. If the initial discovery process is complete on all modules, the value is Initial Cycle Complete. (In the figure, the value for this item is 1 Cycle Completed.)

  • Module Status. Shows the status of each module and the number of cycles each module has completed. In the figure, note the status listed for NXPIP, NCPIPX, and NCPLANZ.

Figure 9.1. Network discovery status on the NetExplorer Console screen.

The following is a list of the different statuses that each module can show and what they mean:

  • Not Loaded. The module is not loaded. This usually means that this service is not configured for discovery.

  • Waiting to Start. Module is loaded, but it is waiting for another module to complete a cycle before it starts.

  • Running. Module is currently running and collecting network data.

  • Suspended. Module is suspended because it reached the end of the schedule in which it was running.

  • Completed. Module completed at least one discovery cycle.

  • Unknown. NetExplorer cannot obtain the module status. This is either because the module is not loaded, but is configured to run, or because of an internal error inside the module.

Changing the Default Configuration

The ZENworks for Servers 3 network discovery software is installed with configuration defaults that are designed to work in most network environments. You may, however, want to modify the default configuration to discover more or fewer devices in your network.

To change the default network discovery configuration, you need to use the NXPCON utility on the ZENworks for Servers 3 management server. The NXPCON utility is automatically loaded when the NetExplorer software is loaded, or you can load it manually by using the following command at the ZENworks for Servers 3 management server console prompt:

load nxpcon

The following sections describe how you can use the NXPCON utility to choose which discovery modules are loaded, how to change SNMP names, and how to modify the discovery scope to help you optimize the discovery process for your network, and how to ensure workstation discovery.

Choosing Which Modules to Load

After the NXPCON utility is loaded, you can modify which modules are being loaded. If you choose to not load a module, the network discovery is limited to the remaining modules being loaded.

Use the following steps in the NXPCON utility to modify which modules are loaded for network discovery:

  1. Select Configuration Options [image] Discovery Modules.

  2. Select the module you want to modify from the Discovery Modules menu, shown in Figure 9.2, and then press the Enter key.

    Figure 9.2. Network discovery module setting in the NetExplorer Console screen.

  3. Select No to unload the module or Yes to load the module, and then press Enter.

  4. Press the Esc key to exit the NetExplorer Modules dialog box.

  5. Select Yes.

  6. Unload the NetExplorer software by entering unxp at the ZENworks for Servers 3 management server's console prompt.

  7. Reload the NetExplorer software by entering netxplor and the changes to network discovery are made.
Changing SNMP Community Names

After selecting which modules to load, you may want to change some of the SNMP community names. ZENworks for Servers 3 automatically uses the community name of Public by default. If your network uses SNMP names other than Public, you should reconfigure the SNMP names in NXPCON to ensure your network maintains the proper security.

To view, add, modify, or delete SNMP configuration information from within the NXPCON utility, follow these steps:

  1. Select Configuration Options [image] SNMP.

  2. Select Edit Community Name List in the SNMP dialog box, shown in Figure 9.3.

    Figure 9.3. Network discovery SNMP options dialog box in the NetExplorer Console screen.

  3. Select Insert to add a community name, Delete to delete the highlighted community name, or just press the Enter key to modify the highlighted community name.

  4. Press the Esc key to exit from the SNMP dialog box.

  5. Select Configuration Options [image] Activate Changes to update the ZENworks for Servers database.
Changing the Discovery Scope

After you modify your SNMP community names appropriately, you can change the scope of the network discovery. NXPCON is set to discover all IPX and IP networks by default. But if your network is extremely large, you may want to limit the scope of discovery for the following reasons:

  • Reduce network traffic. Limiting the scope of discovery limits the number of discovery and management packets being sent on your network.

  • Speed up discovery. Limiting the scope of discovery also speeds up the discovery process by skipping addresses that are not wanted.

  • Simplify manageability. Limiting the scope of discovery limits the number of objects discovered and thereby reduces the number of objects that appear in the Atlas view. This can make it much easier to navigate the atlas.

The following two sections discuss how to use the NXPCON utility to modify the network discovery scope.

Changing the IP Discovery Scope

The NXPCON utility enables you to limit the IP discovery scope by address and subnet mask filters. Using these filters enables you to discover only certain segments or addresses.

If you wanted to restrict the discovery scope to your local IP network, for example, you could set a limit to the IP address of your local network and a subnet mask that you want to use. The mask indicates which part of the addresses needs to match for discovery to proceed on a network segment. The number 0 indicates that no match is required. If your local network IP address were 1.1.x.x, you would use the IP address of 1.1.0.0 and a mask of 255.255.0.0 to capture everything on your local network, but nothing else.

Use the following steps in NXPCON utility to limit the scope of IP discovery:

  1. Select Configuration Options [image] Discovery Scope.

  2. Select IP Discovery Scope.

  3. Press the Insert key to add a new IP discovery scope entry, press the Enter key to modify the highlighted scope entry, or press the Delete key to delete the highlighted scope entry.

  4. Enter the address and mask for your discovery, as shown in Figure 9.4.

    Figure 9.4. Network discovery IP mask dialog box in the NetExplorer Console screen.

  5. Press the Esc key and select Yes to save the changes to the configuration file.

  6. Press the Esc key to exit the Discovery Scope dialog box.

  7. Unload the NetExplorer software by typing unxp at the console prompt.

  8. Reload the NetExplorer software by typing netxplor at the console prompt, and the changes will take effect.
Changing the IPX Discovery Scope

The NXPCON utility enables you to limit the IPX discovery scope by network number and mask filters. Using these filters enables you to discover only certain segments or addresses. A zero in the filter indicates that no match is required.

For example, if you use a specific IPX address on your servers of 1111xxxx, you could limit the scope of your IPX discovery to include only your IPX servers by using the network number of 11110000 and a mask of FFFF0000. Discovery would then pick up only IPX devices whose network number started with 1111.

Use the following steps in the NXPCON utility to limit the scope of IPX discovery:

  1. Select Configuration Options [image] Discovery Scope.

  2. Select IPX Discovery Scope.

  3. Press the Insert key to add a new IPX discovery scope entry, press the Enter key to modify the highlighted scope entry, or press the Delete key to delete the highlighted scope entry.

  4. Enter the network number and mask for your discovery, as shown in Figure 9.5.

    Figure 9.5. Network discovery IPX mask dialog box in the NetExplorer Console screen.

  5. Press the Esc key and select Yes to save the changes to the configuration file.

  6. Press the Esc key to exit the Discovery Scope dialog box.

  7. Unload the NetExplorer software by typing unxp at the console prompt.

  8. Reload the NetExplorer software by typing netxplor at the console prompt and the changes will take effect.
Ensuring Workstation Discovery

After you verify your IPX scopes in the NXPCON utility, you may want to ensure that your IPX workstations will be discovered properly. IPX workstations are discovered with a username if the user is logged in to or attached to a NetWare server that is running the management agent software. To ensure that your workstations are properly discovered, ensure that the management agent is installed on all NetWare servers that have users attached.

Checking the Results of a Network Discovery

You can check the results of the network discovery after the initial discovery is completed and after the ZENworks for Servers 3 database has been updated. You should always check your network atlas to determine whether your network topology was accurately discovered.

Your network atlas should have discovered all the servers, desktops, switches, and routers on your network for which you configured it. For each object that is discovered, the following characteristics are captured:

  • IP type. IP router, IP host, IP service (HTTP, Telnet, SMTP, DNS, FTP, and DHCP)

  • IPX type. IPX workstation, IPX router, IPX service (file, print, any SAP service)

  • Subnet mask. Subnet mask used on each segment

  • NetWare services. Services such as SAP, NCP, and so on

  • eDirectory names and tree. Full distinguished name of nodes on the network, including the tree

If a node is not on your network atlas, you should check the following things about the device:

  • Is the device a type that NetExplorer can discover?

  • Is the node in the incorrect segment? If NetExplorer cannot get enough information about a node, it may simply have been placed in the wrong segment.

  • Is NetExplorer configured to capture this type of device?


Using the Atlas

After the initial discovery process is complete, you can access the data it collects through the Atlas Manager. The Atlas Manager server component reads the database created by network discovery. It then relays that information to the management console user at the client workstation.

From the client workstation, you can navigate through your network graphically, as shown in Figure 9.6. The following sections discuss using the Atlas to view your discovered network topology.

Figure 9.6. Graphical Atlas view of a network in ConsoleOne.

Accessing the Atlas

You must use the ConsoleOne utility to access the ZENworks for Servers 3 Network Atlas. The Network Atlas view is a plug-in service to ConsoleOne that gets installed during the ZENworks for Servers 3 installation.

To access the Atlas from within ConsoleOne, follow these steps:

  1. Double-click the ZENworks for Servers 3 domain. Your ZENworks for Servers 3 management sites should appear.

  2. Select the management site you want to view. If the Atlas Manager is running on that management server, the Atlas shows up underneath it.

  3. Select the Atlas.

  4. Right-click the Atlas icon and select Atlas view from the pop-up menu. A screen similar to the one in Figure 9.7 should appear.

    Figure 9.7. Atlas view of a network in ConsoleOne.

The initial Atlas screen should show you three types of objects, each of which is its own separate Atlas page. These pages represent different views for you to use to see and navigate your network topology. The following list describes the different views you see in each of the three pages:

  • WAN page. Summarizes the entire network by showing the WAN-related network topology. There is usually only one WAN page per network.

  • Area page. Displays the segments on your network. There can be several Area pages on your network, depending on your network configuration, as shown in Figure 9.7.

  • Island page. Displays segments with an undetermined connectivity. During discovery, the Island page is a placeholder for network objects that are not completely discovered. When enough information is obtained about the object, it is moved to an Area or WAN page. There is only one Island page per network.

ZENworks for Servers 3 enables you to perform the following tasks on any of the Atlas pages:

  • Open. Opens the Atlas page in the view window.

  • Import. Enables you to insert a wallpaper background for the Atlas view. For example, you could use the USA.GIF provided with ZENworks for Servers 3 to display a map of the U.S. behind your WAN view so that you could place your routers and servers on the states that they reside in.

  • Save. Enables you to save your custom settings for the Atlas view to be used later.

  • Print. Enables you to print the Atlas view. This feature is extremely useful if you need to take a physical copy of the layout to a planning meeting.

  • Rename. Enables you to rename the Atlas view to something else. Use names that are as descriptive as possible; you might, for example, use a city name for a router that covers a specific city or a department name for a segment that contains an entire department.

  • Layout. Changes the focal point and redisplays the page. This is useful if you need to reset the view.

Assigning Management Roles to the Atlas

ZENworks for Servers 3 enables you to assign roles to manage the Atlas, which gives you tighter control over management operations. When you assign a role, you can restrict which operations an operator can perform when managing objects.

You could, for example, restrict a role to a specific segment of the Atlas. Then, when a user accesses the Atlas, the only segment that they can view or manage is that segment. Another example is to restrict a role to adding objects. Anyone using that role can add objects to the Atlas, but not delete them.

Using Unified Views

ZENworks for Servers 3 provides a Unified view service that acts as a filter on an Atlas. The Unified view enables you to filter the Atlas based on devices or segments of a particular type. This enables you to easily navigate the Atlas and perform quick operations to check the highest severity of the alarms present in a particular node.

The ZENworks for Servers Unified view service runs on the server and must be running to get the data in the view. Use the SMGRUI command at the server console to start and stop the service on the server side. The following sections describe how to use the views after the service is started.

Unified View for Devices

The Unified view for devices view enables you to filter on all manageable or unmanageable devices in the view. This view also displays the MIBs implemented by the device as well as the maximum severity of the alarms against the devices. The following is a list of devices on which you can filter from the Unified view:

  • All (all devices and services)

  • Netware Servers

  • Windows NT/2000 Servers

  • IP routers

  • IPX routers

  • Switches/bridges

  • NCP print servers

  • Printers

  • TCP services

To filter on specific devices, follow these steps:

  1. Right-click the Atlas and select View [image] Unified view for devices.

  2. From the first drop-down list, select All to list all the devices, select Manageable to list the manageable devices, or select Unmanageable to list the unmanageable devices.

  3. From the second drop-down list, select a device.

  4. Click the Show button.
Unified View for Segments

The Unified view for segments view enables you to filter on all manageable or unmanageable segments in the view. This view displays the name of the segments as well as the maximum severity of the alarms against the segments. The following is a list of segment types on which you can filter in the Unified view:

  • All (all types of segments)

  • Ethernet

  • FDDI

  • Token Ring

  • Frame Relay

  • X.25

  • ATM

  • PPP

  • IPX Compatibility Type

To filter on specific segments, follow these steps:

  1. Right-click the Atlas and select View [image] Unified view for segments.

  2. From the first drop-down list, select All to list all the segments, select Manageable to list the manageable segments, or select Unmanageable to list the unmanageable segments.

  3. Select a segment from the second drop-down list.

  4. Click the Show button.
Updating the UNIFIEDVIEW.INI File

ZENworks for Servers 3 enables you to specify your own segment or device types that you want to view in a Unified view. The UNIFIEDVIEW.INI file located in the <vol>:\ZENWORKS\mms\MWServer\bin\ directory on the server contains details of all the segments and the devices. You can optimize the information that you get from this view by editing this file.

To add a new segment or device type to the unified view, follow these steps:

  1. Open the unifiedview.ini file in a text editor.

  2. Add a new entry in the file. The header of the file provides the syntax for adding new entries. The section name should begin with Segment_, and you need to define the values for the properties. The device name should begin with Device_, and you need to define the values for the properties.

  3. Save the file.

  4. Restart the service and the changes are implemented.

Using the Atlas to Troubleshoot

After the Atlas is up and running, you can use it to monitor and troubleshoot your network. To use the Atlas to troubleshoot your network, you must set alarms for your network devices. When ZENworks for Servers 3 recognizes a critical, major, or even minor alarm on a segment or node, it displays an Alarm icon above the object in the Atlas view.

Using Atlas Manager Command-Line Options

The Atlas Manager server component is a Java-based utility. Several command-line options enable you to modify the behavior or perform an action on the ZENworks for Servers 3 Atlas database. You can configure command-line options for the Atlas Manager by modifying the Java load statement for the Atlas Manager in the following file on your ZENworks for Servers 3 management server's management volume:

<volume>:ZENWORKS\mms\MWServer\Bin\AtlasMgr.NCF

Table 9.2 displays the available command-line options for the Atlas Manager server component:

Table 9.2. Command-Line Options for the Atlas Manager

OPTION

EFFECT ON ATLAS MANAGER

-no Notifiers

Ignores database notifications and stops notifying consoles. You should use this option to reduce overhead caused by the notifications.

-no Manager

Stops the topology updates from the database. But changes that are made at the console (renaming, adding, or deleting objects) are still updated.

-no cmdServer

Stops the Atlas Manager server component from communicating with the client component running on the management console.

-rebuild

Deletes the existing topology database and then recreates the map.

Using the Database Object Editor

The ZENworks for Servers 3 Database Object Editor (DOE) enables you to perform operations on a segment or on a node object. The DOE server interacts with the consolidator to process information related to the node and segment object, and then populates the CIM table with this information.

The DOE server interacts with the Atlas to process the information related to a page or an Atlas object, and then populates the MAP table. The DOE client uses the ConsoleOne snap-in to display the user interface; therefore user operation is allowed only through the management console view.

Creating a New Segment Using the DOE

The ZENworks for Servers 3 DOE enables you to create your own segments in the Atlas database. This can be extremely useful if you have segments that you need to have in the Atlas, but that are not being discovered. You could also use this to create segments that you plan to add in the future and to create Atlas views for use in planning. The DOE segment editor, shown in Figure 9.8, enables you to enter the following information about the segments you create:

  • Segment Name. The name is displayed in the Atlas Manager.

  • Network Number. The network number that is associated with the segment.

  • Segment Description. A description of the segment: You may, for example, want to include the purpose, location, or other information specific to this segment.

  • Segment Class. The segment class: Ethernet, Token Ring, PPP, Frame Relay, ATM, X.25, or FDDI.

  • Network Class. The class of the network on which the segment is located.

Figure 9.8. Segment Details dialog box for the DOE in ConsoleOne.

To create a new segment by using the DOE from the Atlas Manager, follow these steps:

  1. Right-click the Atlas object in which you want to create the segment.

  2. Select Database Object Editor [image] New [image] Segment from the pop-up menu.

  3. Specify the segment settings in the Segment Details dialog box shown in Figure 9.8.

  4. Click the OK button to create the object.
Creating a New Node Using the DOE

The ZENworks for Servers 3 DOE enables you to create you own node in the Atlas database. This can be extremely useful if you have a workstation or server that you need to have in the Atlas, but that is not being discovered. You could also use this to create nodes that you plan to add in the future and to create Atlas views for use in planning.

The General tab of the DOE node editor, shown in Figure 9.9, enables you to enter the following information about the nodes you create:

  • Node Name (mandatory). The name of the node that appears in the Atlas Manager.

  • Operating System. The operating system installed on the Node.

  • Type of Node. The type of node: Node, Router, or Switch.

  • IP/IPX Router. Selects whether node routes IP, IPX, or both (if the node type is a router).

  • Make. Enables you to specify the make of computer the node.

  • Criticality. Enables you to specify the criticality, from 1%–100%, you want to assign this node.

  • Description. Enables you to enter a description of the node.

  • Node Location. Enables you specify the location of the node to be used.

  • Owner Name. Enables you to specify the person that owns or is responsible for the node. This can be the person who uses the node, a supervisor, the IT person responsible, or so on.

  • Owner Contact. Enables you to specify the contact information for the owner of the node. Usually this is an email address or an office extension.

  • Prevent Deletion. The Prevent Deletion by NetExplorer check box enables you to specify whether NetExplorer will delete the node the next time autodiscovery runs. You should check this box if you are adding a node that will not always be available and you need some specific information in the node object.

Figure 9.9. General tab of the Node Details dialog box for the DOE in ConsoleOne.

The Interfaces tab of the DOE node editor, shown in Figure 9.10, enables you to enter the following information about the nodes you create:

  • Network Address (mandatory). Specifies the logical network address of the node. This is an IP address for IP networks or IPX for IPX networks.

  • MAC Address (mandatory). Specifies the physical MAC address for the network card located in the node.

  • Subnet Mask. Specifies the subnet mask that the node is using to resolve IP.

  • Network Type. Specifies the type of network on which the node is located (IP or IPX).

  • Interface Type. Specifies the interface type that the node's segment is using.

  • Interface Speed. Specifies the speed that the network is running in Mbps.

  • Interface MTU. Specifies the Message Transfer Unit that the network is using in bytes.

  • Interface Summary. After you set the preceding information for the node, you click the Add button and the interface information appears in the Interface Summary list shown in Figure 9.10. You can then add interfaces if necessary.

Figure 9.10. Interfaces tab of the Node Details dialog box for the DOE in ConsoleOne.

The Services tab of the DOE node editor, shown in Figure 9.11, enables you to enter the following information about the nodes you create:

  • List of Services. Specifies a list of services that are available on the node.

  • Switch-Related Information. Enables you to specify information specific to nodes that are of switch type. Click the Add button shown in Figure 9.11 to bring up the Switch Details dialog box. From this window you can specify the port number, MAC address, and node information used for switching. To modify the information for a specific port, select the port in the list and click the Details button to bring up the Switch Details dialog box.

Figure 9.11. Services tab of the Node Details dialog box for the DOE in ConsoleOne.

To create a new node by using the DOE from the Atlas Manager, follow these steps:

  1. Right-click the Atlas object you want to create the node in.

  2. Select Database Object Editor [image] New [image] Node from the pop-up menu.

  3. Specify the node settings in the Node Details dialog box shown in Figures 9.9, 9.10, and 9.11.

  4. Click the OK button to create the object.


Chapter 10. Using ZENworks for Servers 3 Traffic Analysis

ZENworks for Servers 3 includes LAN traffic analysis tools that help you monitor your LAN traffic, capture traffic data, and collect important statistics of your monitored segments and devices. You can then use the data collected through the LAN traffic tools to understand your network's usage and performance, as well as troubleshoot network issues.

The following sections discuss the different pieces of LAN traffic analysis and how to use them to monitor your managed segments, servers, and other network devices across your multitopology networks.


Understanding LAN Traffic Analysis

ZENworks for Servers 3 LAN traffic analysis is made up of several components that work together to collect, store, and display information about data packets that are being sent on your network. ZENworks for Servers 3 provides tools that enable you to capture and decode the packets as they are sent from one node to another, which enables you to better analyze the traffic. The following sections describe the ZENworks for Servers 3 LAN traffic components, how they communicate, and the functionality of their agents.

Understanding LAN Traffic Components

The ZENworks for Servers 3 LAN traffic analysis system is made up of three main components: the management server, the management console, and the monitoring agent server.

Discussing the Management Server

The management server component of ZENworks for Servers 3 LAN traffic analysis is installed on the management site server. It comprises an extremely scalable Sybase database that stores static information such as network names and LAN addresses of servers, routers, switches, and other nodes on you network.

The management server components include the NetExplorer, a consolidator, and the Atlas Manager (discussed in Chapter 9, "Preparing and Using ZENworks for Servers 3 Network Discovery"). These components gather information about manageable devices on the network and store that information in the management database. The management database is a Common Information Model-2 (CIM-2) database that stores network data used to establish the network's topology. ZENworks for Servers 3 extends the CIM-2 model to enable you to organize the information in the database and create a topology map.

About the Management Console

The management console component of ZENworks for Servers 3 LAN traffic analysis is installed on the management client in the form of snap-ins to the ConsoleOne utility (discussed in Chapter 8, "Understanding ZENworks for Servers 3 Management Services"). These snap-ins provide an intuitive, graphical method to access data collected by the ZENworks for Servers 3 LAN traffic analysis agents.

Exploring the Monitoring Agent Server

The final component of the ZENworks for Servers 3 LAN traffic analysis system is the monitoring agent server. The monitoring agent server is a server with network monitoring agent software installed on it. There must be one monitoring agent server per segment.

The monitoring agent server enables you to analyze a segment by searching the network and gathering information about network traffic. You can then use that information to analyze the LAN traffic on your network.

The network monitoring agents monitor network traffic and capture frames to build a database of objects in the network. Then network monitoring agent software enables you to use the ZENworks for Servers 3 management console traffic analysis tools to maintain your network performance, monitor traffic on your network, and troubleshoot network problems.

Understanding Communication Between Components

Now that you understand what components make up the ZENworks for Servers 3 LAN traffic analysis system, you need to understand how these systems communicate with each other. The management console component communicates with the management server component by using Common Object Request Broker Architecture (CORBA) to obtain static and dynamic information about the managed nodes and devices on your network.

When the management console requests static information from the management server, the management server then communicates with the management database component by using the Java Database Connectivity (JDBC) protocol. It gathers the requested information from the database and relays it back to the management console.

When the management console requests dynamic information from the management server, the management server communicates with the network monitoring agent by using SNMP requests. It gathers the requested information dynamically and relays it back to the management console.

Understanding Agent Functionality

ZENworks for Servers 3 includes several types of monitoring agents to accommodate the various topologies and devices on your network. Network monitoring agents provide you with the functionality to remotely monitor segments and devices that are SNMP-compliant. The agents collect and store statistical and trend information as well as capture real-time data from the managed nodes and devices on your network. The following sections describe the RMON, RMON Lite, RMON Plus, RMON2, and bridge agents to help you decide which one to use, based on the size and topology of your network.

RMON Agents

ZENworks for Servers 3 RMON agents use a standard monitoring specification that enables various nodes and console systems on your network to exchange network data. That network data is used to monitor, analyze, and troubleshoot your LAN from a central site.

The RMON agents are typically used to monitor Ethernet, FDDI, and token ring segments. Table 10.1 describes the groups of monitoring elements that make up the RMON agent.

Table 10.1. RMON Agent Monitoring Groups

RMON GROUP

DESCRIPTION

Statistics

Records statistics measured by the agents for each monitored interface on the device.

History

Records periodic statistical samples from a network and stores them for later retrieval from the management console.

Alarm

Periodically takes statistical samples from parameters in the agent and compares them with previously configured thresholds. Then, if the monitored parameter crosses a threshold, an alarm event is generated.

Host

Lists the statistics associated with each host discovered on the network.

HostTopN

Prepares tables that describe the hosts that top a list ordered by one of their statistics.

Matrix

Stores statistical information for conversations between two nodes. Creates an entry in its table for each new conversation.

Filters

Enables packets to be matched to a filtered variable. The matched packets form a data stream that may be captured or used to generate events.

Packet Capture

Enables packets to be captured after they flow through a channel.

Events

Controls the generation and notification of events from the device.

RMON Lite Agents

ZENworks for Servers 3 RMON Lite agents also use a standard monitoring specification that enables various devices on your network to exchange network data. The RMON Lite agents are typically used to monitor devices that are not dedicated for network management, such as a hub or a switch. Table 10.2 describes the groups of monitoring elements that make up the RMON Lite agents.

Table 10.2. RMON Lite Agent Monitoring Groups

RMON LITE GROUP

DESCRIPTION

Statistics

Lists statistics measured by the agents for each monitored interface on the device.

History

Records periodic statistical samples from a network and stores them for later retrieval from the management console.

Alarm

Periodically takes statistical samples from parameters in the agent and compares them with previously configured thresholds. Then, if the monitored parameter crosses a threshold, an alarm event is generated.

Events

Controls the generation and notification of events from the device.

RMON Plus Agents

ZENworks for Servers 3 RMON Plus agents are proprietary agents that extend the functionality of the RMON agent. They act exactly the same as the RMON agent and provide the same groups as those shown in Table 10.1. In addition to providing data collected from the RMON groups, they also provide data collected from the groups shown in Table 10.3.

Table 10.3. RMON Plus Agent Monitoring Groups

RMON PLUS GROUP

DESCRIPTION

Buffer

Records the number of octets (excluding framing bits but including frame check sequence octets) in packets that are captured in the buffer.

Admin

Collects information sent to the agent, such as version number.

HostMonitor

Monitors a set of nodes for a particular host table and sets traps when a host becomes active or inactive.

DuplicateIP

Records and updates lists of packets arriving that contain duplicate IP addresses.

MacToIP

Stores records of the IP addresses associated with host addresses for a host-mapping table.

BoardStatus

Records the status of each logical interface of the RMON or RMON Plus agent.

RMON2 Agents

ZENworks for Servers 3 RMON2 agents can be used to collect data from nodes and devices in the network and application layers of the network model, unlike the RMON, RMON Lite, and RMON Plus agents, which are used to collect data from nodes and devices in the physical and data link layers of the network model.

RMON2 agents can also determine network usage based on the protocol and application used by the nodes in your network. Table 10.4 describes the groups of monitoring elements that make up the RMON2 agent.

Table 10.4. RMON2 Agent Monitoring Groups

RMON2 GROUP

DESCRIPTION

Protocol Directory

Creates a table of all identifiable protocols and their descriptions.

Protocol Distribution

Collects statistics for each protocol that the agent is configured to track.

Address Map

Maps a network layer address to the corresponding MAC address.

Network-Layer Host

Collects statistics for each host by network layer address.

Network-Layer Matrix

Collects statistics for each network conversation between pairs of network layer addresses.

Application-Layer Host

Collects statistics on the traffic generated by each host for a specific Application layer protocol. The Protocol Directory group can recognize traffic that is broken down by protocols.

Application-Layer Matrix

Collects statistics on conversations between pairs of network layer addresses for a specific application layer protocol. Traffic, broken down by protocols, can be recognized by the Protocol Directory group. The Protocol Directory group can recognize traffic that is broken down by protocols.

User History

Enables the agent to save samples of RMON2 data for any MIB object at specific intervals.

Probe Configuration

Provides remote capability for configuring and querying agent parameters—for example, software updates, IP address changes, resets, and trap destinations.

RMON Conformance

Provides information to the management software regarding the status of support for the group.

Bridge Agents

ZENworks for Servers 3 bridge agents monitor network bridges, enabling you to collect information about switched networks. Table 10.5 describes the groups of monitoring elements that make up the bridge agents.

Table 10.5. Bridge Agent Monitoring Groups

BRIDGE GROUP

DESCRIPTION

Base

Stores information about objects that are applicable to all types of bridges.

Spanning Tree Protocol

Stores information regarding the status of the bridge with respect to the Spanning Tree protocol.

Source Route Bridging

Collects information that describes the status of the device with respect to source route bridging.

Transparent Bridging

Collects information that describes the object's state with respect to transparent bridging.

Static

Collects information that describes the object's state with respect to destination address filtering.


Setting Up LAN Traffic Analysis

Now that you understand the components involved in ZENworks for Servers 3 traffic analysis, you are ready to begin setting up traffic analysis on your network. Setting up LAN traffic analysis for ZENworks for Servers 3 involves establishing normal activity for your LAN, and then making the necessary configuration changes for the management console to be able to communicate with the management server. The following sections discuss creating a baseline document of normal LAN activity to use as a measurement, selecting the preferred RMON agent, and setting the necessary SNMP parameters for the management console to access the RMON agent.

Creating a Baseline Document

The first step in setting up ZENworks for Servers 3 LAN traffic analysis on your network is to create a baseline document that describes the normal activity and usage of your network. The baseline document should show the normal levels of the most common statistics segments monitored by ZENworks for Servers 3.

After you create the baseline document, you can use it to identify parts of your network that are experiencing problems, need to be balanced, or need to be upgraded. The following is a list of the most common network statistics that should be used to create a baseline document:

  • Bandwidth utilization. The bandwidth utilization statistic indicates the percentage of network bandwidth used. Because the network bandwidth tends to be higher at heavy usage times, your baseline document should account for those times—for example, when users are logging on in the morning.

  • Packets per second. The packets-per-second statistic indicates the raw number of packets that are being transferred on the network. This gives you the best indication of how heavy your network traffic really is.

  • Network error rates. You should also set a baseline for network error rates. This is also based on heavy usage, so your baseline should take into account periods of the day when heavy usage would cause errors. This helps you identify times when network errors are atypical.

  • Kilobytes per second. The kilobytes-per-second statistic indicates the raw amount of data that is being transferred on the network. This gives you the best indication of how heavy your network throughput really is.

  • Active servers. You should keep track of the three most active servers on the network. This helps you understand where loads need to be balanced and where network upgrades must take place.

Selecting the Preferred RMON Agent

After you create your baseline document, you need to select which remote monitor (RMON) agent you want to monitor each managed segment. The RMON agent is set on the RMON Agent property page for the segment in ConsoleOne.The RMON property page displays the following information, shown in Figure 10.1, about the RMON agent:

  • Preferred. Checked if this server is set as the preferred RMON agent server for the segment.

  • Agent Name. Displays a list of all the servers on which the RMON agent is installed.

  • Version. Displays the dynamically obtained version number of the RMON agent installed on this server. It is left blank if ZENworks for Servers 3 is unable to contact the server to get a version number.

  • Status. Displays the current status of the RMON agent on the selected segment.

  • MAC Address. Displays the MAC address of the server.

  • Interface Index. Displays the number of interface indexes to which a server can connect through its network card. Each interface corresponds to a segment.

  • Available RMON Services. Displays the list of RMON services available from the selected agent (RMON, RMON Plus, or RMON2).

Figure 10.1. RMON Agent property panel for a segment object in ConsoleOne.

Follow these steps to set an RMON agent as the preferred agent to monitor a segment:

  1. Right-click the segment object in ConsoleOne and select Properties from the pop-up menu.

  2. Click the RMON Agent tab, as shown in Figure 10.1.

  3. Choose a server or workstation name from the list displayed in the properties page, and then choose which server acts as the RMON agent for the segment.

  4. Click the Apply button to save the settings.

Setting Up SNMP Parameters

After you set the preferred RMON agent for each segment, you need to set up the SNMP parameters for the servers hosting your RMON agents. When you request that dynamic information be displayed at the management console, you obtain that information from the monitoring server agents by using SNMP.

Initially, the SNMP communication between the management servers and the management console is based on default SNMP settings; however, you may want to modify the following settings, as shown in Figure 10.2:

  • Secure Get (also known as SNMP get). Encrypts the packets sent by the monitoring agent to the management the agent.

  • Secure Set (also known as SNMP set). Encrypts the packets sent by the management agent to the monitoring agent.

  • Community Strings. Community name of the node requesting dynamic data from the agent.

  • Number of Retries. Number of times you want the management server to retry connecting to the monitoring agent.

  • Timeout in mS. Maximum duration in milliseconds for which the management server should wait for a response from the monitoring agent.

  • Port Number. Port on which the management server contacts the monitoring agent.

Figure 10.2. SNMP Settings tab for a server object in ConsoleOne.

Follow these steps to modify the default SNMP communication for your management servers:

  1. Right-click the server object that is hosting the RMON agent for the segment and select Properties from the pop-up menu.

  2. Click the SNMP Settings property panel, as shown in Figure 10.2.

  3. Modify the Authentication and Communication settings.

  4. Click the Apply button to save your settings.


Analyzing Network Traffic

After you set up the RMON agents and SNMP parameters for the segments and devices on which you want to analyze traffic, you are ready to begin capturing and analyzing network traffic. ZENworks for Servers 3 enables you to monitor and collect detailed real-time statistics from nodes and segments in your network. That information is displayed back to the management console in the form of tables, graphs, and other graphical displays.

This section discusses how to use the ZENworks for Servers 3 management console to monitor and analyze traffic on segments, nodes, protocols, and switches. It also covers how to capture and analyze network packets.

Analyzing Traffic on Network Segments

The most common LAN traffic analysis you will likely be doing is on network segments. You can ensure the most cost-effective, stable, and consistent network by monitoring and managing your segments with ZENworks for Servers 3 traffic analysis.

ZENworks for Servers 3 provides several different views for analyzing network traffic on segments. The management views translate the data collected by the monitoring agent into an easy-to-understand graphical and textual form. The following sections discuss how to use the List Segment Statistics, Segment Dashboard, Trend Data, Alarm Statistics, and Summary views on segments to monitor and analyze their traffic.

Viewing Network Statistics for a Segment

The List Segments Statistics view displays a list of segments in your network, as well as the following statistical information for each of them, as shown in Figure 10.3:

  • Segment Name. Segment name, or address if no name is available.

  • Type. Physical segment type (Ethernet, FDDI, WAN, and so on.)

  • Speed (Mbps). The raw speed of the segment, measured by the speed of the network interface card that attaches the RMON agent to the segment. Cable type is also used to determine the segment speed.

  • Utilization %. Average percentage of the bandwidth currently in use by the traffic on the segment.

  • Packets/s. Average number of packets per second currently being transmitted on the segment.

  • KBytes/s. Average number of kilobytes per second currently being transmitted on the segment.

  • Errors/s. Average number of errors per second the segment is currently incurring.

  • Message. Message describing the current status of the RMON agent on the segment.

Figure 10.3. List Segments Statistics view for a node in ConsoleOne.

Follow these steps from the ZENworks for Servers 3 management console to access the List Segment Statistics view:

  1. Select a segment or a node from the ZENworks for Servers 3 namespace in the management console.

  2. Select View [image] List Segment from the main menu and a screen similar to the one shown in Figure 10.3 appears.
Determining Individual Segment Performance

The Segment Dashboard view is a graphical view that provides real-time statistical information about an individual monitored segment. Shown in Figure 10.4, it displays four gauges that give the following real-time statistics for that segment, as well as node activity for the top nodes on the segment:

  • Packets/s. The Packets gauge shows the number of packets per second that are being transmitted on the segment.

  • Utilization %. The Utilization gauge shows the current utilization, compared to the maximum network capacity that is currently being consumed on the segment.

  • Errors/s. The Errors gauge shows the number of errors per second the segment is currently incurring.

  • Broadcasts/s. The Broadcasts gauge shows the number of broadcast packets per second that are currently being transmitted on the segment.

Figure 10.4. Segment Dashboard view for a segment in ConsoleOne.

Follow these steps from the ZENworks for Servers 3 management console to access the Segment Dashboard view:

  1. Select the segment you want to monitor from the ZENworks for Servers 3 namespace in the management console.

  2. Select View [image] Segment Dashboard from the main menu and a screen similar to the one shown in Figure 10.4 appears.
Analyzing Segment Trends

Use the Trend Data view in conjunction with the baseline document, discussed earlier in this chapter. The Trend Data view enables you to determine trends of traffic patterns that indicate that a segment is in trouble or needs to be updated or expanded. To access the Trend Data view for a segment from the ZENworks for Servers 3 management console, follow these steps:

  1. Select the segment you want to monitor from the ZENworks for Servers 3 namespace in the management console.

  2. Select View [image] Segment Trends from the main menu and a screen similar to the one shown in Figure 10.5 appears.

    Figure 10.5. Trend Data view for a segment in ConsoleOne.

You can configure which statistics to monitor in the Trend Data view. Follow these steps to configure the statistics that best fit your network:

  1. Click the Profile button in the Trend Data view.

  2. Select a profile from the Select Profile column in the Edit Profile window.

  3. Choose which statistics you want to view in the Select Series column. The available options depend on your network type.

  4. Click the OK button and the Trend Data view should be updated with your new selections.
Viewing Alarm Statistics for a Segment

The Alarm Statistics view shows a list of all alarms for the monitored segment, along with their threshold and sampling rate. Follow these steps from the ZENworks for Servers 3 management console to access the Alarm Statistics view for a segment:

  1. Right-click the segment you want to monitor from the ZENworks for Servers 3 namespace in the management console.

  2. Select Properties from the pop-up menu.

  3. Select the Segment Alarms tab, as shown in Figure 10.6.

    Figure 10.6. Segment Alarms tab for a segment object in ConsoleOne.

You can edit the alarms manually by highlighting the alarm and clicking the Edit button, or you can use the Default All button to set a predefined set of default values to the alarms.

Viewing a Segment Summary

The Segment Summary view is both a graphical and a textual view, which provides a quick summary of the managed segment. This view enables you to quickly assess the current state of the segment. It provides the following static information about the managed segment:

  • Name. Name or address of the segment

  • Type. Media type of the segment: Ethernet, token ring, or FDDI

  • IP Address. IP addresses of the segment

  • IPX Address. IPX addresses of the segment

  • Primary Agent. Name of the preferred agent, which is monitoring nodes and traffic on the segment

  • Agent Status. Current status of the preferred monitoring agent

  • Nodes. Number of nodes on the segment

  • IP Nodes. Number of nodes on the segment with IP addresses

  • IPX Nodes. Number of nodes on the segment with IPX addresses

  • Servers. Number of NetWare servers on the segment

  • Workstations. Number of nodes on the segment that are not NetWare Servers

  • Network Probes. Number of monitoring agents available on the segment

  • Switches. Number of switches on the segment

  • Routers. Number of routers on the segment

  • Hubs. Number of hubs on the segment

The Segment Summary view provides the following information about alarms that have occurred on the managed segment:

  • Severity. Severity level associated with the alarm

  • From. Network address of the device that sent the alarm to the alarm management system

  • Summary. Summary of the event, often including the name or address of the object affected by the alarm

  • Owner. Segment or device affected by the alarm

  • Received Time. Date and time when the alarm management system received the alarm

  • Type. Description of the alarm

  • Category. The category of the alarm, based on the MIB

The Segment Summary view provides the following charts and gauges that show you dynamically captured information about the managed segment:

  • Utilization %. Displays a gauge representing the current real-time usage of the network in relation to the maximum capacity.

  • Packets. Displays a trend graph based on data about packets that have been transmitted on the segment.

  • Protocol Distribution. Displays a pie chart that represents the distribution of protocols on the network.

Follow these steps from the ZENworks for Servers 3 management console to access the Segment Summary view for a segment:

  1. Select the segment you want to monitor from the ZENworks for Servers 3 namespace in the management console

  2. Select View [image] Segment Summary from the main menu and a screen similar to the one in Figure 10.7 appears.

    Figure 10.7. Segment Summary view for a segment in ConsoleOne.

Analyzing Traffic on Nodes Connected to a Segment

ZENworks for Servers 3 also provides several views to help you monitor and analyze traffic associated with nodes connected to a monitored segment. Monitoring at the segment level gives you a good understanding about the general trends and health of the entire segment. But if you want to analyze traffic at a more granular level, you need to analyze traffic at the node level.

The following sections describe how to use the ZENworks for Servers 3 management console to analyze statistics between nodes, and to monitor nodes for inactivity.

Analyzing Network Statistics for Stations on a Segment

The first thing that you should do when analyzing traffic of nodes on a segment is to gather information about the most active ones. Viewing the statistics for the most active nodes gives you an indication of how active nodes are on the segment and whether any nodes are exhibiting troubled behavior. ZENworks for Servers 3 provides the Stations view to enable you to view the following statistics on the most active nodes in the segment:

  • MAC Address. Physical address of the node

  • Node. Name or address of the node

  • Utilization %. Percentage of maximum network capacity consumed by packets sent from this node

  • Packets/s In. Packets per second received by this node

  • Packets/s Out. Packets per second sent by this node

  • Bytes/s In. Data in bytes per second received by this node

  • Bytes/s Out. Data in bytes per second sent by this node

  • Errors/s. Errors per second received by this node

  • Broadcasts/s. Broadcast packets per second received by this node

  • Multicasts/s. Multicasts per second received by this node

  • Protocols. Types of protocols used by this node

  • First Transmit. Date and time this node first transmitted a packet since the traffic analysis agent was loaded

  • Last Transmit. Date and time this node last transmitted a packet since the traffic analysis agent was loaded

Follow these steps from the ZENworks for Servers 3 management console to access the Stations view for a segment:

  1. Select the segment on which you want to monitor nodes from the ZENworks for Servers 3 namespace in the management console.

  2. Select View [image] Stations from the main menu and a screen similar to the one in Figure 10.8 appears.

    Figure 10.8. Segment Stations Summary view for a segment in ConsoleOne.

  3. Specify what statistic to use in determining a node's activity from the drop-down list at the top of the window.
Analyzing Traffic Between Nodes

The Conversations view is another useful ZENworks for Servers 3 view that enables you to view real-time data showing traffic between a specific node and one or more other nodes on the same segment. Use this information when you need to determine communication activity between specific nodes.

Suppose you have a database application installed on a node on the segment and you want to see how traffic from this node behaves when the database is active, as opposed to when it is shut down. You would use the Conversations view before and after activating the database and compare the data from each.

The Conversations view provides statistical data on the following characteristics of internode communication:

  • Node. Name or address of the destination node communicating with the selected node

  • % Pkt Load. Percentage of the total packet load being used between this node and the destination node

  • % Byte Load. Percentage of the total byte load being used between this node and the destination node

  • Pkts/s In. Number of packets received per second by the destination node from this node

  • Pkts/s Out. Number of packets sent per second from the destination node to this node

  • Bytes/s In. Number of bytes of data received per second by the destination node from this node

  • Bytes/s Out. Number of bytes of data sent per second from the destination node to this node

  • Pkts In. Number of packets received by the destination node from this node since the view was opened

  • Pkts Out. Number of packets sent by the destination node to this node since the view was opened

  • KBytes In. Number of kilobytes of data received by the destination node from this node since the view was opened

  • KBytes Out. Number of kilobytes of data sent by the destination node to this node since the view was opened

  • Protocols. Protocol packet types used by the destination node to communicate with this node

  • First Transmit. Date and time that this node first transmitted on the network since the traffic analysis agent was loaded

  • Last Transmit. Date and time that this node last transmitted on the network since the traffic analysis agent was loaded

Follow these steps from the ZENworks for Servers 3 management console to access the Conversations view for a node:

  1. Select the node on which you want to monitor conversations from the ZENworks for Servers 3 namespace in the management console.

  2. Select View [image] Conversations from the main menu and a screen similar to the one in Figure 10.9 appears.

    Figure 10.9. Conversations view for a node in ConsoleOne.
Monitoring Nodes for Inactivity

Another useful way to monitor network traffic at a node level is to monitor nodes for inactivity. ZENworks for Servers 3 enables you to monitor nodes to determine whether they become inactive and alert you if they do. This does not impact network traffic because the traffic analysis agent does not poll the node to obtain status. Follow these steps from the ZENworks for Servers 3 management console to set it to monitor inactivity of a node:

  1. Right-click the node you want to monitor for inactivity from the ZENworks for Servers 3 namespace in the management console.

  2. Select Monitor Nodes for Inactivity [image] Add from the pop-up menu to enable monitoring of the node.

After you select the nodes that you want to monitor, you can view the following information about them from the Monitor Nodes for Inactivity view:

  • Name. Name of the node being monitored

  • MAC Address. Physical address of the node

  • Status. Current status of the node (updated every 60 seconds by default)

Follow these steps from the ZENworks for Servers 3 management console to access the Monitor Nodes for Inactivity view:

  1. Select the segment for which you want to see a list of nodes monitored for inactivity from the ZENworks for Servers 3 namespace in the management console.

  2. Select View [image] Monitor Nodes for Inactivity from the main menu.

Capturing Packets from the Network

ZENworks for Servers 3 makes it possible for you to be even more detailed than LAN traffic analysis at a node level by enabling you to capture specific sequences of packets from the network. As nodes communicate on a segment, they send packet sequences to each other, which are captured by the RMON agents in a local buffer and can be accessed by the management console.

Packet captures provide much more detail to LAN traffic analysis because they provide information about requests and replies that nodes are making on the network. This can be useful in troubleshooting interserver or client-to-server communication issues.

The following sections describe how to use the ZENworks for Servers 3 management console to set up a filter and capture packets from the network.

Setting Up a Capture Filter

The first step in capturing packets from a segment is to set up a filter to limit the number of packets captured. Without a filter, there would be far too many packets captured, making it extremely difficult to use the capture. Filtering enables you to capture only the packets that are needed. If you are troubleshooting a client-to-server communication issue on an IP application, for example, you would want to capture IP packets only between the client node and the server node.

Follow these steps from the ZENworks for Servers 3 management console to define a capture filter:

  1. Select a node or a segment from the ZENworks for Servers 3 namespace in ConsoleOne.

  2. Select File [image] Actions [image] Capture Packets from the main menu. The Packet Capture Setup window, shown in Figure 10.10, appears.

    Figure 10.10. Packet Capture Setup window for filtering packet captures in ConsoleOne.

  3. Type in a descriptive name for the buffer in the Buffer Name text box. This typically should describe the purpose of the capture.

  4. Select the source and destination nodes from drop-down lists in the Stations box and specify whether you want to capture packets based on an IP, IPX, or hardware address. You can use Any for either the source or destination, or Both to include all nodes. If it's possible, use specific nodes to reduce the size of the capture.

  5. Select the direction of traffic flow between nodes. You can select only source to destination, only destination to source, or both directions. This can help limit the capture greatly if you need only one direction.

  6. Add protocols on which to filter by selecting the protocol in the Selected Protocols list and clicking the Add button. If you do not add protocols on which to filter, all protocols are captured.

  7. Specify what kind of packets to capture. See Table 10.6 for a list of available statistics by topology.

  8. Specify whether you want to overwrite the buffer or stop the capture when the buffer is full. Overwriting the buffer means that the oldest packets are overwritten with the newest ones. If you specify to overwrite, you must manually stop the capture.

  9. Specify the buffer size. This depends on what you need to capture and for how long. If you are capturing all packets from all nodes, you need a very large buffer; however, if you need packets from only one node to another one, the default buffer of 32K is probably enough. Keep in mind that there must be enough free memory at the RMON server to create the buffer.

  10. Specify the packet slice size. The Slice Size field specifies the maximum number of bytes of each packet, starting from the packet header, to store in the buffer. This also depends on what you need out of the capture. For header information, you need only 150 bytes or so. But if you need data out of the packet itself, you should select the entire packet. This parameter determines the number of packets that a buffer can hold.

  11. Click the OK button and the filter will be set.

Table 10.6. Available Statistics on which to Filter Based on Segment Type

SEGMENT TYPE

AVAILABLE STATISTICS

DEFAULT STATISTICS

Ethernet

Only good packets, only error packets, both good and error packets

Both good and error packets

FDDI ring

All packets, LLC packets, MAC packets, SMT packets

All packets

Token ring

All packets, non-MAC packets, MAC packets

All packets

Starting a Packet Capture

After you set the filter, you are ready to start the capture. When you click the OK button from the Packet Capture Filter window, a Capture Status window similar to the one in Figure 10.11 appears. The Capture Status window displays the following information about the capture:

  • Segment. Name or address of the segment on which the packet capture is occurring

  • LANalyzer Server. Name or address of the server running the RMON agent that is collecting the captured packets

  • Buffer Granted. Size of the buffer used for the capture

  • Description. Description of the filter settings for the capture

  • Count. Incrementing count, shown as 8 in Figure 10.11, for every packet that is captured

Figure 10.11. Packet Capture Status window for packet captures in ConsoleOne.

From the Capture Status window, click the Start button to start the capture. If you are trying to capture a specific sequence, start the capture and then perform the sequence—for example, open a database file or start an application. When you have captured enough packets, you can click the Stop button to stop the capture, or you can simply wait until the buffer fills up if you specified to stop the capture when the buffer was full.

Analyzing Captured Packets

After you set up a capture filter and capture the sequence of packets, you are ready to begin analyzing them from the management console. The packet captures reside on the server hosting the RMON agent; however, ZENworks for Servers retrieves the packet data from the RMON agent individually as you view each packet.

Viewing Captured Packets

ZENworks for Servers 3 provides an extremely useful Trace Display view to help you view and decode packet data. The Trace Display view, shown in Figure 10.12, provides summary information about the captured packets (top), a decoded view of the selected packet (middle), and a hexadecimal view of the packet (bottom).

Figure 10.12. Packet capture Trace Display view for packet captures in ConsoleOne.

You can open the Trace Display view by clicking the View button on the Capture Status window or by Selecting Tools [image] View Packet File from the main menu in ConsoleOne.

The following sections discuss the three different sections of the Trace Display view.

Captured Packet Summary

The summary pane in the Trace Display view displays a list of captured packets, providing you with an overview of the communications between source and destination nodes. You can highlight a packet in this pane to display the decoded and hexadecimal packet data in the panes below. The summary pane provides the following statistical information about the captured packets:

  • No. Numbers the packets in the order in which they were received at the RMON agent

  • Source. Name or MAC address of the node from which the packet was sent

  • Destination. Name or MAC address to which the packet was sent

  • Layer. Abbreviation of the highest protocol layer in the packet—for example, "ncp" for NetWare Core Protocol or "ether" for Ethernet

  • Summary. Displays a brief description of the contents of the highest protocol layer

  • Error. Shows the error type, if any, that occurred in the packet

  • Size. Displays the number of bytes contained in the packet

  • Absolute Time. Displays the hardware clock time when the packet arrived

  • Interpacket Time. Displays the time that elapsed from the end of the preceding packet to the end of the current packet

  • Relative Time. Displays the time that elapsed since the arrival of the oldest packet still in the buffer

Decoded Packet Data

The decode pane in the Trace Display view displays detailed information about the contents of the selected packet. The packet data is decoded and displayed according to defined protocol fields. This is an extremely useful tool because it tells you information such as the station that sent the packet, protocol, NCP request information, reply results, and so forth. You typically use this field to understand packet sequences and why they failed.

Hexadecimal Packet Data

The hexadecimal pane in the Trace Display view displays the raw packet data in hexadecimal format. The column on the left is the hexadecimal offset from the packet header. The second column is the raw hexadecimal data of the packet. The column on the right is the ASCII form of the hexadecimal data.

You will likely use only the hexadecimal display if you know exactly what you are looking for. If, for example, you know the structure of the data that is being sent from a client application to a server, you would be able to manually decode the hexadecimal data. The text column of the hexadecimal display, however, is often useful because it shows textual data in the packet. File pathnames, for example, show up in the ASCII column.

Filtering the Display for Captured Packets

ZENworks for Servers 3 also enables you to filter out packets even after you have begun viewing the packet trace. This is extremely useful in situations where after you begin viewing a packet trace, you narrow down the problem to a specific node or even a specific request.

Suppose you originally capture all packets going between a server and all network nodes, but you need to see only the packets going to that server from a specific node. You could filter on only those packets that are going to the specific node you are troubleshooting.

Another example is if you know the structure of the exact packet type you want to view. You can filter on a value, such as a key sequence, at a specific offset, and see only those packets that match.

Follow these steps to set a display filter for captured packets from the Capture Trace view in ConsoleOne:

  1. Select View [image] Filter from the main menu and the Display Filter dialog box, shown in Figure 10.13, appears.

    Figure 10.13. Trace Display Filter dialog box for packet captures in ConsoleOne.

  2. Modify the stations setting to narrow your filtering down to specific stations.

  3. Modify the packet direction, if possible, to packets going one way.

  4. Add or remove protocols from the selected protocols list.

  5. Set the hexadecimal Offset and the From fields if you are looking for packets containing specific data.

  6. Specify the data value and type to search for at the specified offset.

  7. Click the OK button and your capture display filters on the criteria you have specified.

NOTE

If your packet capture is large, you may have to wait a considerable time for the ZENworks for Servers 3 management console to transfer enough of each packet to filter on. This takes up considerable bandwidth. We recommend that you use the capture filter setting to narrow down your captures first.

Highlighting Protocol Fields and Hex Bytes

One of the most valuable features of the Trace Display view is its capability to match data in the decoded pane with the hexadecimal values in the hexadecimal pane. It does this by highlighting the data areas that you select in the decode pane, the hexadecimal pane, or in both panes. The following is a list of examples of how you can use the highlighting tool:

  • Highlight a protocol layer in the decode pane and view the hexadecimal bytes in the Hex view.

  • Click a specific field in the decode pane and view the hexadecimal value associated with it.

  • Click a hexadecimal byte in the hexadecimal pane and see which protocol field is associated with it in the decode pane.

  • Click ASCII text in the hexadecimal pane and see the hexadecimal values and the specific decode field associated with it.

NOTE

You can save a trace file to a *.tr1 file format so that you can send it to someone else to look at, too, by selecting File [image] Save.

Analyzing Protocol Traffic

The ZENworks for Servers 3 traffic analysis agent also enables you to monitor statistics of traffic generated by protocols in your network.

Displaying Protocols Used on a Network

The RMON2 agent object in the eDirectory tree provides a Protocol Directory property page to view a list of supported and custom protocols used in the network. This is a hierarchical list with the protocols used in the Data Link layer at the top level. Follow these steps from within ConsoleOne to display the protocols used on your network:

  1. Select the node object running the RMON2 agent from the ZENworks for Servers 3 namespace.

  2. Expand the view by clicking the plus sign next to it.

  3. Expand the view for the services object.

  4. Right-click the RMON2 object under Services and select Properties from the pop-up menu.

  5. Select the Protocol Directory tab.

From the Protocol Directory tab, you can also add custom protocols to the supported protocol tree by clicking the Add button. You can also click the Remove button to remove a protocol from being monitored in the tree.

Determining Segment Distribution of Protocols

ZENworks for Servers 3 also enables you to view the distribution of protocols on a segment. This gives the following statistics of the protocol communications in the Network layer, Transport layer, and Application layer that are occurring on your network:

  • Protocol Name. The name of the protocol

  • Packets/s. The average number of packets per second that are being sent with this protocol

  • Bytes/s. The average number of bytes of data per second that are being sent with this protocol

  • Packet Rate %. The percentage of packets transmitted with this protocol, relative to the total percentage of packets transmitted

  • Byte Rate %. The percentage of bytes of data transmitted with this protocol, relative to the total bytes of data being transmitted

Follow these steps from within the ZENworks for Servers 3 namespace in ConsoleOne to view the distribution of protocols in a segment:

  1. Select the managed segment for which you want to view protocols.

  2. Select View [image] Protocol Distribution from the main menu. A window similar to the one in Figure 10.14 appears.

    Figure 10.14. Protocol Distribution view for a segment object in ConsoleOne.

Analyzing Switch Traffic

The ZENworks for Servers 3 traffic analysis agent also enables you to monitor statistics of traffic generated on switches in your network. This helps you determine the load on workstation and workgroup switches in your network, enabling you to plan for future upgrades.

ZENworks for Servers 3 monitors ports and nodes connected to those ports by using an RMON agent, an external RMON agent, or a bridge agent. The following sections discuss how to use these agents to display statistics for ports on the switches on your network and to view the summarized information for a specific switch.

Viewing Port Statistics for a Switch

You can view a switch's port statistics by using the ZENworks for Servers Unified Port Traffic view. This view obtains statistical information about every port in your network. It then displays a list of nodes connected to ports on the switch and statistics for each port.

Follow these steps from within the ZENworks for Servers 3 namespace in ConsoleOne to display the Unified Port Traffic view:

  1. Select the managed switch on which to view port statistics.

  2. Expand the view by clicking the plus sign next to the switch.

  3. Expand the view by clicking the plus sign next to services under the switch.

  4. Select Switch/Bridge under services.

  5. Select View [image] Port Traffic from the main menu to bring up the Unified Port Traffic view.
Viewing Switch Summary Data

ZENworks for Servers 3 also provides a summary view of switch data that provides brief information about the switch. This gives you a quick look at the current status, usage, and alarms generated on the switch. The following statistical information is provided in the switch summary view:

  • Vendor. Name of the manufacturer of the switch

  • Switch Type. Type of switch: transparent or source route

  • Number of Ports Active. Number of ports currently active on the switch

  • Forwarding Table Overflow Count. Number of times the forwarding table has exceeded its capacity

  • Up Time. Time since the switch was last rebooted

  • Number of Ports Present. Number of ports that actually exist on the switch

  • Number of MAC Addresses Learned. Number of MAC addresses dynamically discovered by the switch

Follow these steps from within the ZENworks for Servers 3 namespace in ConsoleOne to display the Unified Port Traffic view:

  1. Select the managed switch for which to view the summary.

  2. Click View [image] Switch Summary from the main menu to bring up the Switch Summary view.


Setting Up ZENworks for Servers 3 Traffic Analysis Agents

ZENworks for Servers 3 provides traffic analysis agents and RMON agents for both NetWare and Windows NT/2000 to enable you to monitor heterogeneous LANs. These agents collect information about activity on your network and relay that information back to the management agent, which in turn sends it to the management console for viewing.

The following sections describe how to set up and use the traffic analysis agents for both NetWare and Windows NT/2000.

Setting Up the Traffic Analysis Agents for NetWare

You should take some time to set up the traffic analysis agents on the NetWare Servers on which they are installed. This involves setting the SNMP parameters, modifying the LANZ.NCF file, and restarting the agents.

Configuring NetWare SNMP Parameters

The first step in setting up ZENworks for Servers 3 traffic analysis agents on NetWare Servers is to configure the SNMP parameters. This involves setting the appropriate read, write, and error-handling options for your agent server.

Follow these steps to configure the SNMP parameters on NetWare servers:

  1. At the traffic analysis agent server, load the INETCFG utility.

  2. From the Internetworking Configuration screen in the INETCFG utility, select Manage Configuration [image] Configure SNMP Parameters.

  3. From Monitor Community Handling options, select Specified Community May Read, and then enter public for the community name.

  4. From Control Community Handling options, select Specified Community May Write, and then enter public for the community name.

  5. From Trap Handling options, select Send Traps with Specified Community, and then enter public for the community name.

  6. Press ESC to exit from the SNMP Parameters screen and save changes.

  7. Press ESC again to exit from the Internetworking Configuration screen and restart the server. These are not changes that the Reinitialize System command makes. For these changes to take place, you have to unload and reload SNMP, and that is done by restarting the server.
Modifying the LANZ.NCF File

The LANZ.NCF file is a script used to launch the traffic analysis agent on NetWare servers. You can modify the LANZ.NCF file to customize agent loading. Use a text editor to modify the commands in Table 10.7 to customize your LANZ.NCF file.

Table 10.7. LANZ.NCF File Commands for the Traffic Analysis Agents

COMMAND

DESCRIPTION

LOAD LANZSU DEBUG=1

Enables the LANZ control screen. Add the DEBUG=1 option to turn on the LANZ control screen, which reports significant events for traffic analysis agent on NetWare.

#LOAD LANZFCB

Disables packet capturing to prevent someone from observing secure traffic to and from the server. Comment out the load line for LANZFCB by putting a # sign in front of the statement to disable packet capturing.

LOAD LANZSM DUPIP=0

Disables generation of duplicate IP address alarms to prevent alarm generation in a DHCP environment. Add the DUPIP=0 option to disable duplicate IP address alarms.

LOAD LANZDI LEVEL=1

Sets packet flow control to yield to other server operations when traffic is high. This reduces the impact of traffic analysis on the server. Add the LEVEL=1 option to enable flow control.

LOAD LANZMEM BOUND=####

Sets the upper limit of available memory to increase the memory that the traffic analysis agents will take. Add the BOUND=#### option to set the amount of memory (####) traffic analysis will use before returning an out-of-memory error.

LOADLANZMEM BOUND=3072 AGE=###

Sets the amount of time the traffic analysis agent will hold data in memory. Add the age to specify the amount of time, measured in hours, that traffic analysis data will be left in memory before it is purged.

LOAD LANZSM TOPN=#

Sorts the number of concurrent sort computations per network adapter. Add the TOPN=# to set the number, between 2 and 10, of sort computations.

LOAD LANZCTL TRAPREG=1

Enables alarms to be sent automatically to the management console. Add the TRAPREG=1 option to tell the traffic analysis agent to automatically send SNMP alarms to management consoles.

LOAD LANZTR POLL=#

Enables/disables polling of source routed bridges on token ring networks. Add the POLL=# option, where # = 0 for off or # = 1 for on, to turn polling of source routed bridges on or off.

Starting/Stopping the Agent

The ZENworks for Servers 3 LAN traffic agents for NetWare comprise several modules. The following two script files are included with ZENworks for Servers 3 and should be used to start and stop the LAN traffic agents:

  • LANZ.NCF. Script file that loads the LAN traffic agent NLMs

  • ULANZ.NCF. Script file that unloads the LAN traffic agent NLMs

Using the NetWare LANZCON Utility

The LANZCON utility provided with ZENworks for Servers 3 enables you to configure and view the traffic analysis agents. The LANZCON utility is an NLM that is installed into the SYS:LANZ directory on the servers in which the traffic analysis agents were installed.

Load the LANZCON utility on your NetWare Server with the traffic analysis agents running to view and configure the following items:

  • Network Adapter Information. Types of items that the adapter is currently monitoring. You can also enable or disable an adapter from monitoring the network.

  • Agent Status. Status of the selected agent and items related to the agent monitoring the segment.

  • Statistics Information. Packet and event statistics for the selected network adapter.

  • History Information. Provides sampling information collected at intervals for the networks that are being monitored by this agent—for example, data source, buckets requested, and buckets granted.

  • Hosts Information. Statistics about specific host or nodes on the monitored network.

  • Matrix Information. Consists of three tables that record information about conversations between pairs of nodes on the monitored segment.

Setting Up the Traffic Analysis Agents for NT/2000

After you set up the traffic analysis agent on your NetWare Servers, you should take some time to set up the traffic analysis agents on your Windows NT/2000 Servers as well. Once again, this involves setting the SNMP parameters and then restarting the agents.

Configuring NT SNMP Parameters

The first step in setting up ZENworks for Servers 3 traffic analysis agents on NT/2000 Servers is to configure the SNMP parameters. This involves setting the appropriate read, write, and error-handling options for your agent server. Follow these steps to configure the SNMP parameters on your Windows NT/2000 servers:

  1. Open the Windows Services Manager dialog box. In Windows NT, double-click on Network in the Control panel and select the Services tab. In Windows 2000, select Start [image] Program Files [image] Administrative Services [image] Services.

  2. Select SNMP Services from the list of services.

  3. Click the Properties button.

  4. Click the Traps tab.

  5. From the Accepted Community Names box, click the Add button.

  6. Enter public in the Service Configuration dialog box.

  7. Click the Add button.

  8. Enter the DNS names or IP addresses of workstations or servers that should receive traps.

  9. Click the Add button.

  10. Click the Security tab.

  11. From the Accepted Community Names, click the Add button.

  12. Enter public in the Service Configuration dialog box.

  13. Set the appropriate rights.

  14. Click the Add button.

  15. Select Accept SNMP Packets from Any Host.

  16. Click the OK button to return to the Network window.

NOTE

If SNMP is not already installed on the NT Server, you have to reboot and get some SNMP errors after you install it from the NT Server CD. To correct this, reapply the NT support pack (whichever one you were on or newer).

Starting/Stopping the SNMP Service

Whenever you make changes to the settings for the SNMP service, you should stop and restart the agent. Follow these steps to stop and restart the traffic analysis agent on a Windows NT/2000 Server:

  1. Open the Services manager.

  2. Select SNMP Services.

  3. Click the Stop Button.

  4. When the agent is stopped, click the Start button.
Using the NT LANZCON Utility

The Windows LANZCON utility provided with ZENworks for Servers 3 enables you to configure and view the traffic analysis agents. The Windows LANZCON utility is an executable that is installed on the desktop of the Windows NT/2000 Servers to which the traffic analysis agents were installed. Load the LANZCON utility on your Windows NT/2000 Server with the traffic analysis agents running to view and configure the following items:

  • Configure LANalyzer Agent. Takes the place of editing the LANZ.NCF file on NetWare servers by letting you enable or disable packet capture and enable/disable station monitoring, and set memory bounds and age (how long to retain packet data before it is too old), concurrent sorting, and duplicate IP address alarms.

  • Network Adapter. Displays a list of network adapters discovered by the agent. You can enable or disable a network adapter from monitoring the network.

  • Agent Log. Displays a list of significant events and errors that occurred during a session.

  • Agent Status. Displays the current status and description of all agents that are installed on the server.

  • RMON Tables. Displays the statistics, history control, history data, host control, host entry, host topN control, host topN entry, matrix control, matrix SD entry, filter, channel, and buffer RMON tables for the network adapter. Also displays the alarm, event, and log RMON tables.

  • SNMP Traps. Displays a list of traps that occurred on the managed segment, including the received time and a summary of the trap.

NOTE

The ZENworks for Servers 3 traffic analysis agent does not have to be installed on every NetWare and NT/2000 Server. You need it installed on only one server (NT/2000 or NetWare) per segment that you want to monitor. This also helps with the discovery process.


Chapter 11. Using ZENworks for Servers 3 Alarm Management

One of the most powerful features of ZENworks for Servers 3 is its ability to make network management much more controlled and easy. ZENworks for Servers 3 adds a powerful alarm management system and a service monitoring system to help you more easily monitor, manage, and control problems on your network.

The ZENworks for Servers 3 alarm management system employs a series of trap and alarm handlers to manage and store information about important events that are occurring on your network. You can then use tools provided by the ZENworks for Servers 3 management console to understand, manage, and resolve those events.

The ZENworks for Servers 3 service monitoring system employs utilities and views from the management console to help you actively test and understand the connectivity between the management console and the monitored services. This feature helps you detect, locate, and understand service and network outages much faster.

The following sections describe the components and utilities that make up the ZENworks for Servers 3 alarm management system and the ZENworks for Servers 3 monitoring services system. They also discuss how to configure and use the services to best detect, diagnose, and resolve network issues.


Understanding Alarm Management Components

The ZENworks for Servers 3 alarm management system comprises several components, each of which has a specific responsibility to send, receive, transfer, handle, store, or view network alarms. ZENworks for Servers 3 uses these components to alert you when conditions or events occur on the network that require an action on your part to resolve.

The following sections discuss the different components that ZENworks for Servers 3 uses to monitor and manage alarms on your network.

About the SNMP Trap Receiver

The SNMP trap receiver is an agent that actively receives SNMP traps from managed servers with SNMP agents loaded on them. When the SNMP trap receiver gets an alarm, it is this agent's responsibility to pass the alarm to the SNMP trap injector component and the SNMP trap forwarder component.

Discussing the SNMP Trap Forwarder

The SNMP trap forwarder checks traps passed from the SNMP trap receiver against the Alarm Manager database to determine whether the trap has an SNMP trap-forwarding disposition. If the Alarm Manager database has a forwarding disposition for the trap, the SNMP trap forwarder forwards the trap based on the criteria specified by the disposition. If there is no forwarding disposition, the SNMP trap forwarder simply ignores the trap.

Understanding the SNMP Trap Injector

The SNMP trap injector is responsible for converting the SNMP traps into manageable alarms. After the trap is converted into an alarm, the SNMP trap injector then passes the alarm to the alarm injector.

About the Alarm Injector

The alarm injector is responsible for collecting alarms from the SNMP trap injector as well as other applications that can transfer alarms to the ZENworks for Servers 3 management system. After it receives an alarm, it then passes it to the inbound processor.

Discussing the Three Types of Alarm Processors

The alarm processors are responsible for processing network and server alarms that are added to them by the alarm injector. The following are the three types of alarm processors and their functions:

  • Inbound processor. The inbound processor receives alarms from the alarm injector and applies a predefined alarm template to them. The alarm template is based on SNMP traps and other proprietary definitions based on specific criteria from the ZENworks for Servers 3 alarm management system. After the inbound processor has applied the template to the alarm, it transfers it to the archive processor.

  • Archive processor. The archive processor takes alarms from the inbound processor, adds them to a log, and then stores data about them in the Alarm Manager database. After the alarm data is stored, the archive processor passes the alarm to the outbound processor.

  • Outbound processor. The outbound processor accepts alarms from the archive processor and then dispatches them to the subscription server and the disposition server.

Understanding the Alarm Manager Database

Now that you understand how traps are picked up and converted to alarms and then handled by the processors, you need to understand the Alarm Manager database. The Alarm Manager database is responsible for storing information about processed alarms as well as alarm templates and dispositions. The following sections discuss the different types of alarm information stored in the database.

Introducing Processed Alarms

The biggest responsibility of the Alarm Manager database is to store data about alarms that have been handled by the alarm processors. This is the data that you can view at the ZENworks for Servers 3 management console via the alarm query server, by using the alarm reporting discussed later.

Information About Alarm Templates

Another key type of alarm information that is stored in the Alarm Manager database is the templates used by the inbound processor to format the alarm so that it can be properly handled by the ZENworks for Servers 3 alarm management system.

Many SNMP traps, for example, do not have an object ID associated with them. But an object ID is required by the ZENworks for Servers 3 alarm management system to process the alarm. Therefore, a template is applied to the alarm at processing, which associates an object ID to the device or node that triggered the alarm.

About Alarm Dispositions

The Alarm Manager database also stores any configured alarm dispositions. Alarm dispositions enable you to configure, prior to the alarm occurring, an automated method of handling the alarm. The alarm dispositions enable you to launch applications, send an email alert, and send console alerts in the form of messages or beeps, forwarding the SNMP traps to other ZENworks for Servers 3 management systems or even to other non-ZENworks for Servers 3 management systems.

Information About Database Archivers

Now that you understand what information is stored in the Alarm Manager database, you need to know what components are responsible for putting it there. The following is a list of alarm database archivers and their responsibilities:

  • Alarm archiver. The alarm archiver stores the actual data and statistics about alarms that have occurred on the network. You can configure the alarm archiver to store whatever alarms you want to manage. The default for the alarm archiver is to store all alarms.

  • Disposition archiver. The disposition archiver receives alarm disposition information from the ZENworks for Servers 3 management console and saves it to the Alarm Manager database to be used by the SNMP trap forwarder.

  • Template archiver. The template archiver stores changes made to alarm templates by the MIB compiler in the database. ZENworks for Servers 3 includes basic templates for all SNMP traps and proprietary alarms; however, you can reconfigure them by using the MIB compiler.

Discussing Alarm Viewers

The final component involved in the ZENworks for Servers 3 alarm management system is the alarm viewers. The alarm viewers are simply different views available at the ZENworks for Servers 3 management console.

The ZENworks for Servers 3 management console uses alarm queries to the Alarm Manager database to provide you with views on currently active alarms, as well as historically archived alarms. You should become familiar with how to view alarm information. The different alarm views are discussed more fully in the next section.


Managing ZENworks for Servers 3 Alarms

Now that you understand the components that make up the ZENworks for Servers 3 alarm management system, you need to know how to begin managing alarms on your network. Alarm management is a process of enabling alarms, then monitoring for alarm conditions, handling the alarm situations, and deleting the alarms.

The following sections describe how to use the ZENworks for Servers 3 management console to enable alarms, disable alarms, understand alarm indicators, work with alarm views, manage alarms, perform actions on the alarms, and then remove alarms from the system.

Enabling and Disabling Alarms

The first task you must be familiar with when managing the ZENworks for Servers 3 alarm management system is how to enable and disable alarms. Alarm thresholds are associated with each managed server and segment. When an alarm threshold is exceeded, an alarm is generated.

Although server threshold alarms are enabled by default, segment threshold alarms are not. You need to use the ZENworks for Servers 3 management console to enable and configure the threshold alarms for your network.

Follow these steps in the management console to enable and disable the alarms for your managed servers and segments to best match your needs:

  1. Select the server or segment object for which you want to enable or disable alarms.

  2. Right-click the object and select Properties from the pop-up menu.

  3. Select the Segment Alarms property tab, shown in Figure 11.1.

    Figure 11.1. Segment Alarms property tab for a segment object in ConsoleOne.

  4. Select the alarm you want to modify.

  5. Click the Edit button and an Edit Alarm dialog box appears.

  6. Select Enable to enable the alarm or Disable to disable the alarm.

  7. If you are enabling an alarm, set the threshold value.

  8. If you are enabling an alarm, you should also set the amount of time in the Sampling Interval field by which the threshold value must be exceeded to generate the alarm.

  9. Click OK to save your alarm setting and return to the Segment Alarms property tab.

Understanding Alarm Indicators

After enabling, disabling, and configuring the alarm thresholds for the managed servers and segments on you network, ZENworks for Servers 3 starts tracking, storing, and relaying network alarms as they occur. At this point, you need to become familiar with the different alarm indicators so that you can recognize and respond to the alarms as they occur.

The following sections discuss the different indicators that you can watch for when alarms are triggered on your network.

About Alarm Icons Anchored to the Affected Object

Alarms that are triggered with a critical, major, or minor severity are displayed in the ZENworks for Servers 3 management console in both the Atlas and Console views. When an alarm is triggered on a segment or server that is being managed by the ZENworks for Servers 3 alarm management system, an Alarm icon is anchored to the object. Therefore, as you browse through the ZENworks for Servers 3 namespace, watch out for Alarm icons.

Discussing the Ticker Tape Message on the Status Bar

You can also configure the ZENworks for Servers 3 alarm management system to display alarm messages on the management console's status bar. This option is on by default. If this option is on, the alarm management system displays a descriptive message on the status bar as it recognizes that an alarm has been triggered. This is another thing that you should keep an eye out for. The messages let you know which object is affected so that you can quickly find the problem and resolve it.

Information About the Audible Beep

The final alarm indicator is an audible beep that is sent to the management console. The alarm management system can be configured to force an audible beep on the management console when an alarm occurs. This is very useful if you are not actively browsing or looking for alarms. If you hear a beep on the management console, look for the Alarm icon on your server or segment objects and investigate the alarm.

Working with Alarm Views

Now that you understand the alarm indicators for which you should look and listen, you need to know how to use the views provided with ZENworks for Servers 3 to monitor and manage alarms. The ZENworks for Servers 3 management console gives you access to both active and historical data about alarms that are occurring or have occurred on your network.

You can define access restrictions to alarm data and management functions through ZENworks for Servers 3 role-based services. You can also modify the presentation of the alarm data displayed in the views by sorting and filtering on specific data elements.

The following sections discuss the different alarm views provided with ZENworks for Servers 3 and how to use them to monitor and manage alarms.

Monitoring Active Alarms

Active alarms are typically the most important type of alarm that you will encounter. Active alarms indicate that a problem is currently happening on either a monitored segment or a server. The ZENworks for Servers 3 Active Alarm view, shown in Figure 11.2, displays the following alarm statistics for all current alarms for the managed site.

  • Severity. Displays an Alarm icon that is color coded to indicate the level of alarm severity: Red = Critical, Magenta = Major, Yellow = Minor, Blue = Informational, and White = Unknown.

  • From. Specifies the network address of the device that sent the alarm to the alarm management system.

  • Summary. Displays a summary of the alarm event, including names, addresses, and other information about the alarm.

  • Owner. Specifies the person or group that is responsible for handling the alarm. SYSTEM is specified until an owner is set.

  • Received Time. Displays the date and time when the alarm management system received the alarm.

  • Type. Specifies the alarm's generic type description.

  • Category. Specifies the category of the trap-type object, identified from its MIB association.

Figure 11.2. Active Alarm view for a ZENworks for Servers site management object in ConsoleOne.

For each of the alarms, the ZENworks for Servers 3 Active Alarm view displays the following alarm-specific data for the selected alarm (see Figure 11.2):

  • Alarm ID. Displays the alarm's object ID in the Alarm Manager database.

  • Alarm state. Displays the alarm's current status. This tells you whether the alarm is currently operational or not.

  • Alarm severity. Displays the alarm's severity: Severe, Major, Minor, Informational, or Unknown.

  • Generator Type. Displays the type of agent that activated the alarm.

  • Alarm category. Displays the category of the trap-type object, identified from its MIB association.

  • Alarm type. Displays the alarm's generic type description.

  • Source Address. Displays the address of the device that triggered the alarm.

  • Received at. Displays the time at which the alarm management system received the alarm from the agent.

  • Summary. Gives a descriptive summary of the alarm. This is one of the most useful statistics because the descriptions include node names and specific data about the alarm's nature.

  • Number of Variables. Lists the number of variables associated with the alarm.

Follow these steps from within the ZENworks for Servers 3 management console to access the Active Alarm view:

  1. Select the ZENworks for Servers 3 site object.

  2. Select View [image] Active Alarms from the main menu in ConsoleOne. The Active Alarm view appears, as shown in Figure 11.2.
Displaying Alarm History

In addition to the currently active alarms, ZENworks for Servers 3 also enables you to view data about all archived alarms that have occurred on the network. The Alarm History view is very similar to the Active Alarm view. But the Alarm History view includes a Handled status field, shown in Figure 11.3, in addition to the same information about the alarms.

Figure 11.3. Alarm History view for a ZENworks for Servers 3 site management object in ConsoleOne.

Follow these steps from within the ZENworks for Servers 3 management console to access the Alarm History view:

  1. Select the ZENworks for Servers site object.

  2. Select View [image] Alarms History from the main menu in ConsoleOne. The Alarm History view appears, as shown in Figure 11.3.
Sorting Alarms

After bringing up either the Active Alarm or the Alarm History view on the management console, you can change the look of the view by sorting the alarms according to a specific criterion. This enables you to tailor the view to meet the needs of the problem you are trying to resolve or a report that you need to prepare.

The following list includes the most common criteria on which you may want to sort alarms and examples of when to use them:

  • Received Time. Received time is the default sort order. This enables you to see the alarms in the chronological order that they occurred. This is the most useful view in understanding the initial status of the network and when problems started occurring.

  • From. Sorting using From enables you to focus on the specific server or node that triggered the alarm. This is most useful when you are troubleshooting a server or router issue.

  • Severity. Sorting according to the severity enables you to focus on a specific level of error. Typically, you sort according to severity when you want to see only the most severe errors that are occurring and resolve them first.

  • Category. Sorting by category enables you to focus on specific trap types identified in the MIB. This sorting enables you to focus on a specific alarm. Use this if you are troubleshooting or monitoring a specific router or server issue where you know the specific SNMP trap you are looking for.

  • Type. Sorting by type can also be very useful to troubleshoot some specific issues. If you were watching for hard drive space problems, for example, you may sort by type and bring together all the volume out of disk space alarms.

Follow these steps from within the ZENworks for Servers 3 management console to sort the Active Alarm or the Alarm History view:

  1. Open the alarm view you want to sort.

  2. Select View [image] Settings [image] Sort from the main menu in ConsoleOne.

  3. From the Alarm Sorting dialog box, shown in Figure 11.4, select the criteria by which you want the alarms to be sorted.

    Figure 11.4. Alarm Sorting dialog box for a ZENworks for Servers 3 site management object in ConsoleOne.

  4. Select the sort order: Ascending or Descending.

  5. Click OK to save your setting. The alarm view should be sorted according to your selections.
Filtering Alarms

ZENworks for Servers 3 also enables you to filter on alarms according to specific criteria after you bring up either the Active Alarm or the Alarm History view on the management console. This gives you even greater control to customize the view to meet more specific needs of the problems you are trying to resolve or reports that you need to prepare.

Table 11.1 shows the available criteria and options that you may want to use to filter alarms in the Active Alarm or Alarm History view.

Table 11.1. Criteria Available on Which to Filter Alarm Views

CRITERIA

OPERATORS

VALUES

Severity

=(equals), !=(does not equal), > or <

SEVERE, MAJOR, MINOR, INFORMATIONAL.

Generator typ

=(equals) or !=(does not equal)

Only SNMP (unless you have additional alarm generator types on your network).

Alarm category

=(equals) or !=(does not equal)

Any one of the alarm categories available in the MIB—that is, Antivirus-MIB, LANDesk-Alarm-MIB, NetWare-Server-Alarm-MIB, and so on.

Alarm type

=(equals) or !=(does not equal)

Any one of the alarm types provided on the alarm system—that is, Threshold—cache buffers, System: Trap NLM Loaded, and so on.

Source address

=(equals) or !=(does not equal)

IP address of the source on which to filter. This enables you to filter on a specific device.

From

=(equals), !=(does not equal), contains, starts with, or ends with

Full distinguished name of a ZENworks for Servers 3 management site server. This lets you filter on a single site if you are using site forwarding.

Alarm owner

=(equals), !=(does not equal), contains, starts with, or ends with

Full distinguished name of a user or group that is responsible for alarms. This could be used to view the alarms that you are currently responsible for.

Alarm summary

=(equals), !=(does not equal), contains, starts with, or ends with

Any text string that may equal, start, end, or be contained in the alarm summary string. If you were looking at lost connection issues, for example, you could filter on Lost Connection and use the contains operator.

Follow these steps from within the ZENworks for Servers 3 management console to filter the Active Alarm or the Alarm History view:

  1. Bring up the view that you want to filter.

  2. Select View [image] Settings [image] Filter from the main menu in ConsoleOne. The Alarm Filter dialog box, shown in Figure 11.5, appears.

    Figure 11.5. Alarm Filter dialog box for a ZENworks for Servers 3 site management object in ConsoleOne.

  3. Select the criteria by which you want the alarm management system to filter alarms from the drop-down list on the left.

  4. Select an appropriate operator, from Table 11.1, to use from the next drop-down list.

  5. Select an appropriate value from the third drop-down list, or specify a value if one is not provided.

  6. Specify how this specific filter relates to other statements you want to define. You can use the AND, OR, new row, delete row, and new group relationship criteria. This enables you to add multiple filters and groups of filters to the alarm view, as shown in Figure 11.5.

  7. If you defined relationship criteria in Step 6, repeat Steps 3 through 6.

  8. When you finish specifying filters, click the OK button. The filter is saved and the view is adjusted according to your criteria.
Viewing Alarm Summary

ZENworks for Servers 3 enables you to view a summary of the alarms for a managed site. The Alarm Summary view provides you with concise—but complete—data about the alarms that have occurred on your network over the past day, week, or month.

The following list breaks down the information displayed in the Alarm Summary view shown in Figure 11.6:

  • Severity Disposition. Displays a pie chart breaking out the alarms based on their severity. This information is useful to find out how many critical alarms your network is seeing. You can, for example, view this in terms of days, weeks, and months to determine whether your network is getting healthier or sicker.

  • Category Disposition. Displays a pie chart breaking out the alarms based on the alarms category. This information is useful to help you understand where your network may need to grow or where problems need to be resolved.

  • Owner Disposition. Displays a pie chart breaking out the alarms based on the owner of the service that triggered the alarm. This information is useful for helping you know where to begin troubleshooting issues.

  • State Disposition. Displays a pie chart that breaks down the alarms based on the state that they are in. This information helps you understand the duration of the alarms on your network. If the active state, for example, is the majority of the pie chart, you know that the alarms are active much of the time and the issues are much more severe.

  • Top Alarm Types. Displays a bar graph of the alarms that are triggered most often. This information helps determine which services are being affected most on your network.

  • Top Affected Nodes. Displays a bar graph of the nodes where alarms are triggered most often. This information helps determine which nodes and/or segments need the most attention in terms of growth and optimization.

  • Top Source Address. Displays a bar graph of the network addresses where alarms are triggered most often. This information enables you to understand on what segments, routers, and so on problems are occurring.

  • Arrival Rate. The arrival rate is a line graph that shows the number of active alarms based on a time interval. The arrival rate shows you the number of alarms that are active at any given time. This information is extremely useful to understand network issues that have to do with time. If you are getting numerous alarms at the same time in the morning, for example, you can look at when employees are arriving at work and logging in to the network. You may need additional hardware to handle the morning login or perhaps stagger the time employees can log in to the network.

Figure 11.6. Alarm Summary view for a ZENworks for Servers 3 site management object in ConsoleOne.

The Alarm Summary page enables you to use the following options from the Alarm Summary view to customize what data is displayed:

  • Select Interval. The Select Interval drop-down menu enables you to view data collected from the last day, week, or month. This information is extremely important in giving you an understanding of how the network's status changes over a period of time.

  • Refresh Every. The Refresh Every check box instructs ZENworks to refresh the data every 10 seconds, 30 seconds, or 1 minute.

  • Customize. The Customize button enables you to configure what information is displayed in the Alarm Summary view. You can disable any of the statistics, and you can set the number of top alarm types, top affected nodes, and top source addresses to display in the bar graphs.

Managing Alarms

Now that you understand how to detect and view network alarms from the ZENworks for Servers 3 management console, you need to know how to manage them on large networks. This sort of management is especially important if numerous administrators are managing different aspects of the management site.

ZENworks for Servers 3 adds options to the alarm to enable you to assign, own, and handle alarms. This feature helps you keep track of who is responsible for what issues and which issues have been resolved.

After you select an alarm from the Active Alarm or the Alarm History view, you can manage the alarm by selecting one of the following options for it from the View menu in ConsoleOne:

  • Assign. The Assign option enables you to specify a person or group that is responsible for handling an alarm. When this option is set, other administrators know that they do not need to respond to it.

  • Own. When you select Own from the View menu of an alarm in ConsoleOne, the owner that is filed changes to the NDS name as which you are logged in. This lets other administrators know that you are handling this alarm. Therefore, they do not need to act on the alarm and they have a person to contact for estimated resolutions and so forth.

  • Handle. After someone has handled an alarm, you can select Handle, and the alarm is removed from the Active Alarm view. This removes the alarm from active issues that need resolving, enabling administrators to focus on current problems. But the alarm still shows up on the Alarm History view.

  • Note. You can use the Note option from the Active Alarm view menu to add any special comments or notes about the alarm. After a note has been added to an alarm, the alarm's icon changes to one with a small icon designating that the alarm has a special note attached to it. The note can be viewed in the alarm information pane when the alarm is selected.

  • Jump. You can select Jump from the Active Alarm view menu to jump directly to the object that triggered the alarm. This gives you faster access to the object to troubleshoot issues.

Setting Alarm Actions

One of the most powerful features of the ZENworks for Servers 3 alarm management system is its ability to perform actions automatically to help you manage alarms as they are triggered. You can use the ZENworks for Servers 3 management console to configure an alarm to automatically trigger an action when it occurs.

Alarm actions are configured through alarm dispositions. Follow these steps to access the Alarm Disposition page, shown in Figure 11.7, and to configure alarm actions in ConsoleOne:

  1. Select the ZENworks for Servers 3 site management object on which you want to configure alarm dispositions.

  2. Select the Alarm Disposition tab.

  3. Select the alarm you want to configure from the list.

  4. Click the Edit button to bring up the Edit Alarm Disposition dialog box.
Figure 11.7. Alarm Disposition tab for a ZENworks for Servers 3 site management object in ConsoleOne.

ZENworks for Servers 3 has added a Sort button to the Alarm Disposition tab that enables you to define a template for ZENworks to use when sorting alarms. This capability is extremely useful to help you analyze and understand the nature of alarms that are occurring on your network. You could, for example, narrow down problem services by setting up a template to sort by the alarm type.

To set up a template to sort alarms, click the Sort button shown in Figure 11.7 to bring up the Template Sorting dialog box. From the Template Sorting dialog box you can define a sort template based on up to four of the following different criteria types:

  • Severity. Severity of the alarm.

  • Generator Type. Type of service that generated the alarm.

  • Category. The classification of the alarm.

  • Type. The specific type of the alarm.

The following sections discuss the actions to be performed when an alarm is triggered, and that are available from the Edit Alarm Disposition dialog box.

Sending Email Notification

The first available option from the Alarm Disposition dialog box is the capability to send an email notification to a user or group. It is very useful to be notified when critical alarms occur on the network.

Network administrators use this feature for various kinds of notification. Some have their SMTP mail servers configured to page them with the notification email when it is received.

Follow these steps to configure an email notification action for an alarm from the Edit Alarm Disposition dialog box in ConsoleOne:

  1. Select the SMTP Mail Notification tab, shown in Figure 11.8.

    Figure 11.8. SMTP Mail Notification tab of an alarm disposition for a site management object in ConsoleOne.

  2. Select the Notify through SMTP Mail option.

  3. In the SMTP Host text box, specify the IP address of the SMTP host server that handles incoming and outgoing email.

  4. In the From text box, specify the mail ID you want to use. This information is usually important for any additional automation on the back end.

  5. In the To text box, specify the mail IDs of the users or groups you want to notify when the alarm is triggered.

  6. In the Subject text box, specify the subject line you want to appear on the mail message that is sent. This information is also often important for additional automation on the back end. You can also add variables to the subject line by using a % sign in front of them. Table 11.2 lists variables that might be useful in the email Subject line.

  7. In the Message text box, specify the text message you want to appear in the body of the email that is sent. This message should include a description of what the alarm means. You can also add variables to the subject line by using a % sign in front of them. Table 11.2 lists variables that might be useful in the email body.

  8. Click the OK button to save your settings and return to the Alarm Dispositions tab.

Table 11.2. Available Variables for Use in the Subject and Message Options for SMTP Mail Notifications

VARIABLES

NAME

DESCRIPTION

a

Alarm ID

Identification number of the alarm as it is stored in the database

c

Affected Class

Class of the device that sent the alarm

o

Affected Object Number

Identification number, from the database, of the node that generated the alarm

s

Alarm Summary String

Message describing the alarm (same message that is displayed in the status bar ticker tape message)

t

Alarm Type String

Description of the alarm (same as the description in the Alarm Type element of the Alarm summary window)

v

Severity Number

Alarm severity level:

1 = Critical

2 = Major

3 = Minor

4 = Informational

Launching an Application

The next option available from the Alarm Disposition dialog box is the capability to launch an application. This option enables you to specify an NLM to be launched when an alarm is triggered on a server.

If your network utilization is too high, for example, you could launch an NLM that shuts down noncritical applications that normally consume high amounts of network bandwidth.

From the Edit Alarm Disposition dialog box in ConsoleOne, follow these steps to configure an external program to be launched when an alarm is triggered:

  1. Select the Launching Application tab, shown in Figure 11.9.

    Figure 11.9. Launching Application tab of an alarm disposition for a site management object in ConsoleOne.

  2. Select the Launch Application option.

  3. Specify the application path and filename in the Application Name text box.

  4. Specify any additional arguments in the Argument text box. You can use variables listed in Table 11.2 as parameters by preceding them with the % sign.

  5. Click the OK button to save your settings and return to the Alarm Dispositions tab.

NOTE

The Application Name field cannot exceed 126 characters in total length. The Argument field cannot exceed 119 characters in total length. The combined total of the Application Name and the Argument fields cannot exceed 139 characters in total length.

Forwarding the SNMP Trap

The next option available from the Alarm Dispositions dialog box is the capability to forward the SNMP trap to another management system. This option enables you to specify the IP address of another management station or server to which to forward the SNMP trap.

If you had another SNMP management system, for example, in addition to ZENworks for Servers 3, and wanted that system to receive the trap as well, you could send an SNMP trap to that management system, too.

From the Edit Alarm Disposition dialog box in ConsoleOne, follow these steps to configure an IP address to which the SNMP trap should be forwarded:

  1. Select the SNMP Trap Forwarding tab, shown in Figure 11.10.

    Figure 11.10. SMTP Trap Forwarding tab of an alarm disposition for a site management object in ConsoleOne.

  2. Enter the IP address of the server to which you want to forward the SNMP traps in the SNMP Target Address field.

  3. Click the Add button to add it to the list of targets.

  4. Click the OK button to save your settings and return to the Alarm Dispositions tab.
Forwarding the Alarm

The next option available from the Alarm Dispositions dialog box is the capability to forward the alarm to another ZENworks for Servers 3 management site. This option enables you to specify a ZENworks for Servers 3 management site name and hostname to which to forward the alarm.

From the Edit Alarm Disposition dialog box in ConsoleOne, follow these steps to configure another ZENworks for Servers management site to which the alarm should be forwarded:

  1. Select the Alarm Forwarding tab, shown in Figure 11.11.

    Figure 11.11. Alarm Forwarding tab of an alarm disposition for a site management object in ConsoleOne.

  2. Enter the ZENworks for Servers 3 management site name to which you want to forward the alarm in the Site Name field.

  3. Enter the ZENworks for Servers 3 site host name in the Site Host field.

  4. Click the Add button to add it to the list of targets.

  5. Click the OK button to save your settings and return to the Alarm Dispositions tab.
Additional Alarm Disposition Actions

The final options panel available from the Edit Alarm Disposition dialog box is the Other Configuration tab, shown in Figure 11.12. This tab enables you to configure the following actions to be performed when an alarm is triggered:

  • Archive. Stores the statistical data for the alarm instance in the Alarm Manager database on the management server. If you want to see the alarm in the Alarm History view, you need to select this option. It is on by default.

  • Show on Ticker Bar. Displays a message of the alarm on the ZENworks for Servers 3 management console status bar to silently notify the administrator of the most recent alarm.

  • Beep on Console. Sends an audible beep to the ZENworks for Servers 3 management console to notify the administrator that an alarm has been triggered.

Figure 11.12. Other Configuration tab of an alarm disposition for a site management object in ConsoleOne.

Follow these steps to configure additional options for the alarm from the Edit Alarm Disposition dialog box in ConsoleOne:

  1. Select the Other Configuration tab (see Figure 11.12).

  2. Set the Archive option if you want to save the alarm to the Alarm Manager database.

  3. Set the Show on Ticker Bar option if you want a message to be displayed in the management console's status bar.

  4. Set the Beep on Console option if you want the alarm to send an audible beep to the management console.

  5. Click the OK button to save your settings and return to the Alarm Dispositions tab.

Deleting Alarms

The final task you need to be familiar with when managing ZENworks for Servers 3 alarms is how to remove them when you are completely finished with them. The alarms take up space in the Alarm Manager database until they are removed. If you do not consistently keep the alarms cleaned out of the database, the database can begin to take up an excessive amount of hard drive space.

The following sections discuss how to manually and automatically remove unwanted alarms from the Alarm Manager database.

Deleting Alarms from the Management Console

You can manually delete alarms from the Alarm Manager database by simply deleting them from the ZENworks for Servers 3 management console. This is the best way to delete an individual alarm. But if numerous alarms have occurred, this process could be too time-consuming. If you have numerous alarms, instead use the automatic alarm deletion method described in the next section.

Follow these steps to manually delete an alarm from the Alarm Manager database from the management console:

  1. Navigate to the server or segment object on which the alarm occurred.

  2. Open the Alarm History view to display the alarms.

  3. Select the alarm you want to delete.

  4. Select View [image] Delete from the main menu and the alarm is deleted from the database.
Automating Alarm Deletion

The best way to handle the deletion of alarms is to automate the process by configuring the purge utility to delete the alarms for you. The purge utility is a Java application that runs on the server where the Alarm Manager database is stored.

The purge utility is controlled by a configuration file, AMPURGE.PROPERTY, which defines the criteria for selecting alarms to be purged as well as when to start purging alarms. The first step in using the purge utility to automatically delete alarms is to configure the criteria listed in Table 11.3 according to how long you need the alarms and when to start purging.

Table 11.3. Criteria for Purging Alarms Listed in the AMPURGE.PROPERTY File

CRITERIA SETTING

DESCRIPTION

SeverityInformationalPurgeWait

Specifies the number of days to wait before informational alarms are purged. The default is 7.

SeverityMinorPurgeWait

Specifies the number of days to wait before minor alarms are purged. The default is 7.

SeverityMajorPurgeWait

Specifies the number of days to wait before major alarms are purged. The default is 7.

SeverityCriticalPurgeWait

Specifies the number of days to wait before critical alarms are purged. The default is 7.

SeverityUnknownPurgeWait

Specifies the number of days to wait before unknown alarms are purged. The default is 7.

PurgeStartTime

Specifies the start time hour to begin the daily purge process. Valid values are from 0 (midnight) to 23 (11:00 p.m.).

AlarmPurgeService

Specifies whether to automatically run the purge process on a daily basis. You can specify either Yes (enable) or No (disable). Omitting this setting also disables it.

After configuring the criteria for purging alarms, you have two options. The first option is to wait for the start time that you specified the purge to begin. The second option is to manually start the purge process.

You may want to manually start the purge process because you turned off the automatic run by setting AlarmPurgeService to No, or because the database has grown too rapidly because of a network problem and you need to free up hard drive space.

Use the following command from the console of the server where the Alarm Manager database is stored to start the automatic purge process manually:

java com.novell.managewise.am.db.purge.AutoPurgeManager –s –d <properties_file_directory>

The properties_file_directory parameter should be replaced with the directory location where the AMPURGE.PROPERTY file is located.

NOTE

The purge process is highly memory- and CPU-intensive. Therefore, you should run the purge only during off hours or when it is truly needed—for example, at night, on weekends, or if the server runs out of disk space.


Using ZENworks for Servers 3 Monitoring Services

In addition to the alarm management services, ZENworks for Servers 3 provides monitoring services to monitor devices on the network. The ZENworks for Servers 3 alarm management system relies on agents either on the device or on the management server to capture events, turn them into alarms, and relay them to the management console.

The ZENworks for Servers 3 monitoring services does the opposite. It enables the management console to check the status of network devices from the point of view of the console itself. This enables you to be immediately notified if connectivity between the console and critical nodes is interrupted.

You should use the monitoring service as another option to monitor the status of the critical services on your network. The following sections describe how to define and configure target services you want to monitor.

Monitoring Services on Target Nodes

ZENworks for Servers 3 uses a ping method to monitor service status on target nodes. A ping packet is sent from a remote server to the target node. The remote server then waits for a specific interval. If a reply is received back from the target node before the interval elapses, the status of the server is up. If a reply is not received back from the target node before the interval elapses, the status of the server is down.

The following sections describe the different utilities and views that ZENworks for Servers 3 provides from the management console to monitor servers on one or more target nodes.

Testing a Single Target Node

ZENworks for Servers 3 provides the ping test as a quick method for you to monitor the status of a specific node. You should use the ping test if you suspect a problem with a specific node in the network.

The ping test provides you with the status—up or down—of communication from the management console to the node, as well as the round-trip delay for the ping to be received back.

Follow these steps to perform a ping test on a particular node from the management console:

  1. Select the node you want to monitor.

  2. Select File [image] Actions [image] Ping from the main menu. The Ping dialog box, shown in Figure 11.13, appears.

    Figure 11.13. Ping test results for a monitored server object in ConsoleOne.

  3. The IP address should be already displayed for you, if it is the default. But you can specify a DNS name or IPX address as well at this point. You can also specify a time in milliseconds to wait before timing out. Click the Apply button.

  4. View the status in the Ping Status area. The status continues to be updated at a configured interval.
Monitoring Services on Several Nodes

ZENworks for Servers 3 also enables you to monitor the services of several target nodes, from the management console through the use of a connectivity test utility and Polling view. Each of these options displays the following statistics, which are dynamically updated:

  • Target. The name or address of the node for which connectivity to services is being tested.

  • Service. The service that is being monitored on the target node.

  • Port. The port number of the service on the target node.

  • Status. The status, up or down, for the service. Up means that a ping packet is sent to the service and a reply is returned; it doesn't necessarily mean that the service is operating normally.

  • Roundtrip Delay. Time interval, in milliseconds, from when the remote ping server sends a ping to the target service and a reply is received back from the target.

  • Packets Sent. Number of packets that were sent from the remote ping server to the target node.

  • Packets Received. Number of packets received by the remote ping server that were sent from the target node.

  • Packets Lost. Number of ping packets and percentage of total packets that were lost during the connectivity testing.

  • Interval. Time, in seconds, the remote ping server waits after sending one ping packet before sending the next.

  • Timeout. Time, in milliseconds, the remote ping server waits for a reply from the target node before declaring the service in a down state.

The Polling view displays connectivity statistics for all configured services on the managed segment. This view can give you a quick understanding of a segment's current status, which can be extremely useful when trying to understand problems such as network outages or LAN overusage. To view the Polling view for a segment, select the desired segment in ConsoleOne; then select View [image] Polling from the main menu.

The connectivity test utility displays statistics for services from a selective group of nodes. You can tailor the Connectivity view to more closely meet your needs by adding only the most important nodes. Typically, you use the Connectivity view when you are troubleshooting issues on a selective group of servers.

Follow these steps to start the Connectivity view from the management console:

  1. Select the segment that contains the nodes in which you want to monitor services.

  2. Select the nodes on which you want to monitor services in the right pane of the console.

  3. Select File [image] Action [image] Connectivity Test from the main menu. A screen similar to the one in Figure 11.14 appears.

    Figure 11.14. Connectivity test results for a monitored segment object in ConsoleOne.

  4. Click the Add button, located in the button bar in Figure 11.14, to add services (discussed in the next section) to the view.
Adding Services to the Connectivity Test

After you have the connectivity test utility running, you can add new services to be monitored. This can be useful as you are monitoring connectivity issues on a node because it enables you to check all services on the monitored node to see whether all, some, or only a single service is affected.

ZENworks for Servers 3 enables you to monitor the following services on monitored nodes from the management console:

  • IP. Internet Protocol

  • IPX. Internet Packet Exchange

  • DNS. Domain Name System

  • DHCP. Dynamic Host Configuration Protocol

  • ECHO. Echo Protocol

  • FTP. File Transfer Protocol

  • TFTP. Trivial File Transfer Protocol

  • HTTP. Hypertext Transfer Protocol

  • HTTPS. Hypertext Transfer Protocol Secure

  • SNMP. Simple Network Management Protocol

  • SMTP. Simple Mail Transfer Protocol

  • TIME. Time Services

  • WUSER. Windows User

  • NNTP. Network News Transfer Protocol

  • NFS. Network File System

From the connectivity test utility, follow these steps to add services to the Connectivity Test window:

  1. Select the target node from which you want to monitor another service—or, if you want to add a server from a node not already listed, select any node.

  2. Click the Add button. The Add Ping Targets dialog box, shown in Figure 11.15, appears.

    Figure 11.15. Add Ping Targets dialog box for the connectivity test on a monitored segment object in ConsoleOne.

  3. If you are adding a service from a node not already listed, type the name, IP address, or IPX address in the Ping Target field.

  4. Select the service from the drop-down menu, or click the Plus button next to the Service field and specify a new service and port number.

  5. Specify the interval at which you want to ping the service in the Ping Interval field.

  6. Specify the amount of time you want to wait for a ping reply before determining that the service is down in the Timeout After field.

  7. Click the Close button to add the service to the monitor list and close the Add Ping Targets dialog box, or click the Apply button to add the service to the list but keep the dialog box open to add more services.

Setting Up Monitoring Services on Monitored Nodes

You must configure monitoring services on each node you want to monitor from the Polling view in the management console. The connectivity test utility simply uses a list of targets to test; however, the Polling view must read the node object contained within it and check for nodes with monitoring services enabled on them before they can be added to the view.

Follow these steps from the management console to configure and enable monitoring services on nodes you want to monitor:

  1. Select the segment on which you want to monitor nodes.

  2. Select a node located in the selected segment for which you want to configure monitor services.

  3. Right-click the node and select Properties from the pop-up menu.

  4. Select the Monitor Services tab, as shown in Figure 11.16.

    Figure 11.16. Monitor Services tab of managed server node object in ConsoleOne.

  5. Select the IP or IPX address you want to use for the node. If the node is connected to multiple segments, make certain that you use the address for the segment you want to monitor.

  6. Select the services that you want to monitor on the node and click the Add button, or you can also click the Add Service button to specify a new service name and port number.

  7. Set the polling interval to ping the server in the Interval field.

  8. Set the amount of time to wait for a reply from the service before declaring it down in the Timeout After field.

  9. Specify whether to send an alarm if the state changes either from up to down or down to up.

  10. Click the Apply button to save the changes.


Chapter 12. Using ZENworks for Servers 3 Server Management

One of the most difficult tasks enterprise network administrators must face is how to manage the numerous servers on their network. This chapter discusses the powerful tools and services included with ZENworks for Servers 3 that help you manage your network servers.


Using ZENworks for Servers 3—SMNP Agents to Manage Servers

ZENworks for Servers 3 has several management agents that enable you to configure, monitor, and manage servers from a single console interface.

Understanding SNMP-Based Server Management

One of the biggest advantages in using ZENworks for Servers 3 to manage your servers is that its server management agents support the industry standard Simple Network Management Protocol (SNMP). These ZENworks for Servers 3 server management agents also support the UDP/IP, IPX, and NCP implementations for packet sending. Therefore, any SNMP console or manager can request information from them.

The ZENworks for Servers 3 server management agents run on both NetWare and Windows NT/2000 Servers in your network. These agents continuously monitor the servers and collect dynamic data in response to requests from the management console.

ZENworks for Servers 3 uses several different management agents to manage servers.

  • Monitoring. The server monitoring agents provide instant information about the current state of the monitored elements of the server, including CPU utilization, memory size, available cache buffers, connected users, volumes, disks, disk space usage per user, network adapters, available print queues, current print jobs, and NLMs loaded on the server.

  • Trending. The server trend agents provide historical data about various server objects and can be displayed in a graphical diagram on the ZENworks for Servers 3 management console. The trend data is stored on the managed server, which eliminates the need for extra LAN traffic to poll the SNMP Agent Manager.

  • Alarm notification. The server alarm notification agents monitor for predefined alarms or events and then notify the ZENworks for Servers 3 management system (or any SNMP management console). Currently, ZENworks for Servers 3 agents monitor more than 580 different types of alarms or events. Any Windows NT/2000 system, security, or application event is converted to an SNMP trap and sent to the management system as well.

  • Configuration management. The server configuration management agents for NetWare servers enable you to remotely view and modify the NetWare server's configuration from the management console. The configuration management agent enables you to modify 187 SET parameters on the NetWare server to tune performance.

NOTE

The ZENworks for Servers 3 SNMP agents must be installed on every server you want to manage.

Discussing the ZENworks for Servers 3 Management Views

The ZENworks for Servers 3 management agents provide information to the administrator's management console through the use of server management views. You can access the following three main types of server management views by selecting a server or network node from the ZENworks for Servers 3 namespace in ConsoleOne:

  • Console view. Provides details about the selected server or node. You can also drill down into the server configuration to display information about the internal component of the server—for example, operating system version, installed devices, and memory.

  • Summary view. Provides details about the server's current performance—for example, alarms generated by the server, CPU utilization, and available disk space. Once again, you can drill down into the server configuration and view summary information about its components—for example, processor, running threads, memory, and NetWare volumes.

  • Trend view. Provides a graphical representation of the trend parameters set up for the server. This enables you to monitor server's state trends over specific periods of time. Then, using this trend data, you can track the server's general health status and predict potential problems and needs for growth.

Planning Server Management

Now that you understand the ZENworks for Servers 3 management agents and the console interface used to monitor your server's state, you need to do a little planning to get the most out of the data that ZENworks for Servers 3 provides you.

This section discusses how to use the data you obtain from the ZENworks for Servers 3 console views to create a baseline document. You then find out how to use that baseline document to monitor, troubleshoot, and optimize your servers.

Creating a Server Baseline Document

You should create a baseline document that defines the normal activity and usage of your network servers. This document is later used to identify atypical performance or problems on your servers.

You can create a baseline document either from data out of the Trend view or from a server health report (see the information on health reports in Chapter 13). The following elements are vital for every baseline document:

  • CPU utilization. The CPU utilization statistic indicates how busy the processor is on the server. High CPU utilization greatly impacts the server's performance. CPU utilization rises and falls with user and network activity throughout each day. CPU utilization, for example, is usually high first thing in the morning when all the users are logging on to the server and reading email, or on Friday when large weekend reports are being run. You should create a daily, weekly, and monthly graph for your baseline document, if necessary, to map out an expected CPU utilization pattern.

  • Cache buffers. Cache buffers represent the amount of server memory usable for processes. The availability of cache buffers greatly impacts the server's performance. Once again, the available cache buffers rise and fall during the day based on users and application usage. You should typically have between 65–70% of your cache buffers available to applications. Create a daily graph for your baseline document showing the typical trend of cache buffers on your server.

  • File reads and writes. The file reads and writes by the server should also be graphed into a baseline document. This helps you determine whether a server is performing a high or low number of file I/Os.

  • Volume utilization. You should also create a graph showing typical volume usage as users create and delete files. This is useful in determining when you must add storage space to a volume.

  • Running software. Another useful parameter to add to a baseline document is the software running on the server. This helps you in network planning and troubleshooting software issues.

Using a Server Baseline Document

After you create a baseline document, you should keep it available and up to date. The following sections describe situations in which the baseline document can be useful.

Setting Alarm Thresholds

The most useful function of a baseline document is its capability to help you understand what thresholds to set for servers monitored by management agents. You can use the baseline document statistics to set alarm threshold values that alert you when normal server usage is being surpassed—for example, the server starts running out of memory or disk space.

Tracking Server Utilization

Another useful function of a baseline document is to help you track server utilization. You can use the current and past data to evaluate the server's usage trends and understand needed configuration changes. You can, for example, use the baseline document to predict a volume running out of disk space, available cache buffers insufficient for running software, and so forth.

Server Troubleshooting

The final function of a baseline document is to aid you in troubleshooting your servers. Using the typical data in the baseline document, you can recognize atypical behavior of your servers, which will help you isolate the problem. For example, suppose that a server is running out of memory. You compare the baseline document to the server's current state and notice that the only difference is that a new application is running on the server. The first step in troubleshooting is to remove the application.

Displaying Server Configuration Information

Using the ZENworks for Servers 3 namespace in ConsoleOne, you can display and view critical configuration information about your servers. You can then use this information to manage and control the servers on your managed network. The following is a list of the configuration information components and information that you can retrieve about your managed servers through the ZENworks for Servers 3 namespace:

  • Processors. Processor number, type, speed, bus, and utilization

  • LAN adapters. Driver name, adapter number, MAC address, and usage

  • Disk adapters. Drive number and type

  • Storage devices. Drive number, vendor name, partition types, size, ID, redirection information, and fault tolerance

  • OS kernel threads. Thread name, parent NLM, execution time, state, stack size, and affinity

  • OS kernel interrupts. Interrupt name, number, number of occurrences, execution time, type, processor, service routines, and spurious interrupts

  • OS kernel memory. Memory type, size, maximum size, and usage

  • OS kernel address spaces. Space name, number of NLMs loaded, mapped pages, restarted bits, memory, and block usage

  • Network interfaces. Protocol name, board name, board number, packets out, packets in, address, and descriptions

  • Network connections. Connection number, username, client address, state, privileges, connection time, bytes read/written, NCP requests, open files, and locked files

  • Users. Username, disk usage, last login time, account and password status, real name, and bad logins

  • Installed software. Application name, type, and date installed

  • NLMs. Filename, version, release date, memory usage, description, copyright, and resource tag information

  • File services. Volume name, segment number, segment index, logical ID, physical ID, size, fault tolerance, and disk name

  • RMON services. Agent name and version, IP and/or IPX address, number of interfaces, current status, agent type, resources, owners, and indexes

To access the server configuration from within the ZENworks for Servers 3 namespace in ConsoleOne follow these steps:

  1. Locate the server object about which you want to display configuration information.

  2. Click the + sign next to the server object to expand the view. The view should expand to reveal the configuration devices, operating system, and services configuration data groups.

  3. Click the + sign next to each of the data groups and data elements to reveal data about each configuration component, as shown in Figure 12.1.

    Figure 12.1. Server configuration groups and components located in the ZENworks for Servers 3 namespace in ConsoleOne.

Showing Server Summary Data

Displaying the configuration data for each individual component gives you a lot of extremely detailed and useful information. At times, however, you may want to take only a quick look at a server's configuration information. For this reason, ZENworks for Servers 3 also enables you to display a quick summary view of the most vital information about the managed server.

ZENworks for Servers 3 uses a series of SNMP GET requests to the ZENworks for Servers 3 management agents to create a quick collection of summary data. That summary data is dynamically updated by ZENworks for Servers 3 as it continuously polls the server.

To access the summary information about a server, right-click the server object and then select Views [image] Summary from the pop-up menu. A screen similar to the one in Figure 12.2 appears, showing the following information about the managed server:

  • Server Type. Tells you whether it is a NetWare server or an NT/2000 Server.

  • Server Name. Lets you know for which server you are viewing the summary.

  • Server Tree. Useful when troubleshooting eDirectory.NDS issues.

  • Description. Tells you the server type, version, and revisions. This is useful in determining whether a support pack has been applied to the server.

  • Location. If a Location field is set up for the server in the management database, that location shows up here. This is essential if you have a WAN with numerous servers located in several different buildings, cities, or countries.

  • Contact. Useful for finding the person responsible for the server, because most enterprise networks are partitioned and administered by several different people.

  • IP Address. Gives you the IP address and subnet mask for the server.

  • IPX Address. Gives you the IPX address and network number for the server.

  • Total RAM. Indicates total RAM installed, which is useful in troubleshooting server problems.

  • Up Time. Knowing the server's up time is very useful for things such as identifying when the server was last serviced, whether the server has been down recently, or whether the server has experienced critical problems and reset itself.

  • Date/Time. The current time that the server thinks it is. This is helpful if you are having any issues involving time synchronization in eDirectory.

  • Service Summary. Lists the services that are currently available on the server. This can be helpful if you are browsing servers to find a candidate to take on extra services.

  • Logged in Users. Gives you the number of users currently logged in to the server.

  • Open Files. Gives you the number of files that are currently open on the server.

  • Server Status. If for any reason the server cannot be contacted, the most recent summary data is collected and the server shows up as being down.

  • Managed Events. All events that are monitored by ZENworks for Servers 3 and that occur on the server are listed. This list can be extremely useful in understanding the current state of a server, because alarms are also listed.

  • CPU Utilization. Displays a speedometer of the current percentage of utilization of the server's CPU.

  • Volume Data. Displays the mount status and free and used space on the server's volumes.

  • Cache Activity. Displays a graph showing the history of the server's cache memory in terms of cache hits and percentage of free cache buffers.

Figure 12.2. Server summary of a NetWare server, located in the ZENworks for Servers 3 namespace in ConsoleOne.

NOTE

ZENworks for Servers 3 also enables you to display similar summary data for processors, LAN adapters, disk adapters, storage devices, threads, interrupts, memory, address spaces, interfaces, connections, users, installed software, NLMs, and volumes.

Viewing Trend Data

Trend data is another important aspect of your servers that ZENworks for Servers 3 enables you to view and monitor. ZENworks for Servers 3 is continuously gathering data about the trends in CPU usage, memory usage, and network traffic from the managed server as it is operating.

You can view the trend data from the management console in terms of current data or historically by day, week, month, or year. That trend data can be extremely useful in troubleshooting network and server issues, as well as understanding the current workload on the server.

You should monitor the trend data to help with decisions on setting trend alarm thresholds, determining peak usage of the server, balancing server loads, and allocating new resources. To view the trend data from the management console, right-click the server you want to monitor and select Views [image] Trend from the pop-up menu; a screen similar to the one in Figure 12.3 should appear.

Figure 12.3. Trend Data view of a NetWare server, located in the ZENworks for Servers 3 namespace in ConsoleOne.

ZENworks for Servers 3 enables you to customize the Trend Data view to give you the data's maximum use. The following sections describe how to customize the Trend Data view by displaying the legend, modifying time spans, displaying grid lines, stacking/unstacking graphs, and modifying the Trend view profile.

Displaying the Legend

You must display a legend to understand the Trend Data view shown in Figure 12.3 and use it to understand the server's current status. The legend is simply a window that relates the trend data parameters used in the Trend Data view with its color of line shown on the graph. Viewing the legend helps you understand what trends are being displayed on the server so that the graph makes sense.

To view the Trend Data view legend, click the Legend icon in the Trend Data view toolbar (refer to Figure 12.3). A pane similar to the one in Figure 12.4 appears.

Figure 12.4. Legend window for the Trend Data view in ConsoleOne.

Modifying Time Spans

After you view the legend and understand what parameters the graph is showing you, you can modify the time spans for the trend data to best understand how the server is doing. You can modify the time span by clicking the down arrow on the toolbar of the Trend Data view and selecting one of the following time spans:

  • 1 Hour. Use the 1 Hour time span to show you the server's current status. At 9:00 a.m., for example, you may want to view the 1 Hour span to see how the server is doing during the morning login.

  • 1 Day. Use the 1 Day time span to see how the server did over the past 24 hours. This can be useful to see how the server performed over a workday, or overnight while reports and backups were running.

  • 1 Week. Use the 1 Week time span to monitor your servers week to week. This is the most commonly used time span to judge a server's overall usage and performance.

  • 1 Month. Use the 1 Month time span to monitor the long-term performance of your server. This can be helpful in determining increased workload trends.

  • 1 Year. Use the 1 Year time span to compare the usage of your servers over the past year. This can help you determine where more servers are needed or where you can reallocate users.

Displaying Grid Lines

Another task you can perform in the Trend Data view is to display horizontal and vertical grid lines. The grid lines make the graphs easier to read. You can turn on and off the horizontal grid lines by clicking the Horizontal Grid button on the Trend Data view toolbar. Conversely, you can turn on and off the vertical grid lines by clicking the Vertical Grid button on the Trend Data view toolbar.

Stacking and Unstacking Graphs

One of the most useful ways to customize your Trend Data view is to stack and unstack the graphs. Stacking the graphs means that they are all overlaid on top of each other on a single graph with several lines for all parameters. Unstacking the graphs makes several different graphs, each with its own line for a single parameter, as shown in Figure 12.5. (Figure 12.3 shows what a graph would look like stacked.)

Figure 12.5. Unstacked Trend Data view of a NetWare server, located in the ZENworks for Servers 3 namespace in ConsoleOne.

To stack the graphs on top of each other, click the Stack Chart button on the Trend Data view toolbar. To unstack the graphs, click the Strip Chart button on the Trend Data view toolbar.

Modifying the Trend Data View Profile

The biggest way to modify the Trend Data view is to modify the Trend Data view profile. The Trend Data view profile is basically the set of parameters that are displayed on the Trend Data view graph. You should modify the Trend Data view profile to best fit your servers and your environment. Follow these steps to modify the Trend Data view profile:

  1. Click the Profile button on the Trend Data view toolbar. A window similar to the one in Figure 12.6 appears.

    Figure 12.6. Trend Data view profile settings window for the Trend Data view in ConsoleOne.

  2. Edit the profile by clicking the parameters to either select or deselect them. Use the Shift+click and Ctrl+click methods to select multiple parameters.

  3. Click OK to apply the setting; the Trend Data view should be updated.

Managing Trend Samplings

Now that you understand how to view the trend data, you need to know how to manage the way that the data is collected. ZENworks for Servers 3 enables you to modify the trend data sampling rates and thresholds used to collect the data. The following sections discuss how to use the management console to customize trend sampling to fit your network.

Modifying Trend Samplings and Intervals

The first step in managing trend sampling is to set the sampling and interval rates for trend parameters. Setting the sampling rate effectively determines the duration for which data from a particular parameter is collected by specifying the number of samples to take. Setting the interval rate determines how often data is collected from a particular parameter. Follow these steps to set the sampling and intervals for trend data parameters:

  1. Right-click the server object and select Properties from the pop-up menu.

  2. Select the Trend tab, as shown in Figure 12.7.

    Figure 12.7. Trend tab for a managed server object in ConsoleOne.

  3. Select the trend parameter you want to modify and click the Edit button. An Edit Trend dialog box appears.

  4. From the State drop-down list in the Edit Trend dialog box, shown in Figure 12.8, select Enabled to enable trend sampling for the parameter.

    Figure 12.8. Edit Trend dialog box for trend data parameters in ConsoleOne.

  5. Modify the time interval by selecting a value from the Frequency drop-down list. Values are from five minutes to one day.

  6. Specify the duration of time for which to collect samples by entering a value in the Number of samples field.

  7. Click the OK button and the parameter is modified.
Modifying Threshold Alarm Settings

After you set the sampling and interval rates for the trend data parameter, you need to set the threshold alarm settings for the parameter. Modifying the threshold alarm settings for a particular parameter controls the range at which the parameter can operate before triggering an alarm. It also controls the scope of the graph in the Trend Data view. Follow these steps to modify the threshold alarm setting for a trend data parameter:

  1. Follow Steps 1–3 from the preceding section.

  2. From the Edit Trend dialog box, shown in Figure 12.8, select Enabled in the Alarm section to enable trend sampling for the parameter.

  3. Set the Rising Threshold to a value that reflects a safe amount for the parameter.

  4. Set the Falling Threshold to a value that reflects an unhealthy state for the parameter.

  5. Click the OK button and the parameter is modified.

NOTE

An alarm is sent the first time the rising threshold is surpassed, and if the parameter never dips back below the falling threshold, an alarm is not re-sent. In other words, for an alarm to be sent again after it has already been sent once, the parameter has to dip down below the falling threshold and then surpass the rising threshold again.

Configuring Server Parameters

Another server management innovation that ZENworks for Servers 3 provides is the capability to modify server parameters without being at the server itself or having a remote management session open to it. ZENworks for Servers 3 enables you to modify the managed server's eDirectory object to make changes to its parameters. Follow these steps to modify server parameters from within ConsoleOne:

  1. Select the Operating System resource under the NetWare server object in the atlas namespace.

  2. Right-click the Operating System resource and select Properties from the pop-up menu.

  3. Select the Set Parameters tab.

  4. Click the down arrow and select the category of set parameters you want to change from the drop-down list, as shown in Figure 12.9.

    Figure 12.9. Set Parameters tab for server objects in the atlas namespace in ConsoleOne.

  5. Select the specific parameter you want to modify, and then click the Edit button.

  6. From the Edit Parameters dialog box, shown in Figure 12.10, enter the new value for the parameter into the field. (The field type changes based on the parameter selected.)

    Figure 12.10. Edit Parameters dialog box for server set parameters in ConsoleOne.

  7. Indicate when you want the change to occur by selecting one of the following times: Now, Until Reboot (the change disappears after the server is rebooted), Only After Reboot (the change does not take effect until the server is rebooted), or Now, and After Reboot (the change is made immediately and permanently).

  8. Click the OK button and the change to the parameter is made according to the criteria you selected.

NOTE

The preceding steps are a way to manually change set parameters on a server-by-server basis. If you want to do this on more than one server at a time throughout your network, you would use the Server Policy Package—Set Parameters policy in the policies piece of ZENworks for Servers 3.

Executing Server Commands

Another server management innovation that ZENworks for Servers 3 provides is the capability to execute server commands without being at the server itself or having a remote management session open to it.

Earlier in this chapter, you learned how to navigate the server object portion of the ZENworks for Servers 3 namespace to view configuration data. You can also use the server level of the ZENworks for Servers 3 namespace to execute server commands at the server level or below.

ZENworks for Servers 3 enables you to execute the following server commands from the ZENworks for Servers 3 namespace area in ConsoleOne:

  • Loading and unloading NLMs. You can load or unload an NLM by right-clicking the NLM object in the ZENworks for Servers 3 namespace and selecting Load or Unload from the Actions menu.

  • Mounting and dismounting volumes. You can mount or dismount a volume by right-clicking the volume object in the ZENworks for Servers 3 namespace and selecting Mount or Dismount from the Actions menu.

  • Clearing a server connection. You can clear a server connection by right-clicking the connection in the ZENworks for Servers namespace (Server [image] Operating System [image] Network [image] Connections) and selecting Clear Connection from the Actions menu.

  • Restarting a server. You can restart a server by right-clicking the server object in the ZENworks for Servers 3 namespace and selecting Restart Server from the Actions menu.

  • Shutting down a server. You can shut down a server by right-clicking the server object in the ZENworks for Servers 3 namespace and selecting Down Server from the Actions menu.

Managing Remote Servers

Managing servers remotely has become an industry standard as companies have increased the number of servers, which requires large data centers. ZENworks for Servers 3 greatly enhances the capability to remotely manage servers through the addition of applications that enable you to remotely take control of the server. The following sections describe how to use the ZENworks for Servers 3 management console to remotely manage a server.

Managing Remote NetWare Servers

ZENworks for Servers 3 includes the capability to use the RCONSOLEJ utility provided with NetWare to remotely manage a server from the management console. This enables you to manage NetWare servers based on your role in the organization and tasks assigned to you.

You can use the ZENworks for Servers 3 remote management capability to perform the following role-based remote management tasks on a managed NetWare server:

  • Console commands. Remotely execute console commands as if you were at the server. You may, for example, want to execute a command to start or stop an eDirectory trace.

  • Scan directories. Scan directories looking for installed software, data files, or file locations.

  • Edit text files. Edit text files on both NetWare and DOS partitions to modify scripts or other files.

  • Transfer files. Send files to the server to update an application or data. You cannot transfer files from a server for security reasons.

  • Install or upgrade. Perform an install or upgrade. You can, for example, remotely install the latest NetWare support pack to the server.

Follow these steps to begin a remote management session with a NetWare server from the ZENworks for Servers 3 management console on an IP-only server:

  1. Load the RCONSOLEJ agent (RCONAG6.NLM) on the NetWare server.

  2. Right-click the server object in ConsoleOne and select Actions [image] Remote Console from the pop-up menu.

  3. Enter the RCONSOLEJ agent password.

  4. Enter the TCP port number on which the agent will listen for requests from RCONSOLEJ. (The default value is 2034.)

  5. Click the Connect button and an RCONSOLEJ session similar to the one shown in Figure 12.11 loads.

    Figure 12.11. RCONSOLEJ remote management session launched from ConsoleOne.

Follow these steps to begin a remote management session with a NetWare server from the ZENworks for Servers 3 management console on an IPX-only server:

  1. Load the RCONSOLEJ agent (RCONAG6.NLM) on the NetWare Server.

  2. Right-click the server object in ConsoleOne and select Actions [image] Remote Console from the pop-up menu.

  3. Enter the RCONSOLEJ agent password.

  4. Enter the TCP port number on which the agent will listen for requests from RCONSOLEJ. (The default value is 2036.)

  5. Enter the IP address of the proxy server or choose a proxy server in the Proxy Server options section of the RCONSOLEJ window. The server acting as a proxy server for the RCONSOLEJ session needs to be running both IP and IPX so that it can communicate with both the workstation and the IPX server.

  6. Enter the SPX port number on which the agent is to listen for requests from the proxy server. (The default value is 16801.)

  7. Click the Connect button and an RCONSOLEJ session similar to the one already shown in Figure 12.11 loads.
Managing Remote NT/2000 Servers

ZENworks for Servers 3 adds the capability to remotely manage a Windows NT/2000 Server from the management console. This enables you to manage Windows NT/2000 Servers based on your role in the organization and tasks assigned to you.

You can use the ZENworks for Servers 3 remote management capability to perform the following role-based remote management tasks on a managed Windows NT/2000 Server:

  • Remote control. Enables you to remotely take control of a Windows NT/2000 Server to resolve any software-related problems and perform any administrative tasks.

  • Remote view. Enables you to remotely view the desktop of the Windows NT/2000 Server. This enables you to monitor activity on the NT server and see when actions are performed.

Follow these steps to begin a remote management session with a Windows NT/2000 Server from the ZENworks for Servers 3 management console:

  1. Verify that the remote management agent installed with the ZENworks for Servers 3 install is running on the Windows NT/2000 Server you want to manage.

  2. Select the server object from within ConsoleOne.

  3. Select Tools [image] Remote Management [image] Windows.

  4. Specify the Agent to use to initiate the remote management session.

  5. Select Remote Control or Remote View from the drop-down menu.

  6. Enter the password for the ZENworks for Servers 3 remote management agent. The remote management session should activate.

NOTE

During a remote management session, the user of the Windows NT/2000 Server receives an audible signal indicating that it is being accessed. Every five seconds the user receives a visible signal displaying the name of the user accessing the remote server. These settings can be changed by selecting Edit Security Parameters from the Remote Management icon's pop-up menu on the remote server's taskbar.

Optimizing Server Management

Now that you understand how ZENworks for Servers 3 uses trend data and alarm thresholds to help you manage your servers, you need to know how to optimize the data that ZENworks for Servers 3 gathers for you. When a managed server is first started, agents for trend data, alarm thresholds, and alarm management are loaded and begin collecting data. The best way to optimize server management is to control the initial settings that are loaded on your servers.

The following sections describe how to modify the configuration files that initialize the server management agents to give you tight control over the information collected and presented at the management console.

Setting Initial Trend Values

The first configuration file you should know how to modify is the trend initialization file. This file sets the initial trends for monitoring a device. Each time a new managed device is discovered on the server, a trend file is created for it.

The trend initialization file is named NTREND.INI on a NetWare server and N_NTREND.INI on a Windows NT/2000 Server. The following sections describe how to use a text editor to modify the initial trend file shown in Figure 12.12.

Figure 12.12. Trend initialization file for a NetWare server.

Setting the Sample Interval

The first column in the trend initialization file is the parameter name, and the second is the sample interval. The sample interval indicates the frequency that samples of the specified parameter are collected in terms of a time interval between five seconds and one day.

Evaluate each parameter to determine how often it should be sampled. If you sample too often, you run the risk of poor performance. But if you don't sample enough, you run the risk of incomplete or inaccurate information. Use the codes listed in Table 12.1 to set the sample interval for each trend data parameter.

Table 12.1. Sample Interval Codes for Trend Initialization

TREND INITIALIZATION CODE

SAMPLE INTERVAL RATE

1

5 seconds

2

10 seconds

3

15 seconds

4

30 seconds

5

1 minute

6

5 minutes

7

15 minutes

8

30 minutes

9

1 hour

10

4 hours

11

8 hours

12

1 day

Setting the Trend Buckets

After you set the sample interval for the trend data parameters, you need to set the number of trend buckets in the third column. Setting the number of trend buckets determines the duration of time for which samples will be collected for the parameter.

If, for example, you want to review the number of users logged in to a server for one day and you set the sample interval to be 30 minutes, you need to specify 48 trend buckets. Each bucket contains one sample taken at a 30-minute interval.

After a particular time duration is exceeded for a file, the oldest trend buckets are emptied and replaced with the most recent samples. Therefore, after the duration has been reached, you will always have samples for that amount of time from the present backward.

Enabling and Disabling Trend Files

The fourth column in the trend initialization file is the Enable Trend Data option. This value can be set to either 0 or 1. Specifying 1 enables the gathering of trend data for this parameter. Specifying 0 disables the gathering of trend data for the parameter.

Setting Initial Threshold Values

After setting up the initial trend values, you need to specify the threshold values for alarm generation. Alarm thresholds control the values at which alarms are generated.

Two values are associated with these thresholds: a rising limit and a falling limit. For rising thresholds, the rising limit is the value at which an alarm is generated for the parameter. The falling limit, for rising thresholds, is the value at which the alarm is reset. They work conversely for falling thresholds. This way, an alarm is generated only when a server goes from a good condition to a bad condition—not if it simply stays in a bad state.

If, for example, you have set a falling threshold on cache buffers and a falling limit of 30% and a rising limit of 50%, the server would send out an alarm if cache buffers got below 30%. If the cache buffers then wavered between 25–35%, only the one alarm would be sent. But if the servers' cache buffers climbed back up to 60% and then back down to 30%, a second alarm would be sent.

Setting Rising and Falling Thresholds

The fifth and sixth columns in the trend initialization file are the rising and falling limits, respectively. They represent a value that indicates a problem for the trend parameter and a value that indicates the trend parameter is out of trouble.

You need to evaluate each parameter to determine the appropriate threshold limits and specify them in their columns. You also need to specify which type of threshold the parameter has by putting "rising" or "falling" in the Type column of the trend initialization file.

Enabling and Disabling Threshold Traps

After you specify the limits, you can enable or disable the threshold trap by specifying 0 or 1 in the seventh column. Specifying 0 disables alarm generation for the parameter. Specifying 1 enables alarm generation for the parameter.

Configuring Alarm Generation

The next configuration file you should know how to modify is the trap configuration file, which controls alarm generation. The trap configuration file consists of keywords with associated information about alarm generation.

The trap configuration file is located in the following locations on the managed servers:

  • NetWare. SYS:\ETC\NWTRAP.CFG

  • Windows NT/2000. \MW\INI\NTTRAP.INI

The following sections describe how to modify the trap configuration file, shown in Figure 12.13, to modify the types of alarms forwarded to management consoles, community strings used for sending SNMP traps, traps to be disabled, and specific alarms that you want to prevent from being forwarded.

Figure 12.13. Trap configuration file, NWTRAP.CFG, for a NetWare server.

Setting the Community String

The first thing you can set in a trap configuration file is the community string. The community string is used to generate traps and is restricted to 32 characters. The default community string is public.

Setting the Time Interval

After setting the community string, you need to specify the time interval that alarm generation waits before issuing the next alarm. This is to prevent the network and management console from being inundated with identical alarms. The time interval can be any value between 0 and 232.

If, for example, you want to set the amount of time between alarms for traps 5, 10, and 100 to 20 seconds, you would use the following command in the trap configuration file:

5 10 100 INTERVAL = 20
Configuring Alarm Security Levels

After you specify the time interval for alarms, you should set the severity levels for alarm generation. Each SNMP alarm has a severity level associated with it. You can specify at what severity level to generate alarms so that only those alarms are actually sent to the management console.

You can use the ENABLE and DISABLE commands, with a severity level code or number, in the alarm configuration file to control which severity levels to pass through. Table 12.2 shows the severity levels for alarm generation and the associated codes for the configuration file.

The following are examples of specifying severity levels in the configuration file:

ENABLE SEVERITY >= MINOR
DISABLE SEVERITY <= WARN

Table 12.2. Severity Levels and Codes for Alarms

NETWARE SEVERITY

SNMP SEVERITY

ZFS SEVERITY

SEVERITY CODE

0—Informational

Informational

Informational

INFORM

1—Warning

Minor

Minor

WARN

2—Recoverable

Major

Major

MINOR

3—Critical

Critical

Critical

MAJOR

4—Fatal

Fatal

Critical

CRITICAL

5—Operation Aborted

Fatal

Critical

CRITICAL

Unrecoverable

Fatal

Critical

CRITICAL

Defining Alarm Recipients

The final configuration file you should know how to modify to optimize server management is the TRAPTARG.CFG file. The TRAPTARG.CFG file is used to send traps to third-party management consoles. It defines recipients of SNMP traps that are detected on the server.

If you plan to use third-party management consoles or utilities to monitor SNMP traps, you need to add their IP addresses or IPX addresses to the TRAPTARG.CFG file for alarms to be sent to them.

Follow these steps to modify the TRAPTARG.CFG file:

  1. Open the file in a text editor.

  2. Add the IPX network number and MAC address of any management consoles to the IPX section of the TRAPTARG.CFG file—for example, FFFF1111:00001B123456.

  3. Add the IP address or logical name of any management consoles, if you have DNS configured, to the UDP section of the TRAPTARG.CFG file—for example, 111.111.5.2. If DNS is configured in your network, you can use the logical name.

  4. Save the file.

  5. Unload and reload NWTRAP.NLM on the agent server.


Using ZENworks for Servers 3 Server Inventory

Another important component of ZENworks for Servers 3 server management is server inventory. ZENworks for Servers 3 uses inventory scan programs to scan and store hardware and software inventory of your managed servers. The following sections describe the inventory components and discuss how to scan server inventory and customize software scanning.

Understanding Server Inventory Components

To get the most out of ZENworks for Servers 3 server inventory, you need to understand the components that make up the inventory process and roles that inventory servers play in capturing and storing inventory data.

In a small network, one inventory server would be ample to collect, store, and provide access to the inventory data about servers. But in enterprise networks, the number of servers and the amount of inventory data that can be collected and managed becomes extremely complex. For that reason, ZENworks for Servers 3 implements a tree design to allow several inventory servers to be involved in accumulating and distributing the inventory data. The following is a list of the types of inventory servers and their roles in the inventory process:

  • Standalone server. The standalone server is used in small networks where only one server and database is needed for collecting and storing inventory data from the network. The standalone server collects the inventory data and stores it in a local database.

  • Root server. In an enterprise network, you need to implement several inventory servers to collect and store inventory data. The first inventory server you create is a root server that acts as the top-most level for the inventory tree. The root server must have an inventory database stored on it to store data collected from the other inventory servers below it in the tree.

  • Intermediate server. If you have a large network, you also need to create intermediate servers. The intermediate server collects data from servers below and passes that data to either another intermediate server above, or to the root server. An intermediate server can have an inventory database attached to it to store inventory information locally, but that is not required.

  • Leaf server. The leaf server is the bottom-most level of the tree. Leaf servers are responsible for collecting inventory data that has been scanned, and then passing that data up to the next level in the inventory tree. The leaf server can send data either to an intermediate server or the root server. It can also have an inventory database attached to it to store inventory information locally, but that is not required.

Now that you understand the types of inventory servers that are involved in the server inventory process, you need to understand the components that are involved. ZENworks for Servers 3 uses several different pieces to scan servers for inventory data, process that information, and then store it in the appropriate location. The following is a list of components that make up the inventory process:

  • Inventory scanners. Inventory scanners are agents that run on managed servers that are responsible for scanning the server's hardware and software. They collect the data each time they are run and store that data in a file.

  • Selector. The selector processes the data scanned by the inventory scanners and selects new data that should be added to the inventory database. It then places those scanned files into appropriate directories.

  • Sender and receiver. The sender and receiver are utilities that run on servers to transfer scanned files from an inventory server to the next level of server in the inventory tree.

  • Inventory storer. The inventory storer is a utility that runs on an inventory server with an inventory database attached. It is responsible for taking the inventory scan files that the server receives and storing the inventory data in the database.

  • Inventory database. The inventory database is an RDBMS maintained by Oracle or Sybase or a Microsoft SQL Server and acts as the repository for the hardware and software inventory data collected by the inventory scanners. You can access the data in the inventory database through management console reporting, as well as through user-customized database queries. (For more information about the inventory database, see Appendix A.)

Understanding the Scanning Process

Now that you understand the types of inventory servers and the software components that are involved in ZENworks for Servers 3 server inventory, it is helpful for you to understand the actual process using ZENworks for Servers 3 to scan, collect, and store inventory data.

The first thing that happens in the inventory process is that the inventory scanner agent is activated on a Windows or NetWare Server. The agent reads inventory policy settings (discussed later in this chapter) and uses those settings to scan the server. As the scanning agent runs, it collects data about the server's hardware and software and stores that data in .STR files on the server's local file system. The scan collector then transfers those files to the scan directory (\SCANDIR\) of the inventory server defined in the inventory policy.

After the inventory scanner places data in the scan directory, the selector begins to process the .STR files. The selector filters out everything but new inventory data, and then stores the new data in the enterprise merge directory (\ENTMERGEDIR\) to be transferred to a higher level and/or to the database directory (\DBDIR\) to be stored in the inventory database, if one is running on the server.

After files are stored in the enterprise merge directory, the sender zips up all the scan data files and sends them to a receiver running on another inventory server, which is defined in the roll-up policy (discussed later in this chapter).

The receiver opens the .ZIP files it receives from a sender and copies them to the enterprise merge directory (\ENTMERGEDIR\) to be transferred to a higher level and/or to the database directory (\DBDIR\) to be stored in the inventory database, if one is running on the server. On an intermediate server with an inventory database, for example, the files would be copied to both directories; however, on the root server the files would be copied to only the database directory.

After files are placed, the storer opens the .ZIP file, extracts the scan files to a temp directory (\DBDIR\TEMP\), and updates the inventory data with the data in the .STR files. After the database is updated, the administrator can view the new inventory data from the management console.

Setting Up Server Inventory

Now that you understand the components that are involved in the ZENworks Server Inventory process, you need to understand how to set up and configure the eDirectory objects that control inventory scanning. You use the management console to define the database types and locations in the inventory tree, as well as their synchronization and roll-up schedules. The following sections discuss the configuration changes you need to make at the management console to configure and customize server inventory.

Configuring the Inventory Service Object

The first object you need to configure for server inventory is the inventory service. You must create an inventory service object for each server on which you install ZENworks for Servers 3. The inventory service object defines which role that server plays during the server inventory process. (The inventory service object can be created automatically during the installation of ZENworks for Servers.)

To configure the inventory service object for an inventory server, right-click the inventory service object in ConsoleOne and select Properties. Then select Inventory Service Object Properties from the drop-down list of the Inventory Server Object tab, as shown in Figure 12.14.

Figure 12.14. Inventory service object properties of an inventory service object of a ZENworks for Servers 3 inventory server.

From the Inventory Service Object Properties panel, you can configure the following items of the inventory server:

  • Inventory Server Role. Select the role of the server (Standalone, Root, Intermediate, or Leaf) from the drop-down list. Then you need to define whether it has a database connected by selecting the Connected to Database box (Intermediate and Leaf only). You also need to specify whether machines are connected to this service (Root and Intermediate only).

  • Discard Scan Data Time. Defines a date and time to discard all scan data and start with a fresh copy.

  • Scan Directory Path. Defines the location on the inventory server where the scan data files are to be stored when a scan is run.

  • Enable Scan of Machines. Enables you to temporarily disable scanning of machines. This option is useful if you need to reduce server or network traffic for troubleshooting or performance reasons.

ZENworks for Servers 3 enables you to configure the synchronization schedule to synchronize servers being inventoried with the inventory server with which they are associated. To configure the synchronization schedule for an inventory server, right-click the inventory service object in ConsoleOne and select Properties. Then select Inventory Server Sync Schedule from the drop-down list of the Inventory Server Object tab, as shown in Figure 12.15.

Figure 12.15. Inventory Server Sync Schedule panel of an inventory service object of a ZENworks for Servers 3 inventory server.

From the Inventory Server Sync Schedule panel, you can configure the following synchronization options for the inventory server:

  • Schedule Type. Determines whether the synchronization is a daily, weekly, or monthly type, or whether it should use the policy package to determine its schedule.

  • Days Active. Enables you to specify, by clicking the day's button, which days the schedule will be active. This is useful for performance reasons. If no changes occur over the weekend, for example, but you are performing network-intensive backups, then you would not select Saturday and Sunday.

  • Start and End Time. Enables you to specify the start and stop time for inventory to occur. This enables you to control what times during the day inventory can run. By setting the stop time to 8:00 a.m., for example, you could have inventory stop at 8:00 a.m. before users begin logging on to the network.

  • Random Dispatch Time. Enables you to have ZENworks randomly start the synchronization between the start and end times.

  • Repeat. Enables you to have ZENworks repeat the synchronization at the specified interval. This can be extremely useful if you are watching software inventory that changes frequently.

Configuring the Distributed Server Inventory Policy

After configuring the inventory service object, you need to configure server inventory policy for distributed server packages that you want to use to collect and distribute inventory data. The server inventory policy enables you to configure which inventory service the servers associated with this package are to use. It also allows you to enable and configure hardware and software scanning.

To configure the server inventory policy for a distributed server package, right-click the package and select Properties from the drop-down menu. Then select the Policies tab for the operating system you want to configure. ZENworks for Servers 3 enables you to select NetWare, Windows, Linux, Solaris, or General to configure for all those operating systems. Next, enable the server inventory policy by checking the box next to it. Finally, select the server inventory policy and click the Properties button to bring up the Server Inventory Policy Properties window. The following sections discuss how to configure the server inventory policy from this window.

Configuring the Inventory Service for the Server

The first step in configuring the server inventory policy is to configure which inventory service the servers associated with this policy are to use. Select the General tab in the Server Inventory Policy panel, as shown in Figure 12.16, and configure the following settings:

  • Inventory Server Object DN. Use the Browse button to navigate through the eDirectory tree and locate the inventory service policy, the correct roll-up schedules, and locations configured for servers associated with this distributed server package.

  • Server IP Address/DNS Name. After selecting the inventory server object, you need to select the IP address or DNS name to use for connecting to the inventory database. Make certain that you select the correct name or address or the inventory servers will be unable to connect to the inventory service database.

  • Proxy Server Configuration. Leave Proxy Server Configuration alone; you do not need to configure it for server inventory.

Figure 12.16. General panel of the NetWare Inventory Server Policy for a distributed server package.

Configuring Hardware Scan

If you are configuring an inventory server policy for Windows, then you need to configure hardware scanning by selecting the Hardware Scan tab and setting the following options:

  • Enable DMI Scan. Enables ZENworks to collect hardware inventory data from Windows NT/2000 workstations by using the Desktop Management Interface (DMI) 2.0 specification. (DMI drivers are usually available through the vendor of the hardware platform.)

  • Enable WMI Scan. Enables ZENworks for Servers 3 to collect hardware inventory data from Windows NT/2000 workstations by using the Web-based Management Interface (WMI) 1.5 specification. (WMI drivers are included in the Windows system.)

Configuring Software Scan

Next you need to configure software scanning. Enable software scanning by checking the box next to the Enable Software Scan option, and then clicking the Custom Scan Editor button to bring up the Custom Scan Editor window (see Figure 12.17).

Figure 12.17. Custom Scan Editor window for software scanning in the server inventory policy for a distributed server package.

If you are configuring a server inventory policy for Windows, then you also have the option to enable ZENworks to scan for product identification numbers of applications that are installed on inventoried Windows NT/2000 Servers. The product identification number can be extremely useful in sorting and organizing inventory software reports.

From the Custom Scan Editor window, you can create a list of software that ZENworks for Servers 3 will scan for on servers during the inventory process. The Custom Scan Editor provides you with a powerful tool to optimize software scanning for your network. Use the Custom Scan Editor to specify the vender, product name, product version, filename, and file size of the software for which you want to scan on servers. This enables you to selectively inventory only software that is important to track, reducing the size of inventory reports as well as network and server utilization.

Configuring the Configuration Editor

After you enable and configure software scanning, you can modify the INI file that ZENworks for Servers 3 uses when reporting software inventory by selecting the Configuration Editor tab, as shown in Figure 12.18. From the Configuration Editor tab, you can edit the SWRules file by clicking the Set Default button to open the default file, and then modifying the entries. This enables you to modify what information ZENworks includes when you create inventory reports.

Figure 12.18. Configuration Editor panel of the server inventory policy for a distributed server package.

If you are modifying the server inventory policy for Windows, then the Configuration Editor tab will have a drop-down arrow enabling you to modify the entry's INI files for Zipped Names. This modification enables you to specify the manufacturers of software that is being used to zip files, as well as the identifiers that they are using for the zipped files.

If you are modifying the server inventory policy for Windows, you can also modify the entries in the INI file for Asset Information. You can specify the DMI classnames and attributes for things such as a server model, model number, serial number, and computer type.

Configuring the Service Location Package

The next step in configuring server inventory is to define the inventory database for the service location package object and associate the database object with the inventory service object. This step tells ZENworks which inventory server to use for objects associated with the service location package. Follow these steps to configure the service location package from within ConsoleOne:

  1. Create and/or select the service location package.

  2. Right-click the service location package object and select Properties from the pop-up menu; then select the NetWare or Windows Policies tab.

  3. Enable the ZENworks database policy by checking the box next to it. Click the Properties button to open the Database Properties window.

  4. Select the Inventory Management Tab; then click the Browse button to find the inventory database object you want to use for the service location. Click OK.

  5. When you return to the Properties page for the service location package, select the Associations tab.

  6. Click the Browse button and select the container that stores the inventory service object you want to associate with the inventory database you defined for the service location package. Click OK.

  7. Click Apply to configure the service location package.
Configuring the Roll-Up Policy

After configuring the service location package, you need to configure the roll-up policy if this inventory server is a leaf or intermediate server. The roll-up policy controls the flow of scanned data through the inventory tree by determining the next inventory location and schedule-to-roll scan data collected by the current inventory server. Follow these steps to configure the roll-up policy for an inventory server in ConsoleOne:

  1. Create and/or select the server package object that is associated with the inventory server.

  2. Right-click the server package object and select Properties from the pop-up menu; then select the NetWare or Windows Policies tab.

  3. Enable the roll-up policy by checking the box next to it. Click the Properties button to open the roll-up policies window, as shown in Figure 12.19.

    Figure 12.19. Roll-Up Policy panel of the server inventory policy for a distributed server package.

  4. Click the Browse button and navigate to the inventory service object of the intermediate or root server to which you want this server to roll-up scan data. Click OK.

  5. Select the IP address of the next level inventory server.

  6. Select the Roll-Up Schedule tab and configure the schedule of when to roll scan data collected by this server up to the next level. You need to keep in mind the synchronization schedule defined for the inventory server when configuring the roll-up schedule so that there are no conflicts and there is minimal lag time. If the inventory synchronization, for example, runs only monthly, then you want the roll-up to occur after the synchronization is complete to avoid a one-month latency of information being rolled up in the tree. (See the "Configuring the Inventory Service Object" section and Figure 12.15, earlier in this chapter, for more information about the schedule page.)

  7. Click the OK button to return to the Server Package Properties page.

  8. Select the Associations tab and click the Add button.

  9. Browse to the inventory server object you want to associate with this server package. Click OK twice to return to the Server Package Properties page.

  10. Click the Apply button to configure the roll-up policy.


Chapter 13. Making the Most of ZENworks for Servers 3 Reporting

One of the most powerful tools included with ZENworks for Servers 3 is its extensive reporting engine. ZENworks for Servers 3 can generate reports for you that show you everything from your server inventory to network health. Using ZENworks for Servers 3 reporting can be a useful tool in helping you understand the condition of your network and plan for future additions. The following sections describe understanding, creating, and using server inventory reports, topology reports, network health reports, and TED reports to quickly understand and administer your network.

All ZENworks for Servers 3 reports are based on Crystal Reports and are executed through a delivered run-time. You can design your own reports by creating defined reports through Crystal Reports designer and running them against the ZENworks for Servers 3 database.


Reading ZENworks for Servers 3 Reports

The first step in making the most out of ZENworks for Servers 3 reports is understanding what types of reports are available and what information can be obtained from them. ZENworks for Servers 3 provides inventory reports that enable you to create lists of hardware and services available on your network to use for tracking and planning your network resources. You can use topology reports, generated by ZENworks, to understand the layout and design of your network, enabling you to plan for future growth. ZENworks for Servers 3 also includes health reports that you can use to understand your network's overall health and quickly diagnose issues. Reports on TED distribution are also provided to enable you to understand the current status of your distribution to determine progress and any errors that might have occurred.

Understanding Server Inventory Reports

ZENworks for Servers 3 enables you to create inventory reports of hardware and software that are located on your managed servers. These reports can be very useful to you if you need to know what hardware or software is on a particular machine.

Suppose you want to install new server software that requires a server with a minimum of 256MB of RAM and a processor speed of at least 500MHz. You can use ZENworks for Servers 3 to generate a report of all NetWare Servers that are possible candidates for the software. ZENworks for Servers 3 can generate two different types of inventory reports: simple inventory lists and comprehensive inventory lists.

Simple Inventory List Report

The report you are likely to use most often is the simple inventory list report. The simple inventory list report enables you to selectively create reports on every aspect of your server by selecting specific criteria that must be matched.

Simple inventory list reports are usually generated quickly, so the information you need will be almost instantaneously available. You may want to run several different inventory list reports, shown in Table 13.1, depending on what information you need.

Table 13.1. Available Server Inventory List Reports

REPORT NAME

INFORMATION PROVIDED

Server Scan Time Listing

Date and time of the last inventory scan on each server. Useful to know how up to date the report is.

Server Operating System Listing

List of all servers with the specified OS version and OS. Essential if you plan to upgrade your servers.

Server BIOS Listing

List of all servers with BIOS release date and the total number of such servers. Essential if your manufacturer releases a BIOS update.

Server Processor Family Listing

List of all servers with a specific processor family. Useful for software upgrades.

Server Processor Current Speed Listing

List of all servers' processor speed.

Server Processor Maximum Clock Speed Listing

List of all servers within a range of processor speed.

Server Video Adapter Listing

List of all servers with a specific video adapter.

Server Network Adapter Listing

List of all servers with a specific network interface card.

Server Software Listing

List of all servers with software installed on them. Listed in order by software.

Software Summary Listing

List of the number of servers with a particular software and version installed on them.

Storage Devices Listings

Lists all fixed and moveable storage devices, floppy disks, and CD-ROMs.

System Information Listing

Generates a list of all machines with system information for each machine.

Device Listing Report

Generates a list of all devices including pointing device, keyboard, bus, display adapter, network adapter, sound adapter, modem, battery, and power supply.

Memory Listing Report

Generates a list of all machines within the specified range of memory and the total number of such machines.

Comprehensive Inventory Report

The other type of inventory report that you will use is the comprehensive inventory report. The comprehensive inventory report combines several aspects of server inventory into each report. Each report takes considerably longer to generate; however, they are more specific and inclusive. You will typically use one of the comprehensive inventory reports listed in Table 13.2 to help you with business and network planning.

Table 13.2. Available Comprehensive Inventory Reports

REPORT NAME

INFORMATION PROVIDED

Application Software Inventory Report

Includes information on software with product name, version, vendor, product ID, and product location for each inventoried server.

Systems Software Inventory Report

Includes information on the operating system, drivers, and NetWare client for each inventoried server

Storage Devices Inventory Report

Includes hard drive, CD-ROM, floppy disk, removable disk, and logical disk drive details for each server.

Peripherals Inventory Report

Includes system description, OS description, BIOS, video type, video display details, network interface card type, and recent information for each server.

Hardware Inventory Report

Includes conventional memory, extended memory size, processor type and speed, hard drive information, video type, and modem information for each server.

Asset Management Report

Includes computer description, OS description, and BIOS information for each server, including memory, processor, display adapter, keyboard, pointing device, fixed and removable disk, floppy, CD-ROM, and network adapter details.

Networking Information Report

Includes OS description, network interface card type, IP address, MAC address, and network drive mappings for each server.

System Internal Hardware Report

Generates a report providing the system internal hardware information for the selected machines. Includes System IRQ, system cache, system DMA, system slot, and motherboard.

Hardware Summary Report

Generates a report providing hardware summary information of the selected machines. This includes OS type, OS version, processor family, processor maximum clock speed, memory, and hard disk sizes.

Analyzing Topology Reports

ZENworks for Servers 3 can also deliver reports on your network topology. These topology reports provide information about the specific topology of selected ZENworks for Servers 3 management sites or segments.

ZENworks for Servers 3 can generate two basic types of topology reports. The first is a site-level report, which provides details about the discovered devices on each segment included in the ZENworks for Servers 3 management site. The second type of report is the segment-level topology report, which enables you to narrow the report down to a specific segment in the ZENworks for Servers 3 management site.

NOTE

Whenever possible, generate a segment-level topology report rather than a site-level topology report. A site-level report takes considerably longer to generate.

The five predefined topology reports that can be generated by ZENworks for Servers 3 are discussed in the following sections.

Computer Systems by Segment Report

The Computer Systems by Segment report can be done at a segment level to get only the systems in that segment; however, it is typically used as a comprehensive report to obtain a list of systems at the management site level.

The Computer Systems by Segment report lists the following information about each node and groups them by segment:

  • System name. Node name. Use descriptive names for your systems to make these reports more useful.

  • MAC address. Physical address.

  • IP address. IP address of node. Useful to match to captured packets and trend data.

  • IPX address. IPX address of node. Useful to match to captured packets and trend data.

  • Services. Network services running on the node. Manageable services for the computer system.

  • MIB services. MIB services running on the node. Manageable MIB services for the device.

  • Community string. Community string defined for SNMP services. SNMP community names associated with this computer system.

NCP Servers Report

When running the NCP Servers report, ZENworks for Servers 3 queries the management site or segment (depending on from where the report was run) and returns the following information for each NetWare Server:

  • Server name. Use descriptive names for your servers to make these reports more useful.

  • MAC address. Physical address.

  • IP address. Useful to match to captured packets and trend data.

  • IPX address. Useful to match to captured packets and trend data.

  • Labels. Other names by which the server is known.

  • MIB services. Manageable MIB services for the device.

  • Services. Manageable services for the computer system.

  • Community strings. SNMP community names associated with reads and writes to the server. report, ZENworks for Servers 3 queries the management

Router Report

When running the Router report, ZENworks for Servers 3 queries the management site or segment (depending on from where the report was run) and report, ZENworks for Servers 3 queries the management returns the following information for each router discovered:

  • IPX address. Useful to match to captured packets and trend data.

  • IP address. Useful to match to captured packets and trend data.

  • MAC address. Physical address.

  • Labels. Other names by which the server is known.

  • MIB servers. Manageable MIB services for the device.

  • Services. Manageable services for the computer system.

  • Bound segments. Segments currently bound to the router.

Segment Report

When running the Segment report on a management site, ZENworks for Servers 3 queries the management site and lists the number of computer systems on all segments. If this report is run at the segment level, it lists only the systems on the selected segment. The following information is shown for each computer system listed:

  • IPX address. Useful to match to captured packets and trend data.

  • IP address. Useful to match to captured packets and trend data.

  • Segment type. Whether the segment is IP or IPX.

Segment Topology Report

The Segment Topology report provides network information about routers and bridges in a ZENworks for Servers 3 management or segment (depending on where the report is run from).

The following information is shown for each router listed in the report:

  • Router name. Use descriptive names for your routers to make these reports more useful.

  • MAC address. Physical address.

  • IP address. Useful to match to captured packets and trend data.

  • IPX address. Useful to match to captured packets and trend data.

  • MIB services. Manageable MIB services for the device.

  • Community strings. SNMP community names associated with the router.

The following information is shown for each bridge listed in the report:

  • Bridge name. Use descriptive names for your bridges to make these reports more useful.

  • Bridge type. Type of bridge device.

  • IP address. Useful to match to captured packets and trend data.

  • Number of ports. Number of ports on bridge. This is useful when planning for network growth.

  • Port number (attached address). Useful when troubleshooting software and network problems.

Understanding Network Health Reports

Network health reports provide information about the overall health of a specified ZENworks for Servers 3 management site or managed network segment. ZENworks for Servers 3 uses a predefined health profile to generate health reports. These health profiles define the trend parameters, shown in the following tables, that are used to calculate the overall health of the segment or site. Table 13.3 lists trend parameters that are used to calculate the health of managed servers.

Table 13.3. Trend Parameters for Managed Servers

TREND PARAMETER

AVAILABLE PROFILES

AVERAGE_CONNECTIONS

NetWare Server, Windows Server

AVERAGE_DISK_TRANSFER

Windows Server

AVERAGE_FAILED_LOGONS

Windows Server

AVERAGE_LOGGED_IN_USERS

NetWare Server, Windows Server

FILE_READ_KBYTES

NetWare Server, Windows Server

FILE_READS

NetWare Server, Windows Server

FILE_WRITE_KBYTES

NetWare Server, Windows Server

FILE_WRITES

NetWare Server, Windows Server

LSL_IN_PACKETS

NetWare Server

LSL_OUT_PACKETS

NetWare Server

NETWORK_IN_KBYTES

Windows Server

NETWORK_OUT_KBYTES

Windows Server

NETWORK_TOTAL_KBYTES

Windows Server

NCP_REQUESTS

NetWare Server

NO_ECB_COUNT

NetWare Server

OS_PACKETS_RECEIVE_BUFFER

NetWare Server

PERCENT_ALLOCATED_MEMORY

NetWare Server

PERCENT_CACHE_BUFFERS

NetWare Server

PERCENT_CACHE_HIT_RATE

NetWare Server, Windows Server

PERCENT_CODE_AND_DATA_MEMORY

NetWare Server

PERCENT_CPU_UTILIZATION

NetWare Server, Windows Server

PERCENT_DIRTY_PACKET_RECEIVE_BUFFERS

NetWare Server

PERCENT_DISK_FREE_REDIRECTION_AREA

NetWare Server

PERCENT_LOGICAL_DISK_FREE_SPACE

Windows Server

PERCENT_MEMORY_AVAILABLE

Windows Server

PERCENT_VOLUME_FREE_SPACE

NetWare Server

PHYSICAL_INTERFACE_IN_KBYTE

NetWare Server, Windows Server

PHYSICAL_INTERFACE_IN_PACKETS

NetWare Server, Windows Server

PHYSICAL_INTERFACE_OUT_KBYTE

NetWare Server, Windows Server

PHYSICAL_INTERFACE_OUT_PACKETS

NetWare Server, Windows Server

QUEUE_AVERAGE_LENGTH

Windows Server

QUEUE_AVERAGE_NEXT_JOB_WAIT_TIME

NetWare Server

QUEUE_AVERAGE_NUMBER_READY_ITEMS

Windows Server

QUEUE_AVERAGE_NUMBER_READY_JOBS

NetWare Server

QUEUE_AVERAGE_NUMBER_READY_KBYTES

NetWare Server, Windows Server

SERVER_PROCESSES

NetWare Server

Table 13.4 lists trend parameters that are used to calculate the health of managed networks.

Table 13.4. Trend Parameters for Managed Networks

TREND PARAMETER

AVAILABLE PROFILES

ABORT_DELIMETERS

Token ring

AC_ERRORS

Token ring

BEACONS

FDDI

BEACON_EVENTS

Token ring

BROADCASTS

Ethernet, token ring, FDDI

BURST_ERRORS

Token ting

CLAIM_TOKENS

Token ring, FDDI

CRC_ERRORS

Ethernet, FDDI

DATA_OCTETS

Token ring

DATA_PACKETS

Token ring

ECHO_PACKETS

FDDI

ELASTICITY_BUFFER_ERRORS

FDDI

ERROR_PACKETS

Ethernet, FDDI

FRAGMENTS

Ethernet

FRAME_COPIED_ERRORS

Token ring

FRAME_NOT_COPIED_COUNT

FDDI

FREQUENCY_ERRORS

Token ring

GOOD_PACKETS

Ethernet

INTERNAL_ERRORS

Token ring

JABBERS

Ethernet

LINE_ERRORS

Token ring

LOST_FRAME_ERRORS

Token ring, FDDI

MAC_OCTETS

Token ring, FDDI

MAC_PACKETS

Token ring, FDDI

MULTICASTS

Ethernet, token ring, FDDI

OVERSIZED_ERRORS

Ethernet, FDDI

PERCENT_UTILIZATION

Ethernet, token ring, FDDI

RECEIVE_CONGESTIONS

Token ring

RING_POLL_FAILURES

Token ring

RING_PURGES

Token ring

RING_WRAPS

FDDI

SMT_OCTETS

FDDI

SMT_PACKETS

Ethernet

TOKEN_ERRORS

Token ring

TOTAL_ERRORS

Token ring

TOTAL_OCTETS

Ethernet, FDDI

TOTAL_PACKETS

Ethernet, FDDI

UNDERSIZED_ERRORS

Ethernet, FDDI

UNICASTS

Ethernet, token ring, FDDI

The following sections describe the five predefined health profiles provided with ZENworks for Servers 3.

NetWare Server Profile

The NetWare Server profile is used to monitor and understand the basic health of your NetWare Servers. It provides graphs and data about the following types of trend parameters, listed in Table 13.3, which are used to calculate the overall health of NetWare Servers on the managed site or segment:

  • Cache buffers. Enables you to see the amount of free memory on the server. Low memory is one of the most common symptoms of a sick server.

  • Cache hits. Enables you to see memory usage to troubleshoot overaggressive applications.

  • CPU utilization. Enables you to see how hard the server processor is being worked. High utilization for extended periods can lead to server health problems. Watching the server's utilization can help you strategically plan for network growth in overused areas.

  • Volume free space. Enables you to monitor available disk space on each volume. Low disk space, especially on the SYS volume, often causes server and application problems.

Microsoft Windows Profile

ZENworks for Servers 3 uses the Microsoft Windows profile to generate reports that monitor the basic health of your Microsoft Windows servers. It provides graphs and data about the following types of trend parameters, listed in Table 13.3, which are used to calculate the overall health of Microsoft Windows servers on the managed site or segment:

  • Available memory. Enables you to see the amount of free memory on the Windows Server. Low memory is one of the most common symptoms of a sick server.

  • Cache hits. Enables you to see memory usage to troubleshoot overaggressive Windows applications.

  • CPU utilization. Enables you to see how hard the Windows Server processor is being worked. High utilization for extended periods can lead to server health problems. Watching the Microsoft Windows Server's utilization can help you strategically plan for network growth in overused areas.

  • Disk free space. Enables you to monitor available disk space on each disk. Low disk space, especially on the Windows drive, often causes Windows Server and application problems. A health report is generated for this parameter, but no trend graph.

Ethernet Network Profile

The Ethernet network profile is used to monitor and understand the basic health of your network. It provides graphs and data about the following types of trend parameters, listed earlier in Table 13.4, which are used to calculate the overall health of your ethernet network on the managed site or segment:

  • Total errors. Enables you to see the number of network errors occurring on your managed site or segment. This helps you troubleshoot problem networks.

  • Network utilization. Enables you to see the current usage of your ethernet networks. This can help you understand which segments are being overused and help you plan for future expansion.

  • Total packets. Enables you to monitor the packets being sent on your managed ethernet networks. A health report is generated for this parameter, but no trend graph.

  • Good packets. Enables you to see the good packets that are being sent on your managed ethernet networks. Combined with the total packets, this can help you troubleshoot network problems and overuse. A health report is generated for this parameter, but no trend graph.

Token Ring Network Profile

The token ring network profile is used to monitor and understand the basic health of your token ring network. It provides graphs and data about the following types of trend parameters, listed earlier in Table 13.4, which are used to calculate the overall health of your token ring network on the managed site or segment:

  • Total errors. Enables you to see the number of token ring network errors occurring on your managed site or segment. This helps you troubleshoot problems on your token ring networks.

  • Network utilization. Enables you to see the current usage of your token ring networks. This can help you understand which segments are being overused and help you plan for future expansion.

FDDI Network Profile

Lastly, the FDDI network profile is used to monitor and understand the basic health of your FDDI network. It provides graphs and data about the following types of trend parameters, listed earlier in Table 13.4, which are used to calculate the overall health of your FDDI network on the managed site or segment:

  • Total errors. Enables you to see the number of FDDI network errors occurring on your managed site or segment. This helps you troubleshoot problems on your FDDI networks.

  • Network utilization. Enables you to see the current usage of your FDDI networks. This can help you understand which segments are being overused and help you plan for future expansion.

  • Total packets. Enables you to monitor the total packets being sent on your managed FDDI networks. A health report is generated for this parameter, but no trend graph.

Appreciating Tiered Electronic Distribution Reports

Tiered Electronic Distribution (TED) is an extremely valuable tool for delivering data from server to server across the network. For this reason, ZENworks for Servers 3 includes several reports, discussed in the following sections, that enable you to view the status and history of data distribution through the TED system.

Detailed Reports

ZENworks for Servers 3 enables you to create Detailed reports for data distribution at both the distribution and subscriber levels. These reports can be used to understand distribution processes that have occurred and that are occurring on your network.

The Detailed reports contain the following statistical information about data distributions on the TED distributors and subscribers:

  • Stage. The current stage of the distribution, which will be either the extract or receive stage.

  • Status. Successful or not successful on the receiving of or extraction of the distribution.

  • Date/time. The date and time the distribution was received on the subscriber.

  • Acting process. The agent that is to extract the distribution.

  • Channel. The name of the channel that contained the distribution.

  • Error description. Description of the error associated with the distribution, traditionally at the subscriber side.

History Reports

ZENworks for Servers 3 also creates Revision History reports. These reports help you understand the revisions of data distributions that have occurred on your network. For example, each time you use TED to distribute a new version of software on your network, it would have a new revision. Therefore, you can track successful and unsuccessful software distributions.

There are two Revision History reports. The first report is for normal distribution. The second report is for failed distributions. The Revision History reports contain the following statistical information about data distributions on the TED distributors:

  • Version. Revision number of the distribution package.

  • Creation date/time. The date and time that the distributor created the distribution package.

  • Size of distribution. The size of the distribution file that contains the compressed combination of files for the particular revision (only on regular report).

  • Distribution error. Description of the error that the distribution experienced (only on failure report).


Using ZENworks for Servers 3 Reports

Now that you understand the types of reports that ZENworks for Servers 3 can generate and the trend profiles that it uses to calculate health, you need to understand how you use the ZENworks for Servers 3 console to create, view, and manage those reports. The following sections discuss how to use the three types of ZENworks for Servers 3 reports to monitor and maintain your network health.

Generating Server Inventory Reports

The Server Inventory report enables you to create inventory reports of hardware and software that are located on your managed servers, as discussed earlier in this chapter. The following sections describe how to create, customize, print, and export the Server Inventory reports.

Creating and Viewing Inventory Reports

The first step in using Server Inventory reports is knowing how to generate them. Follow these steps to generate and view the inventory report from within ConsoleOne:

  1. Right-click the ZENworks for Servers 3 management site or managed segment.

  2. Select Reporting from the drop-down menu.

  3. Select the report category from the Reports window, which is shown in Figure 13.1.

    Figure 13.1. Server Inventory reports list in ConsoleOne.

  4. Specify any additional options you want to use as filters when generating the report. Each report will have different options available to filter the report and reduce the number of entries.

  5. Click the Run Selected Report button. A report similar to the one in Figure 13.2 appears.

    Figure 13.2. Server Software Inventory reports in ConsoleOne.

After you generate the report, it's displayed in a window similar to the one in Figure 13.2. You can now view the information ZENworks for Servers 3 collected. Notice that the report in Figure 13.2 is a server software listing—listed are the server name, the software title, version (if available), and the number of servers with this software installed. The left and right arrow buttons enable you to navigate from page to page in a multipage report

Filtering Inventory Reports

ZENworks for Servers 3 enables you to customize the provided reports by filtering certain parameters. This is vital in large managed sites because it enables you to reduce the number of entries returned in the report. If wildcards are allowed, the report shows filter options and states that wildcard characters are allowed, as shown earlier for the Software List report in Figure 13.1.

Table 13.5 lists several character filters you can use to narrow down your report.

Table 13.5. Character Filters

CHARACTER

PURPOSE

*

Selects all items for the criteria (*picks up all, PRV-* picks up all objects that begin with "PRV-", that is, PRV-SERV1, PRV-HOST2, and so on).

?

Uses all items that match the rest of the criteria (PRV-APP? picks up PRV-APP1 and PRV-APP2, but not PRV-HOST2).

%

Is the SQL equivalent of the * character.

_

Is the SQL equivalent of the ? character.

Specific name

Filters on a specific name for the criteria (PRV-APP1 picks up only objects with that name for the criteria).

Printing Inventory Reports

After you generate the report, you may want to make a hard copy for later reference. To print the report, click the Printer button shown earlier in Figure 13.2. The printer dialog box comes up, enabling you to print the report.

Exporting Inventory Reports

You also have the option to export the report to a file. Exporting the report can be extremely useful if you want to publish the report in a presentation or on the Web, or import it into another database.

To export a report, select File [image] Export Report from the menu when you have the report up; then select one of the following types of files to which you want ZENworks for Servers 3 to export the report, as shown in Figure 13.3:

  • Text. Exports the report to a simple text file that can be imported into a word processor for a status report.

  • HTML. Exports the report directly to HTML format. This can be extremely useful to publish server status directly to an internal Web site automatically.

  • PDF. Exports the report to Adobe Acrobat format. This can be useful when preparing a presentation or publishing it on the Web.

  • SDF. Exports the report to a Standard Delimited Format (SDF). This is useful for importing the report into another database for tracking purposes. You must specify a common delimiter such as a comma, a space, or a tab.

Figure 13.3. ZENworks for Servers 3 report exporting options in ConsoleOne.

Creating Topology Reports

ZENworks for Servers 3 also enables you to generate topology reports that help you understand the status and infrastructure of your network. You can generate two types of reports: one based at a managed site level and the other based at a segment level. The segment level reports provide information about managed devices on the selected segment only.

Follow these steps to generate and view one of the types of topology reports from within ConsoleOne:

  1. Right-click the ZENworks for Servers 3 management site or managed segment.

  2. Select Reporting from the drop-down menu.

  3. Select the topology report category from the Reports window, which is shown in Figure 13.4.

    Figure 13.4. Topology reports list in ConsoleOne.

  4. Click the Run Selected Report button. A report similar to the one shown in Figure 13.5 appears.

    Figure 13.5. Network Segment topology report in ConsoleOne.

After you generate the topology report, it's displayed in a Report window similar to the one shown in Figure 13.5. You can now view the information collected by ZENworks for Servers 3, such as network names, addresses, and servers. The left and right arrow buttons enable you to navigate from page to page in a multipage report. You also have the same options to export and print the report as you do with inventory reports (discussed in the preceding section).

Generating Network Health Reports

The final type of ZENworks for Servers 3 report is the Network and Server Management health report. You should become very familiar with this report. The five standard profiles that ZENworks for Servers 3 uses to generate health reports were discussed earlier in the chapter:

  • Netware server profile

  • Microsoft server profile

  • Ethernet server profile

  • Token ring network profile

  • FDDI network profile

The following sections discuss using those five basic profiles, as well as customizing profiles of your own to schedule, run, and view health reports.

Customizing Health Profiles

The first step when working with network health reports is learning how to customize one of the existing health profiles that you use to generate a health report. Customizing an existing health profile means modifying the trend parameters, discussed earlier in the chapter, to more accurately reflect the health of the monitored devices.

Follow these steps to customize one of the existing health profiles from within ConsoleOne:

  1. Right-click the ZENworks for Servers 3 managed site object and select Properties from the pull-down menu.

  2. Select the Health Profiles tab.

  3. Select the health profile you want to customize and click the Edit button, as shown in Figure 13.6. If you do not want to edit one, but want to create a new one, click the New button (discussed in the next section).

    Figure 13.6. Available health profiles in the Health Profiles tab for a managed site object in ConsoleOne.

  4. From the Edit profile box, shown in Figure 13.7, you can modify the directory location to which reports generated by this profile should be published by typing a network path in the Publish Directory box.

    Figure 13.7. Health trend parameters in the Edit Profile dialog box in ConsoleOne.

  5. Modify the trend parameters (listed earlier in Tables 13.3 and 13.4) that are used to calculate health by either checking or unchecking the In Health Calculation box next to them. This adds or removes the parameter from a list used to calculate the health of the device or segment.

  6. Modify the rank of importance of each of the selected trend parameters by specifying a value in the Weight field. You may enter any whole number in the Weight field. ZENworks for Servers 3 uses the number you specify to determine how important the parameter is in calculating the overall health of the device or segment. Larger numbers mean more weight is given to the trend parameter when calculating health of the device.

  7. Modify the trend parameters you want to see rendered graphically in the health report. Data from the parameters that are selected will be calculated and graphically represented on the health report.

  8. Click the OK button to save your changes.
Adding New Health Profiles

Adding a new health profile means defining the location of the report, the type of report, the trend parameters, and the weights to parameters that are used to generate a health report of the monitored device.

Follow these steps to add a new health profile from within ConsoleOne:

  1. Right-click the ZENworks for Servers 3 managed site object and select Properties from the pull-down menu.

  2. Select the Health Profiles tab.

  3. Select the health profile you want to customize and click the New button, as shown in Figure 13.6.

  4. From the New Profile dialog box, shown in Figure 13.8, type in the name of the new profile.

    Figure 13.8. Drop-down list of health profile types shown in the New Profile dialog box in ConsoleOne.

  5. Select the type of device or segment to which the profile applies from the drop-down list, as shown in Figure 13.8.

  6. Click the OK button. The Edit Profile dialog box appears.

  7. From the Edit Profile box, shown in Figure 13.9, you can modify the directory location to which reports generated by this profile should be published by typing a network path in the Publish Directory box.

    Figure 13.9. Edit Profile dialog box showing the health trend parameters and location for the new health profile in ConsoleOne.

  8. Select the trend parameters, listed earlier in Tables 13.3 and 13.4, that are used to calculate health by either checking or unchecking the In Health Calculation box next to them. This adds or removes the parameter from a list used to calculate the health of the device or segment.

  9. Enter the rank of importance of each of the selected trend parameters by specifying a value in the Weight field. You may enter any whole number in the Weight field. ZENworks for Servers 3 uses the number you specify to determine how important the parameter is in calculating the overall health of the device or segment. Larger numbers mean more weight is given to the trend parameter when calculating the device's health.

  10. Select which of the trend parameters you want to see rendered graphically in the health report. Data from the parameters that are selected will be calculated and graphically represented on the health report.

  11. Click the OK button to save your changes.
Creating and Scheduling Health Reports

After you create and customize the health profiles for your managed network devices and segments, you need to know how to create and schedule a health report to run. You must tell ZENworks for Servers on which devices you want a health report to be run, what type of report to run, and when to run it.

Follow these steps in ConsoleOne to create and schedule a health report:

  1. Right-click the ZENworks for Servers 3 managed site object or a container object in the ZENworks for Servers 3 namespace and select Properties from the drop-down menu.

  2. Select the Health Reports tab, as shown in Figure 13.10.

    Figure 13.10. Drop-down list of health profile types shown in the New Profile dialog box in ConsoleOne.

  3. Click the New button. The Edit Report dialog box appears.

  4. From the Edit Report dialog box, shown in Figure 13.11, enter the name you want to call the report.

    Figure 13.11. Edit Report dialog box showing the health trend parameters and location for the new health profile in ConsoleOne.

  5. Select the profile that you want ZENworks for Servers 3 to use when generating the health report by selecting one of the available types from the Profile drop-down list.

  6. Set the frequency that you want to run by selecting Daily, Weekly, or Monthly from the Period drop-down list.

  7. Set the time that you want the health report to be generated by entering the appropriate values in the Start Time field.

  8. Click the OK button. The date and time that you entered for the report is used to generate it.

NOTE

You should schedule reports to run at optimal times to balance data gathering and network performance. Some of the segment reports, for example, tend to be somewhat network-intensive; therefore, you may not want to run them at 9:00 a.m., when all users are logging in and network usage is at its peak. It could be more advantageous to run them at 1:00 a.m. when the system is slow.

Force Running Health Reports

Now that you understand how to schedule health reports to run, you should also be familiar with how to force them to run. Although health reports are scheduled to run on a daily, weekly, or monthly basis at predefined times, you may also need to run them at unscheduled times.

You may, for example, want to force a report to run if you are troubleshooting a network problem, or need to know the current health of a segment of servers before upgrading them.

Follow these steps in ConsoleOne to force a health report to run:

  1. Right-click the ZENworks for Servers 3 managed site object or a managed container object and select Properties from the pop-up menu.

  2. Select the Health Reports tab, shown earlier in Figure 13.10.

  3. Select the report on which you want to force generation.

  4. Click the Now button and the report is saved to the publish directory specified in the health profile for the report.
Viewing Health Reports

Now that you understand how to schedule a health report or force one to run, you need to know how to actually view it. After the health report is created by ZENworks for Servers 3, it will be published automatically to a directory specified by its controlling profile.

Also located in the published directory is an HTML document, named INDEX.HTM, that is associated with the health report. The INDEX.HTM file is an HTML document that contains a Java application that provides access to all the reports that are stored in the directory.

Follow these steps to view a health report after ZENworks for Servers 3 generates it:

  1. From your console workstation, browse to the directory where the health reports for the associated profile are stored.

  2. Open the INDEX.HTM file located in the directory specified in the controlling profile. The left column of INDEX.HTM lists the report hierarchy based on profiles and your network topology.

  3. Click the plus sign next to the health profile that is associated with the health report you want to view. The profile object expands to display a list of container objects.

  4. Click the plus sign next to the container object associated with the health report you want to view. The container object should expand and display a list of report names that are associated with it.

  5. Click the plus sign next to the report you want to view. The report object expands to display a list of instances of that particular report. A report that is scheduled to run daily, for example, would have one instance for each day the report was run. The date and time at which the report was run is used to generate the report's name. A report that was generated on October 11, 2000, at 5:05:00 mountain daylight time would have a name of 2000.10.11_05.05.00_MDT.

  6. Click the plus sign next to the report name to display a list of individual report pages. The number of report pages depends on which profile you selected and for which managed device or segment the report was generated.

  7. Click the individual report page to display the health report in the right frame, as shown in Figure 13.12. The top of the report displays statistical information about the segment or device and provides an overall calculation of health. The trend parameters specified in the report's health profile are listed with trend data. Below the statistical information are trend graphs depicting health based on the trend data selections in the health profile.

    Figure 13.12. Navigating and viewing a health report in a Web browser.

  8. Click the Print button at the bottom of the left frame to print the report if you need a hard copy.

NOTE

The Java application in the INDEX.HTM file for health reports requires that the Java 1.1.2 plug-in for your Web browser be installed before you view the report. If you do not have the plug-in, you will not be able to view the report. Also, if a report has not been fully generated in that directory yet, the Java application will fail to initialize.

Using Tiered Electronic Distribution Reports

ZENworks for Servers 3 also enables you to generate TED reports that help you understand the status and history of software and data distributions on your network. The following sections describe how to use the management console to create detail and history reports of TED distributions.

The following policy and TED reports are available.

Table 13.6. Available Policy Reports

REPORT NAME

INFORMATION PROVIDED

Discovered Policies

Displays the policies that are known, sorted by each server.

Failed Policies

List of all policies that have failed to be enforced, sorted by server name.

Packages

Lists all the packages and each of their components.

Server Down Process

Displays a report from the Server Down process (if successful and if the server came back up) for each server.

Successful Policies

Displays a list of all policies that have been successfully applied, sorted by server.

Unenforceable Policies

Displays a list of all policies that could not be enforced on the server.

Table 13.7 lists the available TED reports.

Table 13.7. Available TED Reports

REPORT NAME

INFORMATION PROVIDED

Distribution Detail

Displays status information on the distributions received by the subscriber.

Revision History

Displays the versions of each distribution.

Revision History Failure

Reports the versions of a distribution that failed during the creation (gathering) process.

Subscriber Detail

Displays status information on the subscribers that received the distribution.

Creating a Distribution Detail Report

This report describes the information that has occurred on the distributor and subscriber to handle the distribution. Follow these steps from the management console to create a Distribution Detail report:

  1. Right-click the ZENworks for Servers 3 database object.

  2. Select Reporting from the menu.

  3. Select the Distribution Detail report from the available reports list.

  4. Check the Latest box if you want just the latest version of the report; otherwise, specify a From and To date in the Date Range field.

  5. Click the Run Selected Report button to generate the report.
Creating a Subscriber Detail Report

This report gives detailed status information on the various subscribers that receive information from a particular distributor's perspective. Follow these steps from the management console to create a Distribution Detail report:

  1. Right-click the ZENworks for Servers 3 database object.

  2. Select Reporting from the menu.

  3. Pick the Subscriber Detail report from the available reports list.

  4. Specify the distribution object in NDS by using the Browse button.

  5. Select a version number to use as a criterion for generating the report.

  6. Specify a distribution stage to use as a criterion for generating the report.

  7. Choose a distribution status to use as a criterion for generating the report. You could, for example, specify only completed or failed distributions.

  8. Click the Run Selected Report button to generate the report.
Creating a Subscriber Distribution Detail Report

The Subscriber Distribution Detail report describes the distribution information based on information from the subscriber involved in the distribution. This report is similar to the Distribution Detail report that you are given from the database object. Follow these steps from the management console to create a Distribution Detail report, similar to the one shown in Figure 13.13:

  1. Right-click the subscriber object.

  2. Select Reporting from the menu.

  3. Select the Distribution Detail report from the available reports list.

  4. Specify the subscriber object in NDS by using the Browse button.

  5. Check the Latest box if you simply want the latest version of the report; otherwise, specify a From and To date in the Date Range field.

  6. Click the Run Selected Report button to generate the report.
Figure 13.13. Subscriber distribution detail report in ConsoleOne.

Creating a Revision History Report

This report displays a history of the various distribution package's versions. Follow these steps from the management console to create a Distribution Detail report:

  1. Right-click the ZENworks for Servers 3 database object.

  2. Select Reporting from the menu.

  3. Pick the Revision History report from the available reports list.

  4. Specify the distribution object in NDS by using the Browse button.

  5. Click the Run Selected Report button to generate the report.
Creating a Revision History Report for Failures

This report displays a list of the distributions that failed during creation of the distribution. This creation occurs on the distributor and deals with the file types. Follow these steps from the management console to create a Distribution Detail report:

  1. Right-click the ZENworks for Servers 3 database object.

  2. Select Reporting from the menu.

  3. Select the Revision History Failure report from the available reports list.

  4. Specify the distribution object in NDS by using the Browse button.

  5. Click the Run Selected Report button to generate the report.


Chapter 14. Using ZENworks for Servers 3 Web-Based Management

The ZENworks for Servers 2 Remote Web Console has been replaced with Web-based management components that plug in to the Novell iManage utility. These components enable you to use Novell iManage as an alternative to ConsoleOne for managing TED objects and distributions.

The following sections discuss how to access the ZENworks for Servers 3 Web-based management role, how to use it to administer the TED object and the tiered distribution view, how to use it to track distributions throughout your network as well as throughout the Remote Web Console, and how to use it to monitor and maintain the distribution agent, subscriber agent, and policy/package agent.

NOTE

The ZENworks for Servers installation guide discusses how to set up the necessary components in your network to install the Web components for Policy-Enabled Server Management. The installation can be somewhat picky, so you should spend some time understanding the installation steps to make certain that they are followed correctly.


Accessing the ZENworks for Servers 3 Web-Based Management Role

After you have correctly configured the setup the Web-based management components on a NetWare or Windows server, you can access the iManage interface by simply opening the following URL in your Web browser:

http://server_name_or_IP_address/eMFrame/iManager.html

Where server_name_or_IP_address is the name or IP address of the server that has the Web-based management components installed on it.

The first Web page that you will see is a login screen prompting you for login information to authenticate to Novell eDirectory. After you have logged in you will see a page similar to the one in Figure 14.1. Expand the ZFS Management section by clicking on the plus next to it and you have access to the ZENworks for Server Web-based management tool. If you do not see the ZFS Management section, then the Web-based management components are not properly installed.

Figure 14.1. ZENworks for Servers Management role in iManage.

One specific feature of iManage that you should become familiar with is the object selector icon, shown in Figure 14.2. This icon is displayed next to fields that require a Novell eDirectory object. If you do not know the exact DN of the object, then you can click on the object selector icon and bring up the object selector window shown in Figure 14.3.

Figure 14.2. Object Selector icon in iManage.

Figure 14.3. Object Selector document in iManage.

The object selector enables you to navigate through the eDirectory tree and select objects that you need to fill out forms in the iManage interface. You will use the object selector frequently when managing TED and policy packages through the Web-based management role.


Administering TED Objects

A great feature that the Web-based management tool offers is the capability to quickly administer TED objects even when ConsoleOne is not available. This can be extremely useful for an administrator that needs to make changes while traveling. The following sections discuss using the Web-based management tool to create, edit, and delete TED objects.


Creating TED Objects

To create a TED object from the Web-based management tool, click on the Create TED Object option under the ZFS Management section from the main page shown in Figure 14.1. A new page, shown in Figure 14.4, opens in your browser. From this page you have the option of creating a Distributor, Subscriber, External Subscriber, Channel, Distribution, or Subscriber Group.

Figure 14.4. Creation document for the ZENworks for Servers Management Role in iManage.

NOTE

Creating a distributor or subscriber does not install the ZENworks for Servers software on them. Typically you should use the install to create a new distributor or subscriber server.

When you select the type of object you want to create from the creation document, shown in Figure 14.4, a new page is opened in your browser, enabling you to enter the information required to create the type of object you selected. Figure 14.5 shows the object creation page for a distributor object. After you fill out the form with the required information, click the OK button and the object will be created.

Figure 14.5. Creation document to create a distribution in the ZENworks for Servers Management Role in iManage.

Editing TED Objects

You can edit TED objects in the Web-based management tool in one of two ways. The first is to click on the Edit TED Object option under the ZFS Management section from the main page. The second is to select a TED object and click the eDirectory button that is shown in some of the other Web-based management tool pages (discussed later).

When you click on the Edit TED Object option under ZFS Management, you are prompted to enter the object name or use the object selector to specify the TED object you want to edit, as shown in Figure 14.6.

Figure 14.6. Editing document for the ZENworks for Servers Management Role in iManage.

After you select the object and click the OK button, the object's edit page is displayed in your browser, shown in Figure 14.7. From this edit page you can select tabs and different panels that enable you to configure the object's properties. The edit screens try to mimic the look and functionality of ConsoleOne as much as possible.

Figure 14.7. Editing page for a distributor object in the ZENworks for Servers Management Role in iManage.

Figure 14.7 shows the general settings edit page for a distributor object. Notice that it has the same settings as the settings panel for the general tab of a distributor object in the ConsoleOne interface.

Deleting TED Objects

Deleting TED objects from the Web-based management tool is quick and simple. First click on the Delete TED Object option under the ZFS Management section from the main page. Next, from the delete page, shown in Figure 14.8, click on the object selector icon and find the object you want to delete. After it is selected simply click the OK button and the object is deleted.

Figure 14.8. Deletion document for the ZENworks for Servers Management Role in iManage.

    [ Team LiB ]


Monitoring TED Distributions

One of the most useful tools that is provided with ZENworks for Server Web-based management is the capability to monitor TED distributions. You can use this tool to track the progress of distributions down through the channel and determine which subscriber servers have received the distribution, which distributor sent it to them, and when they received it.

To monitor a TED distribution from the Web-based management tool, click on the Tiered Distribution View option under the ZFS Management section from the main page shown in Figure 14.1. A new page, shown in Figure 14.9, opens in your browser. From this page you click on the object selector and select the distribution that you want to monitor.

Figure 14.9. Tiered distribution view document of the ZENworks for Servers Management Role in iManage.

After you have selected the distribution that you want to monitor, click the Next button and the tiered distribution view, shown in Figure 14.10 displays the status of the distribution. From this page you can specify a browser refresh frequency that enables you to keep the page up and monitor the progress of the distribution real-time.

Figure 14.10. Tiered distribution view of a TED distribution in the ZENworks for Servers Management Role in iManage.

You also have the following three options from the tiered distribution view:

  • Remote Web Console. This brings up the Remote Web Console page (discussed later) for the object that you have selected in the distribution screen.

  • eDirectory Configuration. This brings up the edit page (discussed earlier) for the object that you have selected in the distribution screen.

  • Expand All. This is a quick way to expand all the entries in the distribution screen. This is very useful to quickly get a picture of the entire distribution.


Using the Remote Web Console Tool

Another extremely useful tool that is provided with ZENworks for Server Web-based management is the Remote Web Console Tool. The Remote Web Console tool enables you to monitor and maintain the distribution agent, subscriber agent, and policy/package agent from a Web browser. This enables you to view configurations, distributions, schedules, events, and so forth about the agents from one easy-to-access location.

You access the Remote Web Console in the Web-based management tool in one of two ways. The first is to click on the Remote Web Console option under the ZFS Management section from the main page. The second is to select a TED object and click the Remote Web Console button that is shown in some of the other Web-based management tool pages.

When you click on Remote Web Console option under ZFS Management, you are prompted to enter the name of the object or use the object selector to specify the TED or Policy/Package agent you want to monitor.

The following sections discuss using the ZENworks for Servers 3 Remote Web Console tool to monitor Policy/Package Agents and TED Agents.

Monitoring Policy/Package Agents from the Remote Web Console

The Remote Web Console tool is an easily accessible and extremely useful tool for quickly viewing configuration and schedule information for policies and software packages in your tree.

The following sections discuss the type of policy/package information that you can monitor from the Remote Web Console.

Configuration

The Configuration tab, shown in Figure 14.11, of a policy/package agent in the Remote Web Console view displays the configuration information (such as the version, events registered, console level and variables) about the agent that was selected.

Figure 14.11. Configuration document for a policy/package in the Remote Web Console tool in iManage.

Policies

The Policies tab of a policy/package agent in the Remote Web Console view displays all policies that are associated with the agent and enables you to enforce, refresh, and reschedule them. This page also displays a list of scheduled policies, including their schedules and a list of enforcers for the agent.

Software Packages

The Software Packages tab of a policy/package agent in the Remote Web Console view displays a list of the package name, install date, status, and available actions for all software packages managed by the agent. It also enables you add a software package.

Schedule

The Schedule tab of a policy/package agent in the Remote Web Console view (see Figure 14.12) displays the schedule classes and times for the agent. It also displays the name, type, parameters, repeats, time, and actions for each time a schedule is run. You can also add a Java class, script, or executable to the agent's schedule from this page.

Figure 14.12. Schedule document for a policy package in the Remote Web Console tool in iManage.

Actions

The Actions tab of a policy/package agent in the Remote Web Console view gives you the option to perform down and refresh actions on the server that the agent is running.

Monitoring Tiered Electronic Distribution Agents from the Remote Web Console

The Remote Web Console also enables you to monitor and maintain the TED distribution and subscriber agents that are running on your network. From the Tiered Electronic Distribution Agents view in the Remote Web Console you can quickly see the configuration and status of distributors and subscribers, distributions, channels, and security, as well as events for both successful and unsuccessful distributions that are occurring in your distribution channel.

The following sections discuss the type of policy/package information that you can monitor from the Remote Web Console.

Configuration

The Configuration tab of a TED agent in the Remote Web Console view displays the configuration information about the distributor or subscriber that was selected. The following is a list of pages under the Configuration tab for a TED agent:

  • Configuration. Shows the object name, object revision, current working directory, distribution timeout, concurrent distributions, console messaging level, logging level, log file path, I/O rates, schedule, variables, and so on for a distributor or subscriber agent's server. This is a very fast way to view the entire configuration for a distributor or subscriber.

  • Subordinate Configuration. Shows the object name, object revision, current working directory, distribution timeout, concurrent distributions, console messaging level, logging level, log file path, I/O rates, schedule, variables, and so on for a subordinate subscriber agent's server.

  • Threads. Displays TED thread information on the agent's server.

  • Route to Subscriber (distributor only). Shows the routing hierarchy to subscriber servers.

  • Database (distributor only). Displays information about the ZENworks for Servers database used by the distributor agent.

  • Refresh Distributor (distributor only). Enables you to force the distributor to refresh the configuration information it holds (distributor, subscribers, channels, and so forth). Remember that this causes Run Immediately distributions to occur.

Distributions

The Distributions tab of a TED agent in the Remote Web Console view displays the distribution information about the distributor or subscriber that was selected. The following is a list pages under the Distributions tab for a TED agent:

  • Received Distributions. Displays a list of all distributions that this agent has received. You have the option of selecting a distribution from that list and view the status.

  • Active Distributions. Displays a list of the ingoing and a list of the outgoing distributions for the agent. From this page, shown in Figure 14.13, you can view the IP address of the agent that is sending or receiving the distribution, whether the distribution is currently active, its priority, the version number, distribution, channel, bytes sent or received, total size, heartbeat status, and actions.

    Figure 14.13. Active distributions document for TED in the Remote Web Console tool in iManage.

  • Distribution Information (distributor only). Enables you to view information about any distribution on the agent.

  • Build Distribution (distributor only). Enables you to rebuild on the distributor and create a new version, if required.

Channels

The Channels tab of a TED agent in the Remote Web Console view displays the channel information for distributions on a distributor agent that was selected. The following is a list pages under the Channels tab for a TED distributor agent:

  • Channel Information. Enables you to view the configuration of the channel for distributions on the agent.

  • Distribute Channel. Enables you to select a distribution object and start distribution.

Events

The Events tab of a TED agent in the Remote Web Console view displays the distribution events on the subscriber or distributor agent that was selected. The following is a list of pages under the Events tab for a TED agent:

  • Scheduled Events. Displays a list of events that are scheduled on the TED Agent.

  • Subscriber Event Log. Displays a list, including severity, time, and message, for all events that have occurred on the subscriber, as shown in Figure 14.14.

    Figure 14.14. Subscriber Events document for a policy package in the Remote Web Console tool in iManage.

  • Distributor Event Log. Displays a list, including severity, time, and message, for all events that have occurred on the distributor.

Security

The Security tab of a TED agent in the Remote Web Console displays the certificates for distributions on the subscriber or distributor agent that was selected. The following is a list pages under the Security tab for a TED agent:

  • Show Certificates. Displays the data for all certificates on the agent, including who issued the certificate, the subject, the date/time created, and the date/time that it expires.

  • Sign CSR (distributor only). Enables you to have the distributor agent sign a Certificate Signing Request (CSR).


Chapter 15. Troubleshooting ZENworks for Servers 3

ZENworks for Servers 3 is an extremely powerful tool that saves network administrators much-needed time. But because of the complexity of network environments, problems can occur that prevent ZENworks for Servers 3 from doing its job. This chapter covers how to troubleshoot and diagnose many of these problems.


Troubleshooting Policy and Distribution Services

It's important that you know how to troubleshoot policy and distribution services. Common types of issues that you need to troubleshoot are covered in the next few sections.

Reviewing Server and Agent Object Associations

Make sure that the server is associated with the policies that you expect. You can determine the policies that the server is using by going to the server object and choosing the ZENworks tab and then looking at the Effective Policies page. On this page you can click the Effective Policies button, and ConsoleOne then displays all the policies that are associated either directly or indirectly with the server.

To see the effective policies for the TED objects, you can go to the TED object and look on the General tab page. This page displays the effective policy DN.

NOTE

Make certain to look for potential problems with a Container Policy Package if you are using only the container to associate the NDS or eDirectory server object. If you are not sure, it's a good idea to associate the NDS or eDirectory server object directly (as a troubleshooting step, not as an implementation design).

You can also check the policies that the agents are using by entering the policy list command on the ZENworks for Servers 3 (ZFS agent that ZFS.NCF loads) console. This displays the effective policies that the agent on that server is using. Additionally, you can enter policy status to display the order that is being used, as specified in the Container Policy. By doing these tasks, you can track down which policy the agents are using.

Subscriber May Timeout with Patching

The connection timeout for the subscriber (administered in the General Property page of the subscriber object) determines how long the subscriber waits to receive a package from the distributor. When sending a distribution with patching turned on, the distributor connects with the subscriber and figures out the details of the path, and then builds the patch on the distributor server. The building of the patch may take longer than the administered connection timeout of the subscriber, causing the subscriber to timeout while waiting for the distributor (while it is still building the patch). The distributor then notices that the subscriber has timed out the connection and stops building the patch, putting the distribution back into its queue for the next distribution cycle. This may continue to happen because each time the patch is building, the subscriber times out, causing the distribution to never be sent to the subscriber.

The current default timeout for the subscriber and distributor is 3,600 seconds. You may need to increase this in the property pages of the distributor and subscriber (see Chapter 6, "Setting Up Tiered Electronic Distribution").

Distributor Sends Only to Concurrent Connections

The system may distribute only to the number of maximum concurrent distributions in the distributor object. So, for example, if the maximum connections were set to 10, only the first 10 subscribers that receive distributions directly from the distributor will receive the distributions.

Set the number of maximum concurrent distributions in the Distributor object to the value of 0. The zero value signals that the distributor has no limit.

Alternatively, you may use a combination of parent subscribers to make sure that the distributor never attempts to distribute to more subscribers than set in the maximum concurrent distributions. Remember that the number of subscribers receiving from the distributor is the list of subscribers in each channel where a distribution is placed. But if a subscriber were pulling a distribution from a parent subscriber, it would not make a connection to the distributor and would not take up a connection number on that object. It would take up a connection to the parent subscriber object.

You can also use the priority settings for distributions to ensure that the highest-priority distributions are sent first in the channel. The priority of a distribution can be set at either High, Medium, or Low. Medium is the default setting when a distribution is created.

ZENworks for Servers 3 Policy Engine and Distributor State Cannot Find Database

The policy engine and the distributor may report that there was no database specified, or that it was specified incorrectly, when you have installed a ZENworks for Servers 3 database on the network.

The problem is that both these agents look for a Database Location Policy in a Service Location Package to find where the database is located. If this policy is not defined and associated with the agent objects or the server, the agents cannot find the database. See Chapter 5, "Setting Up Server Policies," for more information on this specific policy.

Extraction Fails on Subscriber Because Files Not Found

When the subscriber performs an extraction on a distribution that is done with the File Agent, each new distribution is only a delta from the previous distribution. To perform the extraction, both the delta and the previous version of the distribution must be accessible to the agent.

When the maximum number of revisions is reached, the File Agent builds a new "baseline" of the distribution that includes a complete copy of all the files. In some cases, when the deltas are large enough and the distribution is rebuilt frequently, the new baseline may arrive when the subscriber is still processing the previous delta.

The new baseline, when it arrives, deletes all previous delta files on the subscriber upon extraction. If a previous delta distribution of the same package is still being processed, the previous delta file will be gone because the baseline extraction has removed the files. This causes the subscriber to fail the delta extraction because the file was not found.

Either you need to set the maximum revisions so far out that you avoid this problem for a while, or you need to space the sending and extraction of the distribution apart sufficiently so that the subscriber has time to perform the extraction before the next distribution is sent.


Troubleshooting Traffic Analysis

The ZENworks for Servers 3 traffic analysis system can be an extremely useful tool when debugging LAN-related issues. But there is a possibility for problems with the traffic analysis system itself. The following sections discuss steps to take if you are experiencing problems with the traffic analysis system.

Verifying LAN Traffic Agents Are Loaded on Devices

The first step you should take is to check the servers and other devices that have LAN traffic analysis agents on them. Make certain that the agents are loaded (NetWare servers) or started (Windows NT/2000 Servers) properly.

Verifying RMON Agent Settings

After you verify that the traffic analysis agents are loaded properly, you should check the RMON agent's settings for the device in ConsoleOne. You should verify that the RMON agent is enabled for the nodes you are trying to analyze. You should also verify that you have the correct preferred agent set. (See Chapter 10, "Using ZENworks for Servers Traffic Analysis," for more information about setting up the RMON agent.)

Verifying Settings in the LANZ.NCF File

After you verify the RMON agent, you should verify that the settings in the LANZ.NCF files for your NetWare servers are correct. You can also enable the LANZ control screen that can help you understand the current state of the agents. (See Chapter 10 for more information about setting up the LANZ.NCF file.)

Verifying Settings in the LANZCON Utility

After you verify the settings in the LANZ.NCF files for your NetWare servers, you should verify that the settings in the LANZCON utility for your Windows NT/2000 Servers are correct. (See Chapter 10 for more information about setting up the LANZ.NCF File.)

Additional Debugging Tips

The following sections discuss some possible problems in the traffic analysis system and agents and how to resolve them.

LANalyzer Error—Ethernet Adapter <address> Is Not Monitored Because the Driver Does Not Support Promiscuous Mode

A promiscuous-mode driver receives all packets and errors on the network. This is required for the ZENworks for Servers 3 traffic analysis agents. The driver currently loaded does not support promiscuous mode; therefore, you need to update your driver for the traffic analysis agents to work.

No SNMP Response

No SNMP service is currently started on the Windows NT/2000 Server, or the agent is not configured to receive SNMP requests. Start the SNMP server on the NT server and verify that the IP address of the selected host is included in the trap destination address list. This problem could also be caused if you have some community string settings wrong or SNMP parameters set wrong on the servers.

RMON Tables Are Not Listed

Adapter monitoring is not enabled in the LANZCON utility or the RMON tables have been deleted. You should enable adapter monitoring in the LANZCON utility.

False Duplicate IP Address Alarm Generated in DHCP

The DHCPRELEASE packet from the client has not reached the server, resulting in a false duplicate IP address. Use the LANZCON utility to disable the generation of duplicate IP address alarms.

No Response Message on Management Console

The most common cause is that adapter monitoring is not enabled. Use the LANZCON utility in Windows NT/2000 or the LANZ configuration utility in NetWare to enable adapter monitoring.

MIB-2 Not Found

MIB-2 refers to the information base in which the RMON agents are located. You should reload the agent on the device.

No Statistics Are Reported

The monitoring agent is not running on the segment, the interface cannot be monitored because the driver is not supported or is disabled, or the statistics entry has been deleted. You should enable monitoring on the agent, update the driver to a promiscuous mode driver, and/or reload the agent.

This Segment Does Not Have an RMON Agent Connected to It

The segment does not have a supported topology, the RMON agent is not configured or installed correctly, or insufficient memory is on the management server to run the RMON agent. You should first verify that your topology is supported. Second, you should install or configure the RMON agent. Verify that the server has plenty of memory. Then unload and reload the RMON agent.

Interface Not Found

The management console is not able to find the interface on the server to contact the monitoring agent.

The LAN adapter may not be loaded on the server. You should load the LAN driver for the adapter on the server.

The network card for the server was removed and replaced with a new one. Simply wait until NetExplorer discovers the new card and removes the old one.

You installed or reinstalled a new server on the network, but used an IP or IPX address that has been previously assigned. Change the address and run NetExplorer.

Management Server Is Not Responding

The server is down, out of memory, or has a communication problem. If you're experiencing this sort of problem, first verify that the server is up and running. Next verify that the server has plenty of memory. Then check the connectivity status of all services to the management server by using the connectivity test utility.


Troubleshooting Alarm Management

The ZENworks for Servers 3 alarm management system can be an extremely useful tool when debugging LAN- and server-related issues through the use of a number of alarm events. But if a problem exists in the alarm management system itself, you may not be notified. The following sections discuss steps to take if you are experiencing problems with the alarm management system.

Verifying SNMP Agents Are Loaded on Devices

The first step when troubleshooting the alarm management system is to verify that the SNMP agents are loaded on the servers. The agents are responsible for capturing events as they occur. If the agent is not loaded, then events will not be captured. Therefore, you should check your servers and any other devices, such as a bridge, that may have SNMP agents loaded. (For more information on SNMP agents, see Chapter 11, "Using ZENworks for Servers 3 Alarm Management.")

Verifying Status of Alarm Manager Database

Next check the status of the Alarm Manager database on your NetWare management server. To do this, first make certain that the database is loaded. Then make sure that the server itself is not having problems and that there are no error messages relating to the database. (For more information on the Alarm Manager, see Chapter 11.)

Verifying SNMP Connectivity Between Management Console and SNMP Devices

After you verify that the Alarm Manager database is up, you need to verify connectivity to the devices. Use the connectivity test utility, discussed in Chapter 11, to test the SNMP connectivity between the management console and all devices from which you are not receiving alarms.

Verifying Alarm Thresholds

After you verify that the SNMP service on the devices in question can communicate with the management console, you should verify the alarm thresholds for the alarms that you are not receiving. If the alarm threshold is too great, or too little for falling thresholds, it may never be reached and trigger the alarm. (See Chapter 11 for more information on alarm thresholds.)

Receiving and Using Unknown Alarms

If you are receiving the alarm, but it shows up as an unknown alarm, there is no alarm template available in the MIB pool. It is likely that the alarm is being triggered by a third-party device or software. If you need to use an alarm that is showing up as unknown, you should obtain an MIB from the device or software vendor and add it to the MIB pool.


Troubleshooting Server Management

Most issues involving inability to use the ZENworks for Servers 3 server management servers are results of traffic analysis agent or alarm management issues. The first step when troubleshooting issues involving server management components is to test the traffic analysis and alarm systems. The following sections discuss some additional things you can do to troubleshoot server management problems.

Verifying Connectivity Between the Management Console and Server

One of the first things you should do when you are having trouble accessing the server management components is to verify that the management console can actually connect to the server itself. You should use the ping or connectivity tests, discussed in Chapter 11, to verify that the console can communicate over IP or IPX to the server in question.

Verifying Remote Management Agent Is Loaded on the Server

Another thing you should do when troubleshooting server management issues is to check whether the remote management agent, discussed in Chapter 12, "Using ZENworks for Servers 3 Server Management," is properly loaded and running on the server.

Verifying Port Number for RCONSOLEJ

You may also want to verify that the port number and password you are using for the RCONSOLEJ utility match the settings on the server you are attempting to manage remotely.


Troubleshooting Server Inventory

ZENworks for Servers 3 keeps a detailed log file that includes the status of the inventory agents. This log file enables you to troubleshoot Server Inventory issues very effectively. The ZENworks for Servers 3 inventory agents report their current status, including any errors they encounter in the SYS:\ETC\INVAGENT.LOG log file, on NetWare Servers. The log file is located in the Windows temp directory on Windows NT/2000 inventory servers.

Another Server Inventory log file you can use to troubleshoot inventory issues is the INVAGENTPOLICYENFORCER.LOG log file. This file maintains the status of the current invocation of the policy engine, enabling you to see the time, type, description, and severity of any errors that occur in the policy enforcer.


Troubleshooting NetWare Errors

When troubleshooting ZENworks for Servers 3, you should always be aware of any NetWare error messages that are occurring. ZENworks for Servers 3 is heavily tied into the NetWare operating system, eDirectory, and file system. Therefore, any error occurring in NetWare possibly affects ZENworks for Servers 3 as well.

NetWare Server File System Errors

When ZENworks for Servers 3 is having problems distributing on the server, you should always look for errors in the NetWare or NT file system. These errors often help you narrow down the problem to a specific cause and resolution.

Table 15.1 lists common file system errors.

Table 15.1. Common File System Errors

CODE

TEXT

DESCRIPTION

0x8901

INSUFFICIENT SPACE

The station does not have sufficient disk space. Make certain that the minimum free disk space requirements are set up for the application object being used.

0x8980

FILE IN USE

An attempt was made to open or create a file that is already open. Set the shareable attribute if you want multiple users to access the file at the same time.

0x8983

DISK IO ERROR

A hard drive I/O error occurred on a NetWare volume. Typically, a bad sector has been encountered and could not be migrated to the hot fix area. Replace the drive.

0x8999

DIR FULL

An attempt was made to write to a volume without available directory space. Make certain that you are not exceeding the maximum number of directory entries for the volume.

0x899C

INSUFFICIENT RIGHTS INVALID PATH

An attempt was made to access a path with invalid rights to the path or with an invalid path name. Make certain that the user has appropriate rights to the path and that the pathname is correct.

0x89A8

ACCESS DENIED

Access has been denied. Make certain that the user has appropriate rights to the file.

0x89BF

NAME SPACE INVALID

An invalid namespace was used. Make sure the correct namespaces are loaded on the volume being used.

Troubleshooting eDirectory Errors

Another area you should always review when troubleshooting ZENworks for Servers 3is the eDirectory error messages. ZENworks for Servers 3 uses eDirectory not only for normal authentication and access, but also as a service for controlling ZENworks for Servers 3 objects.

eDirectory errors can be categorized as described in the following sections.

eDirectory Operating System Error Codes

Some eDirectory background processes require the functionality provided by the NetWare operating system. These processes, such as communication and transaction servers, can return operating system–specific error codes to eDirectory. These error codes are then passed on to the eDirectory background process that initiated a request.

Usually, operating system error codes that are generated by eDirectory have a negative numerical representation, whereas normal operating system error codes have a positive numerical representation. The numerical range for operating system error codes generated by NDS is –1 through –255; inversely, the numerical range for operating system error codes is 1 through 255.

NOTE

eDirectory returns the positive numerical error code rather than the negative error code normally used by eDirectory to return to application to prevent any incompatibility. Therefore, any occurrence of an error code within the range of 1 through 255 or –1 through –255 should be treated as the same error.

eDirectory Client Error Codes

The next class of eDirectory error codes is the client error codes. Some eDirectory background processes require the functionality provided by other eDirectory servers. Use of these functions, such as bindery services, requires that an eDirectory server act as an eDirectory client to the server providing the functionality. Therefore, these functions often result in client-specific error codes being returned to the eDirectory background processes and operations.

eDirectory client error codes are generated by the eDirectory client that is built into eDirectory. The eDirectory client error codes fall in the range of codes numbered –301 through –399.

eDirectory Agent Error Codes

eDirectory agent error codes represent errors that originated in the eDirectory agent software in the server and that are returned through eDirectory. These codes are numbered –601 through –799 (or FDA7 through F9FE).

NOTE

Temporary errors are normal, because the eDirectory database is designed as a loosely consistent database. You should not be alarmed if eDirectory error conditions exist temporarily. Some errors might persist, however, until the error condition is resolved.

Other eDirectory Error Codes

Some eDirectory background processes require the functionality provided by other NLM programs, such as timesync.nlm or unicode.nlm. If any of these modules encounter an error, it can be passed on to the ds.nlm. Unicode.nlm and other errors in this category range from –400 through –599.

Tools for Troubleshooting eDirectory Errors

To effectively troubleshoot eDirectory errors that affect ZENworks for Servers 3, you should be familiar with the tools available to troubleshoot eDirectory problems. The following tools are provided to monitor and repair error conditions with eDirectory.

  • The DSREPAIR Utility. The DSREPAIR utility enables you to work from the server console to monitor and repair problems with the eDirectory database on a single-server basis. It does not correct problems on other servers from a single, centralized location. It must be run on each server on which you want to correct eDirectory database errors.

  • The DSTRACE Utility. The DSTRACE utility enables you to work from the server console to diagnose eDirectory errors. These errors might appear when you are manipulating eDirectory objects with the administration utilities. eDirectory errors also show up on the DSTRACE screen.

Table 15.2 lists common NDS errors.

Table 15.2. Common eDirectory Errors

CODE

TEXT

DESCRIPTION

–601 FDA7

NO SUCH ENTRY

The specified eDirectory object could not be found on the eDirectory server that is responding to a request.

–603 FDA5

NO SUCH ATTRIBUTE

The requested attribute could not be found. In NDS, if an attribute does not contain a value, the attribute does not exist for the specific object.

–625 FD8F

TRANSPORT FAILURE

The source server is unable to communicate with the target server. This error is almost always LAN-related.

–626 FD8E

ALL REFERRALS FAILED

The object could not be found; however, it is still possible that the object does exist. It is likely that the server could not communicate with another server that is holding a copy of the object.

–634 FD86

NO REFERRALS

The source server has no objects that match the request and has no referrals on which to search for the object. This is not a serious error, but just a response. This error usually resolves itself.


Appendix A. ZENworks for Servers 3 Database Schemas

ZENworks for Servers 3 comes with several reports to retrieve information from the inventory database. But those reports may not always give you the information you need exactly how you want it. This Appendix describes the model of the ZENworks for Desktops 4 inventory database and can be used a reference if you want to write your own custom queries for a Sybase, Oracle, or other SQL-compatible database interface. To understand the tables in this chapter, you should be familiar with the Common Information Model (CIM) standard, the Desktop Management Interface (DMI) standard, and Relational Database-Based Managed Systems (RDBMS).

This appendix lists tables that define the schema and associations in the ZENworks inventory database.


Database Class Associations and Attributes

Tables A.1–A.5 help you understand the schema structure for inventory classes, class associations, association attributes, and class attributes for the following types of inventory objects:

  • Miscellaneous computer system objects

  • ZENworks site objects

  • Client software objects

  • Network objects

  • Disk objects

Table A.1. Computer System Objects in ZENworks Inventory: Associations and Attributes

LOOKUPCLASS

TARGET CLASS

ASSOC. CLASS

ASSOC. ATTRIBUTE 1

ASSOC. ATTRIBUTE 2

CLASS ATTRIBUTES

ZENworks.Bus

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

BusType, Version, Name, Description, Protocolsupported

ZENworks.BIOS

CIM.Unitary ComputerSystem

SystemBIOS

PartComponent

GroupComponent

Manufacturer, InstallDate, BIOSBytes, Caption, SerialNumber, Version, PrimaryBIOS, Size

ZENworks_OperatingSystem

CIM.Unitary ComputerSystem

InstalledOS

PartComponent

GroupComponent

OSType, Caption, CodePage, Role, Version, InstallDate, TotalVirtualMemorySize, TotalVisibleMemorySize, SizeStoredInPagingFiles

ZENworks_NetWare Operating System

CIM.Unitary ComputerSystem

InstalledOS

PartComponent

GroupComponent InternetBridgeSupport,

AccountingVersion, MaxNumberOfConnections, PeakConnectionsUsed, PrintServerVersion, QueuingVersion, RevisionLevel, SecurityRestrictionLevel, SFTLevel, TTSLevel, VAPVersion, VirtualConsoleVersion, InteranalNetworkInformation

ZENworks. Motherboard Version

CIM.Unitary ComputerSystem

Computer SystemPackage

Dependent

Antecedent

HostingBoard, Manufacturer, NumberOfSlots, Description,

ZENworks. ZENKeyboard

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Delay, TypematicRate, Layout, NumberOfFunctionKeys, Description, subtype

ZENworks. ParalellPort

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Name, DMASupport, Address

ZENworks. SerialPort

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Name, Address

CIM.Pointing Device

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

PointingType, Name, NumberOfButtons

ZENworks. Pointing DeviceDriver

CIM.PointingDevice

DeviceSoftware

Dependent

Antecedent

Name, Version

CIM.DMA

CIM.Unitary ComputerSystem

Computer SystemDMA

PartComponent

GroupComponent

DMAChannel, Availability, Description, BurstMode

CIM.IRQ

CIM.Unitary ComputerSystem

Computer SystemIRQ

PartComponent

GroupComponent

IRQNumber, Availability, TriggerType, Shareable

CIM.Power Supply

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Description, TotalOutputPower

CIM.Battery

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Name, Chemistry, DesignCapacity, DesignVoltage, SmartBatteryVersion

CIM.Card

CIM.Unitary ComputerSystem

Computer SystemPackage

Dependent

Antecedent

Description

CIM.Slot

CIM.Card

CardInSlot

Dependent

Antecedent

MaxDataWidth, ThermalRating

CIM. CacheMemory

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Level, WritePolicy, ErrorMethodology, CacheType, LineSize, ReplacementPolicy, ReadPolicy, Associativity

CIM. PhysicalMemory

CIM.CacheMemory

RealizesExtent

Dependent

Antecedent

Speed, Capacity

ZENworks_VideoAdapter

CIM.Unitary ComputerSystem

System Device

Dependent

Antecedent

Description, NumberOfColorPlanes, CurrentHorizontalResolution, CurrentVerticalResolution, VideoArchitecture, VideoMemoryType, MaxMemorySupported, CurrentBitsPerPixel, MaxRefreshRate, MinRefreshRate, DACType, ChipSet, ProviderName

ZENworks. SoundCard

CIM.Unitary ComputerSystem

Computer SystemPackage

Dependent

Antecedent

Name, Description, Manufacturer

CIM. POTSModem

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Name, Description, Caption

Manage Wise.User

CIM.Unitary ComputerSystem

ManageWise. ObjectContact

Owner

Client

LastLoginName, CurrentLoginName

Table A.2. Site Objects in ZENworks Inventory: Associations and Attributes

LOOKUPCLASS

TARGET CLASS

ASSOC. CLASS

ASSOC. ATTRIBUTE 1

ASSOC. ATTRIBUTE 2

CLASS ATTRIBUTES

ZENworks.Site

CIM.UnitaryComputerSystem

SystemSite

SystemSite

ComputerSystem

SiteID, SiteName

ManageWise.NDSName

CIM.UnitaryComputerSystem

Designates

Designation

Host

Label, Tree

ZENworks.SystemInfo

CIM.UnitaryComputerSystem

Computer SystemPackage

Dependent

Antecedent

Tag, Model, Serial Number, Manufacturer, Description

Table A.3. ZENworks Client Software Objects in ZENworks Inventory: Associations and Attributes

LOOKUPCLASS

TARGET CLASS

ASSOC. CLASS

ASSOC. ATTRIBUTE 1

ASSOC. ATTRIBUTE 2

CLASS ATTRIBUTES

ZENworks. NetWareClient

CIM.UnitaryComputerSystem

Installed SoftwareElement

Software

System

Version

ZENworks. InventoryScanner

CIM.UnitaryComputerSystem

Installed SoftwareElement

Software

System

Version, LastScanDate, InventoryServer, ModificationTime

CIM.Product

CIM.UnitaryComputerSystem

InstalledProduct

Product

ComputerSystem

Name, Version, Vendor

Table A.4. Network Objects in the ZENworks Inventory: Associations and Attributes

LOOKUPCLASS

TARGET CLASS

ASSOC. CLASS

ASSOC. ATTRIBUTE 1

ASSOC. ATTRIBUTE 2

CLASS ATTRIBUTES

ZENworks. ProviderName ZENNetwork Adapter

CIM.UnitaryComputerSystem

SystemDevice

PartComponent

GroupComponent

AdapterType,

CIM.Network Description, Adapter

CIM.UnitaryComputerSystem

SystemDevice

Dependent

Antecedent

Name, Caption, InstallDate, MaxSpeed, PermanentAddress, AutoSense

ZENworks. Description Network AdapterDriver

CIM.UnitaryComputerSystem

Installed SoftwareElement

Dependent

Antecedent

Name, Version,

CIM.IPProtocol EndPoint

CIM.UnitaryComputerSystem

HostedAccessPoint

Dependent

Antecedent

Address, SubnetMask

CIM.IPXProtocol EndPoint

CIM.UnitaryComputerSystem

HostedAccessPoint

Dependent

Antecedent

Address

CIM.LANEndPoint

CIM.UnitaryComputerSystem

HostedAccessPoint

Dependent

Antecedent

MACAddress

ManageWise. MSDomainName

CIM.UnitaryComputerSystem

Designates

Designation

Host

Label

ManageWise. DNSName

CIM.UnitaryComputerSystem

Designates

Designation

Host

Label

Table A.5. Disk Objects in the ZENworks Inventory: Associations and Attributes

LOOKUPCLASS

TARGET CLASS

ASSOC. CLASS

ASSOC. ATTRIBUTE 1

ASSOC. ATTRIBUTE 2

CLASS ATTRIBUTES

ZENworks. DiskDrive

CIM.Unitary ComputerSystem

SystemDevice

PartComponent

GroupComponent

Removable

ZENworks. Physical DiskDrive

CIM.DiskDrive

Realizes

Dependent

Antecedent

ZENworks. Logical DiskDrive

CIM.UnitaryComputerSystem

SystemDevice

PartComponent

GroupComponent

DeviceID, TotalSize, VolumeSerialNumber, Caption

ZENworks. Storage Physical Media

ZENworks.PhysicalDiskDrive, ZENworks.Physicaldiskette, ZENworks.PhysicalCDROM

Description, PhysicalCylinders, SectorsPerTrack, PhysicalHeads, Capacity, Manufacturer, Tracks

CIM. DiskettDrive

CIM.UnitaryComputerSystem

SystemDevice

PartComponent

GroupComponent

ZENworks. Physical diskette

CIM.DisketteDrive

Realizes

Dependent

Antecedent

ZENworks Logical Diskette

CIM.DiskettDrive

MediaPresent

Dependent

Antecedent

DeviceID

CIM. CDROMDrive

CIM.UnitaryComputerSystem

SystemDevice

PartComponent

GroupComponent

ZENworks. Physical CDROM

CIM.CDROMDrive

Realizes

Dependent

Antecedent

Manufacturer, Description, Caption

ZENworks. Logical CDROM

CIM.CDROMDrive

MediaPresent

Dependent

Antecedent

DeviceID

ZENworks. Logical DiskDrive

ZENworks.LocalFileSystem

ResidentOnExtent

Dependent

Antecedent

DeviceID, VolumeSerialNumber, Caption

ZENworks. Local FileSystem

CIM.UnitaryComputerSystem

CIM.HostedFileSystem

PartComponent

GroupComponent

Name, FileSystemSize, Description, FileSystemType


Using the ZENworks for Servers 3 MIB Browser

ZENworks for Servers 3 provides an extremely useful tool to help you navigate and manage the SNMP-manageable nodes in the management database. The following sections discuss MIBs, how to start the MIB browser, and how to use it to view the management database.

Understanding MIBs

An MIB is a text file that contains specifically formatted data that describes the management information on a particular class of an SNMP-manageable device. Each SNMP-manageable device has a specific standard to which it adheres. The MIB file is simply a definition of that standard.

ZENworks for Servers 3 compiles most of the MIBs that you need to manage your network. You can, however, use the MIB Compiler to add or remove files from the MIB pool. You may want to compile an MIB from Cisco, for example, so that you can manage and receive SNMP traps from those types of devices in the ZENworks for Servers console. Follow these steps from the management console to compile the MIBs:

  1. Select a ZENworks for Servers 3 management site object from the Atlas view in ConsoleOne.

  2. Right-click the object and select Properties from the pop-up menu.

  3. Select the MIB Pool tab.

  4. Click the Modify Pool button to bring up the Add/Remove MIBs dialog box.

  5. Select the MIBs that you want to remove and click the Remove button.

  6. Click the Add button and navigate to the .MIB files you want to add.

  7. Click the Compile button to compile the files with the .MIB extension and add them to the database.

  8. Click the Close button to return to the management site properties page.

Starting the MIB Browser

The MIB browser enables you to select objects that you want to display and then queries the node to obtain the data objects. It then periodically pools the node to update the information. After it obtains the data object from the node, it enables you to walk through a tree of data objects in the MIB Tree Browser pane and displays the data about the object in the pane below.

Follow these steps from the management console to access the MIB browser:

  1. Select an SNMP-manageable node in the ZENworks for Servers 3 namespace.

  2. Select File [image] Actions [image] MIB Browser from the main menu to bring up the MIB Browser window, as shown in Figure A.1.

    Figure A.1. MIB browser of an SNMP-manageable server object in ConsoleOne.

  3. Click the + sign next to container objects in the MIB Tree Browser pane to expand them and walk through the MIB objects.

  4. View the description of the object in the pane below.

Viewing Tables of Scalar Objects

You can view tables of the scalar objects in the MIB and their dynamically updated values from the MIB browser. This enables you to see how the object data is being updated in the database.

Follow these steps from the MIB browser to view a table of scalar objects that you want to monitor:

  1. Navigate through the MIB tree until you find the scalar object(s) that you want to monitor. If you want to monitor more than one object, you must select the container object; otherwise, select the scalar object itself.

  2. Click the Display Data as Scalar Table button (fourth from left), as shown in Figure A.1.

  3. From the Scalar Table view, shown in Figure A.2, select any object you do not want to monitor and click the Remove button to narrow your view down.

    Figure A.2. Scalar Table view of scalar objects from the MIB browser in ConsoleOne.

  4. Save the settings profile so that the next time you browse through the tree you can select the same Scalar view.

  5. Close the Scalar Table view window when you're finished.


Appendix B. ZENworks for Servers 3 Console Commands

Several ZENworks for Servers 3 and Tiered Electronic Distribution processes run on the ZENworks Server. These processes provide independent consoles that enable you to use console commands to check the status and control the behavior of ZENworks for Servers 3. This appendix discusses each of these consoles and the commands that you can execute on them.


ZENworks for Servers 3 Policy Engine

The ZENworks for Servers 3 policy engine runs on the NetWare Server, provides enforcement of server policies, and installs server software packages. The commands listed in Table B.1 are available from the ZENworks for Servers 3 console. The console is labeled as ZfS in the screens list.

Table B.1. List of Console Commands for ZENworks for Servers 3 Console

COMMAND

DESCRIPTION

cls

Clears the screen and places the prompt at the top of the screen.

down !

Downs the server, ignoring any downing policy that may be in effect.

down cancel

Cancels the current down process. If the server is still sending out messages and so forth from the down policy, the down is cancelled, the logins are re-enabled, and so forth to bring the server back to its previous state. Any previously dropped connections will, obviously, be lost.

down reset

Downs the server by performing a reset of the server. If a downing policy is administered it is enforced.

down restart

Downs the server and restarts the hardware, bringing the system back up. If a downing policy is administered, it is enforced.

down server

Downs the server and does not bring the server back up, enforcing the downing policy if one is administered.

down status

Reports whether the server is in the process of handling a down request. It tells you, for example, how many minutes before the down actually occurs.

events fire <eventid>

Fires an event as if the event actually happened in the server. The eventid is the exact string that is displayed on the events list. It is not a number, but the name of the class handling the event.

events list

Lists all the events that the ZENworks for Servers 3 system is monitoring and the Java process that is watching for the event.

events status

This command is nonfunctional.

exit

Terminates the policy engine and unloads the processes. Any other enforcer or other Java processes related to ZENworks for Servers 3 policy management will continue.

exitall

Terminates the policy engine and all other Java processes. This command unloads JAVA.NLM, resulting in every Java process (even Java processes that are not related to ZFS) being terminated.

help

Provides help on the ZENworks for Servers 3 console commands. You may also enter help <command> to get more specific help on individual commands.

listplugins

Lists the plug-ins that are in the system.

package list

Lists the current set of installed software packages and the dates that they were installed. An asterisk by the item means that requesting a rollback can uninstall that package.

package process <file>

Processes the specified .CPK (software package) file and installs it onto the server.

package rollback

Uninstalls the last package installed (shown with an asterisk in the package list).

policy eventbased

Displays the policies that are effective on this server that are activated by an event on the server.

policy list

Lists the current effective policies. Also displays a policy number with each effective policy. This number is used in the policy enforce command.

policy plugins

Displays the current plug-ins that are in the policy engine. There is a policy plug-in called an enforcer for each policy that can be associated with the server. These enforcers are responsible for making the policy effective when launched by the scheduler. This command also lists the event handler that watches events that occur on the server (for example, down server) that may be monitored by the engine because a policy may affect behavior.

policy refresh

Causes the policy engine to refresh its configuration and policy information by going to eDirectory and getting all policies and re-caching them internally and rescheduling any scheduled policies.

policy refreshonly

Retrieves from eDirectory all the effective policies associated with this server and refreshes them into the server's cache of the policies. This does not refresh or reschedule any scheduled policy.

policy rescheduleonly

Retrieves from eDirectory all the scheduled effective policies associated with this server, refreshes them into the server's cache of the policies, and reschedules them.

policy schedules

Displays the policy schedules that are to be fired on this server.

policy status

Displays information about the configuration of the policy engine. This information includes tree, engine state, search policy name, policy top container, refresh seconds (time between reads of eDirectory for new or updated policies), search level, search order, and search type.

Search order and type are a set of single-digit values that represent an order from left to right.

Search order values are as follows: 0 = object, 1 = group, 2 = container.

Search type values are as follows: 0 = root, 1 = container, 2 = partition, 3 = specified container.

prompt [new prompt]

Displays the current prompt, if none is given on the command line. If a new string prompt is given, the new prompt is set as the prompt for the console. No quotes are required for the parameter. The system automatically tacks on the > character after the prompt.

refresh

Manually requests that the server refresh its configuration policy. This does not read all policies, only the ZENworks for Servers 3 policy associated with this server. Use the policy refresh command to read all other policies.

setfilelevel [#]

Sets the following level number for the messages to be sent to the log file: 0 = No Messages; 1 = Errors; 2 = Successes & Level 1; 3 = Warnings & Level 2; 4 = Information & Level 3; 5 = Trace information & Level 4; 6 = Developer trace information & Level 5. If no level number is entered, the current level is displayed. This command does not change the messages that are sent to the console.

showschedule

Displays the currently scheduled actions and the Java classes (plug-in) that handle the action when the schedule fires.

showvars

Lists the current variables that are defined on the system. This gives the keys and their values.

status

Displays status information on the policy engine, including base path, number of plug-ins loaded, number of events registered, number of scheduled items, and the current console message level.

time

Displays the current date and time of the server.

version

Displays the current version of the ZENworks for Servers 3 Policy Manager.

The commands listed in Table B.2 are the debug commands that are available with the policy engine. The debug commands enable you to access some of the debugging features of ZENworks for Servers 3 to troubleshoot problems. These commands are not supported by Novell, Inc., and may not be fully functional. These commands are valid even if debug is not turned on in the console.

Table B.2. List of Debug Console Commands for ZENworks for Servers 3 Console

COMMAND

DESCRIPTION

Addtables

Adds tables to the Sybase database for logging policy messages and events.

Debug

Instructs user to use the debugon command to turn on help for debug commands.

Debugoff

Turns off help for debug commands.

Debugon

Turns on help for debug commands.

Deltables

Deletes the log tables that were created in the Sybase database for logging policy messages and events. All the data that are in the tables will be lost.

echo <command><console>

Sends the given command to the specified ZENworks for Server 2 console, such as distributor or subscriber. echo help distributor, for example, causes the distributor console to execute the help command.

load <module name>

Loads the specified Java class module into the Java engine.

logconsoleoutputoff

Turns off sending all characters displayed on the console to the log file.

logconsoleoutputon

Turns on sending all characters displayed on the console to the log file.

off

Performs a clear screen, just like cls.

q

Quits the policy engine. This is the same as exit.

resolve [ip address|dns name]

Resolves a given IP address or DNS name. This returns the IP address and the DNS name known to the system.

send <message>

Performs a broadcast of the message to all connected users.

setconsolelevel [#]

Sets the following level of messages to display on the policy engine console: 0 = No Messages; 1 = Errors; 2 = Successes & Level 1; 3 = Warnings & Level 2; 4 = Information & Level 3; 5 = Trace information & Level 4; 6 = Developer trace information & Level 5. The level is the same as the setfilelevel command. The default level is 4, but it can be specified in the ZFS policy. The level is reset back to the level specified on any refresh or restart of the policy engine.

showstates

Displays the various Java components (in policy engine threads) that are currently active and the state they are in, such as downing in five minutes and so forth.

spc <dn><plugin><cmd><string>

Executes a "server procedure call" to the specified server DN. The call causes the plug-in specified to be loaded and the command with the given string parameters to be launched. This can be used to launch an enforcer on a remote server.

threads

Lists the current threads that the policy engine is managing.


TED Distributor/Subscriber

The ZENworks for Servers 3 TED distributor engine runs on the NetWare Server and provides processing of distributions to subscribers. The commands listed in Table B.3 are available from the Distributor console. The console is labeled as TED in the screens list.

Most of the troubleshooting functions have moved to the iManager interface through a Web browser. Consequently, many of the console commands from previous releases have been removed. And because the distributor and subscriber have been combined, there is only a single console for TED.

Table B.3. List of Distributor Console Commands for the TED Console

COMMAND

DESCRIPTION

cls

Clears the screen and places the prompt at the top of the screen.

help

Displays help on the commands.

prompt [new prompt]

Displays the current prompt, if none is given on the command line. If a new prompt is given, the new prompt is set as the prompt for the console. No quotes are required for the parameter. The system automatically tacks on the > character after the prompt.

setfilelevel <#>

Sets the level of messages that should be logged to the log file. This level is specified in the distributor object in eDirectory, or the TED policy effective for the distributor object. Any changes you make to this level with console commands are reset to the value specified in eDirectory upon the next distributor refresh.

time

Displays the current date and time.

version

Displays the current version of the distributor.

The commands listed in Table B.4 are the debug commands that are available with the distributor. These commands are not supported by Novell, Inc., and may not be fully functional. These commands are valid even if debug is not turned on in the console.

Table B.4. List of Debug Console Commands for TED Distributor Console

COMMAND

DESCRIPTION

debugoff

Turns off help for the debug commands.

debugon

Turns on help for the debug commands.

logconsoleoutputoff

Stops TED messages from being displayed on the console as well as written to the log file.

logconsoleoutputon

Turns on sending of all the characters to the log file as well as the console.

off

Performs a cls command.

setconsolelevel [#]

Sets the following level of messages to display on the distributor engine console: 0 = No Messages; 1 = Errors; 2 = Successes & Level 1; 3 = Warnings & Level 2; 4 = Information & Level 3; 5 = Trace information & Level 4; 6 = Developer trace information & Level 5. The level is similar to the level set with the setfilelevel command. This level is specified in the distributor object, or in a TED policy effective for the distributor object. Any changes you make to this level with console commands are reset to the level specified in eDirectory upon the next distributor refresh.

threads

Lists the current threads that the policy engine is managing.


Appendix C. ZENworks for Servers 3 Resources

This appendix describes several resources that are available to assist you in discovering and implementing ZENworks for Servers 3.


Novell Support and Online Documentation

Novell has set up a Web site that is the home for ZENworks products, www.novell.com/products/zenworks. You can find Novell's online documentation and announcements for updates to the product on this site.

Additionally, from this page you can follow the links to support.novell.com/products, where you can find any patches and fixes that may be released for the product. You can find ZENworks products under the NetWare Products categories.


ZENworks Cool Solutions

Many more uses for ZENworks for Servers 3 exist than can ever be described in a book like this. Many customers who use ZENworks for Servers 3 every day get very creative in using the system.

Novell has set up a location on the Internet, www.novell.com/coolsolutions/zenworks, where customers can go and ask questions of the actual ZENworks for Servers 3 engineers and see what solutions other customers have applied with ZENworks for Servers 3. This is also the destination site for users of ZENworks for Desktop and ZENworks Cool Solutions.

The site changes often and features articles from real customers and insiders on how to make ZENworks for Servers 3 work in your network. It also includes a list of frequently asked questions and their answers, and articles from other deployment specialists who are in the trenches. You can often find a white paper at the Cool Solutions site that will have the information you need for your issues.

Occasionally, the site also posts software that is not supported by Novell, but is provided by some internal Novell engineers, Novell consultants, or customers. These tools can help you deploy and manage ZENworks for Servers 3.

Once, on the ZENworks Cool Solutions site, the Webmaster organized a live "Ask the Experts" session with several ZENworks for Desktops engineers, where customers could ask their questions online and get real-time answers. You may even find some job postings for companies that are looking for ZENmasters to come and implement ZENworks in their environments.


Novell Consulting Services

Novell Consulting Services has many good engineers who are familiar with ZENworks for Servers 3 and how it can help Novell customers in their environments. They can assist you, beyond support, in getting ZENworks for Servers 3 to do exactly what you want for your network. Novell Consulting Services can help you with field consulting and with any custom developments you may need, tailoring ZENworks for Servers 3 to your organization's needs. You can contact Novell's Consulting Services through your local Novell sales office, or at the following Web address: http://www.novell.com/consulting/.


Novell Technical Support Services

Novell has one of the best trained and most responsive technical support services departments in the industry. Novell's technical support engineers help customers resolve installation, configuration, incompatibility, and software issues. They track those issues and create technical information documents (TIDs) that break down the symptoms and resolution to the image. Those TIDs are available to you from the Novell Technical Support Knowledgebase if you go to http://support.novell.com and choose Knowledge Base.

You can also access the Novell Support forums to view and post messages about questions that you have. These messages can be responded to by other users and are also responded to by Novell's support engineers. The Novell Support forums are available at http://support.novell.com/forums/.


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

#LOAD LANZFCB command

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

absolute time
captured packets
accessing
Atlas Manager 2nd 3rd
actions
alarms 2nd
actions, configuring 2nd
alarm forwarding 2nd
applications, launching 2nd
configuring 2nd
e-mail notifications 2nd 3rd
SNMP trap forwarding
performing
managed objects
Actions tab (Remote Web Console)
active alarm view 2nd 3rd
active alarms view
management console
active policies
viewing
active servers statistic
baseline documents
activity
caches
viewing
adapters
disk
information, viewing
LAN
information, viewing
network
configuring
Add Ping Targets dialog box
addersses
network
nodes
adding
columns
management console views
health profiles
network health reports 2nd 3rd
services
connectivity tests 2nd
software packages
distributions
users
e-mail lists
Address Map group
RMON2 agents
addresses
IP
considerations
false duplicate
segments
SMTP hosts
viewing
IPX
segments
viewing
MAC
nodes 2nd
RMON agents
network
alarms
external subscribers
source
alarms 2nd
Addtables command
Admin group
RMON Plus agent
administering
databases
administration roles
management site administrator 2nd
Agent Property page
distribution objects
agents
alarm notification
servers
associations
troubleshooting
Bridge
traffic analysis 2nd
configuration management
servers
distribution objects
distributors
eDirectory
troubleshooting
inventory
identifying
LAN traffic
Bridge 2nd
RMON 2nd
RMON Lite 2nd
RMON Plus 2nd
RMON2 2nd
troubleshooting
LAN traffic analysis
LANZ.NCF file 2nd
LANZCON utility 2nd 3rd 4th
NetWare configuration
NetWare SNMP parameters 2nd
NT SNMP parameters 2nd
starting/stopping 2nd
Windows NT/2000 configuration 2nd
LANalyzer
discovering
management
discovering
management for NT
discovering
monitoring
servers
policy/package
monitoring 2nd
primary
segments
remote management
troubleshooting
RMON
available services
interface indexes
MAC addresses
names
status
traffic analysis 2nd
troubleshooting
versions
RMON Lite
traffic analysis 2nd
RMON Plus
traffic analysis 2nd
RMON preferred
selecting 2nd
RMON2
traffic analysis 2nd
server management
discovery components
SNMP
troubleshooting
status
configuring
segments
subscribers
TED 2nd
Desktop Application 2nd 3rd 4th
files 2nd 3rd
FTP 2nd
HTTP
monitoring 2nd 3rd
Policy Package 2nd
RPM 2nd
Server Software Package 2nd
traffic analysis
discovery components
identifying
trend
servers
alarm archivers
alarm dispositions
Alarm Filter dialog box
Alarm group
RMON agent
RMON Lite agent
Alarm History view 2nd
alarm history view
management console
alarm injectors
alarm management
alarm management
components
Alarm Manager database
alarm management services
Alarm Manager database 2nd
alarm dispositions
alarm templates
archivers
deleting alarms
automatic 2nd
management console
processed alarms
troubleshooting
Alarm Manager role
alarm notification agents
servers
alarm processors
alarm reports
alarm statistics
network segments
Alarm Statistics view
Alarm Summary view 2nd 3rd
alarm templates
alarm viewers
alarms
actions 2nd
actions, configuring 2nd
alarm forwarding 2nd
applications, launching 2nd
e-mail notifications 2nd 3rd
SNMP trap forwarding
arrival rate
categories 2nd 3rd
category disposition
components
alarm injector
Alarm Manager database
alarm processors
alarm viewers
database archivers
SNMP trap forwarder
SNMP trap injector
SNMP trap receiver
customizing
deleting
automatic 2nd
management console
enabling/disabling 2nd
forwarding 2nd
from
generating
community strings
confiugring
security 2nd
time intervals
generators
IDs
indicators
audible beeps
icons
ticker tape messages
intervals
managing 2nd 3rd 4th
network addresses
nodes
affected
owner
owner disposition
owners
processed
purging
received time 2nd 3rd
recipients 2nd
refreshing
security
configuring 2nd
severity 2nd 3rd
severity disposition
severity levels
source addresses 2nd
state
state disposition
summary 2nd 3rd
threshold
customizing
thresholds
baseline documents
troubleshooting
Alarm Manager database status
SNMP agents
SNMP connectivity
thresholds
unknown alarms
types 2nd 3rd 4th
unknown
troubleshooting
variables
views
active 2nd 3rd
filtering 2nd 3rd
history 2nd
sorting 2nd 3rd
summary 2nd 3rd
analysis
traffic
troubleshooting 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th
analyzing
traffic
LAN. [See LAN traffic analysis]
Management Services 2nd
appearance
management console views
display font 2nd
grid lines
titles
appending
files
search strings
lines
search strings
text
files 2nd
application objects
Desktop Application agent
Application Software Inventory report
Application-Layer Host group
RMON2 agents
Application-Layer Matrix group
RMON2 agents
applications
information
viewing
launching 2nd
applying
configurations
daily
interval
monthly
time
yearly
archive processors
archivers
alarm
Alarm Manager database
disposition
template
Area page
Atlas Manager
arrival rates
alarms
Asset Management reprot
Assigned Rights dialog box
associations
agents
troubleshooting
maintaining
packages
viewing
servers
troubleshooting
Associations pages
Container Policy package
Associations Property page
Service Location Policy Package
Atlas Manager 2nd
accessing 2nd 3rd
command-line options 2nd
DOE
nodes, creating 2nd 3rd
segments, creating 2nd
management roles
troubleshooting
unified views 2nd 3rd
devices 2nd
segments 2nd
UNIFIEDVIEW.INI file
views
atlas object
atlas view
management console
attributes
eDirectory
syntaxes 2nd
group membership
server objects
local file copy
zenpolPolicy
existing objects
audible beeps
alarm
autodiscovery
AUTOEXEC.NCF file
customizing
automating
alarm deletion 2nd
available policies
viewing
available services
RMON agents

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

balancing
loads
Desktop Application agents
bandwidth
segments
bandwidth utilization statistic
baseline documents
Base group
Bridge agents
baseline documents
alarm thresholds
cache buffers
CPU utilization
file reads/writes
LAN traffic analysis 2nd
servers 2nd 3rd
servers, tracking
software
troubleshooting
volume utilization
benefits
ZENworks for Servers 3 2nd
BoardStatus group
RMON Plus agent
Bridge agents
traffic analysis 2nd
bridges
transparnte
discovering
Broadcast Message page 2nd
broadcast messages
configuring
broadcast packets
nodes
Broadcasts gauge
browsers
MIBs
scalar objects, viewing 2nd
starting
Buffer group
RMON Plus agent
buffers
cache
baseline documents
bytes per second
internode communication
nodes 2nd

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

cache buffers
baseline documents
caches
activity
viewing
capture filters 2nd 3rd
Capture Status window
capturing
packets 2nd
capture filters 2nd 3rd
filtering 2nd
highlighting data
starting 2nd
viewing 2nd
categories
alarms 2nd 3rd
category disposition
alarms
certificates
digital
distributors, copying
TED
channel objects
channels
distribution objects
external subscribers
properties
subscribers
schedules
TED
Distributions Property page
scheduling
Settings Property page
Subscribers Property page
Channels Property page
distribution objects
external subscribers
subscribers
Channels tab
TED agents
character filters
classes
inventory database
client software objects
computer system objects 2nd
disk objects 2nd
network objects
site objects
Java
loading 2nd
client software objects
inventory database classes
client workstations
discovering
clients
eDirectory
errors
cls command 2nd
columns
management console views 2nd
adding/deleting 2nd
order 2nd
resizing 2nd
command-line options
-no cmdServer
-no Manager
-no Notifiers
-rebuild
Atlas Manager 2nd
commands
#LOAD LANZFCB
Addtables
cls 2nd
console
debug 2nd 3rd
policy engine 2nd 3rd
TED distributors/subscribers 2nd
Debug
Debugoff
debugoff
Debugon
debugon
Deltables
down !
down cancel
down reset
down restart
down server
down status
echo
events fire
events lists
events status
exit
exitall
g
help 2nd
listplugins
load
LOAD LANZCTL TRAPREG=1
LOAD LANZDI LEVEL=1
LOAD LANZMEM BOUND=####
LOAD LANZSM DUPIP=0
LOAD LANZSM TOPN=#
LOAD LANZSU DEBUG=1
LOAD LANZTR POLL=#
LOADLANZMEM BOUND=3072 AGE=###
logconsoleoutputoff 2nd
logconsoleoutputon 2nd
off 2nd
package list
package process
package rollback
policy list
policy refresh
policy refreshonly
policy rescheduleonly
policy schedules
policy status
policyeventbased
policyplugns
prompt 2nd
refresh
resolve
send
server
configuring 2nd
set
Server Software Package requirements
Server Software Packages
setconoslelevel
setconsolelevel
setfilelevel
setfilelevle
showschedule
showstates
showvars
spc
status
threads 2nd
time 2nd
version 2nd
common polling frequency
communication
internode
analyzing 2nd 3rd
LAN traffic analysis
communications servers
discovering
community names
SNMP
customizing 2nd
discovery cycle
SNMP configuration
community strings
configuring
companion servers
down server notification
compiling
MIBs
Server Software Packages
completed status
complex TED layouts 2nd 3rd
components
alarm management
alarm injector
Alarm Manager database 2nd
alarm processors
alarm viewers
database archivers
SNMP trap forwarder
SNMP trap injector
SNMP trap receiver
discovery
Atlas Manager
consolidator software 2nd
Database Object Editor
discovery software 2nd 3rd
related components
inventory servers 2nd 3rd
LAN traffic
communication
management console
management server
monitoring agent server
Management Services 2nd
management console 2nd
management console. [See management console]
Management Site Services
remote control
server inventory
traffic management 2nd
views
Server Software
loading Java classes 2nd
loading NLMs
starting services
stopping services
unloading Java processes
Server Software Package
appending text to files
file copy operations 2nd
file identifications 2nd
folder identifications
local file copy operations
parameters 2nd
postinstallation loading/unloading
postinstallation scripts
prepending text to files
Products.dat Property page
registry
scripts
search files 2nd 3rd
text files 2nd 3rd
Server Software Packages
compiling
Identification Property page
managing
Server Software preinstallation loading/unloading 2nd
Server Software preinstallation requirements
TED 2nd
scheduler interactions 2nd
TED relationships 2nd
comprehensive inventory list report 2nd
computer system objects
inventory database classes 2nd
Computer Systems by Segment report
concurrent distributions
configuring
troubleshooting
conditions
down servers 2nd
Conditions page 2nd
Configuration Editor
configuring
configuration management agents
servers
Configuration page
ZENworks for Servers policy 2nd
Configuration tab
TED agents
Configuration tab (Remote Web Console)
configurations
applying
daily
interval
monthly
time
yearly
configuring
agent status
alarm actions 2nd
alarm generation
community strings
security 2nd
time intervals
alarm recipients 2nd
alarm security 2nd
broadcast messages
community strings
concurrent distributions
Configuration Editor
connection timeouts
free disk space
hardware scans
history
hosts
input rate
inventory servers
inventory service object 2nd 3rd
roll-up policy
server inventory policy 2nd 3rd
service location package 2nd
inventory services
LAN traffic analysis
baseline documents 2nd
preferred RMON agents 2nd
SNMP parameters 2nd
matrix information
monitoring services
nodes 2nd
NetWare parameters 2nd
network adapters
networks 2nd
community names
IP addresses
IPX transports
NDS/DNS name resolution
output rates
parent subscribers
roll-up policies
server parameters 2nd
server scripts
servers
information, viewing 2nd 3rd
service location packages 2nd
SNMP parameters
NetWare 2nd
Windows NT/2000 2nd
software scans
statistics
TED
distribution routes 2nd
routing hierarchies 2nd
scheduler interactions 2nd
time intervals
volume object rights
working directories
connect
NetWare
discovering
connection timeouts
configuring
distributors
subscribers
troubleshooting
connections
local file copy
network
information, viewing
servers
troubleshooting
SNMP
troubleshooting
connectivity tests
services, adding 2nd
Connectivity views
console commands
debug
policy engine 2nd
TED distributors/subscribers
policy engine 2nd 3rd
TED distributors/subscribers 2nd
console prompt parameter
console view
management console
Management Services
server management
ConsoleOne 2nd
actions
Atlas Manager, accessng
capture filters 2nd
copy files policy
inventory reports
generating 2nd
namespaces 2nd
network health reports
customizing 2nd 3rd
force running 2nd
generating
health profiles, adding 2nd 3rd
scheduling 2nd
viewing 2nd
options
properties
roll-up policies
service location packages 2nd
snap-ins
server management
SNMP Settings tab
SPK files
topology reports
generating 2nd
views 2nd 3rd
appearance 2nd 3rd 4th 5th
columns 2nd 3rd 4th
deleting/renaming
expanding
graphical
limiting 2nd
saving
sorting
tabular
ConsoleOne snap-ins
policy services
consoles
management 2nd
actions
alarms, deleting
identifying
LAN traffic analysis
namespaces 2nd
options
properties
requirements
views 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
Remote Web
policy services
consolidator software 2nd
Consulting Services
contacts
owner
nodes
servers
viewing
container package object
Container Policy Packages
Associations page
creating 2nd
eDirectory Rights page
Effective Rights page
Inherited Rights Filters page 2nd
This Object page trustees 2nd
Other Property page 2nd
Policies page
Rights to Files and Folders Property page 2nd
search policy
Refresh Interval page
Search Level page 2nd 3rd
Search Order page 2nd
containers
boundaries
WANs, crossing 2nd 3rd
context
source roots
continue on error flag
Conversations view
node traffic 2nd 3rd
Cool Solutions Web site 2nd
Copy File Property page
Server Software Package components 2nd
file identification 2nd
folder identification
Copy Files policy 2nd 3rd
copying
digital certificates
distributors
files
local file copy operations. [See local file copy operations]
manually
Server Software Package components 2nd
CPK files
Server Software package
CPU utilization
baseline documents
servers
viewing
criticality
nodes
crucial frequencies
crucial polling frequency
cumulative policies
customizing
alarms
AUTOEXEC.NCF file
discovery scopes 2nd 3rd
LANZ.NCF file
traffic analysis agents 2nd
management console views
appearance
columns 2nd 3rd 4th
display fonts 2nd
grid lines
titles
network health reports 2nd 3rd
registry keys
SNMP community names 2nd
time spans 2nd
TRAPTARG.CFG file
trend samplings 2nd
threshold alarms
Trend view profile
cycles
discovery
NXPIP
NXPIPX
NXPLANZ
SNMP community names

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

daily configuration scheduling
daily distribution objects scheduling option
daily distribution scheduling option
daily package scheduling
daily subscriber scheduling option
database object
Database Object Editor role
Database Object Editor. [See DOE]
databases
administration
Alarm Manager 2nd
archivers
deleting alarms 2nd 3rd 4th
troubleshooting
Alarm Managerocesr
alarm dispositions
alarm templates
processed alarms
inventory 2nd 3rd
classes 2nd 3rd 4th 5th 6th 7th
managing
policies
policy and distribution services
TED
topology
ZENworks for Servers
identifying
date/time
servers
viewing
DB_ADMIN_TOOL role
Debug command
debug console commands
policy engine 2nd
TED distributors/subscribers
Debugoff command
debugoff command
Debugon command
debugon command
decoded packet data
default configuration
network discovery
modules, loading 2nd
scopes 2nd 3rd
SNMP community names 2nd
workstations
deleting
alarms
automatic 2nd
management console
all lines after search strings
all lines before search strings
columns
management console views
management console views
nodes
preventing
TED objects
Web-based management tool
Deltables command
dependents
TED 2nd
deployment plan
management/monitoring services 2nd
network maps, preparing
policy-enabled server management
inventory agents
inventory servers
remote managed servers
TED servers
ZENworks for Servers database
descriptions
nodes
servers
viewing
Desktop Application agents 2nd 3rd 4th
Desktop Application Wizard
destination fifes
local file copy
destination paths
local file copy
destination subscribers
files, sending
destination volumes
files
destinations
captured packets
Detailed reports
Device Listing report
devices
discovery
configuration changes
LAN/WAN segments
network segments 2nd
network systems 2nd
source-route bridged token rings
transparent bridges
management
SAP packets
polling
storage
information, viewing
unified view 2nd
dialog boxes
Add Ping Targets
Alarm Filter
Assigned Rights
Edit Alarm Disposition
actions, configuring 2nd
alarm forwarding 2nd
applications, launching 2nd
e-mail notification 2nd 3rd
SNMP trap forwarding
Edit Parameters
Edit Profile
Edit Report
Edit Trend
New Profile
Node Details
Segment Details
digital certificates
distributors
copying
directories
SManager
working
configuring
directories distributors
directories subscribers
disabling
alarms 2nd
threshold traps
trend initialization file
Discovered Policies report
discovering
client workstations
communications servers
IP routers
IPX routers
LANalyzer agents
management agent for NT
management agents
management servers
NetWare connect
network printers
SFT III engines
discovery
network
Atlas Manager. [See Atlas Manager]
components 2nd 3rd 4th 5th 6th 7th 8th 9th
cycles 2nd 3rd 4th 5th
default configuration
devices 2nd 3rd 4th 5th
initial discovery status 2nd 3rd
modules, loading 2nd
results, checking 2nd
scheduling
scopes 2nd 3rd
SNMP community names 2nd
starting 2nd
stopping 2nd
workstations
discovery software 2nd 3rd
disk adapters
information
viewing
disk objects
inventory database classes 2nd
disk space
free
configuring
subscribers
Server Software Package requirements
display fonts
management console views 2nd
disposition archivers
dispositions
alarm
Distributed Policy Packages
creating 2nd
Distribution Detail report
Distribution Detail reports
distribution objects 2nd 3rd
agents
channels
General Property page 2nd
manual distributions
creating 2nd
importing 2nd 3rd
scheduling 2nd 3rd
daily
interval
monthly
never
run immediately
time
yearly
distribution routes
configuring 2nd
distribution schedules
distribution services
starting
troubleshooting
agent associations
concurrent distributions
extractions
no database specified error
server associations
subscriber timeouts
Distribution tab
TED agents 2nd
distribution topology
distributions
concurrent
troubleshooting
software packages
adding
TED
monitoring 2nd
Distributions Property page
distributors
TED channels
distributor objects
distributors 2nd
configurations, scheduling 2nd
connection timeouts
console commands 2nd
debug console commands
dependents 2nd
digital certificates
copying
directories
distribution properties
distribution routes
configuring 2nd
distribution schedules
distribution topology
high priority
input rate
low priority
managing
maximum concurrent distributions
medium priority
message configuration parameters
message levels
messaging properties 2nd 3rd 4th
multiple
names
NDS rights 2nd 3rd
effective rights
IRF 2nd
trustees
objects, creating
Other Property page 2nd
overview 2nd
routing hierarchy 2nd 3rd
schedules
scheduling
daily
interval
monthly
never
run immediately
send immediately
time
yearly
scheduling properties 2nd 3rd
settings 2nd
Settings Property page 2nd
TED
variables
DNS
name resolution
IPX software
documents
baseline
LAN traffic analysis 2nd
baseline server 2nd 3rd
alarm thresholds
cache buffers
CPU utilization
file reads/writes
servers, tracking
software
troubleshooting
volume utilization
DOE
Atlas Manager
nodes, creating 2nd 3rd
segments, creating 2nd
DOE (Database Object Editor)
DOE node editor
General tab
Interfaces tab
Services tab
down ! command
down cancel command
Down Procedure page 2nd
down reset command
down restart command
down server command
down servers
companion server notification
conditions 2nd
messages
procedures
unload order
down status command
downing policies
DSREPAIR utility
DSTRACE utility
Duplicate group
RMON Plus agent

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

e-mail
lists
users, adding
e-mail notifications
sending 2nd 3rd
e-mail parameter
distributors
Message Property page
subscribers
echo command
eDirectory
attributes
syntaxes 2nd
errors
agents
clients
operating system
tools
troubleshooting 2nd
eDirectory Rights pages
creating
Effective Rights page
Inherited Rights Filters page 2nd
This Object page trustees 2nd
Edit Alarm Disposition dialog box
actions, configuring 2nd
alarm forwarding 2nd
applications, launching 2nd
e-mail notification 2nd 3rd
SNMP trap forwarding
Edit Parameters dialog box
Edit Profile dialog box
Edit Report dialog box
Edit Trend dialog box
editing
TED objects
Web-based management tool 2nd
Effective Rights page
distributors
enabling
alarms 2nd
threshold traps
trend initialization file
end-node subscribers
engines
policy
console commands 2nd 3rd
debug console commands 2nd
Server Manager
TED distributor
console commands 2nd 3rd
entire line searches
error processing
local file copy
error processing parameter
errors
captured packets
eDirectory
agents
clients
operating system
tools
troubleshooting 2nd
file system
troubleshooting 2nd
LANalyzer
MIB-2 not found
NetWare
troubleshooting 2nd 3rd 4th 5th
no database specified
troubleshooting
no response message
no SNMP response
no statistics reported
nodes
RMON tables not listed
segments
server not responding
Errors gauge
Ethernet network profile
event package scheduling
events
servers
viewing
events fire command
Events group
RMON agent
RMON Lite agent
events list command
events status command
Events tab
TED agents
exit command
exitall command
expanding
management console views
exporting
inventory reports 2nd
external subscriber objects
external subscribers
channels
General Property page
network addresses
overview 2nd
Extract Schedule Property page
subscribers 2nd 3rd 4th
daily
interval
monthly
never
run immediately
time
yearly
extractions
troubleshooting

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

fail on error flag
Failed Policies report
failures
installation
Server Software package
falling threshold values
false duplicate IP addresses
fault tolerance
Desktop Application agents
FDDI network profile
file agents 2nd 3rd
file rule
Server Software Package requirements
file servers
NetWAre
discovering
file services
information
viewing
file system errors
troubleshooting 2nd
files
appending
search strings
AUTOEXEC.NCF
customizing
copy operations
Server Software Package components 2nd
copying manually
CPK
Server Software package
destination
local file copy
destination volumes
identifying
Server Software Package components 2nd
LANZ.NCF
traffic analysis agents 2nd
troubleshooting
local copy operations
attributes
connections
destiantion paths
destination files
error processing
locking
Server Software Package components
source paths
subdirectories
trustees
MIBs
browser. [See MIBs, browser]
compiling
moving through networks. [See TED]
open
viewing
prepending
search strings
reads/writes
baseline documents
search
Server Software Package components 2nd 3rd
sending
destination subscribers
TED
SPK
Server Software package 2nd
text
apending
appending
prepending 2nd
Server Software Package components 2nd 3rd
trap configuration
community strings
security 2nd
time intervals
TRAPTARG.CFG
customzing
trend initialization
enabling/disabling
sample intervals
threshold values 2nd
trend buckets
UNIFIEDVIEW.INI
updating
filtering
alarm views 2nd 3rd
captured packets 2nd
inventory reports
filters
capture 2nd 3rd
character
management console views 2nd
Filters group
RMON agent
first transmit nodes
first transmits
internode communication
flags
continue on error
fail on error
kill conn on open files
maintain trustees
retry x times
synchronize directories
verify distributions
folders
identifying
Server Software Package components
fonts
display
management console views 2nd
force running
network health reports 2nd
forwarding
alarms 2nd
SNMP traps
free disk space
configuring
subscribers
from alarms
FTP Agent property page
FTP agents 2nd

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

g command
gauges
Broadcasts
Errors
Packets
Utilization
general policies
Server Policy Package
General Property page
distribution objects 2nd
external subscribers
General tab
DOE node editor
generating
Distribution Detail reports
inventory reports 2nd 3rd
network health reports
Revision History for Failures reports
Revision History reports
Subscriber Detail reports 2nd
Subscriber Distribution Detail reports
topology reports 2nd
generation (alarms)
community strings
configuring
security 2nd
time intervals
generators
alarms
graphical views
graphs
stacking/unstacking
grid lines
management console views
viewing
group membership attribute
server objects
groups
Address Map
RMON2 agents
Admin
RMON Plus agent
Alarm
RMON agent
RMON Lite agent
Application-Layer Host
RMON2 agents
Application-Layer Matrix
RMON2 agents
Base
Bridge agents 2nd
BoardStatus
RMON Plus agent
Buffer
RMON Plus agent
Duplicate
RMON Plus agent
Events
RMON agent
RMON Lite agent
Filters
RMON agent
History
RMON agent
RMON Lite agent
Host
RMON agent
HostMonitor
RMON Plus agent
HostTopN
RMON agent
MacToIP
RMON Plus agent
management
networks
Matrix
RMON agent
monitoring
Bridge agents
RMON agents
RMON Lite agents
RMON Plus agents
RMON2 agents
Network-Layer Host
RMON2 agents
Network-Layer Matrix
RMON2 agents
Packet Capture
RMON agent
Probe Configuration
RMON2 agents
Protocol Directory
RMON2 agents
Protocol Distribution
RMON2 agents
RMON Conformance
RMON2 agents
Source Route Bridging
Bridge agents
Spanning Tree Protocol
Bridge agents
Statistics
RMON agent
RMON Lite agent
Transparent Bridging
Bridge agents
User History
RMON2 agents

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

hardware
scans
configuring
Hardware Inventory report
Hardware Summary report
health profiles
adding
network health reports 2nd 3rd
health reports
help command 2nd
hexadecimal packet data
high priority distributors
high priority subscribers
highlighting
captured packets
history
configuring
History group
RMON agent
RMON Lite agent
History reports
hops
optimized
WAN tree transmissions
WAN tree transmissions
Host group
RMON agent
HostMonitor group
RMON Plus agent
hosts
configuring
SMTP
IP addresses
HostTopN group
RMON agent
HTTP agents
hubs
segments

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

icons
alarm
Identification Property page
component mansgement
information
IDs
alarms
iManage
object selector icon
iManage interface
importing
manual ndistributions 2nd 3rd
inactivity
nodes
monitoring 2nd
inbound processors
include subfolders parameter
indicators
alarm
audible beeps
icons
ticker tape messages
Inherited Rights Filters page
distributors 2nd
Inhertied Rights Filters page 2nd
initial discovery
status 2nd 3rd
initial threshold values
servers 2nd
rising/falling
traps
initial trend values
servers
sample intervals
trend buckets
trend data, enabling/disabling
input rate
configuring
distributors
input rates
subscribers
installation failures
Server Software package
installing
Server Software Packages 2nd
ZENworks for Servers 3 2nd
management/monitoring services 2nd
network maps, preparing
policy-enabled server management 2nd 3rd 4th 5th 6th
policy-enabled server management Web components requirements 2nd 3rd 4th
prerequisite checklist 2nd
requirements 2nd 3rd
interface indexes
RMON agents
interfaces
iManage
MTU
nodes
network
information, viewing
speed
nodes
summary
troubleshooting
types
nodes
Interfaces tab
DOE node editor
intermediate servers
internode communication
analyzing 2nd 3rd
interpacket time
captured packets
interval configuration scheduling
interval distribution objects scheduling option
interval distribution scheduling option
interval package scheduling
interval subscriber scheduling option
intervals
alarms
sample
trend initialization file
time
configuring
inventoried servers
NetWare
requirements
Windows
requirements
inventory
reports
comprehensive inventory list 2nd
simple inventory list 2nd
servers
components 2nd 3rd
inventory service object 2nd 3rd
Management Services
roll-up policy
scanning 2nd
server inventory policy 2nd 3rd
service location package 2nd
troubleshooting
inventory agents
identifying
inventory database
classes
client software objects
computer system objects 2nd
disk objects 2nd
network objects
site objects
inventory database servers
NetWare
requirements
requirements
inventory databases 2nd 3rd
inventory management services 2nd
inventory reports
exporting 2nd
filtering
generating 2nd 3rd
printing
viewing 2nd
inventory scanners
Inventory Server Sync Schedule panel
inventory servers
identifying
NetWare
requirements
Windows
requirements
Inventory Service Object Properties panel
inventory service objects
configuring 2nd 3rd
inventory services
configuring
inventory storers
IP addresses
considerations
false duplicate
segments
servers
viewing
SMTP hosts
IP discovery scopes 2nd
IP nodes
segments
IP routers
discovering
nodes
IPGROPER.NLM
IPX addresses
segments
servers
viewing
IPX discovery scopes
IPX nodes
segments
IPX routers
discovering
nodes
IPX transports
identifying
Island page
Atlas Manager

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

Java classes
loading 2nd
Java processes
postinstallation loading/unloading
unloading

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

kernels
OS
information, viewing 2nd
keys
registry
customizing
kill conn on open files flag
kill connection of open files parameter
kilobytes of data
internode communication
kilobytes per second
segments
kilobytes per second statistic
baseline documents

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

LAN adapters
information
viewing
LAN segments
discovering
LAN traffic agents
troubleshooting
LAN traffic analysis 2nd
agents 2nd
Bridge 2nd
LANZ.NCF file 2nd
LANZCON utility 2nd 3rd 4th
NetWare configuration
NetWare SNMP parameters 2nd
NT SNMP parameters 2nd
RMON 2nd
RMON Lite 2nd
RMON Plus 2nd
RMON2 2nd
starting/stopping 2nd
Windows NT/2000 2nd
communication
components
management console
management server
monitoring agent server
configuring
baseline documents 2nd
preferred RMON agents 2nd
SNMP parameters 2nd
network segments
alarm statistics
performance 2nd
statistics, viewing 2nd
summary 2nd 3rd 4th
threads 2nd
node traffic
inactivity, monitoring 2nd
internode communication 2nd 3rd
statistics 2nd 3rd
packet captures 2nd
capture filter 2nd 3rd
filtering 2nd
highlighting data
starting 2nd
viewing 2nd
protocol traffic
protocols, viewing 2nd
segment distribution 2nd
switch traffic
port statistics 2nd
summary data 2nd
LANalyzer agents
discovering
LANalyzer error
LANZ.NCF file
traffic analysis agents 2nd
troubleshooting
LANZCON utility
LAN traffic analysis agents 2nd
traffic analysis agents 2nd
troubleshooting
last transmit nodes
last transmits
internode communication
launching
applications 2nd
layers
captured packets
layouts
TED
complex 2nd 3rd
simple 2nd
tree spanning 2nd
leaf servers
legends
graphs, stacking/unstacking
grid lines
time spans 2nd
Trend view profile
viewing
levels
message
distributors
limiting
management console views 2nd
line end searches
line start searches
lines
appending
search strings
grid
management console views
search strings
Linux policies
Server Policy Package
list of services
nodes
List Segments Statistics view 2nd
listplugins command
load balancing
Desktop Application agents
load command
LOAD LANZCTL TRAPREG=1 command
LOAD LANZDI LEVEL=1 command
LOAD LANZMEM BOUND=#### command
LOAD LANZSM SUPIP=0 command
LOAD LANZSM TOPN=# command
LOAD LANZSU DEBUG=1 command
LOAD LANZTR POLL=# command
loading
Java classes 2nd 3rd 4th
modules 2nd
NLMs 2nd
NLMs/Java processes
postinstallation
servers
scheduling
LOADLANZMEM BOUND=3072 AGE=### command
local file copy operations
attributes
connections
destination filfes
destination paths
error processing
locking
Server Software Package components
source paths
subdirectories
trustees
Local File Copy Property page
Server Software Package components
locations
nodes
servers
viewing
locking
local file copy
log file parameter
distributors
Message Property page
subscribers
logconsoleoutputoff command 2nd
logconsoleoutputon command 2nd
low priority distributors
low priority subscribers

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

MAC addresses
nodes 2nd
RMON agents
MacToIP group
RMON Plus agent
maintain attributes parameter
maintain trustees flag
maintain trustees parameter
maintaining
associations
make (nodes)
managed networks
trend parameters 2nd
managed servers
identifying
trend parameters 2nd
management
alarm. [See alarm management]
management agent for NT
discovering
management agents
discovering
management conosole
identifying
management console 2nd
alarms, deleting
LAN traffic analysis
namespaces 2nd
options
properties 2nd
requirements
views 2nd 3rd
appearance 2nd 3rd 4th 5th
columns 2nd 3rd 4th
deleting/renaming
expanding
graphical
limiting 2nd
saving
sorting
tabular
management devices
SAP packets
management groups
netwkorks
management needs
networks
management roles
Atlas Manager
management servers
discovering
identifying
LAN traffic analysis
requirements
Management Services
management console 2nd
actions
namespaces 2nd
options
properties
views 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th 14th 15th 16th 17th 18th
Management Site Services
alarm management 2nd
database administration
MIB tools
network discovery 2nd
reports 2nd
role-based
SNMP services 2nd
topology mapping
network planning
administration roles 2nd 3rd
management groups/needs
management strategies
network configuration 2nd
server roles
overview
remote control
server inventory
management services
starting 2nd 3rd
Management Services
traffic management 2nd
views
management site administrator roles 2nd
management site services
Management Site Services
alarm management 2nd
management site services
alarms
autodiscovery
Management Site Services
database administration
management site services
databases
MIB tools
Management Site Services
MIB tools
network discovery 2nd
reports 2nd
management site services
role-based
Management Site Services
role-based
SNMP services 2nd
topology mapping
management sites
identifying
management strategies
netwkorks
managers
Atlas 2nd
accessing 2nd 3rd
command-line options 2nd
DOE 2nd 3rd 4th 5th 6th
management roles
troubleshooting
unified views 2nd 3rd
views
managing
alarms 2nd 3rd 4th 5th
console views
appearance 2nd 3rd 4th 5th
columns 2nd 3rd 4th
deleting/renaming
expanding
graphical
limiting 2nd
saving
sorting
tabular
databases
distributors
Server Software Packages
components. [See components, Server Software Packages]
identification
requirements 2nd 3rd 4th
variables 2nd
servers
policies 2nd
remotely
servers. [See server management]
Web-based management
manual distributions
creating 2nd
importing 2nd 3rd
mapping
topology
Management Site Services
Matrix group
RMON agent
matrix information
configuring
maximum concurrent distributions
subscribers
medium priority distributors
medium priority subscribers
memory
Server Software Package requirements
Memory Listing report
message levels
distributors
messages
broadcast
configuring
down servers
segments
SNMP
service identification
messaging
properties
subscribers 2nd 3rd
Messaging Property page 2nd 3rd
distributors 2nd 3rd 4th
subscribers 2nd 3rd
MIB browser role
MIB compiler role
MIB tools
management site services
Management Site Services
MIB-2 not found error
MIBs
browser
scalar objects, viewing 2nd
starting
compiling
Microsoft Windows. [See Windows]
mission critical polling frequency
modules
loading 2nd
Monitor Nodes for Inactivity view
node traffic 2nd
monitoring
node inactivity 2nd
policy/package agents 2nd
Actions tab
Configuration tab 2nd
Schedule tab
Software Packages tab
SNMP services 2nd
SNMP traps
TED agents 2nd 3rd
Channels tab
Configuration tab
Distribution tab 2nd
Events tab
Security tab
TED distributions
Web-based management tool 2nd
monitoring agent servers
LAN traffic analysis
monitoring agents
servers
monitoring groups
Bridge agents
RMON agents
RMON Lite agents
RMON Plus agents
RMON2 agents
monitoring services
nodes
configuring 2nd
starting 2nd 3rd
target nodes
connectivity tests services, adding 2nd
multiple 2nd 3rd
single 2nd
monthly configuration scheduling
monthly distribution objects scheduling option
monthly distribution scheduling option
monthly package scheduling
monthly subscriber scheduling option
multicasts per second
nodes
multiple distributors
mw account object
mw domain object
mw scope object
mw service object

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

name resolution
NDS/DNS
IPX software
names
community
SNMP configuration
distributors
management console views
nodes
owner
nodes
RMON agents
segments 2nd
servers
viewing
SNMP community
customizing 2nd
discovery cycle
namespaces
navigating 2nd
navigating
namespaces 2nd
NCP Servers report
NCP Servers reports
NDS
name resolution
IPX software
NDS rights
distributors 2nd 3rd
effective rights
IRF 2nd
trustees
NDS Rights Property page
distributors 2nd 3rd
effective rights
IRF 2nd
trustees
needs
management
networks
NetExplorer Console screen
NetWare
client workstations
discovering
communications server
discovering
connect
discovering
LANalyzer agents
discovering
Management agent for NT
discovering
Management agents
discovering
parameters
configuring 2nd
print servers
discovering
server profile 2nd
traffic analysis agent configuration
LANZ.NCF file 2nd
LANZCON utility 2nd
SNMP parameters 2nd
starting/stopping
troubleshooting
eDirectory errors 2nd
file system errors 2nd
NetWare file servers
discovering
NetWare inventoried server
requirements
NetWare inventory servers
requirements
NetWare managed servers
requirements
NetWare policy-enabled server management servers
requirements
NetWare servers
discovery components
remote management 2nd
NetWare Set Parameters policy 2nd
NetWare traffic analysis servers
requirements
Network Address Property page
external subscribers
network addresses
alarms
external subscribers
nodes
network capacity
nodes
network discovery
Atlas Manager
accessing 2nd 3rd
command-line options 2nd
DOE 2nd 3rd 4th 5th 6th
management roles
troubleshooting
unified views 2nd 3rd
views
components
Atlas Manager
consolidator software 2nd
Database Object Editor
discovery software 2nd 3rd
related components
cycles
NXPIP
NXPIPX
NXPLANZ
SNMP community names
default configuration
devices
configuration changes
LAN/WAN segments
network segments 2nd
network systems 2nd
source-route bridged token rings
transparent bridges
initial discovery status 2nd 3rd
Managemetn Site Services 2nd
modules
loading 2nd
results, checking 2nd
scheduling
scopes 2nd 3rd
IP 2nd
IPX
SNMP community names 2nd
starting 2nd
stopping 2nd
worksations
network error ratesstatistic
baseline documents
network health reports
Ethernet network profile
FDDI network profile
NetWare server profile 2nd
token ring network profile
trend parameters
managed networks 2nd
managed servers 2nd
viewing
Windows profile 2nd
network heatlh reports
customizing 2nd 3rd
force running 2nd
generating
health profiles, adding 2nd 3rd
scheduling 2nd
viewing 2nd
network interfaces
information
viewing
network maps
preparing
network objects
inventory database classes
network printers
discovering
network probes
segments
network segments
discovered 2nd
configuration changes
LAN/WAN segments
source-route bridged token rings
transparent bridges
node traffic
inactivity, monitoring 2nd
internode communication 2nd 3rd
packet captures 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th
statistics 2nd 3rd
traffic analysis
alarm statistics
performance 2nd
statistics, viewing 2nd
summary 2nd 3rd 4th
threads 2nd
network systems
discovered 2nd
Network-Layer Host group
RMON2 agents
Network-Layer Matrix group
RMON2 agents
Networking Information report
networks
adapters
configuring
configuring 2nd
community names
IP addresses
IPX transports
NDS/DNS name resolution
connections
information, viewing
managed
trend parameters 2nd
Management services planning
administration roles 2nd 3rd
management groups/needs
management strategies
network configuration 2nd
server roles
moving files through. [See TED]
nodes
packet captures 2nd
capture filters 2nd 3rd
filtering 2nd
highlighting data
starting 2nd
viewing 2nd
protocols
viewing 2nd
never configuration scheduling
never schedule distribution objects option
never schedule distributions option
never schedule subscribers option
New Profile dialog box
NLMs
information
viewing
NLMS
IPGROPER.NLM
NLMs
loading 2nd 3rd 4th
NLMS
NXPIP.NLM
NXPIPX.NLM
NXPLANZ.NLM
NLMs
postinstallation loading/unloading
unloading
no cmdServer option
no database specified error
troubleshooting
no Manager option
no Notifiers option
no response messages error
no SNMP response error
no statistics reported error
Node Details dialog box
node details object
Node management role
nodes
affected
alarms
broadcast packets
bytes per second 2nd
creating
DOE 2nd 3rd
criticality
descriptions
errors
first transmit
interface MTU
interface speed
interface summary
interface types
IP
segments
IP/IPX routers
IPX
segments
last transmit
list of services
locations
MAC addresses 2nd
make
monitoring services
configuring 2nd
multicasts per second
names
network addresses
network capacity
network types
operating systems
owner contacts
owner names
packets per second 2nd
prevent deletion
protocols
segments
subnet masks
switch-related informatin
target. [See target nodes]
traffic
inactivity, monitoring 2nd
internode communication 2nd 3rd
statistics 2nd 3rd
types
nodes object
not loaded status
NT server object
NXPCON utility
discovery scopes 2nd 3rd
modules
loading 2nd
NSMP community names 2nd
worksation discovery
NXPIP disocery cycle
NXPIP.NLM
NXPIPX disocery cycle
NXPIPX.NLM
NXPLANZ disocery cycle
NXPLANZ.NLM

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

object selector icon
objects
application
Desktop Application agent
atlas
channel
client software
inventory database classes
computer system
inventory database classes 2nd
container package
database
disk
inventory database classes 2nd
distribution 2nd 3rd
agents
channels
General Property page 2nd
manual distributions
manual distributions. [See manual distributions]
scheduling 2nd 3rd
distributor
creating
external subscriber
inventory service
configuring 2nd 3rd
mw account
mw domain
mw scope
mw service
network
inventory database classes
node details
nodes
NT server
policy
RBS module
RBS role
Remote Web Console
SAS service
scalar
viewing 2nd
segments
server
group membership attribute
server group
server package
service location package
site
inventory database classes
subscriber
subscriber group
subscribers
creating
TED 2nd 3rd
creating 2nd
deleting
editing 2nd
TED channel
TED distribution
TED distributor
TED external subscriber
TED subscriber
TED subscriber group
volume
rights, configuring
zenpolPolicy attribute
ZENworks for Servers
ZENworks for Servers site
off command 2nd
open files
servers
viewing
operating system
nodes
operating systems
Server Software Package requirements
operation parameter
optimizing
server management
alarm managment 2nd 3rd 4th 5th
alarm recipients 2nd
initial threshold values 2nd
initial trend values 2nd 3rd 4th
options
command-line
-no cmdServer
-no Manager
-no Notifiers
-rebuild
Atlas Manager 2nd
management console
actions
properties
views 2nd
order
columns
management console views
Ordered Unload page 2nd
OS kernels
information
viewing 2nd
Other Property page
distributors 2nd
Other Property pages 2nd
outbound processor
output rates
configuring
overwrite destination files parameter
owner contacts
nodes
owner disposition
alarms
owner names
nodes
owners
alarms 2nd

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

package lsit command
package process command
package rollback command
package schedule option
package scheduling
packages
associations
viewing
Container Policy
Associations page
creating 2nd
eDirectory Rights page
Other Property page 2nd
Policies page
Rights to Files and Folders page 2nd
search policy. [See search policy]
Distributed Policy
creating 2nd
policies 2nd
policy-enabled server management services 2nd
scheduling
daily
event
interval
monthly
package schedule option
relative
run immediately
time
weekly
yearly
Server Policy
Copy Files policy 2nd 3rd
creating 2nd 3rd
NetWare Set Parameters policy 2nd
Policies Property page 2nd 3rd 4th 5th 6th
Scheduled Down policy 2nd
Scheduled Load/Unload policy 2nd
Server Down Process policy 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
Server Scripts policy 2nd
SNMP Community Strings policy 2nd 3rd
Text File Changes policy 2nd 3rd 4th 5th 6th 7th
ZENworks for Servers policy 2nd 3rd 4th 5th 6th
Server Software 2nd
.CPK files
.SPK files 2nd
compiling
components. [See components, Server Software Packages]
creating 2nd 3rd 4th
identification
installation failures
installing 2nd
managing
overview
requirements 2nd 3rd 4th 5th
rollbacks
updating
variables 2nd
service
configuring 2nd
Service Location Policy
Associations Property page
creating 2nd
Policies Property page
TED policy. [See TED policy]
ZENworks Database policy 2nd
Service Location Policy Package
SMTP Host policy. [See SMTP Host policy]
Packages report
Packet Capture group
RMON agent
Packet Capture Setup window
packet loads
internode communication
packets
capturing 2nd
capture filters 2nd 3rd
filtering 2nd
highlighting data
starting 2nd
viewing 2nd
SAP
management devices
segments
Packets gauge
packets per second
internode communication
nodes 2nd
packets per secondstatistic
baseline documents
pages
Agent Property
distribution objects
Area
Atlas Manager
Associations
Container Policy package
Associations Property
Service Location Policy Package
Broadcast Message 2nd
Channels Property
distribution objects
external subscribers
subscribers
Conditions 2nd
Configuration
ZENworks for Servers policy 2nd
Copy File Property
Server Software Package components 2nd
Distributions Property
distributors
TED channels
Down Procedure 2nd
eDirectory Rights
creating
Effective Rights page
Inhertied Rights Filters page 2nd
This Object page trustees 2nd
Effective Rights
distributors
Extract Schedule Property
subscribers 2nd 3rd 4th
FTP Agent property
General Property
distribution objects 2nd
external subscribers
Identification Property
component management
information
Inherited Rights Filters 2nd
distributors 2nd
Island
Atlas Manager
Local File Copy Property
Server Software Package components
Messaging Property 2nd 3rd
distributors 2nd 3rd 4th
subscribers 2nd 3rd
NDS Rights Property
distributors 2nd 3rd
Network Address Property
external subscribers
Ordered Unload 2nd
Other Property 2nd
distributors 2nd
Policies
Container Policy package
Policies Property
Policies property
Server Policy Package 2nd 3rd 4th 5th 6th
Policy Schedule
Port Configuration
ZENworks for Servers policy
Postinstallation Load/Unload Property
Server Software Package components
Postinstallation Script Property
Server Software Package components
Preinstallation Load/Unload Property 2nd
Java classes, loading 2nd
Java processes, unloading
NLMs, loading
services, starting
services, stopping
Preinstallation Requirements
component management
Products.dat Property
Server Software Package components
Refresh Interval
Regsitry Settings Property
Server Software Package components
Reporting 2nd
Requirements Property
Server Software Package 2nd 3rd 4th
Rights to Files and Folders Property 2nd
RMON property
Routing Hierarchy Property
distributors 2nd 3rd
Schedule Property 2nd
distribution objects 2nd 3rd
distributors 2nd 3rd
TED channels
Script Property
Server Software Package components
Search Level 2nd 3rd
Search Order 2nd
Set Commands Property
Server Software Package components 2nd
Settings Policy 2nd
Settings Property
distributors 2nd
subscribers 2nd
TED channels
Subscribers Property
TED channels
Targeted Messages 2nd
Text Files Property
Server Software Package components 2nd 3rd
This Object
distributor trustees
trustees 2nd
Variables Property 2nd
Server Software Package 2nd
subscribers 2nd
WAN
Atlas Manager
panels
Inventory Server Sync Schedule
Inventory Service Object Properties
parameters
console prompt
e-mail
distributors
Message Property page
subscribers
error processing
include subfolders
kill connection of open files
log file
distributors
Message Property page
subscribers
maintain attributes
maintain trustees
NetWare
configuring 2nd
operation
overwrite destination files
purge database
retry times
server
configuring 2nd
server console
distributors
Message property page
subscribers
Server Software Package components 2nd
SNMP
configuring 2nd
NetWare configuration 2nd
Windows NT/2000 configuration 2nd
SNMP trap
distributors
Message property page
subscribers
source path
target path
trend
managed networks 2nd
managed servers 2nd
working directory
parent subscribers 2nd
configuring
overview 2nd
subscribers
WANs
paths
destination
local file copy
source
local file copy
performance
network segments 2nd
performing
actions
managed objects
Peripherals Inventory report
planning
Management services
administration roles 2nd 3rd
management groups/needs
management strategies
network configuration 2nd
server roles
server management
baseline documents 2nd 3rd
platform-specific policies 2nd
plural policies
policies
available/active
viewing
Container Policy Package
Associations page
creating 2nd
eDirectory Rights page
Other Property page 2nd
Policies page
Rights to Files and Folders Property page 2nd
search policy. [See search policy]
Copy Files 2nd 3rd
cumulative
Distributed Policy Package
creating 2nd
downing
general
Server Policy Package
Linux
Server Policy Package
NetWare Set Parameters 2nd
overview 2nd
packages
associations, viewing
platform-specific 2nd
plural
policy-enabled server management services 2nd
refreshing
roll-up
configuring
Scheduled Down 2nd
Scheduled Load/Unload 2nd
scheduling
search
Refresh Level page
Search Level page 2nd 3rd
Search Order page 2nd
search options
searching
order
Server Down Process
Broadcast Message page 2nd
Conditions page 2nd
Down Procedure page 2nd
Ordered Unload page 2nd
Reporting page 2nd
Targeted Messages page 2nd
server inventory
Configuration Editor
configuring 2nd 3rd
hardware scan
inventory service
software scan
server management 2nd
Server Manager engine
Server Policy Package
Copy Files policy 2nd 3rd
creating 2nd 3rd
NetWare Set Parameters policy 2nd
Policies Property page 2nd 3rd 4th 5th 6th
Scheduled Down policy 2nd
Scheduled Load/Unload policy 2nd
Server Down Process policy 2nd 3rd 4th 5th 6th 7th 8th 9th 10th 11th 12th 13th
Server Scripts policy 2nd
SNMP Community Strings policy 2nd 3rd
Text File Changes policy 2nd 3rd 4th 5th 6th 7th
ZENworks for Servers policy 2nd 3rd 4th 5th 6th
Server Scripts 2nd
Service Location Policy
ZENworks Database policy. [See ZENworks Database policy]2nd [See ZENworks Database policy]
Service Location Policy package
Service Location Policy Package
Associations Property page
creating 2nd
Policies Property page
SMTP Host policy. [See SMTP Host policy]
TED policy. [See TED policy]
SMTP Host
SNMP Trap Targets policy 2nd
SNMP Community Strings 2nd 3rd
SNMP Trap Targets 2nd
Solaris
Server Policy Package
TED
Messaging Property page 2nd 3rd
Schedule Property page 2nd
Settings Policy page 2nd
Variablbes Property page 2nd
Text File Changes
append to file
Policy Schedule page
prepend to file
search file 2nd 3rd
Windows
Server Policy Package 2nd
ZENworks Database 2nd
ZENworks for Servers 2nd
Configuration page 2nd
Port Configuration page
users, adding
policies database
Policies pages
Container Policy package
Policies Property page
Policies property page
Server Policy Package
general policies
Linux policies
Solaris policies
Windows policies 2nd
Policies tab (Remote Web Console)
policy engine
console commands 2nd 3rd
debug console commands 2nd
policy eventbased command
policy list command
policy objects
Policy Package agents 2nd
policy packages 2nd
policy plugins command
policy refresh command
policy refreshonly command
policy reports
policy rescheduleonly command
Policy Schedule page
policy schedules command
policy services
troubleshooting
agent associations
concurrent distributions
extractions
no database specified error
server associations
subscriber timeouts
policy status command
policy-enabled server management
inventory agents
inventory servers
remote managed servers
TED servers
ZENworks for Servers database
policy-enabled server management services
ConsoleOne snap-ins
packages 2nd
policies 2nd
policies database
Remote Web Console
starting 2nd 3rd
TED
database
distributor
subscribers
policy-enabled server management Web components
requirements 2nd 3rd 4th
policy/package agents
monitoring 2nd
Actions tab
Configuration tab
Policies tab
Schedule tab
Software Packages tab
poliy and distribution services databases
polling
devices
polling frequencies 2nd
Polling views
Port Configuration page
ZENworks for Servers policy
port numbers
RCONSOLEJ utility
ZENworks Web Server
ports
switch
statistics 2nd
Postinstallation Load/Unload Property page
Server Software Package components
Postinstallation Script Property page
Server Software Package components
postinstallation scripts
preferred RMON agents
selecting 2nd
Preinstallation Load/Unload Property page 2nd
Java classes, loading 2nd
Java processes, unloading
NLMs, loading
services
starting
stopping
Preinstallation Requirements Property page
component mansgement
preparing
network maps
prepending
files
search strings
text
files 2nd
prerequisite checklist (installation) 2nd
preventing
node deletion
primary agents
segments
print servers
NetWare
discovering
printers
network
discovering
printing
inventory reports
Probe Configuration group
RMON2 agents
probes
network
segments
procedures
down servers
processed alarms
processes
Java
postinstallation loading/unloading
unloading
processing
errors
local file copy
processors
alarm
archive
inbound
information
viewing
outbound
Products.dat Property page
Server Software Package components
products.dat rule
Server Software Package requirements
profiles
Ethernet network
FDDI network
NetWare server 2nd
token ring network
Trend view
customizing
Windows server 2nd
prompt command 2nd
properties
distribution objects
agents
channels
general 2nd
scheduling 2nd 3rd
distributors
distribution
general 2nd
messaging 2nd 3rd 4th
NDS rights 2nd 3rd
Other Property page 2nd
routing heirarchy 2nd 3rd
scheduling 2nd 3rd
external subscribers
channels
general
network addresses
management console
server level
site level
subscribers
channels
general 2nd
messaging 2nd 3rd
scheduling 2nd 3rd 4th
variables 2nd
TED channels
distributions
scheduling
settings
subscribers
Protocol Directory group
RMON2 agents
Protocol Directory tab
Protocol Distribution group
RMON2 agents
Protocol Distribution view
protocol traffic
protocols, viewing 2nd
segment distribution 2nd
protocols
internode communication
network
viewing 2nd
nodes
purge database entries parameter
purge utility
alarms
purging
alarms

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

RAM
servers
viewing
RBS Admin role
RBS module object
RBS role object
RBS Unified View
RCONSOLEJ utility
port numbers
reads
files
baseline documents
rebuild option
received time
alarms 2nd
received time alarms
receivers (inventory)
recipients
alarms
configuring 2nd
Red Hat Package Manager. [See RPM]
refresh command
Refresh Interval page
refreshing
alarms
policies
registry
keys
customizing
registry rule
Server Software Package requirements
Registry Settings Property page
Server Software Package components
relationships
TED 2nd
relative package scheduling
relative time
captured packets
remote managed servers
identifying
remote management agents
troubleshooting
remote management servers
Windows
requirements
remote management services
Remote ping role
remote server management 2nd
NetWare servers 2nd
NT/2000 servers 2nd 3rd
Remote Web Console
Actions tab
Channels tab
TED agents
Configuration tab
TED agents
Distribution tab
TED agents 2nd
Events tab
TED agents
Policies tab
policy services
Schedule tab
Security tab
TED agents
Software Packages tab
Remote Web Console object
Remote Web Console tool 2nd
policy/package agent monitoring 2nd
Actions tab
Configuration tab
Policies tab
Schedule tab
Software Packages tab
TED agents, monitoring 2nd 3rd
Channels tab
Configuration tab
Distribution tab 2nd
Events tab
Security tab
renaming
management console views
replacing
lines
search strings
search strings
words
search strings
Reporting page 2nd
reports
alarm
health
inventory
comprehensive inventory list 2nd
exporting 2nd
filtering
generating 2nd 3rd
printing
simple inventory list 2nd
viewing 2nd
Management Site services 2nd
network health
customizing 2nd 3rd
Ethernet network profile
FDDI network profile
force running 2nd
generating
health profiles, adding 2nd 3rd
managed networks trend parameters 2nd
managed server trend parameters 2nd
NetWAre server profile 2nd
scheduling 2nd
token ring network profile
viewing 2nd 3rd
Windows profile 2nd
policy
server inventory
server policies
TED 2nd 3rd 4th
Detailed reports
Distribution Detail report
History reports
Revision History for Failures report
Revision History report
Subscriber Detail report 2nd
Subscriber Distribution Detail report
topology 2nd
Computer Systems by Segment report
generating 2nd
NCP Servers report 2nd
Router report
Segment report
Segment Topology report 2nd
viewing 2nd
requirements
management console
management servers
NetWare managed servers
NetWare policy-enabled server management servers
NetWare traffic analysis servers
policy-enabled server management Web components 2nd 3rd 4th
Server Software package
Server Software Packages 2nd 3rd 4th
disk space
file rule
memory
operating system
products.dat rule
registry rule
set commands
Unix policy-enabled server management servers
Windows managed servers
Windows policy-enabled server management servers
Windows traffic analysis server
ZENworks for Servers 3 2nd 3rd
Requirements Property page
Server Software Package 2nd 3rd 4th
disk space
file rule
memory
operating system
products.dat rule
registry rule
set commands
resizing
columns
management console views
resolve command
resources
Consulting Services
cool solutions 2nd
technical support services
ZENworks Web site
results
network discovery
checking 2nd
retry times parameter
retry x times flag
reusing
subscribers
Revision History Failure report
Revision History for Failures reports
Revision History report
Revision History reports
rights
NDS
distributors 2nd 3rd
volume rights
configuring
Rights to Files and Folders Property pages 2nd
rings
source-route bridged token
discovering
rising threshold values
RMON agents
available services
interface indexes
MAC addresses
names
preferred
selecting 2nd
status
traffic analysis 2nd
troubleshooting
versions
RMON Conformance group
RMON2 agents
RMON Lite agents
traffic analysis 2nd
RMON Plus agents
traffic analysis 2nd
RMON property page
RMON services
information
viewing
RMON tables not listed error
RMON2 agents
traffic analysis 2nd
role-based services 2nd
roles
administration
management site administrator 2nd
Alarm Manager
Database Object Editor
DB_ADMIN_TOOL
management
Atlas Manager
MIB browser
MIB compiler
Node mangement
RBS Admin
Remote ping
Segment Admministrator
Segment Manager
Segment Monitor
server
Server Administrator
Server Manager
Server Monitor
Site Database Administrator
Traffic management
Unified View
ZFS maps
roll-up policies
configuring
rollbacks
Server Software package
root servers
roots
source
context
Router reports
routers
IP
discovering
nodes
IPX
nodes
segments
routes
distribution
configuring 2nd
hierarchies
TED 2nd
routing hierarchies
TED 2nd
Routing Hierarchy Property page
distributors 2nd 3rd
routing tables
TED
RPM (Red Hat Package Manager)
RPM agents 2nd
run distributions immediately option
run immediately distribution objects scheduling option
run immediately package scheduling
run immediately subscriber scheduling option
running status

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

sample intervals
trend initialization file
SAP packets
management devices
SAS service object
saving
management console views
scalar objects
viewing
MIB browser 2nd
scanners
inventory
scanning
inventory servers 2nd
scans
hardware
configuring
software
configuring
Schedule Property page 2nd
distribution objects 2nd 3rd
daily
interval
monthly
never
run immediately
time
yearly
distributors 2nd 3rd
daily
interval
monthly
never
run immediately
send immediately
time
yearly
TED channels
Schedule tab (Remote Web Console)
Scheduled Down policy 2nd
Scheduled Load/Unload policy 2nd
schedulers
TED components
interactions 2nd
scheduling
channels
distribution
distribution objects 2nd 3rd
daily
interval
monthly
never
run immediately
time
yearly
distributor/subscriber configurations 2nd
distributors
daily
interval
monthly
never
properties 2nd 3rd
run immediately
send immediately
time
yearly
loading/unloading
servers
network discovery
network health reports 2nd
packages
daily
event
interval
monthly
package schedule option
relative
run immediately
time
weekly
yearly
policies
servers
subscribers
daily
interval
monthly
never
properties 2nd 3rd 4th
run immediately
time
yearly
TED channels
scopes
discovery
customizing 2nd 3rd
IP 2nd
IPX
screens
NetExplorer
Script Property page
Server Software Package components
scripts
postinstalltion
Server Software Package components
servers
configuring
search files
Server Software Package components 2nd 3rd
Search Level page 2nd 3rd
Search Order page 2nd
search policies
Refresh Level page
Search Level page 2nd 3rd
Search Order page 2nd
searches
entire line
line end
line start
string
replacing
strings
result actions 2nd
sub-string
whole world
searching
policies
options
order
security
alarms
configuring 2nd
Security tab
TED agents
Segment Administrator role
Segment Dashboard view 2nd
Segment Details dialog box
Segment Manager role
Segment Monitor role
Segment reports
Segment Summary view 2nd 3rd 4th
Segment Topology reports 2nd
segments
agent status
bandwidth
creating
DOE 2nd
errors
hubs
IP addresses
IP nodes
IPX addresses
IPX nodes
kilobytes per second
messages
names 2nd
network
discovered 2nd
traffic analysis
traffic analysis. [See network segments, traffic analysis]
network probes
nodes
packets
primary agents
protocol distribution 2nd
routers
servers
speed
switches
types 2nd
unified view 2nd
workstations
segments object
selectors (inventory)
send command
send distributions immediately option
senders (inventory)
sending
down server messages
e-mail notifications 2nd 3rd
files
destination subscribers
TED
Server Administrator role
Server BIOS Listing report
server console parameter
distributors
Message property page
subscribers
Server Down Process policy
Broadcast Message page 2nd
Conditions page 2nd
Down Procedure page 2nd
Ordered Unload page 2nd
Reporting page 2nd
Targeted Messages page 2nd
Server Down Process report
server group object
server inventory
components 2nd 3rd
configuring
inventory service object 2nd 3rd
server inventory policy 2nd 3rd
roll-up policy
scanning 2nd
service location package 2nd
server inventory policies
Configuration Ediotr
configuring 2nd 3rd
hardware scan
inventory service
software scan
server inventory reports
server level properties
server management
agents
commands 2nd
configuration information, viewing 2nd 3rd
legends
graphs, stacking/unstacking
grid lines
time spans 2nd
Trend view profile
viewing
optimizing
alarm generation 2nd 3rd 4th 5th
alarm recipients 2nd
initial threshold values 2nd
initial trend vaules 2nd 3rd 4th
parameters
configuring 2nd
planning
baseline documents 2nd 3rd
remote
NetWare servers 2nd
NT/2000 servers 2nd 3rd
SNMP-based 2nd
summary data, viewing 2nd
trend data, viewing 2nd
trend samplings
customizing 2nd
threshold alarms
troubleshooting
connectivity
RCONSOLEJ port numbers
remote management agents
views
server management services
Server Manager engine
Server Manager role
server mangement agents
discovery components
Server Monitor role
Server Network Adapter Listing report
server not responding error
server objects
group membership attribute
Server Operating System Listing report
server package object
server policies reports
Server Policy Package
Copy Files policy 2nd 3rd
NetWare Set Parameters Policy 2nd
Scheduled Down Policy 2nd
Scheduled Load/Unload Policy 2nd
Server Down Process Policy
Broadcast Message page 2nd
Conditions page 2nd
Down Procedure page 2nd
Ordered Unload page 2nd
Reporting page 2nd
Targeted Messages page 2nd
Server Scripts policy 2nd
SNMP Community Strings policy 2nd 3rd
Text File Changes policy
append to file
Policy Schedule page
prepend to file
search file 2nd 3rd
ZENworks for Servers policy 2nd
Configuration page 2nd
Port Configuration page
users, adding
Server Policy Packages
creating 2nd 3rd
Policies Property page 2nd 3rd 4th 5th 6th
Server Processor Current Speed Listing report
Server Processor Family Listing report
Server Processor Maximum Clock Speed Listing reort
server roles
Server Scan Time Listing report
Server Scripts policy 2nd
Server Software Listing report
Server Software Package agents 2nd
Server Software Packages 2nd
.CPK files
.SPK files 2nd
compiling
components
appending text to files
file copy operations 2nd
file identifications 2nd
folder identifications
Identification Property page
local file copy operations
managing
parameters 2nd
postinstallation loading/unloading
postinstalltion scripts
preinstallation loading/unloading 2nd
preinstallation requirements
prepending text to files
Products.dat Property page
registry
scripts
search files 2nd 3rd
text files 2nd 3rd
creating 2nd 3rd 4th
identification
installation failures
installing 2nd
managing
NLMs
Java classes 2nd
loading
unloading
overview
requirements 2nd 3rd 4th 5th
disk space
file rule
memory
operating system
products.dat rule
registry rule
set commands
rollbacks
services
starting
stopping
updating
variables 2nd
Server Video Adapter Listing report
servers
associations
troubleshooting
cache activity
viewing
communications
discovering
companion
down server notification
configuration information
viewing 2nd 3rd
contacts
viewing
CPU utilization
viewing
date/time
viewing
descriptions
viewing
down
companion server notification
conditions 2nd
messages
procedures
unload order
events
viewing
intermediate
inventory
identifying
Management Services
troubleshooting
inventory database
requirements
IP addresses
viewing
IPX addresses
viewing
leaf
loading/unloading
scheduling
locations
viewing
logged in users
viewing
managed
identifying
trend parameters 2nd
management
discovering
identifying
LAN traffic analysis
requirements
managing
policies 2nd
managing. [See server management]
monitoring agent
LAN traffic analysis
names
viewing
NetWare
discovery components
remote management 2nd
NetWare file
discovering
NetWare inventoried
requirements
NetWare inventory
requirements
NetWare managed
requirements
NetWare policy-enabled server management
requirements
NetWare print
discovering
NetWare traffic analysis
requirements
open files
viewing
RAM
viewing
remote managed
identifying
remote management
root
scheduling
scripts
configuring
segments
standalone
status
viewing
summary
viewing
summary data
viewing 2nd
target
Server Software Package installation 2nd
TED
identifying
tracking
baseline documents
trees
viewing
trend data
viewing 2nd
trending
troubleshooting
baseline documents
types
viewing
Unix policy-enabled server management
requirements
up times
viewing
volume data
viewing
Windows inventoried
requirements
Windows inventory
requirements
Windows managed
requirements
Windows NT/2000
remote management 2nd 3rd
Windows policy-enabled server management
requirements
Windows remote management inventoried
requirements
Windows traffic analysis
requirements
ZENworks Web
port number
service location package object
service location packages
configuring 2nd
Service Location Policy package
Service Location Policy Package
SMTP Host policy
SNMP Trap Targets policy 2nd
TED policy
Messaging Property page 2nd 3rd
Schedule Property page 2nd
Settings Policy page 2nd
Variables Property page 2nd
ZENworks Database policy 2nd
Service Location Policy Packages
Associations Property page
creating 2nd
Policies Property page
services
adding
connectivity tests 2nd
alarm management
available
RMON agents
Consulting
distribution
starting
troubleshooting 2nd 3rd 4th 5th 6th 7th
file
information, viewing
inventory
configuring
inventory management 2nd
list of
nodes
Management
administration roles 2nd 3rd
management console 2nd
management console. [See management console]
Management Site Services
network planning 2nd 3rd 4th 5th
overview
remote control
server inventory
server roles
management
starting 2nd 3rd
Management
traffic management 2nd
views
management site
Management Site
alarm management 2nd
management site
alarms
autodiscovery
Management Site
database administration
management site
databases
MIB tools
Management Site
MIB tools
network discovery 2nd
reports 2nd
management site
role-based
Management Site
role-based
SNMP services 2nd
topology mapping
monitoring
nodes, configuring 2nd
starting 2nd 3rd
target nodes 2nd 3rd 4th 5th 6th 7th 8th
policy
troubleshooting 2nd 3rd 4th 5th 6th 7th
policy-enabled server management
ConsoleOne Snap-ins
packages 2nd
policies 2nd
policies database
Remote Web Console
starting 2nd 3rd
TED
TED;database
TED;distributors
TED;subscribers
remote management
RMON
information, viewing
role-based
server management
SNMP
monitoring 2nd
SNMP messages
identifying
starting
stopping
technical support
traffic analysis
Services tab
DOE node editor
set commands
Server Software Packages
Set Commands Property page
Server Software Package components 2nd
setconsolelevel command 2nd
setfilelevel command 2nd
Settings Policy page 2nd
Settings Property page
distributors 2nd
subscribers 2nd
TED channels
severity
alarms 2nd 3rd
severity disposition
alarms
severity levels
alarms
SFT III engines
discovering
showschedule command
showstates command
showvars command
simple inventory list report 2nd
simple TED layouts 2nd
site administrator roles 2nd
Site Database Administrator role
site level properties
site objects
inventory database classes
sites
management
identifying
size
captured packets
SManager directory
SMTP Host policies
SNMP Trap Targets policy 2nd
SMTP hosts
IP addresses
snap-ins
ConsoleOne
policy services
server management
SNMP
community names
connectivity
troubleshooting
traps
monitoring
SNMP agents
troubleshooting
SNMP community names
customizing 2nd
disocery cycle
SNMP Community Strings policy 2nd 3rd
SNMP messages
service identification
SNMP MIB Browser
SNMP MIB Compiler
SNMP parameters
conifguring 2nd
NetWare configuration 2nd
Windows NT/2000 configuration 2nd
SNMP services
monitoring 2nd
SNMP Settings tab
ConsoleOne
SNMP trap forwarder
alarm management
SNMP trap injectors
alarm management
SNMP trap parameter
distributors
Message property page
subscribers
SNMP trap receiver
alarm management
SNMP Trap Targets policy 2nd
SNMP traps
forwarding
SNMP-based server management 2nd
software
baseline documents
consolidator 2nd
discovery 2nd 3rd
scans
configuring
software packages
adding
distributions
Server Software
.CPK files
.SPK files 2nd
compiling
components. [See components, Server Software Packages]
creating 2nd 3rd 4th
identification
installation failures
installing 2nd
managing
overview
requirements 2nd 3rd 4th 5th
rollbacks
updating
variables 2nd
Software Packages tab (Remote Web Console)
Software Summary Listing report
Solaris policies
Server Policy Package
sorting
alarm views 2nd 3rd
management console views
source addresses
alarms 2nd
source path parameter
source paths
local file copy
source roots
context
Source Route Bridging group
Bridge agents
source trees
structure
Desktop Application agent
source-route bridged token rings
discovering
sources
captured packets
spanning
trees
Spanning Tree Protocol group
Bridge agents
spc command
speed
segments
SPK files
Server Software package 2nd
stacking
graphs
standalone servers
starting
distribution services
LAN traffic analysis agents
management services 2nd 3rd
MIB browser
monitoring services 2nd 3rd
network discovery 2nd
packet captures 2nd
policy-enabled server management services 2nd 3rd
services
traffic analysis agents
state
alarms
state disposition
alarms
Static group
Static agents
Stations view
node traffic 2nd 3rd
statistics
active servers
baseline documents
alarm
network segments
bandwidth utilization
baseline documents
configuring
kilobytes per second
baseline documents
network error rates
baseline documents
network segments
viewing 2nd
node traffic 2nd 3rd
packet capture filtering
packets per second
baseline documents
switch port 2nd
Statistics group
RMON agent
RMON Lite agent
status
initial discovery
stopping 2nd 3rd
servers
viewing
status bar
ticker tape messages
status command
statuses
agents
configuring
segments
completed
not loaded
RMON agents
running
suspended
unkown
waiting to start
stopping
LAN traffic analysis agents
network discovery 2nd
services
traffic analysis agents
storage devices
information
viewing
Storage Devices Inventory report
Storage Devices Listing report
storers (inventory)
strategies
management
networks
strings
community
configuring
search
replacing
result actions 2nd
sub-string searches
subdirectories
local file copy
subnet masks
nodes
Subscriber Detail report
Subscriber Detail reports 2nd
Subscriber Distribution Detail reports
subscriber group objects
subscriber objects
subscribers 2nd
channels
configurations, scheduling 2nd
connection timeouts
console commands 2nd
debug console commands
dependents 2nd
destination
files, sending
directories
distributor digital certificate copies
end-node
external
chennels
General Property page
network addresses
overview 2nd
free disk space
high priority
input rates
low priority
maximum concurrent distributions
medium priority
message configuration parameters
message levels
messaging properties 2nd 3rd
objects, creating
overview
parent
configuring
parent subscribers
parent. [See parent subscribers]
reusing
schedules
scheduling 2nd 3rd 4th
daily
interval
monthly
never
run immediately
time
yearly
settings 2nd
Settings Property page 2nd
timeouts
troubleshooting
variables 2nd 3rd
Subscribers Property page
TED channels
subscribors
TED
Successful Policies report
summaries
alarm views 2nd 3rd
alarms
captured packets 2nd 3rd
servers
viewing 2nd 3rd
switch traffic 2nd
summary
alarms 2nd
interfaces
network segments 2nd 3rd 4th
summary view
management console
Management Services
server management
support
topologies
troubleshooting
suspended status
switch traffic
port statistics 2nd
summary data 2nd
switch-related information
nodes
switches
segments
synchronize directories flag
syntaxes
eDirectory attributes 2nd
System Information Listing report
System Internal Hardware report
systems
network
discovered 2nd
Systems Software Inventory report

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

tabular views
target nodes
monitoring services
connectivity testservices, adding 2nd
multiple 2nd 3rd
single 2nd
target path parameter
target servers
Server Software Packages installation 2nd
Targeted Messages page 2nd
Technical Support Knowledgebase Web site
TED
agents 2nd
Desktop Application 2nd 3rd 4th
files 2nd 3rd
FTP 2nd
HTTP
Policy Package 2nd
RPM 2nd
Server Software Package 2nd
certificates
channels
Distributions Property page
schedules
scheduling
Settings Property page
Subscribers Property page
components 2nd
scheduler interactions 2nd
database
dependents 2nd
distribution objects 2nd
agents
channels
General Property page 2nd
manual distributions
manual distributions. [See manual distributions]
scheduling 2nd 3rd
distribution routes 2nd
distributions
software packages, adding
distributors 2nd
configurations, scheduling 2nd
connection timeouts
console commands 2nd
debug console commands
dependents 2nd
directories
distribution properties
distribution schedules
distribution topology
high priority
input rate
low priority
managing
maximum concurrent distributions
medium priority
message configuration parameters
message levels
messaging properties 2nd 3rd 4th
multiple
names
NDS rights 2nd 3rd
objects, creating
Other Property page 2nd
overview 2nd
routing hierarchy 2nd 3rd
schedules
scheduling properties 2nd 3rd
settings 2nd
Settings Property page 2nd
variables
distributrs
digital certificates, copying
external subscribers
channels
General Property page
network addresses
overview 2nd
files
sending
layouts
complex 2nd 3rd
simple 2nd
tree spanning 2nd
objects 2nd 3rd
parent subscribers
overview 2nd
relationships 2nd
reports 2nd
Detailed reports
History reports
routing hierarchies 2nd
routing tables
scheduler interactions 2nd
subscri ers
subscribers
channels
configurations, scheduling 2nd
connection timeouts
console commands 2nd
debug console commands
dependents 2nd
directories
distributor digital certificate copies
end-node
external. [See external subscribers]
free disk space
high priority
input rates
low priority
maximum concurrent distributions
medium priority
message configuration parameters
message levels
messaging properties 2nd 3rd
objects, creating
overview
parent subscribers
reusing
schedules
scheduling 2nd 3rd 4th
settings 2nd
Settings Propety page 2nd
variables 2nd 3rd
TED (Tiered Electronic Distribution) 2nd
TED agents
monitoring 2nd 3rd
Channels tab
Configuration tab
Distribution tab 2nd
Events tab
Security tab
TED channel object
TED distribution object
TED distributions
monitoring 2nd
TED distributor object
TED external subscriber object
TED objects
creating
Web-based management tool 2nd
deleting
Web-based management tool
editing
Web-based management tool 2nd
TED policies
Messaging Property page 2nd 3rd
Schedule Property page 2nd
Settings Policy page 2nd
Variables Property page 2nd
TED reports 2nd
Distribution Detail report
Revision History for Failures report
Revision History report
Subscriber Detail report 2nd
Subscriber Distribution Detail report
TED servers
identifying
TED subscriber group object
TED subscriber object
template archivers
templates
alarm
testing
target nodes
multiple 2nd 3rd
single 2nd
text
appending
files
prepending
files
search file changes 2nd 3rd
Text File Changes policy
append to file
Policy Schedule page 2nd
prepend to file
search file 2nd 3rd
text files
appending
prepending
Server Software Package components 2nd 3rd
Text Files Property page
Server Software Package components 2nd 3rd
appending text to files
prepending text to files
search files 2nd 3rd
This Object page
trustees 2nd
distributors
threads
network segments 2nd
threads command 2nd
threshold alarms
customizing
threshold traps
enabling/disabling
threshold values
servers 2nd
rising/falling
traps
thresholds
alarm
baseline documents
alarms
troubleshooting
ticker tape messages
alarm
Tiered Distribution View
TED distribution monitoring
Tiered Electronic Distribution. [See TED]
time command 2nd
time configuration scheduling
time distribution objects scheduling option
time intervals
configuring
time package scheduling
time spans
customizing 2nd
timed distribution scheduling option
timed subscriber scheduling option
timeouts
connection
distributors
subscribers
subscribers
troubleshooting
titles
management console views
token ring network profile
tolerance
fault
Desktop Application agents
tools
MIB
management site services
Management Site Services
Remote Web Console 2nd
policy/package agent monitoring 2nd
TED agents, monitoring 2nd 3rd 4th 5th 6th 7th 8th 9th
SNMP MIB Browser
SNMP MIB Compiler
Web-based management
Remote Web Console tool. [See Remote Web Console tool]
TED distributions, monitoring 2nd
TED objects, creating 2nd
TED objects, deleting
TED objects, editing 2nd
topologies
distribution
support
troubleshooting
topology databases
topology mapping
Management Site Services
topology reports 2nd
Computer Systems by Segment report
generating 2nd
NCP Servers report 2nd
Router report
Segment report
Segment Topology report 2nd
viewing 2nd
Trace Display view
decoded packet data
filters, setting 2nd
hexadecimal packet data
highlighting tool
summary pane 2nd
tracking
servers
baseline documents
traffic
analyzing
Management Services 2nd
traffic analysis
troubleshooting
false duplicate IP addresses
interfaces
LAN traffic agents
LANalyzer error
LANZ.NCF file
LANZCON utility
MIB-2 not found error
no response messages error
no SNMP response error
no statistics reported error
RMON agents
RMON tables not listed error
server not responding
topology support
traffic analysis (LAN) 2nd
agents 2nd
Bridge 2nd
LANZ.NCF file 2nd
LANZCON utility 2nd 3rd 4th
NetWare configuration
NetWare SNMP parameters 2nd
NT SNMP parameters 2nd
RMON 2nd
RMON Lite 2nd
RMON Plus 2nd
RMON2 2nd
staring/stopping
starting/stopping
Windows NT/2000 configuration 2nd
communication
components
management console
management server
monitoring agent server
configuring
baseline documents 2nd
preferred RMON agents 2nd
SNMP parameters 2nd
network segments
alarm statistics
performance 2nd
statistics, viewing 2nd
summary 2nd 3rd 4th
threads 2nd
node traffic
inactivity, monitoring 2nd
internode communication 2nd 3rd
statistics 2nd 3rd
packet captures 2nd
capture filter 2nd 3rd
filtering 2nd
highlighting data
starting 2nd
viewing 2nd
protocol traffic
protocols, viewing 2nd
segment distribution 2nd
switch traffic
port statistics 2nd
summary data 2nd
traffic analysis agents
discovery components
identifying
traffic analysis services
Traffic management role
Trand Sata view
transparent bridges
discovering
Transparent Bridging group
Bridge agents
transports
IPX
identifying
trap configuration files
community string
security 2nd
time intervals
traps
SNMP
monitoring
threshold
enabling/disabling
TRAPTARG.CFG file
customizing
tree spanning TED layouts 2nd
trees
servers
viewing
source
structure
spanning
trend agents
servers
trend buckets
trend initialization file
trend data
servers
viewing 2nd
trend initialization file
enabling/disabling
sample intervals
threshold values 2nd
rising/falling
traps
trend buckets
trend parameters
managed networks 2nd
managed servers 2nd
trend samplings
customizing 2nd
threshold alarms
Trend Sata view
trend values
servers
sample intervals
trend buckets
trend data, enabling/disabling
trend view
management console
Management Services
server management
Trend view profile
customizing
trending
servers
troubleshooting
alarms
Alarm Manager database status
SNMP agents
SNMP connectivity
thresholds
unkown alarms
Atlas Manager
distribution services
agent associations
concurrent distributions
extractions
no database specified error
server associations
subscriber timeouts
NetWare
eDirectory errors 2nd
file system errors 2nd
policy services
agent associations
concurrent distributions
extractions
no database specified error
server associations
subscriber timeouts
server inventory
server management
connectivity
RCONSOLEJ port numbers
remote management agents
servers
baseline documents
traffic analysis
false duplicate IP addresses
interfaces
LAN traffic agents
LANalyzer error
LANZ.NCF file
LANZCON utility
MIB-2 not found error
no response messages error
no SNMP response error
no statistics reported error
RMON agents
RMON tables not listed error
server not responding
topology support
trustees
local file copy
This Object page 2nd
distributors
types
alarms 2nd 3rd 4th
nodes
segments 2nd
servers
viewing

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

Unenforceable Policies report
Unified Port Traffic view 2nd 3rd 4th
unified views
Atlas Manager 2nd 3rd
devices 2nd
segments 2nd
UNIFIEDVIEW.INI file
UNIFIEDVIEW.INI file
updating
Unix policy-enabled server management servers
requirements
unknown alarms
troubleshooting
unkown status
unload order
down servers
unloading
Java processes
NLMs
NLMs/Java processes
postinstallation
servers
scheduling
unstacking
graphs
up times
servers
viewing
updating
Server Software Packages
UNIFIEDVIEW.INI file
User History group
RMON2 agents
users
adding
e-mail lists
information
viewing
servers
viewing
utilities
DSREPAIR
DSTRACE
LANZCON
LAN traffic analysis agents 2nd
traffic analysis agents 2nd
troubleshooting
NXPCON
discovery scopes 2nd 3rd
modules, loading 2nd
SNMP community names 2nd
workstation discovery
purge
alarms
RCONSOLEJ
port numbers
Utilization gauge

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

variables
alarms
distributors/subscribers
Server Software Packages 2nd
subscribers
properties 2nd
Variables Property page 2nd
Server Software Package 2nd
Variables Property Property page
subscribers 2nd
verify distributions flag
version command 2nd
versions
RMON agents
viewers
alarm
viewing
applications
information
captured packets 2nd
decoded packet data
hexadecimal packet data
summaries 2nd
disk adapters
information
grid lines
inventory reports 2nd
LAN adapters
information
legends
network connections
information
network health reports 2nd 3rd
network information
information
network protocols 2nd
network segment statistics 2nd
NLMs
information
OS kernel
information 2nd 3rd
package associations
policies
active/available
processors
information
RMON services
information
scalar objects 2nd
server configuration information 2nd 3rd
server summary data 2nd
server trend data 2nd
servers
cache activity
contacts
CPU utilization
date/time
descriptions
events
IP addresses
IPX addresses
locations
logged in users
names
open files
RAM
status
summary
trees
types
up times
volume data
storage devices
information
switch port statistics 2nd
switch summary data 2nd
topology reports 2nd
users
information
views
active alarms
management console
alarm history
management console
Alarm Statistics
alarms
active 2nd 3rd
filtering 2nd 3rd
history 2nd
sorting 2nd 3rd
summary 2nd 3rd
atlas
management console
Atlas Manager
Connectivity
console
management console
Management Services
server management
Conversations
node traffic 2nd 3rd
graphical
List Segments Statistics 2nd
management console 2nd 3rd
appearance 2nd 3rd 4th 5th
columns 2nd 3rd 4th
deleting/renaming
expanding
graphical
limiting 2nd
saving
sorting
tabular
Management Services
Monitor Nodes for Inactivity
node traffic 2nd
Polling
Protocol Distribution
Segment Dashboard 2nd
Segment Summary 2nd 3rd 4th
server management
Stations
node traffic 2nd 3rd
summary
management console
Management Services
server management
tabular
Tiered Distribution
distribution monitoring
Trace Display
decode pane
filters, setting 2nd
hexadecimal pane
highlighting tool
summary pane 2nd
trend
management console
Management Services
server management
Trend Data 2nd
unified
Atlas Manager 2nd 3rd
Unified Port Traffic 2nd 3rd 4th
volume data
servers
viewing
volume objects
rights
configuring
volumes
destination
files
utilization
baseline documents

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

waiting to start status
WAN page
Atlas Manager
WAN segments
discovering
WANs
container boundaries, crossing 2nd 3rd
hops
tree transmission
optimized hops
tree transmission
Web components
policy-enabled server management
requirements 2nd 3rd 4th
Web sites
Consulting Services
Cool Solutions 2nd
Technical Support Knowledgebase
ZENworks
Web-based management 2nd
Web-based management tool
Remote Web Console tool. [See Remote Web Console tool]
TED distributions, monitoring 2nd
TED objects, creating 2nd
TED objects, deleting
TED objects, editing 2nd
weekly package scheduling
whole world searches
windows
Capture Status
Packet Capture Setup
Windows
server profile 2nd
Windows 2000 servers
remote management 2nd 3rd
Windows inventoried server
requirements
Windows inventory servers
requirements
Windows managed servers
requirements
Windows NT servers
remote management 2nd 3rd
Windows NT/2000
traffic analysis agent configuration 2nd
LANZCON utility 2nd
SNMP parameters 2nd
starting/stopping
Windows policies
Server Policy Package 2nd
Windows policy-enabled server management servers
requirements
Windows remote management
requirements
Windows traffic analysis server
requirements
wizards
Desktop Application
ZENworks for Servers 2nd 3rd
words
search strings
working directories
configuring
working directory parameter
worksations
discovery
workstations
client
discovering
segments
writes
files
baseline documents

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

yearly configuration scheduling
yearly distribution objects scheduling option
yearly distribution scheduling option
yearly package scheduling
yearly subscriber scheduling option

[ Team LiB ]


[ Team LiB ]

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M] [N] [O] [P] [R] [S] [T] [U] [V] [W] [Y] [Z]

zenpolPolicy attribute
existing objects
ZENworks (zero-effort networks)
ZENworks Cool Solutions Web site 2nd
ZENworks Database policies 2nd
ZENworks for Desktops 2nd
ZENworks for Servers 3
benefits 2nd
installing 2nd
management/monitoring services 2nd
network maps, preparing
policy-enabled server management 2nd 3rd 4th 5th 6th
policy-enabled server management Web components requirements 2nd 3rd 4th
prerequisite checklist 2nd
requirements 2nd 3rd
ZENworks for Desktops, compared
ZENworks for Servers databases
identifying
ZENworks for Servers object
ZENworks for Servers policy 2nd
Configuration page 2nd
Port Configuration page
users, adding
ZENworks for Servers site object
ZENworks for Servers wizard 2nd 3rd
ZENworks Web Server
port number
ZENworks Web site
zero-effort networks. [See ZENworks]
ZFS maps role

[ Team LiB ]


Team LiB

Brought to You by

Like the book? Buy it!