Novell ZENWORKS 10 Best Practices Guide
Novell®
www.novell.com
AUTHORIZED DOCUMENTATION
System Planning, Deployment, and Best Practices Guide
ZENworks® 10 Configuration Management SP3
novdocx (en) 16 April 2010
10.3
March 30, 2010
System Planning, Deployment, and Best Practices Guide
Legal Notices
Novell, Inc., makes no representations or warranties with respect to the contents or use of this documentation, and
specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose.
Further, Novell, Inc., reserves the right to revise this publication and to make changes to its content, at any time,
without obligation to notify any person or entity of such revisions or changes.
Further, Novell, Inc., makes no representations or warranties with respect to any software, and specifically disclaims
any express or implied warranties of merchantability or fitness for any particular purpose. Further, Novell, Inc.,
reserves the right to make changes to any and all parts of Novell software, at any time, without any obligation to
notify any person or entity of such changes.
Any products or technical information provided under this Agreement may be subject to U.S. export controls and the
trade laws of other countries. You agree to comply with all export control regulations and to obtain any required
licenses or classification to export, re-export or import deliverables. You agree not to export or re-export to entities on
the current U.S. export exclusion lists or to any embargoed or terrorist countries as specified in the U.S. export laws.
You agree to not use deliverables for prohibited nuclear, missile, or chemical biological weaponry end uses. See the
Novell International Trade Services Web page (http://www.novell.com/info/exports/) for more information on
exporting Novell software. Novell assumes no responsibility for your failure to obtain any necessary export
approvals.
novdocx (en) 16 April 2010
Copyright © 2007-2010 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied,
stored on a retrieval system, or transmitted without the express written consent of the publisher.
Novell, Inc.
404 Wyman Street, Suite 500
Waltham, MA 02451
U.S.A.
www.novell.com
Online Documentation: To access the latest online documentation for this and other Novell products, see
the Novell Documentation Web page (http://www.novell.com/documentation).
Novell Trademarks
For Novell trademarks, see the Novell Trademark and Service Mark list (http://www.novell.com/company/legal/
trademarks/tmlist.html).
Third-Party Materials
All third-party trademarks are the property of their respective owners.
novdocx (en) 16 April 2010
novdocx (en) 16 April 2010
4 System Planning, Deployment, and Best Practices Guide
Contents
About This Guide 9
1 ZENworks Configuration Management: A Single Solution for Systems
Management 11
1.1 The Goal: Total Management, Zero Effort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 The Management Paradigm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 Management by Exception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 User-Based Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.3 Device-Based Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3 The Solution: ZENworks Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2 Performing Pre-Design Activities 15
2.1 Perform a Business Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Perform a Technical Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Gather Other Critical Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Develop High-Level Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.5 Develop Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Outputs from Pre-Design Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
novdocx (en) 16 April 2010
3 Gathering Critical Information for Design Activities 21
3.1 Design Criteria/Decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Decisions to Make Before Installing the Primary Server . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Infrastructure Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.3 Infrastructure Scale Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Scalability of the Primary Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Factors Influencing Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.2 Load Testing in the Novell SuperLab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3 Achieving Scalability in the Real World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 Scalability of Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Factors Influencing Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Load Testing in the Novell SuperLab. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Achieving Scalability in the Real World . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Scalability, Fault Tolerance, Maintenance, and Sizing of the Database Server. . . . . . . . . . . . 34
3.4.1 Sybase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.2 Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.3 Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.4.4 Database Sizing and Performance Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.5 Virtualization Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.6 Ports Used by ZENworks Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Network Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.1 Infrastructure vs. Bandwidth: Satellite Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.7.2 DNS and DHCP Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7.3 Time Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.7.4 Support for the NetWare Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Contents 5
4 Performing Design Activities 45
4.1 Design Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Developing a Detailed Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.2.1 Device Folder and Group Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2.2 User Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.2.3 Role-Based Administrative Accounts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2.4 Configuration Settings for the Management Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.2.5 Device Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.6 Adaptive Agent Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.2.7 Registration Rules and Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.2.8 Remote Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.2.9 Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.2.10 Application Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2.11 Policy Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.12 Imaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.13 Configuring a Layer 4 Switch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.14 ZENworks Systems Update. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Lab Testing and Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
4.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
novdocx (en) 16 April 2010
5 Deploying ZENworks Configuration Management 81
5.1 Pre-Deployment Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.2 Pre-Deployment Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.3 Pre-Deployment Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4 Pilots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.5 Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.6 Wider Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.7 Post-Deployment Documentation and Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6 Deployment and Migration Scenarios 85
6.1 New ZENworks Customer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.1 Build a Model Office Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.2 Planning. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.1.3 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2 Migrating From a Previous Version of ZENworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.1 Application Deployment Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2.2 Application and Policy Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2.3 Novell eDirectory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.2.4 Repurpose Hardware Used by Previous Zenworks Products . . . . . . . . . . . . . . . . . . 92
A ZENworks Services 93
A.1 ZENworks Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A.1.1 Checking the Status of a ZENworks Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A.1.2 Starting a ZENworks Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A.1.3 Stopping a ZENworks Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.1.4 Restarting a ZENworks Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.1.5 ZENworks Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A.2 Useful URLs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.2.1 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.2.2 Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.3 Critical File Locations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
A.3.1 Installation Directories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6 System Planning, Deployment, and Best Practices Guide
A.3.2 The ZENworks Content Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
A.4 Logging Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.4.1 Local Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
A.4.2 Installation Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.4.3 Registration Log File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
A.5 Backing Up and Restoring the ZENworks Certificate Authority . . . . . . . . . . . . . . . . . . . . . . . 100
B The ZENworks Configuration Management Architecture 101
B.1 ZENworks Architecture Reference. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B.1.1 Standard Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
B.1.2 ZENworks Primary Server Architectural Components . . . . . . . . . . . . . . . . . . . . . . . 103
B.1.3 Agent Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.1.4 Agent Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
B.2 Detailed ZENworks Components Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
C ZENworks Configuration Management Tuning Parameters For Bundle
Distribution 109
C.1 JAVA Memory Allocation: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
C.2 Threads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
C.3 CLIENT RETRIES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
C.4 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
novdocx (en) 16 April 2010
D Reference Materials 113
D.1 Online Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
D.2 Sample Business Requirements Survey Questions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
D.3 Sample Technical Requirements Survey Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
D.4 Extended Port Chart Including Port Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Contents 7
novdocx (en) 16 April 2010
8 System Planning, Deployment, and Best Practices Guide
About This Guide
novdocx (en) 16 April 2010
The purpose of this System Planning, Deployment, and Best Practices Guide is to describe the items
that need to be considered when designing a Novell
solution and deploying it across small and large scale enterprises.
The information in this guide is organized as follows:
Chapter 1, “ZENworks Configuration Management: A Single Solution for Systems
Management,” on page 11
Chapter 2, “Performing Pre-Design Activities,” on page 15
Chapter 3, “Gathering Critical Information for Design Activities,” on page 21
Chapter 4, “Performing Design Activities,” on page 45
Chapter 5, “Deploying ZENworks Configuration Management,” on page 81
Chapter 6, “Deployment and Migration Scenarios,” on page 85
Chapter A, “ZENworks Services,” on page 93
Chapter B, “The ZENworks Configuration Management Architecture,” on page 101
Appendix C, “ZENworks Configuration Management Tuning Parameters For Bundle
Distribution,” on page 109
Appendix D, “Reference Materials,” on page 113
Audience
®
ZENworks® 10 Configuration Management
This guide is intended for ZENworks administrators.
Feedback
We want to hear your comments and suggestions about this manual and the other documentation
included with this product. Please use the User Comments feature at the bottom of each page of the
online documentation, or go to the Novell Documentation Feedback site (http://www.novell.com/
documentation/feedback.html) and enter your comments there.
Additional Documentation
ZENworks Configuration Management is supported by other documentation (in both PDF and
HTML formats) that you can use to learn about and implement the product. For additional
documentation, see the ZENworks 10 Configuration Management SP3 (10.3) documentation (http://
www.novell.com/documentation/zcm10/).
Documentation Conventions
In Novell documentation, a greater-than symbol (>) is used to separate actions within a step and
items in a cross-reference path.
®
A trademark symbol (
trademark.
, TM, etc.) denotes a Novell trademark. An asterisk (*) denotes a third-party
About This Guide 9
When a single pathname can be written with a backslash for some platforms or a forward slash for
other platforms, the pathname is presented with a backslash. Users of platforms that require a
forward slash, such as Linux*, should use forward slashes as required by your software.
novdocx (en) 16 April 2010
10 System Planning, Deployment, and Best Practices Guide
1
ZENworks Configuration
novdocx (en) 16 April 2010
Management: A Single Solution
for Systems Management
The purpose of this System Planning, Deployment, and Best Practices Guide is to describe the issues
you need to consider when designing a Novell
solution and deploying it across small and large scale enterprises. This guide is not meant to replace
the other online resources that Novell provides to customers and partners, but to supplement that
material so that you have a better understanding of certain design-related topics and requirements.
ZENworks Configuration Management is also supported by other documentation (in both PDF and
HTML formats) that you can use to learn about and implement the product. For additional
documentation, see the ZENworks 10 Configuration Management SP3 (10.3) documentation (http://
www.novell.com/documentation/zcm10/index.html).
This following sections contain more information:
Section 1.1, “The Goal: Total Management, Zero Effort,” on page 11
Section 1.2, “The Management Paradigm,” on page 12
Section 1.3, “The Solution: ZENworks Configuration Management,” on page 13
®
ZENworks® 10 Configuration Management
1
1.1 The Goal: Total Management, Zero Effort
Over the last decade, Novell ZENworks has provided the gold standard for centralized configuration
and management of network endpoints in today’s complex, heterogeneous corporate networks.
ZENworks Configuration Management is a key implementation of ZENworks technology, enabling
policy-based automation of software and patch deployment, asset tracking, endpoint security, OS
migration, and many other routine tasks.
With ZENworks Configuration Management, IT staff can synchronize the Windows* desktop
environment with their company’s business policies, while saving IT time, budget, and resources for
strategic projects. All of this focuses on the ZENworks goal to provide total network management
while bringing the associated management effort as close to zero as possible.
Introduced in the last quarter of 2007, the latest version of ZENworks Configuration Management
moves toward that goal by using a completely redesigned architecture to greatly simplify,
consolidate, and integrate policy-based management of Windows network endpoints, including
systems running Windows Vista*.
The latest version of ZENworks Configuration Management does the following:
Provides a single modular architecture, platform, and agent for all ZENworks products
Provides a unified, Web-based administration console
Uses only standards-based protocols
Reduces overall wire traffic
ZENworks Configuration Management: A Single Solution for Systems Management
11
Allows full manageability over the Internet
Simplifies and speeds installation, deployment, and updates
1.2 The Management Paradigm
All design features of the new ZENworks Configuration Management architecture flow from the
basic Novell philosophy of the Open Enterprise: a simple, secure, productive, and integrated IT
environment across mixed systems. ZENworks Configuration Management empowers IT staff to
manage systems to support real users, with all their various security, location, device, and other
needs, while keeping simple, centralized control over the entire end-user environment. It also
supports the idea that IT staff should be empowered to manage systems according to the paradigm
that best reflects the organization’s business policies and the IT staff’s preferred working style.
ZENworks Configuration Management provides the flexibility to manage systems tactically (on a
device-by-device basis) or strategically (in synchronization with business policies), using any
combination of the three following distinct management paradigms:
Section 1.2.1, “Management by Exception,” on page 12
Section 1.2.2, “User-Based Management,” on page 12
Section 1.2.3, “Device-Based Management,” on page 13
novdocx (en) 16 April 2010
1.2.1 Management by Exception
Two of the most important considerations when evaluating any configuration management solution
are how well the administration design scales and what burden it places on the IT staff as they
update the solution to accommodate changing business policies. Novell is a pioneer of “management
by exception,” and ZENworks Configuration Management continues to offer this powerful method
of continuously adapting, with minimal IT effort.
Management by exception is a complement to policy-driven management. Management by
exception allows the general rules of configuration management to be at a high level across user or
device groups, while permitting exceptions at a more granular level to accommodate more
specialized needs.
For example, normal business policies might allow employees to remotely access the corporate
network. However, applying this policy across the board to all desktops, including devices in the
finance and legal departments, could expose the company to regulatory penalties and corporate
spies. Exception-based management allows IT staff to create and automatically enforce general
access policies, as well as more restrictive policies that are enforced on top of the general policies to
protect devices and users that require a higher degree of security. In this case, the exception policy
restricts access to normal business hours, on-site, and by authorized users. Exception-based
management allows for complete flexibility in accordance with business policies, without requiring
IT staff to manage separate policy silos for each type of user and machine.
1.2.2 User-Based Management
User-based management, which leverages user identities, group roles, and business policies, is the
gold standard for automation, security, and IT control. User-based management has always been a
Novell specialty. Although the underlying architecture has been dramatically enhanced in
ZENworks Configuration Management, the full power of user-based management has been retained.
12 System Planning, Deployment, and Best Practices Guide
True user-based configuration management separates users from the specific devices they use, and
treats the users as the company’s most valuable asset to be managed. Devices serve their proper role
as tools. Allowing users, rather than devices, to be managed as a first-class configured entity means
that policies, applications, and other configuration details can follow users from device to device.
User-based management also ties IT policies directly to business policies, which increases
responsiveness to changing business conditions. User-based management also leverages identity
stores and business systems across the enterprise to eliminate errors, increase security, standardize
workflows, document regulatory compliance, and support effective decision making.
User-based management can be defined as strategic, while device-based management is tactical. In
ZENworks Configuration Management, both can be mixed and matched according to business and
IT requirements by using management by exception. For example, a general policy can be applied to
a specific device and then overridden, depending on the identity information for the user who is
currently logged on. Or, a general policy based on user identities and roles can be overridden,
depending on the device being used and its context, such as a mobile device attempting to access the
network from beyond the firewall.
1.2.3 Device-Based Management
novdocx (en) 16 April 2010
Many organizations base their configuration management practices on the devices being managed.
In fact, this is the default method used by most of the configuration management products on the
market today. Without user-based and exception-based policy management, products that target
specific device configurations treat actual business policies and user needs as an afterthought—
essentially equating a specific user with a specific device. Applications, policies, and other
configuration information are associated to a managed device or set of managed devices. This
approach tends to force users into rigid roles instead of supporting users as dynamic participants in
evolving business processes. For that reason, Novell has not focused on device-based management
in the past.
However, the new ZENworks Configuration Management architecture adds device-based
management as a tool that can be used, in addition to the other management styles, to fill specialized
needs. For example, manufacturing-floor devices, public kiosks, and call centers where multiple
users work different shifts and share a single device are all instances where device-based
management might be more appropriate than user-based management. Additionally, companies that
normally rely on user-based management might need the ability to quickly set up a device for onetime use. For example, a customer might need to configure a device to auto-run a presentation in a
conference center without the bother of creating a new “user” for this one instance. With the new
ZENworks Configuration Management architecture, customers now have the option of using
device-based management whenever it suits their specific needs.
Because device-based management is the most familiar method to most IT professionals, and
because it is the fastest way to configure a device in the short term, before setting up long-term userbased policies, device-based management is the default management model after installing
ZENworks Configuration Management.
1.3 The Solution: ZENworks Configuration Management
ZENworks Configuration Management is based on an entirely new architecture designed to provide
a secure, highly usable, open environment for managing all of your Windows devices. ZENworks
Configuration Management provides you with a single, modular architecture that maximizes
ZENworks Configuration Management: A Single Solution for Systems Management 13
flexibility and scalability, simplifies and speeds management throughout the device life cycle,
minimizes processing demands on managed clients, reduces bandwidth consumption for
management processes, and uses standards-based protocols to seamlessly integrate with your choice
of user directories and object databases.
ZENworks Configuration Management lets you manage systems based on user identities, roles,
groups, and locations, so IT can work seamlessly with the company’s business organization and
policies. ZENworks Configuration Management gives you a secure, Web-based console for unified
control over all management tasks, from virtually anywhere.
If your organization is undertaking an Information Technology Infrastructure Library (ITIL)
initiative, ZENworks Configuration Management is the right choice for you. It has been built as a
modular set of components that use industry standards to build a product and set of solutions that
completely aligns with ITIL best practices and disciplines.
To find out more about our vision, visit the Novell ZENworks Configuration Management product
page (http://www.novell.com/zenworks) and download the white paper entitled A Blueprint for
Better Management from the Desktop to the Data Center.
novdocx (en) 16 April 2010
14 System Planning, Deployment, and Best Practices Guide
2
Performing Pre-Design Activities
novdocx (en) 16 April 2010
2
A firm understanding of the organization’s business and technical requirements and the existing
infrastructure components that will take part in the Novell
Management system is the first step in developing a solid design that meets the organization’s
immediate and future needs.
IMPORTANT: Throughout this document, we refer to the need for proper documentation.
Documentation is of the utmost importance. Documentation is a complete and accurate reference to
the system you have designed and built, but most importantly, it is a reference for the future. As
individuals transition in and out of the IT organization, the design documents become a reference as
new employees learn the infrastructure they support, including techniques, policies, and design
decisions. Documentation is also a good reference for others inside the organization who might not
be involved in the day-to-day management of the ZENworks Configuration Management
environment, but are involved in the management of other projects that might have an impact on the
ZENworks Configuration Management environment, including dependencies.
The following activities should be performed during the pre-design phase of implementing
ZENworks Configuration Management:
Section 2.1, “Perform a Business Assessment,” on page 15
Section 2.2, “Perform a Technical Assessment,” on page 16
Section 2.3, “Gather Other Critical Information,” on page 17
Section 2.4, “Develop High-Level Design,” on page 18
Section 2.5, “Develop Documentation,” on page 18
®
ZENworks® Configuration
Section 2.6, “Outputs from Pre-Design Activities,” on page 19
2.1 Perform a Business Assessment
Your first need is a detailed business assessment. If you do not have a solid understanding of what
the overall business (or individual business units) needs or desires, you cannot design a solution to
meet business needs.
Systems management software affects the entire business, so the various departments should
provide input and influence on what the system should look like. This does not mean that
departments outside of IT need to understand the technical complexities of the infrastructure and
how it is designed; they simply need to provide business requirements to the IT organization so that
their needs are met.
The best way to handle this is through a set of informal workshops, which include high-level
introduction to the technology, what it does, how the departments and end users benefit, and
possibly a short demonstration of the product. The three main reasons you hold these workshops are
to inform departments of what you are doing, get their buy-in, and get their feedback in the form of
technical requirements. The meetings should sufficiently inform department members so they begin
to give you feedback as to how they will leverage the system.
Performing Pre-Design Activities
15
The following list presents some ideas on how to perform the business assessment. You might think
of more ideas; use your imagination and tailor your business assessment according to each
organization's unique landscape.
Hold informal workshops and invite leaders from each department.
Survey departmental leaders and find out what they need to become more effective in their
roles. Find out how their staff can become more effective, given the software you are
deploying. Getting departmental leaders to answer a written survey can be very effective and
can give you detail that can be used when building both the high-level and the detailed designs.
A sample survey is provided in Section D.2, “Sample Business Requirements Survey
Questions,” on page 113.
Make sure you completely understand how the organization is dispersed and which
departments of the organization are represented at each of its physical locations.
Make sure you understand the monthly cycles for each of the departments in the organization.
This will assist you with determining peak times when the organization cannot afford to be
impacted by downtime.
Determine whether the organization is going through an ITIL (IT Infrastructure Library)
initiative. This has a direct impact on the solution you design and the services you provide. If
there is an initiative underway, you need to be involved in it and be completely informed. You
want to avoid making design changes mid-project because of the output from another project.
novdocx (en) 16 April 2010
2.2 Perform a Technical Assessment
You next need is for a technical assessment to review what you already have, identify what you
need, and document your requirements.
It is important to note that the technical assessment should be performed at the same time as the
business assessment. The two assessments should take no longer than a week to perform, depending
on the size and complexity of the organization and its infrastructure.
You need to have a good understanding of the existing infrastructure well before you introduce
ZENworks Configuration Management into the environment. In order to do this, you should hold a
set of workshops or meetings to obtain the information you need.
The two main outputs from a technical assessment are documentation on your findings, along with a
set of tasks that you need to perform. Information that you should gather includes the following:
Which operating systems must be supported?
How many users must be supported by the proposed solution?
Will there be support for roaming users?
How many offices and sites must the solution support, and how many users are at each
location?
Where are data centers located?
What is the network architecture, with details on link speeds, and so forth?
Will existing servers will be leveraged to support the ZENworks Configuration Management
infrastructure?
16 System Planning, Deployment, and Best Practices Guide
If so, you should gather the following software and hardware information:
Service pack levels (and whether they meet the minimum requirements for ZENworks
Configuration Management as listed in “Primary Server Requirements” in the ZENworks
10 Configuration Management Installation Guide)
Other software, for example, .NET.
CPU and memory requirements (and whether they meet the minimum requirements for
ZENworks Configuration Management)
IP addressing for all servers and other devices that will be part of the ZENworks
Configuration Management infrastructure
Previous versions of ZENworks that might already be hosted
What is the DNS infrastructure?
What is the DHCP infrastructure?
How should the IP subnet design be handled?
Which network access methods (VPN, Access Manager, and so forth) must be supported?
Which network infrastructure components and design (DMZ, NAT, and so forth) must be
supported?
What is the directory services design, including which directory services are being utilized
(Novell eDirectory
®
, Microsoft* Active Directory*, and so forth), and for what purpose
(Application support, LDAP, and so forth)?
novdocx (en) 16 April 2010
2.3 Gather Other Critical Information
You should also be familiar with other services that are running on the network and that rely on the
infrastructure. You should prioritize these services to better understand bandwidth utilization and
service levels that have been assigned to specific functions. If the customer is implementing ITIL
best practices, you should know about all disciplines that are currently being leveraged.
You should collect information about the following:
Which Service Desk software is currently used by the customer, and how does the deployment
of ZENworks Configuration Management fit within this framework?
Does the customer have a formal Service Level Agreement (SLA) process in place? If so, what
is it and can you access the documentation that explains it?
What is the customer’s Disaster Recovery and Service Continuity plans? How does this impact
the ZENworks Configuration Management design?
How does the customer plan for availability of services and resources? Is the customer fully
aware of availability requirements?
Does the customer leverage a Configuration Management Database (CMDB)? If so, which
CMDB? Does the customer have plans to include information that is stored in the ZENworks
database in their CMDB?
Does the customer have a formal method for keeping track of changes to applications that are
published to the end-user communities?
Does the customer have a Definitive Software Library (DSL) and Definitive Hardware Library
(DHL)?
Performing Pre-Design Activities 17
Is the customer using another framework product in its infrastructure, such as IBM* Tivoli*,
CA Unicenter*, or HP* OpenView*?
Does the customer leverage other products, such as SAP?
What other major projects are currently taking place at the customers sites?
2.4 Develop High-Level Design
After you have completed gathering data to use when building the design of the infrastructure, you
can then develop a high-level design. It is important at this point to understand what the
infrastructure is going to look like, so documenting your high-level thoughts and plans is critical to
the success of the project.
Developing a high-level design consists of building two main outputs:
Assessment document: A high-level design document outlines the general placement of
services across the company's infrastructure. This document does not need to identify servers to
be utilized or deployed to host the specific ZENworks services. The document should simply
outline the services themselves, and where they will reside across the network. Your high-level
design should include the following information:
Number of ZENworks Management Zones needed
novdocx (en) 16 April 2010
Placement of Primary Servers
Placement of Satellite devices
Placement of the Database Servers
Services that run at each location, based on the requirements gathered during the business
assessment.
Configuration of network services, such as DNS (forward/reverse lookup), DHCP, and so
forth
Utilization of network infrastructure, such as L4 switches to front the Primary Servers,
Satellite devices, or both
Remote access capabilities
High-level graphical design diagram: As a supplement to the assessment document, you
should also develop a graphical representation of the infrastructure. This diagram should reflect
exactly what you have described in the document, and it should be at a high enough level so
that everyone can see what the infrastructure is going to look like after the ZENworks
Configuration Management deployment is complete.
2.5 Develop Documentation
It is important to develop your documentation and then discuss it with all parties that have an
interest in the success of the project. Discussing the findings and recommendations in detail is
important to the success of this phase of the project and the success of the more detailed design
phase.
After you have conducted meetings to discuss the findings and recommendations, there will be items
in the high-level design that must be modified or changed. This is normal. Ensure that you capture
the changes and include them in documents you created during this phase. This is important so that
you have accurate information throughout the life cycle of the project. The information in these
documents will be leveraged during the design phase, so it needs to be complete and accurate.
18 System Planning, Deployment, and Best Practices Guide
2.6 Outputs from Pre-Design Activities
As mentioned in Section 2.4, “Develop High-Level Design,” on page 18, there are two main outputs
(or deliverables) from your pre-design activities:
Assessment document: This document highlights all of your findings from the business and
technical assessments that you perform. The document is the foundation for performing your
design activities, and needs to be kept up to date. The document includes information such as:
Requirements gathered during meetings and workshops with department leaders and
others inside the organization that will have an influence on the services ZENworks
Configuration Management will deliver.
A detailed summary of your technical findings, and what needs to change in order to
support ZENworks Configuration Management in the infrastructure. Suggestions should
include best practices and detailed recommendations to resolve any known issues.
High-level design information, including general placement of services and other
infrastructure components.
High-level graphical design diagram: This diagram is used to visually understand what the
infrastructure will look like after the deployment is complete. This is a foundational document,
and it should be further refined during the design phase of your project.
novdocx (en) 16 April 2010
Performing Pre-Design Activities 19
novdocx (en) 16 April 2010
20 System Planning, Deployment, and Best Practices Guide
3
Gathering Critical Information for
novdocx (en) 16 April 2010
Design Activities
After you have created your high-level design, you need to gather additional information to help you
design your specific implementation. Introducing Novell
into an environment involves the efforts, considerations, and input from multiple sources.
The following sections highlight the major areas of concern:
Section 3.1, “Design Criteria/Decisions,” on page 21
Section 3.2, “Scalability of the Primary Server,” on page 25
Section 3.3, “Scalability of Satellite Devices,” on page 30
Section 3.4, “Scalability, Fault Tolerance, Maintenance, and Sizing of the Database Server,” on
page 34
Section 3.5, “Virtualization Considerations,” on page 37
Section 3.6, “Ports Used by ZENworks Components,” on page 38
Section 3.7, “Network Considerations,” on page 40
3.1 Design Criteria/Decisions
A fundamental objective of a design is to balance the need for hardware while easing the load on the
customer's network during deployments.
®
ZENworks® Configuration Management
3
The following sections contain more information:
Section 3.1.1, “Decisions to Make Before Installing the Primary Server,” on page 21
Section 3.1.2, “Infrastructure Placement,” on page 24
Section 3.1.3, “Infrastructure Scale Assumptions,” on page 25
3.1.1 Decisions to Make Before Installing the Primary Server
A number of decisions should be made before installing the first ZENworks Primary Server.
The following sections contain more information:
“Required Functionality” on page 22
“Certificate Authority” on page 22
“Management Structure” on page 22
“Application Store” on page 22
“Staging and Grouping” on page 23
Gathering Critical Information for Design Activities
21
Required Functionality
Only the functionality that is needed by the customer should be enabled. Start with a simple
approach, harden the implementation, and then expand it in the future. For example, if Patch
Management, User Sources, and BOE Reporting are not required by the customer, do not enable or
install them.
Certificate Authority
ZENworks Configuration Management provides the choice of using an external Certificate
Authority (CA) or an internal ZENworks CA. The ZENworks CA is created during the installation
of the first ZENworks Primary Server and is used throughout the life of that ZENworks
Management Zone. The current lifespan of the internal certificate is ten years.
As each subsequent Primary Server is installed, its certificate is signed by the CA. The certificate is
distributed to all managed devices as part of the ZENworks Adaptive Agent installation. This lets
each Adaptive Agent connect to any Primary Server because each server’s certificate is signed by
the trusted CA.
Currently, there is no easy automated method for changing the CA. To change it, each server's
certificate must be re-minted and the certificate of the new CA must be delivered to all managed
devices. For this reason, the decision to use an external CA must be considered very carefully.
Certificates provided by VeriSign* usually expire after one or two years. If you use these
certificates, ZENworks Configuration Management loses all functionality on the expiration date
because ZENworks Adaptive Agents cannot check into the ZENworks Management Zone.
novdocx (en) 16 April 2010
Management Structure
With the previous generation of ZENworks, the technology was tied closely to Novell eDirectory
®
In traditional NetWare
or eDirectory file and print environments, ZENworks is structured
®
according to the design of eDirectory and was therefore based on geography. However, geography is
no longer a requirement for the structure of folders in the Management Zone. Because devices can
connect to any Primary Server, and all Primary Servers should be linked over fast links, the structure
of management can be based on other criteria.
Customers might want to base the folder structures for devices on business functions, such as
Human Resources, Finance, Sales, and so forth.
Basing the device folder structure on geography is still possible and might be required by many
customers. Some customers might want to implement policies and applications site by site, room by
room, and so forth.
Application Store
Traditional ZENworks implementations require file repositories to store application content. Users
and devices access this content via mapped network drives or directly via UNC paths defined in the
application object. Although this fits well with a traditional file and print model, it has the following
drawbacks:
Synchronization: If an application is to be made available to all users, the source content must
be copied to all servers. This requires additional products and processes to be introduced to
manage the location of content, such as the Tiered Electronic Distribution component of
ZENworks Server Management.
.
22 System Planning, Deployment, and Best Practices Guide
Rights: When files are stored in a traditional file and print model, the rights to these locations
must be managed carefully. If users roam between sites, they might need access to all
application repositories to ensure that applications can be installed and verified at any location.
With ZENworks Configuration Management, bundles can be created to install applications
from mapped network drives and UNC paths as before. If you used mapped drives and UNC
paths, file synchronization and the rights to those files must be managed outside of ZENworks
Configuration Management.
ZENworks Configuration Management also allows for application content to be injected in to the
ZENworks Content Repository. By default, the Content Repository is synchronized between all
Primary Servers and is downloaded by devices using HTTP. You can, however, specify which
Primary Servers host content (at least one Primary Server must host the content).
Using the ZENworks Content Repository has the following advantages:
Synchronization: Content is automatically synchronized to other Primary Servers and Satellite
devices. This allows devices to download content from the most appropriate location.
Rights: Rights to files do not need to be managed. Only device and users who are assigned to
the content in ZENworks Configuration Management have access to that content. If a user
accesses a ZENworks Content Repository, the content files are encrypted and cannot be used.
In a traditional model, a user with read access to an application store has the ability to manually
install any application that resides there.
novdocx (en) 16 April 2010
Content is firewall and location friendly: Files are delivered encrypted over HTTP. This
means that there is no need for the user to have the correct drive mapping with the necessary
rights. If the user has been assigned the content, it is downloaded via HTTP from the most
suitable location.
Downsides to using the Content Repository include the following:
Disk Space: Additional disk space is required. Many customers have extremely large
application repositories distributed over many servers. These repositories must be re-created in
ZENworks Configuration Management. If a customer has a 100 GB application repository,
ZENworks Configuration Management requires at least 100 GB on each Primary Server to
store applications, in additional to the space needed for other content, such as patches and
system updates.
MSI applications cannot be easily changed: After an MSI application is uploaded to the
Content Repository, it cannot be changed. To make changes, the original MSI must be updated
and then re-injected back into the Content Repository. In this scenario, a master store of all
applications must reside outside of ZENworks Configuration Management to allow for edits.
Staging and Grouping
Grouping devices is very important in ZENworks Configuration Management because it allows
applications, policies, and system updates to be deployed in a staged fashion.
We recommend that the following groups are identified in your customer environment:
Test devices: Identify test devices that are first to receive updates. Ensure that build versions
are represented for each operating system in the field.
IT departments: Identify IT staff that are typically the first users to receive live updates and
applications.
Gathering Critical Information for Design Activities 23
Early adopters: Identify early adopters who will test deployment in each business unit and
geographical location.
Home workers/VPN users: Identify home workers or users who use a VPN so they can help
test deployment via DMZ and VPN connections.
VIP users: Identify important users whose devices require special focus and attention. You
might want to transition executive laptops and workstations at the end of deployment.
General population: Create logical groups for the rest of managed devices, based on business
function or geography.
3.1.2 Infrastructure Placement
In order to calculate what infrastructure is required and where it should be located, you need to plan
for the scalability of ZENworks Configuration Management.
NOTE: At the time of writing this document, the SuperLab facility in Provo, Utah has provided
metrics and results, as seen in various places in this section, that give you a better understanding
about how the individual components scale. These figures will be kept up-to-date as this document
continues to grow over time.
novdocx (en) 16 April 2010
Based on the connection information, the number of ZENworks Primary Servers and Satellite
devices needed to support thousands of devices can be calculated with the following rules in mind:
“Primary Servers” on page 24
“Satellite Devices” on page 24
Primary Servers
Each Primary Server must be connected to every other Primary Server, the database, and the user
source by LAN speed or close links. Placing Primary Servers behind strong links allows for content
synchronization, credential verification from the user source, and access to the ZENworks
Configuration Management Database Server to occur quickly and efficiently. Performance suffers,
including response times when using ZENworks Control Center to perform administrative tasks, if
there are any barriers between Primary Servers and the Database Server,.
Satellite Devices
When configuring satellite devices, consider the following:
Currently, Satellite devices are primarily designed to reduce load on the network, not to reduce
load on the Primary Servers.
Bandwidth calculations are based on ZENworks Configuration Management having access to a
known percentage of the total bandwidth for a given link.
Satellite devices should be located at remote sites to provide content local to devices on the
local network.
24 System Planning, Deployment, and Best Practices Guide
3.1.3 Infrastructure Scale Assumptions
The following scale assumptions should be made when building the design of the infrastructure.
These actual scale assumptions might be different, based on the services you are providing and how
you break up the services across multiple servers.
ZENworks Primary Server: A single ZENworks Primary Server can provide all ZENworks
services (content, collection, and configuration) for as many as 3,000 devices in a ZENworks
Management Zone.
This is based on a Primary Server handling approximately 1,000 concurrent connections for all
service types (content, configuration, and content).
This is not real-world; see Section 3.2, “Scalability of the Primary Server,” on page 25 for
additional details on how these figures can change, and what you need to consider to ensure
that you are scaling to meet the needs of the organization.
Server-grade Satellite device: A single ZENworks Satellite (dedicated server) can provide
content services for as many as 1,000 concurrent devices.
This is not real-world; see Section 3.3, “Scalability of Satellite Devices,” on page 30 for
additional details on how these figures can change, and what you need to consider to ensure
that you are scaling to meet the needs of the organization.
Workstation-grade Satellite device: A single ZENworks Satellite (dedicated workstation)
can provide content services for as many as 250 concurrent devices.
novdocx (en) 16 April 2010
This is not real-world; see Section 3.3, “Scalability of Satellite Devices,” on page 30 for
additional details on how these figures can change, and what you need to consider to ensure
that you are scaling to meet the needs of the organization.
3.2 Scalability of the Primary Server
Understanding the scalability of the individual components that make up the ZENworks
infrastructure is of the greatest importance. You need to understand the limitations and where you
can expect to see performance degradation to ensure that you build an infrastructure that can
perform well, regardless of the load that your end-user community places on it.
The first area that you need to consider is the scalability of the Primary Server. It is important to
design your Primary Server placement based on the information you collected during your
assessment phase and what you anticipate your overall design will require. You should design your
infrastructure so that there are always Primary Servers available to service devices and the
administrators that are managing the system.
The following sections contain more information:
Section 3.2.1, “Factors Influencing Scalability,” on page 26
Section 3.2.2, “Load Testing in the Novell SuperLab,” on page 26
Section 3.2.3, “Achieving Scalability in the Real World,” on page 29
Gathering Critical Information for Design Activities 25
3.2.1 Factors Influencing Scalability
The main physical factors that govern the scalability of the Primary Servers are:
RAM: The majority of operations are performed by two services: zenserver and zenloader.
Each of these services can consume approximately 1.2 GB of RAM.
Disk I/O: Disk I/O is used when serving content for applications and updates.
The minimum hardware recommendations are listed in “Primary Server Requirements” in the
ZENworks 10 Configuration Management Installation Guide. If you can provide hardware that
exceeds these recommendations, your system will perform better. Adding more RAM, however,
does not make the specific ZENworks services (zenserver and zenloader) respond more quickly.
This is a Java* related issue and will be resolved in the future by moving from a 32-bit JVM* to 64bit JVM. If possible, we recommend that you use a 64-bit OS, so that you are ready when this
change is made. Additional processing power and faster drives can make the systems more
responsive, for example:
Using a quad core processor
Using 4 GB RAM
Allocating as much disk space as you can (RAID 5 with separate physical drives to separate
content and ZENworks Configuration Management from the OS)
novdocx (en) 16 April 2010
There are other factors that you need to consider, including:
Device refresh frequency
Number of Primary Servers being used to deliver content to the managed devices (software,
policies, images, patches, inventory collection, and so forth)
Number of administrators who have access to ZENworks Control Center
Frequency of uploading content in the ZENworks Content Repository
Number and frequency of reports run by administrators
3.2.2 Load Testing in the Novell SuperLab
ZENworks Configuration Management is tested in the Novell SuperLab in Provo, Utah to see how
much load can be placed on the individual components, and more importantly, where the individual
components start to break down and when performance is dramatically affected.
These tests provide insight on how far you can stretch the infrastructure design (for example, how
many Primary Servers you need, based on the components and services you plan to deliver).
The following three tests show how Primary Servers react under different loads, and how quickly
they can service individual requests when load is increased.
The test included the following hardware and software:
A Dell* 2950 Dual Quad Core 2.0Ghz, 4 GB RAM, RAID 5 (4 X 300 GB) server was used for
the Primary Server.
Windows Server* 2003 Enterprise on a 64-bit device.
ZENworks Configuration Management shipping code.
Deploying 100 MB of bundles (11 bundles) to an increasing number of devices.
26 System Planning, Deployment, and Best Practices Guide
All ZENworks Control Center settings used the default; after the 500-device test, retries were
420
390
360
330
300
270
240
210
180
150
120
90
60
30
0
200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2400
Number of Devices
Average Time to Refresh
(in seconds)
Single Server
Time to Refresh
(in seconds)
30.20
60.26
116.68
234.31
234.31
boosted to 800/10/20.
Three test passes for each test were run (for example, three test runs with 250 devices).
All devices were refreshed “simultaneously” (within 30 seconds).
The bundles were chained with the first bundle being associated to a device group set to
launch on refresh.
All tests were run on a full gigabit network.
The following sections contain more information:
“Test 1: Average Time to Refresh” on page 27
“Test 2: Average Time to Download” on page 28
“Test 3: Administrative Tasks Performed Under Load” on page 28
Test 1: Average Time to Refresh
In this test, we used a single ZENworks Primary Server and refreshed all machines inside the lab at
the same time. The devices then contacted the Primary Server at approximately the same time. We
calculated the amount of time it took for the refresh of the ZENworks Adaptive Agent to complete.
As the load increased, the average time increased as well. In fact, the time to complete the refresh
increased considerably at the 1,000 device mark. Between 1,000 and 2,000 devices, the amount of
time it takes to complete the refresh more than doubled.
novdocx (en) 16 April 2010
The Primary Server scaled well to this point; however, this does not mean that you should
implement a single Primary Server to manage 3,000 managed devices. You must always consider
the services that are being implemented, and most importantly, fault tolerance and load balancing.
The following graphic shows the average time to refresh managed devices:
Figure 3-1 Average Time to Refresh
Gathering Critical Information for Design Activities 27
Test 2: Average Time to Download
45
40
35
30
25
20
15
10
5
0
200 400 600 800 1000 1200 1400 1600 1800 2000 2200 2400
Number of Devices
Average Time to Download
(in minutes)
Single Server
Time to Download
(in minutes)
5.11
7.81
15.57
22.84
30.57
This test demonstrates the results of a download of 100 MB of bundle content, spread across 11
bundles that are chained together. The server load increased as the load (in terms of devices)
increased.
The following graphic shows the number of minutes it took to download the content:
Figure 3-2 Average Time to Download
novdocx (en) 16 April 2010
Test 3: Administrative Tasks Performed Under Load
This test used a series of administrative tasks performed on a server with no load and then with a
load. These results demonstrate what to expect in a given environment when a certain load is placed
on a Primary Server that is multi-tasking. This test provides insight into what you can expect if you
do not properly distribute services across multiple Primary Servers. These are conditions that should
not exist in a real-world environment; Novell runs these tests to see when the processes begin to
break. A well-designed infrastructure should perform well for you regardless of the load you are
placing on the servers.
The load consisted of 480 devices running the Daily Use Test.
The Daily Use Test environment in the Super Lab consisted of the following:
Single Server: Windows Server 2003 x86_64
Server hardware: Dell 2950, Quad Core 2.0 MHz, 8 GB RAM
External Microsoft SQL Server* 2005 database
Definition of the “Daily Use” included the following:
24-hour period simulated in four hours
Three bundle pushes of 105 chained bundles (30 MB to 1 KB) per device
One full and three delta inventory scans per device
28 System Planning, Deployment, and Best Practices Guide
One patch distribution per device
Four device refreshes per device
Ten devices continually restoring images
This test environment stretched the limits of what the ZENworks Configuration Management
system is able to achieve, giving us a good idea of where the system starts to reach its limitations. It
comes close to a real-world simulation.
Table 3-1 Tests and results.
novdocx (en) 16 April 2010
Test Name Test Description
BOE Report Run Predefined BOE
report - Bundle
Deployment Status (313
pages)
Inventory Report Run canned report
“Devices By Machine /
Login Name”
Policy Create policy, assign it to
60 devices, and perform
a quicktask on all 60
devices to get the policy
Multicast Create Multicast bundle
and multicast to 60
devices
Bundle Create an MSI Bundle of
OpenOffice, assign it to
60 devices, and refresh
all 60 by using a
quicktask
Primary Server Under No
Load
15 seconds 18 seconds
7 seconds 8 seconds
7 minutes 43 seconds 7 minutes 45 seconds
4 minutes 20 seconds 4 minutes 27 seconds
25 minutes 30 seconds 1 hour 10 minutes 17
Primary Server Under
Load
seconds
When the server is under load, and we created an MSI bundle and assigned it to 60 devices, there is
a large increase in the amount of time it takes to complete the task. In this situation, it is
recommended that you have a dedicated server for ZENworks Control Center so that there would be
virtually no impact on performance.
The ZENworks Control Center is used by administrators to perform administrative tasks, including
the management of content within the system. For environments that are managed by a small
number of administrators (one or two), accessing ZENworks Control Center from a Primary Server
that is also performing work might not be cause performance issue. For larger implementations
(several thousand devices, large amounts of daily content activity, and several administrators),
having a dedicated Primary Server in place for ZENworks Control Center resolves potential
performance issues.
3.2.3 Achieving Scalability in the Real World
Section 3.2.2, “Load Testing in the Novell SuperLab,” on page 26 discussed testing in the Novell
SuperLab to determine the limits of the ZENworks system. Scalability, on the other hand, is
achieved through the proper placement of services, a well thought-out design, and the proper
configuration of services within the ZENworks Configuration Management system itself.
Gathering Critical Information for Design Activities 29
For example, even though we know that a Primary Server can manage 3,000 devices, you should
never deploy only one Primary Server in a 3,000-device environment. For this situation, we
recommend the following as a starting point:
Three Primary Servers to manage load and build a system that is fault tolerant.
A dedicated Database Server using Sybase*, Oracle*, or Microsoft SQL Server.
This system should be further enhanced by considering the following:
Using an L4 switch to manage fault tolerance and load balancing.
Using DNS and aliases for managing the load placed on Primary Servers during deployment
and registration.
Using custom Closest Server Rules to designate certain servers for specific functions (content,
collection, etc.) and to exclude servers from specific functions, or all functions. If a Primary
Server is not listed in the Closest Server Rules, then it does not perform the functions.
Using a dedicated Primary Server for reporting.
Using a dedicated Primary Server for Patch Management.
Using a dedicated Primary Server for imaging.
novdocx (en) 16 April 2010
Using a dedicated Primary Server for ZENworks Control Center.
Using Satellite devices for distribution of content.
The Primary Servers are the heart of your ZENworks Configuration Management environment. You
want to protect these systems from major disruption. Primary Servers can be used for distribution of
content, but this needs to be factored in to your design.
Some of the major factors that you need to consider with ZENworks Configuration Management
and Primary Servers are the following:
Each Primary Server can comfortably handle 1,000 concurrent connections.
Each Primary Server can manage 3,000 devices that are registered into the ZENworks
Management Zone.
A ZENworks Management Zone can scale to 40,000 devices. This has been validated in the
SuperLab and is what Novell recommends as the upper limit to the Management Zone size.
We also recommend that Primary Servers and the Database Server be on the same network, in the
same data center. We do not recommend spanning WAN links with Primary Servers because
replication of the Content Repository could cause utilization issues. Placement of services in a
multi-site environment is done by utilizing the Satellite role, which is discussed in more detail in the
next section.
3.3 Scalability of Satellite Devices
The second area that you should carefully consider is the scalability of the Satellite devices. Satellite
devices are designed to reduce load on the network, not to reduce load on the Primary servers.
Satellite devices help reduce redundant traffic, load, and utilization from the WAN. Even if devices
are located at a remote site, they connect to the central site for authentication and checking in with
the Primary Servers to see if there is work to do. The actual work should be performed with remote
Satellite devices strategically placed to service work requests from managed devices.
30 System Planning, Deployment, and Best Practices Guide
Loading...